RE: Eu OpenSource Vision
- Posted by Pete E <xseal at harborside.com> Oct 02, 2001
- 376 views
David Cuny wrote: > Did that answer the question? Perhaps Pete or Menno would like to chime > in > here. Okay. I got an email from Menno the other day basically asking what am I doing and why he doesn't hear from me... > Pete sort of disappeared - he graduated, Class of 2000, Bachelors in CS > got a job, Rational Software - working with Apex (Ada/C++ IDE) > and hopefully a life. Still hoping. :) > Menno picked up on Pete's work and has been occasionally releasing > updates to > it, but it's sort of stagnated. Menno was using DJGPP or Borland and it stopping compiling on Linux or CygWin, so I gave up on maintaining it. > It's been mentioned that Pete's code is under-commented, Yeah, I regret not commenting it because now I can't even remember how it's supposed to work. > In fairness, Euphoria does a lot of stuff for the user behind the > scenes: > reference counting, garbage collecting, resizing sequences, making > unique > copies, slicing... Pete's was a bit more complex, because (if I recall > correctly) he also implemented strings as a seperate datatype. Getting > it to > work right is a rather delicate art - getting to work quickly and > efficiently > is something else all together. Yeah, it did internally keep two types of sequences. I felt that using 4 bytes instead of 1 was an awful waste when storing large amounts of text or graphics. Since most IO or graphics routines would have to convert the 4-byte to 1-byte anyway (via puts or poke) why not leave the sequence in that format. Irv and others were clamoring for that for a long time. It made the sequence operations slower because it always had to check what kind of sequence it was, and each operation was 4 to 8 times as complex (string op sequence, sequence op string, sequence op sequence, string op string, atom op sequence, atom op string, etc.) I've been giving (too much) thought to the concept of bit-sequences, as an alternate representation of integer types. This would allow faster bit slices or shifting without having to resort to silly hex masks and multiplication or floored division. I liked the recent post about a faster int_to_bytes using poke4+peek. That demonstrated exactly how unexpectedly inefficient euphoria can be about the most trivial things. > Yes. I think there were some cross-platform issues with Peuphoria. I was > > under the impression, for example, that Pete wasn't able to get it > running on > the Mac. There may have been Linux issues as well. I don't have a Mac (or emulator) or compiler with otherwise I would. I had compiled it on BeOS once, but I could never get the dynamic library stuff to work. Linux basically worked from the command line, there were a few problems with dynamic library routines but those were the source of some major headaches. > But I think if Pete got interested again, he could speed it up a bit. > (hint hint). I've got some ideas... they're just notes for now. I won't commit to anything though. > It's been a while since I've seen any release from Menno. > As far as I know, the project is basically dead. Basically. You can still download the various releases from http://www.harborside.com/~xseal/euphoria/ Later, Pete E.