1. The Perfect Solution
- Posted by irv mullins <irvm at ellijay.com> Oct 19, 2004
- 548 views
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
- Posted by Tommy Carlier <tommy.carlier at telenet.be> Oct 19, 2004
- 554 views
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
- Posted by Jason Mirwald <jmirwald at ameritech.net> Oct 19, 2004
- 531 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Oct 19, 2004
- 543 views
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
- Posted by "Kat" <gertie at visionsix.com> Oct 19, 2004
- 535 views
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
- 512 views
- 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
- Posted by codepilot Gmail Account <codepilot at gmail.com> Oct 22, 2004
- 532 views
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
- Posted by Jason Mirwald <jmirwald at ameritech.net> Oct 22, 2004
- 523 views
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
- Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 22, 2004
- 520 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Oct 22, 2004
- 501 views
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
- Posted by "Igor Kachan" <kinz at peterlink.ru> Oct 22, 2004
- 538 views
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
- 532 views
- 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 > > > >