1. Real world example of the includes-with-the-same-name "bug"
There's often much debate and complaining on the
includes-with-the-same-name-in-other-directories-are-treated-as-the-same-file
"bug" and many examples of why many people (myself included) consider this a bad
thing. However, many examples are theoretical or trivial but today at work I ran
into the limitations of this bug head on.
We have this Matlab program at my job that was written years ago by one of our
research specialists that we use to locate underwater moorings. I've been the
sole maintainer of this program for years since the other guy doesn't have the
time to work on it. A couple years ago I was requested to write a Perl script to
install it on people's computers (just for the Windows users, the Linux users are
usually smart enough not to need it).
During my winter break from college I did a minor update of this program and am
now working on updating the installer. Since I now have a deep dislike of Perl
(that's probably Euphoria's fault) I decided to rewrite the program in Euphoria
(yaay!). I was making good headway until today when my progress was brutally
stopped at work today by the "bug".
Before this week the installer was a one-file Perl script that unzipped the
program, installed some libraries, changed the path in the registry to point to
the libraries, and created a shortcut to the program and moved it to the desktop.
This new version will also go through the system path and see if there are any
old versions of the library installed and it'll then uninstall them.
Right now I have the searching the path, uninstalling the libraries, and setting
the path part of the install pretty much done using Davi de Figueiredo's registry
wrappers (which work quite well I might add). After I finished writing those
parts I started work on the part that unpacked the program itself. Before we
distributed the program as a zip file with the installation program which simply
unzipped it and set the path and everything. I tried to do the same thing but the
only good unzipping routines don't seem to like the file (again, they are from
Davi and I've sent him a bug report).
After messing with unzipping files I then tried to embed my files in the program
itself by using Davi's file2eu program (another excellent program, the fact that
he's made every file I've used on this project so far is pretty amazing). I wrote
a script that gets the contents of a directory and for every filename in the
directory makes an include file with the file contents as a massive sequence. I
needed this not only to simplify stuff but also so anybody else can generate
these files if I ever leave (I'm the only Euphoria programmer we have AFAIK). It
also goes through directories recursively and mirrors that structure in the file
where the new include files are stored.
Well, at this point I think you can guess where the problem will occur. After
running this I now had a directory full of include files with subdirectories for
the subdirectories of the program. So, I now run my test install script which
promptly crashes.
The reason for the problem is that the program consists of the main directory
with the execuable files and the resource files and there's a directory inside
that which contains the source. However, since it's a Matlab program and Matlab
programs are usually meant to be used through the Matlab shell and our users are
scientists who know Matlab we decided to include the source for them to look at
and modify if need be. To make the source directory self sufficient all the
example and resource files are in there as well but may not be the same because
of minor differences between compiled and interpreted Matlab. Sadly, since the
files are stored in separate include files sorted by directory the files do not
translate correctly and the installation fails.
I know this is a fairly domain-specific and convoluted example and I have found
a way around this but it does illustrate that this is a limitation and a
limitation that has real-world consequences (imagine if I didn't test it, I
could've lost my job!).
This isn't a rant or a demand for change from Rob (although it would be nice...)
just a friendly reminder to anyone who uses Euphoria scripts to write larger
Euphoria programs that you need to check your includes! 
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
2. Re: Real world example of the includes-with-the-same-name "bug"
1. There are many free and commercial installer packages, why waste time
writing one when it takes 5 minutes to create a professional install using
InstallShield or Wise.
2. I have never ran into the bug you mentioned, and I have written huge
programs in EU. For Example my application Rhyme & Verse has over 21,000
lines of code in the main file, and over 83 include files.
----If you continue to do what you have always done,
you will get what you have always gotten.----
3. Re: Real world example of the includes-with-the-same-name "bug"
- Posted by Vincent <darkvincentdude at yahoo.com>
Jan 19, 2006
-
Last edited Jan 20, 2006
C Bouzy wrote:
> I have never ran into the bug you mentioned, and I have written huge
> programs in EU. For Example my application Rhyme & Verse has over 21,000
> lines of code in the main file, and over 83 include files.
Hi Chris,
Well first of all it isn't a bug, it was intentially designed that way for
internal simplicity. This is a problematic design as discusted before.
Robert wouldn't change it, so I took matters in my own hands. I got it to work
but it is a difficult to resolve every possiblility of full length paths being
different.
I've spent three days far writing code to remove trailing slashes and dots,
converting them to either "\\" or "/", building full paths for main and relative
path when main_path is ".\\" and "./", rewriting path_open() and removing remove
name_ext() in specific places. I also been doing alot of testing too.
I can do some wacky stuff like:
include "C:/\\Documents and Settings\\//\\/\Vincent////\\/\\\\Ic\\//\\Try.e"
include ".////////Ic///\\\\\\/Try.e"
include .////\\//Ic//\\\\/Try.e
include "\\\/\\Ic////Try.e"
include "//Ic///Try.e"
include .\Ic\Try.e
include ./Ic/Try.e
include Ic/\Try.e
include Ic\Try.e
... so on ...
And it recoginize that they all are the same file and directory thus including
it only once. Yet I could use a different path and it will treat "Try.e" as a
seperate file with possibly different contents;
It will fail if the paths dont exist as usual.
There are a couple minor issues that I'm working out before I send my source to
Robert Craig for inspection and hopefully implementation into Euphoria v3.0.
Regards,
Vincent
4. Re: Real world example of the includes-with-the-same-name "bug"
- Posted by C Bouzy <eucoder at hotmail.com>
Jan 19, 2006
-
Last edited Jan 20, 2006
Vincent wrote:
>
> Hi Chris,
>
> Well first of all it isn't a bug, it was intentially designed that way for
> internal
> simplicity. This is a problematic design as discusted before.
I was going by the title name...
> There are a couple minor issues that I'm working out before I send my source
> to Robert Craig for inspection
> and hopefully implementation into Euphoria v3.0.
>
I do not see why he wouldn't add it, I personally think it would be a good
addition, although I almost always put my include files in the same folder.
----If you continue to do what you have always done,
you will get what you have always gotten.----
5. Re: Real world example of the includes-with-the-same-name "bug"
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 19, 2006
-
Last edited Jan 20, 2006
C Bouzy wrote:
>
> Vincent wrote:
> >
>
> > Hi Chris,
> >
> > Well first of all it isn't a bug, it was intentially designed that way for
> > internal
> > simplicity. This is a problematic design as discusted before.
>
> I was going by the title name...
>
>
> > There are a couple minor issues that I'm working out before I send my source
> to Robert Craig for inspection</font></i>
> > and hopefully implementation into Euphoria v3.0.
> >
>
> I do not see why he wouldn't add it, I personally think it would be a good
> addition, although I almost always put my include files in the same folder.
>
>
> ----If you continue to do what you have always done,
> you will get what you have always gotten.----
This started working in one of the 2.5 alpha or beta interpreters, but he
squashed it as soon as it was pointed out.
He doesn't want the interpreter to work this way.
And it wasn't designed for "internal simplicity".
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
6. Re: Real world example of the includes-with-the-same-name "bug"
Jason Gade wrote:
> This started working in one of the 2.5 alpha or beta interpreters, but he
> squashed
> it as soon as it was pointed out.
It worked with Euphoria v2.4 and older when the foward slashes were used. Robert
has changed it in 2.5 after a quick decision. I think he knew about it for quite
awile but probably was reluctant to change it in fear of angering Chris Bensler
and others. :P
I think he changed it because the way it worked was by a glitch and wasn't
designed to do that and only worked when using foward slashes and no quotes (no
absolute paths). It was alot easier for Rob to fix it the normal than to go with
the proper solution.
> He doesn't want the interpreter to work this way.
> And it wasn't designed for "internal simplicity".
He didn't want to add code to resolve slashes, dots, etc. or build full paths
from relative and main path directories.
I think he would prefer the proper way, but just doesnt see it as a big enough
issue to warrent the extra hassle fixing it. I'll make it very simple for him.
All he needs to do is backup his scanner.e and replace it with mine. My scanner.e
is based on the multi-tasking PD-source update. So there shouldn't be any issues
unless he's modified his copy since then. If he did, it would be simple for him
to copy and paste his modified code into the my scanner.e or visa versa. He can
remove my comment tags if he likes.
BTW... I was able to get the largest Win32Lib (IDE too), wxEuphoria, FluidAE,
etc. programs to load correctly, so that means everything is pretty dang stable,
though I ran into a several bugs in the beginning but fixed them quickly.
I want to refine the slash scanner a little more and maybe optimize the code a
little before release it (there is no noticable difference in loading time).
Regards,
Vincent
7. Re: Real world example of the includes-with-the-same-name "bug"
Vincent wrote:
>
> Jason Gade wrote:
>
> > This started working in one of the 2.5 alpha or beta interpreters, but he
> > squashed
> > it as soon as it was pointed out.
>
> It worked with Euphoria v2.4 and older when the foward slashes were used.
> Robert
> has changed it in 2.5 after a quick decision. I think he knew about it for
> quite
> awile but probably was reluctant to change it in fear of angering Chris
> Bensler
> and others. :P
>
> I think he changed it because the way it worked was by a glitch and wasn't
> designed
> to do that and only worked when using foward slashes and no quotes (no
> absolute
> paths). It was alot easier for Rob to fix it the normal than to go with the
> proper solution.
>
> > He doesn't want the interpreter to work this way.
> > And it wasn't designed for "internal simplicity".
>
> He didn't want to add code to resolve slashes, dots, etc. or build full paths
> from relative and main path directories.
I'm not sure what you mean here. Relative and absolute paths already work
properly. They use the OS file routines which resolve this automatically, I
believe.
>
> I think he would prefer the proper way, but just doesnt see it as a big enough
> issue to warrent the extra hassle fixing it. I'll make it very simple for him.
> All he needs to do is backup his scanner.e and replace it with mine. My
> scanner.e
> is based on the multi-tasking PD-source update. So there shouldn't be any
> issues
> unless he's modified his copy since then. If he did, it would be simple for
> him to copy and paste his modified code into the my scanner.e or visa versa.
> He can remove my comment tags if he likes.
>
> BTW... I was able to get the largest Win32Lib (IDE too), wxEuphoria, FluidAE,
> etc. programs to load correctly, so that means everything is pretty dang
> stable,
> though I ran into a several bugs in the beginning but fixed them quickly.
>
> I want to refine the slash scanner a little more and maybe optimize the code
> a little before release it (there is no noticable difference in loading time).
>
>
> Regards,
> Vincent
I think we're talking about different things -- I'm not sure. I didn't think
Euphoria had any problems with slashes and backslashes and dots. I just tested it
and it worked as I expected.
What I thought we were talking about is this: (from the manual)
-- quote --
Other than possibly defining a new namespace identifier (see below), an include
statement will be quietly ignored if a file with the same name (but possibly
located in a different directory) has already been included.
-- quote --
This is the behavior that is considered a 'bug' by almost everyone except Rob.
*I* think that programs could be both more modular and/or more object-oriented
if it worked as follows:
* Quietly ignored if the *exact* same file is included twice without a namespace
identifier
* Treated as separate files if a namespace identifier *is* included
* Treated as separate files if includes are in a different path
* Give a warning and/or an error if there is a global symbol conflict and no
namespace identifier in the above cases
I think this is the major reason why Derek Parnell left -- it was considered a
bug by Rob Craig and a great feature by almost everyone else.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
8. Re: Real world example of the includes-with-the-same-name "bug"
Jason Gade wrote:
> I'm not sure what you mean here. Relative and absolute paths already work
> properly.
> They use the OS file routines which resolve this automatically, I believe.
Correct, but I have to convert the "new_include_name" strings into a full paths
otherwise they wont compare correctly.
> I think we're talking about different things -- I'm not sure. I didn't think
> Euphoria had any problems with slashes and backslashes and dots. I just tested
> it and it worked as I expected.
>
> What I thought we were talking about is this: (from the manual)
>
> -- quote --
> Other than possibly defining a new namespace identifier (see below), an
> include
> statement will be quietly ignored if a file with the same name (but possibly
> located in a different directory) has already been included.
> -- quote --
>
> This is the behavior that is considered a 'bug' by almost everyone except Rob.
>
> *I* think that programs could be both more modular and/or more object-oriented
> if it worked as follows:
>
> * Quietly ignored if the *exact* same file is included twice without a
> namespace
> identifier
> * Treated as separate files if a namespace identifier *is* included
> * Treated as separate files if includes are in a different path
> * Give a warning and/or an error if there is a global symbol conflict and no
> namespace identifier in the above cases
>
> I think this is the major reason why Derek Parnell left -- it was considered
> a bug by Rob Craig and a great feature by almost everyone else.
>
> --
> "The author regrets that he is unable to reconcile himself to the
> thoughtful point of view you have expressed. However, it must be kept
> in mind that being raised in different cultures and different places can
> result in such differences of viewpoint between individuals.
> The author is from planet Earth." [author unknown]
>
> j.
My system basically treats all files with the same name but located in different
directories as different files. Including the same file in the same directory
more than once will ignore the consecutive callings. The functionability your
talking about is known as instance including (I believe) and would be simple to
implement when namespace identifers are used.
Regards,
Vincent
9. Re: Real world example of the includes-with-the-same-name "bug"
Vincent wrote:
>
> Jason Gade wrote:
>
> > I'm not sure what you mean here. Relative and absolute paths already work
> > properly.
> > They use the OS file routines which resolve this automatically, I believe.
>
> Correct, but I have to convert the "new_include_name" strings into a full
> paths
> otherwise they wont compare correctly.
<snip>
I see a little better where you are going with this and some of the
possibilities for error. I think I would handle it differently though. Two
different solutions:
1. Surely the OS and/or the C library for Watcom has a function that returns the
full path of a file given the relative path. No need for the program to parse.
Just compare.
-or-
2. In cases where the filename is the same, compare file sizes. If they are the
same then issue a warning or error saying the user is probably trying to include
the exact same file twice.
Of course, barring using someone's library, if I tried to specify the same file
path by using two different strings I should be slapped. 
> Regards,
> Vincent
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
10. Re: Real world example of the includes-with-the-same-name "bug"
Jason Gade wrote:
>
> Vincent wrote:
> >
> > Jason Gade wrote:
> >
> > > I'm not sure what you mean here. Relative and absolute paths already work
> > > properly.
> > > They use the OS file routines which resolve this automatically, I believe.
> >
> > Correct, but I have to convert the "new_include_name" strings into a full
> > paths
> > otherwise they wont compare correctly.
>
> <snip>
>
> I see a little better where you are going with this and some of the
> possibilities
> for error. I think I would handle it differently though. Two different
> solutions:
>
> 1. Surely the OS and/or the C library for Watcom has a function that returns
> the full path of a file given the relative path. No need for the program to
> parse. Just compare.
>
> -or-
>
> 2. In cases where the filename is the same, compare file sizes. If they are
> the same then issue a warning or error saying the user is probably trying to
> include the exact same file twice.
>
> Of course, barring using someone's library, if I tried to specify the same
> file
> path by using two different strings I should be slapped.
>
> > Regards,
> > Vincent
Another thing is that in Linux you can have soft links, which are like an alias
for a file. So you could do the following and still end up (accidentally)
including the same file twice:
include foo/bar -- original file
include baz/moo -- softlink to foo/bar
Hmmm. I wonder if this works in Euphoria for Linux right now...
Again, I think Linux has OS functions for resolving this.
--
"The author regrets that he is unable to reconcile himself to the
thoughtful point of view you have expressed. However, it must be kept
in mind that being raised in different cultures and different places can
result in such differences of viewpoint between individuals.
The author is from planet Earth." [author unknown]
j.
11. Re: Real world example of the includes-with-the-same-name "bug"
- Posted by Vincent <darkvincentdude at yahoo.com>
Jan 20, 2006
-
Last edited Jan 21, 2006
Jason Gade wrote:
> Another thing is that in Linux you can have soft links, which are like an
> alias
> for a file. So you could do the following and still end up (accidentally)
> including
> the same file twice:
>
> include foo/bar -- original file
> include baz/moo -- softlink to foo/bar
>
I haven't tested the system on linux yet, but you can be sure I will. I'll
probably test it on Damn Small Linux v2.1.
Regards,
Vincent
