1. Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
Rob, I believe you said that in Euphoria 2.5, the front or back slashes
in the path of the include statment will work the same.
include \RDS\Includes\File.e -- example
will work the same as:
include /RDS/Include/File.e -- example
so that fixes 1 of the 2 problems that should be fixed for 2.5
relating to the include statement.
The other thing is when using a path contained in double quotes,
for use with the include statement, another "problem" arises. When
trying to include a file that is named the same as another file
from a different folder that someone may try to use. The interpretter
only reads the first file and skips the second.
Example:
Lets say Try.e in folder named File1 has this code in it:
puts(1, "This is Try.e in folder File1\n")
And say Try.e in folder named File2 has this code:
puts(1, "This is Try.e in folder File2\n")
The lets say in a different folder I make a Eu program called
Tester.ex, and have this code in it:
include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
machine_proc(26,0)
then I save and run the program this would be the output:
**This is Try.e in folder File1**
while skipping the second include.
I understand that this is documented in the refrence manual, and is
meant to be that way. But think of this, imagine EU being extremely
succesful and having lots of active users making contributions like
librarys for example. And say one may have a library or w/e someone
wants but has a include file that is named the same as another
include file in a different folder for a different librarty.
Lets say you need both librarys in a program that you are making
but if you try renaming the files you would screw up the library
and would have to modify code in order to fix that wasting time
which for some also mean money. If you could include 2 files
or more of the same name but in different paths and or directory
this I believe can be avoided unless I figured wrong.
Another reason why I mention this is because this issue doesnt
exist if I modified for example, test.ex to be this:
Example:
include /File1/Try.e
include /File2/Try.e
machine_proc(26,0)
then the output would be:
**This is Try.e in folder File1**
**This is Try.e in folder File2**
thus proving that doing it that way works however if I changed
test.ex to this:
include \File1\Try.e
include \File2\Try.e
machine_proc(26,0)
I get an error saying that it cant open Try.e which is an example
of the other problem with '\' and '/' not working the same, which
you said is already fixed in EU 2.5 :).
To sum all this up I really think that EU's include statement should
be able to read 2 or more files of the same name but in different
folders or directories and include each file and include them
as seperate files and not just the first
one. And allow it for all the ways to use the include statement.
And to do this before the Euphoria 2.5 offical release
Examples:
include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
include /File1/Try.e
include /File2/Try.e
include \File1\Try.e
include \File1\Try.e
------------------------------------------------------------------------
Should all treat Try.e in File1 and Try.e in File2 as seperate files.
Fixing this could save people headache in the future if or when EU
becomes popular enough and has a large enough community where an issue
like this may arise, plus it would give people the piece of mind to know
that this problem is fixed (especially me).
Besides I think this should be an easy thing to fix Rob, just modify the
interpretter source code a little and change just a tiny part of the
Include section in the refrence manual then it should be all good.
And even if it takes a little time to fix I think most people would be
willing to wait for EU 2.5 just a little while more for this fix
(after all they waited like 1-2 years already :}) so a little
longer if nessasary wouldnt hert any. Specially since this was
a big topic in the EU forum not to long ago.
And like you said before Rob, any further ideas can be considered
in Euphoria 2.6.
I would very much appreciative if you definatly consider this
before realeasing EU 2.5 (or at least the final offical version).
Thankyou very much for spending time reading this.
Vincent
2. Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
- Posted by CoJaBo <cojabo at suscom.net>
Nov 05, 2004
-
Last edited Nov 06, 2004
No response... Further enforcing the theory
that Rob is ignoring us...
Vincent wrote:
>
> Rob, I believe you said that in Euphoria 2.5, the front or back slashes
> in the path of the include statment will work the same.
>
> }}}
<eucode>
> include \RDS\Includes\File.e -- example
> </eucode>
{{{
> will work the same as:
> }}}
<eucode>
> include /RDS/Include/File.e -- example
> </eucode>
{{{
>
> so that fixes 1 of the 2 problems that should be fixed for 2.5
> relating to the include statement.
>
> The other thing is when using a path contained in double quotes,
> for use with the include statement, another "problem" arises. When
> trying to include a file that is named the same as another file
> from a different folder that someone may try to use. The interpretter
> only reads the first file and skips the second.
>
> Example:
>
> Lets say Try.e in folder named File1 has this code in it:
> }}}
<eucode>
> puts(1, "This is Try.e in folder File1\n")
> </eucode>
{{{
> And say Try.e in folder named File2 has this code:
> }}}
<eucode>
> puts(1, "This is Try.e in folder File2\n")
> </eucode>
{{{
>
> The lets say in a different folder I make a Eu program called
> Tester.ex, and have this code in it:
> }}}
<eucode>
> include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
> include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
> machine_proc(26,0)
> </eucode>
{{{
> then I save and run the program this would be the output:
>
> **This is Try.e in folder File1**
>
> while skipping the second include.
> I understand that this is documented in the refrence manual, and is
> meant to be that way. But think of this, imagine EU being extremely
> succesful and having lots of active users making contributions like
> librarys for example. And say one may have a library or w/e someone
> wants but has a include file that is named the same as another
> include file in a different folder for a different librarty.
> Lets say you need both librarys in a program that you are making
> but if you try renaming the files you would screw up the library
> and would have to modify code in order to fix that wasting time
> which for some also mean money. If you could include 2 files
> or more of the same name but in different paths and or directory
> this I believe can be avoided unless I figured wrong.
>
> Another reason why I mention this is because this issue doesnt
> exist if I modified for example, test.ex to be this:
>
> Example:
> }}}
<eucode>
> include /File1/Try.e
> include /File2/Try.e
> machine_proc(26,0)
> </eucode>
{{{
> then the output would be:
>
> **This is Try.e in folder File1**
> **This is Try.e in folder File2**
>
> thus proving that doing it that way works however if I changed
> test.ex to this:
> }}}
<eucode>
> include \File1\Try.e
> include \File2\Try.e
> machine_proc(26,0)
> </eucode>
{{{
> I get an error saying that it cant open Try.e which is an example
> of the other problem with '\' and '/' not working the same, which
> you said is already fixed in EU 2.5 :).
>
> To sum all this up I really think that EU's include statement should
> be able to read 2 or more files of the same name but in different
> folders or directories and include each file and include them
> as seperate files and not just the first
> one. And allow it for all the ways to use the include statement.
> And to do this before the Euphoria 2.5 offical release
>
> Examples:
> include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
> include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
>
> include /File1/Try.e
> include /File2/Try.e
>
> include \File1\Try.e
> include \File1\Try.e
> ------------------------------------------------------------------------
> Should all treat Try.e in File1 and Try.e in File2 as seperate files.
>
> Fixing this could save people headache in the future if or when EU
> becomes popular enough and has a large enough community where an issue
> like this may arise, plus it would give people the piece of mind to know
> that this problem is fixed (especially me).
>
> Besides I think this should be an easy thing to fix Rob, just modify the
> interpretter source code a little and change just a tiny part of the
> Include section in the refrence manual then it should be all good.
> And even if it takes a little time to fix I think most people would be
> willing to wait for EU 2.5 just a little while more for this fix
> (after all they waited like 1-2 years already :}) so a little
> longer if nessasary wouldnt hert any. Specially since this was
> a big topic in the EU forum not to long ago.
>
> And like you said before Rob, any further ideas can be considered
> in Euphoria 2.6.
>
> I would very much appreciative if you definatly consider this
> before realeasing EU 2.5 (or at least the final offical version).
<snip>
3. Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
Why not just add that to a preprocessor?
On Fri, 05 Nov 2004 14:59:32 -0800, CoJaBo <guest at rapideuphoria.com> wrote:
>
> posted by: CoJaBo <cojabo at suscom.net>
>
> No response... Further enforcing the theory
> that Rob is ignoring us...
>
>
> Vincent wrote:
> >
> > Rob, I believe you said that in Euphoria 2.5, the front or back slashes
> > in the path of the include statment will work the same.
> >
> > }}}
<eucode>
> > include \RDS\Includes\File.e -- example
> > </eucode>
{{{
> > will work the same as:
> > }}}
<eucode>
> > include /RDS/Include/File.e -- example
> > </eucode>
{{{
> >
> > so that fixes 1 of the 2 problems that should be fixed for 2.5
> > relating to the include statement.
> >
> > The other thing is when using a path contained in double quotes,
> > for use with the include statement, another "problem" arises. When
> > trying to include a file that is named the same as another file
> > from a different folder that someone may try to use. The interpretter
> > only reads the first file and skips the second.
> >
> > Example:
> >
> > Lets say Try.e in folder named File1 has this code in it:
> > }}}
<eucode>
> > puts(1, "This is Try.e in folder File1\n")
> > </eucode>
{{{
> > And say Try.e in folder named File2 has this code:
> > }}}
<eucode>
> > puts(1, "This is Try.e in folder File2\n")
> > </eucode>
{{{
> >
> > The lets say in a different folder I make a Eu program called
> > Tester.ex, and have this code in it:
> > }}}
<eucode>
> > include "C:\\Documents and
> > Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
> > include "C:\\Documents and
> > Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
> > machine_proc(26,0)
> > </eucode>
{{{
> > then I save and run the program this would be the output:
> >
> > **This is Try.e in folder File1**
> >
> > while skipping the second include.
> > I understand that this is documented in the refrence manual, and is
> > meant to be that way. But think of this, imagine EU being extremely
> > succesful and having lots of active users making contributions like
> > librarys for example. And say one may have a library or w/e someone
> > wants but has a include file that is named the same as another
> > include file in a different folder for a different librarty.
> > Lets say you need both librarys in a program that you are making
> > but if you try renaming the files you would screw up the library
> > and would have to modify code in order to fix that wasting time
> > which for some also mean money. If you could include 2 files
> > or more of the same name but in different paths and or directory
> > this I believe can be avoided unless I figured wrong.
> >
> > Another reason why I mention this is because this issue doesnt
> > exist if I modified for example, test.ex to be this:
> >
> > Example:
> > }}}
<eucode>
> > include /File1/Try.e
> > include /File2/Try.e
> > machine_proc(26,0)
> > </eucode>
{{{
> > then the output would be:
> >
> > **This is Try.e in folder File1**
> > **This is Try.e in folder File2**
> >
> > thus proving that doing it that way works however if I changed
> > test.ex to this:
> > }}}
<eucode>
> > include \File1\Try.e
> > include \File2\Try.e
> > machine_proc(26,0)
> > </eucode>
{{{
> > I get an error saying that it cant open Try.e which is an example
> > of the other problem with '\' and '/' not working the same, which
> > you said is already fixed in EU 2.5 :).
> >
> > To sum all this up I really think that EU's include statement should
> > be able to read 2 or more files of the same name but in different
> > folders or directories and include each file and include them
> > as seperate files and not just the first
> > one. And allow it for all the ways to use the include statement.
> > And to do this before the Euphoria 2.5 offical release
> >
> > Examples:
> > include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File1\\Try.e"
> > include "C:\\Documents and Settings\\Vincent\\Desktop\\Test\\File2\\Try.e"
> >
> > include /File1/Try.e
> > include /File2/Try.e
> >
> > include \File1\Try.e
> > include \File1\Try.e
> >
> > Fixing this could save people headache in the future if or when EU
> > becomes popular enough and has a large enough community where an issue
> > like this may arise, plus it would give people the piece of mind to know
> > that this problem is fixed (especially me).
> >
> > Besides I think this should be an easy thing to fix Rob, just modify the
> > interpretter source code a little and change just a tiny part of the
> > Include section in the refrence manual then it should be all good.
> > And even if it takes a little time to fix I think most people would be
> > willing to wait for EU 2.5 just a little while more for this fix
> > (after all they waited like 1-2 years already :}) so a little
> > longer if nessasary wouldnt hert any. Specially since this was
> > a big topic in the EU forum not to long ago.
> >
<snip>
>
>
>
4. Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
Becuase to me those 2 issues are bugs that need to be fixed in
the main core language. Fixing it in a preprocessor would work, but
they are just not significant enough to consider.
codepilot Gmail Account wrote:
>
> Why not just add that to a preprocessor?
>
>
> On Fri, 05 Nov 2004 14:59:32 -0800, CoJaBo <guest at rapideuphoria.com> wrote:
> >
> > posted by: CoJaBo <cojabo at suscom.net>
> >
> > No response... Further enforcing the theory
> > that Rob is ignoring us...
</snip>
5. Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
Well, I can't think of anything good to say, since there is no
official word on whether its a bug or unimplemented feature and I
can't do anything about it myself, but don't want to be rood and not
reply, but officially I think they're saying 'No reply'.
On Sat, 06 Nov 2004 08:04:31 -0800, Vincent <guest at rapideuphoria.com> wrote:
>
> posted by: Vincent <darkvincentdude at yahoo.com>
>
> Becuase to me those 2 issues are bugs that need to be fixed in
> the main core language. Fixing it in a preprocessor would work, but
> they are just not significant enough to consider.
>
> codepilot Gmail Account wrote:
> >
> > Why not just add that to a preprocessor?
> >
> >
> > On Fri, 05 Nov 2004 14:59:32 -0800, CoJaBo <guest at rapideuphoria.com>
> > wrote:
> > >
> > > posted by: CoJaBo <cojabo at suscom.net>
> > >
> > > No response... Further enforcing the theory
> > > that Rob is ignoring us...
> </snip>
>
>
>
>
>
6. Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
----- Original Message -----
From: "codepilot Gmail Account"
Sent: Saturday, November 06, 2004 3:56 AM
Subject: Re: Rob: Euphoria 2.5 & Quick Include Statement Fix (Please Read)
>
> Why not just add that to a preprocessor?
>
> On Fri, 05 Nov 2004 14:59:32 -0800, CoJaBo wrote:
>>
>> posted by: CoJaBo
>>
>> No response... Further enforcing the theory
>> that Rob is ignoring us...
You gave a whopping 6 hours for response time. That didn't prove crap.
however, I've given a few days and he still hasn't responded. So either
he is ignoring us or.. he is so busy that he is, Um, ignoring us. Wait.
Where is the second option?
OH, right.
Either he is ignoring us "Because he is busy" OR
He has read the post and has chosen not to respond.
>>
>>
>> Vincent wrote:
>> >
>> > Rob, I believe you said that in Euphoria 2.5, the front or back slashes
>> > in the path of the include statment will work the same.
>> >
[snip]
You can't fix it in a preprocessor. It isn't there.
The problem exists at a level at which a preprocessor would have to
rename of copy
files to get around the problem.
unkmar - The man with a short fuse.
Please don't light it, I might not be able to put it out in time.
Frigging top posters.
