Re: [phix] what is a hybrid interpreter compiler?

new topic     » goto parent     » topic index » view thread      » older message » newer message
katsmeow said...

"Shared" was my first choice too.

Well, they do say that great minds think alike...;)

katsmeow said...

Over the many years here, i was only shot down for linking EU/OE to Mirc.

I vaguely recall this, but my recollection was that this occured in the early aughts - before RDS EU became open source. (Back then, RobCraig wasn't accepting any code contributions or library changes from anyone - aside from minor bug fixes. The best you could hope for was to get something into the archives.) If that's right, then sadly, the stuff was already deleted by the time that the OE dev team first came together.

It is quite sad, as if you still had the code and were willing to share it, I could guarantee that your code would get a very different reception today.

katsmeow said...


Yes, seriously.

katsmeow said...

Mirc gave me easy gui, easy windows event-driven and threaded access. Mirc was a ready irc interface to #Euphoria on irc,

OE gave me speed and unlimited variable size

Sounds like a nice pairing.

katsmeow said...

But i wrote a threaded web server in mirc before OE had http.e, and the server wasn't blocking.

Sounds like OE was a little late to the party. We can already have non-blocking http in OE today, many years later. Still not threaded (unless you count Phix or the experimental branches).

katsmeow said...

Anyhow, i deleted all the "shared" variables code from the computers. even after my irc.e was rejected and i deleted all that code.

Someone reading this might wonder how mIRC is relevant to the earlier posts - basically, with all the things you claim to have been able to do with RDS Eu with the extra boost from mIRC, adding the shared variable stuff across processes, networks, and so on would have been so so much easier.

At this point in time I do not recollect that anyone aside from jeremy_c ever submitting an irc.e to the Eu dev team. Jeremy wasn't happy with his own irc.e from his EuChat project (though now I don't recollect why) and there weren't really any other contenders. If someone were to submit something now, I'm sure it'd be accepted, albeit with perhaps some modifications.

It's still an open ticket for OE to add a net/irc.e in,

katsmeow said...

I've been hoping Eu would greatly improve, become a shining light in the dark, for over 20 years now, with attempts to copy a few features here and there. It's simply not going to happen.

I'm in my 60's. No one is going to improve OE enough in the time i have left.


I've come around to agreeing with you. Nowadays I have not enough free time to help out myself, and Greg can't go at it alone. (Not that I've given up on Greg, just that I think it's unreasonable to expect too much from him too fast unless he's able to get some help.)

I've got more hopes for Phix now (and I wouldn't mind if Phix took over as the official Euphorian dialect).

katsmeow said...

Also... jimcbrown , the shared vars could have been used to let OE execute strings,

Yes. I can see how one possible implementation might have worked - copy the strings into a temp file, execute it in a new process, and pass the results back. Instant REPL.

katsmeow said...

which was roundly shot down more than once.

Not by me. Remember, I set up an experimental branch to add support for IL execution and self-modifying code.

katsmeow said...

And it would have been a patch for compiled programs that use http.e, which blocks,

Actually, it's pretty trivial to make it non-blocking on nix.

katsmeow said...

and won't run compiled if tasks are used.

The issue IIRC was that compiling a shared library meant that tasks couldn't be used. And someone was trying to compile http.e into a shared library, so that was modified so it still used tasks (compiled or interpreted or bound) UNLESS it was compiled as a shared library - then it'd still work, just without tasks (since in that mode tasks were not available). So it's not an issue you'd hit unless you started using compiled Eu.

katsmeow said...

I was/am plenty happy running Eu as interpreted or bound.

It's not an issue you'd hit unless you started using compiled Eu.

katsmeow said...

So if the incoming data in http.e was assigned to a shared variable in http.e, it would automagically appear in a non-blocking way in the main program as http.e recieved it.

That's pretty neat!

katsmeow said...

I pinned enough hope on Eu that the cluster i built, with spares, totalled 14 P4 desktops, stuffed with as much ram and hdds as they'd take. And gigabit lan. I replaced it with five i5 machines and a i7 a few years ago. I admit i still have two P4 runnng. I have not disassembled all the P4 yet, but there's 48 330GB hdds in a box under the table. It's all such a waste.

Hmm, I don't get it. It still sounds like you could be using that cluster if you did one of:

1. Using Eu + mIRC to provide threads/non-blocking/shared vars

2. Phix, with it's native thread support

3. The experimental OE branches that I set up for threads and self-modifying code.

Perhaps it's just timing - just guessing here, but maybe the cluster was already taken apart by the time Phix supported threads and the experimental branches came out.

euphoric said...

Or... maybe... fork Euphoria and make it do what you want. That might be your penultimate pathway!

OE would be a poor choice due to the fact that so much of it is still written in C.

Phix, which is done in just assembly and .. Phix, would be a much better choice. It already has a lot of what was wanted, so the gap to close would also be much smaller.

new topic     » goto parent     » topic index » view thread      » older message » newer message


Quick Links

User menu

Not signed in.

Misc Menu