1. win32lib 0.70+ and Euphoria 3.0-
win32lib v0.60.x has been compatible with Euphoria 2.3 and later.
win32lib v0.70.1 and more have departed from this in a minor way. Commenting out
the two calls to task_yield() in win32lib.ew restores the correct working of the
library.
However, there is a question to ask.
Since Euphoria has changed since v2.4, and hopefully will keep adding new
features (though I have my doubts), it might be high time win32lib benefits from
the changes. Currently, to my knowledge, there are two options:
1a/ Declare that, from v0.70.1 on, win32lib is not compatible with versions of
Euphoria earlier than 3.0. This will allow $ and task_yield() in, but not
find_from(), match_from() or anything that might come in the future. This one
would have my vote.
1b/ Declare that, from v0.70.1 on, win32lib is compatible with the version of
Euphoria that is officially available at release time. This will allow $,
task_yield(), find_from(), match_from() in, as well as anything that might come
in the future. This one would have my vote.
2/ Allow only task_yield() in, and restore compatibility for v2.3 and 2.4. Users
of 2.5 alpha and official will still have to comment out the two statements,
unless someone knows how to parse code conditionally to interpreter version in Eu
2.5 and later. The late (r3 I think) 2.5 version supports task_yield() and thus
has no problems.
Very unfortunately, RDS had made no provision to test whether a given keyword
was supported otherwise than by crashing at compile time: whatever test is used,
the interpreter will barf at the unknown identifier. A version() function that
would work like platform() does would be useful in the future, but won't solve
issues from the past. (Under v2.4 and less, it can be implemented using the
dynamical include file contents trick). This definitely hampers efforts by
programmers to ensure some degree of backward compatibility.
3/ Of course, not allowing task_yield() in is ruled out.
What to do?
CChris
By the way, a 70.4 version might be ready somewhere in february. Some bug fixes
and a slew of small additions/enhancements left out from the to-do list for 70.3.
Field testing might start as soon as next weekend.
2. Re: win32lib 0.70+ and Euphoria 3.0-
- Posted by Andy Drummond <andy at kes??eltele.com>
Jan 15, 2008
-
Last edited Jan 16, 2008
CChris,
My vote would be to have Win32Lib to use any capability of Euphoria 3 & ff,
so that it would not be compatible with any earlier Euphoria. Euphoria is free
so no-one should need to develop new code for an old Euphoria.
To use features available in various flavours of Eu 3 but not others would
probably cause confusion at some point.
Andy
3. Re: win32lib 0.70+ and Euphoria 3.0-
CChris wrote:
>
> 1b/ Declare that, from v0.70.1 on, win32lib is compatible with the version
> of Euphoria that is officially available at release time. This will allow
> $, task_yield(), find_from(), match_from() in, as well as anything that
> might come in the future. This one would have my vote.
Join the 21st Century! I vote for 1b. I think that it makes sense to use
the full capabilities of the language. If there is interest, someone could
maintain a backwards compatible branch of the code. I know there are a few
die hards out there who still use older versions, but I think that there are
some really nice improvements that have been made since then that make it
easier/nicer to code in euphoria.
I haven't dabbled in win32lib in some time, but I wouldn't be surprised to
find that there were some good uses for the new peek/poke routines.
Matt
4. Re: win32lib 0.70+ and Euphoria 3.0-
Matt Lewis wrote:
>
> CChris wrote:
> >
> > 1b/ Declare that, from v0.70.1 on, win32lib is compatible with the version
> > of Euphoria that is officially available at release time. This will allow
> > $, task_yield(), find_from(), match_from() in, as well as anything that
> > might come in the future. This one would have my vote.
>
> Join the 21st Century! I vote for 1b. I think that it makes sense to use
> the full capabilities of the language. If there is interest, someone could
> maintain a backwards compatible branch of the code. I know there are a few
>
> die hards out there who still use older versions, but I think that there are
> some really nice improvements that have been made since then that make it
> easier/nicer to code in euphoria.
>
> I haven't dabbled in win32lib in some time, but I wouldn't be surprised to
> find that there were some good uses for the new peek/poke routines.
>
> Matt
Among other things, w32memory.ew documents w32peek2(), w32poke_words() and
w32peek_string16(). Guess what they do :p More generally, check all memory data
types that start in u or U.
CChris
5. Re: win32lib 0.70+ and Euphoria 3.0-
Matt Lewis wrote:
>
> CChris wrote:
> >
> > 1b/ Declare that, from v0.70.1 on, win32lib is compatible with the version
> > of Euphoria that is officially available at release time. This will allow
> > $, task_yield(), find_from(), match_from() in, as well as anything that
> > might come in the future. This one would have my vote.
>
> Join the 21st Century! I vote for 1b. I think that it makes sense to use
> the full capabilities of the language. If there is interest, someone could
> maintain a backwards compatible branch of the code. I know there are a few
>
> die hards out there who still use older versions, but I think that there are
> some really nice improvements that have been made since then that make it
> easier/nicer to code in euphoria.
>
Unfortunately, it is not always that simple, because there are regressions in
Euphoria.
The most obvious one is that, under 2.4 and earlier, you could define at run
time the contents of a file to be included, which was a way to implement dynamic
code. A little unwieldy at times, but it worked. This feature disappeared with
2.5. Try defining the contents of a file before including it: this is legal, but
the file has been read and parsed before the statements that set its contents are
executed. Hence you need two Eu programs, one to set the file contents and then
the main program. And it gets messier if the two processes need to exchange
information. A typical application is when include files are different depending
on some hardware/OS configurartion, and the main program also needs the info.
Again, it can be done using editor scripts to update the main program before
running it, but this is definitely harder than the previous way.
CChris
> I haven't dabbled in win32lib in some time, but I wouldn't be surprised to
> find that there were some good uses for the new peek/poke routines.
>
> Matt
6. Re: win32lib 0.70+ and Euphoria 3.0-
CChris wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> > >
> > I haven't dabbled in win32lib in some time, but I wouldn't be surprised to
> > find that there were some good uses for the new peek/poke routines.
> >
> > Matt
>
> Among other things, w32memory.ew documents w32peek2(), w32poke_words() and
> w32peek_string16().
> Guess what they do :p More generally, check all memory data types that start
> in u or U.
>
Wow good for you, most of my library programs have contained peek2, poke2, ansi
and unicode
strings for the last 7 years.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
