[fpc-pascal] Re: TProcess questions
Adrian Maier wrote: It seems nice to have a way of specifying parameters like that (in which case I assume that strings given will be passed as-they-are). Another option is to use escaping for quote characters (and maybe some others) when specifying the TProcess.CommandLine property. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
I sent this once already. Sorry if it duplicated, but I didn't see it showing up on the list: JMO: The last thing we want the FPC team to consider is a port to .NET. Delphi already does .net, and MSFT C# does it even better. Additionally, porting to .net invites FPC to become mired in the same mud that Borland has been stuck in since it decided to allow MSFT to dictate the terms of its market. Lots of good stuff in .net, but let's face it, our spending our brain cells developing for .net is better for MSFT than is it for us. I'll be happy to argue why that's the case. There is functionality in .net that we all like, but FPC is going in exactly the right direction, albeit slowly without the commercial help that I wish the team would consider. The direction is the right one because it's serving a growing need represented by how the internet is evolving into it's own platform and devaluing the OS. So what's the presentation engine for this new platform? The browser. A great example of what can be done with a browser user interface is Morfik. Guess what one of the compiler targets is for Morfik applications. Morfik has a way to go, but their effort is looking much better than it did even several months ago. What's the other part of this equation? The server side. As the internet becomes a platform in its on right, endpoints could care less about what the server OS is, as long as it efficiently provides services. That means we developers should become platform agnostic, and mono is **not** the solution for this. FPC is, and as computing power becomes more centralized, quality, scalability and efficiency will be even more valued. Hopefully FPC will evolve into a tool that will help us to address these issues so that we can build optimized server software, regardless of OS. Again, some judicous commercialization would help FPC in this regard. So instead of supporting .net, I'd like to see FPC evolve into a language that has a personality that is radically different from anything MSFT is developing (and unfortunately by extension, Delphi). Imagine a FPC that supports Design by Contract, or has a Ravenscar profile. I'm convinced that future development will demand this sort of programmable quality assurance, so it would be another sales advantage for developers and companies using FPC. Whatever the example, the point is to be willing to put good ideas into code without letting MSFT decide what those good ideas will be. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC with PocketPC... any others?
> does someone know if Indy port to FPC would work on ARM? (On their > site it says there has been some succes with WinCE... but asside that > 'some' succes on 'wince' is not very clear.) What OS? Indy has quite high requirements on sockets interface and the thread implementation. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
> On Tue, 3 Oct 2006, Marco van de Voort wrote: > > IMHO it would be better to start over legacy free for .NET and really target > > the .NET/JVM/LLVM platform 100%. > > > > I think that single source combinations are already all gone by the time we > > would enter production with a .NET port. And even if, a single source system > > would put a break too much on the mutual development. > > So you would go the VB way: VB.NET completely broke existing VB code. No. I didn't say I even want to keep the appearance that I kept that. > The advantage of Delphi was exactly that it offered a transition path... In the few cases I actually bothered to try, it was more on paper than in reality. Components, lowlevel code, nonsupported database drivers, you name it, it all meant rewrite of most of the code to a library (VCL.NET or at the website ASP.NET 1.x) that was already considered a transition horse, and another rewrite already appeared on the horizon "to really make good use of the nice features that .NET has to offer". And then again when Borland finally manages to push a 2.0 version out of the door. > I don't consider that wise. > What is more, we don't have the manpower to maintain 2 source systems. I did't have the even larger manpower to rewrite twice or thrice shortly after eachother. (in the end it was decided to put the native code into maintainance, and to develop a new system directly in VS2005 and finance it with the customers that directly benefitted from going to the new system. (e.g. because they integrated with existing .NET stuff) HOWEVER, even _if_ I give you the Borland case (I don't, but everybody is entitled to his own opinion of course, and everybody can be wrong), do you think that philosophy holds true for us too? >From a marketing perspective (for Borland) it is perfect: - They show a path of least resistance, a lot of users are going to take, even though it is actually the hard way. - They get paid for it. - They avoid mass evaluation of alternate solutions. - If .NET somehow stalls, they still have win32. - give them a C# compiler for the same money, and then hope a percentage will slowly transition. Mainly because it is the perceived .NET language of preference. Then tighten the noose of the legacy Delphi.NET. Result: same conversion with less defection to MS then saying directly "Delphi is dead, use Borland C#". So now apply the above points to us? Do we gain from that? We won't get a single additional user till we are at least somewhat in the league of Delphi, while we have to neglect and compromise native to actually pull it off. Even Borland only managed to include some open source routines from Fastcode and some minor .NET language compat stuff in post D7 native versions. IF .NET really is so succesful, we only will have something productworthy when native is already dead, and most backwards compat is already abandonned. If it is not so succesful (e.g. a certain double digit percentage of users stays native) , or it is, but we can't get a piece of the pie because we are late, and legacy carrying non sexy, we have put gigantic effort in something new for nothing, drawing resources away from native development, like Borland did from win32. It took us over 7 years to get on par with native Delphi after starting Delphi compat mode. Do your really want to start Delphi.NET now? I've seen the shear size of e.g. C# in VS2005 when I worked with it for a few weeks. It absolute dwarfs Delphi syntax in size, and worse, there are a lot of additional tools to be developed to take actual use of this (e.g. all the database binding directives). And all the while when we are implementing this, we'll get the standard reaction "nice, but not ready yet". ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On Tue, 3 Oct 2006, Marco van de Voort wrote: > > On Tue, 3 Oct 2006, Felipe Monteiro de Carvalho wrote: > > > At my company, we still have a huge number of clients running Windows > > 95, who protest loudly when we even _suggest_ upgrading. > > > > Which is not to say that we should not look at a .NET port of FPC, but > > this is not very high on the priority list. After all, .NET offers no > > advantages by itself. > > IMHO it would be better to start over legacy free for .NET and really target > the .NET/JVM/LLVM platform 100%. > > I think that single source combinations are already all gone by the time we > would enter production with a .NET port. And even if, a single source system > would put a break too much on the mutual development. So you would go the VB way: VB.NET completely broke existing VB code. The advantage of Delphi was exactly that it offered a transition path... I don't consider that wise. What is more, we don't have the manpower to maintain 2 source systems. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC with PocketPC... any others?
Thank you Felipe; does someone know if Indy port to FPC would work on ARM? (On their site it says there has been some succes with WinCE... but asside that 'some' succes on 'wince' is not very clear.) 2006/10/3, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]>: On 10/3/06, Alexandre Leclerc <[EMAIL PROTECTED]> wrote: > I see FPC can compile for PocketPC? > Can it compile on other devices? (i feel ms is not the only player in > the arena...) Take a look here: http://www.freepascal.org/wiki/index.php/Platform_list#Supported_targets_for_ARM -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
Marco van de Voort wrote: > IMHO it would be better to start over legacy free for .NET and really target > the .NET/JVM/LLVM platform 100%. Refer them to Chrome ? ;-) Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with GLOB()
> I just wrote a little program in FPC 2.0.2 which uses GLOB() to search and > display a directory. I use 'oldlinux' in the uses statement. [...] > finally installed the full (and same!) fpc version there and re-compiled the > source, but the result is the same. > > Any idea about what is wrong here? Uhh, making NEW code based on OLDlinux :-) Glob is dead, and with a reason. It used to be faster, but that kind of functionality has been added to the normal findfirst/findnext routines a while ago. (e.g. the FreeBSD port already has it pre 1.0, and the Linux port since 2.0 afaik) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
> On Tue, 3 Oct 2006, Felipe Monteiro de Carvalho wrote: > At my company, we still have a huge number of clients running Windows > 95, who protest loudly when we even _suggest_ upgrading. > > Which is not to say that we should not look at a .NET port of FPC, but > this is not very high on the priority list. After all, .NET offers no > advantages by itself. IMHO it would be better to start over legacy free for .NET and really target the .NET/JVM/LLVM platform 100%. I think that single source combinations are already all gone by the time we would enter production with a .NET port. And even if, a single source system would put a break too much on the mutual development. See e.g. Borland, the native port is at a virtual standstill, the only thing they do is incorporate other peoples source (FastCode) and backport .NET specific language features that are meaninless in native mode. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC with PocketPC... any others?
On 10/3/06, Alexandre Leclerc <[EMAIL PROTECTED]> wrote: I see FPC can compile for PocketPC? Can it compile on other devices? (i feel ms is not the only player in the arena...) Take a look here: http://www.freepascal.org/wiki/index.php/Platform_list#Supported_targets_for_ARM -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC with PocketPC... any others?
Hi all, I see FPC can compile for PocketPC? Can it compile on other devices? (i feel ms is not the only player in the arena...) -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On Tue, 3 Oct 2006, Felipe Monteiro de Carvalho wrote: > > About .NET and LLVM, they don´t seam to add anything Free Pascal > already cannot do. > > We should also think it may be inevitable to write a .NET port in the > very long future (10 years?), if microsoft decides to obsolete windows > api by that time. They cannot. Most existing software would no longer work. And people are not eager to upgrade. Why would they ? Windows XP or Vista bring nothing new. No-one is waiting for it. At my company, we still have a huge number of clients running Windows 95, who protest loudly when we even _suggest_ upgrading. Which is not to say that we should not look at a .NET port of FPC, but this is not very high on the priority list. After all, .NET offers no advantages by itself. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 10/3/06, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: About .NET and LLVM, they don´t seam to add anything Free Pascal already cannot do. Donno about .NET but LLVM advertises itself as a target for compiler development. It does a wide range of optimizations and if memory serves right, osnews ran an article citing the use of LLVM inside the latest release of MacOS-X. Cheers, Krishna -- I long to accomplish a great and noble task, but it is my chief duty to accomplish small tasks as if they were great and noble ! - Helen Keller ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 9/29/06, Adrian Maier <[EMAIL PROTECTED]> wrote: By the way : why dotnet and not java ? Acctually I was considering (not so near in the future), to research about writing a java byte code target for Free Pascal. Of course the faq says you guys aren´t much pro it, but there do is a real use for this, because some devices can only run java bytecode, like many modern cell phones. I was even thinking it may be easier to write a java port (j2me) to get Free Pascal running on Symbian OS, then writing a native port, because there are so many incompatible versions of this OS, but all of them support j2me. There are GPLed assemblers for java bytecode out there, so we would only need to write a instruction generator that generates that assembler and port the rtl. About .NET and LLVM, they don´t seam to add anything Free Pascal already cannot do. We should also think it may be inevitable to write a .NET port in the very long future (10 years?), if microsoft decides to obsolete windows api by that time. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Problem with GLOB()
Hello! I just wrote a little program in FPC 2.0.2 which uses GLOB() to search and display a directory. I use 'oldlinux' in the uses statement. It works fine on my old SuSE 8.0. Then I copied the binary to a SuSE 9.0 machine and started it there. It works (means that it doesn't crash), but shows no files when I use a search mask with a directory, i.e. './work/*' instead of '*'. But is has no LinuxError, oit only finds nothing. First I thought this is caused by copying a binary to a different system, so I finally installed the full (and same!) fpc version there and re-compiled the source, but the result is the same. Any idea about what is wrong here? mfg Ing. Rainer Hantsch ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 29 Sep 2006, at 12:15, Krishna wrote: Why not target LLVM instead? I've also thought about that, but haven't looked yet at the technical specifications of LLVM to see how easy/difficult it would be. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
Adrian Maier wrote: > So, initially the Environment is empty and the program inherits the > variables. > When I append the first variable, it will no longer inherit the variables. > > I find the behaviour counterintuitive: the first "append" causes the > Environment to > be initialised. > > I haven't discovered yet how could the programmer preserve the > inherited environment > and only "add" some variables ? This copies all the envvars to a stringlist. You can add your own of course too. function GetEnvironmentVars: TStringList; var I: Integer; fName: String; begin Result := TStringList.Create; for I := 0 to GetEnvironmentVariableCount-1 do begin fName := GetEnvironmentString(I); Result.Add(fName); end; end; HTH Andrew Haines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Last missing benchmark: regex-dna
> Although fpc has a regexpr unit: > http://svn.freepascal.org/svn/fpc/trunk/packages/base/regexpr/regexpr.pp > It has many todos, such as adding support for | in the search expression. So > this > unit doesn't have enough functionality. While '|' support is to be considered basic regex functionality, what is the really expected functionality? Basic seems to be: |()?*+ (non-UNICODE) support (from wikipedia). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On 10/3/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Oct 2006, Adrian Maier wrote:
> >
> > It's a painful one. I was hoping to switch to TProcess instead of shell (
> > which isn't cross-platform ) ...
>
> The bug won't occur on windows :)
>
> I will see about fixing it. Could you please post a bug report so it won't
> be forgotten.
Wouldn't it be better to also have a way to set the parameters using an
indexed property one by one instead of a cmdline?
Because this kind of interpretation issues will continue forever, since shell
handling is not portable. This was
pretty much the reason for the change to array of string in ExecuteProcess
and friends.
In such case, there is always a "safe" fall back.
It seems nice to have a way of specifying parameters like that (in which case
I assume that strings given will be passed as-they-are).
There is one more thing about TProcess that i've been surprised to
see that after:
proc.Environment.Append('PGDATABASE=db1');
all the variables inherited from the parent process are no longer passed to the
external program by TProcess.
The behaviour is documented :
" Environment contains the environment for the new process; it's a
list of Name=Value pairs, one per line. If it is empty, the
environment of the current process is passed on to the new process. "
So, initially the Environment is empty and the program inherits the variables.
When I append the first variable, it will no longer inherit the variables.
I find the behaviour counterintuitive: the first "append" causes the
Environment to
be initialised.
I haven't discovered yet how could the programmer preserve the
inherited environment
and only "add" some variables ?
Don't you think that by default the Environment list should be filled
with the current
environment? This way "append" would mean indeed "append". It would also
be easy to clear the Environment if needed.
--
Adrian Maier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TProcess questions
Marco van de Voort wrote: > Can you add the following to TProcess instead of using the CommandLine property: > example: > property ProcessName: String - the process to be executed > property Params : TStringList - list of command line params to be > passed to the process > > Why should quote characters be stripped as it is in the current > implementation? When executing, there is a difference between shell notation and the programming interface. e.g. program name parammeter 1 parameter 2 parameter 3 should be written on the cmdline as "program name" "parameter 1" "parameter 2" "parameter 3" But should be passed to a kernel function as: filename:='/full/path/to/program name'; // no quotes; param[0]:='parameter 1'; // no quotes; param[1]:='parameter 2'; // no quotes; param[2]:='parameter 3'; // no quotes; This is the difference between shell api and deeper api. E.g shell deeper Unix: (fp)system() (fp)exec* winxx: shellexecutecreateprocess Another usual difference between these two is that the shell versions search for the binary, while you need to pass full path to the "deeper" category of functions. Thanks for the explanation. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Last missing benchmark: regex-dna
On 10/3/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: The regex-dna benchmark (http://shootout.alioth.debian.org/debian/benchmark.php?test=regexdna&lang=all) is the last missing benchmark. Although fpc has a regexpr unit: http://svn.freepascal.org/svn/fpc/trunk/packages/base/regexpr/regexpr.pp It has many todos, such as adding support for | in the search expression. So this unit doesn't have enough functionality. Is somebody willing to invest time in this unit to complete it? An alternative could be to use the libc unit. But the fpc developers don't encourage its use and I cannot use it on windows, where I develop and improve the tests. Then there is also synregexpr.pas: http://svn.freepascal.org/svn/lazarus/trunk/components/synedit/synregexpr.pas But that is not distrubuted with fpc. And I don't know, if the license is open source. Is it looks likes a BSD derivative, but item 3, about income, doesn't seem to fit in. How should this benchmark be implemented? How about using PCRE? I've used Delphi bindings before and they are quite nice. I guess it should compile with FPC out of the box. This is the one I used: http://www.renatomancuso.com/software/dpcre/dpcre.htm Cheers, Krishna -- I long to accomplish a great and noble task, but it is my chief duty to accomplish small tasks as if they were great and noble ! - Helen Keller ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: TProcess questions
> Can you add the following to TProcess instead of using the CommandLine > property: > example: > property ProcessName: String - the process to be executed > property Params : TStringList - list of command line params to be > passed to the process > > Why should quote characters be stripped as it is in the current > implementation? When executing, there is a difference between shell notation and the programming interface. e.g. program name parammeter 1 parameter 2 parameter 3 should be written on the cmdline as "program name" "parameter 1" "parameter 2" "parameter 3" But should be passed to a kernel function as: filename:='/full/path/to/program name'; // no quotes; param[0]:='parameter 1'; // no quotes; param[1]:='parameter 2'; // no quotes; param[2]:='parameter 3'; // no quotes; This is the difference between shell api and deeper api. E.g shell deeper Unix: (fp)system() (fp)exec* winxx: shellexecutecreateprocess Another usual difference between these two is that the shell versions search for the binary, while you need to pass full path to the "deeper" category of functions. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
> On Tue, 3 Oct 2006, Adrian Maier wrote: > > > > It's a painful one. I was hoping to switch to TProcess instead of shell ( > > which isn't cross-platform ) ... > > The bug won't occur on windows :) > > I will see about fixing it. Could you please post a bug report so it won't > be forgotten. Wouldn't it be better to also have a way to set the parameters using an indexed property one by one instead of a cmdline? Because this kind of interpretation issues will continue forever, since shell handling is not portable. This was pretty much the reason for the change to array of string in ExecuteProcess and friends. In such case, there is always a "safe" fall back. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On 10/3/06, Adrian Maier <[EMAIL PROTECTED]> wrote: > > Well, first of all you should do a 'IsRunning' (or running) before checking > the exitcode. I'm using the poWaitOnExit option, so my program doesn't waits until the external process ends. All I need is to know if the external process ended successfully or not . Sorry for the spelling mistakes. I meant: I'm using the poWaitOnExit option, so my program waits for the external process to end. In this case the process is surely not running anymore when I get the exitcode. All I need is to know if the external process ended successfully or not . > Only after that you can check the exit code. About the signalling, > we'd need to extend TProcess for that. I understand. Cheers, Adrian Maier -- Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On 10/3/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: I will see about fixing it. Could you please post a bug report so it won't be forgotten. Mantis issue 7534 added . Is it likely for the fix to go into fpc 2.0.4? Or just in the HEAD ? Cheers, Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPHashList help
On 03/10/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: Well, I just programmed an extension to TFPHashTable (in cooperation with Dean Zobec) which allows you to select this behaviour: to free or not to free. It's not yet in SVN, but if you want I can send it to you. Michael. It's not urgent, so will wait until it is in SVN. In the mean time I swapped out the internal TFPHashList for a TStringList (and make a note to swap it back later). Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: TProcess questions
On Tue, 3 Oct 2006, Alexander Todorov wrote: > Can you add the following to TProcess instead of using the CommandLine > property: > example: > property ProcessName: String - the process to be executed > property Params : TStringList - list of command line params to be > passed to the process Executable and Params seems like a better choice ? > > Why should quote characters be stripped as it is in the current > implementation? Some should be stripped, others not. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Last missing benchmark: regex-dna
The regex-dna benchmark (http://shootout.alioth.debian.org/debian/benchmark.php?test=regexdna&lang=all) is the last missing benchmark. Although fpc has a regexpr unit: http://svn.freepascal.org/svn/fpc/trunk/packages/base/regexpr/regexpr.pp It has many todos, such as adding support for | in the search expression. So this unit doesn't have enough functionality. Is somebody willing to invest time in this unit to complete it? An alternative could be to use the libc unit. But the fpc developers don't encourage its use and I cannot use it on windows, where I develop and improve the tests. Then there is also synregexpr.pas: http://svn.freepascal.org/svn/lazarus/trunk/components/synedit/synregexpr.pas But that is not distrubuted with fpc. And I don't know, if the license is open source. Is it looks likes a BSD derivative, but item 3, about income, doesn't seem to fit in. How should this benchmark be implemented? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TProcess questions
Can you add the following to TProcess instead of using the CommandLine property: example: property ProcessName: String - the process to be executed property Params : TStringList - list of command line params to be passed to the process Why should quote characters be stripped as it is in the current implementation? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPHashList help
On Tue, 3 Oct 2006, Graeme Geldenhuys wrote: > Hi, > > I have the following class and function that retrieves a object from a > internal TFPHashList. If the object isn't in the list, it is read from > a database, and then also inserted into the hashlist, before it gets > returned. > > Does TFPHashTable also manage the objects it contains (or references) > like TObjectList. If not (which I think it doesn't), that means when > TModuleFlyweightFactory gets destroyed, I need to free and empty the > internal TFPHashTable as well. I'm not sure how I would to that > though. Can is loop through the hashtable using the Items[] property > to free off the referenced object. Set that same Item to nil, and then > in the end, just .Free the FPHashTable? Well, I just programmed an extension to TFPHashTable (in cooperation with Dean Zobec) which allows you to select this behaviour: to free or not to free. It's not yet in SVN, but if you want I can send it to you. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TFPHashList help
Sorry, I forgot to mention... TFPHashTable.Items[] doesn't take a integer, but a string. Which I believe is the 'key', so I can't loop through the list. Graeme. On 03/10/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: Hi, I have the following class and function that retrieves a object from a internal TFPHashList. If the object isn't in the list, it is read from a database, and then also inserted into the hashlist, before it gets returned. Does TFPHashTable also manage the objects it contains (or references) like TObjectList. If not (which I think it doesn't), that means when TModuleFlyweightFactory gets destroyed, I need to free and empty the internal TFPHashTable as well. I'm not sure how I would to that though. Can is loop through the hashtable using the Items[] property to free off the referenced object. Set that same Item to nil, and then in the end, just .Free the FPHashTable? interface section: TModuleFlyweightFactory = class(TObject) private FList: TFPHashTable; function GetModuleCount: integer; public constructor Create; destructor Destroy; override; functionGetModule(pOID: TOID): TModule; overload; functionGetModule(pOIDAsString: string): TModule; overload; propertyModuleCount: integer read GetModuleCount; end; implementation section: function TModuleFlyweightFactory.GetModule(pOID: TOID): TModule; var lData: TModule; begin lData := TModule(FList.Items[pOID.AsString]); if lData <> nil then Result := lData else begin lData := TModule.Create; lData.OID.AsString := pOID.AsString; lData.ReadPK; if lData.ObjectState <> posEmpty then FList.Add(lData.OID.AsString, lData); // only add if we know we have something Result := lData; end; end; Regards, - Graeme - -- There's no place like 127.0.0.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TFPHashList help
Hi, I have the following class and function that retrieves a object from a internal TFPHashList. If the object isn't in the list, it is read from a database, and then also inserted into the hashlist, before it gets returned. Does TFPHashTable also manage the objects it contains (or references) like TObjectList. If not (which I think it doesn't), that means when TModuleFlyweightFactory gets destroyed, I need to free and empty the internal TFPHashTable as well. I'm not sure how I would to that though. Can is loop through the hashtable using the Items[] property to free off the referenced object. Set that same Item to nil, and then in the end, just .Free the FPHashTable? interface section: TModuleFlyweightFactory = class(TObject) private FList: TFPHashTable; function GetModuleCount: integer; public constructor Create; destructor Destroy; override; functionGetModule(pOID: TOID): TModule; overload; functionGetModule(pOIDAsString: string): TModule; overload; propertyModuleCount: integer read GetModuleCount; end; implementation section: function TModuleFlyweightFactory.GetModule(pOID: TOID): TModule; var lData: TModule; begin lData := TModule(FList.Items[pOID.AsString]); if lData <> nil then Result := lData else begin lData := TModule.Create; lData.OID.AsString := pOID.AsString; lData.ReadPK; if lData.ObjectState <> posEmpty then FList.Add(lData.OID.AsString, lData); // only add if we know we have something Result := lData; end; end; Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On 10/3/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: On Tue, 3 Oct 2006, Adrian Maier wrote: > On 10/3/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > Any idea how should i quote the arguments so that they would be properly > > > treated by TProcess? > > > > You can't. The following lines (line 107 of unix/process.inc) > > Result:=StringReplace(Result,'"','',[rfReplaceAll]); > > Result:=StringReplace(Result,,'',[rfReplaceAll]); > > Will strip all quotes inside a quoted string. > > > > Obviously, this is a bug. > > It's a painful one. I was hoping to switch to TProcess instead of shell ( > which isn't cross-platform ) ... The bug won't occur on windows :) I will see about fixing it. Could you please post a bug report so it won't be forgotten. Ok. > > > 3. The code returned by the called program can be got with > > > TProcess.ExitCode , right ? I have a situation in which a program 1 > > > , but TProcess.ExitCode is 0. Therefore it's impossible to detect > > > the failure. > > > > That can be if the program exited because of a signal. > > I'm not sure if this was the case - I'll have to investigate. > Anyway, is it possible to detect this situation ? Well, first of all you should do a 'IsRunning' (or running) before checking the exitcode. I'm using the poWaitOnExit option, so my program doesn't waits until the external process ends. All I need is to know if the external process ended successfully or not . Only after that you can check the exit code. About the signalling, we'd need to extend TProcess for that. I understand. Cheers, Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On Tue, 3 Oct 2006, Adrian Maier wrote: > On 10/3/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > Any idea how should i quote the arguments so that they would be properly > > > treated by TProcess? > > > > You can't. The following lines (line 107 of unix/process.inc) > > Result:=StringReplace(Result,'"','',[rfReplaceAll]); > > Result:=StringReplace(Result,,'',[rfReplaceAll]); > > Will strip all quotes inside a quoted string. > > > > Obviously, this is a bug. > > It's a painful one. I was hoping to switch to TProcess instead of shell ( > which isn't cross-platform ) ... The bug won't occur on windows :) I will see about fixing it. Could you please post a bug report so it won't be forgotten. > > > > > 2. Where is the TProcess documented on the freepascal website? > > Michael, Vincent , > Thanks for the links for TProcess docs . :-) > > > > 3. The code returned by the called program can be got with > > > TProcess.ExitCode , right ? I have a situation in which a program 1 > > > , but TProcess.ExitCode is 0. Therefore it's impossible to detect > > > the failure. > > > > That can be if the program exited because of a signal. > > I'm not sure if this was the case - I'll have to investigate. > Anyway, is it possible to detect this situation ? Well, first of all you should do a 'IsRunning' (or running) before checking the exitcode. Only after that you can check the exit code. About the signalling, we'd need to extend TProcess for that. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On 10/3/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > Any idea how should i quote the arguments so that they would be properly > treated by TProcess? You can't. The following lines (line 107 of unix/process.inc) Result:=StringReplace(Result,'"','',[rfReplaceAll]); Result:=StringReplace(Result,,'',[rfReplaceAll]); Will strip all quotes inside a quoted string. Obviously, this is a bug. It's a painful one. I was hoping to switch to TProcess instead of shell ( which isn't cross-platform ) ... > 2. Where is the TProcess documented on the freepascal website? Michael, Vincent , Thanks for the links for TProcess docs . :-) > 3. The code returned by the called program can be got with > TProcess.ExitCode , right ? I have a situation in which a program 1 > , but TProcess.ExitCode is 0. Therefore it's impossible to detect > the failure. That can be if the program exited because of a signal. I'm not sure if this was the case - I'll have to investigate. Anyway, is it possible to detect this situation ? Cheers, Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
Michael Van Canneyt schreef: On Tue, 3 Oct 2006, Adrian Maier wrote: 2. Where is the TProcess documented on the freepascal website? I had found a FCL.pdf some time ago , but I am unable to find that doc on the freepascal website. It is not documented currently. It's scheduled as the next unit to be documented. It is documented using fpdoc: http://lazarus-ccr.sourceforge.net/docs/fcl/process/index.html I guess there will a similar page on www.freepascal.org too. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On Tue, 3 Oct 2006, Michael Van Canneyt wrote: > > 2. Where is the TProcess documented on the freepascal website? I had > > found a FCL.pdf some time ago , but I am unable to find that doc on the > > freepascal website. > > It is not documented currently. It's scheduled as the next unit to be > documented. Eeh, forget this. it's documented (must be getting old, memory starts failing) you can find it at: ftp://ftp.freepascal.org/pub/fpc/docs-pdf/fcl.pdf Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess questions
On Tue, 3 Oct 2006, Adrian Maier wrote: > Hello, > > I have several questions about executing external programs with TProcess > > 1. I need to execute the following command : > psql -q -f /home/am/src/gfaf/hlemit_d.sql -v D1="'1-apr-06'" -v > D2="'1-jun-06'" > > (it might not be obvious at first sight that there are both " and ' > enclosing those dates , because the argument must contain the ' ) . > > This command works fine when executed from the bash shell. However, it > no longer works when executed from my pascal program (with TProcess). > Any idea how should i quote the arguments so that they would be properly > treated by TProcess? You can't. The following lines (line 107 of unix/process.inc) Result:=StringReplace(Result,'"','',[rfReplaceAll]); Result:=StringReplace(Result,,'',[rfReplaceAll]); Will strip all quotes inside a quoted string. Obviously, this is a bug. > > 2. Where is the TProcess documented on the freepascal website? I had > found a FCL.pdf some time ago , but I am unable to find that doc on the > freepascal website. It is not documented currently. It's scheduled as the next unit to be documented. > > 3. The code returned by the called program can be got with > TProcess.ExitCode , right ? I have a situation in which a program 1 > , but TProcess.ExitCode is 0. Therefore it's impossible to detect > the failure. That can be if the program exited because of a signal. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess questions
Hello, I have several questions about executing external programs with TProcess 1. I need to execute the following command : psql -q -f /home/am/src/gfaf/hlemit_d.sql -v D1="'1-apr-06'" -v D2="'1-jun-06'" (it might not be obvious at first sight that there are both " and ' enclosing those dates , because the argument must contain the ' ) . This command works fine when executed from the bash shell. However, it no longer works when executed from my pascal program (with TProcess). Any idea how should i quote the arguments so that they would be properly treated by TProcess? 2. Where is the TProcess documented on the freepascal website? I had found a FCL.pdf some time ago , but I am unable to find that doc on the freepascal website. 3. The code returned by the called program can be got with TProcess.ExitCode , right ? I have a situation in which a program 1 , but TProcess.ExitCode is 0. Therefore it's impossible to detect the failure. Cheers, Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using Graph unit on Linux Ubuntu...
Tiziano_mk ha scritto:
{ Link with VGA, gl and c libraries }
{$linklib vga}
{$linklib c}
I am not a linux expert, so after installing the library "libsvga" (the
only like "libvga" I found on the ubuntu repository) I don't understand
what the linker wants and I'm giving up.
Some hints would be appreciated,
never mind...
1) I didn't carefully read the rtl.pdf manual;
2) I didn't install libvga-devel;
3) I didn't train enough on linux;
now I can compile and link the program, and catch out all the bugs :-)
bye
tiziano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
