1. IL examples
Hello Robert:
I thought it would be nice to have in the main Euphoria
package some ready Euphoria IL programs as examples of
what is the new IL paradigm really.
Say, both translators E-2-C or one of them.
Then you could make the registered translators compiled.
Now backend*.exes just hang up in the air and no one can
see what is an .il file.
Regards,
Igor Kachan
kinz at peterlink.ru
2. Re: IL examples
Igor Kachan wrote:
> I thought it would be nice to have in the main Euphoria
> package some ready Euphoria IL programs as examples of
> what is the new IL paradigm really.
>
> Say, both translators E-2-C or one of them.
> Then you could make the registered translators compiled.
At first I was going to include the PD translators in .il form,
and make the registered translators as .exe, just as you suggest.
However one of my goals with this release was to reduce the
number of different executables and .zip files that I have
to produce for a new release. Every component, PD or registered,
has to be tested on every platform before release,
and there were getting to be too many components. That's why
I got rid of PD vs Complete Translator, and PD vs Complete
Interpreter, and why I bundled all the Translator .zips
into the one Interpreter .zip. I also found, when translating
something like Judith's IDE that I appreciated the extra speed
from a translated/compiled translator.
> Now backend*.exes just hang up in the air and no one can
> see what is an .il file.
That's true.
Though there's not much to see in a .il.
Just a bunch of random characters all over your screen. 
I thought about just giving backend*.exe to those who register
and letting them distribute it along with their apps,
but it's better for the community if everyone has it automatically.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: IL examples
Robert Craig wrote:
[snip]
> At first I was going to include the PD translators in .il form,
> and make the registered translators as .exe, just as you suggest.
> However one of my goals with this release was to reduce the
> number of different executables and .zip files that I have
> to produce for a new release. Every component, PD or registered,
> has to be tested on every platform before release,
> and there were getting to be too many components. That's why
> I got rid of PD vs Complete Translator, and PD vs Complete
> Interpreter, and why I bundled all the Translator .zips
> into the one Interpreter .zip. I also found, when translating
> something like Judith's IDE that I appreciated the extra speed
> from a translated/compiled translator.
Ok, but I am sleeping and seeing EU 2.5+x on a single 1.44 floppy!
Really we have now 3 backends for DOS - the first one in the ex.exe,
the second one in the ec.exe and the third one as a stand alone
backend.exe, right?
Same picture with Win32. 3 backends in one package.
Let us use the "delete double" method here.
Why not, if I am not wrong in my calculations?
> > Now backend*.exes just hang up in the air and no one can
> > see what is an .il file.
>
> That's true.
> Though there's not much to see in a .il.
> Just a bunch of random characters all over your screen.
Yes, of course, "just a bunch" and "all over".
But people'd like to see some working IL code, I think.
Say, some shrouded demo-program, maybe, without open
source code. Just to avoid additional questions.
> I thought about just giving backend*.exe to those who register
> and letting them distribute it along with their apps,
> but it's better for the community if everyone has it automatically.
Yes, I love to see the backend*.exes in the main package.
Then, just a thought, it seems to me, translators may be combined
into a single multiplatform IL-based E-2-C translator.
What to do, dreams, dreams, dreams
Good Luck & Best Regards!
Igor Kachan,
kinz at peterlink.ru
4. Re: IL examples
Igor Kachan wrote:
> Ok, but I am sleeping and seeing EU 2.5+x on a single 1.44 floppy!
> Really we have now 3 backends for DOS - the first one in the ex.exe,
> the second one in the ec.exe and the third one as a stand alone
> backend.exe, right?
> Same picture with Win32. 3 backends in one package.
> Let us use the "delete double" method here.
> Why not, if I am not wrong in my calculations?
I need all 6 .exe's. There's not much I can do about it.
You need a different .exe format to run a Windows program
vs. a DOS program.
> > > Now backend*.exes just hang up in the air and no one can
> > > see what is an .il file.
> >
> > That's true.
> > Though there's not much to see in a .il.
> > Just a bunch of random characters all over your screen.
>
> Yes, of course, "just a bunch" and "all over".
> But people'd like to see some working IL code, I think.
> Say, some shrouded demo-program, maybe, without open
> source code. Just to avoid additional questions.
Those who register the Binder will see that the Binder
is in fact a .il file.
The binder/shrouder can bind or shroud itself.
The interpreter can interpret itself.
The translator can translate itself.
and all three can do their thing to the other two
Anyway, I understand what you mean. I'll think about it.
> > I thought about just giving backend*.exe to those who register
> > and letting them distribute it along with their apps,
> > but it's better for the community if everyone has it automatically.
>
> Yes, I love to see the backend*.exes in the main package.
>
> Then, just a thought, it seems to me, translators may be combined
> into a single multiplatform IL-based E-2-C translator.
> What to do, dreams, dreams, dreams
Yes that would be possible.
I'd still have as much testing to do,
but fewer files to worry about.
Although people with slow machines might get impatient
when translating something big.
I guess I'm content with the way I'm doing it now.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: IL examples
- Posted by "Kat" <gertie at visionsix.com>
Nov 26, 2004
-
Last edited Nov 27, 2004
On 26 Nov 2004, at 10:53, Robert Craig wrote:
<snip>
> Those who register the Binder will see that the Binder
> is in fact a .il file.
>
> The binder/shrouder can bind or shroud itself.
But you said earlier that we could not bind .il code to the RDS-supplied
backend?
Kat
6. Re: IL examples
Kat wrote:
> On 26 Nov 2004, at 10:53, Robert Craig wrote:
>
> <snip>
>
> > Those who register the Binder will see that the Binder
> > is in fact a .il file.
> >
> > The binder/shrouder can bind or shroud itself.
>
> But you said earlier that we could not bind .il code to the RDS-supplied
> backend?
If you register for the Binder you can.
I just meant that there's no way you could
simply grab the IL coming from the PD source interpreter
and slap it onto the RDS-supplied backend and expect it to work.
The exact IL format is proprietary and undocumented. It's the only
format that the backend will accept.
With the PD source you can do anything.
Make a binder. Make a backend. Whatever. That's up to you.
The .exe's you might eventually produce would be bigger
and much slower than if you register.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: IL examples
Robert Craig wrote:
>
> If you register for the Binder you can.
Huh? If you register for the Binder, you can bind the IL binary to the
RDS supplied backend?
Maybe I'm not getting this because I haven't started playing with it yet.
>
> I just meant that there's no way you could
> simply grab the IL coming from the PD source interpreter
> and slap it onto the RDS-supplied backend and expect it to work.
> The exact IL format is proprietary and undocumented. It's the only
> format that the backend will accept.
Right, so we can't -bind- the IL to the RDS-supplied backend. But we can
still treat it like we usually do, when we release the stuff with the PD
interpreter? It'll just grab the nearest IL file and run with it?
>
> With the PD source you can do anything.
> Make a binder. Make a backend. Whatever. That's up to you.
> The .exe's you might eventually produce would be bigger
> and much slower than if you register.
Right, but once again we're paying for an optimized binder, right?
Paying for the full version doesn't actually have some optimizations to
the backend, does it?
I... need to change my email address... hrm...
--Lord "LEVIATHAN"
8. Re: IL examples
Lord LEVIATHAN wrote:
>
> Robert Craig wrote:
>
> >
> > If you register for the Binder you can.
>
> Huh? If you register for the Binder, you can bind the IL binary to the
> RDS supplied backend?
>
> Maybe I'm not getting this because I haven't started playing with it yet.
>
> >
> > I just meant that there's no way you could
> > simply grab the IL coming from the PD source interpreter
> > and slap it onto the RDS-supplied backend and expect it to work.
> > The exact IL format is proprietary and undocumented. It's the only
> > format that the backend will accept.
>
> Right, so we can't -bind- the IL to the RDS-supplied backend. But we can
> still treat it like we usually do, when we release the stuff with the PD
> interpreter? It'll just grab the nearest IL file and run with it?
What are you reading? If you register the binder, you can shroud code
into an il file, which can be run by backend.exe. You can also bind that
il file to backend.exe, so it turns into a self contained executable. But
you can only use the RDS supplied tool to create the il file, since the
format is proprietary.
What many have been requesting, is for an alternate way to take 'unshrouded'
il code and turn it into the RDS proprietary format (call it an alternative
shrouder/binder).
Matt Lewis
