1. include statement bugs
There is a demo to go along with this post, but it doesn't seem I can
attach files.
You can get the zip here:
http://empire.iwireweb.com/forums/index.php?act=Attach&type=post&id=189
There are 2 problems.
1. backslash and forwardslash should work identically, with the
behaviour that frontslash.ex demonstrates
Using backslash, euphoria thinks that both lib1\test_include.e
and lib2\test_include.e are the same file and completely ignores
the second.
Using \ is apparently supposed to be the expected behaviour.
The fact that / works at all is considered a bug.
This is why I so strongly opposed the 'bug fix' for / that RDS was
going to do for v2.4
I use subfolders to help keep my projects more organized, and I have
to say it works well.
In fact, I consider it bad practice to put files directly into my
include path.
I use subfolders as much as possible.
Win32lib would be easier to deal with, if it were distributed as a
self contained subfolder.
Instead it has to be placed directly in the include path, which
combined with countless other libraries,
begins to cause issues with 'filename clashing'. Another namespacing
problem that has
yet to come to a head.
Euphoria basically doesn't allow the programmer to utilize the
benefit of directory structure,
to help organize our growing library archives.
I will even go so far as to suggest that rds moves it's own official
libraries to include/rds/*
as example and incentive for others to do the same.
2. "lib1\test_include.e" fails
Rob Szalay pointed it out to me.
F:\empire\projects\include_test\backslash.ex:1
can't find lib1 est_include.e in F:\empire\projects\include_test
or in f:\empire\include\rds;f:\my empire\include
or in f:\empire\include
include "lib1\test_include.e" as lib1
^
Notice also, "can't find lib1 est_include.e".
Chris Bensler
Code is Alchemy
2. Re: include statement bugs
Chris Bensler wrote:
>
> There is a demo to go along with this post, but it doesn't seem I can
> attach files.
> You can get the zip here:
> <a
> href="http://empire.iwireweb.com/forums/index.php?act=Attach&type=post&id=189">http://empire.iwireweb.com/forums/index.php?act=Attach&type=post&id=189</a>
>
> There are 2 problems.
>
> 1. backslash and forwardslash should work identically, with the
> behaviour that frontslash.ex demonstrates
>
> Using backslash, euphoria thinks that both lib1\test_include.e
> and lib2\test_include.e are the same file and completely ignores
> the second.
>
> Using \ is apparently supposed to be the expected behaviour.
> The fact that / works at all is considered a bug.
But does it work correctly? When I run frontslash2.ex on Linux, I get:
Test Lib #1
Test Lib #1
Press any key to finish
So here again, Euphoria is ignoring the second include.
Running backslash2, I guess Euphoria thinks the \t in '\test_include.e' is
a escaped character, thus giving the strange error message
"can't find lib1 est_include.e".
So I changed the program:
include "lib1\\test_include.e" as lib1
include "lib2\\test_include.e" as lib2
...
Now guess what happens:
backslash2.ex:1
can't find lib1\test_include.e in .
or in /home/irv/euphoria/include/gtk2
or in /home/irv/euphoria/include
include "lib1\\test_include.e" as lib1
^
To call this broken is too kind.
Worse, this problem of ignoring includes which have the same base name
as a previous include has been brought up numerous times over the past
few years. Will 2.5 fix this?
Irv
3. Re: include statement bugs
Chris Bensler wrote:
[snip]
> I use subfolders as much as possible.
>
> Win32lib would be easier to deal with, if it were distributed as a
> self contained subfolder.
> Instead it has to be placed directly in the include path, which
> combined with countless other libraries,
> begins to cause issues with 'filename clashing'. Another namespacing
> problem that has yet to come to a head.
Could you expand on this, as I don't think I quite understand.
Are you saying that instead of coding "include w32user.ew" I should be
coding something like "include win32lib\w32user.ew" ? And that the user
should have something like "set EUINC=C:\eu\thirdparty" and then install
the win32lib library includes in "c:\eu\thirdparty\win32lib\" ?
--
Derek Parnell
Melbourne, Australia
4. Re: include statement bugs
Chris Bensler wrote:
> There are 2 problems.
>
> 1. backslash and forwardslash should work identically, with the
> behaviour that frontslash.ex demonstrates
>
> Using backslash, euphoria thinks that both lib1\test_include.e
> and lib2\test_include.e are the same file and completely ignores
> the second.
It's documented that Euphoria ignores the second and subsequent includes
of the same file name (although the directory paths could be different).
I've further clarified the docs about this (just now).
> Using \ is apparently supposed to be the expected behaviour.
> The fact that / works at all is considered a bug.
In 2.5, forward slash and backslash are equally supported by
Euphoria on DOS/Windows. Only forward slash will be supported
on Linux/FreeBSD. This is in keeping with what the underlying
operating systems support.
> 2. "lib1\test_include.e" fails
> Rob Szalay pointed it out to me.
>
> F:\empire\projects\include_test\backslash.ex:1
> can't find lib1 est_include.e in F:\empire\projects\include_test
> or in f:\empire\include\rds;f:\my empire\include
> or in f:\empire\include
> include "lib1\test_include.e" as lib1
> ^
> Notice also, "can't find lib1 est_include.e".
When you enclose an include path using double quotes,
Euphoria scans the string as it would any other string.
That means it looks for things like \t and \n and \\ and
treats them as a single special character in the string.
There was an example in the manual (which I just fixed) where I
forgot to double up my backslashes when I added double quotes
around an include file path.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: include statement bugs
- Posted by Derek Parnell <ddparnell at bigpond.com>
Oct 17, 2004
-
Last edited Oct 18, 2004
Robert:
Do you believe that two files always have the same content if
the have the same name but reside in different folders?
For example, given these two files ...
myfolder\abc.ew
yourfolder\abc.ew
do you believe that their contents must therefore also be
identical, just because their names are the same?
If not, will v2.5 use the entire canonical path name when it
determines whether or not to instantiate a new included file?
--
Derek Parnell
Melbourne, Australia
6. Re: include statement bugs
On Sun, 17 Oct 2004 12:40:51 +0000, Chris Bensler <bensler at nt.net>
wrote:
<snip>
I think Chris has raised some good points.
Euphoria should most definitely load two different files which happen
to have the same name from two different folders, when you ask it to.
I don't care if it is documented to be that way, it is wrong.
>Win32lib would be easier to deal with, if it were distributed as a
>self contained subfolder.
>Euphoria basically doesn't allow the programmer to utilize the
>benefit of directory structure, to help organize our growing
>library archives.
Win32lib *is* distributed in a self contained folder (or three). Derek
does the best he can, given the limitation you point out.
One thing I would definitely like to see is that a statement:
include w32/win32lib.ew
adds the w32 directory to the list of places that the interpreter
should search for subsequent includes. [See also PS]
> include "lib1\test_include.e" as lib1
'\t' in a quoted string is a tab character, end of discussion.
If indeed the above works under exu, I proclaim it a bug.
Equally, it appears (from Irv's posts) that '\\' is crippled.
'/' tends to work equally on Windows and Linux, so I think it would be
a good idea to always automatically replace all '\\' with '/' within
the include statement, and resolve any problems that creates.
(after resolving the directory stuff, that is)
>Irv mullins wrote:
>it doesn't take a genius to see that: path1/misc.e IS NOT the same as
>path2/misc.e
Maybe Rob had a panic attack over this BEFORE error reports showed the
full path (quite recent, iirc)
>Rob, doesn't Euphoria have access to the platform() function?
>If so, then why can't the include routine make use of it to handle
>the different path separators appropriately?
Irv, I believe the windows api is documented as supporting
forwardslash; it is linux which does not support backslash.
I would be inclined(tee hee) to think linux got it right vs. M$BS
(Might be a DOS issue, anyone know?)
>Derek wrote:
>of Robert some time again and he has assured me that v2.5 will have
>this and related issues corrected in 2.5.
>For example:
>
> include .\inc1.e
> include inc1.e
>
>are two 'different' files in 2.4 but the same file in 2.5.
My gut reaction is that Rob was just being more adamant that if both
win32lib and EuSQL had, say, a string.e file, he was just being more
certain you could not possibly load them both. So right in one sense,
so wrong in another 
Regards,
Pete
PS Back to Eu supporting directory structures a bit more: It seems
clear that if including w32/win32lib.ew adds the w32 directory to the
list of directories to search, it should also place it at the top of
the list, since it is quite likely that subsequent includes will be
from the same directory, but also at the end of win32lib.ew, w32/
should be removed from the list.
I may be [AM] missing a really simple trick, but I can't seem to do
both, not with nested includes, anyway.
7. Re: include statement bugs
Pete Lomax wrote:
> Irv, I believe the windows api is documented as supporting
> forwardslash; it is linux which does not support backslash.
> I would be inclined(tee hee) to think linux got it right vs. M$BS
> (Might be a DOS issue, anyone know?)
It's ancient history, but I believe that when Bill Gates wrote or
borrowed DOS, he used the backslash, and got a lot of criticism from
people for going against the standard (which was mostly Unix at the
time).
Irv
8. Re: include statement bugs
Derek Parnell wrote:
> Do you believe that two files always have the same content if
> the have the same name but reside in different folders?
>
> For example, given these two files ...
>
> myfolder\abc.ew
> yourfolder\abc.ew
>
> do you believe that their contents must therefore also be
> identical, just because their names are the same?
The second include is ignored on the assumption that they
are essentially the same. ("belief" that they are "identical"
overstates things a bit)
> If not, will v2.5 use the entire canonical path name when it
> determines whether or not to instantiate a new included file?
No it won't.
I consider this to be a tiny issue that affects maybe 1% or less
of all programs. I think it took several years for anyone to
even notice how it works. How many people want to include two files
in one program, where the files have the same name, but
different content?
As I think back 10 years or so, I think I did it
this way because I didn't want:
graphics.e
.\graphics.e
./graphics.e
c:\euphoria\include\graphics.e
\euphoria\include\graphics.e
c:graphics.e
to be considered "different" files, leading to
multiply-defined symbol error messages,
when in fact they might be exactly the same file,
or at least a copy of a file. I didn't want to write code
to resolve the paths, to prove that one of them was in fact
the same file as another.
If this bothers you, just rename one of your files (and avoid
confusing the reader of your code).
By the way, this and the backslash vs. forward slash thing
can be changed easily by anyone in the new source code.
e.g. copied from global.e in the 2.5 front-end...
global integer PATH_SEPARATOR, SLASH
global sequence SLASH_CHARS
if ELINUX then
PATH_SEPARATOR = ':' -- in PATH environment variable
SLASH = '/' -- preferred on Linux/FreeBSD
SLASH_CHARS = "/" -- special chars allowed in a path
else
PATH_SEPARATOR = ';'
SLASH = '\\'
SLASH_CHARS = "\\/:"
end if
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: include statement bugs
Robert Craig wrote:
>
> Derek Parnell wrote:
> > Do you believe that two files always have the same content if
> > the have the same name but reside in different folders?
> >
> > For example, given these two files ...
> >
> > myfolder\abc.ew
> > yourfolder\abc.ew
> >
> > do you believe that their contents must therefore also be
> > identical, just because their names are the same?
>
> The second include is ignored on the assumption that they
> are essentially the same. ("belief" that they are "identical"
> overstates things a bit)
As an aside, I used the word "believe" rather than "assume"
because I want a clear statement of your beliefs/philosophy.
So to summarize, Euphoria will assume that any two files that have
the same name will also have the same contents.
> > If not, will v2.5 use the entire canonical path name when it
> > determines whether or not to instantiate a new included file?
>
> No it won't.
I am very saddened to hear this. Not because it effects my work, but
because it describes a mindset that I'm not comfortable with.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs. I think it took several years for anyone to
> even notice how it works. How many people want to include two files
> in one program, where the files have the same name, but
> different content?
I was thinking more along the lines that, for example, I distribute
win32lib that happens to include a file called "text.e". Some person
installs win32lib and also installs Bill's text editor library, that
coincidently also has an include file called "text.e". My "text.e" and
Bill's "text.e" have nothing in common and have been developed
independantly.
Why should the person who is attempting to use these two libraries be
hindered by Euphoria's file-name assumption?
> As I think back 10 years or so, I think I did it
> this way because I didn't want:
> graphics.e
> .\graphics.e
> ./graphics.e
> c:\euphoria\include\graphics.e
> \euphoria\include\graphics.e
> c:graphics.e
> to be considered "different" files, leading to
> multiply-defined symbol error messages,
> when in fact they might be exactly the same file,
> or at least a copy of a file. I didn't want to write code
> to resolve the paths, to prove that one of them was in fact
> the same file as another.
I can see and agree with your intention, but the lack of effort to
resolve this is a worry. Making the assumption must save a few
milliseconds for <1% of all programs.
> If this bothers you, just rename one of your files (and avoid
> confusing the reader of your code).
Why do you assume that they are 'my' files and that I am in a
position rename them? They could have been provided to me by two or
more independant developers, and could be shrouded.
> By the way, this and the backslash vs. forward slash thing
> can be changed easily by anyone in the new source code.
And will be!
--
Derek Parnell
Melbourne, Australia
10. Re: include statement bugs
Robert Craig wrote:
>
> Derek Parnell wrote:
> > If not, will v2.5 use the entire canonical path name when it
> > determines whether or not to instantiate a new included file?
>
> No it won't.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs. I think it took several years for anyone to
> even notice how it works. How many people want to include two files
> in one program, where the files have the same name, but
> different content?
If you utilize the handy Euphoria search engine, it will show you that
this has been the topic of numerous postings going back at least 2 1/2
years. Furthermore, it is inconceivable that this could be an insurmountable
programming problem. You have just admitted, basically, that there's
nothing but stubbornness keeping you from implementing this feature.
When one of my clients asks for a change, I do everything possible to
accomodate them. If I refuse, especially if I do so without a good
reason, I needn't look forward to getting any more checks from that
client.
Irv
11. Re: include statement bugs
Derek Parnell wrote:
>
> Robert Craig wrote:
> >
> > Derek Parnell wrote:
> > > If not, will v2.5 use the entire canonical path name when it
> > > determines whether or not to instantiate a new included file?
> >
> > No it won't.
>
> I am very saddened to hear this. Not because it effects my work, but
> because it describes a mindset that I'm not comfortable with.
Indeed. There are dozens of programmers out there writing their own
languages who never expect to make a dime for their efforts, nevertheless
they welcome constructive criticism and try to implement the good ideas.
Why? Perhaps they take pride in their creation.
RDS's plan to leave everything as 'an exercise for the reader' is likely
to backfire. People will only take so much of that before they go shopping
for another book.
Irv
12. Re: include statement bugs
On 17 Oct 2004, at 20:45, irv mullins wrote:
>
>
> posted by: irv mullins <irvm at ellijay.com>
>
> Derek Parnell wrote:
> >
> > Robert Craig wrote:
> > >
> > > Derek Parnell wrote:
>
> > > > If not, will v2.5 use the entire canonical path name when it
> > > > determines whether or not to instantiate a new included file?
> > >
> > > No it won't.
> >
> > I am very saddened to hear this. Not because it effects my work, but
> > because it describes a mindset that I'm not comfortable with.
>
> Indeed. There are dozens of programmers out there writing their own
> languages who never expect to make a dime for their efforts, nevertheless
> they welcome constructive criticism and try to implement the good ideas.
> Why? Perhaps they take pride in their creation.
>
> RDS's plan to leave everything as 'an exercise for the reader' is likely
> to backfire. People will only take so much of that before they go shopping for
> another book.
Especially with free open source books out there.
Kat
13. Re: include statement bugs
Kat wrote:
> On 17 Oct 2004, at 20:45, irv mullins wrote:
> > posted by: irv mullins
> > RDS's plan to leave everything as 'an exercise for the reader' is likely
> > to backfire. People will only take so much of that before they go shopping
> > for
> > another book.
>
> Especially with free open source books out there.
If anyone reading the mailing list for any length of time doesn't understand
the situation about "Euphoria" you never will.
This type of thing has been popping up for at least the last 5 years that
I know about!
Here is my summary:
* Euphoria is a great little language and is well suited to a number of
"types" of applications.
* Euphoria will NOT change at a fast pace.
* Unless RDS open source the *full* sources with a liberal license everyone
had better like how RDS do things. (Which is generally not bad ...
but often not "the best" and never fast!).
If you "need" Euphoria to do something it currently doesn't do and it isn't
1 of the 2 or 3 things that RDS will say is comming in the next release then
Euphoria isn't for you!
Euphoria is a "take it and live with the lumps" or leave it langauge ...
it ain't changin!
(Every language has similiar issues ... your best bet is to choose a language
where the designers have similiar ideals to your own).
P.S. It's good to see Chris back ... and still fighting for improvement!
Regards,
Ray Smith
14. Re: include statement bugs
Robert Craig wrote:
> Derek Parnell wrote:
>> Do you believe that two files always have the same content if
>> the have the same name but reside in different folders?
>>
>> For example, given these two files ...
>>
>> myfolder\abc.ew
>> yourfolder\abc.ew
>>
>> do you believe that their contents must therefore also be
>> identical, just because their names are the same?
>
> The second include is ignored on the assumption that they
> are essentially the same. ("belief" that they are "identical"
> overstates things a bit)
>
>> If not, will v2.5 use the entire canonical path name when it
>> determines whether or not to instantiate a new included file?
>
> No it won't.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs.
What can be the effects of this issue?
If this issue can be a source of hidden bugs in a program, the rate
of potentially affected programs should not be the only criterion.
For causing considerable damage, only 1 buggy program is necessary,
that e.g. controls an important device.
<snip>
Regards,
Juergen
15. Re: include statement bugs
Chris Bensler & Irv Mullins wrote:
----------
> From: irv mullins <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: RE: include statement bugs
> Sent: 18 oct 2004 y. 6:31
>
> posted by: irv mullins <irvm at ellijay.com>
>
> Chris Bensler wrote:
>
> > Is there anyone who agrees with how euphoria deals with duplicate
> > includes?
>
> Since files of the same name in different directories are NOT considered
> the same file by any operating system I know of, why should Euphoria
> ignore the differences?
>
> Irv
The Euphoria include files are too specialized, not usual, files.
They are the libraries of functions, procedures and constants for
the universal using.
Do you know any other programming language with the duplicate
libraries names?
What a crazy fantasy to have duplicate names in different folders
for the main programming stuff in Euphoria?
If you have such the duplicated names, it is just yours mistake,
yours problem, yours bug -- nothing more.
Rename it and forget about that "problem".
It is not a Euphoria bug. It is a normal practice to have
the different names for the different libraries.
Delete double - this is the most productive programming rule.
Regards,
Igor Kachan
kinz at peterlink.ru
16. Re: include statement bugs
Igor Kachan wrote:
I'm sorry Mr Kachan, as you know I normally ignore your posts, but
I must reply to this apparent nonsense.
> Chris Bensler & Irv Mullins wrote:
>
> ----------
> > From: irv mullins <guest at RapidEuphoria.com>
> > To: EUforum at topica.com
> > Subject: RE: include statement bugs
> > Sent: 18 oct 2004 y. 6:31
> >
> > posted by: irv mullins <irvm at ellijay.com>
> >
> > Chris Bensler wrote:
> >
> > > Is there anyone who agrees with how euphoria deals with duplicate
> > > includes?
> >
> > Since files of the same name in different directories are NOT considered
> > the same file by any operating system I know of, why should Euphoria
> > ignore the differences?
> >
> > Irv
>
> The Euphoria include files are too specialized, not usual, files.
> They are the libraries of functions, procedures and constants for
> the universal using.
Yes, but so what? That is not relevant.
> Do you know any other programming language with the duplicate
> libraries names?
Yes.
> What a crazy fantasy to have duplicate names in different folders
> for the main programming stuff in Euphoria?
But it may happen outside of my control. Why should I be punished for that?
> If you have such the duplicated names, it is just yours mistake,
> yours problem, yours bug -- nothing more.
No, you are wrong here. Consider that not every file on my system is
created by me. Is it really my mistake that somebody else has used the
same name as I did, or that a thrid person used?
My problem - yes. But not my mistake or my bug.
> Rename it and forget about that "problem".
No every file can be renamed without causing other problems.
> It is not a Euphoria bug.
Agreed, it is not a bug. It is a short-sighted design decision.
> It is a normal practice to have
> the different names for the different libraries.
But only if I haeve complete control. I do not control the libraries that
other people write.
> Delete double - this is the most productive programming rule.
Delete RDS's Euphoria might be a more productive rule.
However, pretend for a moment. You write a wonderful library that consists
of many files. Everyone loves your work and they download it and love
using it.
Later, RDS creates a new library file. One which is always distributed
with Euphoria.
But as luck would have it, one of RDS's files has the same name as one
of your files.
Now some people find a use for both your library and RDS's library in the
same application. Now, which one of these files should all the happy
customers of yours and RDS delete or rename?
Either way they lose don't they? Maybe you should rename your file? But
you came up with that name before RDS? Maybe RDS should rename their file?
But RDS is the maker of Euphoria and has quite a lot invested in that new
library file name. Is either you or RDS at fault? I suspect not, yet
somebody must pay for this design decision in Euphoria?
--
Derek Parnell
Melbourne, Australia
17. Re: include statement bugs
Derek Parnell wrote:
----------
> From: Derek Parnell <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: include statement bugs
> Sent: 18 oct 2004 y. 13:42
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Igor Kachan wrote:
>
> I'm sorry Mr Kachan, as you know I normally ignore your posts, but
> I must reply to this apparent nonsense.
Thanks for reply, and I did not notice that ignorance,
no problem anyway.
But let us see where is that "apparent nonsense".
> > Chris Bensler & Irv Mullins wrote:
> >
> > ----------
> > > From: irv mullins <guest at RapidEuphoria.com>
> > > To: EUforum at topica.com
> > > Subject: RE: include statement bugs
> > > Sent: 18 oct 2004 y. 6:31
> > >
> > > posted by: irv mullins <irvm at ellijay.com>
> > >
> > > Chris Bensler wrote:
> > >
> > > > Is there anyone who agrees with how euphoria deals with duplicate
> > > > includes?
> > >
> > > Since files of the same name in different directories are NOT
considered
> > > the same file by any operating system I know of, why should Euphoria
> > > ignore the differences?
> > >
> > > Irv
> >
> > The Euphoria include files are too specialized, not usual, files.
> > They are the libraries of functions, procedures and constants for
> > the universal using.
>
> Yes, but so what? That is not relevant.
Yes, so it is our common "apparent nonsense", no?
Chris Bensler wrote about include, yes?
Me wrote about include too. What is not relevant?
> > Do you know any other programming language with the duplicate
> > libraries names?
>
> Yes.
What it is, if it is not a top secret?
> > What a crazy fantasy to have duplicate names in different folders
> > for the main programming stuff in Euphoria?
>
> But it may happen outside of my control.
I see you agreed with "a crazy fantasy", so it is our common
"apparent nonsense", no?
> Why should I be punished for that?
Do not panic. Let us see the concrete example and solve
the problem _*JUST NOW*_, if you do need that solution.
> > If you have such the duplicated names, it is just yours mistake,
> > yours problem, yours bug -- nothing more.
>
> No, you are wrong here. Consider that not every file on my system
> is created by me.
Ok, what is the concrete file created not by you?
Is it the John's, Ray's, Irv's, Chris', Rob's, Kat's, Junko's, Judith',
Pete's, Bernie's, Ricardo's, CK's, Dave's, Martin's, Juergen's,
Mark's, Jiri's, Tommy's ..... no the end ..... Igor's file ????
Who is an author of that remarkable file?
> Is it really my mistake that somebody else has used the
> same name as I did, or that a thrid person used?
What concrete mistake, what is the concrete names
of yours file and that one?
> My problem - yes. But not my mistake or my bug.
Where is the concrete problem?
> > Rename it and forget about that "problem".
>
> No every file can be renamed without causing other problems.
What one you can not rename _*JUST NOW*_ and foreve?
Tell me please and I'll ask the author for you to solve that
problem immediately for you both pleasure.
> > It is not a Euphoria bug.
>
> Agreed, it is not a bug.
Ok, so my phrase is our common "apparent nonsense", no?
> It is a short-sighted design decision.
11 years old Euphoria, and we can not name that
author, who doesn't want rename that doubled-name libby ...
Good design, I think, excellent design, I like that design.
> > It is a normal practice to have
> > the different names for the different libraries.
>
> But only if I haeve complete control.
I see you agreed with "a normal practice",
so my phrase is our common "apparent nonsense", no?
> I do not control the libraries that other people write.
What concrete library?
For example, I have made massive changes of Bernie's w32engin.ew,
renamed it - my version is w32engir.ew now, without any problem,
just asked Bernie for that development and all Ok.
> > Delete double - this is the most productive programming rule.
>
> Delete RDS's Euphoria might be a more productive rule.
I see you agreed with that "Delete double",
so my phrase is our common "apparent nonsense", no?
But the RDS's Euphoria is single, and we can see a lot of
different C.
Maybe, it is better solution to ignore some of C ???
> However, pretend for a moment. You write a wonderful library that
consists
> of many files. Everyone loves your work and they download it and love
> using it.
>
> Later, RDS creates a new library file. One which is always distributed
> with Euphoria.
>
> But as luck would have it, one of RDS's files has the same name as one
> of your files.
>
> Now some people find a use for both your library and RDS's library in the
> same application. Now, which one of these files should all the happy
> customers of yours and RDS delete or rename?
>
> Either way they lose don't they? Maybe you should rename your file? But
> you came up with that name before RDS? Maybe RDS should rename their
file?
> But RDS is the maker of Euphoria and has quite a lot invested in that new
> library file name. Is either you or RDS at fault? I suspect not, yet
> somebody must pay for this design decision in Euphoria?
I'm sorry Mr Parnell, I'd prefer to discuss the concrete problems and
try to solve them just now.
My advise to Chris to rename that libby and be happy
with Euphoria, the single in the World language for the End Users.
Well, Derek, I see we are united on most of my "apparent nonsenses", no?
Do not worry about those hypothesises, they are almost impossible
and can be solved with the single command on any OS just momentarily.
> --
> Derek Parnell
> Melbourne, Australia
Regards,
Igor Kachan
kinz at peterlink.ru
18. Re: include statement bugs
Igor Kachan wrote:
>
> Derek Parnell wrote:
> > > The Euphoria include files are too specialized, not usual, files.
> > > They are the libraries of functions, procedures and constants for
> > > the universal using.
> >
> > Yes, but so what? That is not relevant.
>
> Yes, so it is our common "apparent nonsense", no?
> Chris Bensler wrote about include, yes?
> Me wrote about include too. What is not relevant?
The fact that they are *Euphoria* files is not relevant. Are not C files
also libraries of functions and constants? Are not Pascal includes also
libraries of functions, procedures and constants? Of course they are.
Just because a file contains Euphoria code instead of C code doesn't
mean it has any special status which requires it to to handled in a
different and unexpected way - by which I mean 'silently ignored'.
> > > Do you know any other programming language with the duplicate
> > > libraries names?
> >
> > Yes
>
> What it is, if it is not a top secret?
C, C++, D, E, Eiffel ... this bores me.
> I'm sorry Mr Parnell, I'd prefer to discuss the concrete problems and
> try to solve them just now.
The tire is flat only on the bottom. Just turn it over.
Irv
19. Re: include statement bugs
Derek Parnell wrote:
> Either way they lose don't they? Maybe you should rename your file? But
> you came up with that name before RDS? Maybe RDS should rename their file?
> But RDS is the maker of Euphoria and has quite a lot invested in that new
> library file name. Is either you or RDS at fault? I suspect not, yet
> somebody must pay for this design decision in Euphoria?
I agree that if Euphoria ever became widely used, like Python for example,
this would be a problem. Realistically, however, I don't see any chance
that Euphoria will ever become popular. There are too many factors working
against that.
Regards,
Irv
20. Re: include statement bugs
Irv Mullins wrote:
----------
> > > > Do you know any other programming language with the duplicate
> > > > libraries names?
> > >
> > > Yes
> >
> > What it is, if it is not a top secret?
>
> C, C++, D, E, Eiffel ... this bores me.
Ok, sorry, but what the libraries names?
Be so kind, please, I'd like to see these libs,
just interested to understand the real reason of
doubling of those names.
> > I'm sorry Mr Parnell, I'd prefer to discuss the concrete problems and
> > try to solve them just now.
>
> The tire is flat only on the bottom. Just turn it over.
>
> Irv
Oh, yes, but I prefer just that flat tyre, without the whey!
One day, taste, good thing, then you'll do not want turned one.
There are 'tire' and 'tire' and 'tyre' and 'tyre' in English,
I like 'tyre'.
But you, I think, mentioned 'tire'. Anyway, try not turned tyre!
Regards,
Igor Kachan
kinz at peterlink.ru
21. Re: include statement bugs
Hi Igor, you wrote:
> Derek Parnell wrote:
<snip>
>> No every file can be renamed without causing other problems.
>
> What one you can not rename _*JUST NOW*_ and foreve?
>
> Tell me please and I'll ask the author for you to solve that
> problem immediately for you both pleasure.
<snip>
I think the problem is most likely to happen with very common names,
such as "math.e" or "string.e".
Say you have the libraries 'lib1' and 'lib2', and both contain a
"string.e" file, but with different contents. You need to include both
libraries in one of your projects.
Then you ask the author of 'lib1', to rename his "string.e" file to say
"stringX.e". S/he does so, fine for you. Now another user of 'lib1'
might get a naming problem, that s/he didn't have before, because s/he
already has a different file "stringX.e", that belongs to 'lib3'.
Of course, this other user can write to the auther of 'lib3', and ask
her/him to rename the file ...
This would be the never ending "Rename-The-File" game. 
The more widespread Euphoria will be, the more likely this will happen,
no?
Regards,
Juergen
22. Re: include statement bugs
Hi Juergen, you wrote:
----------
> From: Juergen Luethje <j.lue at gmx.de>
> To: EUforum at topica.com
> Subject: Re: include statement bugs
> Sent: 18 oct 2004 y. 17:02
>
> Hi Igor, you wrote:
>
> > Derek Parnell wrote:
>
> <snip>
>
> >> No every file can be renamed without causing other problems.
> >
> > What one you can not rename _*JUST NOW*_ and foreve?
> >
> > Tell me please and I'll ask the author for you to solve that
> > problem immediately for you both pleasure.
>
> <snip>
>
> I think the problem is most likely to happen with very common names,
> such as "math.e" or "string.e".
These short names are common, yes but this is not a problem at all.
Say, if I want contribute some _new_ proggy, I must to check the Arcive
to see what is that my proggy - new, good, single or not single on this
theme, etc - the common practice of such the work.
So, if I use the known name for my new lib, this will be my mistake,
my buggy solution.
The good practice is to know the objects & subjects and to make the new
ones. Euphoria understands the long names. Why not use the progress?
> Say you have the libraries 'lib1' and 'lib2', and both contain a
> "string.e" file, but with different contents. You need to include both
> libraries in one of your projects.
> Then you ask the author of 'lib1', to rename his "string.e" file to say
> "stringX.e". S/he does so, fine for you. Now another user of 'lib1'
> might get a naming problem, that s/he didn't have before, because s/he
> already has a different file "stringX.e", that belongs to 'lib3'.
> Of course, this other user can write to the auther of 'lib3', and ask
> her/him to rename the file ...
There is one more aspect - the doubled lib names can make many confusions
in Euphoria as a monolithic programming system.
So, it is a good thing that Euphoria understands doubled names as same
name. This is a way to make the Archive more and more robust.
> This would be the never ending "Rename-The-File" game.
> The more widespread Euphoria will be, the more likely this will happen,
> no?
Yes, but it is the very rare and the very useful process - renaming of
doubled-name libs.
> Regards,
> Juergen
Regards,
Igor Kachan
kinz at peterlink.ru
23. Re: include statement bugs
----- Original Message -----
From: "Robert Craig"
Sent: Sunday, October 17, 2004 9:56 PM
Subject: Re: include statement bugs
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Derek Parnell wrote:
>> Do you believe that two files always have the same content if
>> the have the same name but reside in different folders?
>>
>> For example, given these two files ...
>>
>> myfolder\abc.ew
>> yourfolder\abc.ew
>>
>> do you believe that their contents must therefore also be
>> identical, just because their names are the same?
>
> The second include is ignored on the assumption that they
> are essentially the same. ("belief" that they are "identical"
> overstates things a bit)
>
>> If not, will v2.5 use the entire canonical path name when it
>> determines whether or not to instantiate a new included file?
>
> No it won't.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs. I think it took several years for anyone to
> even notice how it works. How many people want to include two files
> in one program, where the files have the same name, but
> different content?
>
> As I think back 10 years or so, I think I did it
> this way because I didn't want:
> graphics.e
> .\graphics.e
> ./graphics.e
> c:\euphoria\include\graphics.e
> \euphoria\include\graphics.e
> c:graphics.e
> to be considered "different" files, leading to
> multiply-defined symbol error messages,
> when in fact they might be exactly the same file,
> or at least a copy of a file. I didn't want to write code
> to resolve the paths, to prove that one of them was in fact
> the same file as another.
>
> If this bothers you, just rename one of your files (and avoid
> confusing the reader of your code).
>
> By the way, this and the backslash vs. forward slash thing
> can be changed easily by anyone in the new source code.
> e.g. copied from global.e in the 2.5 front-end...
>
> }}}
<eucode>
> global integer PATH_SEPARATOR, SLASH
> global sequence SLASH_CHARS
> if ELINUX then
> PATH_SEPARATOR = ':' -- in PATH environment variable
> SLASH = '/' -- preferred on Linux/FreeBSD
> SLASH_CHARS = "/" -- special chars allowed in a path
> else
> PATH_SEPARATOR = ';'
> SLASH = '\\'
> SLASH_CHARS = "\\/:"
> end if
> </eucode>
{{{
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
This is the very closed mindeness about Rob that has just about brought my
coding to a halt.
I'm coming to a point to where I must either stop coding or switch languages.
I'm very likely to just stop coding. Learning yet another language is time
consuming.
I have only done it as a hobby and these little annoyances bring me to a point
to where my
ability to not grow as a coder is stiffled by the requirement of abandoning yet
another language.
< at unkmar> Botmar unkmar.code
< at Botmar> Unkmar.code mIRC, Perl, Euphoria, Quick Basic, DOS Batch,
JavaScript, HTML
That just tells the ones that I consider my self very capable in.
unkmar
24. Re: include statement bugs
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: <EUforum at topica.com>
Sent: Monday, October 18, 2004 6:45 AM
Subject: Re: include statement bugs
>
>
> Chris Bensler & Irv Mullins wrote:
>
> ----------
>> From: irv mullins <guest at RapidEuphoria.com>
>> To: EUforum at topica.com
>> Subject: RE: include statement bugs
>> Sent: 18 oct 2004 y. 6:31
>>
>> posted by: irv mullins <irvm at ellijay.com>
>>
>> Chris Bensler wrote:
>>
>> > Is there anyone who agrees with how euphoria deals with duplicate
>> > includes?
>>
>> Since files of the same name in different directories are NOT considered
>> the same file by any operating system I know of, why should Euphoria
>> ignore the differences?
>>
>> Irv
>
> The Euphoria include files are too specialized, not usual, files.
> They are the libraries of functions, procedures and constants for
> the universal using.
>
> Do you know any other programming language with the duplicate
> libraries names?
>
> What a crazy fantasy to have duplicate names in different folders
> for the main programming stuff in Euphoria?
>
> If you have such the duplicated names, it is just yours mistake,
> yours problem, yours bug -- nothing more.
>
> Rename it and forget about that "problem".
>
> It is not a Euphoria bug. It is a normal practice to have
> the different names for the different libraries.
>
> Delete double - this is the most productive programming rule.
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
>
Another one blinded.
johnny/text.e
global function center(sequence data)
-- fill in code
end function
alfred/text.e
global function justify(sequence text)
-- fill in code
end function
Both libs have nothing in common and neither of them belong to me.
now, that is just a simple short example. Not shrouded or anything like that.
but the problem goes much deeper because of collective libs.
Win32 is a collection of libs
kat has her collection of libs
I have mine. You may have yours. We will likely duplicate names without
knowing it. You may want to use others libs that clash.
1: Namespace clash - both libs have some routines named the same
2: Filenaming clash - both libs have have the same filename.
Neither developer had any clue of the other and neither should have to
give up their name. A simple solution is.
unkmar/lib.e
scooby/lib.e
jami/lib.e
derek/lib.e
wingzero/lib.e
....
unkmar
25. Re: include statement bugs
----- Original Message -----
From: "Ray Smith"
Sent: Monday, October 18, 2004 2:25 AM
Subject: Re: include statement bugs
>
>
> posted by: Ray Smith <ray at rays-web.com>
>
> Kat wrote:
>> On 17 Oct 2004, at 20:45, irv mullins wrote:
>> > posted by: irv mullins
>> > RDS's plan to leave everything as 'an exercise for the reader' is likely
>> > to backfire. People will only take so much of that before they go shopping
>> > for
>> > another book.
>>
>> Especially with free open source books out there.
>
> If anyone reading the mailing list for any length of time doesn't understand
> the situation about "Euphoria" you never will.
> This type of thing has been popping up for at least the last 5 years that
> I know about!
>
> Here is my summary:
> * Euphoria is a great little language and is well suited to a number of
> "types" of applications.
> * Euphoria will NOT change at a fast pace.
> * Unless RDS open source the *full* sources with a liberal license everyone
> had better like how RDS do things. (Which is generally not bad ...
> but often not "the best" and never fast!).
>
> If you "need" Euphoria to do something it currently doesn't do and it isn't
> 1 of the 2 or 3 things that RDS will say is comming in the next release then
> Euphoria isn't for you!
>
> Euphoria is a "take it and live with the lumps" or leave it langauge ...
> it ain't changin!
> (Every language has similiar issues ... your best bet is to choose a language
> where the designers have similiar ideals to your own).
>
> P.S. It's good to see Chris back ... and still fighting for improvement!
>
> Regards,
>
> Ray Smith
I dare say that "Chris is back" will be a very short lived experience.
and this time I am more than tempted to follow him on the way out the door.
I'd invite Jason Mirwald along but I think he has already left.
unkmar
26. Re: include statement bugs
Hi, Lucius!
You wrote:
[snip]
> > The Euphoria include files are too specialized, not usual, files.
> > They are the libraries of functions, procedures and constants for
> > the universal using.
> >
> > Do you know any other programming language with the duplicate
> > libraries names?
> >
> > What a crazy fantasy to have duplicate names in different folders
> > for the main programming stuff in Euphoria?
> >
> > If you have such the duplicated names, it is just yours mistake,
> > yours problem, yours bug -- nothing more.
> >
> > Rename it and forget about that "problem".
> >
> > It is not a Euphoria bug. It is a normal practice to have
> > the different names for the different libraries.
> >
> > Delete double - this is the most productive programming rule.
> >
> >
> Another one blinded.
>
> johnny/text.e
> global function center(sequence data)
> -- fill in code
> end function
Who is that johnny?
> alfred/text.e
> global function justify(sequence text)
> -- fill in code
> end function
Who is that alfred?
> Both libs have nothing in common and neither of them belong to me.
> now, that is just a simple short example. Not shrouded or anything like
> that.
> but the problem goes much deeper because of collective libs.
The lagest collection of the Euphoria libs is the RDS Archive.
Are those johnny & alfred thinking that their text.e have
the same name and this same name will confuse most of EU
users ANYWAY ?
> Win32 is a collection of libs
> kat has her collection of libs
> I have mine. You may have yours. We will likely duplicate names
> without knowing it.
You want to program without knowing the language, it seems to me.
> You may want to use others libs that clash.
> 1: Namespace clash - both libs have some routines named the same
> 2: Filenaming clash - both libs have have the same filename.
> Neither developer had any clue of the other and neither should have to
> give up their name. A simple solution is.
>
> unkmar/lib.e
> scooby/lib.e
> jami/lib.e
> derek/lib.e
> wingzero/lib.e
> ....
Try please the below thing instead:
unkmarlib.e
scoobylib.e
jamilib.e
dereklib.e
wingzerolib.e
And you'll never have a problem, this solution is without endless
///////// at all,
and it works just now, do you see ????
I think those johnny & alfred will rename their libbies just now,
to avoid The Giant Crash of Euphoria becouse of that terrible Rob's bug.
Hey, johnny & alfred, am I right?
Regards,
Igor Kachan
kinz at peterlink.ru
27. Re: include statement bugs
Igor Kachan wrote:
> Try please the below thing instead:
>
> unkmarlib.e
> scoobylib.e
> jamilib.e
> dereklib.e
> wingzerolib.e
>
> And you'll never have a problem, this solution is without endless
> ///////// at all,
> and it works just now, do you see ????
There you see. It's a hack. It works now, but not forever.
He gave an example of a problem that could occur.
Didn't you understand that?
Wouldn't it be good if we could get rid of all renaming?
Regards, Alexander Toresson
Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
28. Re: include statement bugs
Robert Craig wrote:
> > do you believe that their contents must therefore also be
> > identical, just because their names are the same?
>
> The second include is ignored on the assumption that they
> are essentially the same. ("belief" that they are "identical"
> overstates things a bit)
That's like assuming that two people with the same name are the same
person.
>
> > If not, will v2.5 use the entire canonical path name when it
> > determines whether or not to instantiate a new included file?
>
> No it won't.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs. I think it took several years for anyone to
> even notice how it works. How many people want to include two files
> in one program, where the files have the same name, but
> different content?
>
> As I think back 10 years or so, I think I did it
> this way because I didn't want:
> graphics.e
> .\graphics.e
> ./graphics.e
> c:\euphoria\include\graphics.e
> \euphoria\include\graphics.e
> c:graphics.e
> to be considered "different" files, leading to
> multiply-defined symbol error messages,
> when in fact they might be exactly the same file,
> or at least a copy of a file. I didn't want to write code
> to resolve the paths, to prove that one of them was in fact
> the same file as another.
This is a pity. So you reject a nice easy solution for a several years old
hack?
The obvious solution to both of these problems would be to make the code
extend the filenames to full filenames and then compare them.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
29. Re: include statement bugs
Hi
For what its worth, compared to all the eu giants here, just thought I'd add
my 2p worth.
SHUTUP AND STOP YOUR MOANING!
You've got a great language here, which has its limitations (as does any other)
but you can find find ways and workarounds like you do in any other language.
So what if you have to rename an include, or find another way to do something.
Thats part of the challenge.
I've had problems too, and worked through them (eg eugtk subfolder include).
If the list has problems with include file names and version numbers, then
create a standard naming convention for include submissions. If your
program can't find the most up to date version, then write a routine
to copy the file to the current directory of the older version, rename it
and include it - etc etc.
I'm VERY happy with the way things are, no need to change. Good job RobC,
and ALL the other library contributors (thankfully got strtok before the
website was blocked )
Just my 2p worth.
Chris
30. Re: include statement bugs
Alexander Toresson wrote:
----------
>
> posted by: Alexander Toresson <toressonodakra at swipnet.se>
>
> Igor Kachan wrote:
> > Try please the below thing instead:
> >
> > unkmarlib.e
> > scoobylib.e
> > jamilib.e
> > dereklib.e
> > wingzerolib.e
> >
> > And you'll never have a problem, this solution is without endless
> > ///////// at all,
> > and it works just now, do you see ????
>
> There you see. It's a hack. It works now, but not forever.
Ok, let us see when it will not work.
Let us wait that catastrophe when we can not rename our libs.
> He gave an example of a problem that could occur.
His example is just an artificial problem of two
boys that do know nothing about Euphoria, but want to
contribute the libs with the same names.
Their mistake is very simple and can be corrected with
a few keystrokes.
> Didn't you understand that?
Why not? I just do understand that two or more libs
with the same name will confuse anyone programmer.
--AnyOne in the World!--
Didn't you understand that?
> Wouldn't it be good if we could get rid of all renaming?
What all renaming? Just Chris found two libs with the same
name on his HDD and wants Rob to change the programming
system to handle these lib files without renaming.
What all renaming? Just one of two Chris' files.
I do not know another such case in Eu for now.
Do you know the second one?
> Regards, Alexander Toresson
>
> Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
Yesss! I'm hunting tooo! On good ideas!
Regards,
Igor Kachan
kinz at peterlink.ru
31. Re: include statement bugs
Normally I side with Rob on this type of question. But here I must agree
with the critics. The assumption that c:\x\foo.e is the same file as
c:\y\foo.e would not be made by any OS or application, and Eu shouldn't be
doing it either. Changing the behavior as suggested won't break any existing
code and would facilitate good orgainzation of include files.
The suggestion that you just rename the files is fatuous. Others have
argued the case quite forcefully and I won't repeat the arguments here.
-- Mike Nelson
32. Re: include statement bugs
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Oct 18, 2004
-
Last edited Oct 19, 2004
Mike Nelson wrote:
----------
> Normally I side with Rob on this type of question. But here I must agree
> with the critics. The assumption that c:\x\foo.e is the same file as
> c:\y\foo.e would not be made by any OS or application, and Eu shouldn't
> be doing it either. Changing the behavior as suggested won't break any
> existing code and would facilitate good orgainzation of include files.
The "good orgainzation of include files" is an issue of a taste.
There are some programs in The Archive just to delete double files.
The very useful tools, try them please. Work Ok for me.
Then, I'd prefer to not confuse the file name and the full path to that
file.
File name is a copyrighted thing, but a full path is just yours taste
thing.
EUPHORIA works with the file names of our libs.
It is good respect to authors of EU libs.
> The suggestion that you just rename the files is fatuous.
Ok, I like that yours "fatuous" without concrete yours receipt of what to
do for Chris. If he wants these libs to work, there is only this "fatuous"
way - to rename one of his libs.
> Others have argued the case quite forcefully and I won't repeat the
> arguments here.
>
> -- Mike Nelson
Regards,
Igor Kachan
kinz at peterlink.ru
33. Re: include statement bugs
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Oct 18, 2004
-
Last edited Oct 19, 2004
Oh, Brian, if I can remember, yours
contribution was one of the very first to the
RDS free Archive, my respects and regards to you!
You wrote:
----------
> From: Brian Broker <bkb at cnw.com>
> To: EUforum at topica.com
> Subject: RE: include statement bugs
> Sent: 18 oct 2004 y. 23:35
>
>
> I think the obvious solution here is to have Igor download every library
> contribution in the archives and find any possible library naming
> conflicts and then he can email the authors and make them change the
> names of their libraries.
I think, this is an author's job. My own libs do not make
any conflicts for now, as far as I know.
Let me know please about any conflicts, and I'll change any
my lib name you want, if you can not change one on your side.
> He should also make a list of all the names
> that are taken so we won't make this mistake in the future (but he
> should still check every new submission, just in case).
Such the list you can see in one of my packages - ru_eu_9_.zip
There are more than 11000 names of functions, constants,
libs(!) etc. Try, maybe it is useful for you.
Just now. It is EU.
> He could take it a step further and make sure that there are no two
> global functions/procedures/variables/constants with the same name...
> then we won't have any namespacing issues at all! Simple, no?
>
> -- Brian
This is a big work, but it is not too big, be sure.
And it may be very useful for some younger boy than me.
Regards,
Igor Kachan
kinz at peterlink.ru
34. Re: include statement bugs
- Posted by "Unkmar" <L3Euphoria at bellsouth.net>
Oct 18, 2004
-
Last edited Oct 19, 2004
----- Original Message -----
From: "Igor Kachan"
Sent: Monday, October 18, 2004 2:08 PM
Subject: Re: include statement bugs
>
>
> Hi, Lucius!
>
> You wrote:
>
> [snip]
[snip]
>> Another one blinded.
>>
>> johnny/text.e
>> global function center(sequence data)
>> -- fill in code
>> end function
>> alfred/text.e
>>
>> global function justify(sequence text)
>> -- fill in code
>> end function
>
> Who is that johnny?
> Who is that alfred?
johnny and alfread are made up names
>> Both libs have nothing in common and neither of them belong to me.
>> now, that is just a simple short example. Not shrouded or anything like
>> that.
>> but the problem goes much deeper because of collective libs.
>
> The lagest collection of the Euphoria libs is the RDS Archive.
And it does not happily exist within itself.
If you attempted to include every single DOS only lib that has
been supplied. Assuming that not even 1 routine name was duplicated
you will still not be able to make it happy.
[snip]
>>
>> unkmar/lib.e
>> scooby/lib.e
>> jami/lib.e
>> derek/lib.e
>> wingzero/lib.e
>> ....
>
> Try please the below thing instead:
>
> unkmarlib.e
> scoobylib.e
> jamilib.e
> dereklib.e
> wingzerolib.e
>
> And you'll never have a problem, this solution is without endless
> ///////// at all,
> and it works just now, do you see ????
won't work.
unkmarlib.e has the following in it.
include unkmar/1.e
include unkmar/2.e
and
scoobylib.e has the following
include scooby/3.e
include scooby/4.e
and so on....
Now I have to not only rename all of MY libs, but I must rename all
of everybody else's libs that I use. And alter everyone of them to be
sure they point to the proper renamed lib files.
> I think those johnny & alfred will rename their libbies just now,
> to avoid The Giant Crash of Euphoria becouse of that terrible Rob's bug.
>
both johnny and alfred shrouded their code
johnny died
alfred doesn't use euphoria anymore and can't be contacted.
> Hey, johnny & alfred, am I right?
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
unkmar
35. Re: include statement bugs
- Posted by "Unkmar" <L3Euphoria at bellsouth.net>
Oct 18, 2004
-
Last edited Oct 19, 2004
----- Original Message -----
From: "Brian Broker"
Sent: Monday, October 18, 2004 4:35 PM
Subject: RE: include statement bugs
>
>
> I think the obvious solution here is to have Igor download every library
> contribution in the archives and find any possible library naming
> conflicts and then he can email the authors and make them change the
> names of their libraries. He should also make a list of all the names
> that are taken so we won't make this mistake in the future (but he
> should still check every new submission, just in case).
>
> He could take it a step further and make sure that there are no two
> global functions/procedures/variables/constants with the same name...
> then we won't have any namespacing issues at all! Simple, no?
>
> -- Brian
Igor, I aplogize. It looks like Brian has a solution that I can leave with.
So, when will you be getting on that task of making sure nothing clashes
and ensuring that all the authors are notified of how the clash and the
changes they should make. :P
unkmar
36. Re: include statement bugs
----- Original Message -----
From: "ChrisBurch2" <guest at RapidEuphoria.com>
To: <EUforum at topica.com>
Sent: Monday, October 18, 2004 2:54 PM
Subject: Re: include statement bugs
>
>
> posted by: ChrisBurch2 <crylex at freeuk.co.uk>
>
> Hi
>
> For what its worth, compared to all the eu giants here, just thought I'd add
> my 2p worth.
>
> SHUTUP AND STOP YOUR MOANING!
if (we don't MOAN) then
nothing gets fixed
else
somethings get fixed
end if
>
> You've got a great language here, which has its limitations (as does any
> other)
> but you can find find ways and workarounds like you do in any other language.
Several serious limitations
Some things can't be resonably worked around.
In fact, Several of our attemps to work around have been thwarted with
even more serious flaws introduced.
> So what if you have to rename an include, or find another way to do something.
> Thats part of the challenge.
rename 1 include. FINE
But the problem is much more than 1 or even 20 includes being renamed.
Not only must you rename but you must alter any files that you use that
included
that file under its old name.
And you must repeat that process for EVERY include that you rename.
Old working code will suddenly break because you didn't think about it using the
very include that you renamed. You were busy with the CURRENT project.
> I've had problems too, and worked through them (eg eugtk subfolder include).
Thus perpetuating the seriousness of the problem. Helping it to snowball much
further than it should have ever gotten by simply remaining silent.
Don't shut up. SPEAK UP!!!
> If the list has problems with include file names and version numbers, then
> create a standard naming convention for include submissions. If your
> program can't find the most up to date version, then write a routine
> to copy the file to the current directory of the older version, rename it
> and include it - etc etc.
>
> I'm VERY happy with the way things are, no need to change. Good job RobC,
> and ALL the other library contributors (thankfully got strtok before the
> website was blocked )
>
> Just my 2p worth.
>
> Chris
unkmar
37. Re: include statement bugs
This is absolutely ridiculous in my opinion. In all the time that people
have invested in beating this dead horse, why hasn't anyone seriously
discussed the idea that we could all use one set of include files?
Obviously more of the archives are going to be broken no matter what
happens, and all my code will be crippled, as will the code of others I
tend to share with, but it isn't like the entire set couldn't be replaced
at least 10 times over.
It's painfully obvious that the includes distributed with the interpreter
are inadequate. They've been virtually unchanged for at least 5 years (no
major changes), and Euphoria is still stuck right where it was at least 5
years ago. This isn't just a coincidence, this is the REASON for the lack
of advancement.
First of all, Rob has never expressed any support for this idea that I
have ever seen or heard of. This lends to the idea that he only endorses
the files that are installed with the interpreter, and in turn causes
most people to build upon those includes. Since they are just not enough
in most cases, almost everyone who uses them must write their own
includes to expand upon that code, and this in turn leads to conflicts
with other libraries, because EVERYONE is doing it.
Then, the community in general seems to either oppose, or hold absolutely
no interest in, any set of files that can't replace the original set with
ABSOLUTELY NO PROBLEMS OR MODIFICATIONS. So now the problem is finally
forced upon us? I, for one, don't think so. It seems to me that the
community has DECIDED that Euphoria should remain right where it's at.
If this language is going to advance and grow, everyone needs to get past
the notion that we can keep backward compatibility with everything ever
written for ever and ever. With the proper planning and support from more
than about three people, we could work toward a better, more
comprehensive set of includes, that would alleviate ALL these problems in
one fell swoop. The road won't be easy, but am I the only one who can see
that if an include file is worth re-using, modifying it ONE TIME to run
on a new, and better set, is still easier than writing a different
version for each user who wants to include it?
Jason
38. Re: include statement bugs
Chris Bensler wrote:
-----
>
> Igor Kachan wrote:
> >
> > Mike Nelson wrote:
[snip]
>
> I have 250kb of Euphoira libraries, being readied as a new alternative
> to RDS's standard libraries.
OK, it is great, but why do you think the standard RDS's libraries
need a new alternative?
> I would like to be able to allow users to use either one,
> or possibly BOTH at once.
OK, no problem. Add some letter to the name of standard RDS
library. Me uses the 'r' letter - Russian, say, file___r.e
instead of standard file.e.
My file___r.e works in both Russian and English.
Try please, it is in The Archive.
> My libraries use many of the same file names as RDS does,
> and for good reason.
What is that good reason to make any conflict with the
standard copyrighted PD programming stuff, 11 years old,
working without any problem for dozens thousands of users?
Do you have any respect to those people?
> I resent the opinion that I should have to rename all of my
> meaningfully named files, just to accomodate your ignorance of the
> problem.
Chris, you have to *name* yours libs *properly* and then
you'll have no problem.
> Do you know what I can do instead?
> I can simply not release my libraries.
I think, it is your problem what to do with yours property.
> That saves everybody the headache
> of dealing with filename conflicts.
Do not create these conflicts yourself.
> Chris Bensler
> Code is Alchemy
Good Luck!
Regards,
Igor Kachan
kinz at peterlink.ru
39. Re: include statement bugs
Lucius Hilley wrote:
[snip]
> >
> > Who is that johnny?
> > Who is that alfred?
>
> johnny and alfread are made up names
>
OK, no problem, they do not exist at all.
Good Luck to johnny & alfread!
[snip]
>>>
>>> unkmar/lib.e
>>> scooby/lib.e
>>> jami/lib.e
>>> derek/lib.e
>>> wingzero/lib.e
>>> ....
>>
>> Try please the below thing instead:
>>
>> unkmarlib.e
>> scoobylib.e
>> jamilib.e
>> dereklib.e
>> wingzerolib.e
>>
>> And you'll never have a problem, this solution
>> is without endless ///////// at all,
>> and it works just now, do you see ????
>
> won't work.
> unkmarlib.e has the following in it.
> include unkmar/1.e
> include unkmar/2.e
Hey, Lucius, unkmarlib.e is yours lib,
all things are in your hands!
> and
> scoobylib.e has the following
> include scooby/3.e
> include scooby/4.e
>
> and so on ...
> Now I have to not only rename all of MY libs, but I must rename all
> of everybody else's libs that I use. And alter everyone of them to be
> sure they point to the proper renamed lib files.
First of all, the libs must be properly named, is it a big news for you?
>> I think those johnny & alfred will rename their libbies just now,
>> to avoid The Giant Crash of Euphoria becouse of that terrible
>> Rob's bug.
>>
>
> both johnny and alfred shrouded their code
> johnny died
> alfred doesn't use euphoria anymore and can't be contacted.
Poor johnny & alfred! They'll never use Euphoria anymore!
>
>> Hey, johnny & alfred, am I right?
Poor johnny & alfred! They'll never use Euphoria anymore!
Poor johnny & alfred! They'll never use Euphoria anymore!
Poor johnny & alfred! They'll never use Euphoria anymore!
Hey, Dear EU users, never shroud your code please!
Just to be immortal ... Me almost never shrouds ...
Regards,
Igor Kachan
kinz at peterlink.ru
40. Re: include statement bugs
On Tue, 19 Oct 2004 11:04:42 +0300, Igor Kachan <kinz at peterlink.ru> wrote:
<SNIP>
> Poor johnny & alfred! They'll never use Euphoria anymore!
> Poor johnny & alfred! They'll never use Euphoria anymore!
> Poor johnny & alfred! They'll never use Euphoria anymore!
>
>
>
> Hey, Dear EU users, never shroud your code please!
> Just to be immortal ... Me almost never shrouds ...
Igor, it's obvious that you feel strongly about this issue... why?
Euphoria as coded assumes that files with the same name are the same
file. As Rob himself has stated, this is a HACK.
A quick-and-dirty, i-can't-be-bothered-implementing-it-properly HACK!
It never should have been like this in the first place. The only
reason it is like this is due to laziness. (Or, giving Rob the benefit
of the doubt, other developmental pressures)
You're quite adept at attacking those who submit reasons why it should
be fixed, but you haven't given any reasons for keeping the HACK as it
is.
Please, tell us. Why should it stay as it is?
I believe that Euphoria should NOT assume that 2 files in different
locations are the same file. This is because:
1. It produces unexpected, undocumented behaviour.
2. It is illogical. There is no supporting argument for keeping it as-is
3. It makes using third-party libraries more difficult.
--
MrTrick
41. Re: include statement bugs
Chris Bensler wrote:
----------
> From: Chris Bensler <bensler at nt.net>
> To: EUforum at topica.com
> Subject: RE: include statement bugs
> Sent: 19 oct 2004 y. 9:21
>
> Igor Kachan wrote:
>
> <SNIP>
>
> > OK, it is great, but why do you think the standard RDS's libraries
> > need a new alternative?
>
> It's blatantly obvious that any explanation to you would be in vain.
Ok, I am not a single reader of yours e-mails, maybe others
want to see your explanations.
> <SNIP>
>
> > OK, no problem. Add some letter to the name of standard RDS
> > library. Me uses the 'r' letter - Russian, say, file___r.e
> > instead of standard file.e.
> > My file___r.e works in both Russian and English.
> > Try please, it is in The Archive.
>
> That means changing the filenames of your precious RDS include files.
These RDS include files are really precious, any EU user uses them.
And I do not *change* the standard filenames.
I just use the standard name as a part of a *new* name of
my *new* include file. The standard filename and the standard
library are untouchable.
Is it clear? The simple thing, it seems to be, no?
Maybe someone else can explain this trick to Chris?
> > > My libraries use many of the same file names as RDS does,
> > > and for good reason.
> >
> > What is that good reason to make any conflict with the
> > standard copyrighted PD programming stuff, 11 years old,
> > working without any problem for dozens thousands of users?
> > Do you have any respect to those people?
>
> Because backwards compatability is a detriment to the optimal progress.
> Because the names are _meaningful_ . Because I CHOOSE to.
> Because I'm not going to use obscure names, just because you are too
> blind/stubborn to accept the fact that it's perfectly logical to have 2
> files with the same name and different content and/or intent.
Ok, Ok, Ok, progress-shmogress, ok, but what about "any respect"?
The simple thing too, I think, no?
> > > I resent the opinion that I should have to rename all of my
> > > meaningfully named files, just to accomodate your ignorance of the
> > > problem.
> >
> > Chris, you have to *name* yours libs *properly* and then
> > you'll have no problem.
>
>
> I DID name my files properly..
> I use include statements such as std/util/file.e
> and rds/file.e
But what is a reason of your problems?
Do you want to replace the standard RDS files with your own
unknown for us files? Yes?
And a good antibug EU resistance doesn't allow you to
make this "buggy revolution"? Yes?
Yes, I found some of your contributions buggy and
crashed for me. Sorry, Chris ...
Yes, you was out of town for a while... What can I do?
Well, but EU standard libs never crash on my 5 different
machines. From 386 mainframe to P4 1.8.
Be careful, please, Chris.
Do not make many noise around yours alternative to RDS libs.
Let us know them first of all.
> The fact that RDS is too stupid to realize that it is a very useful
> functionality, will be YOUR problem when Euphoria is fumbling with hack
> solutions, and you have no choice but to live with it or pick up a new
> language. You can rename all your files, I won't. That is perposterous.
I never see some stupidity from RDS, but I do know some your buggy
products. Sorry, Chris, again.
You do not want new names for the new libs, but your reason
seems to be not very good, sorry, sorry, sorry ...
> Chris Bensler
> Code is Alchemy
Regards,
Igor Kachan
kinz at peterlink.ru
PS What is 'perposterous'? - I have
no this rare word in my Muller's dictionary.
42. Re: include statement bugs
Jason Mirwald wrote:
----------
> From: Jason Mirwald <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: include statement bugs
> Sent: 19 oct 2004 y. 6:59
>
> posted by: Jason Mirwald <jmirwald at ameritech.net>
>
> This is absolutely ridiculous in my opinion. In all the time that people
> have invested in beating this dead horse, why hasn't anyone seriously
> discussed the idea that we could all use one set of include files?
I think, there is no the task for too big set of the existing
include files. Say, just win32lib + w32engine have about 10000
global names at all.
You can program any thing you want just now.
Most of users just do not need new sets of libs.
Include and use existing ones.
win32lib + w32engine + bilingual Euphoria with the unlimited
alphabet has about 11000 global names at all.
Almost all Windows API functions + power of Euphoria itself
are under your fingers just now.
win32lib includes the standard EU libs.
The standard EU libs - just about 20 files, about 160K at all.
The rest tools and programs are created by happy users - more
than 1300 packages, about 400 authors.
If you have some good idea for programming, program please,
all tools are ready for you just now and foreve.
> Obviously more of the archives are going to be broken no matter what
> happens, and all my code will be crippled, as will the code of others I
> tend to share with, but it isn't like the entire set couldn't be replaced
> at least 10 times over.
>
> It's painfully obvious that the includes distributed with the interpreter
> are inadequate. They've been virtually unchanged for at least 5 years (no
> major changes), and Euphoria is still stuck right where it was at least 5
> years ago. This isn't just a coincidence, this is the REASON for the lack
> of advancement.
There is no any need to distribute by RDS itself something additional
to RDS standard package - download the needed package from EU sites
just now and use. RDS has the largest of EU sites.
There is no any need to co-ordinate the activity of those
independent authors. They work and contribute, work and contribute.
What else?
Then, include files by RDS allow you to *remake* all Archive,
all 1300 packages, if you want, from the scratch.
This is the real power of that simple little language.
> First of all, Rob has never expressed any support for this idea that I
> have ever seen or heard of. This lends to the idea that he only endorses
> the files that are installed with the interpreter, and in turn causes
> most people to build upon those includes. Since they are just not enough
> in most cases, almost everyone who uses them must write their own
> includes to expand upon that code, and this in turn leads to conflicts
> with other libraries, because EVERYONE is doing it.
It is a good thing - the end users can do all they need themselves,
and do it themselves and do it one for others.
> Then, the community in general seems to either oppose, or hold absolutely
> no interest in, any set of files that can't replace the original set with
> ABSOLUTELY NO PROBLEMS OR MODIFICATIONS.
You must to prove that the original set requires to be replaced
with something else. Prove first of all.
I do not like if someone returns from the vacation and says -
all around is shit, crap, shitty crap, crappy shit, I'll replace
all that just now with my own big one, but only under yours name.
Sorry please, life is life, I do not like these words, but they
are the most suitable now, I think.
> So now the problem is finally
> forced upon us? I, for one, don't think so. It seems to me that the
> community has DECIDED that Euphoria should remain right where it's at.
>
> If this language is going to advance and grow, everyone needs to get past
> the notion that we can keep backward compatibility with everything ever
> written for ever and ever. With the proper planning and support from more
> than about three people, we could work toward a better, more
> comprehensive set of includes, that would alleviate ALL these problems in
> one fell swoop. The road won't be easy, but am I the only one who can see
> that if an include file is worth re-using, modifying it ONE TIME to run
> on a new, and better set, is still easier than writing a different
> version for each user who wants to include it?
>
> Jason
Oh-ho-ho-oh, Jason, let us wait for 2.5 and test it first of all. Ok?
Regards,
Igor Kachan
kinz at peterlink.ru
43. Re: include statement bugs
----- Original Message -----
From: "irv mullins"
Sent: Tuesday, October 19, 2004 9:05 AM
Subject: The Perfect Solution
Bad subject name.
>
> posted by: irv mullins <irvm at ellijay.com>
[snip]
> RDS *can* simply assign a unique Euphoria User ID to each user, and
> when contributing to the archives, you will use that number as the
> extension for your files, as in 'window.123', where 123 is, of course,
> your EUID. So our euphoria/include directory can have any number of
> files named 'window.xxx', but there will be no conflicts.
This is a hilarious suggestion.
> I realize this plan will limit the total number of contributors to 999,
Ever heard of LFN (Long File Names)
We could all just as easily prefix all of our libs with a unique nick.
That solves the problem for all that conform to this behavior and do
not use code from any that don't.
> assuming RDS will reserve the .000 extension for themselves.
> That shouldn't be a problem. If the number of contributors ever did
> by some miracle grow to 999, there's a long (and growing) list of
> people who have gone away never to return. Their numbers could be
> reassigned.
>
> Irv
unkmar
44. Re: include statement bugs
Hi, Patrick!
You wrote:
----------
> From: Patrick Barnes <mrtrick at gmail.com>
> To: EUforum at topica.com
> Subject: Re: include statement bugs
> Sent: 19 oct 2004 y. 10:27
>
>
> On Tue, 19 Oct 2004 11:04:42 +0300, Igor Kachan <kinz at peterlink.ru>
wrote:
> <SNIP>
> > Poor johnny & alfred! They'll never use Euphoria anymore!
> > Poor johnny & alfred! They'll never use Euphoria anymore!
> > Poor johnny & alfred! They'll never use Euphoria anymore!
> >
> >
> >
> > Hey, Dear EU users, never shroud your code please!
> > Just to be immortal ... Me almost never shrouds ...
>
> Igor, it's obvious that you feel strongly about this issue... why?
>
> Euphoria as coded assumes that files with the same name are the same
> file. As Rob himself has stated, this is a HACK.
Ok, it is the very useful hack. Just happy hack.
1. It is very useful to learn Euphoria.
Imagine please, you have two different libraries with the same name,
and you need to work with them. It is just very awkwardly and
uncomfortably to remember all the time who is who and what is what.
The long names for files, the local langs for the names of files, the
case of the letters for the names of files, the descriptions of the
files -- all these useful things become just extra feature for the
files with the same name.
Anyone will confuse these files, if they have same name.
It is very clear for me.
And imagine please, you have not 2, but 3 or more same names.
2. The name of a file is its copyright attribute.
Authors love the names of their files, routines, constants,
variables. I have investigated the big EU libs - win32lib, w32engin,
some others. 11000 names. The name conflicts are very-very rare.
People love the new names, it is a fact for me.
Many of us just do not want that someone will use the name of their
file. Use my file for your work, edit it, add something, but do not
use the name of my original work.
It is the very coommon thing about intellectual property.
3. RDS's 'hack' is very good in those regards.
There are no any scandals in our community about the
intellectual properties - it is just impossible thing,
Euphoria only uses the very first library of given name.
Be happy, Dear EU users!
[snip]
Regards,
Igor Kachan
kinz at peterlink.ru
45. Re: include statement bugs
- Posted by Patrick Barnes <mrtrick at gmail.com>
Oct 19, 2004
-
Last edited Oct 20, 2004
On Tue, 19 Oct 2004 22:00:18 +0300, Igor Kachan <kinz at peterlink.ru> wrote:
> > Igor, it's obvious that you feel strongly about this issue... why?
> >
> > Euphoria as coded assumes that files with the same name are the same
> > file. As Rob himself has stated, this is a HACK.
>
> Ok, it is the very useful hack. Just happy hack.
>
> 1. It is very useful to learn Euphoria.
> Imagine please, you have two different libraries with the same name,
> and you need to work with them. It is just very awkwardly and
> uncomfortably to remember all the time who is who and what is what.
> The long names for files, the local langs for the names of files, the
> case of the letters for the names of files, the descriptions of the
> files -- all these useful things become just extra feature for the
> files with the same name.
> Anyone will confuse these files, if they have same name.
> It is very clear for me.
> And imagine please, you have not 2, but 3 or more same names.
No, that is not the point.
I'm not going to name two of my libraries the same.
However, a library written by "Alfred" (And don't ask me who Alfred
is, this is an EXAMPLE) uses a little include called tree.e to
accomplish its purpose.
A library written by "Johnny" uses another include that just happens
to be called tree.e to accomplish its purpose.
This is a similar problem to the namespacing issues. I *cannot* use
both "Alfred"'s and "Johhny"'s libraries in my program, because of
this HACK.
- It is not *my* responsibility to go and change alfred's or johnny's
library so that this doesn't happen. Even if I changed the name of
"tree.e", I'd have to go through an entire library changing all of the
names over. And now, it wouldn't be compatible with the real version
of the library. Every time one of them releases a new version, I'd
have to do it again.
- It is not "Alfred"'s or "Johnny"'s responsibility to make sure that
none of their names are the same as any of the other libraries out
there. There are thousands of contributions. If I make a new library,
how far back to I have to search? Do I have to make sure that I don't
duplicate the file name that a library used more than 10 years ago?
That's excessive. I'll bet you didn't do that for any libraries
*you've* released.
- If it's the responsibility of anyone, it's Rob.
> 2. The name of a file is its copyright attribute.
> Authors love the names of their files, routines, constants,
> variables. I have investigated the big EU libs - win32lib, w32engin,
> some others. 11000 names. The name conflicts are very-very rare.
Really? So, whom does 'ini.e' belong to? Who owns the name 'struct.e'?
win32lib is known, and noone will else will use that name. However,
many names are generic, and if the programmers think logically when
they write a library, utility files are quite likely to exist with the
same name.
> It is the very coommon thing about intellectual property.
A NAME is not intellectual property. It never is, if you had any idea
about legal mumbo jumbo.
A NAME can be a trademark. However, you cannot trademark generic
terms. Noone can trademark the name "math.e", because it is a generic
term.
> 3. RDS's 'hack' is very good in those regards.
> There are no any scandals in our community about the
> intellectual properties - it is just impossible thing,
Again see above, you are mistaken in your idea of 'intellectual property'
Igor, you AGAIN pushed your ideals, but did not address any of the
points I raised. I can and will not take you for anything other than a
Troll unless you can answer them:
>Patrick Barnes wrote:
>I believe that Euphoria should NOT assume that 2 files in different
>locations are the same file. This is because:
>1. It produces unexpected, undocumented behaviour.
>2. It is illogical. There is no supporting argument for keeping it as-is
>3. It makes using third-party libraries more difficult.
As well, fixing this HACK would ensure that these problems as
described above do not occur. Igor, can you give me even a single
example where remedying it would cause problems?
Would correcting the behaviour break libraries? NO!
Would it produce undocumented behaviour? NO!
And Rob, you have this annoying habit of being a wallflower whenever a
discussion comes up about the language itself. I know you are proud of
Euphoria, and you have every right to be, but don't pretend that it's
perfect, and that every action you have ever made regarding the
language is correct. Please weigh in on this issue. Do *you* have any
opinion regarding why it shouldn't be changed?
--
MrTrick
46. Re: include statement bugs
Patrick Barnes wrote:
----------
>
> On Tue, 19 Oct 2004 22:00:18 +0300, Igor Kachan <kinz at peterlink.ru>
wrote:
> > > Igor, it's obvious that you feel strongly about this issue... why?
> > >
> > > Euphoria as coded assumes that files with the same name are the same
> > > file. As Rob himself has stated, this is a HACK.
> >
> > Ok, it is the very useful hack. Just happy hack.
> >
> > 1. It is very useful to learn Euphoria.
> > Imagine please, you have two different libraries with the same
name,
> > and you need to work with them. It is just very awkwardly and
> > uncomfortably to remember all the time who is who and what is what.
> > The long names for files, the local langs for the names of files,
the
> > case of the letters for the names of files, the descriptions of the
> > files -- all these useful things become just extra feature for
the
> > files with the same name.
> > Anyone will confuse these files, if they have same name.
> > It is very clear for me.
> > And imagine please, you have not 2, but 3 or more same names.
>
> No, that is not the point.
> I'm not going to name two of my libraries the same.
OK, you are not going, but who is going?
> However, a library written by "Alfred" (And don't ask me who Alfred
> is, this is an EXAMPLE) uses a little include called tree.e to
> accomplish its purpose.
OK, I just think that Alfred was clever enough to see the *existing*
libraries *before* his work on *new* one.
If he was not clever enough about this simplest thing -- to see what is
*already done*, I do not think that his library may be too useful for
the existing EU RDS Archive.
The "library routine" is just one of dozen sections of the RDS Archive.
It is too important section to be dirty and ambiguous.
Do you see, I think Alfred is very clever boy, same as you?
If he is not very clever, I am sorry, he needs some good school.
A good school will not teach him on the libraries with the identical
names, I think. But if will, our poor Alfred risks to get crazy.
And our Chris is very-very clever boy, he wanted just replace without
any noise the copyrighted PD standard set of RDS libraries, see,
he wrote: "RDS has established some crappy libraries as standards",
by RDS own hands - force RDS to allow *full path*
instead of the pure library name.
Our Chris is the very-very clever boy, he learned that "crappy Rob's
Euphoria" and now wants to have his own one.
Ok, what a problem, Karl has, Matt has, there is unlimited alphabet
Euphoria.
But if the standard Euphoria is so bad, why he wants his own one
in such unusual manner?
> A library written by "Johnny" uses another include that just happens
> to be called tree.e to accomplish its purpose.
>
> This is a similar problem to the namespacing issues. I *cannot* use
> both "Alfred"'s and "Johhny"'s libraries in my program, because of
> this HACK.
OK, but this is not a real problem at all.
There is no libraries in The Atchive with the identical names and never
will, I think. I think about clever EU boys, remember please.
Just Chris wanted such the feature for his strongly concrete purposes
- first of all to replace the standard copyrighted stuff.
Remember please again, these standard libraries were *stamped* by RDS for a
while. Then Rob deleted these encrypted stamps - you can see one of results
now.
> - It is not *my* responsibility to go and change alfred's or johnny's
> library so that this doesn't happen. Even if I changed the name of
> "tree.e", I'd have to go through an entire library changing all of the
> names over. And now, it wouldn't be compatible with the real version
> of the library. Every time one of them releases a new version, I'd
> have to do it again.
If and if and if and if .....
> - It is not "Alfred"'s or "Johnny"'s responsibility to make sure that
> none of their names are the same as any of the other libraries out
> there. There are thousands of contributions. If I make a new library,
> how far back to I have to search? Do I have to make sure that I don't
> duplicate the file name that a library used more than 10 years ago?
> That's excessive. I'll bet you didn't do that for any libraries
> *you've* released.
If and if and if and if ....
> - If it's the responsibility of anyone, it's Rob.
Yes, Rob hardly knows his responsibility for Euphoria and protects
his own intellectual and material rights as a real expert and excellent
master, I think.
> > 2. The name of a file is its copyright attribute.
> > Authors love the names of their files, routines, constants,
> > variables. I have investigated the big EU libs - win32lib,
w32engin,
> > some others. 11000 names. The name conflicts are very-very rare.
>
> Really? So, whom does 'ini.e' belong to? Who owns the name 'struct.e'?
> win32lib is known, and noone will else will use that name. However,
> many names are generic, and if the programmers think logically when
> they write a library, utility files are quite likely to exist with the
> same name.
Yes, really, the copyrighted stuff *must* to have its own name.
And if you do see the copyrighted existing 'struct.e' and want your
own similar library, the best way is to use the *new* good name to avoid
any confusion first of all.
Remember please Tommy's efforts around his new " Win4Eu".
> > It is the very coommon thing about intellectual property.
>
> A NAME is not intellectual property. It never is, if you had any idea
> about legal mumbo jumbo.
> A NAME can be a trademark. However, you cannot trademark generic
> terms. Noone can trademark the name "math.e", because it is a generic
> term.
The name and product are indivisible.
And there are the protected names - trademarks.
If you care, you can register the name of your program, but it is the very
expensive thing.
No one care here, as I can see, we just respect the rights on the name
without registration. The case with Chris is single and first as far as I
know.
> > 3. RDS's 'hack' is very good in those regards.
> > There are no any scandals in our community about the
> > intellectual properties - it is just impossible thing,
>
> Again see above, you are mistaken in your idea of 'intellectual property'
No, I am not mistaken, I respect the right of an author on the name of his
product independently if this name is *registered and protected* by the law
or I just see this name in The Archive.
There is no difference for me - author is author. If he was the very first
- he is the very first foreve.
> Igor, you AGAIN pushed your ideals, but did not address any of the
> points I raised. I can and will not take you for anything other than a
> Troll unless you can answer them:
>
> >Patrick Barnes wrote:
> >I believe that Euphoria should NOT assume that 2 files in different
> >locations are the same file. This is because:
> >1. It produces unexpected, undocumented behaviour.
The behaviour of Euphoria interpereter is strongly documented - filename of
library. Full path and filename are different things.
> >2. It is illogical. There is no supporting argument for keeping it as-is
My arguments see please above and below.
> >3. It makes using third-party libraries more difficult.
No, there is no such the third-party libraries at all.
You have nothing to use this way.
> As well, fixing this HACK would ensure that these problems as
> described above do not occur. Igor, can you give me even a single
> example where remedying it would cause problems?
No one is going to create the libraries with the identical names now.
Clever boys do not want, the very-very clever boy wants, but can not.
I do not think Rob wants to implement this strange useless feature
in the standard EU.
Let us wait and see some forked examples.
> Would correcting the behaviour break libraries? NO!
Useless and bad feature.
Irv did not find the libs with the identical names in other
languages for now.
Let us see the reason if he finds one.
And his "perfect solution" is like to prison or such.
> Would it produce undocumented behaviour? NO!
The Euphoria documentation is clear, interpreter has no this bug,
there is no this problem.
What do you want, MrTrick?
What about fish & chips?
> And Rob, you have this annoying habit of being a wallflower whenever a
> discussion comes up about the language itself. I know you are proud of
> Euphoria, and you have every right to be, but don't pretend that it's
> perfect, and that every action you have ever made regarding the
> language is correct. Please weigh in on this issue. Do *you* have any
> opinion regarding why it shouldn't be changed?
Let us respect the Rob's intellectual rights on his Euphoria.
He is the author of that excellent language.
Life is life, no?
I just do not like if some too clever boy returns from the vacation and
says - all around is shit, crap, shitty crap, crappy shit, I'll replace
all that just now with my own big one, but only under YOURS NAME,
hurry up Rob, implement this for me just now, I love your Euphoria
more than you do love, stupid Rob.
And this too clever boy just forgot his naive questions to this
list years ago.
Good behaviour of grateful and thankful apprentice, no?
Again: What about fish & chips, MrTrick?
Regards,
Igor Kachan
kinz at peterlink.ru
47. Re: include statement bugs
Igor Kachan wrote:
> OK, I just think that Alfred was clever enough to see the *existing*
> libraries *before* his work on *new* one.
>
> If he was not clever enough about this simplest thing -- to see what is
> *already done*, I do not think that his library may be too useful for
> the existing EU RDS Archive.
There are 1100 user contributions in the archive. Who checks all before
naming their libraries? Of course there won't be name clashes with the
10 most commonly used, but that's just 10.
> Do you see, I think Alfred is very clever boy, same as you?
>
> If he is not very clever, I am sorry, he needs some good school.
> A good school will not teach him on the libraries with the identical
> names, I think. But if will, our poor Alfred risks to get crazy.
>
> And our Chris is very-very clever boy, he wanted just replace without
> any noise the copyrighted PD standard set of RDS libraries, see,
> he wrote: "RDS has established some crappy libraries as standards",
> by RDS own hands - force RDS to allow *full path*
> instead of the pure library name.
>
YOU are saying that Chris is stupid and needs education?
That does really come from the right person. (WARNING! SARCASM!)
> But if the standard Euphoria is so bad, why he wants his own one
> in such unusual manner?
Because Euphoria is great, but could be greater. He wants to bring in some
competition.
> > - It is not *my* responsibility to go and change alfred's or johnny's
> > library so that this doesn't happen. Even if I changed the name of
> > "tree.e", I'd have to go through an entire library changing all of the
> > names over. And now, it wouldn't be compatible with the real version
> > of the library. Every time one of them releases a new version, I'd
> > have to do it again.
>
> If and if and if and if .....
We're talking about 1100 user contributions!
> Yes, Rob hardly knows his responsibility for Euphoria and protects
> his own intellectual and material rights as a real expert and excellent
> master, I think.
A lawful servant of the Euphoria empire, I see that you are.
> Yes, really, the copyrighted stuff *must* to have its own name.
> And if you do see the copyrighted existing 'struct.e' and want your
> own similar library, the best way is to use the *new* good name to avoid
> any confusion first of all.
The problem is how to know if there already is a library with the same
name. Remember, 1100 user contributions, damnit!
> The name and product are indivisible.
> And there are the protected names - trademarks.
> If you care, you can register the name of your program, but it is the very
> expensive thing.
> No one care here, as I can see, we just respect the rights on the name
> without registration. The case with Chris is single and first as far as I
> know.
And Chris wanted to add a directory where a library is kept into the
filename. My euphoria\include directory is a mess right now, and that
would fix it, by keeping one library in one directory, effectively
organizing it.
> > >1. It produces unexpected, undocumented behaviour.
>
> The behaviour of Euphoria interpereter is strongly documented - filename of
> library. Full path and filename are different things.
This is not. What would you expect, if you included two files with the
same filename, but in different directories? Would 'you' expect that
only one of them is loaded? No?
>
> > >2. It is illogical. There is no supporting argument for keeping it as-is
>
It truly is.
>
> > >3. It makes using third-party libraries more difficult.
>
> No, there is no such the third-party libraries at all.
> You have nothing to use this way.
Let me give you an example. Win32lib is a third-party library.
Every library that's not made by RDS are third-party libraries.
>
> No one is going to create the libraries with the identical names now.
> Clever boys do not want, the very-very clever boy wants, but can not.
> I do not think Rob wants to implement this strange useless feature
> in the standard EU.
>
1100 contributions damnit!
>
> > Would correcting the behaviour break libraries? NO!
>
> Useless and bad feature.
Useful and good.
> Irv did not find the libs with the identical names in other
> languages for now.
> Let us see the reason if he finds one.
The reason isn't that there are libraries with identical names,
but there could be. Only wait a few years. Maybe there are 10000 user
contributions?
>
> And his "perfect solution" is like to prison or such.
>
> > Would it produce undocumented behaviour? NO!
>
> The Euphoria documentation is clear, interpreter has no this bug,
> there is no this problem.
This is a bug. The euphoria documentation states that a file with the
specified filename is included, and a filename *can* have a path,
and therefore, this is a bug, and it should never have been :P
>
> > And Rob, you have this annoying habit of being a wallflower whenever a
> > discussion comes up about the language itself. I know you are proud of
> > Euphoria, and you have every right to be, but don't pretend that it's
> > perfect, and that every action you have ever made regarding the
> > language is correct. Please weigh in on this issue. Do *you* have any
> > opinion regarding why it shouldn't be changed?
>
> Let us respect the Rob's intellectual rights on his Euphoria.
> He is the author of that excellent language.
> Life is life, no?
But what if he doesn't do the the best for the language?
Enough of this dumbness and tunnel-seeing. The only reason I replied to
this post was that I got pissed off.
Regards, Alexander Toresson
Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
48. Re: include statement bugs
Alexander Toresson wrote:
-------
> From: Alexander Toresson <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: include statement bugs
> Sent: 20 oct 2004 y. 19:57
>
>
> posted by: Alexander Toresson <toressonodakra at swipnet.se>
>
> Igor Kachan wrote:
> > OK, I just think that Alfred was clever enough to see the *existing*
> > libraries *before* his work on *new* one.
> >
> > If he was not clever enough about this simplest thing -- to see what is
> > *already done*, I do not think that his library may be too useful for
> > the existing EU RDS Archive.
>
> There are 1100 user contributions in the archive. Who checks all before
> naming their libraries? Of course there won't be name clashes with the
> 10 most commonly used, but that's just 10.
More than 1300 now.
The "library routines" section is not so big.
Try please, the very interesting things.
> > Do you see, I think Alfred is very clever boy, same as you?
> >
> > If he is not very clever, I am sorry, he needs some good school.
> > A good school will not teach him on the libraries with the identical
> > names, I think. But if will, our poor Alfred risks to get crazy.
> >
> > And our Chris is very-very clever boy, he wanted just replace without
> > any noise the copyrighted PD standard set of RDS libraries, see,
> > he wrote: "RDS has established some crappy libraries as standards",
> > by RDS own hands - force RDS to allow *full path*
> > instead of the pure library name.
> >
>
> YOU are saying that Chris is stupid and needs education?
No, I do not. It seems, Chris are saying about stupidity.
So, he is the most educated and very-very clever here.
Isn't he? I do not think so, - that he is not.
> That does really come from the right person. (WARNING! SARCASM!)
No, I am not perfect myself, if you are saying about me now.
Without warning, please!
> > But if the standard Euphoria is so bad, why he wants his own one
> > in such unusual manner?
>
> Because Euphoria is great, but could be greater.
> He wants to bring in some competition.
Ok, it is great, I like competition, but he doesn't
say about competition.
He just wanted replace the standard copyrighted PD stuff
with some unknown stuff without any explanation,
what is so bad in the old well tested libraries.
Reread, please, this thread to be sure about his problem.
> > > - It is not *my* responsibility to go and change alfred's or johnny's
> > > library so that this doesn't happen. Even if I changed the name of
> > > "tree.e", I'd have to go through an entire library changing all of
the
> > > names over. And now, it wouldn't be compatible with the real version
> > > of the library. Every time one of them releases a new version, I'd
> > > have to do it again.
> >
> > If and if and if and if .....
>
> We're talking about 1100 user contributions!
More than 1300 at all, but the specialized section
is not that big. And it is the very interesting.
If someone wants to be a writer of Euphoria
libraries - that section is the exclusively interesting
and rich on ideas.
> > Yes, Rob hardly knows his responsibility for Euphoria and protects
> > his own intellectual and material rights as a real expert and excellent
> > master, I think.
>
> A lawful servant of the Euphoria empire, I see that you are.
No, I am not, I am just an old Russian retired submariner,
Euphoria is very useful for my work and I see it is good.
> > Yes, really, the copyrighted stuff *must* to have its own name.
> > And if you do see the copyrighted existing 'struct.e' and want your
> > own similar library, the best way is to use the *new* good name to
avoid
> > any confusion first of all.
>
> The problem is how to know if there already is a library with the same
> name. Remember, 1100 user contributions, damnit!
More than 1300, specialized section - about 200 items, is here:
http://www.RapidEuphoria.com/lib.htm
If you want to write some library for WIN32, see please
just WIN32 items, DOS32 - DOS32 items, Linux/FreeBSD - LIN
items, something generic - GEN items.
Just begin and you will see that this task - to know
what is already done - is simple enough, as Euphoria itself.
> > The name and product are indivisible.
> > And there are the protected names - trademarks.
> > If you care, you can register the name of your program, but it is the
very
> > expensive thing.
> > No one care here, as I can see, we just respect the rights on the name
> > without registration. The case with Chris is single and first as far as
I
> > know.
>
> And Chris wanted to add a directory where a library is kept into the
> filename. My euphoria\include directory is a mess right now, and that
> would fix it, by keeping one library in one directory, effectively
> organizing it.
No, it is not his problem.
He wanted c:\rds\file.e and c:\chris\file.e to
be included in his program twice as different libs.
But c:\rds\file.e is copirighted standard library,
and c:\chris\file.e is unknow for now some Chris's
or someone's else untested library.
Chris says c:\rds\file.e is "crappy" but do not
want to tell us why it is so bad.
The standard Euphoria includes only the first one
the file.e library from top to bottom of the program.
> > > >1. It produces unexpected, undocumented behaviour.
> >
> > The behaviour of Euphoria interpereter is strongly documented -
filename of
> > library. Full path and filename are different things.
>
> This is not. What would you expect, if you included two files with the
> same filename, but in different directories? Would 'you' expect that
> only one of them is loaded? No?
Yes I do, it is 11 years old well tested, well documented
behaviour of interpreter, translator, binder
> > > >2. It is illogical. There is no supporting argument for keeping it
as-is
> >
>
> It truly is.
There are many different logics in the World.
I prefer to not confuse two different file.e
in any case, and absolutely do not want
confuse copirighted well tested standard
file.e with something else.
> > > >3. It makes using third-party libraries more difficult.
> >
> > No, there is no such the third-party libraries at all.
> > You have nothing to use this way.
>
> Let me give you an example. Win32lib is a third-party library.
> Every library that's not made by RDS are third-party libraries.
No, they are talking about libraries with strongly
identical filename.
There are no such the libraries - with identical filename.
Only RDS file.e - old well tested, and some Chris' new
file.e for which he wants some new Rob's interpreter,
translator and so on.
> > No one is going to create the libraries with the identical names now.
> > Clever boys do not want, the very-very clever boy wants, but can not.
> > I do not think Rob wants to implement this strange useless feature
> > in the standard EU.
> >
>
> 1100 contributions damnit!
See above, please.
> > > Would correcting the behaviour break libraries? NO!
> >
> > Useless and bad feature.
>
> Useful and good.
Think, please once more.
> > Irv did not find the libs with the identical names in other
> > languages for now.
> > Let us see the reason if he finds one.
>
> The reason isn't that there are libraries with identical names,
> but there could be. Only wait a few years. Maybe there are 10000 user
> contributions?
Think, please, once more.
> > And his "perfect solution" is like to prison or such.
> >
> > > Would it produce undocumented behaviour? NO!
> >
> > The Euphoria documentation is clear, interpreter has no this bug,
> > there is no this problem.
>
> This is a bug. The euphoria documentation states that a file with the
> specified filename is included, and a filename *can* have a path,
> and therefore, this is a bug, and it should never have been :P
No, it is not a bug, be sure
> > > And Rob, you have this annoying habit of being a wallflower whenever
a
> > > discussion comes up about the language itself. I know you are proud
of
> > > Euphoria, and you have every right to be, but don't pretend that it's
> > > perfect, and that every action you have ever made regarding the
> > > language is correct. Please weigh in on this issue. Do *you* have any
> > > opinion regarding why it shouldn't be changed?
> >
> > Let us respect the Rob's intellectual rights on his Euphoria.
> > He is the author of that excellent language.
> > Life is life, no?
>
> But what if he doesn't do the the best for the language?
Who, Rob? Think please once more.
> Enough of this dumbness and tunnel-seeing. The only reason I replied to
> this post was that I got pissed off.
Me too. Let us say thanks to Chris
No problem, Chris!
Be very-very-very clever boy!
Good Luck AnyWay!
> Regards, Alexander Toresson
>
> Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
Best regards, Alexander Toresson!
Igor Kachan
kinz at peterlink.ru
49. Re: include statement bugs
Chris Bensler wrote:
Igor Kachan wrote:
<SNIP>
[OT snipped]
> > No, I do not. It seems, Chris are saying about stupidity.
> > So, he is the most educated and very-very clever here.
> > Isn't he? I do not think so, - that he is not.
>
> There are many people much more intelligent than me, and I give them the
> respect they deserve. However, people like Robert Craig deserve a swift
> kick in the head. Maybe it would shake loose that tidbit of wisdom he
> used to have.
All people have strongly identical rights on respectation.
Is it a big news for you?
[old stuff snipped]
> I'm sorry I mentioned my std library project, it was an EXAMPLE! God
> dammit! I could care less if it's vaporware, and even a bad idea.
> It was an EXAMPLE!
I do not see a problem here.
> > Ok, it is great, I like competition, but he doesn't
> > say about competition.
> > He just wanted replace the standard copyrighted PD stuff
> > with some unknown stuff without any explanation,
> > what is so bad in the old well tested libraries.
> >
> > Reread, please, this thread to be sure about his problem.
>
> I never said any such thing, that I intend to 'replace' the RDS libs.
> I have the authority to do that.!?
> I said I am producing an alternative. There is a big difference there. I
> said I would like it if people were able to use both at once if they
> wanted. But I don't really care if they are compatible.
>
>
> <SNIP>
>
>
> > More than 1300 at all, but the specialized section
> > is not that big. And it is the very interesting.
> > If someone wants to be a writer of Euphoria
> > libraries - that section is the exclusively interesting
> > and rich on ideas.
>
> 1300? Other langauges have 130,000 or even 1,300,000.
> PHP is half the age of Euphoria, and has at least 100x more source code
> available for it.
Use PHP please, what a problem?
Do you program an application for Euphoria, or Euphoria itself?
If you want program Euphoria itself, pay for source code and
program all you want accordingly to licence.
2.5 will have 100% Euphoria front-end blok just for such
unusual ideas like extremely rare using of different
libraries with duplicated names.
[old stuff snipped]
> Thankyou Alexander. You hit the nail on the head. It's not even about
> the names of the files themselves. But about our ability to organize our
> Euphoria source code more adequately.
> The fact that we can't use duplicate names, and the fact that Euphoria
> doesn't recognize paths, are the consequential flaws that bring the
> issue to the table.
>
>
> > No, it is not his problem.
>
>
> YES, that IS my problem.
> How many times do I have to say it Igor. My std libraries are an
> EXAMPLE!
See, please, the subject of this thread once more.
Chris, Euphoria does recognize paths very well and does the things
as it is documented.
>From any valid path it only uses the most important, almost
always copyrighted part - own name of the included library.
And doesn't include the second library with same name.
What about apologies for RDS and Robert H. Craig personally?
> > But c:\rds\file.e is copirighted standard library,
>
>
> No it isn't. file.e is absolutely public domain. Do as you please.
> You don't even have to give RDS any credit for using it, even if you
> modify it.
It is copyrighted as Public Domain by RDS.
RDS allows to give credit or not, it is RDS' right.
But I do not think someone does like insultings
for his Public Domain + excellent production.
You must go away with thanks or silently, if you do not
like free fish & chips.
Is it a big news for you?
What about apologies for RDS and Robert H. Craig personally?
> > and c:\chris\file.e is unknow for now some Chris's
> > or someone's else untested library.
> >
> > Chris says c:\rds\file.e is "crappy" but do not
> > want to tell us why it is so bad.
>
> Why should I waste my effort flogging a dead horse? It's quite obvious
> that you aren't willing to change. Many people here are perfectly happy
> with Euphoria how it is, and that is fine. But I for one, am NOT.
> Anyone who is interested in Empire (or not) is welcome to post their
> opinions on the Empire website. This isn't the place for it.
Ok, thanks for invitation, but I am afraid I have no enough free time
to visit the Empire, and, I am sorry, I am not familiar with emperor.
> > Yes I do, it is 11 years old well tested, well documented
> > behaviour of interpreter, translator, binder
>
>
> If its so well tested, and stable, why are there problem with it?
> Why does 90% of the Euphoria commmunity agree that Euphoira should
> recognize paths?
Again.
See, please, the subject of this thread once more.
Chris, Euphoria does recognize paths very well and does
the things as it is documented.
>From any valid path it only uses the most important, almost
always copyrighted part - own name of the included library.
And doesn't include the second library with same name.
What about apologies for RDS and Robert H. Craig personally?
> > There are many different logics in the World.
> > I prefer to not confuse two different file.e
> > in any case, and absolutely do not want
> > confuse copirighted well tested standard
> > file.e with something else.
>
> I don't see how you can confuse
> chris\file.e
> with
> igor\file.e
I have no chris\file.e nor igor\file.e, I have c:\euphoria\include\file.e,
and me very well knows, that file.e is copyrighted by RDS as PD and very
useful Euphoria library. Period, as you say.
I have nothing to confuse, and never will this way.
> Do you confuse your C:\ with your D:\ ? I hardly think so.
I am afraid, that someone wants confuse my C:\ with his C:\,
my D:\ with his D:\ and so on.
> > No, they are talking about libraries with strongly
> > identical filename.
> >
> > There are no such the libraries - with identical filename.
> > Only RDS file.e - old well tested, and some Chris' new
> > file.e for which he wants some new Rob's interpreter,
> > translator and so on.
>
> rds has a library names file.e
> I have a library named file.e
> unkmar has a library named file.e
> jason has a library named file.e
> sounds like kat has her own too..
> anybody else?
>
> They are ALL DIFFERENT.
> Those a REAL examples Igor.
Example of a poor programming, if it is true. I am sorry.
> > > > Irv did not find the libs with the identical names in other
> > > > languages for now.
> > > > Let us see the reason if he finds one.
>
> Show me when he said that.
> I'd like to see a quote. I've been following this thread, and I don't
> recall him mentioning anything of the sort.
See, please, the quote.
----------
Irv Mullins wrote:
----------
IK > > > > Do you know any other programming language with the duplicate
IK > > > > libraries names?
> > >
DP > > > Yes
> >
IK > > What it is, if it is not a top secret?
>
IM > C, C++, D, E, Eiffel ... this bores me.
IK Ok, sorry, but what the libraries names?
IK Be so kind, please, I'd like to see these libs,
IK just interested to understand the real reason of
IK doubling of those names.
----------
Without answer for now.
You must prove that your idea is really good.
I think, he is searching and looking for these libs.
I am sure, he will immediatelly tell us about found examples,
if he is interested in this issue, naturally.
> > > The reason isn't that there are libraries with identical names,
> > > but there could be. Only wait a few years. Maybe there are 10000 user
> > > contributions?
> >
> > Think, please, once more.
>
> Think about what? Think about the fact that there has been an average of
> less than 150 contributions to the Euphoria archives per year, in it's
> 10 year existence? That is pathetic.
Let us wait for Irv's results, if he wants to continue this mistaken
thread.
I'd prefer to not confuse the issues about Euphoria real quality
and your dreams and plans about Empire. I have no any interest to any
Empire.
Sorry, Chris, I have no interest. This is fully different issue.
> You are right in a sense though Igor. As long as RDS is in control,
> Euphoria will never have a serious problem with file name clashing.
> For the effort required to fix the problem, we are probably all better
> off to just rename our files. I highly doubt that the RDS Archives will
> ever accumulate enough source code to be able to have a real problem
> with it.
Let us wait for 2.5 first of all and test it.
Then I want to contribute some my updated projects.
> > > > And his "perfect solution" is like to prison or such.
>
> He was being sarcastic. Pointing out how rediculous you are making
> yourself look.
Welcome! But remember please about that my associative idea.
> > > > Let us respect the Rob's intellectual rights on his Euphoria.
> > > > He is the author of that excellent language.
> > > > Life is life, no?
>
> He gave up his rights when he made me pay for Euphoria.
Hey, Chris, do not get crazy! Stop, please!
*The standard PD Euphoria is free and Public Domain,
as it is stated by RDS. You do not need pay at all for it.
And you must respect the intellectual rights of RDS.
See please quote from readme.doc v2.4*
Notice to Shareware Vendors:
============================
We encourage you to distribute this Public Domain Edition of
Euphoria.
You can charge whatever you like for it. People can use Euphoria
for as
long as they like without obligation. We make money from
those who
start to seriously develop large applications, and want technical
support plus enhanced bind, profile, and trace support for large
programs.
DISCLAIMER:
===========
The Public Domain and Complete Editions of Euphoria are provided
"as
is" without warranty of any kind. In no event shall Rapid
Deployment
Software be held liable for any damages arising from the use
of or
inability to use this product.
> Euphoria is not HIS. It's his consumers. WE are the ones PAYING HIM to
> make the thing.
Hey, Chris, stop, please!
If you do want some *custom* Euphoria, ask Rob, pay him for the individual
*custom* Euphoria (Rob named once $1000000 or so for goto feature)
and get it as you both will be agreed.
> If he wants to give it away for free. He would have alot less problems
> doing as he pleases.
>
> Now *I* have the right to bitch and complain as much as I want.
> I paid for that right. That is what support is about. And that is the
> product I paid for. I paid for support of the language. Whether that
> means I gave money to Rob so that he will continue work. Or whether that
> means I paid for Euphoria, so I could tell him what an idiot I think he
> is. I have paid for that right.
What, what, what ????????????
Please do not confuse and mix *consumers*, *customers*,
*intellectual rights*, *simple human politeness, civility and courtesy*
and *ochlos kratos* into one big heap of dirty rubbish.
Be careful, Chris, in your Empire too.
Too many people in the World do know their simple rights on just respect.
> If you don't like it, too bad.
>
> If RDS won't listen to his customers, he will find more people are
> paying to bitch, than to actually support his efforts.
Yes, you do confuse *consumers*, *customers* and *PD status*
of file.e standard RDS Euphoria library.
What about apologies for RDS and for Robert H. Craig personally?
> Chris Bensler
> Code is Alchemy
Regards,
Igor Kachan
kinz at peterlink.ru
50. Re: include statement bugs
Chris Bensler wrote:
[snip]
> > > No it isn't. file.e is absolutely public domain. Do as you please.
> > > You don't even have to give RDS any credit for using it, even if you
> > > modify it.
> >
> > It is copyrighted as Public Domain by RDS.
> >
> > RDS allows to give credit or not, it is RDS' right.
> >
> > But I do not think someone does like insultings
> > for his Public Domain + excellent production.
> >
> > You must go away with thanks or silently, if you do not
> > like free fish & chips.
> >
> > Is it a big news for you?
> >
> > What about apologies for RDS and Robert H. Craig personally?
> >
> > > > and c:\chris\file.e is unknow for now some Chris's
> > > > or someone's else untested library.
> > > >
> <snip>
>
> I'm just going to do like Derek says he does, and ignore you.
> This discussion is not goin anywhere.
> I don't feel I owe RDS an apology, until Robert Craig recognizes the
> needs of his Euphoria community. Not MY needs. Just because I may
> address an issue, does not make it MY issue.
>
> Enough said. End of discussion.
>
> Chris Bensler
> Code is Alchemy
It is good thing, to know who is who and what is what.
Useful thread.
Poor bug ... ;-(
Amen!
Regards,
Igor Kachan
kinz at peterlink.ru
