Lazarus
Programming => General => Topic started by: snorkel on December 04, 2012, 05:19:47 pm
-
Since I have been using Lazarus I have discovered a couple of little gems I could never do in Delphi:
(these don't work in Delphi mode)
Case with Strings:
case mystring of
'one':showmessage('bla');
end;
+= operator for concatenation
mystring:= 'bla bla'#13#10;
mystring+='yada yada yada'
Anyone else have some gems to share?
-
All open-source
As for the IDE: Codetools keep working while debugging an app. From what I hear, in Delphi while debugging you can not use code completion/navigation?
Afaik, more code completions. http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools (see Identifier_Completion); Does Delphi has all of them?
Way advanced codefolding in the editor
Highlight of matching begin/end (There is a 3rd party tool for Delphi though) http://wiki.lazarus.freepascal.org/New_IDE_features_since#block_matching
Faster editor (at least compared to some Delphi, have not tested the latest): Load a huge (300.000 lines) file; "select all"; Delphi used to give you time for a coffee.
Debugger, while it lacks many things, it has a history and can show you the previous values of watches.
Faster startup (again have not tested latest Delphi)
Upcoming in 1.1 (currently only 32 bit Intel / 64 bit intel is being worked on / possible ppc on MAC) : PascalScript Macros to control the editor.
-
Before that, state which Delphi version you are referring. Case with strings AFAIK is available in recent version (XE and up). C-style operators don't though (but is more like a flaw than feature to me). These things are Free Pascal only:
- http://www.freepascal.org/docs-html/ref/refch11.html#x105-11500011
- http://www.freepascal.org/docs-html/ref/refse24.html#x56-630004.6
-
Faster editor (at least compared to some Delphi, have not tested the latest): Load a huge (300.000 lines) file; "select all"; Delphi used to give you time for a coffee.
Some times I need to use log and debug files . To spot faster some data on the log I use C highlighting and it works fine for me. I used to use Notepad++ on windows and gedit on Linux but when the log is huge +300K lines to 600k lines I can't use them. But Lazarus runs smoothly even when using the mouse wheel and with a selected text that lights up all the file like a Christmas tree!!!
-
bitpacked record like c/c++
type
bit = 0..1;
BitsInaByte = bitpacked record
bit0 : bit;
bit1 : bit;
bit2 : bit;
bit3 : bit;
bit4 : bit;
bit5 : bit;
bit6 : bit;
bit7 : bit;
end;
-
Before that, state which Delphi version you are referring. Case with strings AFAIK is available in recent version (XE and up). C-style operators don't though (but is more like a flaw than feature to me). These things are Free Pascal only:
- http://www.freepascal.org/docs-html/ref/refch11.html#x105-11500011
- http://www.freepascal.org/docs-html/ref/refse24.html#x56-630004.6
Nope, not in XE and up:
I have Xe2 and it does not work.
[DCC Error] abu_formU.pas(90): E2001 Ordinal type required
[DCC Error] abu_formU.pas(91): E2010 Incompatible types: 'Integer' and 'string'
I have Xe3 as well, but have not installed it. Borcadero has been against the case with strings for years.
But according to the docs even Xe3 does not have the ability.
http://docwiki.embarcadero.com/RADStudio/XE3/en/Declarations_and_Statements#Case_Statements (http://docwiki.embarcadero.com/RADStudio/XE3/en/Declarations_and_Statements#Case_Statements)
You can use a CHAR in a case, but not a string.
-
Nope, not in XE and up:
I have Xe2 and it does not work.
[DCC Error] abu_formU.pas(90): E2001 Ordinal type required
[DCC Error] abu_formU.pas(91): E2010 Incompatible types: 'Integer' and 'string'
I have Xe3 as well, but have not installed it. Borcadero has been against the case with strings for years.
But according to the docs even Xe3 does not have the ability.
http://docwiki.embarcadero.com/RADStudio/XE3/en/Declarations_and_Statements#Case_Statements
You can use a CHAR in a case, but not a string.
OK, I guess we're one step ahead Delphi for this :D
-
Then again.. Delphi has a very advanced remote debugger. Delphi has MUCH smaller executables... There are a very, very, very big lot of third party components which add a very big lot of funcionality, from a much bigger group of users..
Lazarus has:
1. No native client-server databases in Lazarus,
2. No native remote debugger,
3. No bigger IDE component framework like DevExpress or JVCL. A lot of needed functionality/components have to be coded by hand.
4. Missing components like on Torry (or I have missed/not found it yet).
5. No decent web-framework like VCL for the Web.
So I can live without the strings in case statement (wondering about the big advantage over a enumeration or a decent if-then-else if) and the bitpacked record will have some decent alternative in Delphi too. What is the advantage over having something that is in a language like C or C++ if more imporant functionality is missing??
I would love to move to Lazarus and I have deep respect for everyone involved in FreePascal and Lazarus. Don't let there be any doubt about that. But untill now, the things Delphi can or has over Lazarus are too many.
-
Delphi has MUCH smaller executables...
Are you sure with the FM? A friend of mine shows that it's bigger than LCL-powered counterpart.
No native client-server databases in Lazarus
What would be the advantage of this over having bindings for many common dbms?
No bigger IDE component framework like DevExpress or JVCL. A lot of needed functionality/components have to be coded by hand.
3rd party support problem, not really a Lazarus problem. In fact, many other functionalities are available (though mostly undocumented) in FCL (content template, expression parsing, json, http server/client, encryption, and more that I can't list all of them).
Missing components like on Torry (or I have missed/not found it yet).
Same as above, partially solved by Lazarus-CCR (contribute please!)
But untill now, the things Delphi can or has over Lazarus are too many.
But it doesn't run on Linux... (most important thing for me, as it's my primary OS now)
-
1. No native client-server databases in Lazarus,
Do you mean that Delphi provides native object FPC units that directly connect to db servers without any need for DLLs? Seems like those Delphi guys have been reinventing the wheel as well as inviting a maintenance nightmare... but it would be impressive.
Or do you mean that there is some database server programmed in Delphi available for Delphi programs?
2. No native remote debugger,
You can debug with gdb over SSH if your target platform is *nix, AFAIU... Haven't tried it though.
I would love to move to Lazarus and I have deep respect for everyone involved in FreePascal and Lazarus. Don't let there be any doubt about that. But untill now, the things Delphi can or has over Lazarus are too many.
I understand your sentiments. Fortunately, Lazarus is improving all the time ;)
-
LCL (the first choise in create new project), empty form is 14,6 MB, delphi 2007 same new project, empty form is 407 kb.
Delphi has the same "bindings". External or not, there are also client-server databases, written in native Delphi, based on components. That gives you total ownership of both client and server, along with control over who is accessing your data and who is not. Not to mention that most of the common dbms-es run on Windows, not on Linux.
3rd party support problem or not, fact remains that DevExpress and Jedi VCL only excist for Delphi. So do most of the reporting engines. I learned that it is very hard to port Delphi components to Lazarus if you don't have a very thorough knowledge of Lazarus (and lots of spare time).
You mention documentation allready..
Maybe Lazarus CCR is not too easy to find..
-
LCL (the first choise in create new project), empty form is 14,6 MB, delphi 2007 same new project, empty form is 407 kb.
Yep. Read the "size matters" wiki article. If after reading that it that is a problem to you... well... to each his own.
Delphi has the same "bindings". External or not, there are also client-server databases, written in native Delphi, based on components. That gives you total ownership of both client and server, along with control over who is accessing your data and who is not.
Well yes. Same applies if you use an open source C/C++/whatever database. Once again, to each his own.
That said, if you want to upgrade e.g. the existing TDBF code to provide client/server functionality and e.g. an SQL layer, I'd certanily not stop you ;)
Not to mention that most of the common dbms-es run on Windows, not on Linux.
Not sure what does has to do with anything - I must be misunderstanding you. Oracle, Firebird, Interbase, MySQL, MS SQL Server, PostgreSQL all run on Windows and all have native SQLDB connectors in Lazarus. Then again, many of them run on *nix too, yes.
Also, I'd think that most data centers/bigger companies run their dbs on anything but Windows... and the SME world perhaps still does things mostly on Windows... Laz (and Delphi) can deal with both, I'd think.
-
Do you mean that Delphi provides native object FPC units that directly connect to db servers without any need for DLLs? Seems like those Delphi guys have been reinventing the wheel as well as inviting a maintenance nightmare... but it would be impressive.
Or do you mean that there is some database server programmed in Delphi available for Delphi programs?
I wonder if you point out my bad explaining or if you are asking this.
Offcourse: database server programmed in delphi available for delphi programs.
2. No native remote debugger,
You can debug with gdb over SSH if your target platform is *nix, AFAIU... Haven't tried it though.
So not natively.. and if 'm correct: unix -> linux.
I would love to move to Lazarus and I have deep respect for everyone involved in FreePascal and Lazarus. Don't let there be any doubt about that. But untill now, the things Delphi can or has over Lazarus are too many.
I understand your sentiments. Fortunately, Lazarus is improving all the time ;)
[/quote]
Yes. Glad it is. Hope that I can edit my post and add Lazarus for Android.
Maybe offtopic for my initial remark but I tried to port all kinds of components, running into the differences with RTTI etc. Maybe I suggest one day that the main page of the Lazarus website could be better used to point to documentation sections and make the release announcements less important.
I do stronly prefer Lazarus. But some of the things I plan to port, I want to make commercial or at least closed source. I have to make a living somehow and I prefer cross platform -> Lazarus.
But if I don't give away my ideas in questions on the forum, I will not have something ready for quite some time from now unless in Delphi..
-
..
I have Xe2 and it does not work.
..
Borcadero has been against the case with strings for years.
OK, I guess we're one step ahead Delphi for this :D
Hmm, yes and no. I guess they want to encourage the use of more optimal ways. Case strings, and string comparison in general is extremely slow compared to indexing and all kinds of other ways.
But i guess it's ok if language supports it, and if it's used for small things. But there could be developers that take this into larger projects and hurt its performance.
-
LCL (the first choise in create new project), empty form is 14,6 MB, delphi 2007 same new project, empty form is 407 kb.
Yep. Read the "size matters" wiki article. If after reading that it that is a problem to you... well... to each his own.
Won't keep me from using Lazarus. Delphi executables don't grow to 15 MB with only an empty form. But I could understand if the exe size is due to compiling everything installed in Lazarus.
Delphi has the same "bindings". External or not, there are also client-server databases, written in native Delphi, based on components. That gives you total ownership of both client and server, along with control over who is accessing your data and who is not.
Well yes. Same applies if you use an open source C/C++/whatever database. Once again, to each his own.
That said, if you want to upgrade e.g. the existing TDBF code to provide client/server functionality and e.g. an SQL layer, I'd certanily not stop you ;)
I would if the code would make sense but it looks like spagetti. If I would upgrade it, I would use Tquery for SQL layer. But again: spagetti. I have tried to port TQuery but gave up on the goto's and pointers.
Not to mention that most of the common dbms-es run on Windows, not on Linux.
Not sure what does has to do with anything - I must be misunderstanding you. Oracle, Firebird, Interbase, MySQL, MS SQL Server, PostgreSQL all run on Windows and all have native SQLDB connectors in Lazarus. Then again, many of them run on *nix too, yes.
Also, I'd think that most data centers/bigger companies run their dbs on anything but Windows... and the SME world perhaps still does things mostly on Windows... Laz (and Delphi) can deal with both, I'd think.
[/quote]
That is where my remarks about native Lazarus client-servers are about: in that case both would run on the same OS.
-
Do you mean that Delphi provides native object FPC units that directly connect to db servers without any need for DLLs? Seems like those Delphi guys have been reinventing the wheel as well as inviting a maintenance nightmare... but it would be impressive.
Or do you mean that there is some database server programmed in Delphi available for Delphi programs?
I wonder if you point out my bad explaining or if you are asking this.
Offcourse: database server programmed in delphi available for delphi programs.
Nope, didn't know what you meant. I don't mind if the source code to my open source db is in another language... as long as it is a good product. Obviously you feel different.
2. No native remote debugger,
You can debug with gdb over SSH if your target platform is *nix, AFAIU... Haven't tried it though.
So not natively.. and if 'm correct: unix -> linux.
You can debug from your Windows (or Linux or OSX) IDE on a Linux, OSX, etc platform where the code rans. Don't know what you mean by "native" debugger; AFAIU from the wiki article, you can set breakpoints etc in your IDE just like you always do. (And the debugger that is used on the remote platform is the same one that is used by Lazarus locally on windows)
Yes. Glad it is. Hope that I can edit my post and add Lazarus for Android.
;)
Maybe offtopic for my initial remark but I tried to port all kinds of components, running into the differences with RTTI etc. Maybe I suggest one day that the main page of the Lazarus website could be better used to point to documentation sections and make the release announcements less important.
If you have specific suggestions, you can post them in the suggestions section. There's been some talk about reorganizing the pages, but nothing happened, AFAIR.
IMO, the wiki has improved tremendously in the last year - more organization, more cross-references, more articles. If you haven't lately, you may want to have another look.
-
Do you mean that Delphi provides native object FPC units that directly connect to db servers without any need for DLLs? Seems like those Delphi guys have been reinventing the wheel as well as inviting a maintenance nightmare... but it would be impressive.
Or do you mean that there is some database server programmed in Delphi available for Delphi programs?
I wonder if you point out my bad explaining or if you are asking this.
Offcourse: database server programmed in delphi available for delphi programs.
Nope, didn't know what you meant. I don't mind if the source code to my open source db is in another language... as long as it is a good product. Obviously you feel different.
No, I mostly agree with you. No fond of the DLL's involved to connect to that DB. I have learned that SQLite DLL's are quite version and OS dependant.
I would prefer native code because of portability. But for me that is different from the quality.
2. No native remote debugger,
You can debug with gdb over SSH if your target platform is *nix, AFAIU... Haven't tried it though.
So not natively.. and if 'm correct: unix -> linux.
You can debug from your Windows (or Linux or OSX) IDE on a Linux, OSX, etc platform where the code rans. Don't know what you mean by "native" debugger; AFAIU from the wiki article, you can set breakpoints etc in your IDE just like you always do. (And the debugger that is used on the remote platform is the same one that is used by Lazarus locally on windows)
Delphi's debugger is ofcourse written for Windows only. But yes it does provide flawless and zero configuration debugging what is running on another computer (ISAPI dll on IIS for example).
Yes. Glad it is. Hope that I can edit my post and add Lazarus for Android.
;)
Maybe offtopic for my initial remark but I tried to port all kinds of components, running into the differences with RTTI etc. Maybe I suggest one day that the main page of the Lazarus website could be better used to point to documentation sections and make the release announcements less important.
If you have specific suggestions, you can post them in the suggestions section. There's been some talk about reorganizing the pages, but nothing happened, AFAIR.
IMO, the wiki has improved tremendously in the last year - more organization, more cross-references, more articles. If you haven't lately, you may want to have another look.
I will. And I will start asking more questions on the forum. :)
-
Not to mention that most of the common dbms-es run on Windows, not on Linux.
I have no idea with your meaning of "common", since MySQL, PostgreSQL, SQLite(3), Firebird and many other run (and are even developed) on Linux.
3rd party support problem or not, fact remains that DevExpress and Jedi VCL only excist for Delphi. So do most of the reporting engines.
Yep, and still it's not Lazarus problem ;)
We have what we have, and the number is increasing, including commercial 3rd party support. It's just not yet at the same level as Delphi (don't ask us, as those 3rd parties).
I learned that it is very hard to port Delphi components to Lazarus if you don't have a very thorough knowledge of Lazarus (and lots of spare time).
It depends on how the components are coded. I've converted several well written Delphi components without too much trouble, despite the fact I've never truly used Delphi (and at that time, I haven't really known Lazarus, or LCL to be precise, internals). But I've also given up on those written with Windows in mind (and directly use Windows API = hell).
So not natively.. and if 'm correct: unix -> linux.
Nope: *nix = every OS that's based on *nix including Linux, Mac OS X, FreeBSD, etc.
Hmm, yes and no. I guess they want to encourage the use of more optimal ways. Case strings, and string comparison in general is extremely slow compared to indexing and all kinds of other ways.
But i guess it's ok if language supports it, and if it's used for small things. But there could be developers that take this into larger projects and hurt its performance.
The positive point of this feature is that we can get performance speed up without changing code when the implementation changes to use proper way. Current AnsiCompareText based implementation is indeed slow, but it should be possible to change to embedded prefix/suffix tree which should perform best both from development and execution point of view.
Won't keep me from using Lazarus. Delphi executables don't grow to 15 MB with only an empty form. But I could understand if the exe size is due to compiling everything installed in Lazarus.
Means you don't understand / haven't read the arcticle. Empty form withOUT debugging information, smartlinked and optimized should be around 1.5 MB, if you don't get that, then something is wrong with your options.
-
Won't keep me from using Lazarus. Delphi executables don't grow to 15 MB with only an empty form. But I could understand if the exe size is due to compiling everything installed in Lazarus.
Reading about optimizations on FPC and benchmarks compared to Delphi, I happened to find this topic. It seems to me that nobody took the time to explain well enough to teos, that Lazarus executables are not 15 MB. I do understand that this is the most FAQ, but as the concept of linking tons of debug info into the exe is completely alien to a Delphi user, it's a good idea to explain it well instead of pointing people to a page.
New project, select "Smart linkable", "Link smart" and "Use external gdb debug symbols file" results in about 1,7 MB exe size on 32 bit Windows, not 15 MB.
So every time you get a completely huge exe size, remember that it has tons of debug info in it, which can be removed with the right options.
-
It seems to me that nobody took the time to explain well enough to teos, that Lazarus executables are not 15 MB. I do understand that this is the most FAQ, but as the concept of linking tons of debug info into the exe is completely alien to a Delphi user, it's a good idea to explain it well instead of pointing people to a page.
But then you will have to answer the same question again and again, and that's what Frequently Asked Questions are for. Feel free to improve the article if you think it's not clear enough.
-
Exactly. It's even worse when you get endless discussions that are all covered in the FAQ and the "size matters" wiki article
Edit: (help in) providing a patch for bug http://bugs.freepascal.org/view.php?id=22743
Provide default and debug build modes by default
would also be very welcome ;)
-
Since I have been using Lazarus I have discovered a couple of little gems I could never do in Delphi:
(these don't work in Delphi mode)
Forget the small potato, go directly for the big stuff.
Inline generic methods ? Works with 2.7.1, not with Delphi XE..XE3.
-
But then you will have to answer the same question again and again, and that's what Frequently Asked Questions are for. Feel free to improve the article if you think it's not clear enough.
The FAQ us good. The challenge is to get people to read it. In this case the reader seems to have left the forum thinking that a one form Lazarus executable really is 15 MB and that we think it's normal. That's why I wanted to emphasize for any future readers, that Lazarus executables are in fact an order of magnitude smaller than that.
-
That is why the installer for 1.1 (snapshots, now displays the following info:
Some Info from our FAQ: http://wiki.lazarus.freepascal.org/Lazarus_Faq
What is Lazarus?
Lazarus is a cross-platform IDE for Pascal. Its aim is write once, compile anywhere.
How to reduce the exe file size?
The default binaries are very big because they include debug information. For release builds you can switch this off in the Project settings.
Licensing:
- The LCL is licensed LGPL with linking exception. This allows you to create apps with any license you want, including comercial.
- The IDE is licensed GPL. If you distribute a modified IDE you must follow the GPL.
- Other packages and components have various licenses. See the readme of each package.
-
Since I have been using Lazarus I have discovered a couple of little gems I could never do in Delphi:
(these don't work in Delphi mode)
Forget the small potato, go directly for the big stuff.
Inline generic methods ? Works with 2.7.1, not with Delphi XE..XE3.
I understand that, since the addition of advanced records, this means that most of codebase for practically everything needs to be changed from classes to advanced records, to take advantage of a fairly significant overhead/speed reduction in Delphi's case. And doesn't seem high on the priority list at Delphi from what I heard.
Is FPC/Lazarus ahead of the curve in this regard, I wonder? I would imagine. If so, then Lazarus should have an advantage here.
-
I understand that, since the addition of advanced records, this means that most of codebase for practically everything needs to be changed from classes to advanced records, to take advantage of a fairly significant overhead/speed reduction in Delphi's case.
I don't understand the connection. Could you elaborate? Classes to advanced records is rarely a solution for anything, since advanced records only support static methods. (and not virtual ones).
The only benefit +/- is that in generics you can mass instantiate records by arranging them in an array and grow themwith setlength (with only one call to the heap manager for all instead of one each), but that effect won't be that big for records with dynamic types (like strings) in them.
And doesn't seem high on the priority list at Delphi from what I heard.
Is FPC/Lazarus ahead of the curve in this regard, I wonder? I would imagine. If so, then Lazarus should have an advantage here.
I don't understand what the "curve" is supposed to be.
-
LCL (the first choise in create new project), empty form is 14,6 MB, delphi 2007 same new project, empty form is 407 kb.
First off, Delphi 2007 is super old, compare it to Delphi XE 2 or XE3 and the sizes are almost exactly the same.
Also in Lazarus when you are done debugging you need to go into Project Options under the Linker settings and uncheck the "Generate Debugging info" This dramatically reduces the exe size.
A empty form project compiled with no debug info is: 1.82 MB (1,915,392 bytes) Which i think is pretty reasonable in this day and age. (You can also enable the smart linking which drops the size a bit more)
Delphi Xe2 with debug: 7.06 MB (7,408,317 bytes)
Delphi Xe2 without debug: 1.52 MB (1,600,000 bytes)
(with Xe2 the difference is even smaller)
So do you think there is a huge difference now?
-
@Snorkel: if he doesn't understand about not including debug info etc now after all these posts, he's probably a zombie ;)
-
@Snorkel: if he doesn't understand about not including debug info etc now after all these posts, he's probably a zombie ;)
Ha ha ha maybe :-)
-
When teos was talking about client/server was he really referring to 3 tier like Midas?
Isn't all the standard SQL stuff included with Lazarus client/server already?
If you want 3 tier you can easily use Synapse to create the middle application server part.
As far as 3rd party is concerned if teos started using Lazarus and then let his 3rd party devs know that he is using it, they may be more likely to support Lazarus and FPC.
The more people that use Lazarus the more likely 3rd parties will port their stuff.
Some great 3rd party tools that work on Lazarus are PostgreSQL DAC and Securebridge from DevArt. The PostgreSQL offering from Devart is unique in it uses the wire protocol directly and does not require the libpq client access library at all.
So if you look closely and take the time to learn what the differences are Lazarus is a very very good alternative to Delphi. Sure you might have to work around a few things but it's very much worth it. I have access to Delphi Xe3 and I don't even use it because I actually prefer Lazarus, not to mention the community is much nicer here and there is no Team B....
-
I understand that, since the addition of advanced records, this means that most of codebase for practically everything needs to be changed from classes to advanced records, to take advantage of a fairly significant overhead/speed reduction in Delphi's case.
I don't understand the connection. Could you elaborate? Classes to advanced records is rarely a solution for anything, since advanced records only support static methods. (and not virtual ones).
The only benefit +/- is that in generics you can mass instantiate records by arranging them in an array and grow themwith setlength (with only one call to the heap manager for all instead of one each), but that effect won't be that big for records with dynamic types (like strings) in them.
And doesn't seem high on the priority list at Delphi from what I heard.
Is FPC/Lazarus ahead of the curve in this regard, I wonder? I would imagine. If so, then Lazarus should have an advantage here.
I don't understand what the "curve" is supposed to be.
My understanding is that an advanced record requires about half the resources of a class and there are many thousands of places where it could be implemented throughout the classes/components. I assume they meant internal classes, like TList, that are used often inside many classes/components. Not as stand alone class replacements, but where they make sense.
By "curve" I mean, being in on-going development, any new feature can be incorporated into any new development in Lazarus vs Delphi which isn't as likely to "tweak" the base code as readily, being a commercial operation.
I was more curious where Lazarus stands in this regard.
-
@Snorkel: if he doesn't understand about not including debug info etc now after all these posts, he's probably a zombie ;)
Hey, that is an unfair characterization of zombies!
Not cool!
You ought to know better, Big Chimp!
Hahahahaha
http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=QcONcCDhY4qO2M&tbnid=lPpVVkmCfIL1rM:&ved=0CAUQjRw&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFile%3ADuccio_di_Buoninsegna_-_Resurrection_of_Lazarus_-_WGA06781.jpg&ei=Adj-UPjhOZLs9ATe5YDwCg&bvm=bv.41248874,d.eWU&psig=AFQjCNHlZFp_n18KWQca0u3NkVMOraADUQ&ust=1358965122253561 (http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=QcONcCDhY4qO2M&tbnid=lPpVVkmCfIL1rM:&ved=0CAUQjRw&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFile%3ADuccio_di_Buoninsegna_-_Resurrection_of_Lazarus_-_WGA06781.jpg&ei=Adj-UPjhOZLs9ATe5YDwCg&bvm=bv.41248874,d.eWU&psig=AFQjCNHlZFp_n18KWQca0u3NkVMOraADUQ&ust=1358965122253561)
-
;) Nice image link ;)
-
If my understanding is correct, advanced records are basically striped down classes. No object model, constructor, exception handling, etc. etc. So you must provide the functionality from scratch, mainly a constructor. Many times you don't need full blown classes, for instance, in an collection or a drawgrid, for example. If a record is all you need for the "contained" object, you are greatly optimizing the speed and size of the collection/grid.
This touches the "exe size" complaints too. You know, the one where C is better at making smaller compiled executables, yada yada. Sure, you CAN make smaller apps possibly, but that is assuming that you are a AAA+ rated C programmer. You still have to know how to set up the project in the C++ IDE for "bare metal" programming, I would assume. Of coarse C is technically the winner. But put an ace Lazarus programmer, who knows how to program "bare metal" vs. your average C programmer, and check size then. There is you reality check.
Same applies with Lazarus. The default settings are well thought out and set up for the "typical user", not to prove that it can go "bare metal". What advanced records throws into the mix is this...the concept of "bare metal OOP", where you can now build in OOP in a ground-up manner, providing only the OOP elements you need. So now the onus is no longer on Lazarus/Fpc's abilities, it is now solely the programmers OOP abilities.
Concerning Lazarus's advantage over Delphi in this regard is that we can look forward to seeing great improvements, very low in the object model, that will improve performance in the whole "object tree". I imagine it is just getting a handle on some good "best practices" techniques is all. You can improve the LCL in Lazarus, not so with Delphi.
-
If my understanding is correct, advanced records are basically striped down classes.
Not really, since they lack the main characteristic of objects/classes: polymorphism aka inheritance.
No object model, constructor, exception handling, etc. etc. So you must provide the functionality from scratch, mainly a constructor
Many times you don't need full blown classes, for instance, in an collection or a drawgrid, for example.
If you were really that memory tight, you probably didn't use LCL and collections to begin with and handcoded everything procedural. It really is unlikely
in this day and age where you may expect even something embedded to have 128MB of ram. This is all DOS talk.
Moreover, even if for some reason you already had such a problem, you probably already used records there, since advanced records doesn't change anything
except writing
instance.methodname(arg1,arg2,arg3)
instead of
methodname(instance,arg1,arg2,arg3)
If a record is all you need for the "contained" object, you are greatly optimizing the speed and size of the collection/grid.
It can be yes. But only if you use say VST, and that didn't allow classes in the first place, since when a grid isn't specially optimized
for this kind of memory tight behaviour, it will do several allocations for every cell anyway, making your savings (if any!) useless.
This touches the "exe size" complaints too. You know, the one where C is better at making smaller compiled executables, yada yada. Sure, you CAN make smaller apps possibly, but that is assuming that you are a AAA+ rated C programmer. You still have to know how to set up the project in the C++ IDE for "bare metal" programming, I would assume. Of coarse C is technically the winner. But put an ace Lazarus programmer, who knows how to program "bare metal" vs. your average C programmer, and check size then. There is you reality check.
This is a totally different discussion. Memory footprint and exe footprint are not directly correlated.
Same applies with Lazarus. The default settings are well thought out and set up for the "typical user", not to prove that it can go "bare metal". What advanced records throws into the mix is this...the concept of "bare metal OOP",
1 There is no such thing as "bare metal OOP"
2 advanced records is not OOP, it misses fundamental OOP concepts, most notably polymorphism.
-
I Come back to the initial topic after all those comments/countercomments
Float/Double properties with a default value are possible in FPC. In the last Delphi I've used for the production of a soft. (d2007), this was not possible.
There was a message saying someting like 'default value can only be set for Ordinal properties...'
Now I don't know if it's been implemented since XE3...but when I've encountered that (so with d2007) I just told myself...that's stupid because a single , from the cpu point of view, is just like any other value: a wide-long-register value....so the default value for a single or a double could be casted from a fp literal to a 4 bytes integer (source code to parser) and in the program, the default single can be passed from a register to the FPU...You know what I mean ?
BTW, I've encountered a few monthes ago a special case where the default value of a FP property (http://stackoverflow.com/questions/12672215/forcing-the-default-value-of-a-real-to-be-written-in-writecomponent) would have helped...so this is a +1 for Fpc.
Anyway, just tell me if since d2007 this has been implemented in Delphi, in this case my answer wouldn't be valid.
-
The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.
And FPC can produce different results from different versions or different platforms. Well.. when Delphi has something irritating, it is at least consistent.
In FPC if i have a component with runtime event assignment, it's allready different when I compile the package or after that use the component in a project.
-
The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.
And FPC can produce different results from different versions or different platforms. Well.. when Delphi has something irritating, it is at least consistent.
In FPC if i have a component with runtime event assignment, it's allready different when I compile the package or after that use the component in a project.
first remark: This is true that packages in Laz are not dynamically linked, so you need to recompile everything...but this restriction can lead to better practices(such as not tesing each single change but rather puting assertions or protectors at the beg of a proc in DEBUG mode).
BTW It never tooks me 20 minutes to recompile Laz when developping a package, even if it's not as fast as in Delphi.
second remark: no comment...the RTL and LCL have some plateform-specific-limitations, your own source code should also have some compiler definitions depending on the target plateform...
third remark: I (really) don't understand what you mean. Maybe your Component is not well enough designed and an assignement made at the runtime clear the one made in the component (then in this case just make a system of 'multi-cast-event' with something like a list and a method such as AddEvent(), or review the component design: accessibility of your fields...)
-
@ The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.
I don't know what hardware you run.
On my 4 years old Core2Duo 2GHz it never takes 20 minutes. Even if you do "svn update" and "make clean all" it is much faster, less than 5 minutes. Adding or modifying package is even faster.
I just tested: rebuild whole IDE from Qt4 to GKT2 takes 85 seconds (another brake may be my 5400 rpm disk).
-
packages without taking 20 minutes
Building times like this are likely to a combination of smart-linking, and low memory.
Smart-linking requires a lot of memory, and if that is not avail then you get heavy swap file usage. And in this case linking can take forever.
On the other hand: The IDE itself (lazarus.exe) does not really benefit from smart-linking. Due to the designer's need to be able ta access all components, the IDE must include all code anyway. Smartlinking may at best save a few bytes.
I recommend to build the IDE without smart linking.
You can still build the LCL, and all packages as smart-linkable (-CX). So your own projects can be smart linked.
But do not use smart-link (-XX) in the IDE build options (or anywhere where it will apply to the IDE build)
-
The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.
I didn't even have such lazarus compile times back on my P-I.
If you want to spread negative sentiment, at least use facts. >:D
-
I didnt think Lazarus went back that far :)
wow P-1 with lazarus now that would be a sight to see haha
-
The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.
I didn't even have such lazarus compile times back on my P-I.
If you want to spread negative sentiment, at least use facts. >:D
I will. And I do. I have (or at least try to) deep respect for the Lazarus/Freepascal community and I am very well aware that negative sentiment will only harm myself and my creditability.
But I have to correct a few things: compile time is waaaay longer, but I have a virtual machine with Suse which has 1024 mb memory and what I build is the Codetyphon large IDE.
Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.
The "out of the box" Lazarus indeed compiles much faster. And yes, I can perfectly imagine that all the extra packages of the "bigIDE" of CodeTyphon are causing this.
And I know: these are "apples and pears".
For my other issue:
in the source i have something like:
button1.click := @dothebuttonclick;
in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.
-
Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.
The "out of the box" Lazarus indeed compiles much faster. And yes, I can perfectly imagine that all the extra packages of the "bigIDE" of CodeTyphon are causing this.
Indeed, I've tried CodeTyphon a couple of times and removing unneeded packages is the irritating part after installation (more packages, more memory, more time to build). So, I give up and instead to have Lazarus installed on a new machine I just generate from my current machine and copy because it already contains only components that I need. Really fast build, installing a package never takes more than 10 seconds (with static linking, smart linking takes about 1 minute).
in the source i have something like:
button1.click := @dothebuttonclick;
in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.
Probably a compiler mode mix (objfpc vs delphi), either in source or command line option.
-
If you want to spread negative sentiment, at least use facts. >:D
I will. And I do. I have (or at least try to) deep respect for the Lazarus/Freepascal community and I am very well aware that negative sentiment will only harm myself and my creditability.
There is no issue with describing a problem you experience. The question is the intend. It is all ok, if you are looking for a solution, or confirmation of it being a known (not yet solved) issue, or similar.
It is questionable, if you spread such negative issues with the intend to damage the project, or to rant, or similar. You would have the right to do so, but it would equally tell about your personality...
But I have to correct a few things: compile time is waaaay longer, but I have a virtual machine with Suse which has 1024 mb memory and what I build is the Codetyphon large IDE.
Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.
Did you check, if smart linking is causing this?
IIRC a default install requires between 700 and 800 MB for smart linking. So code typhon, with lots of extras may well need more.
But without smart linking, it should be much better.
For my other issue:
in the source i have something like:
button1.click := @dothebuttonclick;
in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.
Check the package options ("Compiler options", "parsing"). Make sure it uses the same syntax mode, that you use in your project. Also check for "{$Mode}" in the source.
-
Thanks for pointing me in that direction, something to investigate.
I have no intention to damage the project. I seem to have something in my health that lets me read my comments a lot more positive than others do...
But before this is gonna go completely off topic: it think the compiler directives can be an reason for one issue, and the load of packages in CodeTyphon, together with the low amount of memory could be reason for the other (and the "out of memory" issues).
Thanks for replying and the patience!
-
bitpacked record like c/c++
type
bit = 0..1;
BitsInaByte = bitpacked record
bit0 : bit;
bit1 : bit;
bit2 : bit;
bit3 : bit;
bit4 : bit;
bit5 : bit;
bit6 : bit;
bit7 : bit;
end;
Could you, ttomas, or someone else give a short sample code to explain the use of this.
I fail to see any practical use of it.
Curious and interested :-)
/Kamau
-
Could you, ttomas, or someone else give a short sample code to explain the use of this.
This is mostly useful for low level access (for example, if you access certain hardware or writing a kernel) or data exchange that requires exact bit structure. With this, you don't need to play with bitwise operators in your code.
-
Could you, ttomas, or someone else give a short sample code to explain the use of this.
This is mostly useful for low level access (for example, if you access certain hardware or writing a kernel) or data exchange that requires exact bit structure. With this, you don't need to play with bitwise operators in your code.
I understand it may be useful. Otherwise it would not exist....
And, can you give a very short example-code?
/Kamau
-
And, can you give a very short example-code?
Taken from virtual memory manager of my fpos kernel (not so very short):
const
PageDirVirtAddr = $FFBFF000;
PageTableVirtAddr = $FFC00000;
type
UBit3 = 0..(1 shl 3) - 1;
UBit20 = 0..(1 shl 20) - 1;
PPageTableEntry = ^TPageTableEntry;
TPageTableEntry = bitpacked record
Present, Writable, UserMode, WriteThrough,
NotCacheable, Accessed, Dirty, AttrIndex,
GlobalPage: Boolean;
Avail: UBit3;
FrameAddr: UBit20;
end;
PPageDirEntry = ^TPageDirEntry;
TPageDirEntry = bitpacked record
Present, Writable, UserMode, WriteThrough,
NotCacheable, Accessed, Reserved, PageSize,
GlobalPage: Boolean;
Avail: UBit3;
TableAddr: UBit20;
end;
PPageTable = ^TPageTable;
TPageTable = array [0..1023] of TPageTableEntry;
PPageDir = ^TPageDir;
TPageDir = array [0..1023] of TPageDirEntry;
...
var
PageDir: PPageDir = PPageDir(PageDirVirtAddr);
PageTables: PPageTable = PPageTable(PageTableVirtAddr);
...
procedure Map(const va, pa: LongWord;
const IsPresent, IsWritable, IsUserMode: Boolean);
var
VirtPage, ptIndex: LongWord;
begin
{$ifdef debug}
WriteStrLn('Map $' + HexStr(va, 8) + ' to $' + HexStr(pa, 8));
{$endif}
VirtPage := va div PageSize;
ptIndex := PageDirIndex(VirtPage);
// Find the appropriate page table for 'va'
if PageDir^[ptIndex].TableAddr shl 12 = 0 then begin
// The page table holding this page has not been created yet
with PageDir^[ptIndex] do begin
TableAddr := AllocPage shr 12;
Present := True;
Writable := True;
end;
FillByte(PageTables^[ptIndex * 1024], PageSize, 0);
end;
// Now that the page table definately exists, we can update the PTE
with PageTables^[VirtPage] do begin
FrameAddr := Align(pa, PageSize) shr 12;
Present := IsPresent;
Writable := IsWritable;
UserMode := IsUserMode;
end;
end;
-
Thanks!
I'll study it tomorrow.
/Kamau
-
Last year I convert some c headers for use of OpenLDV LonWorks protocol. Some code from C header
typedef union
{
struct {
Bits queue :4; /* Network interface message queue */
/* Use value of type 'NI_Queue' */
Bits q_cmd :4; /* Network interface command with queue */
/* Use value of type 'NI_QueueCmd' */
Bits length :8; /* Length of the buffer to follow */
} q; /* Queue option */
struct {
Byte cmd; /* Network interface command w/o queue */
/* Use value of type 'NI_NoQueueCmd' */
Byte length; /* Length of the buffer to follow */
} noq; /* No queue option */
} NI_Hdr;
typedef struct {
Bits tag :4; /* Message tag for implicit addressing */
/* Magic cookie for explicit addressing */
Bits auth :1; /* 1 => Authenticated */
Bits st :2; /* Service Type - see 'ServiceType' */
Bits msg_type :1; /* 0 => explicit message */
/* or unprocessed NV */
/*--------------------------------------------------------------------------*/
Bits response :1; /* 1 => Response, 0 => Other */
Bits pool :1; /* 0 => Outgoing */
Bits alt_path :1; /* 1 => Use path specified in 'path' */
/* 0 => Use default path */
Bits addr_mode :1; /* 1 => Explicit addressing, */
/* 0 => Implicit */
/* Outgoing buffers only */
Bits cmpl_code :2; /* Completion Code - see 'ComplType' */
Bits path :1; /* 1 => Use alternate path, */
/* 0 => Use primary path */
/* (if 'alt_path' is set) */
Bits priority :1; /* 1 => Priority message */
/*--------------------------------------------------------------------------*/
Byte length; /* Length of msg or NV to follow */
/* not including any explicit address */
/* field, includes code Byte or */
/* selector Bytes */
} ExpMsgHdr;
It was nightmare to convert to Delphi >:D
-
It was nightmare to convert to Delphi
Indeed it doesn't support bitpacking, but (byte) packing is possible, though you will have to play with bitwise operations to access fields' value.