Re: [fpc-pascal] Internal linker?
On Fri, 3 Mar 2006, chromdildo wrote: > Hi, > > What about the "new internal linker" ? > Is it already available in the development tree? It is available in the 'linker' branch in SVN. > What has changed? Any documents to read? No documents that I know of. The current status is that the compiler can now work without any external tools: both assembler and linker are internal in the compiler for at least windows. 'make cycle' runs, cross-compilation and linking works, the compiler produces a lazarus binary which is functional AFAIK. I have not seen any timings yet, but I have seen reports that memory usage has been greatly reduced. Peter Vreman has done most, if not all, development on this. He can say more about it than I can. Michael. > > Thanks and best regards. > chrom > > > What is new is that the compiler does all the work for you. > > > > What is still missing, is Win32 support. A DLL is a different beast > > than a shared lib on linux, because it's usually self-contained, > > and because it can't export variables. Mainly, this is package stuff. > > > > The new internal linker should make this possible... > > > > Michael. > > ___ > > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Installation of Lazarus
A small question: The latest version of Lazarus I can find is 0.9.12-0. It requests the use of fpc-2.0.2-0. However, the latest fpc - which I have downloaded - is 2.0.2-3. Therefore Lazarus complains. Do I have to install the older version of fpc? (which means forcing rpm to install the older version) or is there an updated Lazarus or can I trick Lazarus to use the newer version? Thanks in advance. Joep ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freereport and tiOPF
What platform are you developing under? I have only tested tiOPF under Windows and Linux. Regards, - Graeme - On 2/27/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote: > A very excellent news indeed! :D I'm very exciting to know that tiOPF has been > run and compiled using FPC. I'll take a look at it soon. I think this also > would > be nice if mention on FPC/Lazarus wiki (contribution section?). > > Thank you for the great work. I believe the FPC community will really > appreciate > this. :) > > -Bee- > > has Bee.ography at > http://beeography.blogsome.com > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
> Please note that I am advocating Lazarus for the project.. I was > responding to the project leader's (defacto at this point) call for > pros and cons of each language. I and one other gentleman suggested > FPC/Lazarus. I posted here precisely because I do not know what > constitutes a "modern" language. I am not a programmer, just a > chemical engineer who has done a lot of programming (mostly in > Fortran), but who switched to delphi -> kylix -> Lazarus for my own > projects. > This is a community project... no companies are currently involved. > The project is a continuation of an existing codebase which was > written in python. Few of the people want to continue it in Python. > Several want to use C#. Two of us know and love Lazarus. This is exactly like I expected. Still the end conclusion stands. Go with the language of the (group of) people you expect to contribute most. Also be wary of people (in the community) suggesting languages they do not daily use. > The application would involve calculations, database access, and a > graphical user interface (visio like diagramming interface)... for > reference you can look at > http://www.aspentech.com/industry_solutions/oilgas/product.cfm?IndustryID=23&ProductID=274 > (scroll down for screen shot) Ah, Aspen. Yeah, used that during my studies, though not "oil and gas". If you need help with from FPC from time to time, just drop me a note. Would be fun to do something with chemical engineering again. (did it for 3 years before I switched to IT) I also have some experience with numeric calculating in pascal, and inherited a pascal lib of relevant numerical routines from my Uni, so be sure to also run numerical math problems over this list. (it's in packages/extra/numlib, but unfortunately the docs are still untranslated in Dutch. I can pick out specific routines and translate/document them if you need them) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On 3/3/06, Matt Henley <[EMAIL PROTECTED]> wrote: > Several want to use C#. Two of us know and love Lazarus. On Open Source projects the Developer is King. Talking doesn´t matter much, what really matters is the code that is written. If they don´t agree on making it a Lazarus software, ask them to have 2 versions. a C# for windows and a Lazarus one for cross-platform. Talk to them about targets that c# does not reach, like *BSD, Mac OS X, Sparc, etc =) Then work very hard on the Lazarus version. They will soon drop the c# version if favor of the Lazarus one =) -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
Please note that I am advocating Lazarus for the project.. I was responding to the project leader's (defacto at this point) call for pros and cons of each language. I and one other gentleman suggested FPC/Lazarus. I posted here precisely because I do not know what constitutes a "modern" language. I am not a programmer, just a chemical engineer who has done a lot of programming (mostly in Fortran), but who switched to delphi -> kylix -> Lazarus for my own projects. This is a community project... no companies are currently involved. The project is a continuation of an existing codebase which was written in python. Few of the people want to continue it in Python. Several want to use C#. Two of us know and love Lazarus. The application would involve calculations, database access, and a graphical user interface (visio like diagramming interface)... for reference you can look at http://www.aspentech.com/industry_solutions/oilgas/product.cfm?IndustryID=23&ProductID=274 (scroll down for screen shot) Thanks for all the input Matt On 3/3/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > "My personal objective is not just to put out a simulator, but a fast > > and efficient simulator. Furthermore, personally, I do not consider a > > program portable if it is written in a language which very few can > > understand. A modern language such as any of the .NET languages will > > meet the efficiency objective but portability remains an issue. While > > I do have the Visual Studio .NET and I am happy with it, I understand > > that not everybody has it and it is not cheap. I looked at the > > Lazarus project and (at least at a first glance) it is indeed very > > "Visual" and will likely do the job. It will however, limit us to > > Pascal which is not really a modern language. For those of you who > > are in favor of using Lazarus, can you assure the rest of us that > > Pascal has been modernized? " > > IMHO the fatal flaw in this reasoning is that this opinion simply > regurgitates some IT management blurb, and doesn't really tailor a choice of > language to your needs. > > There are three different arguments that I would mention in your response: > > 1) While not nearly as bad as Python, there are potential performance issues > in using managed languages. This is not just raw calculating speed, but also > startup time, memory usage (not unimportant in scientific calculations with > large datasets!). > Worse, doing something about it often means doing speed dependant calculations > in a non managed language in a DLL. So you potentially force contributors to > learn a new language, and later have to partially back out again. > > 2) The only somewhat jusitifyable choice for "modern" programming languages > in the IT sector is hiring. One can debate if .NET and Java are new > generations, or just a glorified old hat, but the main point is that they > _are_ prolific. > > However that is not a 100% simple situation: > - First availability must be seend relative to demand (C# programmers > are the only programmer on the US top 10 most wanted list, J2EE has been so > in recent years). A lot more supply, but also a lot more hiring. > - Also, these languages are mainly business (read DB apps) oriented, and much > less scientifically. Pascal has been a scientific language for years. > - Are you going to be hiring anyway? Otherwise I would inventorise > first which suitable language is most common in your community and choose > that (Pascal, Java, C# or not). It would be stupid to e.g. offend your most > worthwhile potential contributors with a wrong language choice. > > IOW, don't be fooled by a simplistic mantrum, but do the research what > language is most suitable, and what's available in your community. > > (your actual question is pretty much unanswerable till you define "modern") > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RE: Modern Language
It seems to me some people thinks none of language/compiler except coming from Microsoft can be "modern" or "safe" ! I'll restrain myself from saying more. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
Tony Pelton wrote: it is *everything* that Java is, but better. i feel like the hobbyist programmer in me has been reborn AND ... i've actually started to look out into the job market a little, with an eye towards maybe trying to make a jump from being a Java J2EE web application developer to making a jump to doing Pascal development for a day job, if the right opportunity came along. Yet another lost soul wanders out of the C-Language (C, C++, C#, Java, Python, et. al.) forrest and into the fertile fields of Object Pascal. You know, in all my years of using Pascal (starting with Turbo 3.01A in 1986) and Object Pascal (starting with Turbo 5.5 in 1989), I have heard this story on more than one occasion. However, I have never heard a story describing the opposite, ie. a person going from Pascal to a C-Language and having the same epiphany. I've tried to make the transition myself on several occasions, but I always end up coming back to Pascal. Congratulations! Mark ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
> "My personal objective is not just to put out a simulator, but a fast > and efficient simulator. Furthermore, personally, I do not consider a > program portable if it is written in a language which very few can > understand. A modern language such as any of the .NET languages will > meet the efficiency objective but portability remains an issue. While > I do have the Visual Studio .NET and I am happy with it, I understand > that not everybody has it and it is not cheap. I looked at the > Lazarus project and (at least at a first glance) it is indeed very > "Visual" and will likely do the job. It will however, limit us to > Pascal which is not really a modern language. For those of you who > are in favor of using Lazarus, can you assure the rest of us that > Pascal has been modernized? " IMHO the fatal flaw in this reasoning is that this opinion simply regurgitates some IT management blurb, and doesn't really tailor a choice of language to your needs. There are three different arguments that I would mention in your response: 1) While not nearly as bad as Python, there are potential performance issues in using managed languages. This is not just raw calculating speed, but also startup time, memory usage (not unimportant in scientific calculations with large datasets!). Worse, doing something about it often means doing speed dependant calculations in a non managed language in a DLL. So you potentially force contributors to learn a new language, and later have to partially back out again. 2) The only somewhat jusitifyable choice for "modern" programming languages in the IT sector is hiring. One can debate if .NET and Java are new generations, or just a glorified old hat, but the main point is that they _are_ prolific. However that is not a 100% simple situation: - First availability must be seend relative to demand (C# programmers are the only programmer on the US top 10 most wanted list, J2EE has been so in recent years). A lot more supply, but also a lot more hiring. - Also, these languages are mainly business (read DB apps) oriented, and much less scientifically. Pascal has been a scientific language for years. - Are you going to be hiring anyway? Otherwise I would inventorise first which suitable language is most common in your community and choose that (Pascal, Java, C# or not). It would be stupid to e.g. offend your most worthwhile potential contributors with a wrong language choice. IOW, don't be fooled by a simplistic mantrum, but do the research what language is most suitable, and what's available in your community. (your actual question is pretty much unanswerable till you define "modern") ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Internal linker?
Hi, What about the "new internal linker" ? Is it already available in the development tree? What has changed? Any documents to read? Thanks and best regards. chrom > What is new is that the compiler does all the work for you. > > What is still missing, is Win32 support. A DLL is a different beast > than a shared lib on linux, because it's usually self-contained, > and because it can't export variables. Mainly, this is package stuff. > > The new internal linker should make this possible... > > Michael. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
> On Fri, 3 Mar 2006 18:28:40 +0100 (Romance Standard Time) > Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > Most people out there probably think of Pascal as still being in > > the state it was in when Niklaus Wirth first designed it. > > > > Object Pascal to date is fully OOP, and misses nothing that C#, C++ > > or Java has: Interfaces, Exceptions, Classes: you name it, Object > > Pascal has it. > > classes in shared libraries; Since when is this a language feature? It is a implementation feature. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
Thanks for all the replies, i will try to formulate an agrigate response. On 3/3/06, Rodrigo Palhano <[EMAIL PROTECTED]> wrote: > but not losing the focus, Pascal is a very modern language. > > On Fri, 03 Mar 2006 15:29:21 -0300, Micha Nelissen <[EMAIL PROTECTED]> > wrote: > > > On Fri, 3 Mar 2006 19:14:41 +0100 (Romance Standard Time) > > Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > >> > That's simply not true. C++ has multiple inheritance, > >> > >> Solved by interfaces in a much cleaner way. > > > > That doesn't solve the same problem. MI is much more powerful, but also > > much more complex, and easily abused so that code maintainability goes > > *down* instead of up. > > > >> > templates, > >> > >> Agreed, but absolutely not essential. It just saves typing. > > > > That's an opinion, not a fact ;-). > > > >> > classes in shared libraries > >> > >> So does FPC if you so desire ? The RTL can be compiled as a shared lib, > >> and that includes Classes... > > > > This is *very* recent stuff. Is it in 2.0.x yet? Does lazarus work > > properly > > with a shared LCL library ? > > > > Micha > > ___ > > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > > > > > -- > Rodrigo Palhano > - > Equipe SpeedCASE > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
but not losing the focus, Pascal is a very modern language. On Fri, 03 Mar 2006 15:29:21 -0300, Micha Nelissen <[EMAIL PROTECTED]> wrote: On Fri, 3 Mar 2006 19:14:41 +0100 (Romance Standard Time) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > That's simply not true. C++ has multiple inheritance, Solved by interfaces in a much cleaner way. That doesn't solve the same problem. MI is much more powerful, but also much more complex, and easily abused so that code maintainability goes *down* instead of up. > templates, Agreed, but absolutely not essential. It just saves typing. That's an opinion, not a fact ;-). > classes in shared libraries So does FPC if you so desire ? The RTL can be compiled as a shared lib, and that includes Classes... This is *very* recent stuff. Is it in 2.0.x yet? Does lazarus work properly with a shared LCL library ? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Rodrigo Palhano - Equipe SpeedCASE ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On Fri, 3 Mar 2006, Micha Nelissen wrote: > > > classes in shared libraries > > > > So does FPC if you so desire ? The RTL can be compiled as a shared lib, > > and that includes Classes... > > This is *very* recent stuff. Is it in 2.0.x yet? Does lazarus work properly > with a shared LCL library ? I'll stick to facts, and skip opinions, as you rightly point out... This is not recent stuff, I did that back in 1998 already on Linux (the machine called tflily) . Admittedly, it was manual work using ppumove, but it worked perfectly. What is new is that the compiler does all the work for you. What is still missing, is Win32 support. A DLL is a different beast than a shared lib on linux, because it's usually self-contained, and because it can't export variables. Mainly, this is package stuff. The new internal linker should make this possible... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On Fri, 3 Mar 2006 19:14:41 +0100 (Romance Standard Time) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > That's simply not true. C++ has multiple inheritance, > > Solved by interfaces in a much cleaner way. That doesn't solve the same problem. MI is much more powerful, but also much more complex, and easily abused so that code maintainability goes *down* instead of up. > > templates, > > Agreed, but absolutely not essential. It just saves typing. That's an opinion, not a fact ;-). > > classes in shared libraries > > So does FPC if you so desire ? The RTL can be compiled as a shared lib, > and that includes Classes... This is *very* recent stuff. Is it in 2.0.x yet? Does lazarus work properly with a shared LCL library ? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
"multiple inheritance" what for? "templates" is a specific resource, but ok. "classes in shared libraries", delphi does have it. On Fri, 03 Mar 2006 14:57:07 -0300, Micha Nelissen <[EMAIL PROTECTED]> wrote: On Fri, 3 Mar 2006 18:28:40 +0100 (Romance Standard Time) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: Most people out there probably think of Pascal as still being in the state it was in when Niklaus Wirth first designed it. Object Pascal to date is fully OOP, and misses nothing that C#, C++ or Java has: Interfaces, Exceptions, Classes: you name it, Object Pascal has it. That's simply not true. C++ has multiple inheritance, templates, classes in shared libraries; all things which FPC does not have. FPC does have metaclasstypes (and virtual constructors) in the OO area, which C++ does not have. I do consider FPC to be a modern language, FYI ;-). Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Rodrigo Palhano - Equipe SpeedCASE ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On Fri, 3 Mar 2006, Micha Nelissen wrote: > On Fri, 3 Mar 2006 18:28:40 +0100 (Romance Standard Time) > Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > Most people out there probably think of Pascal as still being in > > the state it was in when Niklaus Wirth first designed it. > > > > Object Pascal to date is fully OOP, and misses nothing that C#, C++ > > or Java has: Interfaces, Exceptions, Classes: you name it, Object > > Pascal has it. > > That's simply not true. C++ has multiple inheritance, Solved by interfaces in a much cleaner way. > templates, Agreed, but absolutely not essential. It just saves typing. > classes in shared libraries So does FPC if you so desire ? The RTL can be compiled as a shared lib, and that includes Classes... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On Fri, 3 Mar 2006 18:28:40 +0100 (Romance Standard Time) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > Most people out there probably think of Pascal as still being in > the state it was in when Niklaus Wirth first designed it. > > Object Pascal to date is fully OOP, and misses nothing that C#, C++ > or Java has: Interfaces, Exceptions, Classes: you name it, Object > Pascal has it. That's simply not true. C++ has multiple inheritance, templates, classes in shared libraries; all things which FPC does not have. FPC does have metaclasstypes (and virtual constructors) in the OO area, which C++ does not have. I do consider FPC to be a modern language, FYI ;-). Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
Matt Henley wrote: understand. A modern language such as any of the .NET languages will meet the efficiency objective but portability remains an issue. While I believe the with .Net, you will have the same speed issues that you have with Python since it compiles to CLR and not native machine code. So he is mistaken in his initial premise. Java will have the same issue. Plus, when running a simulation, you don't want the program to suddenly decide it has to do garbage collection, thus slowing down. Any .Net or Java program will have these problems due to their very architecture. What does he consider a "modern language". You can't begin to quell his anxiety or disperse his ignorance until he can give you a definition. Ask for specifics. Is he aware that Lazarus is written in Free Pascal? I would show him Pixel... it is very impressive. Mark ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
Mild Pascal rant: Thank you for considering Pascal. Contrary to popular belief, Pascal is indeed a modern language. Though developed some time ago it has evolved the to include most of the extensions seen in 'modern' languages. It should be noted that modern is not synonymous with recently invented. Pascal is fully OO. Many would say the implementation of OO is better and more complete than C++. Performance is on par with C and C++. Any differences usually related to automatic and predictable garbage collection present in Pascal. Accessing C libraries is also simple. Coming from a long background in large scale application design and management, Pascal has other advantages. The syntax is somewhat simple than C and Java. As well, experience and studies have shown that the same skill and effort applied to a C and Pascal project usually results in about 50% less productions bugs in the Pascal code. FPC specifically has more advantages. First is the active (and somewhat rabid:) development community. It is centered in Europe, where the 'language du jour' does not hold as much sway as it does in North America. Also, there is a large collection of libraries, tools and utilities available. FPC handles many different flavours of the language. It is portable (as is Lazarus) over many operating systems and processor types. It is far more portable than Java and .Net (for different reasons)! A thought-out design of your application can be as fast and portable as you wish. Thank you for considering FPC and good luck with your project. On Mar 3, 2006, at 12:01, Matt Henley wrote: I belong to a mailing list for a defunt open source chemical process simulator (Sim42). Members of the list are now showing interest in restarting the effort. It was originally written in python which cause some speed issues. Several of the list members (including me) suggested freepascal and lazarus. The gentleman spearheading the effort sent the following and I would like to know what is the best way to respond. I do not know what features define a "modern language" and would like to know what points to bring up. "My personal objective is not just to put out a simulator, but a fast and efficient simulator. Furthermore, personally, I do not consider a program portable if it is written in a language which very few can understand. A modern language such as any of the .NET languages will meet the efficiency objective but portability remains an issue. While I do have the Visual Studio .NET and I am happy with it, I understand that not everybody has it and it is not cheap. I looked at the Lazarus project and (at least at a first glance) it is indeed very "Visual" and will likely do the job. It will however, limit us to Pascal which is not really a modern language. For those of you who are in favor of using Lazarus, can you assure the rest of us that Pascal has been modernized? " Thanks for any help Matt Henley ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal P Davidson Corax Networks Inc. http://CoraxNetworks.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a "Modern Language"
On Fri, 3 Mar 2006, Matt Henley wrote: > I belong to a mailing list for a defunt open source chemical process > simulator (Sim42). Members of the list are now showing interest in > restarting the effort. It was originally written in python which > cause some speed issues. Several of the list members (including me) > suggested freepascal and lazarus. The gentleman spearheading the > effort sent the following and I would like to know what is the best > way to respond. I do not know what features define a "modern > language" and would like to know what points to bring up. > > "My personal objective is not just to put out a simulator, but a fast > and efficient simulator. Furthermore, personally, I do not consider a > program portable if it is written in a language which very few can > understand. A modern language such as any of the .NET languages will > meet the efficiency objective but portability remains an issue. While > I do have the Visual Studio .NET and I am happy with it, I understand > that not everybody has it and it is not cheap. I looked at the > Lazarus project and (at least at a first glance) it is indeed very > "Visual" and will likely do the job. It will however, limit us to > Pascal which is not really a modern language. For those of you who > are in favor of using Lazarus, can you assure the rest of us that > Pascal has been modernized? " Most people out there probably think of Pascal as still being in the state it was in when Niklaus Wirth first designed it. Object Pascal to date is fully OOP, and misses nothing that C#, C++ or Java has: Interfaces, Exceptions, Classes: you name it, Object Pascal has it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Object pascal a "Modern Language"
I belong to a mailing list for a defunt open source chemical process simulator (Sim42). Members of the list are now showing interest in restarting the effort. It was originally written in python which cause some speed issues. Several of the list members (including me) suggested freepascal and lazarus. The gentleman spearheading the effort sent the following and I would like to know what is the best way to respond. I do not know what features define a "modern language" and would like to know what points to bring up. "My personal objective is not just to put out a simulator, but a fast and efficient simulator. Furthermore, personally, I do not consider a program portable if it is written in a language which very few can understand. A modern language such as any of the .NET languages will meet the efficiency objective but portability remains an issue. While I do have the Visual Studio .NET and I am happy with it, I understand that not everybody has it and it is not cheap. I looked at the Lazarus project and (at least at a first glance) it is indeed very "Visual" and will likely do the job. It will however, limit us to Pascal which is not really a modern language. For those of you who are in favor of using Lazarus, can you assure the rest of us that Pascal has been modernized? " Thanks for any help Matt Henley ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freereport and tiOPF
A very excellent news indeed! :D I'm very exciting to know that tiOPF has been run and compiled using FPC. I'll take a look at it soon. I think this also would be nice if mention on FPC/Lazarus wiki (contribution section?). Thank you for the great work. I believe the FPC community will really appreciate this. :) -Bee- has Bee.ography at http://beeography.blogsome.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Repository access via the HTTP protocol
Hi, I've let the Apache webserver listen on port 8080 as well. This should hopefully fool proxy servers into believing it's not HTTP, so they pass it through. Could people that had previously problems with HTTP access to SVN on the regular HTTP port, please try http access for SVN with this port, and report on their success ? Just add :8080 to the hostname in the anonymous SubVersion access instructions, and you should be fine. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LongStrings Question
In this case, "constant string" is a character sequense between two ''. If you receive a string value in run-time, all must be OK. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] LongStrings Question
Hi,
I'm using {$LONGSTRINGS ON} to use a string variable like ansistring.
In this example, if I uncomment the s1 variable I got "Error: Constant
strings can't be longer than 255 chars", but if I uncomment the s2 variable
(formed by concatenation of strings) the project compiles perfectly.
program testLongString;
{$LONGSTRINGS ON}
var
s1, s2: String;
begin
// test strings with more than 255 characters
// s1:= '1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 end';
{
s2:= '1 1 1 1 1 1 1
1 1 1 1 1 ' +
'1 1 1 1 1 1 1
1 1 1 1 1 ' +
'1 1 1 1 1 1 1
1 1 1 1 1 ' +
'1 1 1 end';
}
end.
I need use the s1 variable way because I'm receiving in a string a value
read from a BD.
I also tried compile with "-Mdelphi", but the error stills the same.
Thanks in advance,
Evandro Sestrem
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.1/273 - Release Date: 2/3/2006
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On Friday 03 March 2006 12:55, Vincent Snijders wrote: > Jonas Maebe wrote: > > On 3 mrt 2006, at 13:42, Vinzent Hoefler wrote: > >>> BTW, I never would have guessed that the random number generator > >>> would have used threadvars. I would have thought, that on app > >>> start you would set one randseed and then call random from all > >>> threads. > >> > >> Considering that the state array for the Mersenne Twister is an > >> unprotected global variable, calling random from different threads > >> looks like a bad idea to me. > >> > >> I mean, it surely gives you sort of random values, but ... > > > > That's why its state (and indeed not just randseed) should be > > threadvars. > > Or use some locking mechanism. That would be slower, but would safe > some memory. I'd suggest both. :) Objectify the whole Mersenne Twister into a single "class", so that each thread can have it's own PRNG if necessary and provide a single global, but locked instance of it for the System.Random subroutines. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
Jonas Maebe wrote: On 3 mrt 2006, at 13:42, Vinzent Hoefler wrote: BTW, I never would have guessed that the random number generator would have used threadvars. I would have thought, that on app start you would set one randseed and then call random from all threads. Considering that the state array for the Mersenne Twister is an unprotected global variable, calling random from different threads looks like a bad idea to me. I mean, it surely gives you sort of random values, but ... That's why its state (and indeed not just randseed) should be threadvars. Or use some locking mechanism. That would be slower, but would safe some memory. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On 3 mrt 2006, at 13:42, Vinzent Hoefler wrote: BTW, I never would have guessed that the random number generator would have used threadvars. I would have thought, that on app start you would set one randseed and then call random from all threads. Considering that the state array for the Mersenne Twister is an unprotected global variable, calling random from different threads looks like a bad idea to me. I mean, it surely gives you sort of random values, but ... That's why its state (and indeed not just randseed) should be threadvars. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On Monday 27 February 2006 08:41, Vincent Snijders wrote: > BTW, I never would have guessed that the random number generator > would have used threadvars. I would have thought, that on app start > you would set one randseed and then call random from all threads. Considering that the state array for the Mersenne Twister is an unprotected global variable, calling random from different threads looks like a bad idea to me. I mean, it surely gives you sort of random values, but ... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On 27 feb 2006, at 09:41, Vincent Snijders wrote: Some other workaround that comes to my mind is to do something like Randomize; RandSeed := RandSeed * getpid; This worked, cut the initial generation time from about 30 seconds down to under 1, of course right now it's NOT platform independent at all so I will need to enhance it but I like the direction of your thinking, combining randseed with some virtually guaranteed unique value solves the problem. Maybe you use a global variable and just add one for each randseed call. After all the only thing that matters for the randseed, is that it is different. BTW, I never would have guessed that the random number generator would have used threadvars. It doesn't currently. I would have thought, that on app start you would set one randseed and then call random from all threads. Every time you call random, the current randseed is read, some calculations are performed and a new value is stored in the randseed variable. So if two threads call random "at the same time", then both will use the same randseed value and thus return the same random value (in the -current- case that randseed is not a threadvar). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
A.J. Venter wrote: Some other workaround that comes to my mind is to do something like Randomize; RandSeed := RandSeed * getpid; This worked, cut the initial generation time from about 30 seconds down to under 1, of course right now it's NOT platform independent at all so I will need to enhance it but I like the direction of your thinking, combining randseed with some virtually guaranteed unique value solves the problem. Maybe you use a global variable and just add one for each randseed call. After all the only thing that matters for the randseed, is that it is different. BTW, I never would have guessed that the random number generator would have used threadvars. I would have thought, that on app start you would set one randseed and then call random from all threads. Vincent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Polymorphism question
I made a typo which I didn't notice, thanks for the replies.
> On Fri, 03 Mar 2006 04:52:36 -0300, <[EMAIL PROTECTED]> wrote:
>
>> (I sent this mail yesterday but somehow it didn't get trough, therefore
>> a
>> new try)
>>
>> I would like to declare a polymorph class. The class has several
>> properties and it's the read and write specifiers that I want to be
>> virtual abstract. So derived classes override the read and write
>> specifiers. The problem however is that I get an EAbstractError. The
>> property is still considered to be abstract according to the compiler.
>> So
>> what did I wrong? I have added an example below.
>> Is it perhaps not allowed to use this construct? What would then be the
>> best way?
>> Darius
>>
>> <>
>>
>> unit MyTest;
>>
>> {$mode objfpc}{$H+}
>>
>> interface
>>
>> uses
>> Classes, ComCtrls, SysUtils;
>>
>> type
>> TCustomClass = class
>> private
>> //virtual mehods
>> function GetMyProperty: string; virtual; abstract;
>> procedure SetMyProperty(Value: string); virtual; abstract;
>> published
>>
>> property MyProperty: string Read GetMyProperty Write SetMyProperty;
>> end;
>>
>> TMyClass = class(TCustomClass)
>> private
>> FMyProperty: string;
>>
>> function GetMyProperty: string; overload;
>> procedure SetMyProperty(Value: string); overload;
>> published
>> property MyProperty;
>> end;
>>
>> implementation
>>
>> function TMyClass .GetMyProperty: string;
>> begin
>> Result := FMyProperty;
>> end;
>>
>> procedure TMyClass .SetMyProperty(Value: string);
>> begin
>> if Value = FMyProperty then
>> exit;
>>
>> FMyProperty := Value;
>> end;
>> end.
>>
>>
>>
>> ___
>> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>
> Try override instead of overload
>
> --
> Rodrigo Palhano
> -
> Equipe SpeedCASE
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Polymorphism question
On Fri, 03 Mar 2006 04:52:36 -0300, <[EMAIL PROTECTED]> wrote:
(I sent this mail yesterday but somehow it didn't get trough, therefore a
new try)
I would like to declare a polymorph class. The class has several
properties and it's the read and write specifiers that I want to be
virtual abstract. So derived classes override the read and write
specifiers. The problem however is that I get an EAbstractError. The
property is still considered to be abstract according to the compiler. So
what did I wrong? I have added an example below.
Is it perhaps not allowed to use this construct? What would then be the
best way?
Darius
<>
unit MyTest;
{$mode objfpc}{$H+}
interface
uses
Classes, ComCtrls, SysUtils;
type
TCustomClass = class
private
//virtual mehods
function GetMyProperty: string; virtual; abstract;
procedure SetMyProperty(Value: string); virtual; abstract;
published
property MyProperty: string Read GetMyProperty Write SetMyProperty;
end;
TMyClass = class(TCustomClass)
private
FMyProperty: string;
function GetMyProperty: string; overload;
procedure SetMyProperty(Value: string); overload;
published
property MyProperty;
end;
implementation
function TMyClass .GetMyProperty: string;
begin
Result := FMyProperty;
end;
procedure TMyClass .SetMyProperty(Value: string);
begin
if Value = FMyProperty then
exit;
FMyProperty := Value;
end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Try override instead of overload
--
Rodrigo Palhano
-
Equipe SpeedCASE
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] polymorphism question
I would like to declare a polymorph class. The
class has several properties and it's the read and write specifiers that I want
to be virtual abstract. So derived classes override the read and write
specifiers. The problem however is that I get an EAbstractError. The
property is still considered to be abstract according to the compiler. So what
did I wrong? I have added an example below.
Is it perhaps not allowed to use this construct?
What would then be the best way?
Darius
<>
unit MyTest;
{$mode objfpc}{$H+}
interface
uses Classes, ComCtrls,
SysUtils;
type TCustomClass = class
private //virtual
mehods function GetMyProperty: string; virtual;
abstract; procedure SetMyProperty(Value: string); virtual;
abstract; published
property MyProperty: string Read
GetMyProperty Write SetMyProperty; end;
TMyClass = class(TCustomClass)
private FMyProperty: string;
function GetMyProperty: string;
overload; procedure SetMyProperty(Value: string);
overload; published property
MyProperty; end;
implementation
function TMyClass .GetMyProperty:
string;begin Result := FMyProperty;end;
procedure TMyClass .SetMyProperty(Value:
string);begin if Value = FMyProperty then
exit; FMyProperty :=
Value;end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Polymorphism question
i'm new so grain of salt ... On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > function GetMyProperty: string; overload; > procedure SetMyProperty(Value: string); overload; should these be 'override' rather than 'overload' ? -- X-SA user ? 0.4 is out ! http://x-plane.dsrts.com http://games.groups.yahoo.com/group/x-plane-foo/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Polymorphism question
(I sent this mail yesterday but somehow it didn't get trough, therefore a
new try)
I would like to declare a polymorph class. The class has several
properties and it's the read and write specifiers that I want to be
virtual abstract. So derived classes override the read and write
specifiers. The problem however is that I get an EAbstractError. The
property is still considered to be abstract according to the compiler. So
what did I wrong? I have added an example below.
Is it perhaps not allowed to use this construct? What would then be the
best way?
Darius
<>
unit MyTest;
{$mode objfpc}{$H+}
interface
uses
Classes, ComCtrls, SysUtils;
type
TCustomClass = class
private
//virtual mehods
function GetMyProperty: string; virtual; abstract;
procedure SetMyProperty(Value: string); virtual; abstract;
published
property MyProperty: string Read GetMyProperty Write SetMyProperty;
end;
TMyClass = class(TCustomClass)
private
FMyProperty: string;
function GetMyProperty: string; overload;
procedure SetMyProperty(Value: string); overload;
published
property MyProperty;
end;
implementation
function TMyClass .GetMyProperty: string;
begin
Result := FMyProperty;
end;
procedure TMyClass .SetMyProperty(Value: string);
begin
if Value = FMyProperty then
exit;
FMyProperty := Value;
end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On 27 feb 2006, at 00:15, A.J. Venter wrote: Randomize; RandSeed := RandSeed * getpid; This worked, cut the initial generation time from about 30 seconds down to under 1, of course right now it's NOT platform independent at all so I will need to enhance it but I like the direction of your thinking, combining randseed with some virtually guaranteed unique value solves the problem. It's not just that, but randseed is not a threadvar. This means that all your threads use the same randseed variable, so if two threads call "random" at the same time they will still get the same "random" number. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better random numbers ?
On 27 Feb 06, at 1:15, A.J. Venter wrote: > > Some other workaround that comes to my mind is to do something like > >Randomize; > >RandSeed := RandSeed * getpid; > This worked, cut the initial generation time from about 30 seconds down to > under 1, of course right now it's NOT platform independent at all so I will > need to enhance it but I like the direction of your thinking, combining > randseed with some virtually guaranteed unique value solves the problem. System.GetProcessID should be perfectly platform independent. HTH Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] data queue
On Mon, 27 Feb 2006, Mattias Gaertner wrote: Is there already a data queue in the RTL/FCL? Something which supports Push(Stream,Count) and Pop(Stream,Count)? No. Feel free to contribute one :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Test
___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] data queue
Is there already a data queue in the RTL/FCL? Something which supports Push(Stream,Count) and Pop(Stream,Count)? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
