OpenEuphoria

1. Rob?

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 08, 2006
• 501 views
• Last edited Feb 09, 2006

Robert Craig wrote:
> 
> 
>   1. Show me an actual example where you or someone else has 
>      run into this "problem" in real life. Explain why in the first
>      decade of Euphoria, *no one* ever reported this "problem".
>      Explain why I should delay 100 other important features and bug
>      fixes, that people actually want, to address this possible "problem".
> 
>   2. Give me a simple, totally reliable solution, coded in Euphoria,
>      that works on all platforms, with no ill side effects and does
>      not add *180* lines of code to the scanner. You say you will
>      do the long-term maintenance, but you've "quit" Euphoria twice 
>      in just the past year.
> 
>   3. Give me something I can write in the Euphoria language definition
>      that does not read "if you change the size of a comment in a
>      source file by one byte, your program's behavior could 
>      change drastically".
> 
>   4. It is bad netiquette to quote private e-mails on public
>      forums without the other party's permission. It does not
>      encourage the other party to exchange private e-mails with you
>      in the future.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>


So now that I've answered all those for you, you're just going to ignore me?
That isn't very fair. I think I deserve a reply. If I was in your position I
certainly wouldn't ignore a paying customer.


Regards,
Vincent

P.S: What ever happened to the customer always being right?

3. Re: Rob?

• Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
• 480 views

Robert Craig wrote:
> 
> Vincent wrote:
> > Robert Craig wrote:
> > >   1. Show me an actual example where you or someone else has 
> > >      run into this "problem" in real life. Explain why in the first
> > >      decade of Euphoria, *no one* ever reported this "problem".
> > >      Explain why I should delay 100 other important features and bug
> > >      fixes, that people actually want, to address this possible "problem".
> > > 
> > >   2. Give me a simple, totally reliable solution, coded in Euphoria,
> > >      that works on all platforms, with no ill side effects and does
> > >      not add *180* lines of code to the scanner. You say you will
> > >      do the long-term maintenance, but you've "quit" Euphoria twice 
> > >      in just the past year.
> > > 
> > >   3. Give me something I can write in the Euphoria language definition
> > >      that does not read "if you change the size of a comment in a
> > >      source file by one byte, your program's behavior could 
> > >      change drastically".
> > > 
> > >   4. It is bad netiquette to quote private e-mails on public
> > >      forums without the other party's permission. It does not
> > >      encourage the other party to exchange private e-mails with you
> > >      in the future.
> >
> > 
> > So now that I've answered all those for you, you're just going to ignore me?
> > That isn't very fair. I think I deserve a reply. If I was in your position I
> > certainly wouldn't ignore a paying customer.
> >
> > Regards,
> > Vincent
> >
> > P.S: What ever happened to the customer always being right?
> 
> I think you're getting a bit paranoid.
> I'm not ignoring you. It's just that I sometimes
> have to leave my computer to sleep, eat, or go out and buy food. 
> I also have to serve many other customers. Customers who 
> disagree with you. Can all customers be right?
> 
> I'm also working hard on the multitasking feature, which I've now
> completed except for packaging the files and uploading them.
> Both the interpreter and translator now work fine with multitasking
> on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc),
> Linux and FreeBSD. I also have example programs that use multitasking
> on all platforms. I'm building the Linux executables on a newer
> version of Linux, so maybe some things will work better 
> for some people.

WooHoo! Looking forward to this.

> I'll grant you that you've answered 1 and 4, (though
> the only person you referred to in 1 found a workaround,
> and is "not demanding" a change to the language).
> However I don't think you've provided a solution that
> answers both 2 & 3.

2. Just compare the include string. If it is the same, then it is the same file.
If it is not (different path) then it is not. Whether or not the file is the
same, if global symbols conflict then it is an error and the include either needs
to be namespaced or fixed. Local symbols are still unique.

Again, this is just aesthetics on my part and definitely not extensive
experience in programming language design. It seems to be pretty easy to change.

3. Deprecated by #2 above.

> You've also mentioned that your 180-line solution
> adds 10% to load time. I find this hard to believe,
> but if it's true, I can't believe that you would want that.
> You've been complaining with great passion about the
> load time issue, but now you're willing to throw 10%
> out the window, as long as the time is spent in your
> code handling a possible problem that does not affect
> 99% of all programs?
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

So, when can I start bugging you to support mingw (basically a Windows version
of gcc) and let routine_id to have forward referencing? 

PS Seriously, you support DJGPP and gcc already, how hard would it be to support
mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support many
different compilers but I'm not sure how different mingw is from gcc. I'm sure
there are differences between it and DJGPP.

--
"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
j.

5. Re: Rob?

• Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
• 498 views

Kenneth Rhodes wrote:
> 
> 
> > Robert Craig wrote:
> 
> > > 
> > > I'm also working hard on the multitasking feature, which I've now
> > > completed except for packaging the files and uploading them.
> > > Both the interpreter and translator now work fine with multitasking
> > > on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc),
> > > Linux and FreeBSD. I also have example programs that use multitasking
> > > on all platforms. 
> 
> > >I'm building the Linux executables on a newer
> > > version of Linux, so maybe some things will work better 
> > > for some people.
> > >
> 
> If you don't mind my asking...
> Specifically, which version of Linux and which version of ncurses
> will Euphoria 3.0 use?

Maybe I'm naive, but I think that my Amiga used to work this way:

Open a shared library by name, check it's version. If version was less than some
number then exit.

Doesn't Linux have a link from a generic 'ncurses' library that points to the
latest version installed? Then the program should do a version check (included
with the library) and exit with a message saying it requires a certain version if
it is not greater.


--
"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
j.

7. Re: Rob?

• Posted by D. Newhall <derek_newhall at yahoo.com> Feb 09, 2006
• 481 views

Robert Craig wrote:
> 
> Vincent wrote:
> > P.S: What ever happened to the customer always being right?
> 
> I also have to serve many other customers. Customers who 
> disagree with you. Can all customers be right?

Without really getting into this I will say that it is impossible to satisfy all
users, some want goto, some want associated arrays, some want integrated GUIs,
etc. however, I would think that thread safety would be more useful than
multitasking (at least for my use) but either is a nice addition.

Vincent's arguments reminded me of this quote I read:

"The language user is usually right ... It is impossible to overestimate the
 value of the direct feedback from users that was available while REXX was being
 designed”
- Mike F. Cowlishaw (the creator of REXX), “The REXX Language, a practical
approach to programming”, Prentice Hall, ISBN 0-13-779067-8

I'm not officially agreeing nor disagreeing with it just posting it for
arguments sake.


The Euphoria Standard Library project :
    http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
    https://lists.sourceforge.net/lists/listinfo/esl-discussion

9. Re: Rob?

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
• 485 views

Kenneth Rhodes wrote:
> If you don't mind my asking...
> Specifically, which version of Linux and which version of ncurses
> will Euphoria 3.0 use?

At the moment, I'm using the version of Linux on the ListFilter machine,
(Red Hat I think) but I might switch to my own machine that 
has Mandrake 10.0, especially if people report any problems. 
Both versions of Linux are fairly recent. I haven't tried to 
pin down the exact ncurses versions. I still plan to do a 
version without ncurses, for people who would prefer that.
Previously I was using an old Red Hat 5.2 Linux (circa 1999). 
I figured it was safer to stick with an older "lowest-common-denominator"
version, than accidentally use new features that not everyone has. 
We'll see.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

11. Re: Rob?

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 09, 2006
• 465 views

Robert Craig wrote:
> 
> I think you're getting a bit paranoid.
> I'm not ignoring you. It's just that I sometimes
> have to leave my computer to sleep, eat, or go out and buy food. 
> I also have to serve many other customers. Customers who 
> disagree with you. Can all customers be right?

I don't think it so much a matter of them disagreeing with me as it is with you
disagreeing with them.
 
> I'm also working hard on the multitasking feature, which I've now
> completed except for packaging the files and uploading them.
> Both the interpreter and translator now work fine with multitasking
> on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc),
> Linux and FreeBSD. I also have example programs that use multitasking
> on all platforms. I'm building the Linux executables on a newer
> version of Linux, so maybe some things will work better 
> for some people.

Great, the beer is on me. 
 
> I'll grant you that you've answered 1 and 4, (though
> the only person you referred to in 1 found a workaround,
> and is "not demanding" a change to the language).
> However I don't think you've provided a solution that
> answers both 2 & 3.

Ok... I've thought about dir() some more and concluded that you can use that
instead?

Let me explain...

You could more or less do everything I mentioned with my second proposal, but
instead of checking and storing for file sizes, check and store results of
dir(f); where f means the current file name.

So now in order for two or more files to be percieved as the same, the results
of the current dir() and a stored dir() must be exactly the same.

Example:

{
  {
    {109,105,115,99,46,101}, -- file name
    {97},                    -- attribute
    7577,                    -- byte size
    2006,                    -- year
    1,                       -- month
    11,                      -- day
    15,                      -- hour
    18,                      -- minute
    4                        -- second
  }
}

So in order for Euphoria to quitely ignore an include statement: Two or more
different files will need to have the same exact names, attributes, and byte
sizes. But it would also need to been modified the same exact year, month, day,
hour, minute, and second! 

Heres another simplifed example showing this idea in action:

include file.e

sequence a, b

a = dir("C:\\EUPHORIA\\include\\misc.e")
b = dir("C:\\EUPHORIA\\include\\machine.e")

if equal(a, b) then
    puts(1, "The two files are most likely the same.\n")
else
    puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n")
end if

machine_proc(26, 0)

I think I like this one better than my 180 line solution.
What do you think?

This is just as simple as the file size solution but with an extremely higher
degree of accuracy.

> You've also mentioned that your 180-line solution
> adds 10% to load time. I find this hard to believe,
> but if it's true, I can't believe that you would want that.
> You've been complaining with great passion about the
> load time issue, but now you're willing to throw 10%
> out the window, as long as the time is spent in your
> code handling a possible problem that does not affect
> 99% of all programs?

Well 10% is virtually undetectable on anything less than the biggest Euphoria
programs. Like I said, the difference with the biggest program I've tested was
less than a half second. Check out my dir() idea above.

> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>


Regards,
Vincent

13. Re: Rob?

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 09, 2006
• 482 views

Igor Kachan wrote:
> 
> Hi Vincent,

Hi there
 
> I am sorry, but I am afraid that I'm strongly against your
> solution on so called "include problem" for the official EU.

I already knew you were against it.
 
> I have some not bad experience about including almost same libs
> into EU programs. There is ru_eu_12.zip package in the Archive.
> 
> It is a bilingual English/Russian Euphoria. And it has bilingual
> versions of all the official EU libs.
> 
> Sorry, but it is much more convenient way to have, say,
> 'misc.e' for the pure English standard lib and 'misc___r.e'
> for almost same, but bilingual, lib rather than, say,
> 'misc.e' and 'russian/misc.e'.

Is that how your operating system works? Just because two files might be named
the same doesn't mean they are. Should they be treated like they are? Obviously
you're not looking at the big picture and the major effects this problem could
bring down the road.

> Just try some real life concrete (specific) work about these
> identical file names of libs and you'll too see lots of
> confusions if these different libs have identical names.

It creates lots of confusion when your programs and/or libraries fail to work
because of this issue. Just because it isn't a big deal now doesn't mean it
shouldn't be fixed... after all the solutions are very simple.

> Now I have NO problems and confusions, Euphoria cares,
> and I'll never confuse my libs this way.
> 
> *The long file and path names were introduced to give us
> a powerful tool for resolving any file name conflicts.*
> 
> Just use for your new lib some new good name and don't
> worry be happy.     

Well it becomes a worry when somebody else uses your good name with their own
programs and libraries. It becomes even more a problem when 10,000 or more do the
same exact thing. That is very real a possability if Euphoria's popularity ever
become significant. Worrying about this then is not a solution as it should have
never existed to begin with.

> First time when this so called "include problem" poped up,
> was Bensler's attempt to replace RDS standard libs with
> his own unknown libs of identical names.

Chris Bensler is Anti-RDS. I support RDS and their buisness model (for the most
part).

> Nobody before him tried that dubious trick against the
> official RDS stuff.
> 
> [snip]
> 
> I'm sorry, but all these look like A-bomb against a sparrow.
> Just renaming of a new file solves that 'problem'.

But how could that be a solution when that is the effect I'm trying to avoid?

As for an A-bomb, I bet Iran's goal is to make one and devistate Israel with it;
we can't let that happen.

> Path name and file name are different things, who cares about
> file attributes? It is too large reading, if you want to learn
> these attributes too.
>
> Why you do not want to name some your new lib, say, as
> "Vincent's_New_Lib_on_SVGA_graphics_for_DOS_and_Windows_and_Linux.e"?

Heh... then we would have to rename it to make it shorter as it is way to long
to type every time.

> Just name it so and I'll pay you my MicroDollars forever,
> (if it will work on my machine)!      

Huh?

> Good Luck!
> 
> Regards,
> Igor Kachan
> kinz at peterlink.ru


Take care,
Vincent

15. Re: Rob?

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 09, 2006
• 474 views
• Last edited Feb 10, 2006

Vincent wrote:
> 
> Igor Kachan wrote:
> >

[snip]
 
> > [snip]
> > 
> > I'm sorry, but all these look like A-bomb against a sparrow.
> > Just renaming of a new file solves that 'problem'.
> 
> But how could that be a solution when that is the effect I'm trying
> to avoid?

Just do remember that Euphoria just ignores double including
and just do not include same file twice.

Just avoid any struggle against this very useful feature.    

> As for an A-bomb, I bet Iran's goal is to make one and devistate
> Israel with it; we can't let that happen.

There is nothing to do with a real A-bomb, Iran, Israel, Chechen,
Marks, Lenin, Stalin, Hitler and others on this list.

The A-bombs and rokets are the only weapon against asteroids, comets etc
and can be very useful for all us - Russians, Americans, Irani, Iraki,
Chinese, Indian, Dutch, Hebrew, etc etc etc, for all living on this planet.

But there is nothing to do with asteroids and comets here, sorry about OT.

> > Path name and file name are different things, who cares about
> > file attributes? It is too large reading, if you want to learn
> > these attributes too.
> >
> > Why you do not want to name some your new lib, say, as
> > "Vincent's_New_Lib_on_SVGA_graphics_for_DOS_and_Windows_and_Linux.e"?
> 
> Heh... then we would have to rename it to make it shorter as it is way to long
> to type every time.

I'll be just happy to type this long name in my Euphoria programs.
Then Euphoria code may be almost absolutelly platform independent. 

Do you see in EU docs : DOS, Windows, Linux?
 
> > Just name it so and I'll pay you my MicroDollars forever,
> > (if it will work on my machine)!      
> 
> Huh?

Yes, I think that such a lib is one of the most needed.
Make it and I'll pay you my MicroMoney with pleasure.

Good Luck!

Regards,
Igor Kachan
kinz at peterlink.ru

17. Re: Rob?

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 10, 2006
• 495 views

Vincent wrote:
> Ok... I've thought about dir() some more and concluded that you can use that
> instead?
> 
> Let me explain...
> 
> You could more or less do everything I mentioned with my second proposal, but
> instead of checking and storing for file sizes, check and store results of
> dir(f);
> where f means the current file name.
> 
> So now in order for two or more files to be percieved as the same, the results
> of the current dir() and a stored dir() must be exactly the same.
> 
> Example:
> 
> {
>   {
>     {109,105,115,99,46,101}, -- file name
>     {97},                    -- attribute
>     7577,                    -- byte size
>     2006,                    -- year
>     1,                       -- month
>     11,                      -- day
>     15,                      -- hour
>     18,                      -- minute
>     4                        -- second
>   }
> }
> 
> So in order for Euphoria to quitely ignore an include statement: Two or more
> different files
> will need to have the same exact names, attributes, and byte sizes. But it
> would also need
> to been modified the same exact year, month, day, hour, minute, and second!
> 
> 
> Heres another simplifed example showing this idea in action:
> }}}
<eucode>
> include file.e
> 
> sequence a, b
> 
> a = dir("C:\\EUPHORIA\\include\\misc.e")
> b = dir("C:\\EUPHORIA\\include\\machine.e")
> 
> if equal(a, b) then
>     puts(1, "The two files are most likely the same.\n")
> else
>     puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n")
> end if
> 
> machine_proc(26, 0)
> </eucode>
{{{

> 
> I think I like this one better than my 180 line solution.
> What do you think?
> 
> This is just as simple as the file size solution but with an extremely higher
> degree of accuracy.

Yes, I thought about this method a few days ago, when I mentioned
dir(), open() etc. in my private e-mail. The fact that it isn't perfect
bothered me at the time, but I think I can accept it. Congratulations.

The "extremely high degree of accuracy" is a bit misleading,
since in some situations, copying a bunch of files will
result in them all having the same time stamp. This is more likely
on Linux/FreeBSD. In fact it's a little bit worrying to think that
a program that's working could now fail just because it got copied
to a new machine or a new directory. But this would be a very rare bug 
so I guess I can accept it. Also, in future I might add a couple of fields to
the dir() result. On Linux/FreeBSD I could easily add the device number
and inode number. The inode number is a unique number for each file
on a device. There is no corresponding thing on DOS/Windows as far
as I know, but maybe there's some extra info I could add.

I guess I'll stick this into the code before the multitasking release,
now that it's on my mind. That'll give me an excuse to delay the release
and go watch a DVD.  

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

19. Re: Rob?

• Posted by Jason Gade <jaygade at yahoo.com> Feb 10, 2006
• 497 views

Vincent wrote:
> 
> Robert Craig wrote:
> > 
> > Vincent wrote:
> > > Ok... I've thought about dir() some more and concluded that you can use
> > > that
> > > instead?

<snip>

> > Yes, I thought about this method a few days ago, when I mentioned
> > dir(), open() etc. in my private e-mail. The fact that it isn't perfect
> > bothered me at the time, but I think I can accept it. Congratulations.
> > 

<snip>

> Thank you! That makes me so happy to hear! I didn't think about the time
> stamps
> changing when files where copied, but even if that happens, the file name,
> attributes,
> and byte size will still all have to be the same for them to be ignored.
> Besides
> any modifications you make towards the files afterwords will make the system
> regain its full accuracy. In the future when you implement additional fields
> into dir(), that will make the accuracy even higher.
> 
> This fix alone is good enough for me to pay for the v3.0 translator upgrade.
> I think you have made the right decision for everyone here (including Igor)
> and for the future success of this language.
> 
> 
> Cheers,
> Vincent

SCOOOOORE! 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
j.

21. Re: Rob?

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 10, 2006
• 499 views

Vincent wrote:

> 
> Igor Kachan wrote:
> > 
> > I'll be just happy to type this long name in my Euphoria programs.
> > Then Euphoria code may be almost absolutelly platform independent. 
> 
> Well you will still be able to do that.

What that? Type long name?

But I'll be happy *to type some very specific long name*,
namely that one you have omitted here.

> > Do you see in EU docs : DOS, Windows, Linux?
> 
> I studied the include system much more than I would have liked.

Ok, but did you notice many platform specific graphics, sound and
mouse procedures and functions? These procedures and functions work
nice on DOS32, but they can not work on WIN32, Linux and FreeBSD.

EU programmer needs to learn Windows and *nix API to just put a pixel
on the screen with exw.exe and exu interpreters.

So, Euphoria needs some new_graphics.e library to make simple graphics
operations in full screen mode under Windows or Linux/FreeBSD control,
same as under DOS32 control.

There are a few such libs in the Archive, but they wrap Allegro or
SVGA, and so they are very version specific. 
   
> > Yes, I think that such a lib is one of the most needed.
> > Make it and I'll pay you my MicroMoney with pleasure.
> 
> What lib do you speak of? I'm not interested in the Micro-money but if you
> have
> an idea on a worthy project for me, I'd be glad to hear it.

A lib which gives simple standard DOS32 SVGA graphics on Windows and
Linux/FreeBSD.

Do you see this problem? DOS, WIN and LNX Euphorias are too different
on this part now because of very different graphics.

I think, it is a very good task, just for you, Vincent.      

[snip]

Regards,
Igor Kachan
kinz at peterlink.ru

23. Re: Rob?

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 10, 2006
• 485 views
• Last edited Feb 11, 2006

Vincent wrote:
 
> Igor Kachan wrote:

[snip]
 
> > A lib which gives simple standard DOS32 SVGA graphics on Windows and
> > Linux/FreeBSD.
> 
> > Do you see this problem? DOS, WIN and LNX Euphorias are too different
> > on this part now because of very different graphics.
> 
> > I think, it is a very good task, just for you, Vincent.      
> 
> OK... I see what your saying. Maybe I'll look into it later and check out the
> other libraries for ideas. It seems to me that there isn't any simple solution
> to cross-platform SVGA pixel graphics?

I do not know if there is a simple solution, I just hope it
may be simple enought if it is based on some kernel functions.

But task is complicated one, yes, I think.

Ok to finish this thread?

Good Luck!

Regards,
Igor Kachan
kinz at peterlink.ru

25. Re: Rob?

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 10, 2006
• 480 views
• Last edited Feb 11, 2006

Chris Burch wrote:

> There is already an SVGA lib wrapper in the archives (incomplete). The big
> problem
> with SVGA in Linux is that the library requires you to be root to run it, or
> else its very difficult to get running as a user. You would be far better off
> wrapping allegro for linux (honest), and running that on the xwindowing
> system.
> 
> Allegro is largely cross platform, and shouldn't be too difficult to make
> cross
> platform replacements for eu's pixel graphics system.
> 
> Chris
> 

Thanks for the information.

It wouldn't replace Euphoria's internal pixel graphic routines. I or someone
else would just submit a library to the archive or something.


Regards,
Vincent