Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Tomas Hajny
On Mon, May 7, 2012 14:26, Mattias Gaertner wrote:
> On Mon, 7 May 2012 13:34:50 +0200 (CEST) "Tomas Hajny"
 wrote:
>> 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the
>> additional platform specific implementation for changing the passed
>> environment).
>
> Where do got those numbers?
> TProcess for winxx only needs a few lines to set the environment:

The numbers are for existing ExecuteProcess implementations (my original
point was that if you needed to change the environment, you could not use
ExecuteProcess as provided by the RTL and had to replicate the
ExecuteProcess implementations within InstantFPC instead). Your (later)
proposal to move to TProcess solves that better, of course.


 .
 .
> It's not big. The RTL lacks little functions for scripts. For
> example download an URL, get a list of files in a directory, load a
> xml file, test a RE.
>
> Running pascal programs as scripts is only the first step. The
> next step is to provide a bunch of units that make
> commons tasks one liners. That's why people use perl et al.
 .
 .


Calling wget, ls or grep already are one liners. ;-)


Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Marco van de Voort
In our previous episode, Mattias Gaertner said:
> It's not big. The RTL lacks little functions for scripts. For
> example download an URL, get a list of files in a directory, load a
> xml file, test a RE.
> 
> Running pascal programs as scripts is only the first step. The
> next step is to provide a bunch of units that make
> commons tasks one liners. 

I agree. I've added some minor stuff in recent versions:

- base64 encode/decode in one function (instead of streaming only)
- symbolic has a simple "quickevaluate" to quick do calculations 
(  like 2+4+6, even simple var substitution is possible )

I recently copied the TProcess wiki example to get the output of an exe in a
string for the 3rd or 4th time, so that was my next target.

A bit like ExecuteProcess, one variant that operates on a whole cmdline (but
only the most basic separation) and one array of const style. 

> That's why people use perl et al.

That is IMHO a bridge too far :-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Mattias Gaertner
On Mon, 7 May 2012 13:34:50 +0200 (CEST)
"Tomas Hajny"  wrote:

> On Mon, May 7, 2012 12:21, Mattias Gaertner wrote:
> > On Sat, 5 May 2012 15:04:05 +0200 (CEST)
> > "Tomas Hajny"  wrote:
>[...]
> > The implementation for unix is only a few lines.
> > I guess for winxx and os/2 too.
> 
> 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the
> additional platform specific implementation for changing the passed
> environment).

Where do got those numbers?
TProcess for winxx only needs a few lines to set the environment:

 
> > I don't know about dos, but as fallback TProcess can be used, which
> > already implements this x-platform.
> 
> Not yet for OS/2 nor GO32v2, but yes, this would probably be a better
> option than including that stuff directly in InstantFPC if going down that
> route (of changing environment for the child process).
>  .
>  .
> >> > A const in the main script is only accessible by the program,
> >> > not by the used units.
> >>
> >> There are obviously solutions for that. However, I assume that the main
> >> use case for such scripts is writing a complete script in one file (the
> >> main program).
> >
> > Many perl/php/python scripts use modules. I don't see why it should be
> > different for fpc scripts. In fact, I already have a few shared units
> > for my instantfpc scripts. The used units need a way to find out the
> > current script path.
> 
> I understand that the preferences vary (personally, I'd probably compile
> such a bigger executable permanently).

It's not big. The RTL lacks little functions for scripts. For
example download an URL, get a list of files in a directory, load a
xml file, test a RE.

Running pascal programs as scripts is only the first step. The
next step is to provide a bunch of units that make
commons tasks one liners. That's why people use perl et al.


> Anyway, it may be useful
> occasionally and as I mentioned, solutions exist (e.g. by defining the
> interface of such modules in a way allowing to pass the location from the
> main script either directly when invoking the functions having such a need
> or indirectly by initializing the location by changing a variable declared
> within the respective unit/module at the beginning of the script, or by
> declaring the variable in the main script as external and accessing it
> from the unit).

True.
But recompilation is slow and should be avoided if possible.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Tomas Hajny
On Mon, May 7, 2012 12:21, Mattias Gaertner wrote:
> On Sat, 5 May 2012 15:04:05 +0200 (CEST)
> "Tomas Hajny"  wrote:
>> On Sat, May 5, 2012 14:13, Mattias Gaertner wrote:
 .
 .
>> > ExecuteProcess is only a simple utility function.
>> > All posix platforms can start a process with another
>> > environment. By default they use the current.
>>
>> Indeed. But InstantFPC works not only on posix platforms but also on
>> WinXX
>> and OS/2 at least if I remember correctly (and there's no reason why it
>> couldn't be used even on Dos with e.g. 4DOS). All of them allow passing
>> a
>> different environment to the child process, but the implementation is
>> obviously always different. That means that you need to replicate the
>> platform specific implementation of that 'wrapper' for all supported
>> platforms within InstantFPC.
>
> The implementation for unix is only a few lines.
> I guess for winxx and os/2 too.

54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the
additional platform specific implementation for changing the passed
environment).


> I don't know about dos, but as fallback TProcess can be used, which
> already implements this x-platform.

Not yet for OS/2 nor GO32v2, but yes, this would probably be a better
option than including that stuff directly in InstantFPC if going down that
route (of changing environment for the child process).


 .
 .
>> > A const in the main script is only accessible by the program,
>> > not by the used units.
>>
>> There are obviously solutions for that. However, I assume that the main
>> use case for such scripts is writing a complete script in one file (the
>> main program).
>
> Many perl/php/python scripts use modules. I don't see why it should be
> different for fpc scripts. In fact, I already have a few shared units
> for my instantfpc scripts. The used units need a way to find out the
> current script path.

I understand that the preferences vary (personally, I'd probably compile
such a bigger executable permanently). Anyway, it may be useful
occasionally and as I mentioned, solutions exist (e.g. by defining the
interface of such modules in a way allowing to pass the location from the
main script either directly when invoking the functions having such a need
or indirectly by initializing the location by changing a variable declared
within the respective unit/module at the beginning of the script, or by
declaring the variable in the main script as external and accessing it
from the unit).

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Mattias Gaertner
On Sat, 5 May 2012 15:04:05 +0200 (CEST)
"Tomas Hajny"  wrote:

> On Sat, May 5, 2012 14:13, Mattias Gaertner wrote:
> > On Sat, 5 May 2012 14:02:12 +0200 (CEST)
> > "Tomas Hajny"  wrote:
> >> On Sat, May 5, 2012 09:22, Michael Van Canneyt wrote:
> >> > On Fri, 4 May 2012, Mattias Gaertner wrote:
> >> >> On Fri, 04 May 2012 17:22:16 +0200
> >> >> dhkblas...@zeelandnet.nl wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> I'm creating a script to be executed by instantfpc when I noticed
> >> >>> that paramstr(0) does not reflect the location of the script but the
> >> >>> location of the cached executable. Is there a way to alter this
> >> >>> location
> >> >>> programatically to the script location? Is there an alternative way?
> >> >>
> >> >> instantfpc passes as first parameter the original file name.
> >> >> But execv overrides the first argument with the executed file. AFAIK
> >> >> there is no alternative.
> >> >>
> >> >> You can set an environment variable.
> >> >
> >> > I think the environment variable is the best and easiest shot.
> >>
> >> My proposal is platform independent (i.e. it will work also under Win32,
> >> OS/2, etc., without any changes). Your proposal probably requires
> >> starting
> >> the compiled binary using platform specific API functions to run it with
> >> a
> >> modified environment rather than using ExecuteProcess which results in
> >> passing the standard parent's environment (changing the current's
> >> process
> >> environment may not be supported on all platforms).
> >
> > ExecuteProcess is only a simple utility function.
> > All posix platforms can start a process with another
> > environment. By default they use the current.
> 
> Indeed. But InstantFPC works not only on posix platforms but also on WinXX
> and OS/2 at least if I remember correctly (and there's no reason why it
> couldn't be used even on Dos with e.g. 4DOS). All of them allow passing a
> different environment to the child process, but the implementation is
> obviously always different. That means that you need to replicate the
> platform specific implementation of that 'wrapper' for all supported
> platforms within InstantFPC.

The implementation for unix is only a few lines.
I guess for winxx and os/2 too.
I don't know about dos, but as fallback TProcess can be used, which
already implements this x-platform.

 
> > A const requires to recompile the program every time you call the script
> > from another location.
> 
> You mean if calling the script with path? Yes, that's true. Passing full
> path would be safer, but obviously different from ParamStr (0) behaviour.

Yes. If you compile for every path change then calling the script via
test.pas or ./test.pas or .//test.pas or /path/test.pas would
compile 4 times.

 
> > A const in the main script is only accessible by the program,
> > not by the used units.
> 
> There are obviously solutions for that. However, I assume that the main
> use case for such scripts is writing a complete script in one file (the
> main program).

Many perl/php/python scripts use modules. I don't see why it should be
different for fpc scripts. In fact, I already have a few shared units
for my instantfpc scripts. The used units need a way to find out the
current script path.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-07 Thread Mattias Gaertner
On Sat, 5 May 2012 17:43:44 +0200
Jonas Maebe  wrote:

> 
> On 05 May 2012, at 14:25, Mattias Gaertner wrote:
> 
> > It uses only the file name, not the path to distinguish.
> > Having two scripts with the same name recompiles every time you
> > switch.
> 
> This does mean that if a script is moved, the stored script location as seen 
> by the compiled binary will not change because it won't be recompiled, as far 
> as I understand.

Correct.

And it does not check if the compiler was updated or some used unit
has changed.
You have to clear the cache or add the -B option to always compile.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Jonas Maebe

On 05 May 2012, at 14:25, Mattias Gaertner wrote:

> It uses only the file name, not the path to distinguish.
> Having two scripts with the same name recompiles every time you
> switch.

This does mean that if a script is moved, the stored script location as seen by 
the compiled binary will not change because it won't be recompiled, as far as I 
understand.


Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Tomas Hajny
On 5 May 12, at 14:20, Mattias Gaertner wrote:
> On Sat, 5 May 2012 14:07:01 +0200 (CEST)
> "Tomas Hajny"  wrote:
> 
> > On Fri, May 4, 2012 21:58, Marco van de Voort wrote:
> > > In our previous episode, Tomas Hajny said:
> > >> 1) Find the first alphabetic character after the first line (which is
> > >> already processed/skipped by InstantFPC anyway) while ignoring all
> > >> whitespaces and possible comments (in all allowed formats, i.e.
> > >> including
> > >> (* *) ) - the only small complexity here are nested comments, but even
> > >> that is not so difficult to handle.
> > >>
> > >> 2) If there is the 'program' keyword, find the semicolon and continue
> > >> searching for the next alphabetic character while still ignoring
> > >> comments
> > >> and whitespaces (to skip possible global compiler directives).
> > >>
> > >> 3) Write down 'const InstantFPCScriptName = ...;' + LineEnding
> > >> immediately
> > >> before the found alphabetic character (there should be no need to parse
> > >> it).
> > >
> > > Will cause some "misplaced global compiler switch" if after the program
> > > came
> > > an {$mode originally.
> > 
> > I don't think so. That's why I suggested skipping all comments in point 1
> > (before 'program') and also point 2 (after 'program' but before anything
> > else) above and also mentioned global compiler directives explicitly
> > ($mode is obviously one of them).
> 
> You also have to skip the uses section.

Yes, of course, I forgot that one, but that alone wouldn't change it 
much.


> And what about ifdefs?

Well, right, ifdefs might make it fairly complex indeed. :-( The 
proposal from Jonas (temporary unit with -Fa) is obviously a better 
solution.

Tomas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Tomas Hajny
On Sat, May 5, 2012 14:08, Jonas Maebe wrote:
> On 05 May 2012, at 14:02, Tomas Hajny wrote:
>
>> My proposal is platform independent (i.e. it will work also under Win32,
>> OS/2, etc., without any changes). Your proposal probably requires
>> starting
>> the compiled binary using platform specific API functions to run it with
>> a
>> modified environment rather than using ExecuteProcess which results in
>> passing the standard parent's environment (changing the current's
>> process
>> environment may not be supported on all platforms).
>
> An alternative would be for instantfpc to create a temporary unit
> containing this constant, and inject it in the main program via the -Fa
> parameter. I don't know whether moving an instantfpc-based script also
> invalidates the cached compiled copy though (but I guess it does, because
> otherwise you wouldn't be able have two scripts with the same name in
> different locations).

Yes, this is a nice one. I originally thought about a unit too, but it
wasn't much better without the -Fa idea (which I didn't remember).

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Tomas Hajny
On Sat, May 5, 2012 14:13, Mattias Gaertner wrote:
> On Sat, 5 May 2012 14:02:12 +0200 (CEST)
> "Tomas Hajny"  wrote:
>> On Sat, May 5, 2012 09:22, Michael Van Canneyt wrote:
>> > On Fri, 4 May 2012, Mattias Gaertner wrote:
>> >> On Fri, 04 May 2012 17:22:16 +0200
>> >> dhkblas...@zeelandnet.nl wrote:
>> >>
>> >>>
>> >>>
>> >>> I'm creating a script to be executed by instantfpc when I noticed
>> >>> that paramstr(0) does not reflect the location of the script but the
>> >>> location of the cached executable. Is there a way to alter this
>> >>> location
>> >>> programatically to the script location? Is there an alternative way?
>> >>
>> >> instantfpc passes as first parameter the original file name.
>> >> But execv overrides the first argument with the executed file. AFAIK
>> >> there is no alternative.
>> >>
>> >> You can set an environment variable.
>> >
>> > I think the environment variable is the best and easiest shot.
>>
>> My proposal is platform independent (i.e. it will work also under Win32,
>> OS/2, etc., without any changes). Your proposal probably requires
>> starting
>> the compiled binary using platform specific API functions to run it with
>> a
>> modified environment rather than using ExecuteProcess which results in
>> passing the standard parent's environment (changing the current's
>> process
>> environment may not be supported on all platforms).
>
> ExecuteProcess is only a simple utility function.
> All posix platforms can start a process with another
> environment. By default they use the current.

Indeed. But InstantFPC works not only on posix platforms but also on WinXX
and OS/2 at least if I remember correctly (and there's no reason why it
couldn't be used even on Dos with e.g. 4DOS). All of them allow passing a
different environment to the child process, but the implementation is
obviously always different. That means that you need to replicate the
platform specific implementation of that 'wrapper' for all supported
platforms within InstantFPC.


> A const requires to recompile the program every time you call the script
> from another location.

You mean if calling the script with path? Yes, that's true. Passing full
path would be safer, but obviously different from ParamStr (0) behaviour.


> A const in the main script is only accessible by the program,
> not by the used units.

There are obviously solutions for that. However, I assume that the main
use case for such scripts is writing a complete script in one file (the
main program).

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Mattias Gaertner
On Sat, 5 May 2012 14:08:26 +0200
Jonas Maebe  wrote:

> 
> On 05 May 2012, at 14:02, Tomas Hajny wrote:
> 
> > My proposal is platform independent (i.e. it will work also under Win32,
> > OS/2, etc., without any changes). Your proposal probably requires starting
> > the compiled binary using platform specific API functions to run it with a
> > modified environment rather than using ExecuteProcess which results in
> > passing the standard parent's environment (changing the current's process
> > environment may not be supported on all platforms).
> 
> An alternative would be for instantfpc to create a temporary unit containing 
> this constant, and inject it in the main program via the -Fa parameter. I 
> don't know whether moving an instantfpc-based script also invalidates the 
> cached compiled copy though (but I guess it does, because otherwise you 
> wouldn't be able have two scripts with the same name in different locations).

It uses only the file name, not the path to distinguish.
Having two scripts with the same name recompiles every time you
switch.
There is a note in the docs about that.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Mattias Gaertner
On Sat, 5 May 2012 14:07:01 +0200 (CEST)
"Tomas Hajny"  wrote:

> On Fri, May 4, 2012 21:58, Marco van de Voort wrote:
> > In our previous episode, Tomas Hajny said:
> >> 1) Find the first alphabetic character after the first line (which is
> >> already processed/skipped by InstantFPC anyway) while ignoring all
> >> whitespaces and possible comments (in all allowed formats, i.e.
> >> including
> >> (* *) ) - the only small complexity here are nested comments, but even
> >> that is not so difficult to handle.
> >>
> >> 2) If there is the 'program' keyword, find the semicolon and continue
> >> searching for the next alphabetic character while still ignoring
> >> comments
> >> and whitespaces (to skip possible global compiler directives).
> >>
> >> 3) Write down 'const InstantFPCScriptName = ...;' + LineEnding
> >> immediately
> >> before the found alphabetic character (there should be no need to parse
> >> it).
> >
> > Will cause some "misplaced global compiler switch" if after the program
> > came
> > an {$mode originally.
> 
> I don't think so. That's why I suggested skipping all comments in point 1
> (before 'program') and also point 2 (after 'program' but before anything
> else) above and also mentioned global compiler directives explicitly
> ($mode is obviously one of them).

You also have to skip the uses section.
And what about ifdefs?


Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Mattias Gaertner
On Sat, 5 May 2012 14:02:12 +0200 (CEST)
"Tomas Hajny"  wrote:

> On Sat, May 5, 2012 09:22, Michael Van Canneyt wrote:
> > On Fri, 4 May 2012, Mattias Gaertner wrote:
> >> On Fri, 04 May 2012 17:22:16 +0200
> >> dhkblas...@zeelandnet.nl wrote:
> >>
> >>>
> >>>
> >>> I'm creating a script to be executed by instantfpc when I noticed
> >>> that paramstr(0) does not reflect the location of the script but the
> >>> location of the cached executable. Is there a way to alter this
> >>> location
> >>> programatically to the script location? Is there an alternative way?
> >>
> >> instantfpc passes as first parameter the original file name.
> >> But execv overrides the first argument with the executed file. AFAIK
> >> there is no alternative.
> >>
> >> You can set an environment variable.
> >
> > I think the environment variable is the best and easiest shot.
> 
> My proposal is platform independent (i.e. it will work also under Win32,
> OS/2, etc., without any changes). Your proposal probably requires starting
> the compiled binary using platform specific API functions to run it with a
> modified environment rather than using ExecuteProcess which results in
> passing the standard parent's environment (changing the current's process
> environment may not be supported on all platforms).

ExecuteProcess is only a simple utility function.
All posix platforms can start a process with another
environment. By default they use the current.

A const requires to recompile the program every time you call the script
from another location.

A const in the main script is only accessible by the program,
not by the used units.


Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Jonas Maebe

On 05 May 2012, at 14:02, Tomas Hajny wrote:

> My proposal is platform independent (i.e. it will work also under Win32,
> OS/2, etc., without any changes). Your proposal probably requires starting
> the compiled binary using platform specific API functions to run it with a
> modified environment rather than using ExecuteProcess which results in
> passing the standard parent's environment (changing the current's process
> environment may not be supported on all platforms).

An alternative would be for instantfpc to create a temporary unit containing 
this constant, and inject it in the main program via the -Fa parameter. I don't 
know whether moving an instantfpc-based script also invalidates the cached 
compiled copy though (but I guess it does, because otherwise you wouldn't be 
able have two scripts with the same name in different locations).


Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Tomas Hajny
On Fri, May 4, 2012 21:58, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> 1) Find the first alphabetic character after the first line (which is
>> already processed/skipped by InstantFPC anyway) while ignoring all
>> whitespaces and possible comments (in all allowed formats, i.e.
>> including
>> (* *) ) - the only small complexity here are nested comments, but even
>> that is not so difficult to handle.
>>
>> 2) If there is the 'program' keyword, find the semicolon and continue
>> searching for the next alphabetic character while still ignoring
>> comments
>> and whitespaces (to skip possible global compiler directives).
>>
>> 3) Write down 'const InstantFPCScriptName = ...;' + LineEnding
>> immediately
>> before the found alphabetic character (there should be no need to parse
>> it).
>
> Will cause some "misplaced global compiler switch" if after the program
> came
> an {$mode originally.

I don't think so. That's why I suggested skipping all comments in point 1
(before 'program') and also point 2 (after 'program' but before anything
else) above and also mentioned global compiler directives explicitly
($mode is obviously one of them).

Tomas


> 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] InstantFPC and argv

2012-05-05 Thread Tomas Hajny
On Sat, May 5, 2012 09:22, Michael Van Canneyt wrote:
> On Fri, 4 May 2012, Mattias Gaertner wrote:
>> On Fri, 04 May 2012 17:22:16 +0200
>> dhkblas...@zeelandnet.nl wrote:
>>
>>>
>>>
>>> I'm creating a script to be executed by instantfpc when I noticed
>>> that paramstr(0) does not reflect the location of the script but the
>>> location of the cached executable. Is there a way to alter this
>>> location
>>> programatically to the script location? Is there an alternative way?
>>
>> instantfpc passes as first parameter the original file name.
>> But execv overrides the first argument with the executed file. AFAIK
>> there is no alternative.
>>
>> You can set an environment variable.
>
> I think the environment variable is the best and easiest shot.

My proposal is platform independent (i.e. it will work also under Win32,
OS/2, etc., without any changes). Your proposal probably requires starting
the compiled binary using platform specific API functions to run it with a
modified environment rather than using ExecuteProcess which results in
passing the standard parent's environment (changing the current's process
environment may not be supported on all platforms).

Tomas




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-05 Thread Michael Van Canneyt



On Fri, 4 May 2012, Mattias Gaertner wrote:


On Fri, 04 May 2012 17:22:16 +0200
dhkblas...@zeelandnet.nl wrote:




I'm creating a script to be executed by instantfpc when I noticed
that paramstr(0) does not reflect the location of the script but the
location of the cached executable. Is there a way to alter this location
programatically to the script location? Is there an alternative way?


instantfpc passes as first parameter the original file name.
But execv overrides the first argument with the executed file. AFAIK
there is no alternative.

You can set an environment variable.


I think the environment variable is the best and easiest shot.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread Mattias Gaertner
On Fri, 04 May 2012 17:22:16 +0200
dhkblas...@zeelandnet.nl wrote:

>   
> 
> I'm creating a script to be executed by instantfpc when I noticed
> that paramstr(0) does not reflect the location of the script but the
> location of the cached executable. Is there a way to alter this location
> programatically to the script location? Is there an alternative way?

instantfpc passes as first parameter the original file name.
But execv overrides the first argument with the executed file. AFAIK
there is no alternative.

You can set an environment variable.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread Marco van de Voort
In our previous episode, Tomas Hajny said:
> 1) Find the first alphabetic character after the first line (which is
> already processed/skipped by InstantFPC anyway) while ignoring all
> whitespaces and possible comments (in all allowed formats, i.e. including
> (* *) ) - the only small complexity here are nested comments, but even
> that is not so difficult to handle.
> 
> 2) If there is the 'program' keyword, find the semicolon and continue
> searching for the next alphabetic character while still ignoring comments
> and whitespaces (to skip possible global compiler directives).
> 
> 3) Write down 'const InstantFPCScriptName = ...;' + LineEnding immediately
> before the found alphabetic character (there should be no need to parse
> it).

Will cause some "misplaced global compiler switch" if after the program came
an {$mode originally.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread Tomas Hajny
On Fri, May 4, 2012 18:44, Darius Blaszyk wrote:
> On May 4, 2012, at 6:12 PM, Tomas Hajny wrote:
>> On Fri, May 4, 2012 17:44, dhkblas...@zeelandnet.nl wrote:
>>> On 4 mei '12, michael.vancann...@wisa.be wrote:
 On Fri, 4 May
>>> 2012, michael.vancann...@wisa.be [3]wrote:

> On Fri, 4 May 2012,
>>> dhkblas...@zeelandnet.nl [1]wrote:


Hi Darius,

>> I'm creating a script to be
>>> executed by instantfpc when I noticed that paramstr(0) does not reflect
>>> the location of the script but the location of the cached executable.
>>> Is
>>> there a way to alter this location programatically to the script
>>> location? Is there an alternative way?
 .
 .
>> There are two parts for a possible solution. The first part should be
>> feasible without major issues (with it still requires someone to do it,
>> e.g. provide a patch) - InstantFPC could add the name of the original
>> script (including full path) as a predefined constant into the Pascal
>> source while extracting it from the original script file.
 .
 .
>> adding
>> the local ParamStr on a single source line would even allow these
>> backtraces to refer to the correct line numbers from the original script
>> file ;-) ).
>>
> Hi Tomas,
> I think your first solution would be the nicest one. If all agree and the
> patch would be accepted then I would like to give it shot. I'm not sure
> though how to insert the code in the best way. Probably it will be using
> passrc, although I'm not sure it will work on scripts with a shebang line.

Not sure about passrc behaviour for shebang but I believe that it may be
quite easy to solve it without passrc too. I'd say that the pascal syntax
knowledge necessary for this task would be limited:

1) Find the first alphabetic character after the first line (which is
already processed/skipped by InstantFPC anyway) while ignoring all
whitespaces and possible comments (in all allowed formats, i.e. including
(* *) ) - the only small complexity here are nested comments, but even
that is not so difficult to handle.

2) If there is the 'program' keyword, find the semicolon and continue
searching for the next alphabetic character while still ignoring comments
and whitespaces (to skip possible global compiler directives).

3) Write down 'const InstantFPCScriptName = ...;' + LineEnding immediately
before the found alphabetic character (there should be no need to parse
it).

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread Darius Blaszyk

On May 4, 2012, at 6:12 PM, Tomas Hajny wrote:

> On Fri, May 4, 2012 17:44, dhkblas...@zeelandnet.nl wrote:
>> On 4 mei '12, michael.vancann...@wisa.be wrote:
>>> On Fri, 4 May
>> 2012, michael.vancann...@wisa.be [3]wrote:
>>> 
 On Fri, 4 May 2012,
>> dhkblas...@zeelandnet.nl [1]wrote:
 
> I'm creating a script to be
>> executed by instantfpc when I noticed that paramstr(0) does not reflect
>> the location of the script but the location of the cached executable. Is
>> there a way to alter this location programatically to the script
>> location? Is there an alternative way?
 The solution can be found on
>> http://www.freepascal.org/docs-html/prog/progsu38.html [2] Const
>> ScriptName = {$INCLUDE FILE};
>>> 
>>> Come to think of it, probably not
>> 100% what you want.
>>> It will contain the name of the temporary script
>> file.
>> 
>> Indeed,
>> it's not. ScriptName will contain "configure.ppx.pas". What I want it
>> that ParamStr(0) will contain the full filename to the script file
>> instead of the compiled version. This should be the default behaviour
>> imho b ecause it's an "executable" script and not a source file anymore.
> 
> There are two parts for a possible solution. The first part should be
> feasible without major issues (with it still requires someone to do it,
> e.g. provide a patch) - InstantFPC could add the name of the original
> script (including full path) as a predefined constant into the Pascal
> source while extracting it from the original script file.
> 
> If you insist on receiving this path as ParamStr (0) result, it gets a bit
> more complicated. Basically, the only at least partly reasonable solution
> coming to my mind is having InstantFPC added a new function ParamStr
> locally to the script during extraction of the "temporary script" (aka
> Pascal source file). This overridden ParamStr function would then call
> System.ParamStr for all values except for ParamStr (0). This isn't much
> more difficult than just adding the constant described above, but it
> wouldn't solve cases like explicit reference to System.ParamStr (0). Also,
> any other RTL/FCL/... functions using ParamStr (0) (which may be in turn
> used from your script) would still refer to the standard System.ParamStr
> (0). You may not like it, but at least it wouldn't break existing standard
> functionality like enhanced backtraces when compiled with -gl (btw, adding
> the local ParamStr on a single source line would even allow these
> backtraces to refer to the correct line numbers from the original script
> file ;-) ).
> 
Hi Tomas,
I think your first solution would be the nicest one. If all agree and the patch 
would be accepted then I would like to give it shot. I'm not sure though how to 
insert the code in the best way. Probably it will be using passrc, although I'm 
not sure it will work on scripts with a shebang line.

Regards, Darius___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread Tomas Hajny
On Fri, May 4, 2012 17:44, dhkblas...@zeelandnet.nl wrote:
> On 4 mei '12, michael.vancann...@wisa.be wrote:
>> On Fri, 4 May
> 2012, michael.vancann...@wisa.be [3]wrote:
>>
>>> On Fri, 4 May 2012,
> dhkblas...@zeelandnet.nl [1]wrote:
>>>
 I'm creating a script to be
> executed by instantfpc when I noticed that paramstr(0) does not reflect
> the location of the script but the location of the cached executable. Is
> there a way to alter this location programatically to the script
> location? Is there an alternative way?
>>> The solution can be found on
> http://www.freepascal.org/docs-html/prog/progsu38.html [2] Const
> ScriptName = {$INCLUDE FILE};
>>
>> Come to think of it, probably not
> 100% what you want.
>> It will contain the name of the temporary script
> file.
>
> Indeed,
> it's not. ScriptName will contain "configure.ppx.pas". What I want it
> that ParamStr(0) will contain the full filename to the script file
> instead of the compiled version. This should be the default behaviour
> imho b ecause it's an "executable" script and not a source file anymore.

There are two parts for a possible solution. The first part should be
feasible without major issues (with it still requires someone to do it,
e.g. provide a patch) - InstantFPC could add the name of the original
script (including full path) as a predefined constant into the Pascal
source while extracting it from the original script file.

If you insist on receiving this path as ParamStr (0) result, it gets a bit
more complicated. Basically, the only at least partly reasonable solution
coming to my mind is having InstantFPC added a new function ParamStr
locally to the script during extraction of the "temporary script" (aka
Pascal source file). This overridden ParamStr function would then call
System.ParamStr for all values except for ParamStr (0). This isn't much
more difficult than just adding the constant described above, but it
wouldn't solve cases like explicit reference to System.ParamStr (0). Also,
any other RTL/FCL/... functions using ParamStr (0) (which may be in turn
used from your script) would still refer to the standard System.ParamStr
(0). You may not like it, but at least it wouldn't break existing standard
functionality like enhanced backtraces when compiled with -gl (btw, adding
the local ParamStr on a single source line would even allow these
backtraces to refer to the correct line numbers from the original script
file ;-) ).

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread dhkblaszyk
  

On 4 mei '12, michael.vancann...@wisa.be wrote: 

> On Fri, 4 May
2012, michael.vancann...@wisa.be [3]wrote:
> 
>> On Fri, 4 May 2012,
dhkblas...@zeelandnet.nl [1]wrote: 
>> 
>>> I'm creating a script to be
executed by instantfpc when I noticed that paramstr(0) does not reflect
the location of the script but the location of the cached executable. Is
there a way to alter this location programatically to the script
location? Is there an alternative way?
>> The solution can be found on
http://www.freepascal.org/docs-html/prog/progsu38.html [2] Const
ScriptName = {$INCLUDE FILE};
> 
> Come to think of it, probably not
100% what you want. 
> It will contain the name of the temporary script
file.
> 
> Michael.
> ___
>
fpc-pascal maillist - fpc-pascal@lists.freepascal.org [4]
>
http://lists.freepascal.org/mailman/listinfo/fpc-pascal [5]

Indeed,
it's not. ScriptName will contain "configure.ppx.pas". What I want it
that ParamStr(0) will contain the full filename to the script file
instead of the compiled version. This should be the default behaviour
imho b ecause it's an "executable" script and not a source file anymore.


Regards, Darius 

  

Links:
--
[1]
mailto:dhkblas...@zeelandnet.nl
[2]
http://www.freepascal.org/docs-html/prog/progsu38.html
[3]
mailto:michael.vancann...@wisa.be
[4]
mailto:fpc-pascal@lists.freepascal.org
[5]
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] InstantFPC and argv

2012-05-04 Thread michael . vancanneyt



On Fri, 4 May 2012, michael.vancann...@wisa.be wrote:




On Fri, 4 May 2012, dhkblas...@zeelandnet.nl wrote:




I'm creating a script to be executed by instantfpc when I noticed
that paramstr(0) does not reflect the location of the script but the
location of the cached executable. Is there a way to alter this location
programatically to the script location? Is there an alternative way?




The solution can be found on

 http://www.freepascal.org/docs-html/prog/progsu38.html

Const
 ScriptName = {$INCLUDE FILE};


Come to think of it, probably not 100% what you want. 
It will contain the name of the temporary script file.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] InstantFPC and argv

2012-05-04 Thread michael . vancanneyt



On Fri, 4 May 2012, dhkblas...@zeelandnet.nl wrote:




I'm creating a script to be executed by instantfpc when I noticed
that paramstr(0) does not reflect the location of the script but the
location of the cached executable. Is there a way to alter this location
programatically to the script location? Is there an alternative way?




The solution can be found on

  http://www.freepascal.org/docs-html/prog/progsu38.html

Const
  ScriptName = {$INCLUDE FILE};


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal