Re: [fpc-pascal] Crosscompile FPC from Win32 to Linux
On 4 June 2010 17:55, Andreas Berger wrote: > I have a stable cgi program running in windows (no libraries - simple > writeln). However, our web host is in linux. Is there a simple way for me to > cross-compile the app? or is it easier to learn how to use linux and do it > there? I saw a page how to crosscompile lazarus, but it seamed very complex. > > P.S. fp.exe lets you select a linux output, but it doesn't work. It's possible, but it's not really simple. Some steps: get cygwin install some stuff like gcc, flex, bison, binutils-source, iconv configure binutils with --target i386-linux and --prefix ~/somewhere open bottle of wine build binutils drink bottle of wine (essential step) binutils will be finished building now and you should have i386-linux-* in prefix/bin build fpc rtl and packages with OS_TARGET=linux, making sure you your new cross binutils are on the path (learn that fpc cygwin.dll isn't compatible with i386-linux-ld, copy dll around and shuffle path) ??? profit! It may be better building the whole compiler for the latest version of cygwin, but I'll see if I can scrape together the necessary files you can drop into your fpc bin directory for this to work (not that many). I managed to get a simple writeln app to cross compile and run on linux. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] random question
On 4 June 2010 15:19, spir wrote: > -1- class wrappers > Are there in stock implementations of class wrappers for primitive types: > such as TInteger, TString, etc? (that would for instance just hold a .value > attr and delegate operations to builtin funcs or procs) This would save me > some work :-) The tiOPF project has those implemented in the tiObject.pas unit. I implemented my own about a year ago, but never really used it in any real-world projects. Lee Jenkins also wrote something similar (VTF - Value Type Framework). tiOPF is on SourceForge. Lee's svn repository is at: http://leebo.dreamhosters.com/VTF My code is somewhere on my hard drive. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Crosscompile FPC from Win32 to Linux
Andreas Berger wrote: > I have a stable cgi program running in windows (no libraries - simple > writeln). However, our web host is in linux. Is there a simple way for > me to cross-compile the app? I haven't ever cross-compiled anything, but here's a start... Looking here: http://wiki.lazarus.freepascal.org/Cross_compiling http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux_2 ...it looks like it may be tricky to do win->linux. I am guessing it is possible... hopefully someone more knowledgeable will give you some tips on this list... and perhaps the wiki will get fleshed out some day. > or is it easier to learn how to use linux and do it there? honestly, this may be the easiest option. If you have ssh access to the web host and an fp compiler is (or can be) installed there, then you could just upload your sources to the host and compile them there. Check out putty or ttssh. Alternately you could just install linux on a machine somewhere, or if that's tricky, install virtualbox with a linux guest and use that. > I saw a page how to crosscompile lazarus, but it seamed very complex. Well, lazarus is very complex, so cross compiling it will be complex. Your program will probably be easier to cross compile if it does not use so many of fpc's and LCL's capabilities and libraries. > P.S. fp.exe lets you select a linux output, but it doesn't work. probably because some other stuff needs to be configured, some of which is noted in the cross compiling wiki instructions above. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] random question
> by declaring the property and pressing Ctrl+C Sorry, I meant Ctrl+Shift+C -- Regards, Vladimir Zhirov ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] random question
spir wrote: > -2- [] operator > How to implement a class that manages this operator (did not find it > in the operator overloading section). Pointer welcome (including to > the implementation of eg TFPList). It seems default properties is what you are looking for. >> type >> TMyClass = class >> ... >> property Items[AnIndex: Integer]: TMyItem read GetItem write SetItem; >> default; Note the "default" keyword, it allows you to access Items like this: >> MyClassInstance[1] instead of >> MyClassInstance.Items[1] You can also use string instead of Integer index, then accessing such property would look like dealing with associative arrays: >> MyClassInstance['first'] or >> MyClassInstance.Items['first'] GetItem and SetItem methods must take the appropriate parameters, and return the appropriate result. You can let Lazarus generate them for you by declaring the property and pressing Ctrl+C while cursor is on the same line with your property declaration. -- Regards, Vladimir Zhirov ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Crosscompile FPC from Win32 to Linux
I have a stable cgi program running in windows (no libraries - simple writeln). However, our web host is in linux. Is there a simple way for me to cross-compile the app? or is it easier to learn how to use linux and do it there? I saw a page how to crosscompile lazarus, but it seamed very complex. P.S. fp.exe lets you select a linux output, but it doesn't work. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[8]: [fpc-pascal] Mozilla XPCOM
Hello FPC-Pascal, Friday, June 4, 2010, 2:50:24 PM, you wrote: >> Not, well, not at least on intention but maybe is the XPCOM which is >> calling pascal code from a different thread :-? XPCOM tells me across >> the documentation to call most of its functions from the main thread, >> but maybe the callback is happening from a different one :-? JM> It doesn't matter that it's called from a different thread, as long as JM> this different thread is also created via the FPC RTL. It is being calledback from the same thread, at least the ThreadID var and the function GetCurrentThreadID returns the same value in the main thread and in the callback functions :-? I think it is time to get windows ASM and Linux ASM and compare them :( or the project will die by my side in non Windows platform :( -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Hello, This discussion is interesting, but it's a meta-discussion that is overwhelming this list due to its sheer volume. So let's please move it to the fpc-other list. Thanks, Jonas FPC mailing lists admin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote: Op 2010-06-04 15:45, Florian Klaempfl het geskryf: of stuff. Of course, a patch breaking existing stuff will be accepted less likely. And yet Embarcadero is ok with breaking compatibility - if it means improving the product. That is also the reason I am still working with D7 at work. Converting 2 million lines because they broke compatibility is NOT funny, and will - in all likelihood - cost us a lot of money. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Graeme Geldenhuys schrieb: Op 2010-06-04 15:45, Florian Klaempfl het geskryf: of stuff. Of course, a patch breaking existing stuff will be accepted less likely. And yet Embarcadero is ok with breaking compatibility - if it means improving the product. Yet core developers from FPC and its "hobby project" can't get over that hurdle?? You might judge on what's improving fpc and what not if you break the border of 500 resolved fpc bug reports. Then you know what average users really want (and not only the criers on mailing lists). The bug tracker is full with examples like: http://bugs.freepascal.org/view.php?id=16618 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpc-pascal Digest, Vol 72, Issue 15
spir wrote: I'm surprised of this, fpc still systematically trying to follow Delphi, after so many years. I can understand that at the beginning the fpc team needed to mostly comply with Delphi, as de facto object pascal standard. But then, fpc could live its own life, possibly taking the best of Delphi's innovations, but not having as main goal to be always running after it. Fpc anyway has done different choices for some features (including choices of non-implementation), so why not having already made the step of declaring fpc a (object) Pascal dialect of its own? First of all, I would like to saty that Pascal needs convergence and compatibility; it must be easy to adapt old code as well as being compatible between compilers. And with only three significant players (if my count is right: Delphi, FPC and GPC) that problem is quite a bit smaller than in the past when countless of companies were producing various dialects. But there is of course another point, moving ahead. One major advantage of FPC is that it gives me all the advantages of C++ (performance, overloading), but none of its weaknesses (manual namespaces, lack of modularity, ugly syntax, questionable security). But the Pascal compilers I used in the 90's did not have that. I am not sure FPC would have been a viable choice today without these additions. So pleasew do not stop innovating! Some problems can be handled by built in dialects, of which FPC have plenty. I am switching between modes a lot, and I often wish they could be merged a little bit. (MacPas and Delphi modes are quite different.) I think my conclusion is that various compatibility modes are important, but I think FPC should rather be an innovative superset of Delphi than a clone that waits for the leader to move. /Ingemar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote: Op 2010-06-04 14:58, Michael Van Canneyt het geskryf: And as for 'improve quickly': - Where are the donations ? - Where are the developers ? As soon as someone pays me my salary to work full-time on FPC: there will be REAL quick improvement; I guarantee it. I have many things I would like to work on. Unicode being on the top of my list. My employer already approved the time I can spend of it (after our current project release, which now seems to have moved to Jan/Feb) Till that time: FPC is a *hobby* project for all core developers. That's the problem. To others it's a vital part of making a living - where it is used in a commercial environment. We have always been very clear about that it is a hobby. I can show you all the mails that were sent carrying exactly that message. I put my job on the line when I suggested our company switch from Delphi to FPC. And if it is just a "hobby" to the core developers, why then so damn strict with accepting improvements (patches, alternative designs etc)? Because we care about FPC and it's features & stability. We are proud of it. I care about my hobby. I care more for my hobby than for my current day job; So yes, I am strict. I want it to be better than e.g. what I produce at work. If we had put in all crazy suggestions we got through the years without caring, I don't think we would stand where we are today. But we didn't. And all that exactly because we care and have clear goals. And let's be correct: if we did crazy things, would you have 'put your job on the line' ? I don't think so. It is exactly because we are so strict, that we can offer something which people can trust and rely on. So actually, currently it's you being dangerous, and we are protecting your job safety. Just because we like our hobby. Now, isn't that cool ? :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
In our previous episode, Graeme Geldenhuys said: > Op 2010-06-04 15:45, Florian Klaempfl het geskryf: > > of stuff. Of course, a patch breaking existing stuff will be accepted > > less likely. > > And yet Embarcadero is ok with breaking compatibility - if it means > improving the product. Yet core developers from FPC and its "hobby project" > can't get over that hurdle?? Sure. If all devels agree that it is an improvement and necessary. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Op 2010-06-04 15:45, Florian Klaempfl het geskryf: > of stuff. Of course, a patch breaking existing stuff will be accepted > less likely. And yet Embarcadero is ok with breaking compatibility - if it means improving the product. Yet core developers from FPC and its "hobby project" can't get over that hurdle?? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
In our previous episode, Graeme Geldenhuys said: > And if it is just a > "hobby" to the core developers, why then so damn strict with accepting > improvements (patches, alternative designs etc)? Hobby doesn't mean we don't care. And it doesn't eliminate a decade (and longer) experience in development, fixing bugs etc. Even if only in parttime. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
In our previous episode, Graeme Geldenhuys said: > > And porting 3rd party delphi code. > > I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free > Pascal. It's not that hard at all, so even if FPC is not very Delphi > compatible, porting will still be much easier than porting from other > languages. Maybe. But the point is that a lot of users think it is more important to really minimize that. > What annoys me most is that there is no clear cut line between > portability and improvements. Sometimes the FPC core developers all > all ok with improvements, and sometimes flatout refuse even minor > improvement (at which point they throw the Delphi Compatibility card). > It's like mood swings. If we catch you guys on a good day, then > things go smooth - but dare we propose something on a bad day, then > all hell breaks loose. Well, situations where there is a possible conflict always requires a comparison of both arguments. That is always a bit subjective. That's why there usually are always several devels in such discussions. > The other problem with Delphi Compatibility is that not even the FPC > team knows which version of Delphi we are supposed to be Delphi > compatible with. That's a moving target. > First TP, then D5, then D7, then a bit from D2007, (1.0.x Delphi mode was aimed at D2-d3, and inbetween there), but keep in mind that is over say 13 years. (17 if you count the TP-only years). Logically also the user base changed versions over such periods. > Compatibility with Delphi is drastically declining, I've not even a clue what you mean with that. IMHO it is still vastly improving. > but still no improved design or other goods ideas are allowed (most of the > time). That is awfully subjective. And I don't agree. > How long are we supposed to wait until you guys finally give up > the compatibility race, and see how flawed (and broken) it is at this > current point in time? I don't see a change coming there. I've learned to never exclude anything long term though. Btw, you are not the first to have such feelings and arguments. I was the same roughly in the period '98-'02 (e.g. I was very opposed to many D4+ features being implemented). The same with the multi platform angle (being very opposed to Kylix too, due to its Linuxisms) This disappeared when I got more experience in Delphi (and the reasons behind these features), and when I had a couple of years of bugfixing under the belt (which causes you to be confronted with earlier, in retrospect, bad decisions) I'm still not fond of Kylix though. Both deviating of the VCL and the extreme linux/x86 centricity made it IMHO a "worst of both worlds". However it was canned before it could be cleaned up. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Op 2010-06-04 14:58, Michael Van Canneyt het geskryf: > And as for 'improve quickly': > - Where are the donations ? > - Where are the developers ? > As soon as someone pays me my salary to work full-time on FPC: > there will be REAL quick improvement; I guarantee it. I have many things I would like to work on. Unicode being on the top of my list. My employer already approved the time I can spend of it (after our current project release, which now seems to have moved to Jan/Feb) > Till that time: FPC is a *hobby* project for all core developers. That's the problem. To others it's a vital part of making a living - where it is used in a commercial environment. I put my job on the line when I suggested our company switch from Delphi to FPC. And if it is just a "hobby" to the core developers, why then so damn strict with accepting improvements (patches, alternative designs etc)? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with. Of course we know: given infinite time, we would support all. Given the limited time we have, we support the stuff we think being important. If you think something else is important: submit a patch like Paul did with the foreach stuff or Alexander Klenin's student with the case of stuff. Of course, a patch breaking existing stuff will be accepted less likely. Oh, and we even have a bit of Kylix in the mix. Compatibility with Delphi is drastically declining, but still no improved design or other goods ideas are allowed (most of the time). Most current Delphi code still compiles. Very little code uses the new features. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] random question
On 04 Jun 2010, at 15:22, Michael Van Canneyt wrote: On Fri, 4 Jun 2010, spir wrote: -1- class wrappers Are there in stock implementations of class wrappers for primitive types: such as TInteger, TString, etc? (that would for instance just hold a .value attr and delegate operations to builtin funcs or procs) This would save me some work :-) No. They are planned. They partially exist for the objectivec import layer. (although they may be semantically different there) They don't exist in Objective-C (and hence not in Objective-Pascal either) Maybe you were thinking about class helpers, but that's something different. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] random question
On Fri, 4 Jun 2010, spir wrote: Hello Pascaleers, -1- class wrappers Are there in stock implementations of class wrappers for primitive types: such as TInteger, TString, etc? (that would for instance just hold a .value attr and delegate operations to builtin funcs or procs) This would save me some work :-) No. They are planned. They partially exist for the objectivec import layer. (although they may be semantically different there) -2- [] operator How to implement a class that manages this operator (did not find it in the operator overloading section). Pointer welcome (including to the implementation of eg TFPList). [] is not an operator. It is a set notation. Or it is used as a notation for selecting elements from an array. But that also is not an operator. -3- List specialization What is actually needed to specialise TFPList or TObjectList, in order for an instance of the new list class to hold as elements instances of a subclass of TObject. (The main purpose for this specialisation is to avoid systematically casting back elements to TMyObject). I guess I only need to redefine the .List or .Items property, but to do what, actually (maybe the main issue jumps back to question -2-)? What you want - no typecasts - needs to be accomplished using generics, see the fgl unit. If typecasts are OK: just look at the contnrs unit, there you have several descendents of the TList class. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] random question
Hello Pascaleers, -1- class wrappers Are there in stock implementations of class wrappers for primitive types: such as TInteger, TString, etc? (that would for instance just hold a .value attr and delegate operations to builtin funcs or procs) This would save me some work :-) -2- [] operator How to implement a class that manages this operator (did not find it in the operator overloading section). Pointer welcome (including to the implementation of eg TFPList). -3- List specialization What is actually needed to specialise TFPList or TObjectList, in order for an instance of the new list class to hold as elements instances of a subclass of TObject. (The main purpose for this specialisation is to avoid systematically casting back elements to TMyObject). I guess I only need to redefine the .List or .Items property, but to do what, actually (maybe the main issue jumps back to question -2-)? Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote: Op 2010-06-04 14:09, Michael Van Canneyt het geskryf: Personally, I fail to understand what people are complaining about. I make my programs with the tools available, and they work damn well. Michael, the thing is that sometimes somebody will come up with a better idea for something - yes we can sometimes think of better ideas/designs than Borland, Embarcadero or Microsoft. They are just developers like we are! But take a simple idea like adding Observer support to the RTL. If you didn't support that idea, and only I proposed it And if we had to go through the same arguments as before, the simple answer would have been that NO it will not be added. EVEN though it will not break any existing code. Then on top of that, you get people proposing stupid ideas like implementing your own RTL simply to add one little feature. Each idea is taken on its merit. And rest assured: core people must sometimes struggle equally hard. It is a price we pay for stability. It is guarded like a hen guards her pullets.. Yes the Observer issue got resolved (hopefully), but such arguments really discourages a developer from outside the core team to propose something in the future. Why must we always struggle with proposals - fighting an uphill battle all the way. Some of us don't give a toss about Delphi compatibility (we are programmers, we can work around such problems), and yet proposals get refused even if it doesn't break Delphi compatibility (simply because Delphi doesn't have that feature to start with), or we caught the core team on a bad day. In the end the FPC project suffers because it couldn't improve as quickly as some of use would have liked, or those developers move on to something else. That there is discussion is a necessity. It takes only 2 people for that. In 15 years of FPC development, I have known only 2 such discussions. I can live with that. Yes, I was not fond of Foreach (I think it's an unneeded construct). I was even less fond of generics. But both made it in the compiler. So no, we're not closed. Each idea is taken on its merit, we take into account many things. If our viewpoint is different from the proposers', we see other (or less) things. But in the end we decide, because we end up doing the work. Implementation is the small part. Maintenance takes a lot of work. And as for 'improve quickly': - Where are the donations ? - Where are the developers ? As soon as someone pays me my salary to work full-time on FPC: there will be REAL quick improvement; I guarantee it. Till that time: FPC is a *hobby* project for all core developers. Many have wives and children. We have never left any doubt on this. As it is, the users cannot even get a foundation organized which would coordinate development. I have offered many times to act as a go-between. But nothing ever comes of it, so: get organized ! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[6]: [fpc-pascal] Mozilla XPCOM
On 04 Jun 2010, at 14:03, José Mejuto wrote: Hello FPC-Pascal, Friday, June 4, 2010, 10:37:42 AM, you wrote: JM> Maybe you are executing Pascal code in threads that have not been JM> started via the FPC rtl? (i.e., not via beginthread nor via JM> tthread.create) That is not supported on Unix platforms. Not, well, not at least on intention but maybe is the XPCOM which is calling pascal code from a different thread :-? XPCOM tells me across the documentation to call most of its functions from the main thread, but maybe the callback is happening from a different one :-? It doesn't matter that it's called from a different thread, as long as this different thread is also created via the FPC RTL. If that's the case is any kind of workaround ? No, it cannot be worked around (other than adding functions to the FPC rtl that you can call *once* from externally created threads to initialise and finalise the FPC thread support for that specific thread, but that has not yet been done). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[7]: [fpc-pascal] Mozilla XPCOM
Hello FPC-Pascal, Friday, June 4, 2010, 2:10:22 PM, you wrote: >> If that's the case is any kind of workaround ? Callbacks are only 4 or >> 5 functions +/- and maybe I can create another thread (in pascal) and >> inquiry this thread to process the data and put result in some kind of >> shared memory block ? MVC> I've been studying the thread problem for years and never found a workable MVC> solution on Unix. So as no "real solution" maybe I can find one shoot solution. When Pascal code is being called from an unknown thread (not aware of it) which is not possible to do ? Can I access local variables non refcounted ? Can I access global variables ? I'm quite sure the real problem is a "lost" of memory pools, refcounters and other internal managed structures but also I'm quite sure others can be accessed safelly. Can you give me a little note about which must not be used at all ? Thank you. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote: On 4 June 2010 13:53, Marco van de Voort wrote: And porting 3rd party delphi code. I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free Pascal. It's not that hard at all, so even if FPC is not very Delphi compatible, porting will still be much easier than porting from other languages. What annoys me most is that there is no clear cut line between portability and improvements. Sometimes the FPC core developers all all ok with improvements, and sometimes flatout refuse even minor improvement (at which point they throw the Delphi Compatibility card). It's like mood swings. If we catch you guys on a good day, then things go smooth - but dare we propose something on a bad day, then all hell breaks loose. The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with. Of course we do: as recent as practically feasible, given time. And yes, we are aware that this is a moving target. If we didn't have this approach, we'd be stuck with TP compatibility, and we'd have a very small community indeed. First TP, then D5, then D7, then a bit from D2007, another bit from D2009 oh, and then this other little bit from D2010. Oh, and we even have a bit of Kylix in the mix. Compatibility with Delphi is drastically declining, but still no improved design or other goods ideas are allowed (most of the time). How long are we supposed to wait until you guys finally give up the compatibility race, and see how flawed (and broken) it is at this current point in time? The compatibility race will never be given up; if you are waiting for that, you will be disappointed. But you can submit patches. Very few patches have been refused till now. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Op 2010-06-04 14:09, Michael Van Canneyt het geskryf: > > Personally, I fail to understand what people are complaining about. > I make my programs with the tools available, and they work damn well. Michael, the thing is that sometimes somebody will come up with a better idea for something - yes we can sometimes think of better ideas/designs than Borland, Embarcadero or Microsoft. They are just developers like we are! But take a simple idea like adding Observer support to the RTL. If you didn't support that idea, and only I proposed it And if we had to go through the same arguments as before, the simple answer would have been that NO it will not be added. EVEN though it will not break any existing code. Then on top of that, you get people proposing stupid ideas like implementing your own RTL simply to add one little feature. Yes the Observer issue got resolved (hopefully), but such arguments really discourages a developer from outside the core team to propose something in the future. Why must we always struggle with proposals - fighting an uphill battle all the way. Some of us don't give a toss about Delphi compatibility (we are programmers, we can work around such problems), and yet proposals get refused even if it doesn't break Delphi compatibility (simply because Delphi doesn't have that feature to start with), or we caught the core team on a bad day. In the end the FPC project suffers because it couldn't improve as quickly as some of use would have liked, or those developers move on to something else. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On 4 June 2010 13:53, Marco van de Voort wrote: > > And porting 3rd party delphi code. I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free Pascal. It's not that hard at all, so even if FPC is not very Delphi compatible, porting will still be much easier than porting from other languages. What annoys me most is that there is no clear cut line between portability and improvements. Sometimes the FPC core developers all all ok with improvements, and sometimes flatout refuse even minor improvement (at which point they throw the Delphi Compatibility card). It's like mood swings. If we catch you guys on a good day, then things go smooth - but dare we propose something on a bad day, then all hell breaks loose. The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with. First TP, then D5, then D7, then a bit from D2007, another bit from D2009 oh, and then this other little bit from D2010. Oh, and we even have a bit of Kylix in the mix. Compatibility with Delphi is drastically declining, but still no improved design or other goods ideas are allowed (most of the time). How long are we supposed to wait until you guys finally give up the compatibility race, and see how flawed (and broken) it is at this current point in time? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] Mozilla XPCOM
On Fri, 4 Jun 2010, José Mejuto wrote: Hello FPC-Pascal, Friday, June 4, 2010, 10:37:42 AM, you wrote: And this is the backtrace. Any idea ? JM> Maybe you are executing Pascal code in threads that have not been JM> started via the FPC rtl? (i.e., not via beginthread nor via JM> tthread.create) That is not supported on Unix platforms. Not, well, not at least on intention but maybe is the XPCOM which is calling pascal code from a different thread :-? XPCOM tells me across the documentation to call most of its functions from the main thread, but maybe the callback is happening from a different one :-? If that's the case is any kind of workaround ? Callbacks are only 4 or 5 functions +/- and maybe I can create another thread (in pascal) and inquiry this thread to process the data and put result in some kind of shared memory block ? I've been studying the thread problem for years and never found a workable solution on Unix. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, spir wrote: On Fri, 4 Jun 2010 13:21:09 +0200 (CEST) Michael Van Canneyt wrote: And to be honest, I think we do a very good job of it. Yes, we don't have 100% compatibility. But no, it's never 100%. But it is certainly good enough to satisfy most people that need it. Hello, Michael! No doubt about this. And I take the opportunity to thank you (and all others) for this great (and huge) project. What I question is the necessity to keep Delphi-compliance now and for ever. And the consequent choice of _not_ making, progressively, a free (object) Pascal dialect, with its own design & principles, style & taste, and so on... (*) Sure, I also understand the great advantage of reusing Delphi code and cloning its libraries, esp. for production code. But after so long, fpc could already have a relevant shared codebase, don't you think? (what by the way GNU PAscal does not have). How old is freepascal already, 10 years? More. 15-16 years. Denis (*) For instance, I have had a look at GNU Pascal, and via this look discovered standard & extended Pascal design. I must say that on numerous points it looks better to me than TP & Delphi choices; standards were obviously very carefully designed. An FP freed of Delphi chains could take the best of this. "Free" also means free ;-) Another point is the terrible library/unit mess, partially inherited from Borland pascal history, partially increased by compiler modes. Very hard to find what one looks for (except maybe if coming from BP). More or less, anything can hide anywhere; and there are variants of any feature; and many are just legacy from the 80's. (I don't even evoke the global namespace.) Severe, radical, cleanup needed, imo. There is no global namespace; there is a per-unit namespace if you care to use it. It existed before the term namespace was coined. But, and this is the main thing: The call for Delphi compatibility is MUCH larger than the call for ISO or Extended ISO pascal. If someone were to submit patches to improve the ISO-Pascal compatibility: no problem, they would be accepted. Once upon a time, we had a gpc mode (which is pretty much what ISO pascal is), but there is no demand for it, so it died a quiet death. Theorizing is nice, but sterile if no-one uses it in practice. And in view of the large Delphi codebase: I think Borland didn't do such a bad job of it. Personally, I fail to understand what people are complaining about. I make my programs with the tools available, and they work damn well. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] Mozilla XPCOM
Hello FPC-Pascal, Friday, June 4, 2010, 10:37:42 AM, you wrote: >> And this is the backtrace. Any idea ? JM> Maybe you are executing Pascal code in threads that have not been JM> started via the FPC rtl? (i.e., not via beginthread nor via JM> tthread.create) That is not supported on Unix platforms. Not, well, not at least on intention but maybe is the XPCOM which is calling pascal code from a different thread :-? XPCOM tells me across the documentation to call most of its functions from the main thread, but maybe the callback is happening from a different one :-? If that's the case is any kind of workaround ? Callbacks are only 4 or 5 functions +/- and maybe I can create another thread (in pascal) and inquiry this thread to process the data and put result in some kind of shared memory block ? -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
In our previous episode, Michael Van Canneyt said: > > To many people inside and outside the FPC team, a high degree of Delphi > compatibility is a must. For a simple reason: reuse of existing Delphi > code, of which there is infinitely more than FPC code. (see e.g. also the number of Delphi compatibility bugs reported. This is quite a high percentage) > Do not forget that component creators must maintain their code for older > version of delphi. That means that they cannot use the 'newer' features > of Delphi anyway and so they don't mind if we don't have all of the latest. > And usage shows that there still is a very large amount of D7 out there, so > it's unlikely to change anytime soon. And porting 3rd party delphi code. > And to be honest, I think we do a very good job of it. Yes, we don't have > 100% compatibility. But no, it's never 100%. But it is certainly good > enough to satisfy most people that need it. Yes. THat is also the big flaw in Graeme's reasoning. The fact that porting will never be 100% perfect is no reason to abandon the possibility completely. This is very visible in 1.0.x vs 2.x. With 1.0.x usage of Delphi code was very low, with 2.x it is much, much higher. A lot of it are relative benign things. But a lot of benign things make porting large codebases difficult. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010 13:21:09 +0200 (CEST) Michael Van Canneyt wrote: > And to be honest, I think we do a very good job of it. Yes, we don't have > 100% compatibility. But no, it's never 100%. But it is certainly good > enough to satisfy most people that need it. Hello, Michael! No doubt about this. And I take the opportunity to thank you (and all others) for this great (and huge) project. What I question is the necessity to keep Delphi-compliance now and for ever. And the consequent choice of _not_ making, progressively, a free (object) Pascal dialect, with its own design & principles, style & taste, and so on... (*) Sure, I also understand the great advantage of reusing Delphi code and cloning its libraries, esp. for production code. But after so long, fpc could already have a relevant shared codebase, don't you think? (what by the way GNU PAscal does not have). How old is freepascal already, 10 years? Denis (*) For instance, I have had a look at GNU Pascal, and via this look discovered standard & extended Pascal design. I must say that on numerous points it looks better to me than TP & Delphi choices; standards were obviously very carefully designed. An FP freed of Delphi chains could take the best of this. "Free" also means free ;-) Another point is the terrible library/unit mess, partially inherited from Borland pascal history, partially increased by compiler modes. Very hard to find what one looks for (except maybe if coming from BP). More or less, anything can hide anywhere; and there are variants of any feature; and many are just legacy from the 80's. (I don't even evoke the global namespace.) Severe, radical, cleanup needed, imo. vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 4 Jun 2010, spir wrote: On Fri, 04 Jun 2010 08:50:06 +0200 Graeme Geldenhuys wrote: Borland and Embarcadero jumps off the cliff - FPC must now also jump off the cliff. :) Hello, Graeme! I'm surprised of this, fpc still systematically trying to follow Delphi, after so many years. I can understand that at the beginning the fpc team needed to mostly comply with Delphi, as de facto object pascal standard. But then, fpc could live its own life, possibly taking the best of Delphi's innovations, but not having as main goal to be always running after it. Fpc anyway has done different choices for some features (including choices of non-implementation), so why not having already made the step of declaring fpc a (object) Pascal dialect of its own? To many people inside and outside the FPC team, a high degree of Delphi compatibility is a must. For a simple reason: reuse of existing Delphi code, of which there is infinitely more than FPC code. Do not forget that component creators must maintain their code for older version of delphi. That means that they cannot use the 'newer' features of Delphi anyway and so they don't mind if we don't have all of the latest. And usage shows that there still is a very large amount of D7 out there, so it's unlikely to change anytime soon. And to be honest, I think we do a very good job of it. Yes, we don't have 100% compatibility. But no, it's never 100%. But it is certainly good enough to satisfy most people that need it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
Op 2010-06-04 12:54, spir het geskryf: > (including choices of non-implementation), so why not having already > made the step of declaring fpc a (object) Pascal dialect of its own? I agree 100%. It was all good and well (in the beginning) to try and be a Delphi clone, but now it makes no real sense to me. FPC (or Lazarus IDE or Lazarus LCL) will never, ever be 100% compatible with Delphi. You will also never be able to simply swap out delphi and replace it with FPC and recompile. Developers will always have to go through a porting process - a fact of life. And if FPC's only goal is to be a Delphi clone, then soon they are going to be out of business - why? Because Embarcadero is already working on a cross-platform compiler (the biggest advantage FPC has(had) over Delphi) and a 64-bit compiler. Embedded systems will be the only advantage FPC then has over Delphi - and this is a small percentage of FPC users. But we all know, many others will disagree with us - saying that staying a clone and always one step behind is good. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On Fri, 04 Jun 2010 08:50:06 +0200 Graeme Geldenhuys wrote: > Borland and Embarcadero jumps off > the cliff - FPC must now also jump off the cliff. :) Hello, Graeme! I'm surprised of this, fpc still systematically trying to follow Delphi, after so many years. I can understand that at the beginning the fpc team needed to mostly comply with Delphi, as de facto object pascal standard. But then, fpc could live its own life, possibly taking the best of Delphi's innovations, but not having as main goal to be always running after it. Fpc anyway has done different choices for some features (including choices of non-implementation), so why not having already made the step of declaring fpc a (object) Pascal dialect of its own? [Note: if ever this topic is a sensible one launching flame wars, just close it. This is not my intention, I'm just asking.] Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] Mozilla XPCOM
On 04 Jun 2010, at 00:23, José Mejuto wrote:
Thursday, June 3, 2010, 6:51:22 PM, you wrote:
JM> Since the RTL is compiled with optimisation enabled, you may
JM> be missing intermediate stack frames. You will have to recompile
JM> it without optimisations to get a full backtrace.
Done, the halt is in fpc code:
---
Function fpc_Catches(Objtype : TClass) : TObject;[Public, Alias :
'FPC_CATCHES']; compilerproc;
var
_Objtype : TExceptObjectClass;
_ExceptObjectStack : PExceptObject;
begin
_ExceptObjectStack:=ExceptObjectStack;
If _ExceptObjectStack=Nil then
begin
{$ifdef excdebug}
Writeln ('Internal error.');
{$endif}
halt (255);
end;
[...]
---
And this is the backtrace. Any idea ?
Maybe you are executing Pascal code in threads that have not been
started via the FPC rtl? (i.e., not via beginthread nor via
tthread.create) That is not supported on Unix platforms.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] compiler / language // ----- sending error
*** Sorry, I sent this post to the wrong list. Hope you find it interesting anyway ... Hello, I just discovered a set of wiki pages about freepascal's compiler: http://wiki.lazarus.freepascal.org/FPC_internals. On can find at http://wiki.lazarus.freepascal.org/Symbol_tables the following table (a bit refactored here). The Symbol table object All symbol tables in the compiler are this type of object, which contains fields for the total size of the data in the symbol table, and methods to read and write the symbol table into a stream. The start of the linked list of active symbol tables is the symtablestack variable. [...] The type of possible symbol tables are shown in the following table: Field Description - --- abstractSymTable(Default value for debugging purposes) WithSymTableAll symbols accessed in a with statement StaticSymTable Contains unit implementation or program symbols GlobalSymTable Contains unit interface symbols ObjectSymTable Contains all symbols within an object/class... RecordSymTable Contains all symbols within a record statement LocalSymTable Hold symbols for all local variables of a routine ParaSymTableHolds symbols for all actual parameters of a routine Stt_ExceptSymTable Contains all exception symbols defined in an except block exportedMacroSymTable Holds all exported macros localMacroSymTable Holds all macros currently in scope enumSymTableContains all enumeration elements symbols of an enumeration Well, this is a rather good presentation of claro! (my own project). Not of its compiler's guts, but of the language structure itself: everything is a symbol table (a "unit" in claro slang). Units are the kind of object/flexible record I discussed a data structure for, in a previous thread. Scopes (including the global "world"), ordinary values (including things=references), their types, methods, formal and actual parameter sets, code elements (meta-level)... really everything is a symbol table. [Note: I thought I was the only one in programming using "symbol" in the (for me proper) meaning of an association between a form & a sense, more precisely here a name:value link. See eg Lisp or Ruby where "symbol" means a name or id, just a special kind of string.] Replacing Lisp's lists by symbol tables, one gets a pretty good idea of claro's guts. This is slightly more complex, also more expressive imo. (But I need plain sequences anyway, so Lisp is indeed more raw, as I won't represent sequences as symbol tables which symbols are ordinals!) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] compiler / language //
Hello, I just discovered a set of wiki pages about freepascal's compiler: http://wiki.lazarus.freepascal.org/FPC_internals. On can find at http://wiki.lazarus.freepascal.org/Symbol_tables the following table (a bit refactored here). The Symbol table object All symbol tables in the compiler are this type of object, which contains fields for the total size of the data in the symbol table, and methods to read and write the symbol table into a stream. The start of the linked list of active symbol tables is the symtablestack variable. [...] The type of possible symbol tables are shown in the following table: Field Description - --- abstractSymTable(Default value for debugging purposes) WithSymTableAll symbols accessed in a with statement StaticSymTable Contains unit implementation or program symbols GlobalSymTable Contains unit interface symbols ObjectSymTable Contains all symbols within an object/class... RecordSymTable Contains all symbols within a record statement LocalSymTable Hold symbols for all local variables of a routine ParaSymTableHolds symbols for all actual parameters of a routine Stt_ExceptSymTable Contains all exception symbols defined in an except block exportedMacroSymTable Holds all exported macros localMacroSymTable Holds all macros currently in scope enumSymTableContains all enumeration elements symbols of an enumeration Well, this is a rather good presentation of claro! (my own project). Not of its compiler's guts, but of the language structure itself: everything is a symbol table (a "unit" in claro slang). Units are the kind of object/flexible record I discussed a data structure for, in a previous thread. Scopes (including the global "world"), ordinary values (including things=references), their types, methods, formal and actual parameter sets, code elements (meta-level)... really everything is a symbol table. [Note: I thought I was the only one in programming using "symbol" in the (for me proper) meaning of an association between a form & a sense, more precisely here a name:value link. See eg Lisp or Ruby where "symbol" means a name or id, just a special kind of string.] Replacing Lisp's lists by symbol tables, one gets a pretty good idea of claro's guts. This is slightly more complex, also more expressive imo. (But I need plain sequences anyway, so Lisp is indeed more raw, as I won't represent sequences as symbol tables which symbols are ordinals!) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WriteComponent not outputting a hierarchy of components?
On Friday 04 June 2010 09:10:28 Graeme Geldenhuys wrote: > > I now understand why Martin implemented MSEgui from the ground up and not > basing any code on Borland's ideas. You never need to fight strange > implementations, other than your own. :) > Although you are right in principle, owner/parent relationship is a bad example because MSEgui uses the default streaming mechanism. :-) I wanted to be able to use forign non visual components in MSEgui and I think the concept is not so bad because there is more flexibility. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WriteComponent not outputting a hierarchy of components?
On Fri, 4 Jun 2010 00:33:18 +0200 Graeme Geldenhuys wrote: > On 3 June 2010 22:55, Mattias Gaertner wrote: > > I other words: There are two tree like structures: Owner and Parent. > > Parent is optional and will make your stream files more readable. > > > >[...] > > > > Readability. > > I can't think that's the reason. D1 thru D5 (or D7) saved dfm files in > binary format. So there was no readability to speak of. Afaik the you had always the possibility to edit the form as text format. The binary format had a few advantages when saving to disk. > Also the only people that actually look (and care) about the dfm/lfm > files are the IDE designers. Normal developers almost never look > inside those files (unless something major screwed up - in which case > they should have made backups). Almost never is not never. I guess almost every developer has looked it it. There is also another reason: The parent property is set before all other. This is important to reduce overhead, especially on the early windows versions. >[...] Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WriteComponent not outputting a hierarchy of components?
Op 2010-06-04 08:41, Michael Van Canneyt het geskryf: > > It is up to you. Both approaches are possible. Like I said, in the LCL it is > TWinControl that does the loop over it's child controls. But you could LCL implements GetChildren in TWinControl, TFrame and TCustomForm. But looking more closely at the code, TWinControl loops over Controls property and TCustomForm loops over Components property. I now understand why Martin implemented MSEgui from the ground up and not basing any code on Borland's ideas. You never need to fight strange implementations, other than your own. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
