As a first step in the 3.0.0 release process the stable branch was branched off to branches/fixes_3_0 and the version number was updated to 3.0.1
The version in trunk was raised to 3.1.1
Scripts might need modification accordingly.

Mailing lists / lazarus / 2015-01
35 messages · 13 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
As a first step in the 3.0.0 release process the stable branch was branched off to branches/fixes_3_0 and the version number was updated to 3.0.1
The version in trunk was raised to 3.1.1
Scripts might need modification accordingly.
Good news!
Chances of custom attributes[1] (or something like this) in release 3.0? I have plans to use IoC[2] and DI using this feature.
Thank you!
[1] - http://forum.codecall.net/topic/76463-introducing-attribute/ [2] - http://martinfowler.com/articles/injection.html
As a first step in the 3.0.0 release process the stable branch was branched off to…
So finally there'll be no 2.8 ?
?
Anyway, it works well. I just updated to 29419 and built it with 2.6.4. Lazarus compiled well too. Just have Lazarus 1.3 r47310M FPC 3.1.1 x86_64-linux-qt. ?
Thanks
?
Vojt?ch?
______________________________________________________________
As a first step in the 3.0.0 release process the stable branch was branched off to branches/fixes_3_0 and the version number was updated to 3.0.1
The version in trunk was raised to 3.1.1
Scripts might need modification accordingly.
Good news! Chances of custom attributes[1] (or something like this) in release 3.0? I…
No. One of the reasons for branching off 3.0 now is that the custom attributes can be merged to trunk (or so I understood)
Michael.
As a first step in the 3.0.0 release process the stable branch was branched off to…
Marco van de Voort wroteAs a first step in the 3.0.0 release process the stable branch was branched off to branches/fixes_3_0 and the version number was updated to 3.0.1
Thanks Marco - good news indeed. Let the testing begin! ;-)
ps:
I remember reading a while back from the Lazarus/FPC conference a few weeks back that dynamic loading of libraries (like Delphi does) was demoed. Is that functionality in the next FPC release (or parts of it)? I don't need it - I was just curious.
From the bit I've read about recent FPC changes I think its time I take
a look at finally trying FPC with the tiOPF v3 branch to bring it on par with Delphi again.
Regards,
- Graeme -
Not even remotely. Also this is currently in a seperate branch and the reason we branched 3.0 finally off was that we could reintegrate branches back into trunk.
Regards,
Sven
As a first step in the 3.0.0 release process the stable branch was branched off to…
For the record, at what revision number did this happen (i.e. if I want to grab /the/ /last/ 2.7.1 what should I tell svn)?
I don't know. Since trunk are daily/scratch versions that kind of info is not recorded seperately. Check trunk SVN log for details (should be within the last 25 revs)
Was going to, but thought I'd ask.
r29399 | marco | 2015-01-04 21:09:04 +0000 (Sun, 04 Jan 2015) | 1 line
* version updated to 3.1.1
------------------------------------------------------------------------ r29397 | joost | 2015-01-04 20:46:57 +0000 (Sun, 04 Jan 2015) | 1 line
* Renamed pas2js package to utils-pas2js, for consistency
Not even remotely. Also this is currently in a seperate branch and the reason we branched…
Sven Barth wrotereason we branched 3.0 finally off was that we could reintegrate branches back into trunk.
No problem, I fully understand. Thanks for the info.
Regards,
- Graeme -
I don't know. Since trunk are daily/scratch versions that kind of info is not recorded…
Marco van de Voort wrote> > For the record, at what revision number did this happen (i.e. if I want > > to grab /the/ /last/ 2.7.1 what should I tell svn)? I don't know.
A quick look in the git mirror.
https://github.com/graemeg/freepascal/commits/master
Seems the last 2.7.1 commit (in Trunk/Master) was r29397 (SubVersion) or f70d35a (git).
The next commit after that [r29399 (svn) or 5f1a29ec (git)] the compiler version was bumped to 3.1.1 by Marco.
Regards,
- Graeme -
Was going to, but thought I'd ask. r29399 | marco | 2015-01-04 21:09:04 +0000 (Sun, 04…
Lazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on SPARC using Debian "Lenny", except that toolbar icons don't appear (bug 25470, so this is not in fact fixed or has reverted). I can't test on Debian "Squeeze" at the moment since it looks as though lnet doesn't compile with recent 2.7.1 which I need to look at since I'm using it in the code I'm trying to test.
Problem was due to some local improvements to ltelnet subcommand handling that I'd never submitted as a patch, my patched copy was no longer compatible with FPC trunk. Now on Mantis as 27273.
Lazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on SPARC using Debian "Lenny",…
Mark Morgan Lloyd wroteLazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on SPARC using Debian "Lenny",
Same combination on a PPC Mac raises an exception as below when the IDE is told to Tools -> Options.
TApplication.HandleException Error reading
ComponentsListView.Items.LazData: Stream read error Stack trace:
$10118410 TREADER__READPROPERTY, line 1279 of
/usr/local/src/fpc/fpc-trunk/rtl/objpas/classes/reader.inc
Apart from that and the blank toolbar issue it appears OK. Does anybody want me to get a backtrace and raise a bug?
TListItems.ReadLazData reads a TLazItemInfo, which is a record:
TLazItemInfo = record // packing is not needed and not wanted
ImageIndex: Integer;
StateIndex: Integer;
OverlayIndex: Integer;
SubItemCount: Integer;
end;Without "packed" the layout depends on the platform. But the stream should be streamed the same on all platforms. So it needs "packed". OTOH someone added a comment that it is not wanted.
Has someone an idea why "packed" is "is not needed and not wanted"?
Mattias
Annotate that unit and see who wrote that ?
z.
On Sat, 10 Jan 2015 12:49:04 +0000 TListItems.ReadLazData reads a TLazItemInfo, which is…
10.01.2015 16:39, Mattias Gaertner ?????:
AFAIK such record has the same layout on 32 and 64 bit targets, at least when {$packrecords c} is in effect. But writing it directly to stream is incorrect anyway because you'll get different data on big and little-endian targets.
Regards,
Sergei
As a first step in the 3.0.0 release process the stable branch was branched off to…
Marco van de Voort wroteAs a first step in the 3.0.0 release process the stable branch was branched off to branches/fixes_3_0 and the version number was updated to 3.0.1
Which version the 3.0 branch will have just after 3.0 release?
fixes_3_0 will be ver. 3.0.2 (after 3.0.0 release).
zeljko
No, it will after 3.0.2 is released it wil be increased to 3.0.3. Take a look at fixes_2_6 to see what I mean... (which is )
Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150112/ae2a17ce/attachment.html>
fixes_3_0 will be ver. 3.0.2 (after 3.0.0 release). zeljko
wich one is rigth number of version ?
stable is 2.6.4
svn 2.7.1 ?????
fixes 3.0 or 3.0.1
trunk 3.1.1 ?
on osx yosemite
before change this version number 2.7.1 to 3.1.1, I installed fpc trunk version, but now nothink
write on terminal
? fpc
Error: ppc386 can't be executed, error message: Failed to execute "ppc386", error code: 127
? which fpc
/usr/local/bin/fpc
How to I install fpc svn:
first install fpc and source stable version then
svnVer="3.1.1" --> before it was 2.7.1 but, .../compiler/makefile.fpc has "version=3.1.1" so I have to changed
svn co http://svn.freepascal.org/svn/fpc/trunk /opt/freepascal/3.1.1 make clean all install CPU_TARGET=x86_64
INSTALL_PREFIX=/opt/freepascal/3.1.1
How to I can install fpc svn on OSX? or pelase share stable version of fpc Is Nobody using fpc trunk on OSX ???
wich one is rigth number of version ? stable is 2.6.4
yes
svn 2.7.1 ?????
2.7.1 was "trunk" and was changed to 3.1.1.
fixes 3.0 or 3.0.1
fixes_3_0 has 3.0.1.
trunk 3.1.1 ?
yes
see compiler/version.pas
[...]
Mattias
question: Where can I find "install fpc trunk" script? for osx. I attached mine sctipt , Its still testing and has problems. Can you or somebody Help or fix this my script?
first page has parameters, can change that.
Script download fpc stable dmgs, attach thats and install dpks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeman_fpc_laz_test.sh
Type: application/x-sh
Size: 19943 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150112/04969c01/attachment-0001.sh>
wich one is rigth number of version ? stable is 2.6.4 svn 2.7.1 ????? fixes 3.0 or 3.0.1…
FreeMan wrotewich one is rigth number of version ?stable is 2.6.4svn 2.7.1 ?????fixes 3.0 or 3.0.1trunk 3.1.1 ? on osx yosemitebefore change this version number 2.7.1 to 3.1.1,
Any reference that I'm making to compiling Lazarus with 2.7.1 are for testing purposes only, and are specifically because one of the platforms I'm interested in is SPARC which got code generation fixes post-2.6.4.
So listen to people like Mattias since they know what they're doing: I don't claim to :-)
Don't worry, who tell about script how to install fpc from trunk, I'm definitely listening :)
Lazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on SPARC using Debian "Lenny",…
The same combination builds on SPARC Solaris 10 for "all" but not for "bigide", giving
/export/home/usr_local/share/lazarus-trunk-47318/components/sqldb/registersqldb.pas(505,5) Error: (5000) Identifier not found "TIBConnection" registersqldb.pas(564) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
make[2]: *** [sqldblaz.ppu] Error 1
make[2]: Leaving directory
`/export/home/usr_local/share/lazarus-trunk-47318/components/sqldb'
Crudely commenting-out the relevant call to RegisterPropertyEditor() appears to fix it, but I've done so without significant understanding of what's going and haven't checked whether it's been fixed in current trunk (a few dozen revisions later), neither have I checked what IB's functionality is on Solaris.
Subject to some library path issues basic operation is OK except Tools -> Options bombs with
TApplication.HandleException Error reading
ComponentsListView.Items.LazData: Stream read error Stack trace:
$0014FE1C TREADER__READPROPERTY, line 1282 of
/export/home/usr_local/src/fpc/trunk-2.7.1-29398/rtl/objpas/classes/reader.inc $0013F04C TCOMPONENT__READSTATE, line 320 of
/export/home/usr_local/src/fpc/trunk-2.7.1-29398/rtl/objpas/classes/compon.inc $003282D0 TCONTROL__READSTATE, line 3657 of ./include/control.inc
etc. with a dialogue reporting "Stream read error". Please advise if anybody wants a backtrace or more info. This operation also failed on PPC Linux but not necessarily with the identical error, it's OK on SPARC Linux.
I can't check Solaris on x86-64, or any releases later than Solaris 10 although I might look at OpenSXCE at some point.
Mark Morgan Lloyd wroteSubject to some library path issues basic operation is OK except Tools -> Options bombs
Also Help -> About gives an alignment error, doesn't happen on PPC Linux or SPARC Linux. Also the toolbar icons are slow to display (i.e. like
> Debian "Lenny", except that toolbar icons don't appear (bug 25470, so > this is not in fact fixed or has reverted). I can't test on Debian
No, it will after 3.0.2 is released it wil be increased to 3.0.3. Take a look at…
What version number RCs will receive?
2.9.x or 2.99.x sounds a bit more... suitable, it was the version number management used for ages iirc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150112/c50ff31a/attachment.html>
RCs don't have separate version numbers. The version number for 3.0.0 RC will be 3.0.0.
Regards,
Sven
The same combination builds on SPARC Solaris 10 for "all" but not for "bigide", giving…
This combination compiles natively (i.e. not as a cross-compiler) on ARM running on Qemu. Lazarus built with either "all" or "bigide" appears to run, the OS in this case was Debian "Squeeze" and toolbar icons appeared OK.
On mipsel running on Qemu compiling Lazarus fails with
..
(9009) Assembling codecache
(3104) Compiling customcodetool.pas
(3104) Compiling codetree.pas
/usr/local/share/lazarus-trunk-47318/components/codetools/codetree.pas(824,1) Fatal: Internal error 2013022101
Fatal: (1018) Compilation aborted
make[1]: *** [codetools.ppu] Error 1
make[1]: Leaving directory
`/usr/local/share/lazarus-trunk-47318/components/codetools' make: *** [codetools] Error 2
If anybody wants more detail on this error please say, I find Qemu useful for some of the more obscure architectures but it's painfully slow.
On mips running on Qemu compiling Lazarus fails with
make -C packager/registration
make[1]: Entering directory
`/usr/local/share/lazarus-trunk-47318/packager/registration' Makefile:196: *** The Makefile doesn't support target mips-linux, please run fpcmake first. Stop.
make[1]: Leaving directory
`/usr/local/share/lazarus-trunk-47318/packager/registration' make: *** [registration] Error 2
Attempting to run fpcmake (with minimal investigation of the "right" way of doing things) fails with
0 1>markMLl at pye-dev-07d:/usr/local/share/lazarus-trunk-47318$ fpcmake Processing Makefile.fpc
Error: Target "linux", package "rtl" not found
-----
The combination above compiles Lazarus in both 32- and 64-bit mode on an AMC Athlon running Linux (Debian "Wheezy"), but Lazarus doesn't run. I've not investigated further.
30.01.2015 17:39, Mark Morgan Lloyd ?????:
I reproduced it, it's caused by combination of leaf function with open array parameter passed by value and {$implicitexceptions off} directive. Pretty rare stuff to meet in regular code. Will try to fix.
Regards,
Sergei
Thanks Sergei, I'm glad I'm not imagining things :-)
I'd quite like to look at the same combination on a couple more architectures, when I'm done I'll raise some bug reports.
I know that I should be following trunk for testing, but particularly with some of the slower systems a compiler or Lazarus build takes long enough that it's more practical to call an arbitrary revision a testing checkpoint.
Same combination on a PPC Mac raises an exception as below when the IDE is told to Tools…
Working on the same combination as above on a PPC G4 Mac with OS X 10.4 and XCode 2.0. A make all gives me
Assembling (pipe) units/powerpc-darwin/nogui/synregexpr.s synbeautifier.pas(157,63) Error: Default values can only be specified for value, const and constref parameters
synbeautifier.pas(465,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
This looks like a spurious =0 in the interface (not implementation) declaration, when commented-out compilation completed. I don't know why I've not seen this on other platforms.
The program starts, but sticks at the initial configuration form with inoperative buttons (some other controls work). If I grab an "about right" file from another machine I'm similarly stuck at the "upgrade" form. I've not tried building a project using lazbuild since I assume that all LCL stuff is similarly affected.
I assume that this is due to the excessively-old version of Xcode that's on this machine, and unless somebody really wants me to try updating it or use a later Lazarus revision I'm in no hurry to (I'm currently trying to clear stuff off my desk, not add to it).
Annotate that unit and see who wrote that ? z.
Now on Mantis as 27719.
When will FPC 3.0.0 be released officially???
2015-03-24 19:26 GMT+07:00 Mark Morgan Lloyd <
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150325/dafd3a38/attachment.html>