1. New features besides tasking
So, Rob. Are there any other new features or improvements that you are working
that you would like to share with us? Besides the great new tasking feature?
Maybe some new control structures like continue or case? Or an exception
handling mechanism? A built-in string type? Any changes to the include mechanism
besides what has already been discussed? A version-checking statement?
What about the next version after this? You haven't updated the new features/bug
page in awhile.
Not to advocate anything in particular, I was just wondering and I notice that
the list has been pretty dead the last couple of days.
You had suggested adding the bfind() function to the ESL. Seeing the (lack of)
progress of ESL and the possible utility of the function, could it be added to
sort.e or some other appropriate place?
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
2. Re: New features besides tasking
Jason Gade wrote:
>
> So, Rob. Are there any other new features or improvements that you are working
> that you would like to share with us? Besides the great new tasking feature?
Oh, and adding support for DOS long filenames in Euphoria built-ins.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: New features besides tasking
Jason Gade wrote:
> So, Rob. Are there any other new features or improvements that you are working
> that you would like to share with us? Besides the great new tasking feature?
>
> Maybe some new control structures like continue or case? Or an exception
> handling
> mechanism? A built-in string type? Any changes to the include mechanism
> besides
> what has already been discussed? A version-checking statement?
>
> What about the next version after this? You haven't updated the new
> features/bug
> page in awhile.
>
> Not to advocate anything in particular, I was just wondering and I notice that
> the list has been pretty dead the last couple of days.
>
> You had suggested adding the bfind() function to the ESL. Seeing the (lack of)
> progress of ESL and the possible utility of the function, could it be added
> to sort.e or some other appropriate place?
I think the first thing I need is a way to organize all these
feature requests, so I don't lose track of them, and so we
don't keep starting up the same discussion at the beginning
every few months.
I posted a message on the Open Watcom forum about the
"flipping to full-screen" problem. No response yet.
I spent a great deal of time yesterday studying the
machine code that Watcom (10.6) is giving me in the inner
part of the interpreter. I found a couple of trivial
changes I could make in the C code that greatly
improved the machine code generated across many ops.
I'm not sure how much of this is an improvement over 2.5 official,
versus how much just restores some speed that was
lost since then. I'm going to continue working on that
for a while before looking at new features.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: New features besides tasking
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com>
Feb 18, 2006
-
Last edited Feb 19, 2006
>
> Jason Gade wrote:
> > So, Rob. Are there any other new features or improvements that you are
> > working
> > that you would like to share with us?
<clip>
> >
> > You haven't updated the new features/bug
> > page in awhile.
> >
> > You had suggested adding the bfind() function to the ESL. Seeing the (lack
> > of)
> > progress of ESL and the possible utility of the function, could it be added
> > to sort.e or some other appropriate place?
>
Robert Craig wrote:on 2006 Feb 18 18:47:
> I think the first thing I need is a way to organize all these
> feature requests, so I don't lose track of them, and so we
> don't keep starting up the same discussion at the beginning
> every few months.
Exactly! Oh, what a difference a couple of weeks makes:
Ken Rhodes wrote on 2006 Feb 2 3:09:
> I was thinking that you could make "suggestions" a
> link to email you or to a recommendation entry form of some sort.
> The point being to facilitate the gathering and organizing
> suggestions and feedback/suggestions. I suppose you could
> set up a similar link to automate bug reports. You could
> add these feedback links to the EUforum monthly reminder posts.
Robert Craig's reply: 2006 Feb 2 18:16
>I'm vaguely aware of the need for a more organized bug tracking
>and suggestion system. But given a choice, I would rather spend my
>time working on the many worthwhile suggestions and bug fixes that
>I already have, rather than organizing, discussing, and soliciting
>lots of new ones. (brilliant ideas excepted of course!)
>I imagine Junko or I will do something in this area eventually.
>For now, if you have an idea, just post it here on EUforum.
Some type of suggestions/feature request/bug report database system
might save RDS as well a the community of Euphoria users a great
deal of time - and reduce the amount of futile "noise" in the
EUforum. I'd suggest that such a database include a section
sumarizing your essential vision of Euphoria and listing such
features that you will not, or you are highly unlikey to implement.
As it stands now, we "keep starting up the same discussion
at the beginning every few months".
Ken Rhodes
100% MicroSoft Free
SuSE Linux 10.0
No AddWare, SpyWare, or Viruses!
Life is Good 
5. Re: New features besides tasking
Robert Craig wrote:
>
> I'm going to continue working on that
> for a while before looking at new features.
>
Hello Robert,
I hope one of the new features you do implement is non-blocking support.
This is one feature that EU desperately needs, and almost everyone here
would benefit from this much needed feature.
---- C Bouzy
----If you continue to do what you have always done,
you will get what you have always gotten.----
6. Re: New features besides tasking
C Bouzy wrote:
>
> Robert Craig wrote:
> >
> > I'm going to continue working on that
> > for a while before looking at new features.
> >
> Hello Robert,
>
> I hope one of the new features you do implement is non-blocking support.
> This is one feature that EU desperately needs, and almost everyone here
> would benefit from this much needed feature.
>
> ---- C Bouzy
>
>
> ----If you continue to do what you have always done,
> you will get what you have always gotten.----
Please pardon my ignorance.
How would the interpreter implement this? I know Windows and Linux have
asynchronous I/O functions. I know for copying and disk routines, anyway.
Probably for network routines as well.
Maybe by making the interpreter thread-safe with regards to call-backs would
solve the problem. How else would the problem be solved? What other interpreted
languages have this? I'm sure Java does, but I'm not sure about others.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
7. Re: New features besides tasking
- Posted by Vincent <darkvincentdude at yahoo.com>
Feb 19, 2006
-
Last edited Feb 20, 2006
Robert Craig wrote:
> I posted a message on the Open Watcom forum about the
> "flipping to full-screen" problem. No response yet.
I saw that. I spent several hours trying to figure this out for you. No success.
I looked at all the compiler and linker options and even read the compiler
documentation.
I'll post it on there for you again, so they'll know that we don't wish to be
ignored. However even if the problem can't be fixed, you should still use Watcom
1.4 anyway because of the almost 6x speed up with DOS graphics. I know the
problem is annoying, but just pretend it doesn't exist. You'll get over it
quickly just like I did. Everyone who uses a new Watcom version and the
translator has to deal with it anyway. It's miniscule hassle to press "Alt-Enter"
to return to DOS prompt if you really wanted to. Most DOS applications are
full-screen and if you ran in pure DOS it wouldn't matter at all. Pressing
"Alt-Enter" is an very small price to pay for a near 6x speed up for DOS
full-screen pixel graphics, cleaner internal code, and possibly slightly better
overall performance in most or all aspects.
> I spent a great deal of time yesterday studying the
> machine code that Watcom (10.6) is giving me in the inner
> part of the interpreter. I found a couple of trivial
> changes I could make in the C code that greatly
> improved the machine code generated across many ops.
> I'm not sure how much of this is an improvement over 2.5 official,
> versus how much just restores some speed that was
> lost since then. I'm going to continue working on that
> for a while before looking at new features.
Well lets think about this for a second here. Watcom 10.6 was released in 1996
and it's 2006 now. That means the compiler you're using is ten years old (almost
as old as Euphoria itself). In a decade of time, how many improvements, bug
fixes, and optimizations do you think have been made?
With Open Watcom you have C99 ISO compliant language features that allow you to
clean up or enhance some of your C source code; GCC 3/4.x also has C99 support.
You also have numerous new compiler & linker options to try out, to produce the
best overall performing and smallest size DOS, Windows interpreter executables
and EMAKE options. So basically you options and tools to produce better code and
thus offer better products.
Couldn't the changes you're making to the C back-end also benefit with Open
Watcom?
Do you honestly believe that the tiny issue of DOS Euphoria switching to
fullscreen in text-mode rather than just pixel-mode justfies denying a compiler
that is a decade newer and otherwise fully compatable with the Euphoria source
code?
Regards,
Vincent
8. Re: New features besides tasking
Vincent wrote:
> Robert Craig wrote:
> > I posted a message on the Open Watcom forum about the
> > "flipping to full-screen" problem. No response yet.
>
> I saw that. I spent several hours trying to figure this out for you. No
> success.
> I looked at all the compiler and linker options and even read the compiler
> documentation.
Thanks.
I didn't have any luck either.
> I'll post it on there for you again, so they'll know that we don't wish to be
> ignored. However even if the problem can't be fixed, you should still use
> Watcom
> 1.4 anyway because of the almost 6x speed up with DOS graphics. I know the
> problem
> is annoying, but just pretend it doesn't exist. You'll get over it quickly
> just
> like I did. Everyone who uses a new Watcom version and the translator has to
> deal with it anyway. It's miniscule hassle to press "Alt-Enter" to return to
> DOS prompt if you really wanted to. Most DOS applications are full-screen and
> if you ran in pure DOS it wouldn't matter at all. Pressing "Alt-Enter" is an
> very small price to pay for a near 6x speed up for DOS full-screen pixel
> graphics,
> cleaner internal code, and possibly slightly better overall performance in
> most
> or all aspects.
I'm still evaluating OW 1.4.
So far I don't see a general improvement in speed,
but I haven't done detailed benchmarking yet, or tried
to remove the work-arounds that I had to use with 10.6.
The fact that it's all shiny and new doesn't impress me much.
I suspect the code generation algorithms are essentially the same.
> > I spent a great deal of time yesterday studying the
> > machine code that Watcom (10.6) is giving me in the inner
> > part of the interpreter. I found a couple of trivial
> > changes I could make in the C code that greatly
> > improved the machine code generated across many ops.
> > I'm not sure how much of this is an improvement over 2.5 official,
> > versus how much just restores some speed that was
> > lost since then. I'm going to continue working on that
> > for a while before looking at new features.
>
> Well lets think about this for a second here. Watcom 10.6 was released in 1996
> and it's 2006 now. That means the compiler you're using is ten years old
> (almost
> as old as Euphoria itself). In a decade of time, how many improvements, bug
> fixes, and optimizations do you think have been made?
I've looked at their release notes, and only a few of the improvements
are relevant for me. At least I've proved that I can switch easily
to OW, if there is something to be gained by it.
> With Open Watcom you have C99 ISO compliant language features that allow you
> to clean up or enhance some of your C source code; GCC 3/4.x also has C99
> support.
> You also have numerous new compiler & linker options to try out, to produce
> the best overall performing and smallest size DOS, Windows interpreter
> executables
> and EMAKE options. So basically you options and tools to produce better code
> and thus offer better products.
>
> Couldn't the changes you're making to the C back-end also benefit with Open
> Watcom?
>
> Do you honestly believe that the tiny issue of DOS Euphoria switching to
> fullscreen
> in text-mode rather than just pixel-mode justfies denying a compiler that is
> a decade newer and otherwise fully compatable with the Euphoria source code?
I find "popping up to full screen" very irritating.
I don't know if the graphics library is faster in general,
or whether it's just the drawing of horizontal line segments
that's faster. That's an example of some detailed benchmarking
I want to do. It's also possible that DOS graphics with OW will
work in SVGA on more video cards.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: New features besides tasking
Robert Craig wrote:
> Vincent wrote:
> > I'll post it on there for you again, so they'll know that we don't wish to
> > be
> > ignored. However even if the problem can't be fixed, you should still use
> > Watcom
> > 1.4 anyway because of the almost 6x speed up with DOS graphics. I know the
> > problem
> > is annoying, but just pretend it doesn't exist. You'll get over it quickly
> > just
> > like I did. Everyone who uses a new Watcom version and the translator has to
> > deal with it anyway. It's miniscule hassle to press "Alt-Enter" to return to
> > DOS prompt if you really wanted to. Most DOS applications are full-screen
> > and
> > if you ran in pure DOS it wouldn't matter at all. Pressing "Alt-Enter" is an
> > very small price to pay for a near 6x speed up for DOS full-screen pixel
> > graphics,
> > cleaner internal code, and possibly slightly better overall performance in
> > most
> > or all aspects.
>
> I'm still evaluating OW 1.4.
> So far I don't see a general improvement in speed,
> but I haven't done detailed benchmarking yet, or tried
> to remove the work-arounds that I had to use with 10.6.
> The fact that it's all shiny and new doesn't impress me much.
> I suspect the code generation algorithms are essentially the same.
>
> > > I spent a great deal of time yesterday studying the
> > > machine code that Watcom (10.6) is giving me in the inner
> > > part of the interpreter. I found a couple of trivial
> > > changes I could make in the C code that greatly
> > > improved the machine code generated across many ops.
> > > I'm not sure how much of this is an improvement over 2.5 official,
> > > versus how much just restores some speed that was
> > > lost since then. I'm going to continue working on that
> > > for a while before looking at new features.
> >
> > Well lets think about this for a second here. Watcom 10.6 was released in
> > 1996
> > and it's 2006 now. That means the compiler you're using is ten years old
> > (almost
> > as old as Euphoria itself). In a decade of time, how many improvements, bug
> > fixes, and optimizations do you think have been made?
>
> I've looked at their release notes, and only a few of the improvements
> are relevant for me. At least I've proved that I can switch easily
> to OW, if there is something to be gained by it.
>
> > With Open Watcom you have C99 ISO compliant language features that allow you
> > to clean up or enhance some of your C source code; GCC 3/4.x also has C99
> > support.
> > You also have numerous new compiler & linker options to try out, to produce
> > the best overall performing and smallest size DOS, Windows interpreter
> > executables
> > and EMAKE options. So basically you options and tools to produce better code
> > and thus offer better products.
> >
> > Couldn't the changes you're making to the C back-end also benefit with Open
> > Watcom?
> >
> > Do you honestly believe that the tiny issue of DOS Euphoria switching to
> > fullscreen
> > in text-mode rather than just pixel-mode justfies denying a compiler that is
> > a decade newer and otherwise fully compatable with the Euphoria source code?
>
> I find "popping up to full screen" very irritating.
> I don't know if the graphics library is faster in general,
> or whether it's just the drawing of horizontal line segments
> that's faster. That's an example of some detailed benchmarking
> I want to do. It's also possible that DOS graphics with OW will
> work in SVGA on more video cards.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
A 6x improvement in DOS graphics drawing speed alone is not a reason to change
compilers. It doesn't matter if Watcom 10.6 is 10 years old. If it does the job,
then it is good enough.
Using the latest version, though, would be a good thing if it has enough
improvements to make it worthwhile. At least you know that it is better
supported.
I hardly ever use ex.exe, though, but I think the fullscreen thing (when
unnecessary) would annoy me as well. Especially if I just double-click on a *.ex
file that isn't required to be run under DOS.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: New features besides tasking
Jason Gade wrote:
> A 6x improvement in DOS graphics drawing speed alone is not a reason to change
> compilers. It doesn't matter if Watcom 10.6 is 10 years old. If it does the
> job, then it is good enough.
If in fact its a 5-6x improvement then that is a excuse to change.
DOS users (like myself) would really appreciate this improvement.
The fact that Watcom 10.6 is 10 years olds is problem. It has plenty of bugs and
is now unsupported and obsolete. RDS having to work around a couple of it's
problems is proof in itself.
> Using the latest version, though, would be a good thing if it has enough
> improvements
> to make it worthwhile. At least you know that it is better supported.
It has plenty of improvements and the near future beholds official Linux and BSD
support and maybe LFN extentions (just what Euphoria needs).
http://www.openwatcom.org/index.php/Long_Filenames_CLIB_Extension
> I hardly ever use ex.exe, though, but I think the fullscreen thing (when
> unnecessary)
> would annoy me as well. Especially if I just double-click on a *.ex file that
> isn't required to be run under DOS.
I understand. The people on the Watcom C user groups just arn't replying to
Robert's message. I posted one today to in hope of a reply sooner or later.
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
Bottom Line: Robert should use whatever he thinks is best. But he should do his
tests with OW 1.4 and form a basis for his decision. Excusing OW soley on a
difference in how DOS programs startup isn't fair enough.
Regards,
Vincent
11. Re: New features besides tasking
Vincent wrote:
>
> Jason Gade wrote:
>
> > A 6x improvement in DOS graphics drawing speed alone is not a reason to
> > change
> > compilers. It doesn't matter if Watcom 10.6 is 10 years old. If it does the
> > job, then it is good enough.
>
> If in fact its a 5-6x improvement then that is a excuse to change.
> DOS users (like myself) would really appreciate this improvement.
Yeah, if you were running graphics intensive programs on 10-year-old DOS
machines, I could see how this would be important.
> The fact that Watcom 10.6 is 10 years olds is problem. It has plenty of bugs
> and is now unsupported and obsolete. RDS having to work around a couple of
> it's
> problems is proof in itself.
Software doesn't become obsolete in the same way that hardware does. If it
continues to work with current OSes then it shouldn't be a problem.
While I know that RDS has had to write some workarounds, he said himself that he
doesn't know if those have been changed in the current version. I'm not even sure
if they are related to C99 or whatever or whether they were compiler specific.
> > Using the latest version, though, would be a good thing if it has enough
> > improvements
> > to make it worthwhile. At least you know that it is better supported.
>
> It has plenty of improvements and the near future beholds official Linux and
> BSD support and maybe LFN extentions (just what Euphoria needs).
>
> <a
> href="http://www.openwatcom.org/index.php/Long_Filenames_CLIB_Extension">http://www.openwatcom.org/index.php/Long_Filenames_CLIB_Extension</a>
>
> > I hardly ever use ex.exe, though, but I think the fullscreen thing (when
> > unnecessary)
> > would annoy me as well. Especially if I just double-click on a *.ex file
> > that
> > isn't required to be run under DOS.
>
> I understand. The people on the Watcom C user groups just arn't replying to
> Robert's message. I posted one today to in hope of a reply sooner or later.
>
> Bottom Line: Robert should use whatever he thinks is best. But he should do
> his tests with OW 1.4 and form a basis for his decision. Excusing OW soley on
> a difference in how DOS programs startup isn't fair enough.
Yes, of course.
>
>
> Regards,
> Vincent
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
12. Re: New features besides tasking
Jason Gade wrote:
> Yeah, if you were running graphics intensive programs on 10-year-old DOS
> machines, I could see how this would
> be important.
I see alot of improvement possible on my P4 box. But just for the record I also
use Eu on a blazing fast 386 and 486 DX laptop. But I do have a 286 laptop, Apple
IIe and Commodore 64 as well.
> Software doesn't become obsolete in the same way that hardware does. If it
> continues
> to work with current OSes then it shouldn't be a problem.
> While I know that RDS has had to write some workarounds, he said himself that
> he doesn't know if those have been changed in the current version. I'm not
> even
> sure if they are related to C99 or whatever or whether they were compiler
> specific.
Well it couldn't have anything to do with C99. Watcom 10.6 was released before
the new C99 specifcation was submitted. I think RDS only uses the older ANSI C,
which is fine.
Its a good chance that whatever Robert was trying to work around has been fixed
after ten years. But of course he wont know until he tries to remove it. If it
hasn't been fixed, he can report it to the Watcom development team.
Regards,
Vincent
