Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
Am 03.03.2016 um 14:29 schrieb Alfred: > Working ! > > Thanks very much. > I have now an aarch64 fpc(laz)up executable, compiled through Lazarus. > > If a 64 bit RPi3 distro is available, I will report back !! I ordered also one in the hope using it to play with fpc aarch64. But currently it does not look good as it seems that it is not only a matter of the kernel but also the firmware. At least I didn't unwrap mine yet because of this, without aarch64 support I see no use for me in it. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 07.11.2015 um 06:40 schrieb Alexander Klenin: > On Sat, Nov 7, 2015 at 5:58 AM, Florian Klaempfl > wrote: >> Am 06.11.2015 um 20:22 schrieb Luca Olivetti: >>> El 06/11/15 a les 18:10, Martin Schreiber ha escrit: >>> >>>> You are joking, no? It has been discussed on fpc-pascal/fpc-devel several >>>> times. An IIRC Italian community member then usually shows a syntax >>>> description of a safe "with" statement from a maybe more than 20 year old >>>> pascal dialect. > Here is one "recent" discussion: > http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-with-is-evil-isn-t-it-td3219144.html > >> It is similiar to the proc. var code which is also one of the places >> only very brave people look at ;) > One nice thing about FPC/Lazarus is that I may disappear for a few years, > then look back and see same topics discussed by the same people with > the same conclusions ;-) > Indeed, unfortunatly nothing changed: bug count increases continously and the fixing is done mainly by the long term comitters but people are still proposing to extend the language with more sugar increasing maintainance work. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 07.11.2015 um 06:42 schrieb Ondrej Pokorny: > > Do not forget that you can overload operators! In particular you can > overload the comparison operator to return a record, so your > "with a=somerecord do" can already be a valid pascal code now: > > *type** > ** TMyRec = record** > **I: Integer;** > ** end;** > ** > ** TMyResult = record** > **Res: Integer;** > ** end;** > ** > **operator = (z1: TMyRec; z2 : TMyRec) b : TMyResult;** > **begin** > ** Result.Res := z1.I+z2.I;** > **end;** > ** > **var** > ** m1, m2: TMyRec;** > **begin** > ** m1.I := 10;** > ** m2.I := 1;** > ** with m1=m2 do** > **writeln(Res);** > ** readln;** > **end.* > > The assignment operator would be better, since it doesn't return a value > (in pascal, of course) and thus cannot be used in a with statement now: Good that we removed another "great" language extennsion already years ago, the support for a C-like assignment operator which returns a result :))) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 06.11.2015 um 20:22 schrieb Luca Olivetti: > El 06/11/15 a les 18:10, Martin Schreiber ha escrit: > >> You are joking, no? It has been discussed on fpc-pascal/fpc-devel several >> times. An IIRC Italian community member then usually shows a syntax >> description of a safe "with" statement from a maybe more than 20 year old >> pascal dialect. > > I don't know if that's me, but, yes, I used a variant of pascal (by > texas instruments) that allowed to declare aliases with "with", e.g > > with a=somerecord, b=someotherrecord do > begin >a.x:=b.x; > end; > While I think this is something were a patch would be accepted, my main issue is that the with handling code in the compiler is somehow messy. Not necessarily due to bad coding but simply the way how "with" works. It is similiar to the proc. var code which is also one of the places only very brave people look at ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OOP - where do you start?
Am 26.06.2015 um 14:47 schrieb Michael Van Canneyt: > > > On Fri, 26 Jun 2015, Graeme Geldenhuys wrote: > >> Hi, >> >> Last night I was working on a relatively new project. This got me >> thinking... How do others tackle such a task? >> >> So here is my question: >> >> When faced with a new database related project, where do you start? Do >> you first design the database schema, then build the BOM (Business >> Objects) accordingly? Or, do you first design the BOM, then design the >> database schema to fit. >> >> Personally, most of my project were started by first creating the >> database schema. Don't ask me why, that is just what I did. Maybe it was >> because many of the tools I use, can write much of the boiler plate code >> for me, and they do that by querying a database structure. But I've been >> thinking that with my next project, I'm going to start with the BOM >> first, and see how it goes. I'm assuming the end result should be the >> same, no matter which part I tackled first. >> >> What's your thoughts? > > I always start with the data. Almost all applications I ever wrote have > databases. Maybe we should store compiled unit interfaces in a database instead of using .ppu ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] The future of desktop
Am 04.12.2013 21:31, schrieb Avishai: The guys that started Lazarus had a base to start from. They didn't start from scratch. They already had the basic code to do a lot of things and it worked. But it only worked for LeftToRight. If Lazarus could address even a few of the major issues, I think it would become the dominant programming tool of the Middle East. I thing that's significant. No. Significant are the contributors. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] The future of desktop
Am 04.12.2013 21:48, schrieb Avishai: Really? I thought it started fro Megido. And? Then the same would apply to Megido. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Release Candidate 1 of 1.2
Am 06.11.2013 20:42, schrieb Martin: One of my favourite features: 'Inactive code in $IFDEF can be "low-lighted" (greyed out)' :) And, if you configure IFDEF to be foldable, and right click the fold gutter part, then you find an option to fold all inactive ifdef. Nice to see, now my last complaint on folding must be fixed and I'am really happy: the folding header line should be surrounded fully by a rectangle, not only the three dots at the end :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] When TException is distroyed?
Am 29.06.2013 23:59, schrieb William Oliveira Ferreira: Just a curiosity question: if we use try exception, the system auto create a texception object, but, when it is destroyed? When leaving the except block handling the exception (if AcquireExceptionObject has not been called). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus and Free Pascal downloads plummeting on SourceForge
Am 30.07.2012 21:18, schrieb Russell Davies: > Hi, > > Over the years I have occasionally checked the increase in downloads > of both Lazarus and Free Pascal on SourceForge, but for some reason > the download rates of both suddenly seem to be in free-fall! See the > attached graphs. http://sourceforge.net/projects/lazarus/files/stats/timeline?dates=2004-01-01+to+2012-12-31 Looks like it was indeed some fluctuation. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus 1.0 release candidate 2 available for download
Am 22.08.2012 11:00, schrieb Mattias Gaertner: The Lazarus team is glad to announce that Lazarus 1.0RC is available for download at the SourceForge download page: Gratulations also from me that lazarus is finally approaching 1.0 :) My personal experience is also that lazarus is 1.0 ready because during the last year I switched all my compiler development from the fp text mode ide (which I used for >10 years to do compiler development) to lazarus. Though I'am using 1.1 instead of 1.0 rcX :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] AGG missing 3 asm conversions to work on 64-bit CPU's
Am 09.03.2012 15:33, schrieb Graeme Geldenhuys: > On 9 March 2012 16:12, Mattias Gaertner wrote: >> >> Should these changes be applied to the lazarus aggpas? > > > Yes. Attached is the patch for this thread's mentioned problem - no > x86_64 bit shifting implementation. > Making the helpers inline functions is probably a good idea. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling only LCL to 64-bit, on Windows
Am 25.08.2011 17:38, schrieb Henry Vermaak: >> If you don't use TortoiseSVN I guess it's shouldn't be to hard to feed >> sed with svn st output to remove untracked files. Why should svn do this >> if a sed one liner can do this ;)? > > Indeed. Just remember to use svn st --no-ignore and catch both "I" and > "?". Well, ignored is not untracked for me ;), but for a really clean working copy, you're right. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling only LCL to 64-bit, on Windows
Am 25.08.2011 17:19, schrieb Andreas Schneider: > On 25.08.2011 17:09, Graeme Geldenhuys wrote: >> On 08/25/2011 05:06 PM, Andreas Schneider wrote: >>> >>> Although slightly off-topic, but SVN's revert is not really clean. It >>> reverts files it knows, but it doesn't remove unknown files. I'm not >>> aware of an SVN equivalent of Mercurial's purge (for example). >>> So yes, a clean checkout CAN make sense sometimes. >> >> svn revert . >> svn export > > Still not the same. Export would also remove .svn metadata, which is not > what I (would) want. What I want is to remove all files that aren't > tracked by SVN - i.e. get the working copy to be EXACTLY what a fresh > checkout would be; no more, no less. If you don't use TortoiseSVN I guess it's shouldn't be to hard to feed sed with svn st output to remove untracked files. Why should svn do this if a sed one liner can do this ;)? > >> Then use the as a "clean" directory. But yes, SVN still >> sucks big time compared to Mercurial or Git. > > Oh yes. /signed ;-) > So they got finally proper cherry pick tracking and blocking ;)? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling only LCL to 64-bit, on Windows
Am 25.08.2011 17:06, schrieb Andreas Schneider: > On 25.08.2011 16:49, Flávio Etrusco wrote: >>> (...) meanwhile >>> I'm downloading clean FPC sources to test again. >>> >>> Marcos Douglas >>> >> >> "downloading clean"? I hope you mean TortoiseSVN's "Revert..." command... >> >> -Flávio > > Although slightly off-topic, but SVN's revert is not really clean. It > reverts files it knows, but it doesn't remove unknown files. I'm not > aware of an SVN equivalent of Mercurial's purge (for example). TortoiseSVN's cleanup dialog has an option to delete unversioned files and directories. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Code completation results in ugly indention
I just tried another time the code completation in lazarus for a class, however it resulted again in a pretty bad indention, see attachment. I played with various options and things but nothing helped (procedure/constructor should be at column 4 as it is typically in the compiler sources, begin/end at column 6). What is wrong/how can I tweak it? <>-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] RE : RE : Console App Development
Am 14.08.2011 11:49, schrieb Martin: > > Does valgrind know about the fpc internal mem handling When using valgrind, cmem is used. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi XE2 uses FPC, plus VCL just not portable
Am 07.08.2011 17:46, schrieb Graeme Geldenhuys: > On 7 August 2011 16:11, Florian Klaempfl wrote: >>> Imagine Mozilla Firefox simply >>> wanted to be a clone of IE. >> >> This would have no advantage > > It would have had, just not for the better. If Firefox simply cloned > IE, web designers would only have had to code for ONE broken browser > (ignoring HTML standards while they are at it, but at least all > websites would have worked on all platforms), and they [web designers] > could have reused there broken-HTML syntax knowledge for all > platforms. My point was simply that cloning has very little benefits > at all, and is always two steps behind - never as good as the real > deal. As said before, for me the indicator of the success of an OSS product is the number of contributors, so this narrows it down. > Think iPad vs Tablet. 1-2 years later, with hundreds of > clones, and still iPad is better than the rest with no real > competition in sight. > > >> ...while being VCL compatible allows people to >> reuse a lot of their knowledge when using the LCL. > > Yes, Object Pascal knowledge and some VCL knowledge. And > realistically, LCL has many differences between VCL and many > differences between LCL on different platforms (again, look at Mantis > if you don't believe me). Not to mention a different compiler too, > different deployment rules etc etc. No matter how much you clone, > there is still LOTS to learn when moving your products cross platform. > To have truly cross-platform products you have to think cross-platform > from the start. Trying to convert your Windows-ism's to Linux or Mac > simply doesn't work! You will end up with a half-baked product that > will not sell. Embarcadero realized this too. You know that the CLX was not VCL compatible either, aimed a cross platform compatibility (Qt) and required basically a complete rewrite? Result is known ... >From what I saw of FireMonkey so far (admitted little): I don't think that it competes with classical gui toolkits but it seems to aim at new gui concepts as mobiles or tablets require. So the situation is different here and FireMonkey has good chances to be a success. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi XE2 uses FPC, plus VCL just not portable
Am 07.08.2011 14:32, schrieb Graeme Geldenhuys: > > Let history be a lesson too. What "clone" of a popular product is > currently a success today. NONE! Sybil - dead. CLX - dead. Mono - dead Just count the number of dead, non-vcl compatible and largely unknown gui libraries. At least I've one to offer: FPKWin :) > Imagine Mozilla Firefox simply > wanted to be a clone of IE. This would have no advantage while being VCL compatible allows people to reuse a lot of their knowledge when using the LCL. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Illegal parameter: -WG
Am 07.06.2011 20:43, schrieb Mattias Gaertner: > On Tue, 7 Jun 2011 20:36:57 +0200 > Vincent Snijders wrote: > >> 2011/6/7 Mattias Gaertner : >>> On Tue, 7 Jun 2011 17:02:30 +0200 >>> Vincent Snijders wrote: >>> [...] So win32, win64, wince, os2 and macos (not macosx). >>> >>> I implemented that. >>> >> >> mac os <> darwin, >> darwin is Mac OS X (unix like), macos is Mac OS before version 10, >> which ran on the m68k. ... and PowerPC. > > Oops. > Fixed in 31127. Please keep in mind that OS/2 actually means plain OS/2 and EMX which are different targets in FPC. Maybe it's worse to check all the -W switches in lazarus. I made them all target dependent. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki.lazarus.freepascal.org have problem with mysql
Am 03.05.2011 16:22, schrieb Graeme Geldenhuys: > > As for Florian's issue with the "corrupted file system". I would highly > suggest he investigates why the problem occurred in the first place, so > that it can _truly_ be fixed. The machine suffered multiple UPS failures recently and one suspision is that the fsck run did not find all errors. Further, it is a years old Ubuntu 6.06 LTS install which ran first on a physical machine and later on the image was imported into a xen vm. Moving all services to another vm with a fresh and new ubuntu install (windows trick ;)) is on our todo list. But you know ... > The wonderful world of Windows > Administrators have corrupted the minds of so many system admins with > the advice: "reboot and the problem should be fixed". That's the worst > advice ever, and it fixes nothing! > > Paul Venezia said it best: "When in doubt, reboot? Not Unix boxes" > http://www.infoworld.com/t/unix/when-in-doubt-reboot-not-unix-boxes-061 > > > > Regards, > - Graeme - > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki.lazarus.freepascal.org have problem with mysql
Am 03.05.2011 15:53, schrieb Graeme Geldenhuys: > On 03/05/2011 13:14, Florian Klaempfl wrote: >> >> Won't help in case of a corrupted file system ;) > > Ever heard of backups? ;-) We have daily backups but it was not needed to restore a backup, but linux remounted the fs read-only so mysql stopped obviously to work ... > > All our servers have the following setup that works very well for us: An > OS drive (only contains the OS - in our case Linux), and all data is > stored on a separate RAID disk set (two or more drives with mirroring > enabled). Replacing/Reinstalling the OS takes 30 minutes, restoring > config files takes <5 minutes. A faulty RAID disk is simply a swap-out > and it rebuilds itself. Each Friday one RAID disk gets swapped with an > off-site spare disk. You only need to loose data once, then you learn to > protect it like crazy. ;-) Well, you can loose the data of one week in the scenario of a corrupted file system. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki.lazarus.freepascal.org have problem with mysql
Am 03.05.2011 10:49, schrieb Graeme Geldenhuys: > On 02/05/2011 18:15, ik wrote: >> >> (Can't contact the database server: Can't connect to local MySQL server >> through socket '/var/run/mysqld/mysqld.sock' (2) (localhost)) > > > I can confirm this problem. They should have used Firebird RDBMS > instead. ;-) Won't help in case of a corrupted file system ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC and Lazarus on ARM
Am 28.03.2011 13:35, schrieb Felipe Monteiro de Carvalho: > On Mon, Mar 28, 2011 at 1:18 PM, Florian Klaempfl > wrote: >> Am 28.03.2011 11:41, schrieb Felipe Monteiro de Carvalho: >>> If you want to >>> actually develop on the platform, you really need to get rid of >>> Android and install a standard Linux. If you manage to do that, then >>> AC100 with a USB mouse might actually be a good ARM test platform for >>> developers. >> >> Did you do so? > > No, not really. In my work all development is done via cross-compiling. > Hmm, I'am still looking for a reasonable system for arm eabi development. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [OT] About licences
Am 31.03.2011 04:09, schrieb waldo kitty: > On 3/30/2011 08:18, Zaher Dirkey wrote: >> On Wed, Mar 30, 2011 at 12:52 PM, Marco van de Voort >> wrote: >> >> On Wed, Mar 30, 2011 at 09:23:12AM +0200, Graeme Geldenhuys wrote: >> > > The (L)GPL with exception bit absolves you from that. >> > >> > Where does it say that? By "LGPL with exception", I gather you >> mean like >> > the license used by FPC? It that case, there is only a "static >> linking >> > exception". You are still required to donate all modifications >> to the >> > LGPL code though, just like the vanilla LGPL license. >> >> My bad, you are entirely right. The exception absloves you from >> the clause >> that forces dynlinking, not the OSS bits. I don't know what I was >> thinking. >> >> >> I always feel not free with all this free licenses. > > my thoughts, too... for many years ;) IMO but IANAL, the free is meant to keep the liberty of the sources but it's not about that a user is free to do with the sources what he wants. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Off-topic: Debian vs Ubuntu
Am 29.03.2011 09:47, schrieb Graeme Geldenhuys: > Hi, > > While following some of the discussion about "FPC and Lazarus on ARM" it > made me think of a question I wanted to ask any Linux users, and I know > here are quite a few. > > Is it only Ubuntu that cannibalized the Linux run-levels beyond > recognition, or is the same thing done in Debian too? I think the Debian policy is that you should configure yourself the runlevels 2-5 as you need. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC and Lazarus on ARM
Am 28.03.2011 11:41, schrieb Felipe Monteiro de Carvalho: > If you want to > actually develop on the platform, you really need to get rid of > Android and install a standard Linux. If you manage to do that, then > AC100 with a USB mouse might actually be a good ARM test platform for > developers. > Did you do so? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Rescan FPC sources crashes Lazarus
Am 26.03.2011 10:15, schrieb Hans-Peter Diettrich: Graeme Geldenhuys schrieb: [fpc] should rather use some singleton class with a read-only property, A class is not required, FPC supports unit-level properties as well :-) True, but the issue with them is: you cannot use them to create a fool proof read-only property without using a function because there is no unit level encapsulation aka private/protected on unit level: the variable read by the property cannot be in the implementation part of the unit because it wouldn't be accessible at declaration time of the property. Making IsMultiThreaded a function is a no-no: it is used in really speed critical code paths and using an inline function neither because it's used mostly in assembler code in the rtl like: if ismultithreaded then else -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 22.02.2011 11:11, schrieb Graeme Geldenhuys: > Op 2011-02-22 11:27, Florian Klaempfl het geskryf: >> >> Feel free to do so, we are all waiting for at least five years for > > Wasn't that what Hans-Peter (or somebody) recently tried?? But from the > discussions I read, the changes were "to radical" from a non-core > member, so as usual, the changes get declined Please stay with the truth: first of all, the proposed changes so far had nothing to do with improving unit loading. Further, none of the changes were working. You'd kill me, if I merged those changes breaking FPC completely :) Last but not least: the radical changes (also far from working changes in the sense of no regressions) which get declined aimed on a multi language front end for FPC. While this in theory is imaginable, I expect a lot of dedication before I merge such changes into FPC: it means not only a hacked parser, but also a complete new runtime environment, complete reorganisation of the directory structures and build processes, a lot of new regression tests etc. Considering http://fpcext.git.sourceforge.net/git/gitweb.cgi?p=fpcext/compiler;a=summary the dedication and interest is little. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Am 22.02.2011 09:58, schrieb Graeme Geldenhuys: > Op 2011-02-22 10:44, Florian Klaempfl het geskryf: >> Delphi clone/non delphi clone? Does it ring bells? You always tell us: >> don't do a delphi clone. Then we don't do it and you cry. > > Well make up your bloody mind??? If you want to make FPC a Delphi clone, > then stick to it. Having some areas cloned and some not, makes things a > little annoying. No problem, if you don't troll, somebody else will. > That was what I was complaining about that time. You followed the generics discussions? > An NO, I'll never shed a tear over FPC - that's all your wishful thinking. I'am glad to hear that you're always happy about FPC :) > > >> An even better argument not to change it :) Even in ObjFPC mode a string >> is a shortstring for years. > > Out of curiosity, why does ObjFPC mode default to ShortString and not > AnsiString? Why break existing code for nothing? Such a change would simply steel people their time while the gain is zero: people interested in string = ansistrings can either add $H/-Sh to their project when migrating from shortstring to ansistring or they can replace explicitly string by ansistring. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 22.02.2011 08:35, schrieb Graeme Geldenhuys: > No point > in recommending all developers changes their style of coding, when the > issue is in the compiler - not the language. Rather try and fix Feel free to do so, we are all waiting for at least five years for somebody to fix it :) I estimate that it takes me on month of fulltime work to fix it by rewriting the whole unit loading mechanism. I simply don't have the time to do and it seems nobody else either. > the > cause of the problem, not the symptom. If you can't heal a disease, you can at least try to reduce the symptoms. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Am 22.02.2011 08:58, schrieb Graeme Geldenhuys: > Op 2011-02-21 10:02, Florian Klaempfl het geskryf: >> >> the different handling of temp. interfaces in >> FPC which is only a implementation detail? > > Sorry, no idea how that relates to this discussion. Delphi clone/non delphi clone? Does it ring bells? You always tell us: don't do a delphi clone. Then we don't do it and you cry. > > >> ObjFPC used AnsiString for a String from the >> beginning ... > > Learn your own compiler! ;-) Theo is correct, mode ObjFPC defaults to > ShortString, not AnsiString. An even better argument not to change it :) Even in ObjFPC mode a string is a shortstring for years. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 10:30, schrieb Alexander Klenin: > On Mon, Feb 21, 2011 at 18:05, Florian Klaempfl > wrote: >> >> Well, he got it wrong :) It is exactly the point of putting units in the >> interface uses clause: the compiler helps you to avoid circular unit >> dependencies. When you put them in the implementation clause, you just >> hide them, they are still here but the compiler does not complain as >> long as you don't hit its flawed unit loading algorithm. >> > > So, Florian, how about adding a compiler hint or warning for circular > dependencies? I'am not sure if the compiler somewhere gets this information explicitly. As said, the design of the unit loading is fundamentally flawed. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 09:00, schrieb Graeme Geldenhuys: > Op 2011-02-21 09:55, Florian Klaempfl het geskryf: >> >> And? Does it compile? > > Read Bo Berglund's message from a few minutes ago... maybe he explains > better what I was trying to get at. Well, he got it wrong :) It is exactly the point of putting units in the interface uses clause: the compiler helps you to avoid circular unit dependencies. When you put them in the implementation clause, you just hide them, they are still here but the compiler does not complain as long as you don't hit its flawed unit loading algorithm. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Am 21.02.2011 08:09, schrieb Graeme Geldenhuys: > > Introducing yet another compiler mode also doesn't seem like the way to > go. FPC is already complex enough. The String type simply needs to > evolve to Unicode support, just like it did from ShortString to > LongString. A natural evolution. Remember your crying about the different handling of temp. interfaces in FPC which is only a implementation detail? > This should probably be something > included in both ObjFPC and Delphi compiler modes, but again, I only > every work with ObjFPC mode. When did String change from ShortString to LongString (actually AnsiString) in ObjFPC? ObjFPC used AnsiString for a String from the beginning ... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 08:54, schrieb Graeme Geldenhuys: > Op 2011-02-21 09:50, Graeme Geldenhuys het geskryf: >> Op 2011-02-21 09:41, Mattias Gaertner het geskryf: >>> >>> You can't create circular dependencies with only interface >>> dependencies. Only implementation uses section allow this. >> >> Really? See attached project. Took me all of 30 seconds to create such >> an example for you. Only Interface uses sections are used. > > And just to be clear...by that I mean, to get the "circular unit > reference error" in FPC. So simply using Interfaces uses section only > doesn't resolve such an issue. Of course it does: a similiar project using the units only in the implementation part compiles. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 08:50, schrieb Graeme Geldenhuys: > Op 2011-02-21 09:41, Mattias Gaertner het geskryf: >> >> You can't create circular dependencies with only interface >> dependencies. Only implementation uses section allow this. > > Really? See attached project. Took me all of 30 seconds to create such > an example for you. Only Interface uses sections are used. And? Does it compile? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 08:18, schrieb Graeme Geldenhuys: > just because of a FPC bug doesn't bode well. Rather fix the cause > of the problem. > It is a known issue for years that FPC gets rarely into trouble with complex circular unit dependencies. The problem is the recursive design of the unit loader. However, nobody volounteered yet to fix it :( -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Identifier not found, but code completion works....
Am 21.02.2011 07:43, schrieb Graeme Geldenhuys: > > it reduces circular unit dependencies if you use > the implementation section as much as possible, How? Dependency is dependency. The danger of putting units in the implementation uses clause is that somebody creates circular dependencies by accident. This cannot happen when the unit is used in the interface part. This is usually a no brainer for small teams and projects but for bigger projects it might matter. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
> If so, then I wouldn't waist any more of my time on working on the > cpstrnew branch FPC still follows the thumb rule (notice the thumb rule): the person who implements a certain feature, decides. E.g. if somebody comes up with a working code paged string implementation without breaking existing stuff too hard, I'am pretty sure it will be added. Of course, somebody else might pop up and add Delphi like support. > (which I have been doing quietly on my own). Always bad. Release sources early, release sources often ;) > > then why use FPC - just switch to the > "real" thing [Delphi]. Everybody is free do to so, at least I'am not dogmatic about this as long as you use some compiled pascal flavour :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] following wiki for new clean install from SVN...
Am 09.02.2011 10:18, schrieb Lukasz Sokol: > On 09/02/2011 08:33, Sven Barth wrote: > >> At least on XP and newer TortoiseSVN does not need a reboot... > > AFAIR they (TSVN) recommend it themselves (at least when I was installing > TSVN 1.6.5 build 16974) > in their installation program; The point is simply that dlls might be updated so rebooting is recommend so all programs get the latest dlls. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] 0.9.30 merges are not really merged???
Am 02.02.2011 12:37, schrieb Vincent Snijders: > > The list of merged revision can be found in the svnmerge-integrated > property of root of the branch. > vincent@fpclin32:~/src/lazfixes$ svn propget svnmerge-integrated > http://svn.freepascal.org/svn/lazarus/branches/fixes_0_9_30 > /trunk:1-28809,28812-28814,28816-28826,28828-28847,28853-28854,28861,28863-28875,28877,28905,28907,28910-28912,28923,28925-28927,28930,28935,28937,28941,28963-28964,28978-28980,28982,29005,29021,29025-29027,29031,29035-29036,29061-29062,29067,29081-29084,29094-29100,29104,29112,29136,29138,29140-29141,29146,29157,29159,29181,29192-29193,29237,29296,29299,29316 Or just use svnmerge integrated maybe with -l to get the logs and -S if multiple branches are merged into the current one. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OFFTOPIC: Money Model, for Lazarus
Am 06.12.2010 13:46, schrieb Alexsander Rosa: > Back to the topic: I think the Lazarus project could SELL products like > this: > http://shop.canonical.com/product_info.php?products_id=648 > > Ubuntu also has a service called "Ubuntu Advantage" which gives > advantages to enterprises that choose to pay a fee, like a network admin > tool, a 24/7 support phone line and access to an exclusive online > knowledge base "written and audited by senior engineers". I do not know > what kind of "advantages" the Lazarus/FPC team could offer, but it is a > valid business model. Like http://www.lazarussupport.com/lazarus/Support ;) ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] News on Delphi x64
Am 04.11.2010 09:23, schrieb Sven Barth: > Am 04.11.2010 03:29, schrieb Paul Breneman: >> I've recently been doing more TP 6 programming for some embedded >> systems. TP 6 still works nice but I'd prefer to have all of the Free >> Pascal features... > > What exactly stops you from using Free Pascal? (I'm curious sometimes :P ) Maybe the embedded system is 16 bit? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 27.10.2010 15:18, schrieb Graeme Geldenhuys: > Op 2010-10-27 14:00, Joost van der Sluis het geskryf: >> Well, as you're such a bug Git fan. And you want a better >> debugging-environment >> >> Just checkout the archer/gdb project, you can find it at: >> >> git://sourceware.org/git/archer.git > > That is a half-baked mirror of their primary CVS repository (from what I > can see). I see. One has apparently to throw away all the old history to have a full baked git. Even more a no go for FPC and probably lazarus as well. > That repository doesn't use any features of Git, so what did you > expect. What features do they not use? At least they use heavily feature branches. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 27.10.2010 15:12, schrieb Graeme Geldenhuys: > Op 2010-10-27 15:02, Florian Klaempfl het geskryf: >> >> Graeme just ignores only slightly more complex questions about git >> (typical fanboy behaviour) so don't expect too much. > > Oh piss off! I have work to do. q.e.d. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 27.10.2010 14:00, schrieb Joost van der Sluis: > > But you can create a much better gdb-environment that way. > > Oh, and ... good luck! Graeme just ignores only slightly more complex questions about git (typical fanboy behaviour) so don't expect too much. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 13:19, schrieb Alexander Klenin: > to the current FPC one: [...] > Perl porters managed to overcome most of the problems > (except, of course, language competition) > and seriously invigorate Perl development by > 1) Streamlining release process, so a single person > can do a release in a single day. Ok, then we need first some sponsors for hardware :) We're releasing binary releases and not only a blob of source code. Then we need somebody with deep knowledge about windows, all unixes, OS/2, DOS etc. Further, he needs to know all unix package systems and is able to fix errors in all the different installer information files from inno setup to the home made DOS installer. > It should be noted that FPC problems are worsened > by the lack of tests, Really? What do you miss in the compiler testsuite? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 11:10, schrieb Alexander Klenin: > On Mon, Oct 25, 2010 at 19:52, Marco van de Voort wrote: >> What I haven't seen: >> - the problem > > Lazarus project is unable to do releases in a timely manner. > >> - the solution > > Make a releases time-based, as suggested at the start of the thread. I guess you prepared also a list of people who volounteer to do the boring job of release building? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 11:24, schrieb Graeme Geldenhuys: > Op 2010-10-25 11:12, Florian Klaempfl het geskryf: >> >> So how much do you contribute for the remuneration of the branch manager? > > You understood me wrong, Did you miss again my irony tags? > I was putting my name up for the position of the > branch manager (fat chance that will ever happen), not offering to pay > somebody else. You complained the workflow is flawed, so you should do anything against it. Complaining is easy but it's waste of time to do it again and again if nobody comes up with a practicable solution. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 11:09, schrieb Graeme Geldenhuys: > Op 2010-10-25 10:50, Florian Klaempfl het geskryf: >> >> Let me quote you from a few days ago on fpc-other: > > And did you bother to ask why I do that? I guess you have some cheap excuse like that they didn't accept some patch from your granny. > Past history explains that, and Indeed ... > the currently flawed workflow of the Lazarus project. So how much do you contribute for the remuneration of the branch manager? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 11:05, schrieb Graeme Geldenhuys: > Op 2010-10-25 10:46, Florian Klaempfl het geskryf: >> narrows it down how much branch managing the 1.5M LOC of Lazarus would >> require: almost one full time branch manager. You? Juha? Anyone? > > So where do we discuss remuneration? Just ask the people requesting such a micro- and feature branch based workflow. It seems they think it is worth. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 10:47, schrieb Graeme Geldenhuys: > Op 2010-10-25 10:35, Vincent Snijders het geskryf: >> >> No, there is a limit on the number of branches you - sorry, I mean *I* >> - can overview. For me, two long living branches are already too much. > > Distribute the work-load. The developer working on whatever branches are > responsible for keep it up to date. Why do you think you must do that? All > you (meaning the person maintaining the key public branches like Fixes, > Trunk etc) need to do, is merge those "feature" branch into others. If they > don't merge, revert the changes, email the maintainer of that branch to get > his work in order. > > The key is to delegate! :-) Let me quote you from a few days ago on fpc-other: "I've taken the following stance with the Lazarus team. I contribute, and forget about the patch. They can do with it as they please, I did my part." -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 10:42, schrieb Graeme Geldenhuys: > Op 2010-10-25 10:27, Marco van de Voort het geskryf: >> >> About 6 dedicated paid people (and a whole bunch more volunteers) to manage >> all the branches and review and administrate each patch to reitegrate all >> the various patches into a few production trees. > > Maybe the Linux project was not the best example, because as you say, it > has commercial funding. So rather look at the Git project then. It has many > many branches (though only a select few are made public on a public server > - for end-user convenience). The Git project also has a "stable" branch, an > "experimental branch", a "fixes / maintenance" branch etc. All managed by a > single person (Junio) - not being paid for the job. And that single person > still has time for his own development too. And? Git is only 300k LOC, it requires only a part time branch manager. Fine. The Linux kernel is 12M LOC: six full time branch managers. This narrows it down how much branch managing the 1.5M LOC of Lazarus would require: almost one full time branch manager. You? Juha? Anyone? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release schedule and policy
Am 25.10.2010 09:38, schrieb Michael Van Canneyt: > > > On Mon, 25 Oct 2010, Graeme Geldenhuys wrote: > >> Op 2010-10-25 09:25, Michael Van Canneyt het geskryf: >>> >>> Too much work, because it requires me to know in which branches the >>> features are. >> >> That only occurs if they don't name the branch appropriately. For >> example, >> a branch named 'michaels_work' is useless to anybody else. Compare >> that to >> a branch named 'ide_build_modes' or 'fpdoc_rtf_hyperlink_support'. > > True, but it still requires me to actually know the names. That means > looking them up. > So > > svn update > > is still much shorter and easier. > Real lazy people like me do an svn up only or have even an u script :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 17.09.2010 13:33, schrieb Michael Schnell: > On 09/17/2010 11:48 AM, Juha Manninen (gmail) wrote: >> On Friday 17 September 2010 11:47:12 Florian Klaempfl wrote: >>> Same can be said about goto and labels. Very intuitive and simple why >>> bother about while, for, repeat loops? >> Well, it is a valid comparison. I remember reading about new syntax in >> some >> languages. One is a "future variable" which you calculate in one place >> and >> then use later. Actually the compiler creates a thread for the >> calculation and >> does "waitfor" when the result is used first time. Cool! >> >> Another was the "parallel" keyword for loops. Cool as well! >> >> > > Since long I am raving about "Thread Events". (You might find some posts > about this in the backlog of this list.) > > Those are supposed to be procedural properties of objects. Currently > those simply are called. When used as "Events", the Object calls them > when appropriate and they are assigned to procedures by some code > outside of the object. Thus they are used as "Callbacks". > > This concept can be enhanced by assigning a thread to such an event with > any call of same and execute the called procedure as this thread. Of > course the function results and var parameters of such a beast would > automatically be "futures" > > This would make threads easy to create and use for the programmer, but > of course it would not at all handle the potential complexity problems > regarding mutual access, indeterminated code sequencing, and debugging. > This is imo the real challenging part, besides mechanisms to abort threads. Especially because using the current mechanisms of synchronication, it is very hard to read multithreaded programs. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 17.09.2010 11:26, schrieb Graeme Geldenhuys: > On 17 September 2010 11:11, Florian Klaempfl wrote: >> >> This is your personal opinion. I don't consider it as sarcasm but as >> truth. The current models of threading are imo simple flawed and need >> major improvements, maybe even a new programming paradigmas to be usable >> in programs in a robust and readable way. > > Well, what are you waiting for? For a good approach. I'am collecting and reading papers etc. about this topic for years. We need a quantum step in this regard as the structured programming was compared with spaghetti code. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 17.09.2010 11:00, schrieb Graeme Geldenhuys: > On 17 September 2010 10:47, Florian Klaempfl wrote: >> >> Same can be said about goto and labels. Very intuitive and simple why >> bother about while, for, repeat loops? > > Please keep such sarcasm This is your personal opinion. I don't consider it as sarcasm but as truth. The current models of threading are imo simple flawed and need major improvements, maybe even a new programming paradigmas to be usable in programs in a robust and readable way. > to yourself, or as a private message to the > individual. Got list moderator? > They don't contribute to the discussion and just bog up > everybody's inboxes. Just use an filter. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 17.09.2010 10:29, schrieb Juha Manninen (gmail): > BTW, TThread class has a good and intuitive interface, IMO. A new language > syntax for parallelism would be nice but it wouldn't make any fundamental > difference. Start a thread and call WaitFor later. How much easier can it be? Same can be said about goto and labels. Very intuitive and simple why bother about while, for, repeat loops? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] parallel loop: was Threads in Lazarus code base
Am 15.09.2010 16:09, schrieb Mattias Gärtner: > Zitat von Florian Klaempfl : > >> Am 15.09.2010 15:26, schrieb ik: >>> >>> >>> On Wed, Sep 15, 2010 at 15:16, Florian Klaempfl >> <mailto:flor...@freepascal.org>> wrote: >>> >>> Am 15.09.2010 13:56, schrieb Michael Schnell: >>> > My impression is that regarding the OS-interface of a program that >>> needs >>> > the said features (multiple "logical threads", performance, >>> latency, >>> > making use of modern SMP systems, ...), threads are a >>> necessity. But >>> > programming languages might be able to in many cases hide the >>> dirty >>> > details from the programmer (e.g. "parallel" loops, see the Delphi >>> Prism >>> > and/or .NET documentation on these issues.) If FPC could be >>> enhances tn >>> > that direction it might be a decent improvement. >>> >>> The parallel loop solves nothing which makes threading hard and >>> is only >>> a cheap excuse. The real problems of threading are >>> synchronization and >>> especially abording threads e.g. triggered by the main thread. >>> >>> >>> So how do you do multiple sub routines "at the same time", or some tasks >>> that will hang your system but you require it to function even when it >>> does the heavy work ? >> >> It depends on the application. But as I said before: aborting something >> like a parallel loop because the user pressed e.g. ESC isn't easy either. > > It's not that hard either. Well, it depends how much resources must be freed, how "snappy" the abording should be etc. If the parallel threads need also locking, it gets ugly imo. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 15.09.2010 15:26, schrieb ik: > > > On Wed, Sep 15, 2010 at 15:16, Florian Klaempfl <mailto:flor...@freepascal.org>> wrote: > > Am 15.09.2010 13:56, schrieb Michael Schnell: > > My impression is that regarding the OS-interface of a program that > needs > > the said features (multiple "logical threads", performance, latency, > > making use of modern SMP systems, ...), threads are a necessity. But > > programming languages might be able to in many cases hide the dirty > > details from the programmer (e.g. "parallel" loops, see the Delphi > Prism > > and/or .NET documentation on these issues.) If FPC could be > enhances tn > > that direction it might be a decent improvement. > > The parallel loop solves nothing which makes threading hard and is only > a cheap excuse. The real problems of threading are synchronization and > especially abording threads e.g. triggered by the main thread. > > > So how do you do multiple sub routines "at the same time", or some tasks > that will hang your system but you require it to function even when it > does the heavy work ? It depends on the application. But as I said before: aborting something like a parallel loop because the user pressed e.g. ESC isn't easy either. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads in Lazarus code base
Am 15.09.2010 13:56, schrieb Michael Schnell: > My impression is that regarding the OS-interface of a program that needs > the said features (multiple "logical threads", performance, latency, > making use of modern SMP systems, ...), threads are a necessity. But > programming languages might be able to in many cases hide the dirty > details from the programmer (e.g. "parallel" loops, see the Delphi Prism > and/or .NET documentation on these issues.) If FPC could be enhances tn > that direction it might be a decent improvement. The parallel loop solves nothing which makes threading hard and is only a cheap excuse. The real problems of threading are synchronization and especially abording threads e.g. triggered by the main thread. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus platform "popularity contest"
> No "ET, phone home" thingy > without approval of the user ever. And even then you'll have to be > very careful about what you want the system to report back. > As explained, for me there is no need for such a thing, I wouldn't listen to it anyways. The same way as I don't listen to teasers like "if you do this or that, fpc will get really usefull and great or whatever". -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus platform "popularity contest"
Am 12.08.2010 10:14, schrieb Ger Remmers: >> Very true, but it /is/ in your interest to make sure that the developers >> are aware, in some structured way, what facilities you're using. >> > > I understand what you are saying, but no, it's none of Florians business > (sorry Florian) to know what I'm using Yes, and the same way I usually don't care what users want (use it or use it not), but I develop what I want :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus platform "popularity contest"
Am 11.08.2010 21:46, schrieb Ger Remmers: > On Wednesday 11 August 2010 07:07:21 Mark Morgan Lloyd wrote: >> Bernd Kreuss wrote: >>> On 10.08.2010 22:29, Mark Morgan Lloyd wrote: I don't know how anybody else feels, but I'd have no objection to a "popularity contest" extension which submitted anonymous platform details >>> >>> This would be cool! Maybe even FPC itself could create these statistics. >>> Something like this with really big numbers (after aggregating all >> >>> users) would look quite impressive: >> I have to say that I don't know how to write this sort of thing, either >> from the point of view of Lazarus or from the point of view of making it >> acceptable to users rather than looking like intrusive spyware. >> >> But I think the really useful thing, far more than just aggregating >> number of lines of code, would be picking up when somebody tried to >> compile either Lazarus itself or an app for a specific CPU/OS/widget >> set, including cases where that combination failed. >> >> How many people get Lazarus (on any platform) and try it out without >> joining the mailing list or commenting on a project forum? Of these, how >> many drop it because they have a problem compiling a project? How can we >> find out where the problem areas are, without getting feedback from >> these anonymous users? >> >> If we had- for example- aggregated statistics for "This copy of Lazarus" >> on one of the about tabs, how could we also roll in e.g. somebody >> attempting to build Lazarus from the command line (make clean bigide) >> who found it didn't work because he'd got the wrong version of the KDE >> libraries (been there done that)? > > To be brutally honest, I don't like any form of "ET, phone home" things in a > program. > > Why not? > Because it is nobodies business [how / if / what for] I or anybody else uses > the compiler. I agree with this. But we've to life with its downsides: We've no clue in what directions the compiler should be pushed. The mailing or bug lists are a bad indication for this: just imagine 90% of the users use a certain compiler package but never have problem with it, so no bug reports and no mailing list posts. So we decide, ok, let's dump this particular release type/package, it seems nobody is interested in it. It boils down to: you usually hear only form unsatisfied customers and seldomly from the satisfied. > It has been put out there as open source, no strings attached. Actually free software ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus platform "popularity contest"
Am 12.08.2010 08:55, schrieb Felipe Monteiro de Carvalho: > On Tue, Aug 10, 2010 at 6:21 PM, Mark Morgan Lloyd > wrote: >> Does anybody have any current figures as to the relative popularity of >> Lazarus on different CPUs and OSes? > > There you go, I have put the Source Forge statistics in a table: > > http://wiki.lazarus.freepascal.org/User:Sekelsenmat#Lazarus_and_Free_Pascal_usage_statistics_from_Source_Forge > > The only surprise for me was Nintendo DS. wow, it has a lot of > downloads, and then people didn't upgrade much to the latest FPC. > It > seams that development for game consoles also attracts a huge number > of developers, but those consoles only live a couple of years, so when > they become obsolete you need to start over. SF is only a small part of FPC's downloads. The fpc master ftp has approx. 25,000 downloads (less in summer) of fpc-2.4.0.i386-win32.exe per month. So approx. 300,000 per year and this is only one mirror. So the reason for the high Nintendo DS download number might be that some webpage/blog/wiki with a FPC Nintendo DS howto links directly to the SF page and thus the statistics gets wrong. About the Mac OS X "market": well, fpc-2.4.0.intel-macosx.dmg has 300 to 400 downloads per months. Numbers can be found at: http://www.hu.freepascal.org/webalizer -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus installer
Am 28.07.2010 15:39, schrieb Juha Manninen: > Still I had to ask instructions on chat for how to install on Windows, > and without asking it would have gone wrong. Namely I would have chosen > "fpc-2.4.0.source.zip" instead of "fpcbuild-2.4.0.zip" when I wanted FPC > sources. Lazarus comes with FPC sources? > > The goal should be a one-click installer for anyone who wants to try > Lazarus. Just get http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Lazarus%200.9.28.2/lazarus-0.9.28.2-fpc-2.2.4-win32.exe/download ? Of course, if you want bleeding edge code, this is more difficult, but this is always the case. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: > On 07/01/2010 11:15 AM, Florian Klaempfl wrote: >> ... which does not mean that it fits into the Pascal philosophy. > Of course it does not. That exactly was my point. So it's pretty clear that a C front end does not change much. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: > On 07/01/2010 10:00 AM, Florian Klaempfl wrote: >> Even if FPC supported such a mess, this won't solve the fundamental >> problem with C headers: they work only properly if every used header is >> compiled for each source file again > > Yep. Thats a fundamental philosophy of C. In fact there is a compiler > flag with gcc to compile all files of a project as if there were a > single source: simulated includes instead of linking.In fact there are C > compilers that don't support linking at all and just compile a source > file (with includes) directly to an executable. > > Using headers is strictly optional (and of course the .h extension is > not forced), but the _convention_ is to move commonly usable "external" > "typedef" etc stuff into header files. There is no dedicated syntax for > this. > > (Free )Pascal, OTOH, provides syntax for doing units with an "interface" > and provide using the "precompiled" interface definitions. Less flexible > but more structured and faster than the C way. > >> so the whole unit concept of object >> pascal has to be thrown away. > That its why a "per unit base" could be more suitable and easier to do. > The C units would use C header files and a GNU compatible preprocessor. > A FP-propriety interface part would be added to the C units to make them > create an FP compatible compiled unit, usable in the normal way by > Pascal units and by the linker. ... and not fully automatable, so not better than current solutions. Even worse, it does not cover the cases which are really a problem like #define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the UNICODE define in windows headers #include Things like this are the really nasty corner cases which make h2pas only semi automatic. Show me a tool which translates C headers fully automatic in *usable* pascal units (test case e.g. glibc and mysql), then we can continue this discussion. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: > On 07/01/2010 10:51 AM, Marco van de Voort wrote: >> Ask yourself why GCC doesn't have preprocessed headers, > I supposed you mean "precompiled headers" and not "headers that are > passed through the preprocessor. > > This is according to what I called the "C philosophy" in the other mail. > Even if this philosophy is simplistic and introduced by need rather than > by science, it _is_ consistent and workable. ... which does not mean that it fits into the Pascal philosophy. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Henry Vermaak schrieb: > On 01/07/10 09:57, Marco van de Voort wrote: >> >> Yes, and this is why gcc and most other C compilers have a totally manual >> build systems, where you have to manually specify depedancies, so the >> compiler can figure out what to recompile. > > I just use gcc -MMD in my Makefiles, which generates the dependencies > for me. This works for your headers if you take care of them and it already breaks if you mess with conditional #includes (which must be covered by a fully automated solution). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb:
> On 07/01/2010 08:26 AM, Marco van de Voort wrote:
>> Since accessing header files is repeated as possible advantage files
>> again
>> and again,
> In fact I already missed sadly a fully working preprocessor (to be
> activated optionally).
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again so the whole unit concept of object
pascal has to be thrown away. So using a fully automated always working
approach you've go back to {$I ...}-style imports. Even ignoring the
fact that the real value of a half automated translated header is that
someone spent some brain into the translation and how it can be done in
a pascal styled way.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: > On 06/30/2010 10:31 PM, Florian Klämpfl wrote: >> This can be done already using compilers supporting these languages > As discussed multiple times it's not possible to share classes between > FP-Pascal and GNU-C++. I don't know it it's possible at all to share > classes between Pascal and C++, even if FP would be enhanced to compile > C++ code. Only as a cppclass because the Object Pascal class modell is very different from that one of C++. But don't underestimate the work to do so: there is nothing to reuse so far. It needs a C++ front end and a C++ back end. Everybody dreaming of something like this might start with the "cppclass" support in FPC and create the back end part first. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: > On Wed, Jun 30, 2010 at 10:53:39PM +0200, Michael Van Canneyt wrote: >>> ... because it increases the maintainance work on fpc. Even with one >>> front end only we are almost unable to keep the issue count under >>> control. I'am pretty sure that more front ends will be rejected without >>> more people working on bug fixing in fpc. >> Exactly. We can barely cope as it is. If we compiled C as well, we'd get >> bug reports about glibc or whatever C library fails to compile. no thanks. >> >> And, frankly, the project is called "Free Pascal" for a simple reason: >> it is a *Pascal* compiler and a *Pascal* project. > > I'm sorry. Can't agree with that. > > I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both > parsing, modulesystem and language type) that one could regard it as a > dialect. Aren't you against a e.g. .Net backend because it requires a completely different runtime :)? I think the same applies to M2 etc. as well? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Adem schrieb: > On 2010-07-01 00:20, Florian Klämpfl wrote: >>> Same here: What's wrong with considering, say, a new language >>> back-end (or front-end) much like a new CPU-support? >> As Michael said, it is called "Pascal". Supporting a new CPU does not >> change this. Adding a C/Oberon/Modula whatever front end simply does >> not fit into this scope besides the fact that there is not the >> slightest advantage in doing so. > I am not sure about the 'slightest advantage' aspect: I thought MS sold > the .Net thing mostly on the premise of 'write in the language you're > most comfortable yet share with others you/they find useful'; Exactly, "sold". It's marketing speech. You could use any language but only to a degree of maybe 95%. So everybody decided to use C#. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New website www.lazarussupport.com launched
Marco van de Voort schrieb: On Sun, Jun 20, 2010 at 02:26:20PM +0300, Adem wrote: Speaking of pedanticism: Cheetah live only in a small portion of the world [see http://upload.wikimedia.org/wikipedia/commons/6/63/Cheetah_range.gif ]. FPC/Lazarus, OTOH, isn't so restricted. Shouldn't the mascot be a member of Canidae family --coyote, volf, jackal, fox or preferably a dog. If you find one that runs faster than a Cheetah, I don't see why not. Because afaik that analogy was why Florian selected the Cheetah, fast compilation times and the like, not origin. Some years ago, somebody made an FPC cheetah in svg, maybe it's a compromisse, see http://svn.freepascal.org/svn/html/pic/running_cheetah_dan_gerh_01.svg -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New website www.lazarussupport.com launched
Hans-Peter Diettrich schrieb: > "Florian Klaempfl", not Actually Klämpfl, today, most websites use UTF-8 so writing ae instead of ä is usually not needed anymore. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Installing FPC/Lazarus on Windows using SVN, no binaries
waldo kitty schrieb: > On 6/7/2010 11:11, Mattias Gärtner wrote: >> Zitat von Marcos Douglas : >> >>> On Mon, Jun 7, 2010 at 11:22 AM, Marcos Douglas wrote: Rigth. But the 'make install' do not override these files? If not, then is better delete all .ppu files in all directory? >>> >>> I deleted all ppu files. Now I have another error: >>> >>> C:\freepascal\lazarus>make all OPT="-glw2" >> >> Always try "clean": >> >> make clean all OPT="-glw2" > > i've been noticing that it seems that locating that Contnrs unit is a > real buggar... This has nothing to do with contnrs in particular. It seems contnrs is only the first unit being searched and thus not found if your fpc setup is broken. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Suggestion again: remove GTK1 from IDE and LCL
Graeme Geldenhuys schrieb: > On 3 June 2010 23:15, Marc Weustink wrote: >> GTK1 wont get removed. > > > And it won't be maintained and it won't work anymore. I don't see your > logic, sorry. Who knows? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] easy cross-platform compiling??
Graeme Geldenhuys schrieb: > On 1 June 2010 02:56, waldo kitty wrote: >> hopefully one day >> it will be as simple as installing the base product and then simply ticking >> all of the other platforms you want to compile for and at the end, you end >> up with a binary for each of those chosen platforms (ie: tick several, hit > > Then take a look at RealBasic - that is exactly how they do it. Tick > the platforms and click Build. How they actually accomplished this > feat is another story. :) Four platforms (macosx universal is not an own) is doable. An FPC installer for four platforms might be 100 MB and when one gets >100 Eur or US-$, one can also waste the bandwidth and disk space for such a package or when one expects to sell 100 of these packages to waste one month of time to implement flawless on the fly compilation of the cross packages if needed. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Adem schrieb: > On 2010-05-31 14:57, Florian Klaempfl wrote: >>> But, the parser does produce a parse tree, doesn't it. >> FPC doesn't produce a parse tree during compilation. The parser puts >> declarations/definitions immediatly into the symtables, for code an >> intermediate representation is created which is indeed a tree but no >> more a parse tree because statements might already be transformed. >> > So, if I understand this right, the code is parsed but instead of > producing a tree, a more directly usable structure is created. > > Now, the question is, can it be made to produce (in parallel with what > it already does) a tree to be used elsewhere? Of course this could be done but we are now at the point were the discussion started: if somebody adds new features and doesn't update this alternate path/code to produce this tree, the situation is the same as currently. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
>>> Yet, as far as parser goes, it is the best solution. Because it is the >>> originial source of information. Any new additions as well as >>> corrections go in there -- >>> >> This is not necessarily true. Someone might hack in support for a new >> procedure specifier. However, it is not guranteed that this one would be >> exposed in any way to an external interface. >> > But, the parser does produce a parse tree, doesn't it. FPC doesn't produce a parse tree during compilation. The parser puts declarations/definitions immediatly into the symtables, for code an intermediate representation is created which is indeed a tree but no more a parse tree because statements might already be transformed. >>> it can also reorganize some comments in such constructs. >>> >> The compiler simply discards comments and it has no infrastructure to >> link comments in any way to code. >> > Naturally, comments are no good for the compiler --so, I am assuming > that the current parser does recognise comments but does not add them to > the parse tree; if so, it is fine, all it will have to do is to add > those nodes while the compiler still ignores them. Would that be too > difficult to add? > No idea, at least I expect a lot of pitfalls. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Adem schrieb: > On 2010-05-31 05:36, Doug Chamberlin wrote: > > Doug, > >> I have great interest in a parser-based code formatting tool. However, > I have doubt that using the compiler's parser is the best solution. > > It may not be the best solution basically bexause it was written solely > for the compiler's needs. IOW, a very customized, special purpose one. > > Yet, as far as parser goes, it is the best solution. Because it is the > originial source of information. Any new additions as well as > corrections go in there -- This is not necessarily true. Someone might hack in support for a new procedure specifier. However, it is not guranteed that this one would be exposed in any way to an external interface. > if something then begin > something; > end else begin > somethingelse; > end; > > it can also reorganize some comments in such constructs. The compiler simply discards comments and it has no infrastructure to link comments in any way to code. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Hans-Peter Diettrich schrieb: > Florian Klaempfl schrieb: > >> I doubt this, just one example: ptconst.pas: it parses typed >> constants. Due being tailored for the compiler, it reads the constants >> and writes them without any second pass to the output assembler list. >> A generic parser needs to create first some kind of parse tree and >> this parse tree needs to be outputted in a second pass. > > This is what virtual methods are good for. Yes, one can always hack around such things but in general I'am very pessimistic that using the fpc parser is possible without too much drawbacks on the compiler and compiler development. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Hans-Peter Diettrich schrieb: > Michael Van Canneyt schrieb: > >> Well, given the recent breakage because of the support for 'deprecated', >> I started on a test file, but I think that a better and more fundamental >> approach is needed. My idea was to create a large number of small files >> with code fragments. The test application reads the fragments and puts >> them in a unit (interface/implementation) and attempts to scan/parse it. >> After that, it's just a matter of creating the code fragments. > > A nice idea, but what about verification of the result? Not getting > exceptions is not necessarily a sign of a properly working parser, with > decent error recovery. This is even not guranteed for the compiler parser ;) I discovered recently that fpc eats the following nonsense: label 1234; begin 4321+1234: end. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Hans-Peter Diettrich schrieb: Michael Van Canneyt schrieb: Using the parser/scanner from the compiler is an impossible task, they are impossible to separate. There's nothing impossible in software ;-) Yes, but within a reasonable time and without other penalties :) It's a matter of refactoring, and whether the refactored code will be accepted by the FPC team. If it's good I'am sure it will be accepted, but I expect this to be a work of years. First expected rejection argument: it slows down compilation... A weak argument so far, perhaps we can make the parser even faster? I doubt this, just one example: ptconst.pas: it parses typed constants. Due being tailored for the compiler, it reads the constants and writes them without any second pass to the output assembler list. A generic parser needs to create first some kind of parse tree and this parse tree needs to be outputted in a second pass. One does so and we release a compiler with this and then the people pop up, crying that their pascal files with millions of lines of typed constants don't compile anymore or compiles for ages because memory requirements of the compiler heavily increased. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Hans-Peter Diettrich schrieb: Florian Klaempfl schrieb: BTW: We had this discussion ten years ago already when fpdoc was made and it was decided to write a separate parser after failed attempts to use fpc's frontend. Just a question: AFAIR at that time the parser was an automaton, created by some lex/yacc port. At that time I also gave up to make the parser usable for documentation or other purposes. But when this is no more true, the discussion could be resurrected? No. yacc was never used seriously, the usage of flex was removed mid 90's. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Mattias Gaertner schrieb: > On Fri, 28 May 2010 20:50:15 +0200 > Florian Klaempfl wrote: > >>> It is the only way the code formatter can keep up with new features of FPC. >> FPC isn't moving that fast nowadays regarding syntax so keeping up >> shouldn't be that hard. > > Maybe not in the last month, but it definitely got in the last year a > lot of new keywords and syntax. For example: > foreach, generics were extended, objcclass, objprotocol, objccategory, > nested classes, some new modifiers were added True, but the years before we were really slow ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
dmitry boyarintsev schrieb: > On Fri, May 28, 2010 at 11:06 PM, Adem wrote: >> Would I have your blessing if I proposed a bounty to unentwine them so that >> each one of those major modules becomes objects in tehir own right >> --commnicating with one another through public/published events and >> properties. >> >> I can guess that it would be hard to do, but I feel it will be absolutely >> impossible without your (and the rest of compiler team's) blessing. > > I can see another benefit of separating parser/tokenizer from code > generation. Separating code generation is easy. The bigger problem is the symtable information: fpc uses symbol information while parsing and generating the parse tree for better error checking and for simpler and faster parsing. Further, the compiler is a really complex piece of software so we don't want to be hindered by exposing functionally too much, this would make the oil tanker a continent. BTW: We had this discussion ten years ago already when fpdoc was made and it was decided to write a separate parser after failed attempts to use fpc's frontend. > Is easier and better support of newer targets. I'm talking > about long wished LLVM, and even possibly Java and/or .NET. (No need > to support all possible features, but generate their native > byte-code). > So far, the internal structure of the compiler is the **only** > obstacle (caused by lack of manpower, actually) > > thanks, > dmitry > > -- > ___ > Lazarus mailing list > Lazarus@lists.lazarus.freepascal.org > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
> Would I have your blessing if I proposed a bounty to unentwine them so > that each one of those major modules becomes objects in tehir own right > --commnicating with one another through public/published events and > properties. 15 years ago I had similiar dreams. Within the last 15 years I learned that a compiler is something different: one does a clear design and then a border case pops up (followed by more) which kills this design. I wrote a lot of other software during this time but nothing is comparable in this regard with a compiler. I'am pretty sure not only FPC has this problem, gcc has it as well (just look at the sources) and considering the trouble Borland, CG etc. have to create a 64 bit delphi compiler hints that they might have the same problem. So I simply don't think that this can be achieved in a reasonable time. IMO the effort to do so should be spent in existing pascal parsers. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
> I found a Oil Tanker more responsive and flexible than some of the > developers here. I know, most git users prefer the development model "fix one, break one". -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using FPC parser/tokenizer for code formatting
Adem schrieb: > >>> But, I am hoping to modify the FPC parser/tokenizer so that instead >>> of it deciding whether to stop, it should do a callback and let the >>> caller decide whether it should stop. >>> >>> Is this likely to be unworthy of the effort? >> No, but it is hard to do in a meaningful way. > Could you (or someone else) point me to the source files of FPC > parser/tokenizer please. > > I can guess that it won't be easy; but if it can be done, I think it > should be. It might be possible but the fpc scanner/parser are rather interwinded with other parts of the compiler, just to name an example: pmodules.pas parses units and programs but controls also code generation and handles symtables etc. for them. > > It is the only way the code formatter can keep up with new features of FPC. FPC isn't moving that fast nowadays regarding syntax so keeping up shouldn't be that hard. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] DBMaskEdit: A small contribuition for Lazarus project.
Graeme Geldenhuys schrieb: > On 28 May 2010 10:45, Florian Klaempfl wrote: >> This is not carved in stone but a good thumb rule. > > So what is the criteria to get a new feature in the "fixes" branch You've to ask the release manager about this ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] DBMaskEdit: A small contribuition for Lazarus project.
Graeme Geldenhuys schrieb: > New features are not allowed in "fixes" branch. This is not carved in stone but a good thumb rule. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Regex and Syntax Highlighting
Florian Klaempfl schrieb: > Florian Klaempfl schrieb: >>> But are they complete/correct ? :-) I know that many editors aren't. They >>> support a basic easy subset and that is it. Stuff like using directive >>> names as variables where allowed, support for & to escape keywords etc. >> A nice test is also >> const >> eof = ^Z; > > .. which makes me wonder if > type > a = array[^A..^Z] of integer;+ > > is valid pascal as well (fpc doesn't like it currently). Oops, without the + obviously. type a = array[^A..^Z] of integer; -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Regex and Syntax Highlighting
Florian Klaempfl schrieb: >> But are they complete/correct ? :-) I know that many editors aren't. They >> support a basic easy subset and that is it. Stuff like using directive >> names as variables where allowed, support for & to escape keywords etc. > > A nice test is also > const > eof = ^Z; .. which makes me wonder if type a = array[^A..^Z] of integer;+ is valid pascal as well (fpc doesn't like it currently). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Regex and Syntax Highlighting
> But are they complete/correct ? :-) I know that many editors aren't. They > support a basic easy subset and that is it. Stuff like using directive > names as variables where allowed, support for & to escape keywords etc. A nice test is also const eof = ^Z; -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.4.2 and Lazarus
Graeme Geldenhuys schrieb: > On 20 May 2010 01:04, Marco van de Voort wrote: >> Do you care about users? Do you volunteer for release engineering? We always >> have a few spots open? > > Is there a list of who does what for each release so we can see what > spots are open? > For a new release http://wiki.freepascal.org/Release_Template needs to be copied and adapted, for 2.4.0 it looked like http://wiki.freepascal.org/Release_2.4.0 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Suggestion: Remove GTK1 support from IDE and LCL.
Graeme Geldenhuys schrieb: > On 15 May 2010 11:02, Florian Klaempfl wrote: >>> is already at 2.30 and LCL-GTK2 still says we only support from GTK >>> 2.4/2.6 yet all modern distros ship with GTK 2.16+ at least. >> Debian Lenny is still at 2.10 afaik. > > I did say "modern distros" didn't I? :-) Debian Lenny is the latest stable Debian release and probably used by a lot of people. I know also a lot of ubuntu machines running 6.06 simply because upgrading is too expensive. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Suggestion: Remove GTK1 support from IDE and LCL.
Graeme Geldenhuys schrieb: > On 15 May 2010 11:13, Florian Klaempfl wrote: >> And what features exactly misses the LCL by taking care of 2.8? > > Read the GTK+ changelogs: htpp://www.gtk.org. > Bug fixes, new features etc... And? When running on a GTK2 2.20 system the LCL benefits from a lot of these changes as well. Only new API functions cannot be used or only with a version check. > there are just too many to list here. I doubt that there are a lot which are really needed. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
