1. The Perfect Solution
I have the perfect solution to the 'include' problem, one which should
please Igor and satisfy everyone else.
Using this solution, anyone can write an include file and give it a
meaninful name, yet never conflict with any other file from anyone else.
RDS will 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.
I realize this plan will limit the total number of contributors to 999,
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
2. Re: The Perfect Solution
irv mullins wrote:
> I have the perfect solution to the 'include' problem, one which should
> please Igor and satisfy everyone else.
>
> Using this solution, anyone can write an include file and give it a
> meaninful name, yet never conflict with any other file from anyone else.
>
> RDS will 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.
>
> I realize this plan will limit the total number of contributors to 999,
> 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.
I really hope you're kidding.
--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
Euphoria Message Board: http://uboard.proboards32.com
Empire for Euphoria: http://empire.iwireweb.com
3. Re: The Perfect Solution
Again, let's just stick a bandaid on the problem and continue re-writing
all our own libraries. Then, after a couple years of "everyone writing
the same code with similar names that is in NO WAY compatable with anyone
else's libraries", we can all start pestering Rob again to fix our file
name problems.
This is exactly the reason I haven't even attempted to code anything new
lately. Why should I waste my time writing a library to use in one of my
programs, just to find out someone else already wrote a similar library?
Then I either have to try and convince them to use mine, or debug what
I've written to run with theirs.
I've all but abandoned hope for any of my code because of these very
issues. I do this as a hobby, and I, for one, am not going to waste my
time recoding all of it again for each person who wants to use it. If
this community can manage to come to grips with the real problems that we
face, and in some small way attempt to overcome them, I would be happy to
contribute again.
If all of you could simply step out of your little boxes for just a
minute, and realize that everyone is basically writing the same code over
and over and over again (that's why it clashes so much), you might see
that the problem isn't with the slashes, and it isn't with the file names,
and it's not even with the routines. The real problem is the lack of
interest in trying to WORK TOGETHER to set up a new "standard set" of
include files for the community in general.
In all the time that will be wasted arguing about how to "fix" the
problems with the paths, we could have written a set of includes to
replace the ones that Rob distributes. Oh ... but I forgot ... we can't
break all that existing code ...
Jason
4. Re: The Perfect Solution
Jason Mirwald wrote:
>
> Again, let's just stick a bandaid on the problem and continue re-writing
> all our own libraries. Then, after a couple years of "everyone writing
> the same code with similar names that is in NO WAY compatable with anyone
> else's libraries", we can all start pestering Rob again to fix our file
> name problems.
>
> This is exactly the reason I haven't even attempted to code anything new
> lately. Why should I waste my time writing a library to use in one of my
> programs, just to find out someone else already wrote a similar library?
> Then I either have to try and convince them to use mine, or debug what
> I've written to run with theirs.
WTF? Why do you need to convince anyone of anything? Maybe it was your
fault for not looking for that other library. Maybe that other library
wouldn't have been suitable for your purposes anyway. If one is truly
superior, chances are that most people will use that one (assuming it
meets their needs). Does that mean that we should all delete the other
one from our hard drives?
> I've all but abandoned hope for any of my code because of these very
> issues. I do this as a hobby, and I, for one, am not going to waste my
> time recoding all of it again for each person who wants to use it. If
> this community can manage to come to grips with the real problems that we
> face, and in some small way attempt to overcome them, I would be happy to
> contribute again.
Oooh, the real problems. I guess we're just bumping around in the dark
here. Thank goodness you came back to show us the light. Most people
around here put a lot of 'hobby' time in on Euphoria, and probably don't
consider it wasted time.
> If all of you could simply step out of your little boxes for just a
> minute, and realize that everyone is basically writing the same code over
> and over and over again (that's why it clashes so much), you might see
> that the problem isn't with the slashes, and it isn't with the file names,
> and it's not even with the routines. The real problem is the lack of
> interest in trying to WORK TOGETHER to set up a new "standard set" of
> include files for the community in general.
>
> In all the time that will be wasted arguing about how to "fix" the
> problems with the paths, we could have written a set of includes to
> replace the ones that Rob distributes. Oh ... but I forgot ... we can't
> break all that existing code ...
What's wrong with the includes that come with Euphoria? If this is such
a great problem, why have I noticed only 2 people mention this (you and
Mr Bensler)? Why should we change *our* hobbies (or work--I often use
Eu at work) to please you?
Why should anyone turn over their efforts to RDS? The really popular
libraries are mostly constantly evolving. Euphoria only changes very
slowly, and releases are usually at least a year apart. Everyone has
a different idea about what's absolutely necessary, what's nice to have,
and what's disk clutter.
Matt Lewis
5. Re: The Perfect Solution
On 19 Oct 2004, at 6:47, Tommy Carlier wrote:
>
>
> posted by: Tommy Carlier <tommy.carlier at telenet.be>
>
> irv mullins wrote:
> > I have the perfect solution to the 'include' problem, one which should
> > please Igor and satisfy everyone else.
> >
> > Using this solution, anyone can write an include file and give it a
> > meaninful name, yet never conflict with any other file from anyone else.
> >
> > RDS will 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.
> >
> > I realize this plan will limit the total number of contributors to 999,
> > 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.
>
> I really hope you're kidding.
Maybe he was doing advertising for Bach or Open-Eu ?
Kat
6. Re: The Perfect Solution
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Oct 19, 2004
-
Last edited Oct 20, 2004
On Tue, 19 Oct 2004 21:00:29 +0000, Chris Bensler <bensler at nt.net>
wrote:
>A sourceforge project was even started before. They probably gave up
>because they could see that nobody would accept the changes they wanted
>to make.
LOL, See
http://palacebuilders.pwp.blueyonder.co.uk/posdiff.htm
So many people will run away screaming, but I reckon good riddance 
Pete
7. Re: The Perfect Solution
On Wed, 20 Oct 2004 04:00:55 -0700, Matt Lewis <guest at rapideuphoria.com>
wrote:
>
> posted by: Matt Lewis <matthewwalkerlewis at yahoo.com>
>
> Chris Bensler wrote:
> >
> >
> > Matt Lewis wrote:
<snip>
>
> What are these 'strongly opposed' attempts at breaking RDS's monopoly.
Can someone tell me why there are so many 'strongly opposed' attempts
at breaking RDS's monopoly. After all RDS did make euphoria, to start
with and has gathered the croud thats here, listened(maybe no
implemented) to suggestions. I'm personally very satisfied, and all
the changes I've seen so far are probably place for pre-processors and
DIY libraries. But the changes that can only be made to the
interpreter, well they should be made to the interpreter, all of them.
But certainly not the public or registered version, everyone that has
been voicing there opions about changes SHOULD licence the source, and
make them, themselves. If the changes make a huge impression then they
will probably be added.
-Its late and I'm voicing my opinions, but hey I got the source and
make the changes I like to it myself.
Daniel
> There have been a few message board attempts, and there are several
> people working on an open source implementation of Euphoria.
>
> The message boards go away because they're not as useful as this forum.
> Some people like to get their messages by email. There is a much wider
> user base for this forum than the others (a chicken and the egg scenario).
> It's easier to check one source than many. That doesn't stop people from
> using them, but it also doesn't mean that they're strongly opposed. Yes,
> it does help that this is the Official forum, but it's not like Rob
> censors people (at least not on-topic messages).
>
> Frankly, I'm for more choices. I don't understand why you think
> otherwise.
>
> Matt Lewis
>
>
>
>
>
8. Re: The Perfect Solution
I would not say that I, personally, am trying to break anything Rob has
done. I was simply voicing my opinion on the subject of compatability.
I have tried, to no avail, to write my programs to be as flexible as
possible in the past, but regardless of how much work on my projects,
they always seem to be broken by incompatabilities that occur with
files/routines outside the distributed includes.
The fact that the subject even comes up on this list suggests that I'm
not the only one that has the same problems to one degree or another, and
I just don't understand why all these problems can't be overcome simply
by the creation (and acceptance of) a better set of include files.
This goes beyond a preprocessor to sort out which files and routines to
use. There is alot of good code out there, but why should I need to
include 5 different libraries for structure access to write one windows
program, that includes files from 5 diffferent users, then to have to
fight all the conflicts. (that was just an example)
I have lots of code I would love to share, but every time I think I may
submit it, I remember that I also have to submit all my supporting code,
which will surely comflict with SOMETHING that someone else wrote. Or
that I'll have to support the unknown code, cause nobody else uses it...
It's just very frustrating to fight a problem that could be overcome by
the simple use of a new, standard, set of includes.
Jason
9. Re: The Perfect Solution
codepilot Gmail Account wrote:
> On Wed, 20 Oct 2004 04:00:55 -0700, Matt Lewis <guest at rapideuphoria.com>
> wrote:
>>
>> Chris Bensler wrote:
>>>
>>>
>>> Matt Lewis wrote:
> <snip>
>>
>> What are these 'strongly opposed' attempts at breaking RDS's monopoly.
^^^^
> Can someone tell me why there are so many 'strongly opposed' attempts
> at breaking RDS's monopoly.
This question doesn't make much sense, until the question above (^^^^)
isn't answered.
> After all RDS did make euphoria, to start
> with and has gathered the croud thats here, listened(maybe no
> implemented) to suggestions. I'm personally very satisfied, and all
> the changes I've seen so far are probably place for pre-processors and
> DIY libraries. But the changes that can only be made to the
> interpreter, well they should be made to the interpreter, all of them.
> But certainly not the public or registered version, everyone that has
> been voicing there opions about changes SHOULD licence the source, and
> make them, themselves.
Sorry, but this is plain nonsense. I don't know C, so I cannot make
changes to the Euphoria code. And I don't want to learn C, that's why I
use Euphoria.
> If the changes make a huge impression then they will probably be added.
Ahhh ... Please tell me, where you got this fine cristal ball which
allows this good prediction. True is, that several very simple but
useful improvements were NOT added in the past.
> -Its late and I'm voicing my opinions, but hey I got the source and
> make the changes I like to it myself.
Yes, that's why we also e.g. need no butchers. When we want some meat,
we just go and shoot a bull ourselves ...
Regards,
Juergen
--
/"\ ASCII ribbon campain | Math problems?
\ / against HTML in | Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
10. Re: The Perfect Solution
Jason Mirwald wrote:
>
> I would not say that I, personally, am trying to break anything Rob has
> done. I was simply voicing my opinion on the subject of compatability.
> I have tried, to no avail, to write my programs to be as flexible as
> possible in the past, but regardless of how much work on my projects,
> they always seem to be broken by incompatabilities that occur with
> files/routines outside the distributed includes.
>
> The fact that the subject even comes up on this list suggests that I'm
> not the only one that has the same problems to one degree or another, and
> I just don't understand why all these problems can't be overcome simply
> by the creation (and acceptance of) a better set of include files.
Because there's no such thing. Any set of files will have problems.
Either they'll be feature poor, or too bloated (depending on who you
ask). What happens when someone wants to do something differently?
The same situation occurs.
I'm not saying that there aren't things that can be done. We've gone
around a lot about some fairly simple namespacing issues that would
help a lot of cases (I even put that into the 2.4 source code). But
'a better set of include files' is not the panacea that you claim.
> This goes beyond a preprocessor to sort out which files and routines to
> use. There is alot of good code out there, but why should I need to
> include 5 different libraries for structure access to write one windows
> program, that includes files from 5 diffferent users, then to have to
> fight all the conflicts. (that was just an example)
Libraries get written for a lot of different reasons, and at different
times. Different resources (i.e., structure libraries) are available
at different times. Some people prefer one to another, and often,
the implementations use paradigms that force them to work in incompatible
ways. It could be a personal preference on how to do things, or it
could be a performace vs ease of use issue. Again, there's no
[reasonable] way to solve this.
Using a common open source mantra, you could always change those libs to
work with others (or require that your users do the same), supporting
libs that you prefer, and then release it. The alternative is to
coerce others to use one set of tools, which isn't going to happen.
This is a software issue, not a Euphoria issue.
> I have lots of code I would love to share, but every time I think I may
> submit it, I remember that I also have to submit all my supporting code,
> which will surely comflict with SOMETHING that someone else wrote. Or
> that I'll have to support the unknown code, cause nobody else uses it...
>
> It's just very frustrating to fight a problem that could be overcome by
> the simple use of a new, standard, set of includes.
>
I understand your frustration, but if there's a solution, it hasn't been
found yet.
Matt Lewis
11. Re: The Perfect Solution
Jason Mirwald wrote:
[snip]
> I have lots of code I would love to share, but every time I think I may
> submit it, I remember that I also have to submit all my supporting code,
> which will surely comflict with SOMETHING that someone else wrote. Or
> that I'll have to support the unknown code, cause nobody else uses it...
>
> It's just very frustrating to fight a problem that could be overcome by
> the simple use of a new, standard, set of includes.
Try please:
--file.e file
? 1
--end of file.e file
--my_foo.ex--
include file.e
--end of my_foo.e file
Create new dir
my_dir_foo
Place
file.e that is just above
into my_dir_foo
Place
my_foo.ex that is just above
into my_dir_foo
Just run my_foo.ex without any conflict
with the standard c:\euphoria\include\file.e
Euphoria looks for supporting stuff
*in the current dir first of all*,
includes yours file.e and runs yours
proggy with *yours file.e*, ignoring standard one.
If it is your problem, submit please your
programs and say in readme file to run
them in separate dedicated dir only.
Good Luck!
Regards,
Igor Kachan
kinz at peterlink.ru
12. Re: The Perfect Solution
- Posted by "Unkmar" <L3Euphoria at bellsouth.net>
Oct 22, 2004
-
Last edited Oct 23, 2004
idiot
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: <EUforum at topica.com>
Sent: Friday, October 22, 2004 3:37 PM
Subject: Re: The Perfect Solution
>
>
> Jason Mirwald wrote:
>
> [snip]
>
>> I have lots of code I would love to share, but every time I think I may
>> submit it, I remember that I also have to submit all my supporting code,
>> which will surely comflict with SOMETHING that someone else wrote. Or
>> that I'll have to support the unknown code, cause nobody else uses it...
>>
>> It's just very frustrating to fight a problem that could be overcome by
>> the simple use of a new, standard, set of includes.
>
> Try please:
>
> --file.e file
> ? 1
> --end of file.e file
>
> --my_foo.ex--
> include file.e
> --end of my_foo.e file
>
> Create new dir
>
> my_dir_foo
>
> Place
>
> file.e that is just above
> into my_dir_foo
>
> Place
>
> my_foo.ex that is just above
> into my_dir_foo
>
> Just run my_foo.ex without any conflict
> with the standard c:\euphoria\include\file.e
>
> Euphoria looks for supporting stuff
> *in the current dir first of all*,
> includes yours file.e and runs yours
> proggy with *yours file.e*, ignoring standard one.
>
> If it is your problem, submit please your
> programs and say in readme file to run
> them in separate dedicated dir only.
>
> Good Luck!
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
>
>
>
>
