1. RE: Euphoria's Future?
- Posted by Henri.Goffin at sbs.be
Nov 15, 2001
Hi all!
I'm sorry if I spoil a little bit the unlimited enthusiasm expressed so far but
Euphoria suffers from a least one severe limitation that I already mentioned
here.
In the file bind.doc that comes with Euphoria 2.2 it is stated:
" A bound executable file can handle standard input and output redirection. e.g.
myprog.exe < file.in > file.out"
This is simply not true, at least on NT/W2K platforms. The reason is the bound
executable starts in a new console window that is unaware of the invoking
window's environment.
There is also the problem of a memory violation error that I have with a bound
Euphoria program. The answer of Robert to my request for help was rather
disappointing because too reminescent of Microsoft's favorite silver bullet:
"reboot your system, maybe the problem will have disappeared". Who would dare
build his/her business on such a basis?
To conclude with a positive remark I have to say that I will continue to use
Euphoria because it is a fine tool that has allowed me to write some useful
programs, even with a professional looking GUI, at a fraction of the cost (in
time and sweat and tears) that other languages (VB, C++, PERL, JAVA,...) would no
doubt have implied.
Kind regards,
Henri Goffin
> -----Original Message-----
> From: Igor Kachan [SMTP:kinz at peterlink.ru]
> Sent: Wednesday, November 14, 2001 11:44 AM
> To: EUforum
> Subject: Re: Euphoria's Future?
>
>
> Yes FP, yes & yes !!!
>
> Documentation of Euphoria is wonderful,
> and my native language is not English,
> it is Russian. I had very large practice of
> writing and editing of Russian naval/electronics
> scientific texts (more than 10 years), and I can
> say Euphoria's English documentation is crystal.
>
> I understand it very well without translation
> into Russian, in English as in my native language.
>
> This is the very rare thing so clear and exact
> expression of powerful programming ideas in
> strongly concrete manual for strongly concrete
> programming practice, and in very compact form.
>
> This documentation is the *ideal* *instruction*.
> But look for ideas in any instruction on OOP
> and you'll find "the object is any thing, iron
> or car or bread or ... for example. Just
> remember for future".
>
> Very clear for programmer, no ?
>
> Just remember ... OK ... I'll rememmmber ...
> I'mmmm very clever programmmer ... hmmmm ...
>
> But C++'s and Java's manuals and books are
> full of such the "ideas".
>
> Yes, English Euphoria documentation is
> so excellent that it is the very difficult
> thing to corrupt this documentation
> with translation into other languages 
>
> My Russian readers say: Russian docs are
> clear and exact thank you Robert very much!
>
> (But Rob says he doesn't understand
> Russian at all, I do not believe to him,
> but can not examine his Russian here
>
> There was the printed manual in CE pakage
> earlier, but any one can prepare such the
> manual on his/her taste with the color
> printer now, I think.
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
>
> ----------
> > > Îò: freeplay at mailandnews.com
> > Êîìó: EUforum <EUforum at topica.com>
> > Òåìà: Re: Euphoria's Future?
> > Äàòà: Wednesday, November 14, 2001 00:37
>
> >
> > At 09:10 13/11/01 +0100, you wrote:
> > <snip>
> > >It needs a shiny box and a good manual.
> > <snip>
> > xxxxxxxxxxx
> >
> > I disagree on one point. Euphoria doesn't need a good manual because it
> > already comes with one far far better than "good" - "excellently superb"
> is
> > a better description. The documentation (i.e. "manual") that is supplied
> > with Euphoria is the best example of clearly written, easy to understand
> > and (thanks to the hot link ability of HTML) the easiest to navigate I>
> have
> > ever come across in twenty years of reading such material. I believe
> this
> > is one of the reasons why so many people have taken the time (at no cost)
> > to translate the documentation to other languages.
> >
> > High quality documentation for any product is essential for it's success
> > but a shiny box to put it in is, IMHO, not
> >
> > Keep up the good work all.
> >
> > Regards,
> >
> > FP.
>
>
>
2. RE: Euphoria's Future?
... "my" 2 cents worth about Euphoria's future ....
I have been using Euphoria on and off for close to 3 years and get
very frustrated about the lack of available good quality, bug free,
documented libraries. Over this time I have seen many people
come and go (myself included!).
Don’t people wonder why more people aren’t using Euphoria?
Why hasn’t it grown faster?
Where are all the Euphoria web sites?
I always sound very negative when I talk like this and I don’t mean
to be but sometimes you have step back and look at the big picture.
Euphoria is a good "base" language for the small to medium sized
tasks that don't need to much interaction with other technologies.
What I’m saying is that Euphoria “IS” good for some tasks. But it
isn’t the “best” tool for “a lot” of tasks.
Yes there are many libraries available but few are complete and even
fewer are documented. The return "cry" is always ... build your own
libraries ... the problem is that this takes a lot of effort!
Trust me I should know!
If you like building libraries then this is great!
The big benefits of Euphoria (IMO) are:
* it's small
* it's fast
* It's easy to program in.
If you strip all of the libraries and extensions out of almost any
other language you would probably achieve the same benefits.
Being small isn't always a feature.
Euphoria creates a lot of enthusiasm from people new
to programming because it is easy to use. These same
people mostly wander off when they find out things get
very difficult very quickly after you can do the basics.
I believe Euphoria needs “official” libraries (or utilities)
that are distributed with (and documented with) the
base Euphoria install. Or an “official” libraries pack
that can be downloaded as a separate download but
installed and documented together.
I don’t believe the current method of letting people write
and share their libraries with other people is working
satisfactorily.
Sometimes you need to look at the past to see the future!
How long has Euphoria been used for?
What is the current status?
What is the future?
I don’t want people to stop using Euphoria … but I believe
people should be aware of what is easily achievable and what
is not. I’m always happy when people push the boundaries
of what can be done but my feeling is most people give up
with frustration at what can’t be done (“easily”).
Marketing is another thing mentioned….
Why wouldn’t RDS want Euphoria to be popular?
Who hear is happy with the current progress of Euphoria?
Who wouldn’t want Euphoria to improve and expand at a faster rate?
To finish with a positive note … I’m waiting with anticipation as to
what can be achieved when others have the source code. This is
the most positive step RDS have made for years and hopefully
there are enough people willing to buy and expand on it and
expand Euphoria’s capabilities.
Ray Smith
http;//www.geocities.com/ray_223
3. RE: Euphoria's Future?
On Fri, 16 Nov 2001, Ray Smith wrote:
> I have been using Euphoria on and off for close to 3 years and get
> very frustrated about the lack of available good quality, bug free,
> documented libraries.
Here's my excuse to bring up the subject of gtk.e, a library started by
David Cuny but not finished. This library is (I guess) mainly for the
linux world but is (I guess) supposed to be cross-platform.
Is there any chance that someone could be motorvated to do some more
work on it? Even if it is not completed, more work on it would help
greatly to do projects with it.
I was tentatively planning to re-do and/or translate my program DMAK
(Diet Monger @$$ Kicker) for the linux world. ( According to a search on
freshmeat they are kinduv deficient in nutrient programs. ) But there is
not enough stuff in gtk.e to make DMAK using gtk.e. For example I can
use addItem to put items in a list box, but I can't remove items.
Besides my own little personal goals, making gtk.e more complete would
probably significantly expand Euphoria into the linux world.
Jerry Story
4. RE: Euphoria's Future?
On Thu, 15 Nov 2001 jstory at freenet.edmonton.ab.ca wrote:
> Here's my excuse to bring up the subject of gtk.e, a library started by
> David Cuny but not finished. This library is (I guess) mainly for the
> linux world but is (I guess) supposed to be cross-platform.
That should be gtklib.e, not gtk.e.
Jerry Story
5. RE: Euphoria's Future?
Hi Jerry,
I "was" playing with a GUI toolkit called FLTK (www.fltk.org) that
I have partially working under Euphoria Win32.
I attempted it under Linux but had trouble building a shared
library. (It should be possible to get it to work though!!!)
It was turning out to be a fair amount of work so I decided
"why don't I just try learning C++" ... and I have started doing that
and am getting into the world of OO programming.
For anyone interested ... just get a good C++ book (or download one),
some free time, a free C++ compiler and start reading.
The basics are fairly simple and all of a sudden you can make fair
sized programs with not as much effort as you might have thought.
An added benefit is that it might be of benefit in furthur (or
current) employement!
Euphoria does lack flexibility in interfacing with libraries built
with other languages (C and C++ primarily).
If this could be simplified it would be a MAJOR improvement.
Jerry ... sine you have done some work of gtk.e you should consider
using standard C to re-write your program. It would then (with I
don't know how much modification) work on all platforms that GTK
supports. How portable is ANSI C???
... Just some thoughts
Ray Smith
http;//www.geocities.com/ray_223
> Here's my excuse to bring up the subject of gtk.e, a library started by
> David Cuny but not finished. This library is (I guess) mainly for the
> linux world but is (I guess) supposed to be cross-platform.
>
> Is there any chance that someone could be motorvated to do some more
> work on it? Even if it is not completed, more work on it would help
> greatly to do projects with it.
>
> I was tentatively planning to re-do and/or translate my program DMAK
> (Diet Monger @$$ Kicker) for the linux world. ( According to a search
> on
> freshmeat they are kinduv deficient in nutrient programs. ) But there
> is
> not enough stuff in gtk.e to make DMAK using gtk.e. For example I can
> use addItem to put items in a list box, but I can't remove items.
>
> Besides my own little personal goals, making gtk.e more complete would
> probably significantly expand Euphoria into the linux world.
>
>
> Jerry Story
>
>
6. RE: Euphoria's Future?
On Fri, 16 Nov 2001, Ray Smith wrote:
> Jerry ... sine you have done some work of gtk.e you should consider
> using standard C to re-write your program.
Just in case anyone mis-understands, I did not do any work on gtk.e or
gtklib.e. I merely looked at it, studied it, to find out whether I could
use it. I don't have any technical knowledge. I leave stuff like that to
the gurus.
I used to program in QuickC for DOS, but modern C for Windowy stuff is
C++, and it has classes and stuff and every time I try to learn it I am
reminded of why I prefer to program in Euphoria. I was reading some
documentation of C#. Microsoft describes C# as "simple". I thought:
"They call THAT(!) simple?"
Jerry Story
7. RE: Euphoria's Future?
Kat wrote:
> for windoze, so we still have the non-portable programs. What i was
> thinking
> was being able to write an Eu program on my win95, and then upload to a
> shell server running *nix, and it works. I still see no way to do it.
>
Kat:
If you have any dos programs that you wrote in Euphoria and
want to run that same program on Linux, you can always
use my eu_engin.e library.
Bernie
8. RE: Euphoria's Future?
Hi David,
I finally got around to looking at wxBasic. It looks very
impressive, well done.
My question is ...
What is the future or wxBasic?? What are your "current" aims for
developing wxBasic??
Is your aim to develop a cross platform Visual Basic "type"
environment?
You also mentioned you would/might add your wx wrappers to Euphoria
when the Euphoria source is available. What incentive is there to do
that if you have your own interpreter?
How difficult would it be to remove the wxWindows logic from the
source code and produce a "simple" basic interpreter?
Following on from that, how difficult would it be to plug in other
libraries (like Allegro games library, FLTK GUI Library, Fox GUI
library for examples) into your basic interpreter?
How has the responce been from the wxWindows community regarding
wxBasic???
Does wxBasic have any limitations?
Regards,
Ray Smith
David Cuny wrote:
> I've already written a set 'generic' wrappers that can be used to glue
> wxWindows to C/C++ scripting languages. As a sort of 'proof of concept',
> I'm
> using them in my own Basic interpeter:
>
> http://wxbasic.sourceforge.net
>
> Ironically, I started out the project writing wrappers for Euphoria, but
> since the source wasn't available, I had to set up my own test platform.
> That 'test platform' eventually turned into wxBasic.
[snip]
> Once Robert releases Euphoria, I'll trying creating a wxWindows enabled
> version of Euphoria.
>
Ray Smith
http;//www.geocities.com/ray_223
9. RE: Euphoria's Future?
- Posted by Henri.Goffin at sbs.be
Nov 19, 2001
I'd rather think I'm trapped in a space-time loop that forces me to live the
same events again and again 
More seriously, Rob, your suggestion (use trace to locate the offending
statement) is of no use here since my prog crashes before executing the first
statement. Probably during the init phase (heap allocation or something).
My poor debugging skills on MS platforms have just allowed me to make clear that
the program tries to write to an unallocated memory area. The instruction is:
mov [edi+0x4],ebx and edi = 0x007d0ffc. This pattern reminds me of numerous
such errors I saw in the past where some loop executes one time too much and
makes a pointer point just beyond the boundary of an allocated memory block. But
it's just a feeling. After all maybe neither my program nor Euphoria interpreter
are wrong but instead the C-compiler (Watcom, right?) is the culprit.
Last comment. The doc says a bound program is bound with the PD flavor of
exw.exe. So I tried 'pdexw myprog.exw' thinking I would reproduce the problem.
But it also runs OK just like with the registered Euphoria interpreter. So it
seems to be linked with what bind.ex produces.
Regards,
Henri Goffin
> -----Original Message-----
> From: rforno at tutopia.com [SMTP:rforno at tutopia.com]
> Sent: Friday, November 16, 2001 1:24 AM
> To: EUforum
> Subject: Re: Euphoria's Future?
>
>
> Were the planets properly aligned?
> ----- Original Message -----
> From: "Robert Craig" <rds at RapidEuphoria.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Thursday, November 15, 2001 2:20 PM
> Subject: Re: Euphoria's Future?
>
>
> > Henri Goffin writes:
> > > This is simply not true, at least on NT/W2K platforms.
> > > The reason is the bound executable starts in a new console
> > > window that is unaware of the invoking window's environment.
> >
> > With the Euphoria source, you'll be able to build your
> > own exw.exe that is more console-oriented. It should work
> > with STDIN/STDOUT on any system. You just have to edit
> > one line in the .bat file that I'll distribute with it. Maybe I'll make a
> version
> > like that myself and upload it once 2.3 alpha is out.
> >
> > > There is also the problem of a memory violation error
> > > that I have with a bound Euphoria program. The answer of
> > > Robert to my request for help was rather disappointing because
> > > too reminescent of Microsoft's favorite silver bullet:
> > > "reboot your system, maybe the problem will have disappeared".
> > > Who would dare build his/her business on such a basis?
> >
> > On Oct 5, 2001 I replied to you...
> >
> > R> In 2.3 the interpreter will have trace(3) which will allow you
> > R> to log the exact Euphoria statement that was being executed
> > R> when a machine-level crash like this occurred.
> >
> > R> Until then, you can insert print statements to pin down
> > R> where the crash happens.
> >
> > Did you insert any print statements?
> > If not, wait 10 days or so until trace(3) is available.
> > You'll also be able to try the new 2-pass binder,
> > although I doubt that a binding bug is the
> > root cause of your problems.
> > >From my experience these cases usually turn out
> > to be a bug in the application that only shows up
> > when it's bound (or it's Tuesday afternoon, or there's
> > unusual sunspot activity, or ...)
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
> >
> >
>
>
10. RE: Euphoria's Future?
- Posted by Henri.Goffin at sbs.be
Nov 20, 2001
Thank you, Igor.
I did as you said and quickly came to the conclusion that the problem occurs
during the include processing. Eventually I just shuffled a bit my include
statements, changing their order and... now it's OK!!!
But basically the problem is still potentially there because your method did not
allow me to pinpoint one particular include. Indeed when I insert at least one of
your "breakpoints", no matter where provided there is at least one somewhere
amidst the include statements, the error does not reproduce. I also tried a
couple of different include arrangements (without breakpoints) and it's always
OK.
It seems to indicate there are include sequences that are endowed with dark
powers! Maybe when they reproduce the pattern of some ancient runes!!!
Strange, isn't it??? (insert X-files theme here :-0)
Henri Goffin
> -----Original Message-----
> From: Igor Kachan [SMTP:kinz at peterlink.ru]
> Sent: Monday, November 19, 2001 3:23 PM
> To: EUforum
> Subject: Re: Euphoria's Future?
>
>
> Hi Henri,
>
> ----------
> > > Îò: Henri.Goffin at sbs.be
> > Êîìó: EUforum <EUforum at topica.com>
> > Òåìà: RE: Euphoria's Future?
> > Äàòà: Monday, November 19, 2001 16:29
>
> <snip>
>
> >my prog crashes before executing the first statement.
> >Probably during the init phase
> >(heap allocation or something).
>
> </snip>
>
> Try please:
>
> --- just the top of your prog
> puts(1,"1\n")
> while get_key()=-1 do end while
> -- the first your old statement
> include your_lib1.e -- just the first include
> puts(1,"2\n")
> while get_key()=-1 do end while
> include your_lib2.e -- just the second include
> ---- and so on
>
> If you see 1, push any key to go to the next statement,
> if you see 2, push any key to go to the next statement.
> and so on ...
> If it crashes on the 1st include then place in the 1st
> include on the top:
>
> puts(1,"1-1\n")
> while get_key()=-1 do end while
>
> and so on ....
>
> This method is the most powerful debugger.
>
> Try please, maybe the thing is not so sad ...
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
>
>
>
