Re: [phix] what is a hybrid interpreter compiler?
- Posted by jimcbrown (admin) Feb 07, 2021
- 854 views
"Shared" was my first choice too.
Well, they do say that great minds think alike...;)
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.
Seriously?
Yes, seriously.
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.
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).
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, https://openeuphoria.org/ticket/357.wc
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.
Kat
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).
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.
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.
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.
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.
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.
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!
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.
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.
