Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 23/06/13 20:56, Florian Klämpfl wrote: So they support now native development on MacOS X as well? No, all development is still ONLY done under Windows. You cross compile to OS X and iOS. You also remote debug to OS X and iOS. I still think forcing a Windows licence for somebody that wants to develop for iOS only is bad. After all, Apple already forced you to purchase Apple hardware to develop for any of their platforms. But what I was getting at is that Embarcadero made cross compiling and remote debugging a no-brainer. Trying to do the same thing with FPC and Lazarus IDE is a huge pita! I'm not saying its impossible, it's just not nearly at the convenience level Delphi does it. right click on project and select 'Add target'; double click on new target to make it active; Ctrl+F9 to compile The problem are platforms like linux where linking is basically impossible without having the libraries of the target system available. I consider Linux and OS X similar - both *nix type OS'es. Delphi manages it, though I don't know the exact details of how they do it. I believe they get around the linking problem (and remote debugging) by using the PAServer, and using XCode command line tools for the final step in building a project. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 20/06/13 22:41, Michael Ring wrote: Doing crosscompiles and remotedebugging will add a level of complexity that will not justify the better performance of lazarus when using it on the 'real' linux box. It doesn't need to be! Having tested Delphi XE4 recently with iOS and MacOSX development. I was simply amazed at how easy it was to develop for an alternative platform, including remote debugging and deployment - it fact developing for the iOS target was just as simple as developing for the Win32 or Win64 or MacOSX targets. There is still a huge gap in FPC and Lazarus's usability when it comes to developing, debugging and deploying to alternative targets. I guess that is why Embarcadero can charge the big bucks. Maybe Dennis can try CodeTyphon [http://www.pilotlogic.com/sitejoom/]. They are the only people I know that are trying really hard to get FPC cross-compiling to the masses. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TTypeKind, strings and chars
On 2013-06-02 02:44, waldo kitty wrote: so maybe svn blame will tell when it was put in and by whom? commit 7aa20ac1cc61578db56a9de741f306f07a35460c Author: Florian Klaempfl flor...@freepascal.org Date: Sat Apr 16 14:01:44 2011 + * Merged helper branch made by Sven Barth -- Zusammenführen der Unterschiede zwischen Projektarchiv-URLs in ».«: U rtl/inc/objc1.inc Urtl/inc/system.inc Urtl/objpas/typinfo.pp Atests/test/tchlp30.pp ...snip... ie SVN commit r17328 Regards, G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Please double test my results of bug #7833
Hi, http://bugs.freepascal.org/view.php?id=7833 Could somebody double test my results in the above bug report (see my comments there). As far as I can see the report isn't a bug any more. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] state of units dbf*
On 2013-03-25 09:18, Sven Barth wrote: I don't know whether it's an approbiate alternative for this purpose, but: http://wiki.freepascal.org/ZMSQL Thanks for the link. tiOPF can also be used for storing data in CSV, TAB or XML, and you use it exactly like you do for a RDBMS. But the more important point is, that doing so causes a 3rd party dependency (tiOPF or ZMSQL). With DBF, it comes standard with FPC - I like that. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] state of units dbf*
On 2013-03-24 13:06, Michael Van Canneyt wrote: I am extremely surprised to see it marked 'deprecated'. Same here! I love using DBF for demos because I don't need any database server or 3rd party DLL/SO files etc. It is also one of very few database systems that can be fully compiled into a [small] FPC based executable with ease. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work. Netiquette? G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-05 13:02, Sven Barth wrote: Two words: backwards compatibility. To Turbo Pascal yes (ie: tp mode), but surely not ObjFPC? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 20:33, Howard Page-Clark wrote: You can simulate this in FPC as well as TP by using a local typed constant. e.g. function GetValue: integer; const value: integer = 0; begin Inc(value); Result:= value; end; I've seen this before, and always been baffled by this. How can you increment a constant? If you can, it is then a variable, no? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-05 09:12, Michael Van Canneyt wrote: You may think that Delphi is the best thing since sliced bread, but not everyone thinks so. There are several people on the list that do not like what Delphi is doing to the pascal language. +1000 I think Embarcadero is butchering the Object Pascal language. Stealing ideas (and worse, the syntax) from other languages verbatim. They don't put any thought in there language design like Borland did. For that reason, I love FPC and the objfpc mode. ALL my products are developer only in objfpc mode. The syntax is much cleaner and true to Pascal. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] STOP OVER QUOTING PLEASE
Hi, I find it extremely hard to follow conversations in this mailing list lately. Everybody seems to disregard simple netiquette guidelines here. For example: I can't read a message thread any more by just using my up/down arrow keys [jumping from one reply to the next]. I have to constantly scroll 50+ lines of quoted text [often 4-6 levels keep quotes], just to get to a 2-4 line reply! Please, please, please... trim your quotes to just the relevant lines. It takes but a second to do, so will not slow you down. I know I'm not the list moderator, but try and respect some basic netiquette, and make it easier for everybody to read messages here. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 10:31, Henry Vermaak wrote: Ah, I remember that fpmake can build with multiple threads, so perhaps this is a better solution than to do it with make. I'll investigate. I've got that option enabled by default for building FPC 2.7.1 and it does shave off a few seconds. I'm also trying to use fpmake for other hourly build server tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-05 15:24, Marcos Douglas wrote: Why follow the Delphi even knowing that is the wrong way to implement something? Because like the FPC team have said a million times to me because they follow Delphi blindly, and WILL do everything to stay delphi compatible. Good thing is, most of these are kept in the 'delphi' compiler mode. The 'objfpc' mode normally get some more pascal love. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 17:09, waldo kitty wrote: on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite. Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 01:47, Boian Mitov wrote: vast improvements of the code and the readability. They are unreadable to me. I recently started rewriting our libraries with anonymous methods and that alone allowed for cutting over 2 lines of code Just my dropping method names? I doubt that. ps: You do know that the Object Pascal language already supports things like method pointers, so passing methods to a procedure common - plus it has the benefit that the method is well named (so you know what it should be doing). Anonymous methods seem to be exactly what existing method pointers are, but with the downside that they are obscure (no names to hint to what they do), and defined in the wrong place in code. If you have never developed with them, (as was I), you never know what you have been missing. This is what I am trying to find out. So far, with everything I have read and seen. I can do the same thing in code, using method pointers and it will be more structured code (with names and defined in the correct location in my unit]. I simply don't see a need for anonymous methods. Maybe other languages have them, because they didn't have the method pointer construct to start with? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 03:59, Alexander Klenin wrote: Because computer science is advancing, and there is a limit after which programming language can not ignore those advancements and stay relevant. Sure, I understand that. I just haven't seen an example that explains why it is needed. Kind of why I am asking about this now. Method pointers, which already exist for a long time, seem to allow the same thing (passing methods to other functions etc), and they at least have the benefit that the method is named (hint to the developer what it does), and that it is defined and implemented in a more sane location in the unit. Was the anonymous method concept implemented in other languages, because they didn't have the method pointer concept that Object Pascal has? If so, does Object Pascal really need another method pointer type implementation? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 09:24, Marco van de Voort wrote: In Delphi, synchronization primitives like queue() and synchronize() have been adapted to work with them, so they are actually more used than some other new features. Sure, just like Delphi implemented Advanced Records, when the Object type already does the exact same thing! Was advanced records really needed, NO. Just because Embarcadero starting using there duplicated functionality, doesn't make it good, or better than what existed before. Here is an example Does the following make sense? http://docwiki.embarcadero.com/Libraries/XE3//en/System.IOUtils.TDirectory TDirectory = record ... class procedure Blablabla(...) end; HINT: Proof that Embarcadero lost the plot, when you read class procedure, but it is defined in a record, and not a class? Also, the TDirectory implementation could just as easily have been defined in a Class with class methods, and the actually usage would have been exactly the same [and made more sense]. Thus no need for the advanced record rubbish. It is a duplication of the functionality in a Class and Object type. Thus, isn't anonymous method just a bad and duplicate implementation of method pointers. Passing methods to functions etc.? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 04:54, Boian Mitov wrote: In this case, not only you save declaration, you save the need to write a whole new class just for the task. All my code live in classes already, so I would simply have benefited by having a properly defined method. Then pass the method pointer to the AExecutionTask.Add(..) call. Your example still doesn't convince me that anonymous methods were needed. In my OOP code, I wouldn't have saved any lines of code. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 01:16, Marcos Douglas wrote: I know. I just used the last mail on this thread -- in that case, your mail. Sorry. You should know better, and to never use any of my replies for something like that. I have no patience or sense of humour. ;-) Yes, I agree... but I feel a fight between Martin and FPC Team, don't you agree? No, and I don't desire it either. I feel the same... but we can not force people who work for free to do tasks that are not important to them. Correct. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 10:27, Michael Schnell wrote: It does make sense to allow for a kind of class that does not need to reside on the heap and, (residing on the stack or global space) And that is exactly what the Object type [already] does... and was introduced into the language in Turbo Pascal v5.5 (if I got the version right). http://www.freepascal.org/docs-html/ref/refse25.html#x61-680005.1 I still use the Object type to this day for performance or ease of use. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 11:17, Martin wrote: I added: - the name Bar - Used is at reference - the keyword closure The above code would then create the exact same closure, as your code does. And it does not need an anonymous method. +1 Much better solution, an in my opinion, much easier to read than anonymous methods. It looks more Pascal-like. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-04 13:05, Michael Van Canneyt wrote: And the first to use anonymous functions in FPC distributed code, I will personally make him eat his keyboard. Without pepper and salt. Thank you!! :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Thanks for taking the time with your detailed explanation. Regards, G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 12:44, Sven Barth wrote: that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the See, so Martin posting performance results after every FPC release does pay off. Without his post, your proposal would probably not have happened. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 15:53, Sven Barth wrote: Then I'll commit my changes :) Thanks for your efforts Sven. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-03 23:21, Marcos Douglas wrote: Sad. Instead of fight, why not walking together? I'm not joining any fight, simply wanted to know what the 'm' stood for. I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You said it yourself... most of us know nothing about compiler coding. So how are we supposed to propose improvements! All we can do is file bug reports on things we can duplicate, or highlight issues. This is what Martin is doing here. 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. But let me repeat what you said earlier. Some of use know nothing about compilers coding, so not much we can do about it. The task falls squarely on the select few, but they have no interest in that. Optimization is boring work, compared to implementing the latest CPU target or language feature. I understand that fully. A great pity. You are only showing the Delphi/Kylix speed is extremely superior And Martin is just showing half the problem. The Delphi Kylix compilers also produce executables that run 10+ times faster than what FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And don't even think of mentioning that faster hardware will mask the problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high performance RAM and 450MB read speed SSD. I noticed a 10+ times difference in running executables on my hardware. And comments from Florian like expect FPC to get even slower by the next release doesn't help much. Nobody expects FPC to beat Delphi or Kylix performance, but FPC degrading its speed (compile time and executable run time) year-on-year is not a good sign for the long run. Anyway, this is nothing new. I mentioned this long ago, and made my peace with it. I have to cherish the fact that FPC is luckily still faster that C/C++ compilers. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-02 19:03, vrt277 wrote: I want to implement support of Delphi anonymous methods for fpc. Just curious... why must such a feature be allowed in Object Pascal? Referring to the recent butchering of the Object Pascal language thread we had recently in fpc-pascal. It was clearly stated in the past that FPC will not support the C/C++ language feature of declaration a variable in-line inside code blocks, but only in var sections. Example of not allowed code: for i: integer = 0 to 10 do begin end; or var s: string; begin s := 'string' ... i: integer := 0; // I must be declared in var section instead Inc(i, 5); ... end; From what I can see, anonymous methods are just like the above code... allowing a declaration of a procedure/method in-line inside a code block where in shouldn't belong. It is very, very un-Pascal like. The end result is unreadable code, probably hard to debug etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-02 10:28, Michael Van Canneyt wrote: We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are x86 optimizations across various platforms shared?
On 2013-02-12 08:48, Mark Morgan Lloyd wrote: There's a vast number of factors that you're underreporting. For example, the underlying VM system could detect which OS is running as a guest, and behave differently. Or the OS could reconfigure the CPU and ... snip... That should normally point to the fact why VM's run slower than the host. Simulated hardware etc. But in my case, it is other way round. Linux is in the VM, yet runs faster than FreeBSD. The only way that you're going to get anywhere is by tweaking the programs to loop, so that you can factor startup time out. I seriously doubt it is startup time that accounts for the difference - especially in the case of non-persistent test, where a test might simply search a string for tokens, create a list object, add a few objects, then free the list object, making sure the children are freed too. Such tests all happen simply in memory and don't have any OS or other library API calls. Plus these exact tests run on both OS's, so if a test startup would be a factor, it would apply to both OS's. Looping the test suite is no problem, the testing framework already supports that. But I doubt timing will be much different. I will run a 10 iteration anyway, just to see. I'll try and investigate further, and see if I can create more benchmark tests. For now I have the following FPC questions... 1) Does the binary releases of FPC for Linux and FreeBSD use the same compiler settings when a release is created? 2) Does FPC optimize code per CPU and OS, or just per CPU architecture? I assume the latter, but would appreciate a confirmation from somebody that knows FPC internals. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Are x86 optimizations across various platforms shared?
Hi, I'm not sure how it works, but does FPC compiler optimizations for the amd64 (x86_64) CPU's get shared across various OSes? eg: I've read various reviews that FreeBSD benchmarks often perform better than the same benchmarks run on Linux. It was even shown that FreeBSD runs Linux executable faster than Linux can. I can quote the websites if really need. So while setting up my automated unit tests for tiOPF across my various systems I compared the test results and timings. NOTE: My host OS is FreeBSD 9.1 (64-bit) using a Intel i7-3770K @ 3.5Ghz with 16GB RAM. FreeBSD boot OS is on a 128GB OCZ Vertex 4 SSD. The rest of the system runs off a 3x 2TB ZFS in RAID-z1 setup (similar to RAID5). All other OS's run in VirtualBox VM sessions. I have a single Firebird 2.5 DB server running natively under FreeBSD. All file access tests run on each OS's native file system. The Linux VM session I have is Ubuntu 10.04.4 (64-bit). Both OS's run FPC 2.6.0 and the exact same revision of tiOPF, FPTest and fpGUI. fpGUI is used for the GUI test runner of FPTest. Here is the summary of the unit test results, and the times it took in minutes and seconds. No of tests | Type of Tests | Linux | FreeBSD -+-++ 151| CSV persistence |0:22|0:27 -+-++ 151| TAB persistence |0:22|0:27 -+-++ 151|XMLLight |0:23|0:26 -+-++ 151| SqlDB-Firebird |3:14|3:38 -+-++ 682| Non-Persistent |1:09|1:30 -+-++ As you can see, consistently the FreeBSD tests take longer than the Linux ones. The test project on each platform was compiled with exactly the same compiler settings. Also the Non-Persistent tests is 99% in-memory tests (no disk access). So this eliminates the idea that the file systems might cause the speed difference, though the SqlDB tests used the same DB server, and there was still a large difference in speed. So this got me wondering. Does FPC compiler optimizations differ between FreeBSD and Linux, even for the same CPU type? If so, then the results is probably understandable, because there are more Linux developers and testers in the Free Pascal project, than for FreeBSD. Thus more working going into Linux optimization than for FreeBSD. If my assumption about FPC optimization is incorrect, then I'm lost for ideas why my FreeBSD setup is so much slower than a Linux VM session (and contrary to other benchmarks on the net). [sorry for the long winded email] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are x86 optimizations across various platforms shared?
On 2013-02-11 19:03, Mark Morgan Lloyd wrote: No of tests | Type of Tests | Linux | FreeBSD -+-++ 151| CSV persistence |0:22|0:27 -+-++ 151| TAB persistence |0:22|0:27 -+-++ 151|XMLLight |0:23|0:26 -+-++ 151| SqlDB-Firebird |3:14|3:38 -+-++ 682| Non-Persistent |1:09|1:30 -+-++ As you can see, consistently the FreeBSD tests take longer than the Linux ones. The test project on each platform was compiled with exactly the same compiler settings. What exactly are we looking at there: 151 iterations inside a single program, or 151 programs? The unit testing project is a single executable running all the above tests. 151 is 151 different unit tests to test the various persistence layers. The test suite is based on a hierarchy of classes, that is why all persistence tests have 151. The exact same persistence tests are run for each persistence layer. The 682 is again different tests for anything non persisting - testing various classes, and pretty much all functionality of those classes. I did not setup the testing framework to run multiple iterations, only one run was completed with a total of around 1200+ unit tests taking around 4:30-5:00 to complete, from start to finish. So memory cache etc should really have an effect. Because each test case starts from scratch, does the test, then cleans up. Then the next test etc etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are x86 optimizations across various platforms shared?
On 2013-02-11 19:11, Sven Barth wrote: I would say the No of tests is the number of different test functions that have been invoked (all within one single test program). Correct. The first four sets are the same persistence tests, but against different persistence backends (CSV, TAB, various client/server DBs). The last set is for anything in tiOPF that is not related to persistence (storage). The last set includes base classes, visitor, iterators, parsers, encryption, object/list management, mediators etc. - the core functionality of the tiOPF framework. I only selected some of the persistence layers for this message thread. tiOPF supports many more like SqlDB-Postgress, SqlDB-MySQL, Zeos-Firebird, Zeos-MySQL, etc.. pushing the total unit test count over 2000+ But the ones I showed above gives a clear indication of what I am after Why is native FreeBSD slower than Linux (in a VM)? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are x86 optimizations across various platforms shared?
On 2013-02-11 18:24, Sven Barth wrote: AFAIK the optimizations are CPU specific, not OS specific. That is what I expected too. guessing here) that the FreeBSD release was created with different optimizer settings than the Linux one (regarding the RTL and packages). Both FPC 2.6.0 installs were from the binary releases made by the FPC team. I never install FPC from FreeBSD ports of Linux repositories. Otherwise I'm as puzzled as you... :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 2013-02-06 20:10, Sven Barth wrote: We don't have semaphores yet in SyncObjs. Correct. FPC's SyncObjs unit has quite a few missing features compared to Delphi. http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 2013-02-06 20:17, Sven Barth wrote: If you just define your own semaphore class that contains the platform specific types and lock and unlock methods then you only need to add an additional array[0..4] of Longint after the sem_t field for FreeBSD. Then you should be okay. Yes that will work, but it simply moves the problems or IFDEF's to a different location. You need to use at least synchronisation primitives like mutexes otherwise it won't be threadsafe. Yes, that is what I am planning. The class I am working with is a Thread Pool, so thread safety is a given. ;-) At least I don't need cross-process semaphore support, only multiple threads in the same process. So this makes things a lot easier. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 2013-02-07 09:13, Sven Barth wrote: But the ifdefs will only be in one location. I understand that, but there will be IFDEF's none the less. As I said, I hate IFDEF's in application/library code. They have their place in FPC source code, but I don't like them anywhere else. That's just me. This way you'd reduce that to one and rely on OS functionality nevertheless (which is known to work - if used correctly :P ). Having a clean Object Pascal based Semaphore implementation will be useful, and clean code. My unit testing and usage of it in tiOPF on Windows, Linux and FreeBSD will hopefully prove that it works too. Once done, I'll post a link to the code. You are welcome to see if it will fit in the SyncObjs unit. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Hi Jonas, Interesting, there is no mention of those limitations in the FPC 2.6.0 documentation. I looked in the RTL docs. It this is a concern, it is something that should be mentioned in the docs. Do you know more specifically what platforms or CPU's are affected, so Michael could update the docs accordingly. Does this limitation apply to all InterlockedXXX() functions? Regards, - Graeme - On 2013-02-07 10:57, Jonas Maebe wrote: === Code Begin === Procedure WaitLockVar(var aLock: Integer); Begin Repeat Until InterLockedCompareExchange(aLock, 1, 0) = 0; End; Procedure UnlockVar(var aLock: Integer); Begin InterlockedExchange(aLock, 0); End; === Code End === This last code is tested and works. It only works on some platforms (and even there it may change depending on which exact processor you are using). InterlockedExchange does not guarantee any kind of memory barrier, and hence you will get occasional data races on platforms with weakly consistent memory models. You have to add memory barriers. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 2013-02-07 17:55, Flávio Etrusco wrote: Not if you want high performance and multi-processor support. I'll prefer _working_ code to start. Currently semaphores are broken in FPC+FreeBSD. My implementation at least works everywhere I have tested - without hacks or jumping through loops. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Hi, OK, now that we established that semaphores are broken in FreeBSD using FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative. An alternative for two reasons. - I hate IFDEF code, and the semaphore code between Linux, FreeBSD and Windows are different. - Semaphore sem_t structure is incorrectly defined for FreeBSD, so I'll have to implement a special case for that platform. Semaphore functionality seems pretty simple though, so I am thinking of creating my own Object Pascal based cross-platform semaphore - no low level code or OS specific library API's. It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Why FreeBSD sem_init() works different to Linux?
Hi, I found another problem with Semaphores between FreeBSD and Linux. Attached is my test project. Again, it is similar code used in tiOPF. For some reason under FreeBSD, it *always* zeros the variable that holds the Max Pool Size value passed in to sem_init()'s third parameter. This means that if I try and us that variable anywhere after the sem_init() call, like when I want to destroy the semaphore, I can't because the variable now holds the value 0. Here is an example of the test program's output. Not the value of FMaxPoolSize before and after sem_init() call. Also note the value of i - no destruction code (sem_post) is executed. -[ output under Linux ]--- $ ./project1 FMaxPoolSize before = 2 FMaxPoolSize after = 0 c = 2 Now create a lock c = 1 Now create a lock c = 0 i = 0 --- And here is that exact same test project under Linux. Note the FMaxPoolSize variable still has the original value after the sem_init() call - as expected. Also the i variable increments as we unlock the semaphore. -[ output under Linux ]--- $ ./project1 FMaxPoolSize before = 2 FMaxPoolSize after = 2 c = 2 Now create a lock c = 1 Now create a lock c = 0 i = 0 unlock a semaphore i = 1 unlock a semaphore i = 2 --- Any idea why FreeBSD does this? A bug in FPC+FreeBSD? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ semp_test.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 2013-02-04 12:22, Sven Barth wrote: I have an idea. But for this I'd need some confirmation: Can you please put in your example program the FSemaphore into a record and add also a ... OK, attached is the new test project. Below is the output. Now the FMaxPoolSize variable still has the correct value before and after sem_init(), and I could successfully unlock the semaphores. But as you can see, the array values have changed. [ freebsd output ]-- $ ./project1 FMaxPoolSize before = 2 FValues[0] = $123456 FValues[1] = $654321 FMaxPoolSize after = 2 FValues[0] = $02 FValues[1] = $00 c = 2 Now create a lock c = 1 Now create a lock c = 0 i = 0 unlock a semaphore i = 1 unlock a semaphore i = 2 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ semp_test2.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD
Hi,
I initially posted this in the fpc-pascal list, but I think fpc-devel is
maybe more appropriate, because the pthreads include files might need
amendment.
I'm trying to get tiOPF to compile under FreeBSD. It works under Linux
and Windows without problems.
I got compiler errors using FPC 2.6.0 under FreeBSD, saying that the
compiler couldn't decide which version of the sem_* methods to use.
I had code like this in tiOPF:
{$IFDEF MSWINDOWS}
FSemaphore: THandle;
{$ENDIF MSWINDOWS}
{$IFDEF UNIX}
FSemaphore: TSemaphore;
{$ENDIF UNIX}
...
procedure TtiPool.CreatePoolSemaphore;
begin
{$IFDEF MSWINDOWS}
if FSemaphore 0 then
CloseHandle(FSemaphore);
FSemaphore := CreateSemaphore(nil, FMaxPoolSize, FMaxPoolSize, nil);
{$ENDIF MSWINDOWS}
{$IFDEF UNIX}
FillChar(FSemaphore, sizeof(FSemaphore), 0);
// pShared = 0 means, shared between the threads of a process
writeln('FMaxPoolSize = ', FMaxPoolSize);
if sem_init(@FSemaphore, 0, FMaxPoolSize) 0 then
raise EtiOPFInternalException.Create('Failed to initialize the
semaphore');
{$ENDIF UNIX}
end;
Note the sem_init() call takes a pointer.
As you can see from the quoted code below, FreeBSD has two versions of
the sem_* methods. The compiler couldn't decide which version to use:
Error: Can't determine which overloaded function to call
To get it to compiler under FreeBSD, I must change the sem_init() line
too the following...
if sem_init(FSemaphore, 0, FMaxPoolSize) 0 then
...but this breaks compiling under Linux again.
1) How do I get the tiOPF code to work under both Linux and FreeBSD
using a single {$IFDEF UNIX}. I don't really want to introduce {$IFDEF
LINUX} and {$IFDEF FREEBSD} in the code.
2) Why does FreeBSD have two versions of these methods and Linux only
one? I had a look at the other pthr*.inc units. Linux and SunOS has a
single version, BSD (which I believe is MacOSX too) and Haiku has two
versions.
[ pthrbsd.inc freebsd ]---
function sem_init(__sem:Psem_t;
__pshared:cint;__value:dword):cint;cdecl; external;
function sem_destroy(__sem:Psem_t):cint;cdecl;external ;
function sem_close(__sem:Psem_t):cint;cdecl;external ;
function sem_unlink(__name:Pchar):cint;cdecl;external ;
function sem_wait(__sem:Psem_t):cint;cdecl;external ;
function sem_trywait(__sem:Psem_t):cint;cdecl;external ;
function sem_post(__sem:Psem_t):cint;cdecl;external ;
function sem_getvalue(__sem:Psem_t; __sval:Pcint):cint;cdecl;external;
function sem_init(var __sem: sem_t; __pshared:cint;
__value:dword):cint cdecl;external;
function sem_destroy(var __sem: sem_t):cint;cdecl;external;
function sem_close(var __sem: sem_t):cint;cdecl;external;
function sem_wait(var __sem: sem_t):cint;cdecl;external;
function sem_trywait(var __sem: sem_t):cint;cdecl;external;
function sem_post(var __sem: sem_t):cint;cdecl;external;
function sem_getvalue(var __sem: sem_t; var
__sval:cint):cint;cdecl;external;
[ end ]--
---[ pthrlinux.inc linux ]-
function sem_init(__sem:Psem_t; __pshared:cint;
__value:dword):cint;cdecl;external libthreads;
function sem_destroy(__sem:Psem_t):cint;cdecl;external libthreads;
function sem_close(__sem:Psem_t):cint;cdecl;external libthreads;
function sem_unlink(__name:Pchar):cint;cdecl;external libthreads;
function sem_wait(__sem:Psem_t):cint;cdecl;external libthreads;
function sem_trywait(__sem:Psem_t):cint;cdecl;external libthreads;
function sem_post(__sem:Psem_t):cint;cdecl;external libthreads;
function sem_getvalue(__sem:Psem_t; __sval:pcint):cint;cdecl;external
libthreads;
function sem_timedwait(__sem: Psem_t; __abstime:
Ptimespec):cint;cdecl; external libthreads;
---[ end ]---
Attached is a small test project using snippets of code that tiOPF uses.
The current version of this test project will compiler under FreeBSD,
but will not compiler under Linux.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
semp_test.tar.gz
Description: GNU Zip compressed data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD
On 2013-02-03 12:28, Sven Barth wrote: I personally think that the fpc-pascal list was the more approbiate, but nevertheless: your problem comes down to this code (in principal): I thinking was that this problem seems to point towards a bug, or at least inconsistency between defined types and various platforms. But as you say, nevertheless. Thanks for replying. type sem_t_rec = record end; // from rtl/freebsd/ptypes.inc sem_t = ^sem_t_rec; // from rtl/freebsd/ptypes.inc psem_t = ^sem_t; // from packages/pthreads/src/pthrbsd.inc Indeed, the sem_t is differently defined between Linux and FreeBSD. Under Linux, sem_t is just a record defined as: // rtl/linux/ptypes.inc sem_t = record __sem_lock: _pthread_fastlock; __sem_value: cint; __sem_waiting: pointer; end; In FreeBSD sem_t is pointer. Isn't that what psem_t is for? So under FreeBSD sem_t should be defined as sem_t_rec = record end; sem_t = sem_t_rec; psem_t = ^sem_t; I would expect unix-types / posix-types supposed to be defined the same in all such related OSes (eg: *BSD, Linux, MacOSX, Haiku, *nix)? Now the problem is the @s. This returns type Pointer and now you have two pointer types: sem_t and psem_t. Thus the compiler can not resolve this. Indeed. You just seem to have explained it better than I. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD
On 2013-02-03 18:08, Marco van de Voort wrote:
The resulting overloading can cause problems. It can be reduced by
deprecating the original pascallized versions, and removing them in some
future version.
So at this current point in time, my only solution is to have code as
follows in tiOPF:
procedure TtiPool.CreatePoolSemaphore;
...
begin
{$ifdef windows}
...
{$endif}
{$ifdef unix}
{$ifdef linux}
...
{$endif}
{$ifdef freebsd}
...
{$endif}
{$ifdef macosx} // I plan to test under MacOSX soon
...
{$endif}
{$endif}
end;
And everywhere else in the TtiPool class where sem_* methods are used.
This is just yuck!!! I hate IFDEF's. :-/
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD
On 2013-02-03 18:10, Sven Barth wrote:
I personally still think there is a bug, because the compiler should (in
my opinion) not consider sem_init(@sem) a valid usage of sem_init(var
sem: sem_t)...
+1
I you look at the POSIX definition at
http://pubs.opengroup.org/onlinepubs/007904975/basedefs/semaphore.h.html
you'll see that they don't specify any specific fields so sem_t should
After reading Marco's reply I now understand. I didn't know this before.
Did at least the solution help you? AFAIK it should work for FreeBSD as
well as Linux (and maybe the other *nix systems...)
[After my reply to Marco, I tried your solution]
Yes, that did work - thanks. I have never seen those {$} you
mentioned, but will read the FPC docs now to find out more.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD
On 2013-02-03 18:29, Sven Barth wrote: Why? The variant with the TYPEDADDRESS should work for the other *nix targets as well... Sorry, I replied to Marco before I tried your solution. Your solution works. Thanks. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fixes 2.6.1 fails to install under Win32
On 01/30/13 02:22, Michalis Kamburelis wrote: Do not use a final backslash, like make install INSTALL_PREFIX=c:\fpc\2.6.1 Ah, that did the trick. Thank you for your help. Side Note: That also highlights how fragile the build system is, but that is another issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fixes 2.6.1 fails to install under Win32
Hi, I'm using a Win2000, and have a released FPC 2.6.0 installed. I updated my FPC 2.6.1 to r23533 (latest revision to date). I run by usual build.bat script (shown below). FPC, RTL and FCL seems to compile fine, but the 'make install ...' seems to fail. I've never had such issues before. It seems like the Makefile is broken, if you look at the odd directory it tried to create. Anybody else experiencing this, or have a solution? 8-8-8-8-8 make distclean make all FPC=c:\FPC\2.6.0\bin\i386-win32\ppc386.exe make install INSTALL_PREFIX=c:\fpc\2.6.1\ FPC=c:\FPC\2.6.0\bin\i386-win32\ppc386.exe ...snip... 6.exe --prefix=c:\fpc\2.6.1\ --unitinstalldir=c:\fpc\2.6.1\/units/i386-win32/fcl -web Installing package fcl-web The installer encountered the following error: Failed to create directory C:\fpc\2.6.1 --unitinstalldir=c:\fpc\2.6.1\\units\i3 86-win32\fcl-web\units\i386-win32\fcl-web\ make[4]: *** [install] Error 1 make[4]: Leaving directory `C:/FPC/2.6.1/src/packages/fcl-web' make[3]: *** [fcl-web_distinstall] Error 2 make[3]: Leaving directory `C:/FPC/2.6.1/src/packages' make[2]: *** [packages_distinstall] Error 2 make[2]: Leaving directory `C:/FPC/2.6.1/src' make[1]: *** [installother] Error 2 make[1]: Leaving directory `C:/FPC/2.6.1/src' make: *** [install] Error 2 8-8-8-8-8 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freebsd 9.1 -liconv not found
On 01/27/13 15:35, Leonardo M. Ramé wrote: Pass -Fl/usr/local/lib in OPT= Thanks Marco, that did the trick!. I had a similar problem for X11 apps recently. I simply modified my ~/.fpc.cfg file and specified -Fl/usr/local/lib inside there. Solved my problem without too much fuss, and no need to modify compiler parameters per project. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FreeBSD ports maintainer for FPC?
Hi, Who is the FreeBSD ports maintainer for FPC? There are some grammar errors in the pkg-message.in (final instructions after a make) file. I thought I would notify the ports maintainer of that. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freebsd 9.1 -liconv not found
On 01/28/13 11:45, Marco van de Voort wrote: The TAR installer and afaik the port should add this line to the config already, I installed the stable FPC from the TAR installer, then installed the fixes version from the repository. All done as a normal user, not root. But building fpc ignores (.)fpc.cfg, so it is not a solution anyway for the reported problem. Thanks for correcting me, my mistake. Re-reading the original post, I see he mentions compiling FPC itself. My message referred to compiling my applications. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreeBSD ports maintainer for FPC?
On 01/28/13 11:49, Marco van de Voort wrote: There is a MAINTAINER field in every ports makefile? acm@ Ah got it, thanks Marco. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 08:07, Michael Van Canneyt wrote: If he wants to help, Alexander Klenin had better put his students to useful tasks. There are plenty to choose from. He said maybe he'd look after fcl-stl. The silence since was deafening. He said he needed a arbitrary precision math library: Well, get started ! Both should be perfectly within grasp of a student. If he has students, let them work on that. +1 To add to that list... a native Free Pascal Debugger. I'm already working on this in my [very limited] spare time. Progress is slow, but progress is being made. The debugger is based on reading the DWARF debug information that FPC generates. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 17:17, Alexander Klenin wrote: Using indicies is against all principles of iterators. I am not sure what princilpes you are talking about, The theory. Read any Design Patterns book or technical papers. but accessing the key of the current element is required quite often On the contrary. You should be interested in the current element, not the index value it represents. ALL my iterators in all my application code don't use or need the index value. I simply ask for the Next or Previous object or value. This also hides the implementation details of the container object, thus the container can change its internal implementation, and my Iterator code in my applications will still continue to function without change. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/28/13 13:20, Michael Van Canneyt wrote: tatata, you should always understand everything :) :-) Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. Yup. I have also seen sample Delphi code where they used Generics. It was on the Code of Horror website if I remember correctly. It was ridiculously complex, unreadable, and probably a nightmare to debug. I regard simplicity and readability very high in my code. It makes working in a team so much easier too. That is what the Pascal language was all about. I use avanced record syntax because it makes code more understandable. It offers nothing that objects didn't already have. Yeah, what was that all about... advanced records. They are nothing more than the Objects introduced in Turbo Pascal days - and then Embarcadero has the audacity to call it a new language feature. LOL. BTW: I still find it useful using Objects instead of Classes in some places in my code. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 00:11, Alexander Klenin wrote: Do I understand correctly that you are speaking about this article: http://opensoft.homeip.net/articles/iterator_pattern.pdf ? Yes. As far as I understand, since iterators described in the article do not have the concept of a current item, The current item is returned when you call Next or Previous on the iterator. You use HasNext and HasPrevious in the loop. As the article describes, my Iterator implementation is based on the Java-style where the pointer in the list sits between items - there is a graph of that in the article too. they also do not have concept of an index, and hence are not relevant in the context of this discussion. No need for an index value because Next and Previous returns what you need. Also the one Iterator I implemented can take a regular expression (regex), thus you can iterator a list but filtered results are returned. The article shows this somewhere near the end. So the traditional index value doesn't or can't apply, because it can skip many or all items in the list. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 10:22, Michael Schnell wrote: and replacing the term myString[n] by a straight forward function searching for the n'th printable character will be very slow. And I am yet to see a real-world example where this is needed. ALL examples I have seen, the developer was already busy iterating the UTF-8 string, so index access wasn't needed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 10:40, Michael Schnell wrote: The real world in fact does not need computers. Huh? G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/25/13 10:51, Michael Schnell wrote: A decent smart indexer class with appropriate enumerator/iterator-like compiler-magic syntax might help until then and is a lot nicer than the old-fashioned myString[i] notation anyway, on top of being compatible with any future string implementations. I think you got programming confused with a magic wand. ;-) G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/24/13 19:36, Alexander Klenin wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? Enumerators are limited in functionality. Iterators are the full-blown thing. Common Iterator API is something like Next, Prev, Reset, HasNext, HasPrev etc. Enumerators normally just advance and only in one direction. This is how it is in many frameworks. Even Java's documentation describes it like that - see the bottom of the page for Iterator. http://docs.oracle.com/javase/6/docs/technotes/guides/collections/reference.html Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On 01/24/13 23:26, Alexander Klenin wrote: If you want full fledged iterators, use classes. Please provide example of your suggestion for the case in the wiki. I don't need to provide *anything*. Of course you do not, this is why I said please :) However, it is impossible to have a meaningful discussion without such an example, so could you please indulge me? Do you want examples of Iterator classes? If so, I have a such implementations I have used for years, and can iterate just about any collection object without issue. Getting such an Iterator instance is as single line of code. If that is what you are talking about, I can email you a copy. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
On 01/07/13 11:02, Michael Schnell wrote: Lets see what Embarcadero comes up with I wouldn't hold my breath. Based on recent Embarcadero history, the first version would be absolute crap, second version might be beta quality, 3rd version might not even exist (removed from product). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AMD Intel CPUCount
On 27/12/12 22:06, Ewald wrote: and an Intel i7, and works correctly. If someone would be so kind to test it on some other CPU's that would be great! It gives correct result (8 cores) on my Intel i7-3770K CPU with HyperThreading enabled in the BIOS. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
On 24/12/12 11:22, Martin wrote: half-width spaces etc..., control chars (RTL/LTR...), currently unused codepoints (that could become anything in future...) As Marco said, the list will be smaller than the allowed list. Also the Unicode specification defines blocks or categories for code points, so that could be used too. eg: Take a look at TCharacter.IsNumeric(..) implementation. It doesn't do actual code point comparisons, it simply checks the Unicode category of the passed in code point. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23/12/12 10:13, Michael Van Canneyt wrote: ? No, the old RTL will remain maintained. It's the same codebase, just recompiled. It was impossible to deduce that from your earlier reply http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27659.html With the new information at hand, it seems a lot more manageable than I first envisioned. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 22/12/12 10:34, Martin Schreiber wrote: Please note that the message has not been posted to the list by me. My apologies Martin. I should have taken your questions and rephrased them in a list form. To save time, I simply obfuscated the names - probably not the best idea. The names where not the important bit anyway - the listed items and their status in the FPC project was. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 21/12/12 16:46, Mark Morgan Lloyd wrote: Cutting out a whole lot of crap: as somebody very much on the periphery of the project, I'm disappointed to see sentiments of this tenor being aired in public. Mark, much of what happens with the FPC project seems to be done in secrecy, or a private core only mailing list. So it takes message threads like this to actually find out (for the rest of us) what is going on. It's an open-source project (not commercial), so I would have thought open discussions should be a given. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 21/12/12 17:16, Florian Klämpfl wrote: The mission goal of FPC is: develop an open source pascal compiler written in pascal in a community effort. You forgot the last bit and be Delphi compatible! Maybe people should indeed first work on the compiler instead of developing another gui and ide. A compiler on its own is a pretty useless item. It needs advanced GUI frameworks, IDE's and other large apps to fully test the compiler and drive its features. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 22/12/12 16:43, Marco van de Voort wrote: I think you have a wrong idea on what the core list contains. LOL. And how is anybody supposed to know what goes on - it is a PRIVATE mailing list. I don't think direction on unicode (or even general) came up since the last unicode discussions on fpc-devel/pascal. OK, so once again it is proven that Unicode is just not sexy enough for the core team, so it will stay stagnant for a few more years. That's unless a member ignores all discussions and does his own thing [or gets paid for the job]. As Florian likes to says so often, whoever implements it decides. Unfortunately that courtesy is not extended to non-members, because what good is a patch [of such magnitude and effort] with no chance of ever being committed. So we are at the mercy of the FPC gods. Many of use non-core developers have given our input with multiple solutions, to try and help the private discussions along. But I guess all of us are not knowledgeable enough people. What a nice F*** Y** to the community. Well, let me just say that the idea of two RTL's is rather ridiculous too!! You guys keep bitching about not having enough developers, so how on earth do you think you are going to be able to maintain developing two RTL's, patching too RTL's when bugs are reported, inform the public to remember to mention which RTL they are using when reporting bugs, keeps those two RTL's in sync over time etc. Yeah, it seams you guys are sometimes not to knowledgeable either. All you are going to do is create more work for yourselves. But hey, who are we to state the obvious. Anyway, I can see where this thread is heading... just another waist of time. So I'll stop here. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 21/12/12 10:15, Michael Van Canneyt wrote: It would be good to keep those facts in mind before ranting. I was simply bringing some of those questions (which I had too) to light. Unicode has been under development for many years, and has come to a halt - with no final decisions being made. This is very frustrating for those using FPC. And even if we wanted to contribute in that regard, how could we, if the FPC team itself doesn't know what it wants. I would also like to point out that I am well aware that FPC is a part time project for you guys. I never demanded anything with my original post, simply asking what the progress was. In the same breath, you guys work on FPC - that's your hobby project. Others work on Lazarus, MSEide, fpGUI, tiOPF, FPTest, FP Debugger, OnGuard, etc etc. So comments like Florian's - suggesting that if you want a feature, implement it your self is often not an option. I'm skilled in certain programming, definitely not compiler design. So it seems quite logical to leave such compiler work to those that know how to do it, or that are already familiar with the code base. I do contribute to the FPC project where I can, eg like in the fpdoc tool, documentation updates etc. This might mean jack-shit to somebody like Florian, but we are not all compiler designers, and I'm already swamped with other open-source projects I work on. Anyway, good to hear that Unicode progress might actually happen. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 21/12/12 12:26, Michael Van Canneyt wrote: We know what to do. What we lack, is time. Status currently: Thanks for the update. Most of what you mentioned was unknown to any person outside the FPC core team. So to us outsiders, it seems like progress has halted. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 18/12/12 12:19, Michael Schnell wrote: IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus, as adding a source package and recompiling does the trick just as well. Tell that to component developers and companies like Devx, TMS etc! With the current way things work, there is 0% chance of getting a trial version of any component. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 18/12/12 13:26, Marco van de Voort wrote: They could deliver ppu's and .o's. True, but widely untested. As a previous conversation from a few month back ended... it should work in theory. Also Lazarus Packages are designed to work with source only. There is no option to install .ppu's and .o's in Lazarus IDE. But this is another issue, best left to be discussed in the Lazarus mailing list. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Forwarded message about FPC status
Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? Original Message Subject: Re: [MSEide-MSEgui-talk] MSEide+MSEgui 2.8.4 Date: Mon, 17 Dec 2012 08:57:15 +0100 From: John Doe 1 To: mseide-msegui-t...@lists.sourceforge.net On Saturday 15 December 2012 18:19:24 John Doe 2 wrote: On 14/12/12 20:15, John Doe 1 wrote: This probably is the last version which depends on FPC-FCL. I often feel like doing the same. Hell, sometimes even replacing the RTL. I already have a slimmed down SysUtils and Classes unit in a private branch. It seems to me, main target of FPC development today is compatibility to the modern Delphi language constructs, I don't want to go this route.And we need more flexibility, I can't fight days or weeks with Michael and Marco for every little change which is not on Lazarus or their own benefit.Ouh, and there still is no unicode support for resource strings, no official statement how unicode will be implemented in RTL, the compiler becomes slower and slower, smart linking MSEide on 64 bit Linux is not possible with 2GB ram, still no Delphi-like packages... Sad. John Doe 1 --[ end ]--- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 17/12/12 13:06, Hans-Peter Diettrich wrote: We should wait for and explore how the multi-target Delphi handles that. Probably not even implemented, because Delphi IDE is Windows only - and there are no plans to make a cross-platform IDE by Embarcadero. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 17/12/12 15:29, Sven Barth wrote: I predict that we'll reach a point in the near(!) future where we won't (be able to) follow Delphi's lead anymore. And what a good day that will be. FPC will can innovate again. Delphi hasn't been leading for years, and Embarcadero is milking a dead cow!!! Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hi Luiz,
First off, thanks for take the trouble it creating test projects.
On 2012-11-29 02:59, luiz americo pereira camara wrote:
Test1
As is today, if you have a reference to a IFPObserver is not possible
to use it to attach to, e.g., child objects. This occurs because AFAIK
you can't get a TObject from a interface reference.
OK, there are quite a few things I consider wrong with your Test1
application.
1) Nothing stops Michael from extending the IPFObserver interface to
include a GetObject function that returns a TObject reference of
the observer.
I have seen many such cases in the wild. Not sure if I agree
with it, but that is another story.
2) What exactly are you observing in Test1? What are you trying to
accomplish?
TMyParentView is a TObject. Adding children to the Children property
doesn't notify the observer about anything.
... now if the Observer property is holding reference to something
that should observer each of the Children, well, then that is very
easy to accomplish too. Simply changes the Observer property to
a TObject instance.
3) Something Michael should fix. TFPObjectList doesn't support
IPFObserver. TObjectList does though. I guess many of the list
classes in the Contnrs unit should be double checked.
4) If you change FChildren to TObjectList, then it can be observer.
Then simply attach observers directly to the Children property. That
way if you add or remove children, the observers are notified.
5) I guess this depends on what you want to accomplish. But if you
first add children, then only call Initialize, then the observer
will never be notified that children was added to the list.
It was actually hard to figure out what you are trying to accomplish
with your test project. I think I'm still unclear of this. I'm seriously
under the weather at the moment (bad case of flu), so that probably
affects my judgement. So if I misinterpreted your Test project, please
do let me know. In the mean time, I modified your test1 (see attached).
The Observer now observes the Children List, and each Child - again, not
100% sure what you wanted to accomplish.
So solving your supposedly impossible problem was rather easy. So I'm
still on Michael's side that the FPC Observer API needs no change.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program ObserverTest1;
{$mode objfpc}{$H+}
uses
Classes, contnrs;
type
{ TMyParentView }
TMyParentView = class
private
FChildren: TObjectList;
FObserver: TObject;
public
constructor Create;
destructor Destroy; override;
procedure Initialize;
property Children: TObjectList read FChildren;
property Observer: TObject read FObserver write FObserver;
end;
{ TMyObserver }
TMyObserver = class(TObject, IFPObserver)
public
procedure FPOObservedChanged(ASender : TObject; Operation : TFPObservedOperation; Data : Pointer);
end;
{ TMyObserver }
procedure TMyObserver.FPOObservedChanged(ASender: TObject; Operation: TFPObservedOperation;
Data: Pointer);
begin
writeln('Observer changed');
end;
constructor TMyParentView.Create;
begin
writeln('Creating MyParentView...');
FChildren := TObjectList.Create(True);
end;
destructor TMyParentView.Destroy;
var
i: Integer;
Observed: IFPObserved;
Child: TObject;
begin
writeln('Destroying MyParentView...');
for i := 0 to FChildren.Count-1 do
begin
Child := FChildren[i];
if Child.GetInterface(SGUIDObserved, Observed) then
begin
//AFAIK it's not possible to get a TObject instance from an interface reference
//so if you have an IFPObserver variable or field it cannot be used to attach dettach to IFPObserved
Observed.FPODetachObserver(FObserver);
end;
end;
FChildren.Destroy;
inherited Destroy;
end;
procedure TMyParentView.Initialize;
var
i: Integer;
Observed: IFPObserved;
Child: TObject;
begin
for i := 0 to FChildren.Count-1 do
begin
Child := FChildren[i];
if Child.GetInterface(SGUIDObserved, Observed) then
begin
//AFAIK it's not possible to get a TObject instance from an interface reference
//so if you have an IFPObserver variable or field it cannot be used to attach dettach to IFPObserved
Observed.FPOAttachObserver(FObserver);
end;
end;
end;
var
View: TMyParentView;
ObserverObj: TMyObserver;
begin
ObserverObj := TMyObserver.Create;
View := TMyParentView.Create;
View.Observer := ObserverObj; // as IFPObserver;
View.Children.FPOAttachObserver(ObserverObj);
View.Children.Add(TPersistent.Create);
View.Children.Add(TPersistent.Create);
View.Children.Add(TPersistent.Create);
View.Initialize;
//Execute View
View.Destroy;
ObserverObj.Destroy;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On 2012-11-29 12:10, michael.vancann...@wisa.be wrote: The primary reason of existence for TFPList and TFPObjectList is speed and minimal overhead. OK, I understand now. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hello luiz, Thursday, November 29, 2012, 12:31:41 PM, you wrote: BTW: Graeme already pointed, that the Observer methods should be public. Does not makes sense to protect methods that are exposed by an interface. When did I say that? [Though my memory has been failing me once or twice. :)] As far as I'm concerned it should be the other way round. Interface implementations should all be done private - because you should always access those interface methods using an Interface reference. That's the way I do it in my own code. -- Best regards, Graeme ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hello luiz, Thursday, November 29, 2012, 9:39:36 PM, you wrote: In the message of the example observer: It seems Gmail searching has failed me. Thanks for fulfilling my curiosity. As for my comment. It was purely a suggestion (for convenience). My personal preference is still to use interface methods only via a interface reference. As I also mentioned in my quoted comment - there is good arguments for doing so. -- Best regards, Graeme fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 08:23, Vincent Snijders wrote: production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. +1 I thought it was a known fact that if you use FPC Trunk in production code, you stand a very likely chance that your production code will be broken at some point. Nothing in FPC Trunk is cast in stone. Though I must admit, this code has been around for some time (at least in my Inbox). I can see where Luiz is coming from. Most Observer implementations seem to be based on interfaces - but that is no hard and fast rule. I also understand Michael's point that AddObserver() and AttachObserver() doesn't need to take interfaces as a parameter. Most developers think that all Interface code is reference counted, but this is simply not true. eg: CORBA interfaces, which is used internally for the Observer support in FPC. The FPC implementation is very similar to what we have in tiOPF for many years, and there it works very well. Though in tiOPF the AttachObserver() and DetachObserver() parameters are a class type we know supports the the observer interface. In FPC this is not the case, though still not a show-stopper. You simply need to double check with a few Supports(obj, IFPObserved, intf) calls where needed. Luiz, could you produce a small sample application (or show the code you are working on for Lazarus) where you think the current FPC Observer implementation doesn't work. Your initial bug report doesn't include any test project to show the issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 09:41, Marco van de Voort wrote: You often can't reroot external components, but if they support tcomponent (and thus Tinterfacedobject), you can add an interface in a child class. You can add a CORBA interface to any existing class, and it doesn't need to descend from TInterfacedObject either. CORBA is not COM interfaces. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 10:07, Graeme Geldenhuys wrote:
You can add a CORBA interface to any existing class, and it doesn't need
to descend from TInterfacedObject either. CORBA is not COM interfaces.
In case anybody is in doubt. Here is a small example where CORBA
interfaces are attached to TComponent (aka TInterfacedObject
descendants) and TObject classes.
With CORBA interfaces - unlike COM interfaces - we can extend *any*
class. A lot more useful!
8-8-8-8-8
MyShape was created
MyShape is being freed
MyShape was created
AttachObserver called - MyShape
MyShape is being freed
MyNonInterfacedObjectClass was created
AttachObserver called - MyNonInterfacedObjectClass
MyNonInterfacedObjectClass is being freed
8-8-8-8-8
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program test;
{$mode objfpc}{$h+}
{$ifdef mswindows}
{$apptype console}
{$endif}
{$interfaces corba}
uses
Classes, SysUtils;
type
IObserved = interface
['{5DEEE4A1-8D50-4EA2-96C6-E47EFB65A563}']
procedure AttachObserver(AObserver: TObject);
end;
{ 3rd party component - out of our control }
TShape = class(TComponent)
private
FName: string;
public
constructor Create(const AName: string); virtual; reintroduce;
property Name: string read FName write FName;
end;
{ my personal extensions }
TSquare = class(TShape, IObserved)
private
FSize: integer;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Size: integer read FSize write FSize;
end;
{ my non-TInterfacedObject class }
TMyClass = class(TObject, IObserved)
private
FName: string;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Name: string read FName write FName;
end;
{ TShape }
constructor TShape.Create(const AName: string);
begin
inherited Create(nil);
FName := AName;
end;
procedure TSquare.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
{ TMyClass }
procedure TMyClass.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
var
s1: TShape;
s2: TSquare;
s3: TMyClass;
intf: IObserved;
begin
{ Lets try the Shape first }
s1 := TShape.Create('MyShape');
writeln(s1.Name + ' was created');
if Supports(s1, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s1.Name + ' is being freed');
s1.Free;
writeln('');
{ now lets try the Square }
s2 := TSquare.Create('MyShape');
writeln(s2.Name + ' was created');
if Supports(s2, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s2.Name + ' is being freed');
s2.Free;
writeln('');
{ now lets try the the non-TInterfacedObject class }
s3 := TMyClass.Create;
s3.Name := 'MyNonInterfacedObjectClass';
writeln(s3.Name + ' was created');
if Supports(s3, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s3.Name + ' is being freed');
s3.Free;
writeln('');
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 16:19, Michael Van Canneyt wrote: The consequence is that you must pass around the objects themselves. I'm curious to see Luiz's code example of what issues he has, but in the mean time, maybe it wouldn't be such a bad idea to update (with latest FPC changes and Observer support) the LCLMediators code and demos you emailed me a couple years back. [time permitting of course] If you haven't made other changes to those LCL Mediators since the code you emailed me, I could take a look at updating the code for Lazarus too. That's a perfect example of the FPC Observers support being fully functional as-is. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Interface usage causes FPC to crash
Hi,
I tested the attached program under Delphi 7 and FPC 2.6.0 and FPC 2.7.1
(dated 2012-11-15).
The test application tests two things:
1) Interface delegation via another class
2) Overriding a interface implementation using method resolution
Under Delphi 7 the test application compiles and runs as expected.
Under FPC (both 2.6.0 and 2.7.1)
- I get a compiler error. I thought interface delegation was
supported in FPC?
- I also get a compiler crash with an AV - in both versions.
Isn't interface delegation supported in FPC?
Is method resolution supported in FPC?
Why does the compiler crash while compiling?
8-8-8-8-8
Free Pascal Compiler version 2.6.0 [2011/12/23] for x86_64
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test.pas
test.pas(38,76) Error: Class TMyIntfClass does not implement interface
IMyIntf
Fatal: Compilation aborted
An unhandled exception occurred at $0054CA3D :
EAccessViolation : Access violation
$0054CA3D
$00532148
$0056CEF4
$0042392F
8-8-8-8-8
The expected output when running the test application should be:
--
c:\Programming\test\interface_delegation_2test
TMyIntfClass.P1
TMainForm.MyP2
--
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program test;
{$ifdef FPC}
{$mode objfpc}{$H+}
{$else}
{$APPTYPE CONSOLE}
{$endif}
uses
Classes;
//-- Interface --
type
IMyIntf = interface(IInterface)
['{ED858BD2-0E49-4B42-861D-6F415A7C0CF0}']
procedure P1;
procedure P2;
end;
{ Delegation class.
NOTE: Documenatation suggested we use the TAggregatedObject, but
under Delphi 7 (at least) we can use TObject too. }
TMyIntfClass = class(TObject)
private
{ IMyIntf implementation }
procedure P1;
procedure P2;
end;
TMainForm = class(TComponent, IMyIntf)
private
FMyIntfClass: TMyIntfClass;
{ delegate IMyIntf implementation to another class }
property MyIntfClass: TMyIntfClass read FMyIntfClass implements IMyIntf;
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
procedure Run;
{ overrides the IMyIntf.P2 implementation using name resolution }
procedure IMyIntf.P2 = MyP2;
procedure MyP2;
end;
//-- Implementation --
procedure TMyIntfClass.P1;
begin
Writeln(Classname + '.P1');
end;
procedure TMyIntfClass.P2;
begin
Writeln(Classname + '.P2');
end;
constructor TMainForm.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FMyIntfClass := TMyIntfClass.Create;
end;
destructor TMainForm.Destroy;
begin
FMyIntfClass.Free;
inherited Destroy;
end;
procedure TMainForm.Run;
begin
(self as IMyIntf).P1;
(self as IMyIntf).P2;
end;
procedure TMainForm.MyP2;
begin
Writeln(Classname + '.MyP2');
end;
// - Application starting point -
var
frm: TMainForm;
begin
frm := TMainForm.Create(nil);
try
frm.Run;
finally
frm.Free;
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 15:02, luiz americo pereira camara wrote: Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. [Not related to the issue in question] Indeed, just because it is tagged as RC doesn't mean everything must be cast in stone. A RC tag is *not* an official release yet. Nothing stops the FPC team from creating another 10 RC releases before the official FPC 2.6.2 - and maybe fixing last minute critical bugs etc. The more important thing is to get the issue at hand [if there is one] resolved. Many developers don't use Trunk, and only start testing new FPC releases when RC's are announced. Yes, this is definitely not ideal for the FPC team, but this is often how it works - roll with it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 17:17, Leonardo M. Ramé wrote: Hi, does anyone know of a link to the wiki with info about the newly implemented Observer pattern?. No wiki page, but I did submit in the mailing list and Mantis a observer demo with code comments to show how it works and how to use it. http://bugs.freepascal.org/view.php?id=23329 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus 1.0 and fpc 2.6 do not install on popular distributions
On 2012-11-22 23:34, Giuliano Colla wrote: Thanks, but I managed to install. I just wanted to point out that those incompatibilities may frighten or discourage a new user. I do agree with what you said - all valid points. I would also like to point out that FPC (not sure about Lazarus) is available in a .tar.gz release as well – using its own home-grown installer. I use OpenSUSE 12.2 (and before that, many versions of Ubuntu) but never install FPC or Lazarus using the .rpm or .deb releases. I always use the binary .tar.gz release for FPC and install into a custom location (in my $HOME directory). I then download the source release of Lazarus, and manually compile that — also in a custom location in my $HOME directory. The reasoning is two-fold. * I can install into my $HOME directory * By manually compiling Lazarus, I am also testing if my FPC installation is correct to build my own projects. Most developers are often going to recompile Lazarus anyway - by installing new components. So it is just easier doing it from the start, and in a location where I have read/write access. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On 25/10/12 00:55, luiz americo pereira camara wrote: - Initially i questioned the fpc obsever support, now i see as a good implementation The FPC Observer and Mediator is based on works found in the tiOPF framework - done a few years ago. And that in turn was based on a implementation I done for our company back in 2005. The design and functionality has a long history, is well tested in production software - so yes, it is good. ;-) - ... (i would bet it was introduced to support the Live Bindings) Yes I would imagine so. The tiOPF Observer Mediator implementation is the basis for our company's live bindings, which we call Model-GUI-Mediator (very similar to Model-View-Controller). This was long before Delphi had Live Binding support. We have been using the tiOPF implementation for 7 years in all our products, and all our application's UI is Observer/Mediator driven. There isn't a single DB-aware component in sight. I can hook up any gui control to a data/business object property with a single line of code, and have 2-way updates with no extra work. Michael even took the tiOPF idea and built a non-tiOPF based design-time support for Lazarus (this is where the current FPC Observer/Mediator comes in) - though the design-time code was never contributed to the Lazarus project. I'm sure he will at some point. Anyway, to make a long story short. The current FPC Observer/Mediator is a good design and very flexible with what it can offer. The Lazarus project could very easily use this to implement their own live bindings support. It could even make DB-aware components obsolete (optional). (two implementations) since would have overlapping features with possible overhead (two observer lists per component?) at base classes Yes indeed, having two implementations in FPC would definitely not be a good idea! Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On 2012-10-24 07:52, michael.vancann...@wisa.be wrote: However, given the total lack of documentation, it is hard to say. +1 I had a look too, the Embarcadero website isn't much help. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On 2012-10-24 09:59, michael.vancann...@wisa.be wrote: in the classes (!) unit, makes me shudder, though. How anyone can create such a convoluted system is beyond me. Yup. [shaking my head in disbelief] Delphi is going the way of the dodo. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On 2012-10-24 10:01, Marco van de Voort wrote: I can still unmerge the observer functionality from fixes/2.6.2. Then (1) is also still a possibility. Please don't! I've been waiting years for that in FPC, and am actively building work based on that functionality. G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 08:22, Martin Schreiber wrote: I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. I'm afraid I don't understand your reply. People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. Then that is me. :) Fine, but I did also mention a web forum front-end to the NNTP server. So users/developers have a choice of what they want to use. A traditional NNTP Client (desktop app) or the Web Interface (Forum interface) to the NNTP server. This is exactly what Embarcadero did too. They have loads of newsgroups, but they also knew some developers prefer web forums, so they bought such a solution and modified it to suite there needs. New postings are seen by everybody instantly - no matter if you use NNTP directly, or use the Web Interface. Now what of this did Marco not understand? Then again, I should be use to Macro's odd answers to anything I post. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 09:56, Marco van de Voort wrote: So having a preference is not the problem (and I prefer NNTP too), but pushing it when it is a lost cause is. So you give up that easy. Personally, I don't tend to be a lemming and always follow the flavour of the month. G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:30, michael.vancann...@wisa.be wrote: For me, it has become second nature never ever to have a variable with the same name as a property, even in Delphi. +1 G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:48, Marcos Douglas wrote: problem, IMHO, is that I can't choose when we talk about local variables. Just like there is a coding style (not language rule) that classes start with the T prefix, and class field variable start with a F prefix, I applied that same coding style to parameters and local variables. L prefix for local variable - though I prefer the lowercase 'l' for this for some add reason. The exception being counter variables like x, y, i, j etc. A prefix for parameter variables. Using this simple coding style makes things even more logical and less confusing, even though I use mode objfpc for 90% of my code. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. The change in FPC mode objfpc was definitely a good thing. I had code where a class had an Index property, and other methods of that class had an Index parameter name. Even though it was my own code, I had to triple check the method's implementation to find the real meaning when I used the Index identifier somewhere in that method. Now with the new language rule, I don't have such issues any more. Index will be the property name, AIndex will be the parameter, lIndex will be a local variable. Much simpler for my brain to process. :) Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On 2012-09-27 14:50, michael.vancann...@wisa.be wrote: I did some benchmarking. Using XML (well, SOAP) makes a typical application 6 times slower than a comparative binary transmission mechanism. Just curious, did you even do that test with JSON as well? Probably still slower than binary, but how much faster than XML? tiOPF has normal XML and compact XML for remote persistence layer. The compact XML is the default, more cryptic names and values, but reduces network traffic a lot. I still want to add JSON support too. Cheers, G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
