1. Detecting the Eu version
Hi all,
recently Derek and Pete (L) posted here some useful code, that allows
a program to detect the current Eu version at runtime. I think it is
especially helpful to use such a functionality in libraries, that
require at least a particular Eu version.
Concerning Eu 2.5, it can look like this:
include machine.e
if routine_id("crash_routine") = -1 then -- crash_routine() was
puts(1, "Euphoria 2.5 or later required." -- introduced in v2.5
& "\n\nPress Enter ...")
if getc(0) then end if
abort(1)
end if
-- In the following some code is used, that will not run on Eu versions
-- prior to 2.5.
sequence s
s = "Hello World?"
s[$] = '!'
puts(1, s)
if getc(0) then end if
Running the above program on Eu versions prior to 2.5, the program will
not crash, but will show the user-defined message, as intended. OK.
The issue I'd like to discuss now is, that I think this might not work
with future Eu versions. Say in Eu 2.6 there will be a new procedure
called new_26_proc(). Then the same approach as above would look
something like this:
if routine_id("new_26_proc") = -1 then
puts(1, "Euphoria 2.6 or later required."
& "\n\nPress Enter ...")
if getc(0) then end if
abort(1)
end if
new_26_proc() -- ... or any other code, that will not
-- run on Eu versions prior to 2.6.
Using Eu 2.6 or later, the program will work anyway. Using Eu 2.4 or
earlier, the program will show the user-defined message, as intended.
But using Eu 2.5, the program will crash. ATM I don't see any way how
a crash could be prevented in this case. That means when we have say Eu
3.0, version checks at run-time will not work with all versions from 2.5
to 2.9, if the program contains any code that was introduced in a later
Eu version.
Is this true, or are there logical errors in my considerations? If it's
true, I believe even a built-in version() function can't solve the
problem, because such a function will act at run-time rather than at
compile-time, right?
If there is any way to solve this problem, it should be done now in v2.5,
so that there will be no "gap" in detecting the Eu version.
Regards,
Juergen
--
Have you read a good program lately?
2. Re: Detecting the Eu version
Hi, Juergen!
You wrote:
> Hi all,
>
> recently Derek and Pete (L) posted here some useful code, that allows
> a program to detect the current Eu version at runtime. I think it is
> especially helpful to use such a functionality in libraries, that
> require at least a particular Eu version.
>
> Concerning Eu 2.5, it can look like this:
> }}}
<eucode>
> include machine.e
> if routine_id("crash_routine") = -1 then -- crash_routine() was
> puts(1, "Euphoria 2.5 or later required." -- introduced in v2.5
> & "\n\nPress Enter ...")
> if getc(0) then end if
> abort(1)
> end if
There is some universal method - all ex.exes, exw.exes, exus, ec.exes etc
have the unique lengths.
So, you can detect the version with something like to:
global function version(sequence name, atom EXE_Length)
name = machine_func(22, name) -- dir info
if name[1][3] = EXE_Length then
return 1
else
return 0
end if
end fubction
[snip]
Just pass the name of the needed interpreter and
its known length and you'll get an answer is it yours one
or no, it is not.
Regards,
Igor Kachan
kinz at peterlink.ru
3. Re: Detecting the Eu version
Igor Kachan wrote:
> Hi, Juergen!
>
> You wrote:
>
>> Hi all,
>>
>> recently Derek and Pete (L) posted here some useful code, that allows
>> a program to detect the current Eu version at runtime. I think it is
>> especially helpful to use such a functionality in libraries, that
>> require at least a particular Eu version.
>>
>> Concerning Eu 2.5, it can look like this:
>> }}}
<eucode>
>> include machine.e
>> if routine_id("crash_routine") = -1 then -- crash_routine() was
>> puts(1, "Euphoria 2.5 or later required." -- introduced in v2.5
>> & "\n\nPress Enter ...")
>> if getc(0) then end if
>> abort(1)
>> end if
My previous post begins with an "introduction", that ends with the word
"OK". _Thereafter_ follows the description of the problem that I see.
What you quoted here, is only a part of the "introduction".
> There is some universal method - all ex.exes, exw.exes, exus, ec.exes etc
> have the unique lengths.
>
> So, you can detect the version with something like to:
>
> }}}
<eucode>
> global function version(sequence name, atom EXE_Length)
> name = machine_func(22, name) -- dir info
> if name[1][3] = EXE_Length then
> return 1
> else
> return 0
> end if
> end fubction
> </eucode>
{{{
>
> [snip]
>
> Just pass the name of the needed interpreter and
> its known length and you'll get an answer is it yours one
> or no, it is not.
That will not solve the problem that I described. If I had expressed
myself ambiguously or otherwise unclear in my original post, please tell
me what you didn't understand.
Regards,
Juergen
--
Have you read a good program lately?
4. Re: Detecting the Eu version
On Mon, 13 Dec 2004 11:17:48 +0100, Juergen Luethje <j.lue at gmx.de>
wrote:
>But using Eu 2.5, the program will crash. ATM I don't see any way how
>a crash could be prevented in this case.
You're quite right. No attempt to set up a friendly crash_message will
help, the end user will see the compile error instead.
If we had "with 2.5" checked at compile time it would certainly help.
Note that 2.4 and before will ignore "with 2.5" (part of the old
stamping feature which used an 8 or 9-digit integer), so the other
methods would still be required.
Regards,
Pete
5. Re: Detecting the Eu version
Pete Lomax wrote:
>
> On Mon, 13 Dec 2004 11:17:48 +0100, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
> >But using Eu 2.5, the program will crash. ATM I don't see any way how
> >a crash could be prevented in this case.
> You're quite right. No attempt to set up a friendly crash_message will
> help, the end user will see the compile error instead.
People have been asking for a simple version() function as far back as
Jan, 1999. If Rob weren`t so pig-headedly stubborn, he would have added the
necessary code (maybe 12 bytes?) at that time, and the issue of "backward
compatibility" would have resolved itself by now. Hardly anyone is uses the
1.x versions of Euphoria any more, do they? And those who do won't be able
to use current code anyway, because it will almost certainly need things like
routine_id, etc.
> If we had "with 2.5" checked at compile time it would certainly help.
>
> Note that 2.4 and before will ignore "with 2.5" (part of the old
> stamping feature which used an 8 or 9-digit integer), so the other
> methods would still be required.
Somehow, I have the feeling that you could change those numbers to
3.4 and 3.5, or even 5.4 and 5.5, and post that message again 5 years
from now, and what you say would still be true.
Too bad Rob just can't admit that he made a minor mistake back around
1.0, and just FIX IT NOW, so this discussion won't still be taking place
in 2009.
Irv
6. Re: Detecting the Eu version
Juergen Luethje wrote:
>
> Igor Kachan wrote:
>
> > Hi, Juergen!
> >
> > You wrote:
> >
> >> Hi all,
> >>
> >> recently Derek and Pete (L) posted here some useful code, that allows
> >> a program to detect the current Eu version at runtime. I think it is
> >> especially helpful to use such a functionality in libraries, that
> >> require at least a particular Eu version.
> >>
> >> Concerning Eu 2.5, it can look like this:
> >> }}}
<eucode>
> >> include machine.e
> >> if routine_id("crash_routine") = -1 then -- crash_routine() was
> >> puts(1, "Euphoria 2.5 or later required." -- introduced in v2.5
> >> & "\n\nPress Enter ...")
> >> if getc(0) then end if
> >> abort(1)
> >> end if
>
> My previous post begins with an "introduction", that ends with the word
> "OK". _Thereafter_ follows the description of the problem that I see.
> What you quoted here, is only a part of the "introduction".
Ok, I do understand this.
> > There is some universal method - all ex.exes, exw.exes, exus, ec.exes
etc
> > have the unique lengths.
> >
> > So, you can detect the version with something like to:
> >
> > }}}
<eucode>
> > global function version(sequence name, atom EXE_Length)
> > name = machine_func(22, name) -- dir info
> > if name[1][3] = EXE_Length then
> > return 1
> > else
> > return 0
> > end if
> > end fubction
> > </eucode>
{{{
> >
> > [snip]
> >
> > Just pass the name of the needed interpreter and
> > its known length and you'll get an answer is it yours one
> > or no, it is not.
>
> That will not solve the problem that I described. If I had expressed
> myself ambiguously or otherwise unclear in my original post, please tell
> me what you didn't understand.
Described way, author can detect *any* concrete version of Euphoria, where
his program *can not run*.
Then it is just an author's problem - to stop his program with a warning
message or to give user a standard crash message without any additional
explanations.
So, I just didn't see some "gap", as you say in the part of your message,
that I have snipped off.
I snipped that part, where I have nothing to say or comment, sorry, that
was just usual practice, I think.
Regards,
Igor Kachan
kinz at peterlink.ru
7. Re: Detecting the Eu version
irv mullins wrote:
[snip]
> People have been asking for a simple version() function
> as far back as Jan, 1999. If Rob weren`t so pig-headedly
> stubborn, he would have added the necessary code
> (maybe 12 bytes?) at that time, and the issue of "backward
> compatibility" would have resolved itself by now.
> Hardly anyone is uses the 1.x versions of Euphoria any more,
> do they? And those who do won't be able to use current code
> anyway, because it will almost certainly need things
> like routine_id, etc.
[snip]
Just 1.12.2004, I sent to one Ukrainian programmer v1.4b
and Russian docs on it I have. He asked me for that to
have a free binder. And it is not a single case this year.
What do you know about dozens of thousands EU users at all?
If you want a version(), use the ready one just now.
Regards,
Igor Kachan
kinz at peterlink.ru
8. Re: Detecting the Eu version
Igor Kachan wrote:
> Juergen Luethje wrote:
>>
>> Igor Kachan wrote:
<big snip>
>>> Just pass the name of the needed interpreter and
>>> its known length and you'll get an answer is it yours one
>>> or no, it is not.
>>
>> That will not solve the problem that I described. If I had expressed
>> myself ambiguously or otherwise unclear in my original post, please tell
>> me what you didn't understand.
>
> Described way, author can detect *any* concrete version of Euphoria, where
> his program *can not run*.
> Then it is just an author's problem - to stop his program with a warning
> message or to give user a standard crash message without any additional
> explanations.
No. The problem that I described happens at compile-time (with Eu 2.5
and later), so it can't be solved by anything that happens at run-time.
Whatever code you'll write in this regard -- it will never be executed,
because the program crashes beforehand.
> So, I just didn't see some "gap", as you say in the part of your message,
> that I have snipped off.
> I snipped that part, where I have nothing to say or comment, sorry, that
> was just usual practice, I think.
You snipped the part that contained my question, and you "answered"
something that I didn't ask.
Regards,
Juergen
--
Have you read a good program lately?
9. Re: Detecting the Eu version
Igor Kachan wrote:
>
>
> What do you know about dozens of thousands EU users at all?
> If you want a version(), use the ready one just now.
Search the archives.
By the way, your version won't work, you know.
Irv
10. Re: Detecting the Eu version
Pete Lomax wrote:
> On Mon, 13 Dec 2004 11:17:48 +0100, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> But using Eu 2.5, the program will crash. ATM I don't see any way how
>> a crash could be prevented in this case.
>
> You're quite right. No attempt to set up a friendly crash_message will
> help, the end user will see the compile error instead.
>
> If we had "with 2.5" checked at compile time it would certainly help.
I like this suggestion!!
> Note that 2.4 and before will ignore "with 2.5" (part of the old
> stamping feature which used an 8 or 9-digit integer), so the other
> methods would still be required.
I see. And I just tested, that Eu 2.5 alpha also ignores "with 2.5", and
e.g. "with 4.0", too.
Rob, here comes my wish for Christmas. 
Could you please build this into Eu 2.5 beta:
If there is "with [any number > 2.5]" in the source code, then Euphoria
stops compiling and says something like:
"Sorry, this program requires Euphoria version [specified number] or
later."
This will not be useful until Eu 2.6 is out, however, it must be built
into Eu 2.5 now, of course -- if you want to do so.
Wishing,
Juergen
--
Have you read a good program lately?
11. Re: Detecting the Eu version
Igor Kachan wrote:
>
> What do you know about dozens of thousands EU users at all?
> If you want a version(), use the ready one just now.
The people who have asked for 'version' are the same people
who have contributed several hundred thousand dollars worth of development
work to the Euphoria community (see win32lib, ide, etc). Even if no one
else had asked, you'd think Rob would be willing to do 5 minutes worth of
work as a 'thank you'.
Now, if you are referring to the plan you submitted, it should be obvious
why that can't work. In addition to what Jergen posted:
1. What happens when version 2.5 reaches "official" status, and then,
after a couple of months, Rob fixes some minor, obscure bug which causes
the size of the file to change by a few bytes? I *am* running 2.5, but
your code says "Sorry, this requires 2.5".
2. How do you write code to allow "2.5 or better", when you have no idea what
size 2.6 will be? Yet, isn't it very likely that code written for 2.5 will
also run just fine on 2.6 (and later) versions?
Irv
12. Re: Detecting the Eu version
Juergen Luethje wrote:
[very big snip]
> > Described way, author can detect *any* concrete version of Euphoria,
where
> > his program *can not run*.
> > Then it is just an author's problem - to stop his program with
> > a warning message or to give user a standard crash message without
> >any additional explanations.
>
> No. The problem that I described happens at compile-time (with Eu 2.5
> and later), so it can't be solved by anything that happens at run-time.
> Whatever code you'll write in this regard -- it will never be executed,
> because the program crashes beforehand.
You can not run some new code with some old interpreters.
OK, you'll get an error message to understand what happend.
Who cares is it at run-time or at compile-time?
Old interpreters have mixed run/compile time for the top
level statements. See ex.err file, update your Euphoria
and you are all set.
So, the critical case is some old not bound code with some new
interpreters.
The only way is to update that some *old code* for some *new interpreter*.
Remember please your efforts on "dynamic inclusion".
> > So, I just didn't see some "gap", as you say in the part of your
message,
> > that I have snipped off.
> > I snipped that part, where I have nothing to say or comment, sorry,
that
> > was just usual practice, I think.
>
> You snipped the part that contained my question, and you "answered"
> something that I didn't ask.
Your main question was about something like a version() function,
as far as I can see, of course. My version() may work Ok too,
if it stands on the very first place of a main program.
It is not tested, but better than with routine_id(), I think.
But the best way is:
!with 2.5 -- Code works with Euphoria v2.5 only, but comment this line
Works for me just now.
I do not see any "gap" again, to answer about it.
Regards,
Igor Kachan
kinz at peterlink.ru
13. Re: Detecting the Eu version
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Dec 13, 2004
-
Last edited Dec 14, 2004
Irv Mullins wrote:
> Igor Kachan wrote:
>
> >
> > What do you know about dozens of thousands EU users at all?
> > If you want a version(), use the ready one just now.
>
> The people who have asked for 'version' are the same people
> who have contributed several hundred thousand dollars worth of
development
> work to the Euphoria community (see win32lib, ide, etc). Even if no one
> else had asked, you'd think Rob would be willing to do 5 minutes worth of
> work as a 'thank you'.
Ok, but no one knows how many hundred thousand dollars they got
using their Euphoria skills.
And it is not an interesting subject for me, be sure.
> Now, if you are referring to the plan you submitted, it should be obvious
> why that can't work. In addition to what Jergen posted:
It works almost on all pre-2.5 versions, which have machine_func(22,s)
implemented.
1.0 has just a wrapped DOS DIR command.
> 1. What happens when version 2.5 reaches "official" status, and then,
> after a couple of months, Rob fixes some minor, obscure bug which causes
> the size of the file to change by a few bytes? I *am* running 2.5, but
> your code says "Sorry, this requires 2.5".
>
> 2. How do you write code to allow "2.5 or better", when you have no idea
what
> size 2.6 will be? Yet, isn't it very likely that code written for 2.5
will
> also run just fine on 2.6 (and later) versions?
Try please:
!with 2.5 -- add your comment here, the 'with' word is blue
or
With 3.0 only -- add your comment here, the 'With' word is black
Works on 2.5, just now, at compile time.
Regards,
Igor Kachan
kinz at peterlink.ru
14. Re: Detecting the Eu version
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Dec 13, 2004
-
Last edited Dec 14, 2004
Igor Kachan wrote:
> Juergen Luethje wrote:
>
> [very big snip]
>
>>> Described way, author can detect *any* concrete version of Euphoria,
>>> where his program *can not run*.
>>> Then it is just an author's problem - to stop his program with
>>> a warning message or to give user a standard crash message without
>>> any additional explanations.
>>
>> No. The problem that I described happens at compile-time (with Eu 2.5
>> and later), so it can't be solved by anything that happens at run-time.
>> Whatever code you'll write in this regard -- it will never be executed,
>> because the program crashes beforehand.
>
> You can not run some new code with some old interpreters.
> OK, you'll get an error message to understand what happend.
> Who cares is it at run-time or at compile-time?
That is an important difference. E.g. I do care about it. If you had
read my original post until the end, you probably would know.
> Old interpreters have mixed run/compile time for the top
> level statements. See ex.err file, update your Euphoria
> and you are all set.
>
> So, the critical case is some old not bound code with some new
> interpreters.
No, you did not understand what I wrote.
> The only way is to update that some *old code* for some *new interpreter*.
> Remember please your efforts on "dynamic inclusion".
Thanks, I have no problems regarding my memory. This is a different
issue, you simply don't understand it.
>>> So, I just didn't see some "gap", as you say in the part of your
>>> message, that I have snipped off.
>>> I snipped that part, where I have nothing to say or comment, sorry,
>>> that was just usual practice, I think.
>>
>> You snipped the part that contained my question, and you "answered"
>> something that I didn't ask.
>
> Your main question was about something like a version() function,
> as far as I can see, of course.
Take your time and read my original post from the beginning to the end,
*if* you actually want to know what I wrote. That post is understandable
indeed. I certainly will not try to explain you over and over again what
I wrote. With your first reply, when you snipped my question and
"answered" something that I didn't ask, it was already obvious that we
have different understandings of what meaningful communication is (to
say the least). So this "discussion" is finished for me.
<snip>
Regards,
Juergen
--
Get your facts first, and then
you can distort 'em as you please.
[Mark Twain]
15. Re: Detecting the Eu version
- Posted by Derek Parnell <ddparnell at bigpond.com>
Dec 13, 2004
-
Last edited Dec 14, 2004
Igor Kachan wrote:
>
> Irv Mullins wrote:
>
> > Igor Kachan wrote:
> >
> > >
> > > What do you know about dozens of thousands EU users at all?
> > > If you want a version(), use the ready one just now.
> >
> > The people who have asked for 'version' are the same people
> > who have contributed several hundred thousand dollars worth of
> development
> > work to the Euphoria community (see win32lib, ide, etc). Even if no one
> > else had asked, you'd think Rob would be willing to do 5 minutes worth of
>
> > work as a 'thank you'.
>
> Ok, but no one knows how many hundred thousand dollars they got
> using their Euphoria skills.
How does "sweet F.A." translate into Russian?
--
Derek Parnell
Melbourne, Australia
16. Re: Detecting the Eu version
- Posted by irv mullins <irvm at ellijay.com>
Dec 13, 2004
-
Last edited Dec 14, 2004
Igor Kachan wrote:
>
> Irv Mullins wrote:
> > The people who have asked for 'version' are the same people
> > who have contributed several hundred thousand dollars worth of
> development
> > work to the Euphoria community (see win32lib, ide, etc). Even if no one
> > else had asked, you'd think Rob would be willing to do 5 minutes worth of
> > > work as a 'thank you'.
>
> Ok, but no one knows how many hundred thousand dollars they got
> using their Euphoria skills.
> And it is not an interesting subject for me, be sure.
If they have the skills to write IDE's and Win32 libraries (for free), then
they could have used those same skills and hours to do *paying*
jobs using any number of languages which are more complete and capable
than Euphoria. Just about any computer store has shelves full of these.
Perhaps most of them did this because they hoped that, with enough effort,
Euphoria would become another complete and capable language. Unfortunately,
this seems not to have been a part of the plan.
> > Now, if you are referring to the plan you submitted, it should be obvious
> > why that can't work. In addition to what Jergen posted:
<snip>
"with 2.5" or "with 2.5+" would work nicely. Now the only problem is
getting Rob to implement it. However, to really work properly, it should
be possible to query the required version, so you can present a meaningful
message or even write version dependent code, such as can be done with
platform() now.
Irv
17. Re: Detecting the Eu version
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Dec 13, 2004
-
Last edited Dec 14, 2004
Derek Parnell wrote:
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Igor Kachan wrote:
> >
[snip]
> > Ok, but no one knows how many hundred thousand dollars they got
> > using their Euphoria skills.
>
> How does "sweet F.A." translate into Russian?
I do not know, sorry, what is "F.A." in English?
I have no this abbreviation in my 53,000 words
Muller's dictionary.
Regards,
Igor Kachan
kinz at peterlink.ru
18. Re: Detecting the Eu version
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Dec 13, 2004
-
Last edited Dec 14, 2004
irv mullins wrote:
>
> Igor Kachan wrote:
> >
[snip]
> <snip>
>
> "with 2.5" or "with 2.5+" would work nicely. Now the only problem is
> getting Rob to implement it. However, to really work properly, it should
> be possible to query the required version, so you can present a
meaningful
> message or even write version dependent code, such as can be done with
> platform() now.
Irv, it works for me just now, I just do not want run my program
with interpreter v2.4 if I got the error message that it requires 2.5
only. Then I just comment one line and run it on 2.5.
Some people are strange here, it works just now, but they want
to force Rob to implement new feature, rewrite docs etc.
Then I need retranslate all these docs into Russian etc.
For what? For a feature, which works fine just *now*?
Do you know, fc command gives about 600Kb file of differensies
in docs for 2.3 and for 2.5? 300 pages just to read.
So use, please:
!with 2.9 -- Code works with 2.9 only, but comment this line.
And the best way is to write a version independent code.
Regards,
Igor Kachan
kinz at peterlink.ru
19. Re: Detecting the Eu version
- Posted by irv mullins <irvm at ellijay.com>
Dec 13, 2004
-
Last edited Dec 14, 2004
Igor Kachan wrote:
>
> Irv, it works for me just now, I just do not want run my program
> with interpreter v2.4 if I got the error message that it requires 2.5
> only. Then I just comment one line and run it on 2.5.
>
> Some people are strange here, it works just now, but they want
> to force Rob to implement new feature, rewrite docs etc.
> Then I need retranslate all these docs into Russian etc.
>
> For what? For a feature, which works fine just *now*?
I suppose you are talking about your routine:
> > There is some universal method - all ex.exes, exw.exes, exus, ec.exes
etc
> > have the unique lengths.
> >
> > So, you can detect the version with something like to:
> >
> >
> > global function version(sequence name, atom EXE_Length)
> > name = machine_func(22, name) -- dir info
> > if name[1][3] = EXE_Length then
> > return 1
> > else
> > return 0
> > end if
> > end fubction
> >
Explain, please, how this is supposed to work after the
file size of Euphoria 2.5 changes (as it certainly will, probably
more than once, as Rob fixes bugs).
Explain, please, how this allows "2.5 or better" to be implemented.
Do you somehow know the file size(s) of all future versions of
Euphoria?
Irv
20. Re: Detecting the Eu version
On Mon, 13 Dec 2004 06:29:02 -0800, irv mullins
<guest at RapidEuphoria.com> wrote:
>Pete Lomax wrote:
>>
>> On Mon, 13 Dec 2004 11:17:48 +0100, Juergen Luethje <j.lue at gmx.de>
>> wrote:
>>
>> >But using Eu 2.5, the program will crash. ATM I don't see any way how
>> >a crash could be prevented in this case.
>> You're quite right. No attempt to set up a friendly crash_message will
>> help, the end user will see the compile error instead.
>
>People have been asking for a simple version() function as far back as
>Jan, 1999.
Jeurgen's main point was that version() wouldn't help, builtin or not.
Regards,
Pete
21. Re: Detecting the Eu version
On Tue, 14 Dec 2004 01:30:10 +0000, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
> >> >But using Eu 2.5, the program will crash. ATM I don't see any way how
> >> >a crash could be prevented in this case.
> >> You're quite right. No attempt to set up a friendly crash_message will
> >> help, the end user will see the compile error instead.
> >
> >People have been asking for a simple version() function as far back as
> >Jan, 1999.
> Jeurgen's main point was that version() wouldn't help, builtin or not.
Well, right and wrong.
I don't think it's possible to write a program in Euphoria that will
adapt to the version of the interpreter that it has, because there's
no preprocessor statements like C's #defines.
What would still be useful is a way to stipulate in code that a
particular version was required.
If a program contains '$' for length(seq), it won't work in anything
but 2.5, and programs written for later versions of Euphoria will
likely have new features that won't work in 2.5.
If there was a method (perhaps the 'with 2.5' that was suggested
earlier) to check the version before proceeding, then it'd make life
easier for people who try and run the program.
If I take a Eu2.5 program and try and run it on Eu2.3, it probably
won't work. Fair enough. However, *why* doesn't it work? A *user* who
encounters a problem caused by this won't know why it occurs. By being
able to *require* a version, the interpreter can stop and say "Error,
this program requires Euphoria version 2.5 or newer", which is much
more helpful.
--
MrTrick
22. Re: Detecting the Eu version
On Tue, 14 Dec 2004 00:39:58 +0300, Igor Kachan <kinz at peterlink.ru>
wrote:
>Some people are strange here, it works just now, but they want
>to force Rob to implement new feature, rewrite docs etc.
>Then I need retranslate all these docs into Russian etc.
>
>For what? For a feature, which works fine just *now*?
Jeurgen has wisely spotted a problem that *WILL* arise on the day 2.6
is released, which ought to be addressed sooner not later.
>Do you know, fc command gives about 600Kb file of differensies
>in docs for 2.3 and for 2.5? 300 pages just to read.
What??!! I suppose you would prefer 2.5 docs to be identical to 2.3?
Stick with 2.3 then, don't try stopping us using new version.
>And the best way is to write a version independent code.
I suppose we shouldn't use the new $ feature then. Rob's already used
it at least 91 times that I know of in the standard package, and next
release of win32lib may well have 700 instances of $, and why not.
Regards,
Pete
23. Re: Detecting the Eu version
On Tue, 14 Dec 2004 13:00:38 +1100, Patrick Barnes <mrtrick at gmail.com>
wrote:
>If I take a Eu2.5 program and try and run it on Eu2.3, it probably
>won't work. Fair enough. However, *why* doesn't it work? A *user* who
>encounters a problem caused by this won't know why it occurs. By being
>able to *require* a version, the interpreter can stop and say "Error,
>this program requires Euphoria version 2.5 or newer", which is much
>more helpful.
Absolutely, the bugbear being you can achieve this in 2.4 but cannot
in a theoretical 2.5 vs 2.6 scenario, hence the request to act now.
Still hoping Rob will at least comment on
with 2.5
and hoping he will agree the '.' will distinguish it adequately from
historical stamping statements.
Regards,
Pete
24. Re: Detecting the Eu version
Pete Lomax wrote:
>
> On Tue, 14 Dec 2004 13:00:38 +1100, Patrick Barnes <mrtrick at gmail.com>
> wrote:
>
> >If I take a Eu2.5 program and try and run it on Eu2.3, it probably
> >won't work. Fair enough. However, *why* doesn't it work? A *user* who
> >encounters a problem caused by this won't know why it occurs. By being
> >able to *require* a version, the interpreter can stop and say "Error,
> >this program requires Euphoria version 2.5 or newer", which is much
> >more helpful.
>
> Absolutely, the bugbear being you can achieve this in 2.4 but cannot
> in a theoretical 2.5 vs 2.6 scenario, hence the request to act now.
>
> Still hoping Rob will at least comment on
>
> with 2.5
>
> and hoping he will agree the '.' will distinguish it adequately from
> historical stamping statements.
>
However this only deals with the situation in which the entire program
is incompatible with an earlier version. To deal with the situation
where only part of the code is imcompatible we might additionally need
a run-time function to return the Euphoria version.
I would suggest the machine_func() could be easily adapted for this
purpose, such that we could have something like ...
A new include file, version.e, in the euphoria include folder.
global function version()
return machine_func(M_VERSION, {})
end function
Which would could use as ...
include version.e
. . .
procedure XYZZY()
if version() >= 2.5 then
. . .
else
. . .
end if
end procedure
And for people using earlier versions of Euphoria, RDS or others
could easily provide a specialized edition of version.e to cater
for that, such as ...
global function version()
return 2.3
end function
Well, you get the idea...not exactly rocket science.
--
Derek Parnell
Melbourne, Australia
25. Re: Detecting the Eu version
On Mon, 13 Dec 2004 19:02:26 -0800, Derek Parnell
<guest at rapideuphoria.com> wrote:
> > Still hoping Rob will at least comment on
> >
> > with 2.5
> >
> > and hoping he will agree the '.' will distinguish it adequately from
> > historical stamping statements.
>
> However this only deals with the situation in which the entire program
> is incompatible with an earlier version. To deal with the situation
> where only part of the code is imcompatible we might additionally need
> a run-time function to return the Euphoria version.
Well, perhaps this would occur in a large modular program, such as a
fancy IDE where the integrated debugger only worked for v2.5
onwards.... still, I think it'd be a bit rare.
> Which we could use as ...
> include version.e
> . . .
> procedure XYZZY()
> if version() >= 2.5 then
> . . .
> else
> . . .
> end if
> end procedure
In theory, ok. But what sort of incompatible code could there be?
AFAICS, the only differences would be syntax errors - new built-in
commands that were previously not supported, and new keywords (like
the '$'). The only way there could be run-time errors is if the
built-in functions returned a different set of data.
I know that 2.5 parses the entire thing first, so would't be able to
ignore the 'syntax errors' in branches not meant for it to execute,
but 2.4 doesn't work:
constant VERSION = 2.4
sequence t = {1,1,1,1,1,1,1,1}
if VERSION = 2.5 then
? t[2..$]
else
? t[2..length(t)]
end if
This code can't ignore the '$', despite the fact that it'll never be executed.
I think the only way that version-adaptive code could work is if
modules (includes) could be added dynamically depending on interpreter
version.
> Well, you get the idea...not exactly rocket science.
Maybe not, but it's still rather a curly problem.
--
MrTrick
26. Re: Detecting the Eu version
Patrick Barnes wrote:
>
> I think the only way that version-adaptive code could work is if
> modules (includes) could be added dynamically depending on interpreter
> version.
>
I agree with this, I have always wanted the ability to dynamically include
include files (sounds wierd when put like that).
if VERSION = 2.5 then
include lib25.e
else
include libold.e
end if
Of course this would mean that the code in the library that does not get
included is not parsed.
Dynamic inclusion would probably be easy with an interpreter, but may get
a bit tricky with a bound/shrouded program in some cases, like would you
have to include all the include files in the bound program just in case
whatever the trigger is for including that library, changes at some point!
See where it can get messy with the bound program?
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
27. Re: Detecting the Eu version
On Mon, 13 Dec 2004 20:34:47 -0800, Ferlin Scarborough
<guest at rapideuphoria.com> wrote:
> Dynamic inclusion would probably be easy with an interpreter, but may get
> a bit tricky with a bound/shrouded program in some cases, like would you
> have to include all the include files in the bound program just in case
> whatever the trigger is for including that library, changes at some point!
Well, perhaps it (for now) shouldn't be treated fully dynamically...
You could allow includes inside if-statements, as long as the
conditions must be able to be resolved at parse-time.
For instance:
if platform() = LINUX then
include linux_display.e
elsif platform() = WINDOWS then
include win_display.e
end if
platform() will *always* be known at parse-time, because it's a
stateless function built into the interpreter. Same with a 'version()'
call.
> See where it can get messy with the bound program?
If it's known at parse-time, it won't affect bound programs.
Executeables aren't meant to be platform-independant.
--
MrTrick
28. Re: Detecting the Eu version
Patrick Barnes wrote:
> If it's known at parse-time, it won't affect bound programs.
> Executeables aren't meant to be platform-independant.
I would have to agree with this, cause, no matter the language, except Java,
each program has to be "compiled" specifically on the "Target" system, due
to the diffrences in File I/O, and machine functions, just like with
Euphoria.
Again, this would have to come to having a pre-proccessor #define, #ifdef,
and #else, or such things, to allow Cross-Platform compatability, both in
Operating Systems, and In Euphoria Versions. But this would also mean, that
the feature would have to be implemented Now, or realitively soon, cause
otherwise, it will not be backwards compatable. Then again, I belive most
programmers here would agree, if this kind of functionality was implemented,
they would not go back to previous versions of Euphoria.
Mario
29. Re: Detecting the Eu version
Irv Mullins wrote:
> Igor Kachan wrote:
>
> >
> > Irv, it works for me just now, I just do not want run my program
> > with interpreter v2.4 if I got the error message that it requires 2.5
> > only. Then I just comment one line and run it on 2.5.
> >
> > Some people are strange here, it works just now, but they want
> > to force Rob to implement new feature, rewrite docs etc.
> > Then I need retranslate all these docs into Russian etc.
> >
> > For what? For a feature, which works fine just *now*?
>
> I suppose you are talking about your routine:
No, I am talking here about just an artificial syntax
error, which prevents user from useing of a wrong version
of interpreter and acts at compile-time:
with 2.5! <-- comment this line if your version is 2.5. See docs on
program.
> > > There is some universal method - all ex.exes, exw.exes, exus, ec.exes
> etc
> > > have the unique lengths.
> > >
> > > So, you can detect the version with something like to:
> > >
> > >
> > > global function version(sequence name, atom EXE_Length)
> > > name = machine_func(22, name) -- dir info
> > > if name[1][3] = EXE_Length then
> > > return 1
> > > else
> > > return 0
> > > end if
> > > end fubction
> > >
>
> Explain, please, how this is supposed to work after the
> file size of Euphoria 2.5 changes (as it certainly will, probably
> more than once, as Rob fixes bugs).
This function works at run-time on 2.5+ and may not do a job,
if its call stands *after* the place of a possible critical error.
Then, this function works on all pre-2.5 versions, just see
the size of used interpreter.
Say, I work with 2.3 ruphoria, my interpreter is 178551 bytes.
Same about any old version of interpreter.
See size, create your program, use function.
There is a huge heap of old interpreters in the World.
> Explain, please, how this allows "2.5 or better" to be implemented.
> Do you somehow know the file size(s) of all future versions of
> Euphoria?
I know nothing about future size(s).
But what a problem? Who cares?
No one can even program for some future interpreter.
But anyone can prevent improper useing of any
future version at compile-time with just an artificial
syntax error, described above.
Then, as a last trick - pay for binder and bind your
proggy to avoid your user's painful reaction. 
Regards,
Igor Kachan
kinz at peterlink.ru
30. Re: Detecting the Eu version
Pete Lomax wrote:
>
> On Tue, 14 Dec 2004 00:39:58 +0300, Igor Kachan <kinz at peterlink.ru>
> wrote:
>
> >Some people are strange here, it works just now, but they want
> >to force Rob to implement new feature, rewrite docs etc.
> >Then I need retranslate all these docs into Russian etc.
> >
> >For what? For a feature, which works fine just *now*?
>
> Jeurgen has wisely spotted a problem that *WILL* arise on the day 2.6
> is released, which ought to be addressed sooner not later.
I prefer to solve today problems at first.
> >Do you know, fc command gives about 600Kb file of differensies
> >in docs for 2.3 and for 2.5? 300 pages just to read.
>
>
> What??!! I suppose you would prefer 2.5 docs to be identical to 2.3?
> Stick with 2.3 then, don't try stopping us using new version.
No, I do like 2.5 very much, I'm working on docs, site, my programs etc.
2.5 is great. And *any* step on correction of RDS 2.5 must be
discussed from all sides.
I just thought this number - 300 pages - is useful thing to know.
But people like their old stable products. 2.3 PD ruphoria works for my
Russian users and for me. And 2.5 requires big efforts to make it Russian.
> >And the best way is to write a version independent code.
> I suppose we shouldn't use the new $ feature then. Rob's already used
> it at least 91 times that I know of in the standard package, and next
> release of win32lib may well have 700 instances of $, and why not.
Win32lib has its authors. Maybe, authors want Win32Lib to be compatible
with 2.4 or 2.3. Who knows?
We can do all we want now, with 2.5. Again, Great product.
> Regards,
> Pete
Regards,
Igor Kachan
kinz at peterlink.ru
31. Re: Detecting the Eu version
Mario Steele wrote:
> Patrick Barnes wrote:
>> If it's known at parse-time, it won't affect bound programs.
>> Executeables aren't meant to be platform-independant.
>
> I would have to agree with this, cause, no matter the language, except Java,
> each program has to be "compiled" specifically on the "Target" system, due
> to the diffrences in File I/O, and machine functions, just like with
> Euphoria.
>
> Again, this would have to come to having a pre-proccessor #define, #ifdef,
> and #else, or such things, to allow Cross-Platform compatability, both in
> Operating Systems, and In Euphoria Versions. But this would also mean, that
> the feature would have to be implemented Now, or realitively soon, cause
> otherwise, it will not be backwards compatable.
Yes, the feature would have to be implemented now in Eu 2.5. Otherwise
for the Eu 2.5 interpreter (as it currently is) *there is no other way
than crashing*, when it will try to run source code that contains
keywords which were introduced in Eu 2.6 or later.
<snip>
Regards,
Juergen
--
Have you read a good program lately?
32. Re: Detecting the Eu version
On Mon, 13 Dec 2004 19:02:26 -0800, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>> Still hoping Rob will at least comment on
>>
>> with 2.5
>>
>> and hoping he will agree the '.' will distinguish it adequately from
>> historical stamping statements.
>>
>
>However this only deals with the situation in which the entire program
>is incompatible with an earlier version. To deal with the situation
>where only part of the code is imcompatible we might additionally need
>a run-time function to return the Euphoria version.
Why? Is there something to prevent with statements in include files?
>I would suggest the machine_func() could be easily adapted for this
<snip>
> if version() >= 2.5 then
<snip>
It doesn't matter how you code it, it won't get executed in time.
(It was possible in 2.4, it is not in 2.5) The user will see eg:
C:\EUPHORIA\INCLUDE\FILE.E:183
Syntax error - expected to see an expression, not an illegal character
find(path_name[$], {' ', SLASH}) do
^
instead of:
This program requires Euphoria 2.7 or later.
OK, you can bind/translate and the problem goes away, but that may be
a problem for people releasing open source, and is no longer an option
for anyone releasing library components such as win32lib.
BTW, I am not asking for a single source which "needs" 2.5 to somehow
run on 2.4. Now that would be silly.
Regards,
Pete
33. Re: Detecting the Eu version
On Tue, 14 Dec 2004 10:57:06 +0000, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
> It doesn't matter how you code it, it won't get executed in time.
> (It was possible in 2.4, it is not in 2.5) The user will see eg:
>
> C:\EUPHORIA\INCLUDE\FILE.E:183
> Syntax error - expected to see an expression, not an illegal character
> find(path_name[$], {' ', SLASH}) do
This:
constant VERSION = 2.4
sequence t = {1,1,1,1,1,1,1,1}
if VERSION = 2.5 then
? t[2..$]
else
? t[2..length(t)]
end if
Doesn't even work in 2.4.
Distancing the branches enough so that 2.4 doesn't 'see' the problems
still requires a kludge, like putting them inside a function called by
the branch.
--
MrTrick
34. Re: Detecting the Eu version
On Tue, 14 Dec 2004 22:36:27 +1100, Patrick Barnes <mrtrick at gmail.com>
wrote:
>constant VERSION = 2.4
>sequence t = {1,1,1,1,1,1,1,1}
>if VERSION = 2.5 then
> ? t[2..$]
>else
> ? t[2..length(t)]
>end if
>
>Doesn't even work in 2.4.
You snipped this from my previous post:
BTW, I am not asking for a single source which "needs" 2.5 to somehow
run on 2.4. Now that would be silly.
35. Re: Detecting the Eu version
On Tue, 14 Dec 2004 12:25:43 +0000, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
> You snipped this from my previous post:
>
> BTW, I am not asking for a single source which "needs" 2.5 to somehow
> run on 2.4. Now that would be silly.
Yes, I know. I'm saying that even 2.4 sometimes parses statements that
it never executes.... so 2.5 (while changing to 'parses *all*
statements') isn't the point at which the problem starts, it probably
existed (partially) much further back.
--
MrTrick
36. Re: Detecting the Eu version
Derek Parnell wrote:
> Igor Kachan wrote:
<snip>
>> Ok, but no one knows how many hundred thousand dollars they got
>> using their Euphoria skills.
>
> How does "sweet F.A." translate into Russian?
Derek, now that I know you are a millionaire, may I humbly suggest that
you buy the Foster's brewery, and then send me free beer every week? ;o)
SCNR,
Juergen
37. Re: Detecting the Eu version
Patrick Barnes wrote:
> If I take a Eu2.5 program and try and run it on Eu2.3, it probably
> won't work. Fair enough. However, *why* doesn't it work? A *user* who
> encounters a problem caused by this won't know why it occurs. By being
> able to *require* a version, the interpreter can stop and say "Error,
> this program requires Euphoria version 2.5 or newer", which is much
> more helpful.
syntax error - expected to see an expression, not an
illegal character
s = s[2..$]
Indeed, the current results of running a 2.5 program on 2.4 give a
message as shown above. Now, for people who have some experience
with programming languages, that says nothing about 'not having the correct
version of Euphoria', instead it suggests that the programmer was careless,
and didn't test his code. So they might spend hours trying to 'debug' a
perfectly good program.
This is just silly, because Rob could have EASILY added versioning to
Euphoria at any time in the past. I would like to see Rob explain, in
terms that the average programmer could understand, why that was impossible,
and why it is still impossible.
Irv
^
38. Re: Detecting the Eu version
Pete Lomax wrote:
<snip>
> Jeurgen's main point was that version() wouldn't help, builtin or not.
I'm grateful for a post like this, because it proves that my original
post in this thread *is* understandable.
Regards,
Juergen
--
Math problems? Don't drink and derive.
39. Re: Detecting the Eu version
The easiest way would to be to embed a date in the interpeter
in a offcial format that is the date of the first issue of the
Alpha version of that interpeter.
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
40. Re: Detecting the Eu version
Bernie Ryan wrote:
>
>
> The easiest way would to be to embed a date in the interpeter
> in a offcial format that is the date of the first issue of the
> Alpha version of that interpeter.
>
>
> Bernie
It already is, but it's compressed ;^)
Actually, I think the easiest way is to include a library routine. That assumes
that any users will be using the same library files as their interpreter.
Best way is to include a version() function in the interpreter.
=====================================
Too many freaks, not enough circuses.
j.
41. Re: Detecting the Eu version
Juergen Luethje wrote:
[snip]
> Yes, the feature would have to be implemented now in Eu 2.5. Otherwise
> for the Eu 2.5 interpreter (as it currently is) *there is no other way
> than crashing*, when it will try to run source code that contains
> keywords which were introduced in Eu 2.6 or later.
Any program requires installing and testing, if it is set up
on a new machine.
Why not to have a forced artificial crash to avoid improper
future using of a given program?
Open code programs are for programmers, not for incompetent public.
> Regards,
> Juergen
Regards,
Igor Kachan
kinz at peterlink.ru
42. Re: Detecting the Eu version
Dear EUforum members to whom it may concern:
Please don't change the Subject of a thread
(unless there is an *important* reason)!
My e-mail client (and many other clients, too) allows to sort messages
by Subject, that makes it much easier to read this mailing list.
Also, RDS had built a useful feature into the EUforum web interface:
After clicking at the Subject of a message, you'll get the whole thread.
Even if you are not interested in these possibilities yourself, other
people here find them useful, so do not destroy them!
-> I changed "(no subject)" back to "Detecting the Eu version".
Jason Gade wrote:
> Alan Oxley wrote:
>> My reply:
>> You said it yourself - if the official is the only release, then the CRC
>> won't change? But consider if the convention of "2.5.01" is used,
>> or even (possibly less usable) return a string "Euphoria vx.x 12th December
>> 2004".
>>
>> Whats the problem with generating and storing a CRC for every release? There
>> are not THAT many! Why would you want to test for future versions, if
>> they don't exist..? The reason for testing is to ensure your code is
>> compatible with a feature that does not (yet) exist? Sorry, I don't get this.
>> Also, there is no reasons why two or more CRC's cannot return the same
>> EU version like "2.5" if what the CRC's identify are known bugfixes from Rob.
>>
>> I'd still like Rob to give us a proper function though, as first prize.
>> My suggestion is mostly aimed at testing for earlier releases without
>> having to change them.
>
> The problem is say you use a feature which is included in versions 2.8
> or later. You want to check to make sure you have *at least* version
> 2.8. You don't care if the user has 2.9, 3.1 or whatever. Since you
> can't tell if the CRC is going to be greater or less than the CRC for
> 2.8, you can only check for 2.8 *exactly*.
Yes, this is actually the problem when using a CRC, size of the EXE file
or something similar for implementing a version() function. There have
been much better suggestions in the past though, recently namely by
Derek and Pete.
However, starting with Eu 2.5, the problem has changed. A version()
function -- builtin or not -- wouldn't solve the problem any more. For
the Eu 2.5 interpreter (as it currently is) *there is no other way than
crashing*, when it will try to run source code that contains keywords
which were introduced in Eu 2.6 or later.
Whatever code you write in order to try to solve this problem, your
code will never be executed, because the program crashes beforehand.
This has been discussed previously in this thread. So it might be a
good moment now for some people, to test the cool feature that I
mentioned above: On the EUforum web interface, click at the subject,
and read the whole thread ...
> Euphoria is small enough, I think, to include the required interpreter
> and files to users. Also, binding or translating would work. For open
> source, you would just distribute a source tree like any other
> (executable) project would.
>
> The real problem, of course, comes in distributing libraries that you
> don't want to work only for the lowest common denominator. Libraries
> are the code that need to check versions somewhat reliably so they can
> give a meaningful message to the user of the library.
Right!
> (Of course, if the library user would read the docs...)
Are we talking about a low-level or a high-level language?
If Euphoria is a high-level language, then it should for instance say
something like:
Sorry, code in "thisprog.e" requires Euphoria version 2.5 or later.
Rather than:
syntax error - expected to see an expression, not an
illegal character
s = s[2..$]
^
Regards,
Juergen
--
Have you read a good program lately?
43. Re: Detecting the Eu version
Juergen Luethje wrote:
>
> Dear EUforum members to whom it may concern:
>
> Please don't change the Subject of a thread
> (unless there is an *important* reason)!
>
> My e-mail client (and many other clients, too) allows to sort messages
> by Subject, that makes it much easier to read this mailing list.
> Also, RDS had built a useful feature into the EUforum web interface:
> After clicking at the Subject of a message, you'll get the whole thread.
> Even if you are not interested in these possibilities yourself, other
> people here find them useful, so do not destroy them!
>
> -> I changed "(no subject)" back to "Detecting the Eu version".
Agreed. I usually only change the subject title when a thread forks to a
different subject but then I put something like [was: whatever].
> However, starting with Eu 2.5, the problem has changed. A version()
> function -- builtin or not -- wouldn't solve the problem any more. For
> the Eu 2.5 interpreter (as it currently is) *there is no other way than
> crashing*, when it will try to run source code that contains keywords
> which were introduced in Eu 2.6 or later.
> Whatever code you write in order to try to solve this problem, your
> code will never be executed, because the program crashes beforehand.
>
> This has been discussed previously in this thread. So it might be a
> good moment now for some people, to test the cool feature that I
> mentioned above: On the EUforum web interface, click at the subject,
> and read the whole thread ...
Right. I understood this and tried to clarify it for people who didn't.
So you would do this...
> > Euphoria is small enough, I think, to include the required interpreter
> > and files to users. Also, binding or translating would work. For open
> > source, you would just distribute a source tree like any other
> > (executable) project would.
> > The real problem, of course, comes in distributing libraries that you
> > don't want to work only for the lowest common denominator. Libraries
> > are the code that need to check versions somewhat reliably so they can
> > give a meaningful message to the user of the library.
>
> Right!
>
> > (Of course, if the library user would read the docs...)
>
> Are we talking about a low-level or a high-level language?
> If Euphoria is a high-level language, then it should for instance say
> something like:
>
> Sorry, code in "thisprog.e" requires Euphoria version 2.5 or later.
>
> Rather than:
>
> syntax error - expected to see an expression, not an
> illegal character
> s = s[2..$]
> ^
> Regards,
> Juergen
Obviously this would be the *best* solution. I don't have much hope for its
implementation.
The 'with 2.5' or whatever would have to be executed before the entire program
is parsed. It would have to be a compiler directive. Versions prior to 2.5
might still break as mentioned earlier in the thread but we would at least solve
the problem for future versions.
> --
> Have you read a good program lately?
>
>
=====================================
Too many freaks, not enough circuses.
j.
44. Re: Detecting the Eu version
Jason Gade wrote:
>
> Juergen Luethje wrote:
> > Are we talking about a low-level or a high-level language?
> > If Euphoria is a high-level language, then it should for instance say
> > something like:
> >
> > Sorry, code in "thisprog.e" requires Euphoria version 2.5 or later.
> >
> > Rather than:
> >
> > syntax error - expected to see an expression, not an
> > illegal character
> > s = s[2..$]
> > ^
> > Regards,
> > Juergen
>
> Obviously this would be the *best* solution. I don't have much hope for its
> implementation.
>
> The 'with 2.5' or whatever would have to be executed before the entire program
> is parsed.
> It would have to be a compiler directive. Versions prior to 2.5 might still
> break
> as mentioned earlier in the thread but we would at least solve the problem for
> future
> versions.
Correction: as long as versions 2.5 and up parse the entire file before
beginning execution it is the *only* solution other than ignoring syntax errors
at compile time.
> > --
> > Have you read a good program lately?
> >
> >
> =====================================
> Too many freaks, not enough circuses.
>
> j.
>
=====================================
Too many freaks, not enough circuses.
j.
45. Re: Detecting the Eu version
- Posted by Patrick Barnes <mrtrick at gmail.com>
Dec 14, 2004
-
Last edited Dec 15, 2004
On Tue, 14 Dec 2004 14:36:10 +0100, Juergen Luethje
> Derek, now that I know you are a millionaire, may I humbly suggest that
> you buy the Foster's brewery, and then send me free beer every week? ;o)
Blechh... nobody *in* Australia drinks Fosters, that's why we export it.
The Lord Nelson hotel in Sydney, perhaps? (microbrewery and pub, makes
very good beer)
--
MrTrick
46. Re: Detecting the Eu version
- Posted by Greg Haberek <ghaberek at gmail.com>
Dec 14, 2004
-
Last edited Dec 15, 2004
Fosters... Australian for "Blech" :)
~Greg
On Wed, 15 Dec 2004 08:38:51 +1100, Patrick Barnes <mrtrick at gmail.com> wrote:
>
> On Tue, 14 Dec 2004 14:36:10 +0100, Juergen Luethje
> > Derek, now that I know you are a millionaire, may I humbly suggest that
> > you buy the Foster's brewery, and then send me free beer every week? ;o)
>
> Blechh... nobody *in* Australia drinks Fosters, that's why we export it.
> The Lord Nelson hotel in Sydney, perhaps? (microbrewery and pub, makes
> very good beer)
> --
> MrTrick
>
>
47. Re: Detecting the Eu version
Me wrote:
> Juergen Luethje wrote:
>
> [snip]
>
> > Yes, the feature would have to be implemented now in Eu 2.5. Otherwise
> > for the Eu 2.5 interpreter (as it currently is) *there is no other way
> > than crashing*, when it will try to run source code that contains
> > keywords which were introduced in Eu 2.6 or later.
>
> Any program requires installing and testing, if it is set up
> on a new machine.
> Why not to have a forced artificial crash to avoid improper
> future using of a given program?
> Open code programs are for programmers, not for incompetent public.
Ok, there is the very old and good command in Euphoria - 'with'.
Try please :
with ! -- add here needed comments to guide user in proper direction
-- code to adjust
with ! -- add here other comments
-- code to adjust
You'll get crashes with the error messages:
unknown with/without option
with !-- your directional comments
Force user to correct your program as it is suitable
for concrete user's machine, platform, OS version,
videocard, processor speed, interpreter version,
needed EU libs, RAM size, HD size, start directory,
dll version, EUDIR, EUINC, cr/lf, cr, lf, EOF,
language, window size ... all you need to get your
program working and nice.
I think, EUPHORIA is a great language, JUST NOW, isn't it?
Thanks Juergen for your question!
Regards,
Igor Kachan
kinz at peterlink.ru
48. Re: Detecting the Eu version
Igor Kachan wrote:
>
> Me wrote:
>
> > Juergen Luethje wrote:
> >
> > [snip]
> >
> > > Yes, the feature would have to be implemented now in Eu 2.5. Otherwise
> > > for the Eu 2.5 interpreter (as it currently is) *there is no other way
> > > than crashing*, when it will try to run source code that contains
> > > keywords which were introduced in Eu 2.6 or later.
> >
> > Any program requires installing and testing, if it is set up
> > on a new machine.
> > Why not to have a forced artificial crash to avoid improper
> > future using of a given program?
> > Open code programs are for programmers, not for incompetent public.
>
> Ok, there is the very old and good command in Euphoria - 'with'.
> Try please :
>
> }}}
<eucode>
> with ! -- add here needed comments to guide user in proper direction
> -- code to adjust
> with ! -- add here other comments
> -- code to adjust
> </eucode>
{{{
>
> You'll get crashes with the error messages:
>
> unknown with/without option
> with !-- your directional comments
>
> Force user to correct your program as it is suitable
> for concrete user's machine, platform, OS version,
> videocard, processor speed, interpreter version,
> needed EU libs, RAM size, HD size, start directory,
> dll version, EUDIR, EUINC, cr/lf, cr, lf, EOF,
> language, window size ... all you need to get your
> program working and nice.
>
> I think, EUPHORIA is a great language, JUST NOW, isn't it?
>
> Thanks Juergen for your question!
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
>
>
You are right, Igor. I wish that Microsoft would include a feature like this in
Office so that I could manually edit the executable when I have the wrong version
of the operating system on my computer.
I tried the with example you printed above. I couldn't include a '!' in the
with statement unless I wanted the program to crash every time. Unless that is
what you intended.
=====================================
Too many freaks, not enough circuses.
j.
49. Re: Detecting the Eu version
Juergen Luethje wrote:
>
> Hi all,
>
> recently Derek and Pete (L) posted here some useful code, that allows
> a program to detect the current Eu version at runtime. I think it is
> especially helpful to use such a functionality in libraries, that
> require at least a particular Eu version.
>
I have been reading over this thread with interest, and it just occured to me
that maybe we could do something like this (just off the top of my head so the
code may not be exactly right.
sequence cmd
integer filenum
cmd=command_line()
filenum=open(cmd[1],"rb")
Then we could look for something like "Euphoria Interpreter 2.4", the message
that prints out when you type ex or exw without a file name.
Oh, wait a minute I don't think this would work either, seems to me I remember
that the Euphoria Interpreter programs are compressed.
Hmmm....Well, maybe this will get someone started in a direction that might
work, if they know how to do this with compressed programs.
Just a thought.
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
50. Re: Detecting the Eu version
Jason Gade wrote:
[snip]
> I tried the with example you printed above. I couldn't include a '!' in
the
> with statement unless I wanted the program to crash every time.
Why every time? Just once.
'with !' stands just to invoke crash and a suitable error message,
'unknown with/without option'.
Then you can see critical section of code, set needed parameter
and then comment the line with 'with !'.
Say, some machines have videocards with 1024x768 resolution,
but monitor is just 800x600. You can not *automatically*
detect this monitor's resolution to set up needed
videomode for user.
And I'd prefer to get forced crash to adjust program,
than to get lost synchronisation of monitor.
I set screen mode 800x600, comment that 'with !' and
your program runs on my machine.
Maybe, I do not understand you?
Regards,
Igor Kachan
kinz at peterlink.ru
51. Re: Detecting the Eu version
So many of you still don't understand the problem.
Let's assume that version 2.6 of euphoria introduces the use of % as an operator
for remainder.
Current code is:
puts(1, "2.5 or better")
atom a
a = remainder(35, 4)
---------
Example future code could be:
puts(1, "2.6 or better")
atom a
a = 35 % 4
Lets call these C and F for Current and Future.
The problem with version testing comes from the fact that
version 2.5 (and probably future versions) parse the entire
program before execution.
If you try to run F code on C it will never display the result
of the puts command because of % being a syntax error.
The interpreter will detect the error before you can run
ANYTHING. Including any version testing. The only
current method around this is to have 2 programs.
1. Program A tests version
2. If version good then Program A start Program B
3. Program B is the intended program.
Now, the problem with this layout should be obvious.
* Includes can't version test.
* Environment Settings.
* Includes can't version test
-----------------------------
A version dependant programs can't test for interpreter
version because of "parse all before execute any".
A secondary program that is not version dependant
must be used to test version before launch.
This means that individual includes that are version
dependant can NOT test the version.
-- Why do I care?
If I think write my program that requires version 2.4
and I include a file that requires version 2.5 and
another file that requires 2.3.
Then entire program must use most recent required
version. That is, the entire program requires at least
version 2.5.
* Environment Settings.
-----------------------------
You would expect to be able to just call the program
that you want to run using a system call or shell execute.
However, The end user may have decided to use version
2.4 to start the version testing program but 2.3 is the
registered version. Of course, you can test command_line()
to detect which is executed. Assuming any path was
provided on the command line. Then you also have to take
into account. PATH, EUDIR, EUINC, and I think there
is something else to worry about. A large number of things
have to be considered when attempting to ensure that the
version that you intend to run is indeed the version required.
And it is possible that the version that your tester is running
on may NOT be the version that you intend the main program
to run on. Or you may want to ensure that the version tester
is running on is the version that you intend the main program
to run on.
This concludes my lecture on the subject.
unkmar
52. Re: Detecting the Eu version
Lucius Hilley wrote:
> So many of you still don't understand the problem.
>
> Let's assume that version 2.6 of euphoria introduces the use of % as an
operator
> for remainder.
>
> }}}
<eucode>
> Current code is:
>
> puts(1, "2.5 or better")
> atom a
> a = remainder(35, 4)
>
> ---------
> Example future code could be:
>
> puts(1, "2.6 or better")
> atom a
> a = 35 % 4
> </eucode>
{{{
>
> Lets call these C and F for Current and Future.
> The problem with version testing comes from the fact that
> version 2.5 (and probably future versions) parse the entire
> program before execution.
>
> If you try to run F code on C it will never display the result
> of the puts command because of % being a syntax error.
Why never will ?
1. You can replace '%' to 'remainder'.
2. You can update interpreter.
3. You can do:
with ! -- this program runs with 2.6 or better,
comment these lines if your interpreter
is 2.6 or better, read docs.
puts(1, "2.6 or better")
atom a
a = 35 % 4
User just ed, comments forced crash and runs you program, if
his interpreter is 2.6 or better, or replaces '%' to 'remainder',
if he hates 2.6, then comments forced crash, runs adapted program.
> The interpreter will detect the error before you can run
> ANYTHING. Including any version testing. The only
> current method around this is to have 2 programs.
>
> 1. Program A tests version
> 2. If version good then Program A start Program B
> 3. Program B is the intended program.
Good idea about combined useing of 2.3 or 2.4 and 2.5+.
I like it. Thanks.
[snip]
Regards,
Igor Kachan
kinz at peterlink.ru
53. Re: Detecting the Eu version
Unkmar wrote:
>
> So many of you still don't understand the problem.
>
What we need is a Version function added to Euphoria that works something like
this:
version_message="This program requires Euphoria Version 2.5 or greater!"
if version("2.5") = 0 then
abort_parse()
abort(0)
end if
The version() function would check to see if the version running is less than
the version number passed to it, if so it would print the version_message on
the screen. The abort_parse() would tell the interpreter not to interpret
any further in the program. The interpreter would of course have to check to
see if you were using the version() function and parse it first.
Of course this would only work in the version of Euphoria that the version()
function was added to, and future versions, but this would not solve the
problem with earlier versions of Euphoria.
Just some wishful thinking I guess.
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
54. Re: Detecting the Eu version
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 15, 2004
-
Last edited Dec 16, 2004
Ferlin Scarborough wrote:
>
> Unkmar wrote:
> >
> > So many of you still don't understand the problem.
> >
>
> What we need is a Version function added to Euphoria that works something like
> this:
> }}}
<eucode>
> version_message="This program requires Euphoria Version 2.5 or greater!"
>
> if version("2.5") = 0 then
> abort_parse()
> abort(0)
> end if
> </eucode>
{{{
>
<snip>
Ferlin, the main pont is that version() will never be executed. The file is
parsed entirely first, so if newer versions have any syntax changes a
compile-time error will occur before any part of the program is executed.
Some people think that an acceptable solution is to cause a deliberate syntax
error that will then print a message and the end user will have to manually edit
the source to fix it.
The second solution is to add a 'stub' program that detects the interpreter
version and either executes it or exits with a message.
The best solution would be for RDS to include a compile-time directive to detect
the version and let the program act accordingly.
Can we let this thread die now? End users should get all proper files when a
program is distributed to them. Developers should read the docs and be aware of
what versions they need.
> Ferlin Scarborough
>
> Learn To Program Games in Free Courses At
> <a href="http://www.gameuniv.net">http://www.gameuniv.net</a>
>
> My Euphoria Home Page
> <a
> href="http://mywebpage.netscape.com/shadetreesoft">http://mywebpage.netscape.com/shadetreesoft</a>
>
=====================================
Too many freaks, not enough circuses.
j.
55. Re: Detecting the Eu version
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Dec 15, 2004
-
Last edited Dec 16, 2004
On Wed, 15 Dec 2004 11:16:29 -0800, Jason Gade
<guest at RapidEuphoria.com> wrote:
>Can we let this thread die now?
I tire of it too, but, sorry, one last suggestion:
sequence v v={1}
v[$]=1 -- This program requires Euphoria 2.5 or later
Pete
PS. What I can't understand is why Rob is being so stubborn about
this. Why wouldn't he want to encourage the use of new features and
people to release programs, libraries, etc, with friendly messages
which encourage other users to install the latest version of Eu?
Maybe he is one (of several) that don't understand the problem.
56. Re: Detecting the Eu version
- Posted by Derek Parnell <ddparnell at bigpond.com>
Dec 15, 2004
-
Last edited Dec 16, 2004
Jason Gade wrote:
[snip]
> Can we let this thread die now? End users should get all proper files when a
> program
> is distributed to them. Developers should read the docs and be aware of what
> versions
> they need.
I would like these questions answered ...
a) Do I update win32lib to use '$'? I'd like to because it is so useful.
b) If so, do I keep two versions of the source? One for 2.4 and one for 2.5
c) If I keep two versions, how can I keep them synchronized? Use a preprocessor?
d) If I don't keep two versions, how can I support people who will not upgrade
to 2.5?
e) Should I wash my hands of the whole lot and just make it somebody else's
problem?
--
Derek Parnell
Melbourne, Australia
57. Re: Detecting the Eu version
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 15, 2004
-
Last edited Dec 16, 2004
Derek Parnell wrote:
>
> Jason Gade wrote:
>
> [snip]
>
> > Can we let this thread die now? End users should get all proper files when
> > a program
> > is distributed to them. Developers should read the docs and be aware of
> > what versions
> > they need.
>
> I would like these questions answered ...
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
Umm... even if RDS included a proper control measure what would you do? Include
both length() and [$] in the same source?
> b) If so, do I keep two versions of the source? One for 2.4 and one for 2.5
I guess you would have to freeze the version that supports 2.4. Either that or
not use the new feature.
> c) If I keep two versions, how can I keep them synchronized? Use a
> preprocessor?
It would be a kludge, but I guess that would work.
> d) If I don't keep two versions, how can I support people who will not upgrade
> to 2.5?
You don't. (see (b) above)
> e) Should I wash my hands of the whole lot and just make it somebody else's
> problem?
I really don't know the answer to that.
Like Igor said, Euphoria is very good. But there are just a lot of little
niggles that need to be fixed. We can either fix them ourselves and have a
slower interpreter, or we can just live with the things that Rob won't change.
Don't get me wrong -- I agree with you here. RDS should implement some
version() control measure that can be tested without crashing the program. I'm
just also trying to suggest workarounds in face of the fact that RDS' silence
means that he probably won't change it. Also it would be harder to add something
like that now that source files are parsed completely before execution.
One thought that I've had recently is that it would be great if people who have
earned EUbucks on code they have written could pledge those EUbucks back to RDS
in exchange for feature changes. I think that the opinions of people like you
and Dave Cuny and others who have contributed so much to the community are worth
a lot more than mine, who has never registered nor written that much code.
>
> --
> Derek Parnell
> Melbourne, Australia
>
=====================================
Too many freaks, not enough circuses.
j.
58. Re: Detecting the Eu version
- Posted by cklester <cklester at yahoo.com>
Dec 15, 2004
-
Last edited Dec 16, 2004
Derek Parnell wrote:
>
> I would like these questions answered ...
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
No. $ is not compatible among all current versions of Euphoria, whereas
length(my_seq) is. And, since 2.5 is still only alpha, please don't use
it for libraries people! (That includes you, Tommy. :))
> b) If so, do I keep two versions of the source? One for 2.4 and one for 2.5
If you do "upgrade" the code to use $, then I would ask nicely that you keep
two versions. (What a pain, though!)
> c) If I keep two versions, how can I keep them synchronized? Use a
> preprocessor?
That's up to you. :P
> d) If I don't keep two versions, how can I support people who will not upgrade
> to 2.5?
You might not be able to. Ultimately, you may decide to post on your door:
"Upgrade or lose out."
> e) Should I wash my hands of the whole lot and just make it somebody else's
> problem?
Only if you want to take the road more traveled. :) I feel so feelosophical.
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
59. Re: Detecting the Eu version
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 15, 2004
-
Last edited Dec 16, 2004
Derek Parnell wrote:
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
The funny thing is (that is, funny-sad or funny-ironic) I think that it was
Derek who suggested the [$] notation in the first place...
> --
> Derek Parnell
> Melbourne, Australia
>
=====================================
Too many freaks, not enough circuses.
j.
60. Re: Detecting the Eu version
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Dec 15, 2004
-
Last edited Dec 16, 2004
cklester wrote:
> Derek Parnell wrote:
>>
>> I would like these questions answered ...
>> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
>
> No. $ is not compatible among all current versions of Euphoria, whereas
> length(my_seq) is. And, since 2.5 is still only alpha,
... and since the 2.5 interpreter has a rather long startup-time, which
makes usage of Win32Lib unbearable (not only) on my PC,
> please don't use
> it for libraries people! (That includes you, Tommy. :))
I second this wish.
<snip>
Regards,
Juergen
--
/"\ ASCII ribbon campain | This message has been ROT-13 encrypted
\ / against HTML in | twice for higher security.
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
61. Re: Detecting the Eu version
- Posted by Ferlin Scarborough <ferlin1 at bellsouth.net>
Dec 15, 2004
-
Last edited Dec 16, 2004
Jason Gade wrote:
>
> Ferlin, the main pont is that version() will never be executed. The file is
> parsed
> entirely first, so if newer versions have any syntax changes a compile-time
> error will
> occur before any part of the program is executed.
>
<snip>
Jason,
I understand this completely, but you sniped the part of my message where I
stated that:
The interpreter would of course have to check to see if you
were using the version() function and "parse it first."
My point being that if you were using the version() function the interpreter
could parse it, then return a 1 if the version is what you passed the function
or greater or return a 0 if the version is lower than what you passed to the
function and print a message supplied by the programmer. Then you could use
a command such as abort_parse() to tell the interpreter do stop parsing the
rest of the program and abort. I placed an abort(0) after that command, but
the abort_parse() command could abort the program for you.
I had the version() function return with out aborting the program, so the
programmer could add additional messages or do some other processing, also,
maybe in the future if something along the lines of dynamic includes was added
to Euphoria the programmer could dynamically include a library based on rather
the version() function passed or failed. (I know dynamic includes will probably
never be added to Euphoria) but there may be something in the future that would
require the programmer to do additional processing after the version() function
check.
Do you see where I was coming from now? :)
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
62. Re: Detecting the Eu version
Derek Parnell wrote:
>
<snip>
> I would like these questions answered ...
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
> b) If so, do I keep two versions of the source? One for 2.4 and one for 2.5
> c) If I keep two versions, how can I keep them synchronized? Use a
> preprocessor?
> d) If I don't keep two versions, how can I support people who will not upgrade
> to 2.5?
> e) Should I wash my hands of the whole lot and just make it somebody else's
> problem?
>
> --
> Derek Parnell
> Melbourne, Australia
>
Derek,
I agree with what Jason said about freezing the version. If you would like to
use the '$' then go ahead, after all you are the programmer. Just freeze a
copy of the Win32Lib that works with 2.4, and on the Web Site, make a note
that the version for pre Euphoria 2.5 does not have the latest updates.
I see nothing wrong with upgrading Euphoria to 2.5, the biggest complaint
seems to be that the start up time is too slow, but Rob has already noted
that he has done improvements on the speed issue in the upcoming Beta release.
People can wait and see, but personally the increased start up time due to
the interpreter pre-parsing the whole program does not bother me, as the
program runs faster once it is up and running, which is where the speed matters
the most any way, most of your Bigger Commercial products such as Word
Processors,
Adobe Acrobat, Photoshop etc... take a while to start up, but you don't hear
any complaints about that from the users.
Just my .02
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
63. Re: Detecting the Eu version
Ferlin Scarborough wrote:
>
> Jason Gade wrote:
> >
> > Ferlin, the main pont is that version() will never be executed. The file is
> > parsed
> > entirely first, so if newer versions have any syntax changes a compile-time
> > error will
> > occur before any part of the program is executed.
> >
> <snip>
>
> Jason,
>
> I understand this completely, but you sniped the part of my message where I
> stated that:
>
> The interpreter would of course have to check to see if you
> were using the version() function and "parse it first."
>
> My point being that if you were using the version() function the interpreter
> could parse it, then return a 1 if the version is what you passed the function
> or greater or return a 0 if the version is lower than what you passed to the
> function and print a message supplied by the programmer. Then you could use
> a command such as abort_parse() to tell the interpreter do stop parsing the
> rest of the program and abort. I placed an abort(0) after that command, but
> the abort_parse() command could abort the program for you.
>
> I had the version() function return with out aborting the program, so the
> programmer could add additional messages or do some other processing, also,
> maybe in the future if something along the lines of dynamic includes was added
> to Euphoria the programmer could dynamically include a library based on rather
> the version() function passed or failed. (I know dynamic includes will
> probably
> never be added to Euphoria) but there may be something in the future that
> would
> require the programmer to do additional processing after the version()
> function
> check.
>
> Do you see where I was coming from now? :)
>
> Later.
>
> Ferlin Scarborough
>
> Learn To Program Games in Free Courses At
> <a href="http://www.gameuniv.net">http://www.gameuniv.net</a>
>
> My Euphoria Home Page
> <a
> href="http://mywebpage.netscape.com/shadetreesoft">http://mywebpage.netscape.com/shadetreesoft</a>
>
Sorry, I missed where you said that it had to parse and execute the version()
statement first. I still don't understand how you would do that. I mean, the
parser could pick up the version() statement and then what? There would have to
be specific compiler directives designed for this.
I guess that version(ver, message) could be a compiler directive that checked
ver against the (built-in) version and printed message and exited if it was
greater.
Right now the only compiler directive in the interpreter is 'with/without'. Of
course, they actually emit their own opcodes but they could be adapted to this
purpose.
Another way to handle it would be for the interpreter to defer all errors until
runtime. A built-in version() function would work then the way people want it
to. But it might make some kinds of bugs more difficult to find.
The more we hash this out, the less relevant I think that it is. Derek brought
up the point when he asked if he should use the [$] feature in win32lib or not.
How would that work even with a good version statement? You either would have to
write parallel code a la c type #ifdef or exit with a friendly message telling
the user to upgrade.
It seems like we're dealing with two issues: Crashing in a way that the user
knows it is a version error instead of trying to track down a syntax error, and
writing robust libraries that work across different versions of the interpreter
and are able to take advantage of new features.
=====================================
Too many freaks, not enough circuses.
j.
64. Re: Detecting the Eu version
Jason Gade wrote:
>
> Another way to handle it would be for the interpreter to defer all errors
> until runtime.
> A built-in version() function would work then the way people want it to. But
> it might
> make some kinds of bugs more difficult to find.
>
> The more we hash this out, the less relevant I think that it is. Derek
> brought up
> the point when he asked if he should use the [$] feature in win32lib or not.
> How would
> that work even with a good version statement? You either would have to write
> parallel
> code a la c type #ifdef or exit with a friendly message telling the user to
> upgrade.
>
> It seems like we're dealing with two issues: Crashing in a way that the user
> knows
> it is a version error instead of trying to track down a syntax error, and
> writing robust
> libraries that work across different versions of the interpreter and are able
> to take
> advantage of new features.
>
I agree completely Jason. So, now I will make this my last message on this
thread so that it can have a chance to die out. Seems like it has been done
to death already.
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
65. Re: Detecting the Eu version
Ferlin Scarborough wrote:
>
> Jason Gade wrote:
> >
> > Another way to handle it would be for the interpreter to defer all errors
> > until runtime.
> > A built-in version() function would work then the way people want it to.
> > But it might
> > make some kinds of bugs more difficult to find.
> >
> > The more we hash this out, the less relevant I think that it is. Derek
> > brought up
> > the point when he asked if he should use the [$] feature in win32lib or not.
> > How would
> > that work even with a good version statement? You either would have to
> > write parallel
> > code a la c type #ifdef or exit with a friendly message telling the user to
> > upgrade.
> >
> > It seems like we're dealing with two issues: Crashing in a way that the
> > user knows
> > it is a version error instead of trying to track down a syntax error, and
> > writing robust
> > libraries that work across different versions of the interpreter and are
> > able to take
> > advantage of new features.
> >
>
> I agree completely Jason. So, now I will make this my last message on this
> thread so that it can have a chance to die out. Seems like it has been done
> to death already.
>
> Later.
>
> Ferlin Scarborough
>
> Learn To Program Games in Free Courses At
> <a href="http://www.gameuniv.net">http://www.gameuniv.net</a>
>
> My Euphoria Home Page
> <a
> href="http://mywebpage.netscape.com/shadetreesoft">http://mywebpage.netscape.com/shadetreesoft</a>
>
Okay. Even though I wanted to kill this thread a few hours ago my interest is
piqued now that I see more nuance in it. How do other languages handle this
situation? Most of us know how C/C++ handles it (with #ifdef). What about
Python, Ruby, Lua, or Perl?
=====================================
Too many freaks, not enough circuses.
j.
66. Re: Detecting the Eu version
Jason Gade wrote:
[snip]
> Okay. Even though I wanted to kill this thread a few hours ago my interest is
> piqued
> now that I see more nuance in it. How do other languages handle this
> situation? Most
> of us know how C/C++ handles it (with #ifdef). What about Python, Ruby, Lua,
> or Perl?
The D language has a 'version()' directive which is very versitile.
if version(2.5) {
.. . .
}
else
{ . . . }
But you can also do things like ...
if version(myspecial) { }
On the command line you can do ...
dmd -version=myspecial
And even inside the code you can do ...
version = abc;
. . .
if version(abc) { }
It's great for temporarily commenting out nested lines...
if version(COMMENTOUT) {
int a = 1;
if version(COMMENTOUT) {
float b = 2.3;
}
}
The 'version()' is processed by the parser and thus you can get it
to include or exclude compilable code in a very flexible and intuitive
manner; so don't expect this from RDS anytime soon.
--
Derek Parnell
Melbourne, Australia
67. Re: Detecting the Eu version
cklester wrote:
>
> Derek Parnell wrote:
> >
> > I would like these questions answered ...
> > a) Do I update win32lib to use '$'? I'd like to because it is so useful.
>
> No. $ is not compatible among all current versions of Euphoria, whereas
> length(my_seq) is. And, since 2.5 is still only alpha, please don't use
> it for libraries people! (That includes you, Tommy. :))
1. We asked for $, we got it, and now we can't use it?
2. I decided to use $, because I don't expect Win4Eu to be released
very soon, and by the time it will be released, Eu 2.5 will probably
also be released (or at least in beta). Besides, it's also to stimulate
people to use 2.5, because I think that 2.5 has some nice potential.
Although it doesn't have many new visible features yet, the whole underlying
architecture has changed. Maybe it's a bit slow right now, but it's also
a first alpha version. And Robert reported that the version he's working on
is already a lot faster.
--
The Internet combines the excitement of typing
with the reliability of anonymous hearsay.
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
68. Re: Detecting the Eu version
> Subject: Re: Detecting the Eu version
>
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Jason Gade wrote:
>
> [snip]
>
>> Can we let this thread die now? End users should get all proper files when a
>> program
>> is distributed to them. Developers should read the docs and be aware of what
>> versions
>> they need.
>
> I would like these questions answered ...
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
It is useful, but 2.5 as it stands now comes with a lot of problems when
executing a program using large libraries, so that I, as quite a few others I
think, didn't switch to 2.5 yet. After all, there's only one useful feature
extra (for me - I'm not saying that crash_routine() is not an improvement, it
is, but I have scant use for it) in 2.5, whch does not offest the drawbacks.
So I'd say: use $ and make up your mind about the problems this approach will
generate.
Perhaps the point becomes moot with 2.5 beta, but my crystal ball is so misty...
> b) If so, do I keep two versions of the source? One for 2.4 and one for 2.5
Probably the best route to go.
> c) If I keep two versions, how can I keep them synchronized? Use a
> preprocessor?
Code using $, then run a preprocessor to get a 2.4-compatible separate file.
This part in my idEu preprocessor works, I email it to you if you wish.
Actually I'll have to mod the code a bit, as it first converts $ to -1 and
then converts negative indexes to regular ones, but that must not be too hard.
> d) If I don't keep two versions, how can I support people who will not upgrade
> to 2.5?
You wouldn't be able to.
> e) Should I wash my hands of the whole lot and just make it somebody else's
> problem?
If it's too bothersome to downgrade $ to length(<previous sequence>), somebody
else can do it. And well... that's your own decision really.
Just my thoughts.
CChris
>
> --
> Derek Parnell
> Melbourne, Australia
69. Re: Detecting the Eu version
Derek Parnell wrote:
> Jason Gade wrote:
>
> [snip]
>
> > Can we let this thread die now? End users should get all proper files
when a program
> > is distributed to them. Developers should read the docs and be aware
of what versions
> > they need.
>
> I would like these questions answered ...
> a) Do I update win32lib to use '$'? I'd like to because it is so useful.
Why not? The full featured for developer Euphoria 2.5 is Public Domain.
Anyone can trace, debug, translate to =F3, compile with C any program
of any size for free. If you do not like RDS message about themselves,
you can upgrade translator for free if you have 2.4CE, or for $29.
See please http://www.RapidEuphoria.com/reg.htm for details.
Plus you can use $-like feature of Euphoria great types with 2.5, 2.4,
2.3 etc, if you do not hate it, of course.
> b) If so, do I keep two versions of the source? One for 2.4 and one for
2.5
> c) If I keep two versions, how can I keep them synchronized? Use a
preprocessor?
> d) If I don't keep two versions, how can I support people who will not
upgrade to 2.5?
> e) Should I wash my hands of the whole lot and just make it somebody
else's problem?
Who is an author of win32lib? You or we? This is just an author's duty
to think about the product's best future, I think, sorry.
RDS have done their job on 2.5, sure.
We can do all we want at all to make
our money with PD Euphoria now.
Good Luck!
Regards,
Igor Kachan
kinz at peterlink.ru
70. Re: Detecting the Eu version
Derek Parnell wrote:
>
> Jason Gade wrote:
>
> [snip]
>
> > Okay. Even though I wanted to kill this thread a few hours ago my interest
> > is piqued
> > now that I see more nuance in it. How do other languages handle this
> > situation? Most
> > of us know how C/C++ handles it (with #ifdef). What about Python, Ruby,
> > Lua, or Perl?
>
> The D language has a 'version()' directive which is very versitile.
>
> if version(2.5) {
> .. . .
> }
> else
> { . . . }
>
> But you can also do things like ...
>
> if version(myspecial) { }
>
> On the command line you can do ...
>
> dmd -version=myspecial
>
> And even inside the code you can do ...
>
> version = abc;
> . . .
> if version(abc) { }
>
> It's great for temporarily commenting out nested lines...
>
> if version(COMMENTOUT) {
> int a = 1;
> if version(COMMENTOUT) {
> float b = 2.3;
> }
> }
>
> The 'version()' is processed by the parser and thus you can get it
> to include or exclude compilable code in a very flexible and intuitive
> manner; so don't expect this from RDS anytime soon.
>
> --
> Derek Parnell
> Melbourne, Australia
>
Yeah, I was aware of D's version() feature... it's pretty cool. But you would
still have to write parallel code to implement future features while retaining
backward compatability. It is still a very useful thing, though.
=====================================
Too many freaks, not enough circuses.
j.
