1. Independent Euphoria Interpreter
How close are we to this?
http://rapideuphoria.wiki.sourceforge.net/nix+config
2. Re: Independent Euphoria Interpreter
- Posted by Matt Lewis <matthewwalkerlewis at ?mai?.com>
Dec 13, 2007
-
Last edited Dec 14, 2007
c.k.lester wrote:
>
> How close are we to this?
>
> http://rapideuphoria.wiki.sourceforge.net/nix+config
I've started a new branch in svn to work on this concept. As I started
coding (haven't had much time for that lately) I came up with lots of
questions, and updated the wiki.
My questions are about supporting multiple files, and little implementation
details like that. I'd suggest that those who are interested in the topic
keep current with the wiki, and update it or post discussion there (we can
talk about it here, too, but it's nice to have all of that stuff in a
central location).
svn URL for the branch:
https://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria/branches/nix
Matt
3. Re: Independent Euphoria Interpreter
- Posted by Juergen Luethje <j.lue at gmx?d?>
Dec 13, 2007
-
Last edited Dec 14, 2007
Matt Lewis wrote:
> c.k.lester wrote:
> >
> > How close are we to this?
> >
> > <a
> > href="http://rapideuphoria.wiki.sourceforge.net/nix+config">http://rapideuphoria.wiki.sourceforge.net/nix+config</a>
>
> I've started a new branch in svn to work on this concept. As I started
> coding (haven't had much time for that lately) I came up with lots of
> questions, and updated the wiki.
>
> My questions are about supporting multiple files, and little implementation
> details like that. I'd suggest that those who are interested in the topic
> keep current with the wiki, and update it or post discussion there (we can
> talk about it here, too, but it's nice to have all of that stuff in a
> central location).
>
> svn URL for the branch:
> <a
> href="https://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria/branches/nix">https://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria/branches/nix</a>
Some comments about the updated page.
On the page it currently reads:
| Specifying a config file on the command line would preclude looking in
| the other places.
Yes, this will provide maximal flexibility.
And:
| Should more than one file be allowed? A system wide file could be stored
| in /etc/... and each user could have their own for additional directories
| (presumably in their home directory structure somewhere).
What does that question mean?
Should more than one file be allowed to be specified on the command line?
No, it should be only allowed to specify either 0 or 1 config file on
the command line.
Should more than one file be allowed to exist on the hard disk?
Yes, that's why a smart search order is very important.
On the page it also reads:
| A nominal search order might be (and this would also define the order in which
| directories are searched):
|
| * command line switches (based on the order encountered on the command line)
| o -c command line switch
| o -i command line switch (a specific directory)
| * ~/.euinc.conf or %APPDATA%\euphoria\euinc.conf
| * euinc.conf local to the interpreter (mainly for a portable config)
| * /etc/euphoria/euinc.conf %ALLUSERSPROFILE%\euphoria\euinc.conf (the
system-wide config)
Can you please elaborate on this?
Why two different switches for specifying a config file??
The order in this list is not good:
A 'euinc.conf' file local to the interpreter/translator should have the
2nd priority, i.e. such a config file should be more important than a
user-specific config file in say %APPDATA%\euphoria\.
All portable applications that I know, do follow this search order.
E.g. when I have Euphoria on my USB drive, and I visit a friend who has
Eu installed on his PC, and I want to show one of my programs to him by
running it from my USB drive, then the program on the USB drive should
use the config file on the USB drive, and not any config file on my
friend's hard disk. That's the reason why this search order is important.
So the search order should be:
1) config file specified on the command line
2) config file in the same directory as the interpreter/translator
3) user-specific "typical" config directory on the hard disk
4) "typical" system-wide config directory on the hard disk
Regards,
Juergen
4. Re: Independent Euphoria Interpreter
- Posted by Matt Lewis <matthewwalkerlewis at g?ail.co?>
Dec 13, 2007
-
Last edited Dec 14, 2007
Juergen Luethje wrote:
>
> Some comments about the updated page.
>
> On the page it currently reads:
> | Specifying a config file on the command line would preclude looking in
> | the other places.
>
> Yes, this will provide maximal flexibility.
>
> And:
> | Should more than one file be allowed? A system wide file could be stored
> | in /etc/... and each user could have their own for additional directories
> | (presumably in their home directory structure somewhere).
>
> What does that question mean?
> Should more than one file be allowed to be specified on the command line?
> No, it should be only allowed to specify either 0 or 1 config file on
> the command line.
> Should more than one file be allowed to exist on the hard disk?
> Yes, that's why a smart search order is very important.
Yeah, that wasn't terribly coherent. I was basically proposing something,
and asking for comments, because I'm not sure it's the right way. Could
you elaborate on why only one file on the command line?
My thought on this is that we're basically going to maintain a sequence of
directories in which to look for include files. Every time we encounter a
new directory [not already in the sequence] we'll append it. When we try
to find an include file, we'll just use this list to try to open the file.
So it's not as though any of the files will step on each other with
contradictory settings or anything. Here's a question for you, since you
brought it up. :)
When we talk about 'relative paths' are you saying relative to the
interpreter? Does that only make sense for the local conf file? It seems
like you'd almost have to. What do relative paths mean for the other files?
> | * command line switches (based on the order encountered on the command
> line)
> | o -c command line switch
> | o -i command line switch (a specific directory)
>
> Can you please elaborate on this?
> Why two different switches for specifying a config file??
One is a config file (using the -c switch), and another is passing a
directory right there on the command line. It's 'inspired' by C compilers,
which do a similar thing with the -i switch (typically).
> The order in this list is not good:
> A 'euinc.conf' file local to the interpreter/translator should have the
> 2nd priority, i.e. such a config file should be more important than a
> user-specific config file in say %APPDATA%\euphoria\.
> All portable applications that I know, do follow this search order.
>
> E.g. when I have Euphoria on my USB drive, and I visit a friend who has
> Eu installed on his PC, and I want to show one of my programs to him by
> running it from my USB drive, then the program on the USB drive should
> use the config file on the USB drive, and not any config file on my
> friend's hard disk. That's the reason why this search order is important.
>
> So the search order should be:
> 1) config file specified on the command line
> 2) config file in the same directory as the interpreter/translator
> 3) user-specific "typical" config directory on the hard disk
> 4) "typical" system-wide config directory on the hard disk
Good points. I'll update the wiki.
Matt
5. Re: Independent Euphoria Interpreter
- Posted by c.k.lester <euphoric at c??ester.com>
Dec 13, 2007
-
Last edited Dec 14, 2007
I tried to reply to your message at the wiki, matt, but every time i logged
in and then went to the wiki, it logged me out (or kept asking for me to
login again, which i did, but then couldn't post because it kept asking me
to login again, which i did, but then...)
anyway, i think there are two issues here that might be somewhat related and
they need to be separated.
1. unix installations
2. euphoria interpreter environment variables
Item 2 is important to CGI, even for Windows, so the Windows interpreter
needs to take into account the same config file functionality as Linux/FreeBSD.
That is, all the interpreters need to look for the config file before
running on their respective platform.
6. Re: Independent Euphoria Interpreter
c.k.lester wrote:
>
> I tried to reply to your message at the wiki, matt, but every time i logged
> in and then went to the wiki, it logged me out (or kept asking for me to
> login again, which i did, but then couldn't post because it kept asking me
> to login again, which i did, but then...)
Yeah, they've been changing the sf.net page recently, and there are several
things that annoy me, not the least being that it never remembers you when
you return to the site.
> anyway, i think there are two issues here that might be somewhat related and
> they need to be separated.
>
> 1. unix installations
> 2. euphoria interpreter environment variables
>
> Item 2 is important to CGI, even for Windows, so the Windows interpreter
> needs to take into account the same config file functionality as
> Linux/FreeBSD. That is, all the interpreters need to look for the config
> file before running on their respective platform.
You're absolutely right. I think that every place where 'portable' is
mentioned, you can imagine that it also says 'cgi'--I'll edit the page
to reflect this. But that doesn't change the meat of what's on the page.
Here are the relevant parts of the page (with editing to show only the
Win32/DOS32 parts):
The interpreters/translators would search for the configuration file firstly
in their own directory (important if they are on a portable device). If no
configuration file is found there, then they'll look for it in some standard
places. That could be (see below for more detail):
* on Windows: %ALLUSERSPROFILE%\euphoria\euinc.conf :
%APPDATA%\euphoria\euinc.conf
* on DOS : ??? Probably just a local conf file, since there are no users
Matt
7. Re: Independent Euphoria Interpreter
Matt Lewis wrote:
>
> Juergen Luethje wrote:
> >
> > Some comments about the updated page.
> >
> > On the page it currently reads:
> > | Specifying a config file on the command line would preclude looking in
> > | the other places.
> >
> > Yes, this will provide maximal flexibility.
I disagree. If you run an app and it cannot find say libX, then you should just
be able to specify where libX is on the command line, rather than libX, and
machine.e, and win32lib/wxEuphoria, etc. Of course look where the command line
says first, but if you do not find it I can think of no reason to prohibit
looking elsewhere.
> > Should more than one file be allowed?
Perhaps. You might equally want a semicolon separator in the -i option.
> When we talk about 'relative paths' are you saying relative to the
> interpreter? Does that only make sense for the local conf file? It seems
> like you'd almost have to. What do relative paths mean for the other files?
From a windows perspective, if you're running C:\euphoria\bin\exw.exe then
obviusly it ought to look for includes in C:\euphoria\include\. I would
therefore expect there to be a file C:\euphoria\bin\euinc.conf (ie same dir as
exw.exe) which contains the relative path "..\include\" (and/or attempt that as a
last resort if no config file can be found). IMO relative paths should be
relative to the location of the .conf file they are specified in,
and a -i relative path should be relative to the current directory.
You may also want a special notation such as "%%..\include\" whereby the %% is
replaced with the location of exu/exw.exe.
> > | * command line switches
> > | * -c command line switch
> > | * -i command line switch (a specific directory)
> >
> One is a config file (using the -c switch), and another is passing a
> directory right there on the command line.
Personally I would reword that as:
* command line switches
* -c <config file>
* -i <directory of euinc.conf>
Lastly, can you add a note that if %APPDATA% and/or %ALLUSERSPROFILE% do not
exist then the corresponding step is skipped (rather than crash/error out).
Regards,
Pete
8. Re: Independent Euphoria Interpreter
Pete Lomax wrote:
> > > Should more than one file be allowed?
> Perhaps. You might equally want a semicolon separator in the -i option.
Colon for *nix; semicolon for DOS/Windows.
> > > | * command line switches
> > > | * -c command line switch
> > > | * -i command line switch (a specific directory)
> > >
> > One is a config file (using the -c switch), and another is passing a
> > directory right there on the command line.
> Personally I would reword that as:
> * command line switches
> * -c <config file>
> * -i <directory of euinc.conf>
I dunno about using -i for euinc.conf; I would prefer -i to be a list of
directories to check for include files (in addition to whatever has already been
configured). Both styles of config files should accept the same syntax and -c can
specify both of them (or even one file that fills in for both).
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
9. Re: Independent Euphoria Interpreter
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> > Juergen Luethje wrote:
> > >
> > > Some comments about the updated page.
> > >
> > > On the page it currently reads:
> > > | Specifying a config file on the command line would preclude looking in
> > > | the other places.
> > >
> > > Yes, this will provide maximal flexibility.
>
> I disagree. If you run an app and it cannot find say libX, then you should
> just be able to specify where libX is on the command line, rather than
> libX, and machine.e, and win32lib/wxEuphoria, etc. Of course look where
> the command line says first, but if you do not find it I can think of no
> reason to prohibit looking elsewhere.
Yes, I've come to the same conclusion as you.
> > > Should more than one file be allowed?
> Perhaps. You might equally want a semicolon separator in the -i option.
I think I'd rather allow multiple -i's. But a semicolon on windows and
a colon on nix would work, too.
> > When we talk about 'relative paths' are you saying relative to the
> > interpreter? Does that only make sense for the local conf file? It seems
> > like you'd almost have to. What do relative paths mean for the other files?
>
> From a windows perspective, if you're running C:\euphoria\bin\exw.exe
> then obviusly it ought to look for includes in C:\euphoria\include\. I
> would therefore expect there to be a file C:\euphoria\bin\euinc.conf
> (ie same dir as exw.exe) which contains the relative path "..\include\"
> (and/or attempt that as a last resort if no config file can be found).
> IMO relative paths should be relative to the location of the .conf file
> they are specified in, and a -i relative path should be relative to the
> current directory.
Yes, the $EUDIR/include issue will likely be implicit, like it is now (which
will, of course, not work for portable/cgi, but that's what the conf files
and other command line switches are for.
> You may also want a special notation such as "%%..\include\" whereby the
> %% is replaced with the location of exu/exw.exe.
Yeah, I'd thought about something like this. Is it really necessary?
Useful? If we're going to check in the same directory as the interpreter,
then you could just put those entries in that file. And if you put it in
another conf file, then if you happen to run the wrong interpreter (maybe
because you're testing out the version you just modified and built from
source) then you could have brokenness. I'm open to it, but I'd like to
hear some more arguments on that front.
> Personally I would reword that as:
> * command line switches
> * -c <config file>
> * -i <directory of euinc.conf>
I think you missed the intent. Let's suppose that you have (all configured
and everything) your favorite win32lib (v0.60.6) set up:
-- c:\euphoria\bin\euinc.conf file:
c:\euphoria\include\win32lib
But you're interested in testing v0.71.6.h, so you put it in:
c:\euphoria\downloads\win32lib71
Now, to run your program, you could type:
> exwc -i c:\euphoria\downloads\win32lib71 myapp.exw
Now you've overridden, *for this execution only*, the version of win32lib
that you use with your application. If you find yourself doing the same
switch over and over, you probably should just put it into a conf file,
but I think it will make life a lot easier, at least for those of us
who develop the libraries, and often have need to switch back and forth.
> Lastly, can you add a note that if %APPDATA% and/or %ALLUSERSPROFILE% do
> not exist then the corresponding step is skipped (rather than crash/error
> out).
Yeah, I'll point that out.
Matt
10. Re: Independent Euphoria Interpreter
- Posted by Juergen Luethje <j.lue at gmx.??>
Dec 14, 2007
-
Last edited Dec 15, 2007
Matt Lewis wrote:
> Juergen Luethje wrote:
>
> > Some comments about the updated page.
> >
> > On the page it currently reads:
> > | Specifying a config file on the command line would preclude looking in
> > | the other places.
> >
> > Yes, this will provide maximal flexibility.
> >
> > And:
> > | Should more than one file be allowed? A system wide file could be stored
> > | in /etc/... and each user could have their own for additional directories
> > | (presumably in their home directory structure somewhere).
> >
> > What does that question mean?
> > Should more than one file be allowed to be specified on the command line?
> > No, it should be only allowed to specify either 0 or 1 config file on
> > the command line.
> > Should more than one file be allowed to exist on the hard disk?
> > Yes, that's why a smart search order is very important.
>
> Yeah, that wasn't terribly coherent. I was basically proposing something,
> and asking for comments, because I'm not sure it's the right way. Could
> you elaborate on why only one file on the command line?
>
> My thought on this is that we're basically going to maintain a sequence of
> directories in which to look for include files. Every time we encounter a
> new directory [not already in the sequence] we'll append it. When we try
> to find an include file, we'll just use this list to try to open the file.
>
> So it's not as though any of the files will step on each other with
> contradictory settings or anything.
Ah, I see now. Such a system might be advantageous.
On the other hand, scattering the list of include directories across
several config files can make it harder for the programmer to keep track
of the list, and especially of the _order_, in which the interpreter
will look at the include directories.
I'm somewhat concerned that this might cause hidden bugs that are hard
to find -- especially by newbies --, when e.g. the interpreter includes
say "test\tools.e" instead of "reliable\tools.e".
But using multiple config files would only be an additional option for
people who like to do so ... So, you've convinced me.
> Here's a question for you, since you brought it up. :)
>
> When we talk about 'relative paths' are you saying relative to the
> interpreter?
Yes, that's what I was meaning.
In the meantime, Pete wrote:
| IMO relative paths should be relative
| to the location of the .conf file they are specified in,
That sounds very reasonable as well.
> Does that only make sense for the local conf file? It seems
> like you'd almost have to. What do relative paths mean for the other files?
Hmm... good question. 
I think specifying a relative path on the command-line sometimes can
make sense, too. In the other two cases, when the interpreter reads a
config file in user-specific "typical" directory, or in a system-wide
config directory on the hard disk, I currently can't imagine any benefit
of relative paths.
> > | * command line switches (based on the order encountered on the command
> > line)
> > | o -c command line switch
> > | o -i command line switch (a specific directory)
> >
> > Can you please elaborate on this?
> > Why two different switches for specifying a config file??
>
> One is a config file (using the -c switch), and another is passing a
> directory right there on the command line. It's 'inspired' by C compilers,
>
> which do a similar thing with the -i switch (typically).
I see. And I agree that this can be useful.
>
> > The order in this list is not good:
> > A 'euinc.conf' file local to the interpreter/translator should have the
> > 2nd priority, i.e. such a config file should be more important than a
> > user-specific config file in say %APPDATA%\euphoria\.
> > All portable applications that I know, do follow this search order.
> >
> > E.g. when I have Euphoria on my USB drive, and I visit a friend who has
> > Eu installed on his PC, and I want to show one of my programs to him by
> > running it from my USB drive, then the program on the USB drive should
> > use the config file on the USB drive, and not any config file on my
> > friend's hard disk. That's the reason why this search order is important.
> >
> > So the search order should be:
> > 1) config file specified on the command line
> > 2) config file in the same directory as the interpreter/translator
> > 3) user-specific "typical" config directory on the hard disk
> > 4) "typical" system-wide config directory on the hard disk
>
> Good points. I'll update the wiki.
Thanks!
Regards,
Juergen
11. Re: Independent Euphoria Interpreter
- Posted by Juergen Luethje <j.lue at gm?.?e>
Dec 14, 2007
-
Last edited Dec 15, 2007
Pete Lomax wrote:
> Matt Lewis wrote:
> >
> > Juergen Luethje wrote:
> > >
> > > Some comments about the updated page.
> > >
> > > On the page it currently reads:
> > > | Specifying a config file on the command line would preclude looking in
> > > | the other places.
> > >
> > > Yes, this will provide maximal flexibility.
>
> I disagree. If you run an app and it cannot find say libX, then you should
> just
> be able to specify where libX is on the command line, rather than libX, and
> machine.e, and win32lib/wxEuphoria, etc. Of course look where the command line
> says first, but if you do not find it I can think of no reason to prohibit
> looking
> elsewhere.
When I specify a config file on the command line, then I should have a
special reason to do so. IMHO the command-line is not a proper place to
store default values. And when then say libX is not found, that probably
indicates that the specified config file does not contain the include
directories that I expected it to contain ... or the directories specified
in the config file do not contain the source code files that I expected
them to contain. Anyway, I think I'd prefer to get the information that
the desired stuff was not found, so that I can correct/update the config
file or the concerning include directory.
> > > Should more than one file be allowed?
> Perhaps. You might equally want a semicolon separator in the -i option.
>
> > When we talk about 'relative paths' are you saying relative to the
> > interpreter? Does that only make sense for the local conf file? It seems
> > like you'd almost have to. What do relative paths mean for the other files?
>
> From a windows perspective, if you're running C:\euphoria\bin\exw.exe then
> obviusly it ought to look for includes in C:\euphoria\include\. I would
> therefore
> expect there to be a file C:\euphoria\bin\euinc.conf (ie same dir as exw.exe)
> which contains the relative path "..\include\"
Yes, that's what I was meaning.
> (and/or attempt that as a last resort if no config file can be found).
For being able to use Euphoria as a portable app, it is important that
the interpreter looks in it's own directory for a config file *not* as a
last resort, but with a _higher priority_ than looking e.g. in %APPDATA%
or %ALLUSERSPROFILE%.
> IMO relative paths should be relative
> to the location of the .conf file they are specified in,
Very interesting idea!! I'll have to think about it more in depth.
( This will not guarantee any sound result, though. )
> and a -i relative path should be relative to the current directory.
Hmm ... I do not like the concept of "current directory".
My current directory probably changes every 10 minutes or so.
I prefer it when
cd C:\mydir
exw myapp.exw
and
exw C:\mydir\myapp.exw
exactly behave the same way, so that it's not necessary to change the
current directory in order to achive a specific result.
And when using a file manager such as Total Commander (TC) instead of
the Windows Explorer, does then displaying a particular directory also
mean that this one now is the "current directory"? As far as TC is
concerned, the answer by it's author is "yes". But what about all the
other file managers out there?
> You may also want a special notation such as "%%..\include\" whereby the %%
> is replaced with the location of exu/exw.exe.
>
> > > | * command line switches
> > > | * -c command line switch
> > > | * -i command line switch (a specific directory)
> > >
> > One is a config file (using the -c switch), and another is passing a
> > directory right there on the command line.
> Personally I would reword that as:
> * command line switches
> * -c <config file>
> * -i <directory of euinc.conf>
>
> Lastly, can you add a note that if %APPDATA% and/or %ALLUSERSPROFILE% do not
> exist then the corresponding step is skipped (rather than crash/error out).
Yes, of course. For instance, if not config file is found, this would be
the same as if we now have "empty" EUDIR and EUINC environment variables.
That shouldn't cause a crash.
Regards,
Juergen
12. Re: Independent Euphoria Interpreter
- Posted by Matt Lewis <matthewwalkerlewis at gma?l.com>
Dec 14, 2007
-
Last edited Dec 15, 2007
Juergen Luethje wrote:
>
> Pete Lomax wrote:
>
> >
> > I disagree. If you run an app and it cannot find say libX, then you should
> > just
> > be able to specify where libX is on the command line, rather than libX, and
> > machine.e, and win32lib/wxEuphoria, etc. Of course look where the command
> > line
> > says first, but if you do not find it I can think of no reason to prohibit
> > looking
> > elsewhere.
>
> When I specify a config file on the command line, then I should have a
> special reason to do so. IMHO the command-line is not a proper place to
> store default values. And when then say libX is not found, that probably
> indicates that the specified config file does not contain the include
> directories that I expected it to contain ... or the directories specified
> in the config file do not contain the source code files that I expected
> them to contain. Anyway, I think I'd prefer to get the information that
> the desired stuff was not found, so that I can correct/update the config
> file or the concerning include directory.
I can see a useful utility that would list out the include directories.
We could even add a special switch that would have the interpreter (or
translator) print out the directories in the order they will be searched.
But if it's not found, then you should get a dump of all of the directories,
and we can print them out in the correct order.
> For being able to use Euphoria as a portable app, it is important that
> the interpreter looks in it's own directory for a config file *not* as a
> last resort, but with a _higher priority_ than looking e.g. in %APPDATA%
> or %ALLUSERSPROFILE%.
Yes, that's how I've got it coded, and I've fixed the wiki to reflect this.
> > IMO relative paths should be relative
> > to the location of the .conf file they are specified in,
>
> Very interesting idea!! I'll have to think about it more in depth.
> ( This will not guarantee any sound result, though. )
It should probably be considered bad practice to use relative paths in
general, although I can see that it would be helpful in some cases. I
can imagine a library developer possibly shipping these, as it would
make their directory structure more portable, and wouldn't require that
people change their system settings to try out the demos that come with
a library.
> > and a -i relative path should be relative to the current directory.
>
> Hmm ... I do not like the concept of "current directory".
> My current directory probably changes every 10 minutes or so.
> I prefer it when
> cd C:\mydir
> exw myapp.exw
> and
> exw C:\mydir\myapp.exw
> exactly behave the same way, so that it's not necessary to change the
> current directory in order to achive a specific result.
Since the -i is a command line only thing, the 'current directory' would
be wherever you ran the command. If it's a problem, then don't use a
relative path in the command line.
Matt
13. Re: Independent Euphoria Interpreter
Matt Lewis wrote:
> Juergen Luethje wrote:
> >
> > Pete Lomax wrote:
> >
> > >
> > > I disagree. If you run an app and it cannot find say libX, then you should
> > > just
> > > be able to specify where libX is on the command line, rather than libX,
> > > and
> > > machine.e, and win32lib/wxEuphoria, etc. Of course look where the command
> > > line
> > > says first, but if you do not find it I can think of no reason to prohibit
> > > looking
> > > elsewhere.
> >
> > When I specify a config file on the command line, then I should have a
> > special reason to do so. IMHO the command-line is not a proper place to
> > store default values. And when then say libX is not found, that probably
> > indicates that the specified config file does not contain the include
> > directories that I expected it to contain ... or the directories specified
> > in the config file do not contain the source code files that I expected
> > them to contain. Anyway, I think I'd prefer to get the information that
> > the desired stuff was not found, so that I can correct/update the config
> > file or the concerning include directory.
>
> I can see a useful utility that would list out the include directories.
> We could even add a special switch that would have the interpreter (or
> translator) print out the directories in the order they will be searched.
>
> But if it's not found, then you should get a dump of all of the directories,
> and we can print them out in the correct order.
That sounds good to me.
> > For being able to use Euphoria as a portable app, it is important that
> > the interpreter looks in it's own directory for a config file *not* as a
> > last resort, but with a _higher priority_ than looking e.g. in %APPDATA%
> > or %ALLUSERSPROFILE%.
>
> Yes, that's how I've got it coded, and I've fixed the wiki to reflect this.
Wow, you're fast!
> > > IMO relative paths should be relative
> > > to the location of the .conf file they are specified in,
> >
> > Very interesting idea!! I'll have to think about it more in depth.
> > ( This will not guarantee any sound result, though. )
>
> It should probably be considered bad practice to use relative paths in
> general, although I can see that it would be helpful in some cases. I
> can imagine a library developer possibly shipping these, as it would
> make their directory structure more portable, and wouldn't require that
> people change their system settings to try out the demos that come with
> a library.
When running Euphoria from a portable device, at least for usage on
Windows, writing relative paths into the config file(s) is the only
working possibility, because it's not predictable what drive letter
the device will have when it will be used next time.
> > > and a -i relative path should be relative to the current directory.
> >
> > Hmm ... I do not like the concept of "current directory".
> > My current directory probably changes every 10 minutes or so.
> > I prefer it when
> > cd C:\mydir
> > exw myapp.exw
> > and
> > exw C:\mydir\myapp.exw
> > exactly behave the same way, so that it's not necessary to change the
> > current directory in order to achive a specific result.
>
> Since the -i is a command line only thing, the 'current directory' would
> be wherever you ran the command.
The problem is, that I sometimes do not know "where I am", i.e. what the
so called "current directory" is. I already had given examples. Another
one: When I chose on Windows 'Start' > 'Run', then a small input box opens,
where I can enter a command. What is the "current directory" then?
> If it's a problem, then don't use a relative path in the command line.
Newbies can only avoid this problem, if they are aware that it is a
problem. IMHO it would be better not to introduce this problem, by not
using the concept of "current directory".
Regards,
Juergen
14. Re: Independent Euphoria Interpreter
Juergen Luethje wrote:
>
> Matt Lewis wrote:
> >
> > Yes, that's how I've got it coded, and I've fixed the wiki to reflect this.
>
> Wow, you're fast!
And now I've committed my first version of the code (works for interpreter
and translator--need to update the binder).
To get the code:
$ svn export https://rapideuphoria.svn.sf.net/svnroot/rapideuphoria/branches/nix
rdsnix
(will put the source into a new subdirectory of the current dir)
So far, I've only tested it on Linux, but it should work on windows
(the code is there for the appropriate environment variables). The
interesting stuff is mainly in pathopen.e for the interested.
I've also added the built-in option_switches() to get any command line
arguments passed to the interpreter/compiler before the file name.
> > It should probably be considered bad practice to use relative paths in
> > general, although I can see that it would be helpful in some cases. I
> > can imagine a library developer possibly shipping these, as it would
> > make their directory structure more portable, and wouldn't require that
> > people change their system settings to try out the demos that come with
> > a library.
>
> When running Euphoria from a portable device, at least for usage on
> Windows, writing relative paths into the config file(s) is the only
> working possibility, because it's not predictable what drive letter
> the device will have when it will be used next time.
Yes, portable (and possibly cgi--don't know enough about that mode of
operation) are the main exceptions that I had in mind. But since
they're in the euinc.conf files, the relativity is easily defined and
understood.
> > > > and a -i relative path should be relative to the current directory.
> > >
> > > Hmm ... I do not like the concept of "current directory".
> > > My current directory probably changes every 10 minutes or so.
> > > I prefer it when
> > > cd C:\mydir
> > > exw myapp.exw
> > > and
> > > exw C:\mydir\myapp.exw
> > > exactly behave the same way, so that it's not necessary to change the
> > > current directory in order to achive a specific result.
> >
> > Since the -i is a command line only thing, the 'current directory' would
> > be wherever you ran the command.
>
> The problem is, that I sometimes do not know "where I am", i.e. what the
> so called "current directory" is. I already had given examples. Another
> one: When I chose on Windows 'Start' > 'Run', then a small input box opens,
> where I can enter a command. What is the "current directory" then?
No clue. We'll have to try it and see what happens. :)
I guess I'd probably tell you that if it doesn't work, you should probably
open up a console and do it that way if you really want to do it that
way. Or just use an absolute path. Auto-complete is your friend in
that case.
> > If it's a problem, then don't use a relative path in the command line.
>
> Newbies can only avoid this problem, if they are aware that it is a
> problem. IMHO it would be better not to introduce this problem, by not
> using the concept of "current directory".
Yes, the documentation will be important, but I think it's better to try
to follow the principle of least surprise. You'll be able to see what
directory it thought it should look in within the error message, so it
shouldn't be complete voodoo. In any case, this is where testing will
be important, so we can get both the code and the documentation correct.
Matt
15. Re: Independent Euphoria Interpreter
Juergen Luethje wrote:
>
> When running Euphoria from a portable device, at least for usage on
> Windows, writing relative paths into the config file(s) is the only
> working possibility, because it's not predictable what drive letter
> the device will have when it will be used next time.
>
Absolutely agreed.
<snip>
>
> The problem is, that I sometimes do not know "where I am"
I'm confused. Why would you ever use relative directories in such case?
> I already had given examples.
Umm, the only thing I can find is:
> Hmm ... I do not like the concept of "current directory".
> My current directory probably changes every 10 minutes or so.
> I prefer it when
> cd C:\mydir
> exw myapp.exw
> and
> exw C:\mydir\myapp.exw
> exactly behave the same way, so that it's not necessary to change the
> current directory in order to achive a specific result.
which I do not understand any better; one is using a relative filename and one
is using an absolute, and does not change what I said above.
> > If it's a problem, then don't use a relative path in the command line.
>
> Newbies can only avoid this problem, if they are aware that it is a
> problem. IMHO it would be better not to introduce this problem, by not
> using the concept of "current directory".
What you are saying to me in all that is this:
1. I've got a project in C:\My Documents and Folders\My Latest Whizmo.
2. I've put some files in ""\tmp.
3. I *CANNOT* type exw -i tmp\ main.exw but instead *FORCED* into entering
exw -i "C:\My Documents and Folders\My Latest Whizmo\tmp" main.exw???!!?
Why?
Also, why are relative directories in .conf files somehow *less* confusing than
those on the command line? What happens when some edjut newbie decides to move a
.conf file? Is that not far harder to solve than a -i option?
Confused,
Pete
PS Relative directories *ARE* potentially confusing, we know.
They are also damn handy, like as in yer first point.
16. Re: Independent Euphoria Interpreter
Pete Lomax wrote:
> Juergen Luethje wrote:
>
> > When running Euphoria from a portable device, at least for usage on
> > Windows, writing relative paths into the config file(s) is the only
> > working possibility, because it's not predictable what drive letter
> > the device will have when it will be used next time.
> >
> Absolutely agreed.
> <snip>
> >
> > The problem is, that I sometimes do not know "where I am"
> I'm confused. Why would you ever use relative directories in such case?
It can happen by accident. In the same post, a few lines later I wrote:
| Newbies can only avoid this problem, if they are aware that it is a
| problem.
> > I already had given examples.
> Umm, the only thing I can find is:
> > Hmm ... I do not like the concept of "current directory".
> > My current directory probably changes every 10 minutes or so.
> > I prefer it when
> > cd C:\mydir
> > exw myapp.exw
> > and
> > exw C:\mydir\myapp.exw
> > exactly behave the same way, so that it's not necessary to change the
> > current directory in order to achive a specific result.
I was referring to the following text, which I wrote previously:
| And when using a file manager such as Total Commander (TC) instead of
| the Windows Explorer, does then displaying a particular directory also
| mean that this one now is the "current directory"? As far as TC is
| concerned, the answer by it's author is "yes". But what about all the
| other file managers out there?
> Also, why are relative directories in .conf files somehow *less* confusing
> than
> those on the command line?
I didn't write something like that. It seems to be a misunderstanding.
> What happens when some edjut newbie decides to move
> a .conf file?
This might cause severe problems when we decide to use concept b)
(below), but less likely with concept a).
> Is that not far harder to solve than a -i option?
>
> Confused,
> Pete
>
> PS Relative directories *ARE* potentially confusing, we know.
> They are also damn handy, like as in yer first point.
Concerning relative directories, the question "Relative to what?" must
be answered unambiguously, and the Eu programmer should know the answer.
Sound concepts are IMHO:
a) relative to the location of the currently running instance of the
interpreter/translator
b) relative to the location of the .conf file they are specified in
(as you suggested)
No good concept is IMHO:
c) relative to the "current directory"
That's what I wrote before. I didn't write anything against an -i option
or against relative directories on the command-line.
The contrary is true. When Matt asked for my opinion, I replied:
| I think specifying a relative path on the command-line sometimes can
| make sense, too.
But IMHO relative directories (on the command-line or elsewhere) should
_not be relative to the so called "current directory"_. Because
sometimes it's not clear what the "current directory" is. See example
above concerning file managers. I had given another example:
| When I chose on Windows 'Start' > 'Run', then a small input box opens,
| where I can enter a command. What is the "current directory" then?
Also, according to the principle of least surprise, when we use relative
paths for specifiying the Eu configuration, we should only use _one_ of
the concepts a), b), or c) above!
When e.g. a relative path in a config file is relative to the location
of the interpreter, and a relative path on the command-line is relative
to the "current directory", this would be a good source of confusion.
Regards,
Juergen
17. Re: Independent Euphoria Interpreter
Matt Lewis wrote:
> Juergen Luethje wrote:
>
> > Matt Lewis wrote:
> > >
> > > Yes, that's how I've got it coded, and I've fixed the wiki to reflect
> > > this.
> >
> > Wow, you're fast!
>
> And now I've committed my first version of the code (works for interpreter
> and translator--need to update the binder).
>
> To get the code:
> $ svn export
> <https://rapideuphoria.svn.sf.net/svnroot/rapideuphoria/branches/nix>
> rdsnix
> (will put the source into a new subdirectory of the current dir)
>
> So far, I've only tested it on Linux, but it should work on windows
> (the code is there for the appropriate environment variables). The
> interesting stuff is mainly in pathopen.e for the interested.
>
> I've also added the built-in option_switches() to get any command line
> arguments passed to the interpreter/compiler before the file name.
Matt, thank you one more time for your engagement and ongoing work with
improving Euphoria!
I personally still have no SVN access, and unfortunately I also have
almost no free time currently. When I'm back in town next year, and when
there'll be a ZIP file for download, then I'll be happy to test the new
stuff.
> > > It should probably be considered bad practice to use relative paths in
> > > general, although I can see that it would be helpful in some cases. I
> > > can imagine a library developer possibly shipping these, as it would
> > > make their directory structure more portable, and wouldn't require that
> > > people change their system settings to try out the demos that come with
> > > a library.
> >
> > When running Euphoria from a portable device, at least for usage on
> > Windows, writing relative paths into the config file(s) is the only
> > working possibility, because it's not predictable what drive letter
> > the device will have when it will be used next time.
>
> Yes, portable (and possibly cgi--don't know enough about that mode of
> operation) are the main exceptions that I had in mind. But since
> they're in the euinc.conf files, the relativity is easily defined and
> understood.
>
> > > > > and a -i relative path should be relative to the current directory.
> > > >
> > > > Hmm ... I do not like the concept of "current directory".
> > > > My current directory probably changes every 10 minutes or so.
> > > > I prefer it when
> > > > cd C:\mydir
> > > > exw myapp.exw
> > > > and
> > > > exw C:\mydir\myapp.exw
> > > > exactly behave the same way, so that it's not necessary to change the
> > > > current directory in order to achive a specific result.
> > >
> > > Since the -i is a command line only thing, the 'current directory' would
> > > be wherever you ran the command.
> >
> > The problem is, that I sometimes do not know "where I am", i.e. what the
> > so called "current directory" is. I already had given examples. Another
> > one: When I chose on Windows 'Start' > 'Run', then a small input box opens,
> > where I can enter a command. What is the "current directory" then?
>
> No clue. We'll have to try it and see what happens. :)
>
> I guess I'd probably tell you that if it doesn't work, you should probably
> open up a console and do it that way if you really want to do it that
> way. Or just use an absolute path. Auto-complete is your friend in
> that case.
>
> > > If it's a problem, then don't use a relative path in the command line.
> >
> > Newbies can only avoid this problem, if they are aware that it is a
> > problem. IMHO it would be better not to introduce this problem, by not
> > using the concept of "current directory".
>
> Yes, the documentation will be important, but I think it's better to try
> to follow the principle of least surprise. You'll be able to see what
> directory it thought it should look in within the error message, so it
> shouldn't be complete voodoo. In any case, this is where testing will
> be important, so we can get both the code and the documentation correct.
Following the principle of least surprise IMHO would mean in this case,
that relative paths are always relative to the same reference point.
When e.g. a relative path in a config file is relative to the location
of the interpreter, and a relative path on the command-line is relative
to the "current directory", this would be a good source of confusion.
The least confusing concept in this context IMHO is, that "relative" will
mean "relative to the location of the currently running instance of the
interpreter/translator".
Regards,
Juergen
