1. Standardized Euphoria
I'm working on designing new standard libraries for Euphoria to replace the RDS
libs that are shipped with the distro.
I have a few questions.
1. Besides additional functionality, I would prefer to redesign/reorganize the
existing libs. Would this be acceptable to people?
The new libs would not be compatible with the RDS libs but they would include
the same functionality, plus much more. The alternative is to just build upon the
existing libs, though I strongly beleive that we would be better off if they were
reorganized. Now that Eu supports include subfolders, I do have a way for
'legacy' code that uses rds libs to be compatible with the new libs, since that
would of course be a concern. This plan has actually been on the backburner for
many years because Euphoria didn't support include subfolders until v3.
2. Many things that would be added to the standardized libraries would collide
with existing projects that define the same things in it's own code.
This problem is unavoidable if I wish to expand on the RDS libraries, but I'm
sure it would deter many people from migrating. Any opinions on this?
3. My plan is to make a system of libraries that are successively more complex
and abstract using layers.
For example, there would be a core set (call it tier 0) of libraries that
provide rudimentary functionality. The actual libs that most people would use
would be tier 1 or tier 2 functionality.
The main purpose of the layers would be modularization. The core set could be
replaced with different functionality, such as a debug set or advanced error
handling for example. For the most part, the layers would be transparent to the
programmer, but you would have the ability to get under the hood make changes
that would affect the whole API. Currently if you want to change some basic
functionality such as how errors are handled, you would have to modify very file
that has an error condition, since there is no amalgomated method of error
handling in the RDS libs.
I've probed people on this issue in the past and the caveat here is that
the libraries would be codependent, whereas the rds libs are for the most part
independent. This is a concern for some people, because they don't want to have
to ship a whole bunch of files just for the sake of needing one.
Again, opinions?
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
2. Re: Standardized Euphoria
Chris Bensler wrote:
> 1. Besides additional functionality, I would prefer to redesign/reorganize the
> existing libs. Would this be acceptable to people?
What is it about the existing libraries (both RDS and community) that you find
inadequate structure-wise? If you're thinking about the OOP way of including
libraries (include System.IO.Net), I would say limit your innovation to OOP
variants of Euphoria. Personally, I don't see the system as broken. If I want
to use RDS's get.e, I just include it. If I want to use my own personal
modded version, it's no more work than copying or renaming a file or two.
Don't get me wrong - I'm not against anybody trying to improve the tools. I
just don't see any benefit for the general applications I write. Perhaps a
more detailed explanation of the gap would help me understand your point of
view a bit better.
Mike Sabal
3. Re: Standardized Euphoria
Michael J. Sabal wrote:
>
> Chris Bensler wrote:
>
> > 1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> What is it about the existing libraries (both RDS and community) that you find
> inadequate structure-wise? If you're thinking about the OOP way of including
> libraries (include System.IO.Net), I would say limit your innovation to OOP
> variants of Euphoria. Personally, I don't see the system as broken. If I
> want
> to use RDS's get.e, I just include it. If I want to use my own personal
> modded version, it's no more work than copying or renaming a file or two.
No, I'm not talking about OOP. It's unfortunate that so many people
automatically associate 'modularity' with OOP, they aren't related.
Every programmer should practice modular programming, regardless of what
language or paradigm you use.
get.e is an excellent example of why the libs should be reorganized. Have you
studied the code it contains? It's extremely useful!, but it's localized. A
proper library for dealing with streaming text would be much more beneficial to
everyone.
database.e is another good example. It contains localized code to deal with
serializing eu data objects.
Misc.e and machine.e should both be split up into about 5 or 6 files in my
opinion.
Yes it works now, but it could be much better.
The key concept of modularity is that you don't want to duplicate code.
Duplicating code means duplicating problems.
> Don't get me wrong - I'm not against anybody trying to improve the tools. I
> just don't see any benefit for the general applications I write. Perhaps a
> more detailed explanation of the gap would help me understand your point of
> view a bit better.
>
> Mike Sabal
The main issue is organization.
When new functionality is added, it would be prudent to split up misc.e and
machine.e to correspond with more meaningful categorizations. EG a math library,
or a sequence library, or a string library, or a mem i/o library to compliment
machine.e
If machine.e contains poke_float() etc, and I would like to add all the missing
peek/poke routines, plus a bunch of other closely related functions for bit and
byte manipulations, should I just stuff them all into machine.e as well? Would it
make sense to have some functions in one library, and the rest in another file,
in an API that is supposed to be a standard?
Another issue is convenience and pollution.
I would like to move all the RDS libs into a subfolder of the include path.
This would make it so a person could just copy the whole subfolder into their
project and that's it, they dont' even have to think about what files are
included. It's an API, it should be treated as an API, not just a collection of
unrelated library files. Granted, you normally wouldn't be distributing the
standard includes, but they should set an example for how other API's should be
structured.
If it's agreed that API's should be stored in subfolders instead of directly in
the include path, then it would be desirable to have the RDS libs behave the
same. If we move the RDS libs, compatability will be broken anyways, so taking
advantage of that fact to reorganize the libs make sense.
By pollution, I mean having to place a bunch of library files directly into your
project folder, the alternative is to manually move them to a subfolder and
change any include references to the files. It would also be good practice to
keep the main include folders free from files whenever possible, to avoid clutter
and confusion.
Yes, I can just build upon the RDS libs as I said, but backwards compatibility
should only be a concern, not a mandate. Backwards compatability can be supported
with abstraction and deprecation, we don't have to stop moving forward at it's
expense.
I'm thinking of the future, trying to plan things for much larger scales.
Weighing the fact that a relative handful of people are already accustomed to
the existing libs is really a moot point considering the size of the community
and the archives. I could rewrite all the code in the archives myself to make it
compatible if nessecary (not that I want to, or think it's a good idea). It's not
like there is a very large selection of Euphoria resource sites available that
would make a mass port impossible.
I wish it were a problem and it should be.
Think about why not many people are using Euphoria. To think that it isn't
popular simply because it's not well known is lying to ourselves.
Why are other languages, which are seemingly inferior much more popular?
This is where my thoughts and efforts towards Euphoria lay.
I'm not saying that I think that it's because the RDS libs are bad, but
improving them would be a step in the right direction.
In a nutshell, I beleive Euphoria fundamentally has a problem with scalability.
It's slowly being addressed in the language itself, but besides that we also need
a much more expansive set of standard libraries for Eu. They don't have to all be
part of the distribution, but they should be geared to compliment eachother.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
4. Re: Standardized Euphoria
Chris Bensler wrote:
>
> Every programmer should practice modular programming, regardless of what
> language
> or paradigm you use.
I agree totally and attempt to do this with all my code. I like to make my
code so modular that the interface itself can be changed if needed (say, to
make a Linux or Windows or DOS interface, or Win32Lib or wxEuphoria interface)
and still work without changing anything else.
> The key concept of modularity is that you don't want to duplicate code.
> Duplicating code means duplicating problems.
I'm with you on all this, so get busy. :)
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
5. Re: Standardized Euphoria
Chris Bensler wrote:
> I'm working on designing new standard libraries for Euphoria to replace the
> RDS libs that are shipped with the distro.
>
> I have a few questions.
>
> 1. Besides additional functionality, I would prefer to redesign/reorganize the
> existing libs. Would this be acceptable to people?
Now that Euphoria is open source and free, I think it will be
much easier to add to the existing standard libraries. In the past
I was reluctant to start adding all sorts of user contributed
files to the official download package. The reasons are fairly
obvious:
* I was the only one making money from the package,
so it seemed unfair to mix in the work of others.
* Someone might try to sue me over a copyright
misunderstanding.
* I might get stuck maintaining other peoples code
after they leave.
I think the idea of adding to euphoria\include is good,
and creating subdirectories makes sense, especially if
there are eventually going to be lots of include files.
I don't think you should change the existing standard .e
files in a way that will cause existing programs to break.
You can add lots of new files, some in the main euphoria\include
directory and collections of related files in subdirectories.
I know that a language designer frequently wishes he could
start over and do things perfectly in the name of beauty
and elegance, but the users will not appreciate your sense
of beauty when they try to upgrade and discover that
lots of existing programs are now bombing out. It's just not
worth the hassle.
One source of new include files could be things that
are already being used by many people. Perhaps cleaned up
a bit.
People like to have standard libraries because they
know that other people are using those libraries
and the code is probably well supported and debugged.
It's of course necessary, but a bit risky,
to invent new libraries. Perhaps few people will use them,
but the few that do will demand that they be well maintained
and documented ... forever.
Good luck in exploring this area.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Standardized Euphoria
Robert Craig wrote:
>
> Chris Bensler wrote:
> > I'm working on designing new standard libraries for Euphoria to replace the
> > RDS libs that are shipped with the distro.
> >
> > I have a few questions.
> >
> > 1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> Now that Euphoria is open source and free, I think it will be
> much easier to add to the existing standard libraries. In the past
> I was reluctant to start adding all sorts of user contributed
> files to the official download package. The reasons are fairly
> obvious:
> * I was the only one making money from the package,
> so it seemed unfair to mix in the work of others.
>
> * Someone might try to sue me over a copyright
> misunderstanding.
>
> * I might get stuck maintaining other peoples code
> after they leave.
>
> I think the idea of adding to euphoria\include is good,
> and creating subdirectories makes sense, especially if
> there are eventually going to be lots of include files.
> I don't think you should change the existing standard .e
> files in a way that will cause existing programs to break.
I hope not. My preference is to progress not compatability, but I do have to be
realistic. The most sophisticated invention in the world is useless if nobody
will use it.
I have a way to avoid breaking compatability, although it would be desirable to
deprecate and eliminate the existing setup eventually.
I actually have a prototype laid out already. I've been reluctant to upload it
for evaluation because I'm not satisfied with the subfolder structure yet, but I
think I will anyways, so people can see where I'm at.
> You can add lots of new files, some in the main euphoria\include
> directory and collections of related files in subdirectories.
> I know that a language designer frequently wishes he could
> start over and do things perfectly in the name of beauty
> and elegance, but the users will not appreciate your sense
> of beauty when they try to upgrade and discover that
> lots of existing programs are now bombing out. It's just not
> worth the hassle.
Agreed, I'd like to make any required transition as seamless as possible.
Again, personally I'm not of a mind to adhere to backward compatability if
breaking it can be justified. Being that the community is still small at this
point, it would be wise to do it now before Eu does manage to get too big, rather
than suffer with comprimises.
I saw a good quote a while ago: (paraphrased)
"Progress is the person who advances on the road to success. Sometimes one finds
themself on the wrong road and then they must turn back to where they deviated
from the road to success. Thus the most progressive person is the one who turns
back first."
Being rational though, I know that I can't force everyone to see my perspective
or force them to use my work and I don't want it to be in vain.
In any case, I think it may have been a mistake to mention compatability in
regards to the file organization, since I don't think that will be a problem.
I mentioned about my 'batch include' concept in another thread. This concept
would be utilized to provide a compatability layer for the existing libs.
The real issue with compatability is when new functionality is added. Such as
the famous TRUE and FALSE constants. These types of things will inevitably create
conflicts with legacy code that can't be avoided.
> One source of new include files could be things that
> are already being used by many people. Perhaps cleaned up
> a bit.
Yes. When I have established a structure for the libs, I will be calling on the
community to nominate functions and files to be considered.
> People like to have standard libraries because they
> know that other people are using those libraries
> and the code is probably well supported and debugged.
Quite right. I've been using my Empire libs with Eu2.3 for several years now,
unfortunately all of my code is incompatible with everyone elses. It really
defeats the purpose of advancement if it isolates you from all available
resources.
> It's of course necessary, but a bit risky,
> to invent new libraries. Perhaps few people will use them,
> but the few that do will demand that they be well maintained
> and documented ... forever.
>
> Good luck in exploring this area.
Uh oh, the 'D' word! LA LA LA! I can't hear you! LA LA LA! :P
Writing documentation for me is like trying to explain what blue looks like to a
blind person :<
And I'm colorblind! :S
I can only hope that someone will be willing to chip in on that aspect or the
docs will undoubtedly be substandard.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
7. Re: Standardized Euphoria
Robert Craig wrote:
>
> I don't think you should change the existing standard .e
> files in a way that will cause existing programs to break.
True. Instead, release a "Standard Libraries Package v2.0."
All new programs can use this new library, and the old one can be
phased out or whatever.
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
8. Re: Standardized Euphoria
cklester wrote:
>
> Robert Craig wrote:
> >
> > I don't think you should change the existing standard .e
> > files in a way that will cause existing programs to break.
>
> True. Instead, release a "Standard Libraries Package v2.0."
>
> All new programs can use this new library, and the old one can be
> phased out or whatever.
I agree 100%.
Only after "most" people are using the new library should there be any thought
about breaking backward compatibility.
Ray Smith
http://RaymondSmith.com
9. Re: Standardized Euphoria
Ray Smith wrote:
>
> cklester wrote:
> >
> > Robert Craig wrote:
> > >
> > > I don't think you should change the existing standard .e
> > > files in a way that will cause existing programs to break.
> >
> > True. Instead, release a "Standard Libraries Package v2.0."
> >
> > All new programs can use this new library, and the old one can be
> > phased out or whatever.
>
>
> I agree 100%.
> Only after "most" people are using the new library should there be any thought
>
> about breaking backward compatibility.
>
> Ray Smith
> <a href="http://RaymondSmith.com">http://RaymondSmith.com</a>
"1. Besides additional functionality, I would prefer to redesign/reorganize the
existing libs. Would this be acceptable to people?
The new libs would not be compatible with the RDS libs but they would include
the same functionality, plus much more. The alternative is to just build upon
the existing libs, though I strongly beleive that we would be better off if
they were reorganized. Now that Eu supports include subfolders, I do have a
way for 'legacy' code that uses rds libs to be compatible with the new libs,
since that would of course be a concern. This plan has actually been on the
backburner for many years because Euphoria didn't support include subfolders
until v3."
I'm too tired to try and find a different way to explain the same thing.
Please read the thread again more thouroughly.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
10. Re: Standardized Euphoria
Chris Bensler wrote:
> "1. Besides additional functionality, I would prefer to redesign/reorganize
> the
> existing libs. Would this be acceptable to people?
Do you mean change the current include files so they aren't compatible with
the current version?
I'd say no to this.
Make your new libs based on the old ones (make copies and rename to something
else) go crazy, go nuts break all compatibility if you want. If they turn out
to be superior they will eventually replace the current versions. BUT don't
change the current libs without the alternative released, tested and
documented well before it becomes "official".
Regards,
Ray Smith
http://RaymondSmith.com
11. Re: Standardized Euphoria
>
> Subject: Re: Standardized Euphoria
>
>
> posted by: Ray Smith <ray at RaymondSmith.com>
>
> Chris Bensler wrote:
> > "1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> Do you mean change the current include files so they aren't compatible
> with
> the current version?
>
> I'd say no to this.
>
> Make your new libs based on the old ones (make copies and rename to
> something
> else) go crazy, go nuts break all compatibility if you want. If they
> turn out
> to be superior they will eventually replace the current versions. BUT
> don't
> change the current libs without the alternative released, tested and
> documented well before it becomes "official".
>
> Regards,
>
> Ray Smith
> http://RaymondSmith.com
>
Let's not get nuts about this compatibility breaking.
Does it make sense to have more useful features in a language, yet
abstain to change the form (arguments, return values...) of standard
library routines written 10 years before?
I'd say no to this.
Does it make sense to keep the organisation of routines or symbols
inside files the same when the scope covered by the libraries grows, the
technical environment changed so much (who still draws ellipses under
DOS, or in text mode for that matter?)?
I'd say no to this.
I'd say you are both right.
We are at a turning point in the history of Euphoria, and it is probably
the right time to make substantial changes and reorganisations, some of
which may break some backward compatibility. Otherwise, Eu will remain
compatible with 386 machines and will end in the dump as well.
However, this must done with great care:
* testing and documentation must be impeccable;
* mechanisms must be there to allow say 95% of legacy code to keep
running, perhaps less efficiently;
* As a community, we should collectively help in porting or rewriting
the tricky pieces of code which are in use and would be left on the
roadside even with the abovementioned mechanisms on.
As for examples of stuff which could help enhancing and reorganising the
current basic functionalities, you may glance at various files in
oedoc.free.fr/Fichiers/ESL/ Since the project seems to go nowhere, let
it be a part of the hopefully upcoming lift-up.
CChris
--
cchris005 at fastmail.fm
--
http://www.fastmail.fm - Accessible with your email software
or over the web
12. Re: Standardized Euphoria
Ray Smith wrote:
>
> Chris Bensler wrote:
> > "1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> Do you mean change the current include files so they aren't compatible with
>
> the current version?
>
> I'd say no to this.
>
> Make your new libs based on the old ones (make copies and rename to something
> else) go crazy, go nuts break all compatibility if you want. If they turn out
> to be superior they will eventually replace the current versions. BUT don't
> change the current libs without the alternative released, tested and
> documented well before it becomes "official".
I wish I could just take my own path and start right from scratch, but that's
not going to happen. I've tried already with my empire libs.
How do you propose to convince people to actually use a library that is entirely
incompatible with existing code for Euphoria and uses obfuscated names, just so
that it doesn't conflict with the RDS libs, eventhough they should never be used
in conjunction?
Yet again, my plans to reorganize the RDS libs _would not be incompatible_.
Yes they will break compatability, but I will be providing a way for them to be
compatible. What's the problem with that?
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
13. Re: Standardized Euphoria
cchris005 wrote:
>
> >
> > Subject: Re: Standardized Euphoria
> >
> >
> > posted by: Ray Smith <ray at RaymondSmith.com>
> >
> > Chris Bensler wrote:
> > > "1. Besides additional functionality, I would prefer to
> > > redesign/reorganize
> > > the
> > > existing libs. Would this be acceptable to people?
> >
> > Do you mean change the current include files so they aren't compatible
> > with
> > the current version?
> >
> > I'd say no to this.
> >
> > Make your new libs based on the old ones (make copies and rename to
> > something
> > else) go crazy, go nuts break all compatibility if you want. If they
> > turn out
> > to be superior they will eventually replace the current versions. BUT
> > don't
> > change the current libs without the alternative released, tested and
> > documented well before it becomes "official".
> >
> > Regards,
> >
> > Ray Smith
> > <a href="http://RaymondSmith.com">http://RaymondSmith.com</a>
> >
>
> Let's not get nuts about this compatibility breaking.
>
> Does it make sense to have more useful features in a language, yet
> abstain to change the form (arguments, return values...) of standard
> library routines written 10 years before?
>
> I'd say no to this.
>
> Does it make sense to keep the organisation of routines or symbols
> inside files the same when the scope covered by the libraries grows, the
> technical environment changed so much (who still draws ellipses under
> DOS, or in text mode for that matter?)?
>
> I'd say no to this.
>
> I'd say you are both right.
>
> We are at a turning point in the history of Euphoria, and it is probably
> the right time to make substantial changes and reorganisations, some of
> which may break some backward compatibility. Otherwise, Eu will remain
> compatible with 386 machines and will end in the dump as well.
>
> However, this must done with great care:
> * testing and documentation must be impeccable;
> * mechanisms must be there to allow say 95% of legacy code to keep
> running, perhaps less efficiently;
> * As a community, we should collectively help in porting or rewriting
> the tricky pieces of code which are in use and would be left on the
> roadside even with the abovementioned mechanisms on.
>
> As for examples of stuff which could help enhancing and reorganising the
> current basic functionalities, you may glance at various files in
> oedoc.free.fr/Fichiers/ESL/ Since the project seems to go nowhere, let
> it be a part of the hopefully upcoming lift-up.
>
> CChris
Thank you CChris, those are my sentiments exactly.
As I said in a previous post: "Backward compatability should be a concern, not a
mandate."
If we allow it to be a mandate, progress stagnates or at least must be
compromised.
There seems to be a major misconception that just because I said the libs would
break compatability that there won't be any way for them to be compatible. If I
thought I could get away with that, I would just write docs for Empire and save
myself a huge pile of extra work.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
14. Re: Standardized Euphoria
cchris005 wrote:
>
> As for examples of stuff which could help enhancing and reorganising the
> current basic functionalities, you may glance at various files in
> oedoc.free.fr/Fichiers/ESL/ Since the project seems to go nowhere, let
> it be a part of the hopefully upcoming lift-up.
I've already been examining those libs and extracting things for Empire for a
couple of years now ;) (since it has stagnated)
Interesting tidbit:
Did you know that I've been working on Empire since before even ESL was
conceived? :)
I don't recall exactly when I started on it anymore, but it's been close to 5
years or more. Since Eu v2.2, maybe even 2.1
I've refrained from releasing it because I've feared the code will get ripped
out and ported to work with the RDS libs, which would defeat half of the purpose
of redesigning the libs and discourage people from migrating.
In a way, the Empire libs were a failure because they were ahead of their time.
Only now, with Eu v3 supporting includes with the same name and include
subfolders can I really begin to do what I had intended originally.
Besides that, Empire attempted to make some changes that were a bit too drastic
to be generally acceptable.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
15. Re: Standardized Euphoria
- Posted by Ray Smith <ray at RaymondSmith.com>
Dec 24, 2006
-
Last edited Dec 25, 2006
Hi Chris,
Chris Bensler wrote:
> I wish I could just take my own path and start right from scratch, but that's
> not going to happen. I've tried already with my empire libs.
>
> How do you propose to convince people to actually use a library that is
> entirely
> incompatible with existing code for Euphoria and uses obfuscated names, just
> so that it doesn't conflict with the RDS libs, eventhough they should never
> be used in conjunction?
If you can't convince people to use a new set of libs is it the right thing
to do to "force" them to use the new libs? (I don't know what the answer is
but I'd err on the side of conservatism)
Release them ... call them "new_{old_lib_name}".
Ask for feedback, make sure they are well documented and stable.
After a "certain period of time" and if a vote takes place they may become
the new official libs.
> Yet again, my plans to reorganize the RDS libs _would not be incompatible_.
> Yes they will break compatability, but I will be providing a way for them to
> be compatible. What's the problem with that?
Yep, sounds great.
In general you just can't force people to use a new set of standard libraries
without those libraries having been around for awhile.
But go ahead and release them, I agree that a great set of cross platform
(where possible) standard libs is something Eu has been missing for a long time.
Regards.
Ray Smith
http://RaymondSmith.com
16. Re: Standardized Euphoria
Chris Bensler wrote:
>
> Ray Smith wrote:
> >
> > cklester wrote:
> > >
> > > Robert Craig wrote:
> > > >
> > > > I don't think you should change the existing standard .e
> > > > files in a way that will cause existing programs to break.
> > >
> > > True. Instead, release a "Standard Libraries Package v2.0."
> > >
> > > All new programs can use this new library, and the old one can be
> > > phased out or whatever.
> >
> >
> > I agree 100%.
> > Only after "most" people are using the new library should there be any
> > thought
> >
> > about breaking backward compatibility.
> >
> > Ray Smith
> > <a href="http://RaymondSmith.com">http://RaymondSmith.com</a>
>
>
> "1. Besides additional functionality, I would prefer to redesign/reorganize
> the
> existing libs. Would this be acceptable to people?
>
> The new libs would not be compatible with the RDS libs but they would include
> the same functionality, plus much more. The alternative is to just build upon
> the existing libs, though I strongly beleive that we would be better off if
> they were reorganized. Now that Eu supports include subfolders, I do have a
> way for 'legacy' code that uses rds libs to be compatible with the new libs,
> since that would of course be a concern. This plan has actually been on the
> backburner for many years because Euphoria didn't support include subfolders
> until v3."
>
> I'm too tired to try and find a different way to explain the same thing.
> Please read the thread again more thouroughly.
I bet you are!!
Could it be that Euphoria after all these years, has reached a crossroad? A
"defining moment" as the famous Dr. Phil puts it?
That happened in the Perl world between Perl4 and Perl5 -- and soon again
with the upcoming Perl6. Some things got broke, but that was the price for
moving on. Anybody *use* that old DOS stuff any more?
I'm too new to Euphoria to pop-off too much, but you have my "go-for-it"
vote! ( he mumbles: Gosh I hope that this doen't mean I *have* to learn OOP )
;)
--
duke
17. Re: Standardized Euphoria
Chris Bensler wrote:
> ETC.
You dont have to break anything.
Just leave the normal RDS includes where they are
since any function you want to use is global.
All you have to do is create your new libraries and import
any RDS global function you want to use and export it as a global function
from your new library.
If someone uses your library and does not include a RDS library
that has this function in it.
If they want to use RDS library then they will have to use them exclusively
or use name spaces.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
18. Re: Standardized Euphoria
Re compatibility,
If along with your "cb_stdlib.e" you release ~10 (19-byte) files , eg
dll.e:
include cb_stdlib.e
I think that might help somewhat.
Don't kick me if it's a duff idea, though.
With regards to include file handling, under 2.4 you could code eg:
include some\path\or\other\xxx.e
include xxx.e
and it would effectively ignore the "include xxx.e". Under 3.0.0 and
later it has another "look see" for xxx.e, which is fine, BUT if it
cannot (now) find, it CRASHES! I firmly believe it should check the
previous includes and if an "xxx.e" was included OK elsewhere, accept
that it /has/ already been included and move on...
Or am I really the lone voice of this unacceptable incompatibility?
(this is, again, really all about not modifying 3rd party sources)
Regards,
Pete
19. Re: Standardized Euphoria
Ray Smith wrote:
>
> If you can't convince people to use a new set of libs is it the right thing
> to do to "force" them to use the new libs? (I don't know what the answer is
>
> but I'd err on the side of conservatism)
> Release them ... call them "new_{old_lib_name}".
> Ask for feedback, make sure they are well documented and stable.
> After a "certain period of time" and if a vote takes place they may become
> the new official libs.
I don't intend to force anyone to do anything. People could still choose to use
the existing RDS libs. In time hopefully the new libs would be worthy of
replacing it in the distribution. To start it would of course just be an
alternative lib set.
Happy Holidays!
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
20. Re: Standardized Euphoria
Pete Lomax wrote:
>
> Re compatibility,
> If along with your "cb_stdlib.e" you release ~10 (19-byte) files , eg
> dll.e:
> }}}
<eucode>
> include cb_stdlib.e
> </eucode>
{{{
> I think that might help somewhat.
> Don't kick me if it's a duff idea, though.
I'm not quite sure what you mean, but I think I know.
It's basically what I'm doing.
Here is an example of what eu/include/machine.e currently looks like in the
prototype API:
-- This file is an abstraction layer to provide Empire Std library compatability
-- to legacy applications created using the RDS libs
-- These are provided in a deprecated state.
-- When the transition from the RDS library dependencies to Empire Std library
dependencies
-- is satisfactory, these abstraction libraries will be eliminated from the
standard distribution.
include std/core/error.e
include std/util/system.e
include std/mem/mem.e
include std/mem/binary.e
include std/math/math.e
include std/gfx/graphics.e
> With regards to include file handling, under 2.4 you could code eg:
> }}}
<eucode>
> include some\path\or\other\xxx.e
> include xxx.e
> </eucode>
{{{
> and it would effectively ignore the "include xxx.e". Under 3.0.0 and
> later it has another "look see" for xxx.e, which is fine, BUT if it
> cannot (now) find, it CRASHES! I firmly believe it should check the
> previous includes and if an "xxx.e" was included OK elsewhere, accept
> that it /has/ already been included and move on...
>
> Or am I really the lone voice of this unacceptable incompatibility?
> (this is, again, really all about not modifying 3rd party sources)
Yer saying that if foo/xxx.e is already included and I try to include bar/xxx.e
which doesn't exist, it should default to foo/xxx.e like it did when using
previous versions of Eu?
I don't agree. I consider the previous behaviour to be broken.
Happy Holidays!
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
21. Re: Standardized Euphoria
Chris Bensler wrote:
> Here is an example of what eu/include/machine.e currently looks like in the
> prototype API:
>
> }}}
<eucode>
> -- This file is an abstraction layer to provide Empire Std library
> compatability
> -- to legacy applications created using the RDS libs
> -- These are provided in a deprecated state.
> -- When the transition from the RDS library dependencies to Empire Std library
> dependencies
> -- is satisfactory, these abstraction libraries will be eliminated from the
> standard distribution.
>
> include std/core/error.e
> include std/util/system.e
> include std/mem/mem.e
> include std/mem/binary.e
> include std/math/math.e
> include std/gfx/graphics.e
> </eucode>
{{{
>
>
> > With regards to include file handling, under 2.4 you could code eg:
> > }}}
<eucode>
> > include some\path\or\other\xxx.e
> > include xxx.e
> > </eucode>
{{{
> > and it would effectively ignore the "include xxx.e". Under 3.0.0 and
> > later it has another "look see" for xxx.e, which is fine, BUT if it
> > cannot (now) find, it CRASHES! I firmly believe it should check the
> > previous includes and if an "xxx.e" was included OK elsewhere, accept
> > that it /has/ already been included and move on...
> >
> > Or am I really the lone voice of this unacceptable incompatibility?
> > (this is, again, really all about not modifying 3rd party sources)
>
> Yer saying that if foo/xxx.e is already included and I try to include
> bar/xxx.e
> which doesn't exist, it should default to foo/xxx.e like it did when using
> previous
> versions of Eu?
>
> I don't agree. I consider the previous behaviour to be broken.
I believe that Chris is on the correct track here. I support his work and would
feel comfortable in contributing to a reorganisation of the standard library set
that comes with Euphoria. I can also see that the effort might plug a few
remaining gaps in the library functionality.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
22. Re: Standardized Euphoria
Chris Bensler wrote:
>
> I'm working on designing new standard libraries for Euphoria to replace the
> RDS libs that are shipped with the distro.
>
> I have a few questions.
>
> 1. Besides additional functionality, I would prefer to redesign/reorganize the
> existing libs. Would this be acceptable to people?
Ok, it sounds as though most people are in agreement on this topic, so it will
proceed.
On to the next issue:
> 2. Many things that would be added to the standardized libraries would collide
> with existing projects that define the same things in it's own code.
> This problem is unavoidable if I wish to expand on the RDS libraries, but I'm
> sure it would deter many people from migrating. Any opinions on this?
The collisions I'm referring to here are the addition of things like
TRUE, FALSE, NULL, abs(), or_all(), etc...
Although we already deal with these types of collisions anyways.
I've included a prototype distro which only contains the RDS libs reorganized,
along with the abstraction files.
Have a look and let me know if you have any suggestions.
(Euphoria Library Foundation)
http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip
There is a few things to keep in mind"
1. There is currently no additional functionality in the elf api other than a
couple of things.
i) std/core/declares.e defines some addtional constants (TRUE/FALSE, etc..)
These additions demonstrate the conflict I mention in my #2 query. If you try to
run the distributed eu demos, you will find that you need to either modify the
demos or modify the elf libs.
ii) safe.e was changed to std/mem/debug.e and uses a slightly different
technique which allows debug.e to be used in conjunction with std/mem/mem.e by
simply including it before including mem.e, instead of the previous behaviour
where safe.e was a replacement for machine.e
This change is not definite since the method involves the use of routine id
which could affect code cleanup when binding (or translating?). (look at the
DEBUG ROUTINE PLACEHOLDERS in std/mem/mem.e)
I'll explain the issue in more detail at a later time when someone brings it up,
although I think it's probably insignificant.
2. the subfolder structure is not definite, it's only a prototype for now to
provide a basis and to get the idea across. Some of the subfolders seem sort of
redundant, but there will be many more files added.
Perhaps before we figure out what the structure will be like, we should decide
on what kinds of things will be added?
3. the xtra/ subfolder does not belong. The elf api should contain only primary
functionality.
I think msgbox.e should be deprecated in favour of a win32 API and database.e
deserves to be it's own distribution.
4. ideally, extraneous functionality such as a win32 API and various database
systems will be supported officially by at least affirmation of conformity and
quality.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
23. Re: Standardized Euphoria
Chris Bensler wrote:
>
> Chris Bensler wrote:
> >
> > I'm working on designing new standard libraries for Euphoria to replace the
> > RDS libs that are shipped with the distro.
> >
> > I have a few questions.
> >
> > 1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> Ok, it sounds as though most people are in agreement on this topic, so it will
> proceed.
>
> On to the next issue:
>
> > 2. Many things that would be added to the standardized libraries would
> > collide
> > with existing projects that define the same things in it's own code.
> > This problem is unavoidable if I wish to expand on the RDS libraries, but
> > I'm
> > sure it would deter many people from migrating. Any opinions on this?
>
> The collisions I'm referring to here are the addition of things like
> TRUE, FALSE, NULL, abs(), or_all(), etc...
> Although we already deal with these types of collisions anyways.
>
> I've included a prototype distro which only contains the RDS libs reorganized,
> along with the abstraction files.
> Have a look and let me know if you have any suggestions.
>
> (Euphoria Library Foundation)
> <a
> href="http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip">http://www.empire.iwireweb.com/dl/elf-api%20v0.0.1.zip</a>
>
> There is a few things to keep in mind"
>
> 1. There is currently no additional functionality in the elf api other than
> a couple of things.
>
> i) std/core/declares.e defines some addtional constants (TRUE/FALSE, etc..)
> These additions demonstrate the conflict I mention in my #2 query. If you try
> to run the distributed eu demos, you will find that you need to either modify
> the demos or modify the elf libs.
>
> ii) safe.e was changed to std/mem/debug.e and uses a slightly different
> technique
> which allows debug.e to be used in conjunction with std/mem/mem.e by simply
> including it before including mem.e, instead of the previous behaviour where
> safe.e was a replacement for machine.e
> This change is not definite since the method involves the use of routine id
> which could affect code cleanup when binding (or translating?). (look at the
> DEBUG ROUTINE PLACEHOLDERS in std/mem/mem.e)
> I'll explain the issue in more detail at a later time when someone brings it
> up, although I think it's probably insignificant.
>
> 2. the subfolder structure is not definite, it's only a prototype for now to
> provide a basis and to get the idea across. Some of the subfolders seem sort
> of redundant, but there will be many more files added.
> Perhaps before we figure out what the structure will be like, we should decide
> on what kinds of things will be added?
>
> 3. the xtra/ subfolder does not belong. The elf api should contain only
> primary
> functionality.
> I think msgbox.e should be deprecated in favour of a win32 API and database.e
> deserves to be it's own distribution.
>
> 4. ideally, extraneous functionality such as a win32 API and various database
> systems will be supported officially by at least affirmation of conformity and
> quality.
>
>
> Chris Bensler
> ~ The difference between ordinary and extraordinary is that little extra ~
> <a href="http://empire.iwireweb.com">http://empire.iwireweb.com</a> - Empire
> for Euphoria
Hi
I've had a look at that folder/file structure - would I be correct in thinking
that the
way you want to take it forward is to have th 'old' standard includes in the top
level,
and the 'new' standard includes within a new folder structure under
/include/std
If so - I like it - it should retain backwards compatability that way.
Bear in mind that any file reorganising should not be exclusive to windows,
and that win32 api functions are not necessarily part of a standard euphoria
installation (ditto the wxwidgets and other cross platform GUI's)
This IMHO, should be a good thing.
Chris
PS please don't start any function names with CB!
Chris Burch
24. Re: Standardized Euphoria
- Posted by cklester <cklester at yahoo.com>
Dec 27, 2006
-
Last edited Dec 28, 2006
Chris Bensler wrote:
>
>
> I think msgbox.e should be deprecated in favour of a win32 API
I vote 'no' on this one. Official library should be cross-platform only.
A win32 library can be official but not base. wxWidgets FTW.
> and database.e deserves to be its own distribution.
How about that library that lets you interface to all databases?
Right now I use Matt Lewis' EuSQL quite extensively and effectively for all
my database needs. Since all my database interface is SQL, I could change from
EDS to [fill in the blank] whenever I please (in theory). :)
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
25. Re: Standardized Euphoria
- Posted by ags <eu at 531pi.co.nz>
Dec 27, 2006
-
Last edited Dec 28, 2006
Chris Bensler wrote:
>
> 3. the xtra/ subfolder does not belong. The elf api should contain only
> primary
> functionality.
Hi Chris, I like what you have done, though I think the database should remain
seen as 'base'. It is a good general purpose file storage system and I don't see
anything wrong with touting a language as containing that, especially given how
mature the code is.
Also to maintain compatiblity for a few sub versions how about keeping the
standard include names and locations and have them emit a warning saying "this.e
is deprecated, please use this/that.e instead". eg for safe.e just a short stub
maintained until about version 3.5, or 4?
Also, do forward and back slashes work for include sub folders, ie are they OS
specific? (Can I use forward slashes on DOS/Windows?)
Gary
26. Re: Standardized Euphoria
- Posted by ags <eu at 531pi.co.nz>
Dec 27, 2006
-
Last edited Dec 28, 2006
Hi Chris, scratch all this... I actually LOOKED at what you did (or should I say
SAW 
(Sorry just woke up)
The only thing remaining is about the warning for using deprecated include
files?
Gary
ags wrote:
>
> Chris Bensler wrote:
> >
> > 3. the xtra/ subfolder does not belong. The elf api should contain only
> > primary
> > functionality.
>
> Hi Chris, I like what you have done, though I think the database should remain
> seen as 'base'. It is a good general purpose file storage system and I don't
> see anything wrong with touting a language as containing that, especially
> given
> how mature the code is.
>
> Also to maintain compatiblity for a few sub versions how about keeping the
> standard
> include names and locations and have them emit a warning saying "this.e is
> deprecated,
> please use this/that.e instead". eg for safe.e just a short stub maintained
> until about version 3.5, or 4?
>
> Also, do forward and back slashes work for include sub folders, ie are they
> OS specific? (Can I use forward slashes on DOS/Windows?)
>
> Gary
27. Re: Standardized Euphoria
ChrisBurch2 wrote:
> Hi
>
> I've had a look at that folder/file structure - would I be correct in thinking
> that the
> way you want to take it forward is to have th 'old' standard includes in the
> top level,
> and the 'new' standard includes within a new folder structure under
> /include/std
>
> If so - I like it - it should retain backwards compatability that way.
Yes and no. The 'old' includes are just dummy files now. In time, they will be
eliminated entirely.
> Bear in mind that any file reorganising should not be exclusive to windows,
> and that win32 api functions are not necessarily part of a standard euphoria
> installation (ditto the wxwidgets and other cross platform GUI's)
>
> This IMHO, should be a good thing.
Agreed, that type of code does not belong in the distribution, but it would be
desirable to at least endorse certain things like gui API's.
Personally, I'm inclined to even remove the DOS graphics,image and mouse libs
from the API making them a separate download since they are fairly high-level
functionality also.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
28. Re: Standardized Euphoria
cklester wrote:
>
> Chris Bensler wrote:
> >
> >
> > I think msgbox.e should be deprecated in favour of a win32 API
>
> I vote 'no' on this one. Official library should be cross-platform only.
> A win32 library can be official but not base. wxWidgets FTW.
I think you kinda misunderstood. Part of my reasoning for removing msgbox.e is
because it's not x-platform. It's also isolated, top-level functionality which
will interfere with other gui API's (specifically win32) if someone tries to use
them in conjuction by mistake.
I would like to see several gui API's being supported, so that people have
choice. Personally, I'm generally not interested in x-platform development so I
would prefer to have a win32 API.
I'd like to see endorsements for wxWidgets and possibly gtk, and maybe others?
It's not a matter of certifying that any library is better than another, just
that those API's meet certain criteria, such as completed documentation,
examples, full functionality and stability.
(What's FTW?)
> > and database.e deserves to be its own distribution.
>
> How about that library that lets you interface to all databases?
>
> Right now I use Matt Lewis' EuSQL quite extensively and effectively for all
> my database needs. Since all my database interface is SQL, I could change from
> EDS to [fill in the blank] whenever I please (in theory). :)
Sure, something like that may be supported as an external package, but it should
not be part of the ELF API.
Keep in mind that ELF = Eu Library _Foundation_
It will provide the base for other libraries, such as databases, gfx libs,
gui's, sockets, etc...
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
29. Re: Standardized Euphoria
ags wrote:
>
> Hi Chris, scratch all this... I actually LOOKED at what you did (or should I
> say SAW
> (Sorry just woke up)
>
> The only thing remaining is about the warning for using deprecated include
> files?
>
> Gary
>
> ags wrote:
> >
> > Chris Bensler wrote:
> > >
> > > 3. the xtra/ subfolder does not belong. The elf api should contain only
> > > primary
> > > functionality.
> >
> > Hi Chris, I like what you have done, though I think the database should
> > remain
> > seen as 'base'. It is a good general purpose file storage system and I
> > don't
> > see anything wrong with touting a language as containing that, especially
> > given
> > how mature the code is.
> >
> > Also to maintain compatiblity for a few sub versions how about keeping the
> > standard
> > include names and locations and have them emit a warning saying "this.e is
> > deprecated,
> > please use this/that.e instead". eg for safe.e just a short stub maintained
> > until about version 3.5, or 4?
> >
> > Also, do forward and back slashes work for include sub folders, ie are they
> > OS specific? (Can I use forward slashes on DOS/Windows?)
> >
> > Gary
Good point. I wanted to bring it up before.
I havent tested in v3, but in previous versions that allowed subfolders in the
include statements, slashes were not interchangable. / would only work for linux
and windows, but \ would only work for DOS and windows.
From glancing at the source, I think the problem might have been addressed
already in v3.
From experience, I can tell you that you should normally use forward slash of
course, since backslash is a valid character within file and folder names on unix
systems.
IMO, Eu should only support forward slashes to be in accordance with x-plat
compatability since neither slash is a valid character in a DOS/WIN file name.
We'll have to test and verify to see. It would be a simple fix in the
interpretter if need be.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
30. Re: Standardized Euphoria
Chris Bensler wrote:
> cklester wrote:
> > I vote 'no' on this one. Official library should be cross-platform only.
> > A win32 library can be official but not base. wxWidgets FTW.
> (What's FTW?)
"For the win" :)
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
31. Re: Standardized Euphoria
I'm still confused on the purpose of changing the standard libraries.
When we attempted the ESL we got hung up on details like coding standards and
specifications and what not. We didn't have just one person with some good ideas
that the others were willing to follow, rather we had several people whose
definitions of what needed to be done were all different. That is where you
probably have an advantage.
I haven't seen any of this Empire stuff except for references to it over the
years so I don't necessarily know whether its longevity is an advantage or not.
I also wonder about your statement up above about not being able to write
documentation. Can't you write documentation from your specification? You do have
a specification, don't you? Even though I haven't grasped it from your posts you
seem to have one.
Anyway, my vote is that the current Euphoria libraries are just fine as they are
but there is some functionality that needs to be added as "standard".
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
32. Re: Standardized Euphoria
Jason Gade wrote:
>
> I'm still confused on the purpose of changing the standard libraries.
This is why I'm at least not the right person to be writing docs if I can avoid
it. I need a mediator.
The purpose is to lay the groundwork for future additions without making the API
seem even more confusing than it already is. In general, I think most people
agree that some of the current categorizations were a matter of convenient
placement and not practical design. Understandably, Rob didn't want to create a
file for just one simple routine in the event that other routines will be added,
instead he chose to lump a bunch of more-or-less related things with each other
to make the files more balanced. The trig routines in misc.e should be placed in
a math library or even more specifically a trigonometry library for example. I
think that should be rectified.
> When we attempted the ESL we got hung up on details like coding standards and
> specifications and what not. We didn't have just one person with some good
> ideas
> that the others were willing to follow, rather we had several people whose
> definitions
> of what needed to be done were all different. That is where you probably have
> an advantage.
In a way, yes. Democracy is a long process, but dictatorship can be worse.
It is my hope that others will get involved with this project, although I would
probably want to maintain some kind of creative control.
> I haven't seen any of this Empire stuff except for references to it over the
> years so I don't necessarily know whether its longevity is an advantage or
> not.
It's just experience with the concepts I'm presenting.
There have been other concepts in empire that I will not be introducing because
I see them as being unsuccessful, such as a library that provides predefined
routine id's for all the eu builtins.
> I also wonder about your statement up above about not being able to write
> documentation.
> Can't you write documentation from your specification? You do have a
> specification,
> don't you? Even though I haven't grasped it from your posts you seem to have
> one.
No I don't really have any specifications written down, but I do have a clear
plan in my mind. It's not like I haven't tried to write it down though. It's very
tough to convince people to assist you when you can't even explain what you need
assistance with. Frankly I don't enjoy writing documentation, mainly because it's
futile for me. What seems common sense to me is difficult for others and I have a
tendency to either under or over explain things because of it.
I suppose I just feel my time is better spent working on the ideas instead of
trying to explain them. Afterall, some people are good at writing but not so good
at coming up with their own ideas. Makes sense to allow them to do the documents
while I do the advising and work on development. Just my POV. Realistically, I
should make more effort to be good at writing documentation just so that I could
express my ideas better, but it's hard to be good at something you don't enjoy
doing. Even if I were good at expressing my ideas, I still wouldn't have enough
time to reflect them all.
My excessive ramblings on this forum are a prime example of why I can't write
docs. Nobody wants to read a book about how and why Eu's scoping rules should be
rectified, for example. I'm sure alot of people think I just like to debate
without resolve :)
> Anyway, my vote is that the current Euphoria libraries are just fine as they
> are but there is some functionality that needs to be added as "standard".
Just leave a bunch fo stuff in misc.e rather than moving it to a more meaningful
categorization with additional routines that are implemented?
Nobody has expressed any real contention or issues with moving the rds libs to
subfolders. Doing so would make any rearrangement of the files or existing
routines in the libs insignificant since you will be forced to use a
compatability layer anyway. For someone who is accustomed to Eu, the arrangment
is not a very big deal but for someone who is new it appears to be rather ad-hoc
and unintuitive. That trait will compound when new functionality is added if we
don't correct it.
Euphoria NEEDS to have more people using it. Much more.
Regardless if you would like to see Eu become a mainstream language or you like
the fact that it has a cult following, it's undeniable that Eu and everyone who
uses it suffers from isolation and lack of participation. Things like revamping
the distributed libraries is a first step in this direction.
Just like building a house, if you don't have a proper foundation, it doesn't
really matter what you do on top of it.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
33. Re: Standardized Euphoria
On Mon, 25 Dec 2006 11:57:50 -0800, Chris Bensler <guest at RapidEuphoria.com>
wrote:
>It's basically what I'm doing.
Yep, looks fine to me.
>Yer saying that if foo/xxx.e is already included and I try to include
>bar/xxx.e which doesn't exist, it should default to foo/xxx.e like it
>did when using previous versions of Eu?
Nearly.
>I don't agree. I consider the previous behaviour to be broken.
When you say "bar/xxx.e", as opposed to just "xxx.e", and there is no such
file loaded from a subdirectory named bar, wherever that dir is, then I
agree, but imo when you just say "xxx.e" you imply you don't care where
it is, and of course the compiler will look in current_dir, EUINC, EUDIR,
and possibly a few other places as well for you.
What I now (in Positive) have, and let's be honest not exactly difficult
to implement, is this:
include test\t05\inc5\t2.e
--include t2.e -- OK
--include inc5\t2.e -- OK
--include c5\t2.e -- Bad
--include foo\t2.e -- Bad
Another way to say this is: if your app uses libs from Chris and Dave,
which both use Bob's, correct organisation is Bob/Chris/Dave, not
Chris/Bob/Dave/Bob.
The way things stand, if I try to put bob.e and associated paraphernalia
into bob\, then the "include bob.e" statements in chris.e and dave.e will
both crash.
Regards,
Pete
