OpenEuphoria

1. .il code/file questions

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 17, 2004
• 763 views

Questions:

1) Can I create (unshrouded) .il files that will run with backend.exe by using
the .il producing code in the PD source?

2) Can I translate .il files?

3) Why not release the Eu source for the translator?

What I really want to know is if I hack the Eu front-end, is there a way to use
this new front-end as usual with the rest of the Euphoria tools?  (i.e.
translating, or at least binding)  Obviously I can register the interpreter
source and create a modified interpreter.  It seems natural that since the
translator uses the same front-end now that I would also be able to create a
modified translator so that I can do all the things I can usually do, but with a
customized version of Eu.

Because what would really be desirable is to be able to develop programs in my
modified (front-end hacked) version of Euphoria and then be able to distribute an
executable of that program, preferably translated, or at least bound.  In other
words, I have no interest in creating & distributing a modified version of
Euphoria, but in creating a modified version of Euphoria for myself that I can
develop programs with.  However, if there is no way to distribute such developed
programs (as executables), then the worth of the whole thing is much less, at
least for me.

Possible?  Allowed?

3. Re: .il code/file questions

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 17, 2004
• 688 views
• Last edited Nov 18, 2004

Andy Serpa wrote:
> 1) Can I create (unshrouded) .il files that will run with backend.exe by using
> the
> .il producing code in the PD source?

No. The .il format is proprietary.
I'm trying to make Euphoria as open as possible,
while still having something to sell.
I can't let the whole world edit my source and
produce modified versions of Euphoria, that run at the same
speed as mine.
 
> 2) Can I translate .il files?

No. The owner of the .il can translate his original source.
Anyone else should not be allowed to convert a .il 
into readable C source.
 
> 3) Why not release the Eu source for the translator?
> 
> What I really want to know is if I hack the Eu front-end, is there a way to
> use this
> new front-end as usual with the rest of the Euphoria tools?  (i.e.
> translating, or
> at least binding)  Obviously I can register the interpreter source and create
> a modified
> interpreter.  It seems natural that since the translator uses the same
> front-end now
> that I would also be able to create a modified translator so that I can do all
> the
> things I can usually do, but with a customized version of Eu.
> 
> Because what would really be desirable is to be able to develop programs in my
> modified
> (front-end hacked) version of Euphoria and then be able to distribute an
> executable of
> that program, preferably translated, or at least bound.  In other words, I
> have no interest
> in creating & distributing a modified version of Euphoria, but in creating a
> modified
> version of Euphoria for myself that I can develop programs with.  However, if
> there is
> no way to distribute such developed programs (as executables), then the worth
> of the whole
> thing is much less, at least for me.
> 
> Possible?  Allowed?

In theory, I could sell the translator source, but with
the restriction that it can only be used for private use,
and not for creating and distributing new versions of Euphoria
to the masses. It would involve extra 
configuration/packaging/documenting/tech suport 
work for me, and I don't think there are very many people,
other than potential competitors,
who would have the ability or desire to modify the translator 
in a significant way, though some front-end changes might be easy.
In general, it's quite a bit more complicated than the interpreter.

It provides me with one of my last "fig leaves" in this
age of openness. 

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

5. Re: .il code/file questions

• Posted by Derek Parnell <ddparnell at bigpond.com> Nov 17, 2004
• 686 views
• Last edited Nov 18, 2004

Andy Serpa wrote:
> 
> Robert Craig wrote:
> > 
> > In theory, I could sell the translator source, but with
> > the restriction that it can only be used for private use,
> > and not for creating and distributing new versions of Euphoria
> > to the masses. It would involve extra 
> > configuration/packaging/documenting/tech suport 
> > work for me, and I don't think there are very many people,
> > other than potential competitors,
> > who would have the ability or desire to modify the translator 
> > in a significant way, though some front-end changes might be easy.
> > In general, it's quite a bit more complicated than the interpreter.
> > 
> > It provides me with one of my last "fig leaves" in this
> > age of openness. 
> > 
> 
> How about this?  You already have an open-source front-end.  Now we just have
> to get
> to the point where that can really be useful.  What I would like, and I think
> it would
> increase demand for sales rather than decrease it, is this: allow me or anyone
> to hack
> to the front-end to our heart's content, and then allow that front-end to be
> "plugged
> in" for use with the translator or binder.  We would still need to buy the
> binder from
> you to make .il files, and we would still have to register the translator to
> get rid
> of the delay.  Since the translator is now written in Euphoria, couldn't it
> actually
> just run as interpreted Euphoria instead of as an .exe?  You could shroud the
> proprietary
> parts of it, but allow us to replace the unshrouded front-end source files
> with our
> modified versions.  Isn't this basically what we can do with the interpreter
> if we
> register the source?  So let's allow it with the translator too -- a fully
> user-modifiable
> front-end that emits the same .il as usual, but arrived at differently because
> the
> user has modified the parser, etc.  I hope I am explaining clearly...

This is the sort of thing I was also suggesting. RDS doesn't lose on the
deal because the only thing we would be replacing is the free stuff anyway.

In fact, RDS needs to realize that they have multiple products - the free
Euphoria-to-IL converter(s) - the front-end, and the not-free binder that
can bind backend.exe to an IL to create a new .exe file.

I want to support RDS's backend because its very very good. Its just that
I would like to create the IL using a different tool than the free RDS
product.

I know that the current IL file format is proprietary but that doesn't
mean that another, public format, can't be devised and supported by 
bind.exe. In fact, I've already started documenting a file format
that could become the 'official' standard, after lot's of peer review.

It would be only if RDS refuses to support this idea, that some real
competition could evolve to challenge RDS's income stream. This is
a real win-win for all.

-- 
Derek Parnell
Melbourne, Australia

7. Re: .il code/file questions

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 19, 2004
• 694 views

Derek Parnell wrote:
> 
> Andy Serpa wrote:
> > 
> > Robert Craig wrote:
> > > 
> > > In theory, I could sell the translator source, but with
> > > the restriction that it can only be used for private use,
> > > and not for creating and distributing new versions of Euphoria
> > > to the masses. It would involve extra 
> > > configuration/packaging/documenting/tech suport 
> > > work for me, and I don't think there are very many people,
> > > other than potential competitors,
> > > who would have the ability or desire to modify the translator 
> > > in a significant way, though some front-end changes might be easy.
> > > In general, it's quite a bit more complicated than the interpreter.
> > > 
> > > It provides me with one of my last "fig leaves" in this
> > > age of openness. 
> > > 
> > 
> > How about this?  You already have an open-source front-end.  Now we just
> > have to get
> > to the point where that can really be useful.  What I would like, and I
> > think it would
> > increase demand for sales rather than decrease it, is this: allow me or
> > anyone to hack
> > to the front-end to our heart's content, and then allow that front-end to be
> > "plugged
> > in" for use with the translator or binder.  We would still need to buy the
> > binder from
> > you to make .il files, and we would still have to register the translator to
> > get rid
> > of the delay.  Since the translator is now written in Euphoria, couldn't it
> > actually
> > just run as interpreted Euphoria instead of as an .exe?  You could shroud
> > the proprietary
> > parts of it, but allow us to replace the unshrouded front-end source files
> > with our
> > modified versions.  Isn't this basically what we can do with the interpreter
> > if we
> > register the source?  So let's allow it with the translator too -- a fully
> > user-modifiable
> > front-end that emits the same .il as usual, but arrived at differently
> > because the
> > user has modified the parser, etc.  I hope I am explaining clearly...
> 
> This is the sort of thing I was also suggesting. RDS doesn't lose on the
> deal because the only thing we would be replacing is the free stuff anyway.
> 
> In fact, RDS needs to realize that they have multiple products - the free
> Euphoria-to-IL converter(s) - the front-end, and the not-free binder that
> can bind backend.exe to an IL to create a new .exe file.
> 
> I want to support RDS's backend because its very very good. Its just that
> I would like to create the IL using a different tool than the free RDS
> product.
> 
> I know that the current IL file format is proprietary but that doesn't
> mean that another, public format, can't be devised and supported by 
> bind.exe. In fact, I've already started documenting a file format
> that could become the 'official' standard, after lot's of peer review.
> 
> It would be only if RDS refuses to support this idea, that some real
> competition could evolve to challenge RDS's income stream. This is
> a real win-win for all.

Sorry for the slow response.
This is a tricky question to answer.

It may be premature to even try to settle this issue now.
After all, 2.5 has been out for all of two days.
Derek and Andy, you have little experience in modifying the
front end, and neither of you has described what 
changes you would like to make. You might discover that
you actually need back-end changes as well, to properly implement
some feature. The Euphoria back-end was designed
specifically to execute Euphoria programs, not a wide variety 
of assorted programming languages.

The Source Code product lets you make any changes you like, 
to either the front end, or the back-end. The only "catch" 
is that the interpreter you create must be for your own use. 
You can't distribute it to the world (unless it runs on a new
platform).

The Public Domain source lets anyone in the world, for free,
make any changes they like to the way the Euphoria interpreter works.
The only "catch" is that it runs slower than
the official interpreter. Translating it helps, but it's 
still slower.

I feel I'm already walking a tight rope, balancing openness
with the need to protect my income. It should be obvious
that I can't make it easy for people to produce their
own "enhanced" versions of Euphoria that run at the same speed
as mine, and can be distributed widely. That would be 
financially reckless, if not suicidal. I'm not saying
this proposal would necessarily do that, but I feel the tight rope
getting narrower.

I also feel I have enough product configurations on enough platforms
to keep me busy for now. Adding another configuration that 
would be used by only a few people wishing to create fast
personalized versions of Euphoria would probably not be a 
good use of my development/testing/documenting time.
But maybe I'll "see the light" after 2.5 has been out a while longer.

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

9. Re: .il code/file questions

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 19, 2004
• 682 views

On Thu, 18 Nov 2004 17:39:31 -0800, Robert Craig
<guest at RapidEuphoria.com> wrote:

>Derek Parnell wrote:
<snip>
>> I want to support RDS's backend because its very very good. Its just that
>> I would like to create the IL using a different tool than the free RDS
>> product.
<snip>

>You might discover that you actually need back-end changes as well,
> to properly implement some feature.
Hopefully that's unlikely. A lot of it seems to be syntactic sugar.

>The Source Code product lets you make any changes you like, 
>to either the front end, or the back-end. The only "catch" 
>is that the interpreter you create must be for your own use. 
>You can't distribute it to the world (unless it runs on a new
>platform).
Hmmm...

Excuse me for putting words in your mouth, but what I think you should
be saying is something like this (some parts unedited):

>The Public Domain source lets anyone in the world, for free,
>make any changes they like to the way the Euphoria interpreter works.
>The only "catch" is that it runs slower than
>the official interpreter. Translating it helps, but it's 
>still slower.

If you buy the sources, you get:

>   B. a bit of extra closed-source Euphoria code that 
>      interfaces the Euphoria front-end with my C back-end.

If you want to redistribute your modified compiler, you can, but not
including B. You can of course suggest to your users that they buy B
from RDS to make it run at full speed.

Am I missing something here?

Regards,
Pete

11. Re: .il code/file questions

• Posted by Tommy Carlier <tommy.carlier at telenet.be> Nov 19, 2004
• 676 views

Derek Parnell wrote:
> It's confirmed: I've am a moron. Sorry. 
> 
> I kept thinking that RDS would be reasonable, but I'm wasting my time here. 
> 
> I'll tidy up Win32lib and complete the contest, then I'm gone.

I wish you all the luck in the world. You've been one of the greatest
contributors, and an inspiration to us all. You've encouraged people to
create programs, you've dedicated a lot of time and effort to Win32Lib,
which has grown a lot lately, with many new marvelous features.
I really feel the Euphoria community could use more people like you,
who are not afraid to tell what they think, but who are always honest
and trying to help others.
The community won't be the same without you.

--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

13. Re: .il code/file questions

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 19, 2004
• 693 views

Robert Craig wrote:
> 
> Pete Lomax wrote:
> > Am I missing something here?
> 
> Probably not, though I don't completely understand your point.
> 
> At this time I feel I've opened things up a lot.
> I'm giving away 30% of the interpreter source as PD. I'm selling
> the rest for $79. Wait until 2.5 has been out for
> a while before trying to get me to consider wonderful new ways
> of opening things up. I'll be able to make a much better
> decision when some people actually start to do something with
> the PD and/or $79 source. Users will also understand better
> by that time what they can do, and what they want to do.
> If what they want to do is take full control of the source,
> add a bunch of "features", run at full speed, and put 
> me out of business, they'll have a long wait.
> 

I'm really having a tough time figuring out where the threat to your business
comes from.  People can already create modified versions of the interpreter than
run at full speed by buying the source from you.  So your defensive strategy is
to make sure that doing that is not useful for anything?  I for one was ready to
plunk down my money for the source, the binder, & the translator, but now knowing
that I won't actually be able to use the binder or the source for any useful
purpose -- i.e. create executables / actually be able to develop software --
what's the point?  This effectively reduces the "purposeful" new features of 2.5
to crash_routine() and the $ shorthand symbol.  So now I wondering if I should
even bother using 2.5 at all.  What we're proposing creates a demand for your
binder since it would be the only way to run .il code at full speed.  This all
seems so obvious I have a hard time accepting that you even understand what we
mean.

Take a simple example.  In v2.5, the '$' symbol now represents length(this
sequence).  Ok great.  So let's say I want to add some other stuff like that to
cut down on my own typing.  So I modify the front-end to add some new shorthand. 
For instance, maybe I'd have:

s &&= x

be equivalent to: s = append(s,x).

And maybe I'd implement assign on declaration, so I do this:

integer x = 4.

Just basic pre-processor type stuff.

Problem is, if I make those modifications, I CAN'T USE THEM!  Because now I
can't translate or bind programs than contain those shorthands.  So if I can't
even do simple pre-processor type stuff, then attempting to add more complex new
features (new functions, built-in support for external libraries, etc.) is also
out of the question.

So again, how would the above threaten you, esp. if I have to buy your binder or
translator still in order to do the binding or translating?  Your .il format can
remain proprietary, and everybody wins.  What's the problem?  You keep talking
about people releasing enhanced versions of the language itself, but anyone CAN
ALREADY DO THAT by buying the source from you (and breaking the license, of
course).  How is this a new or different threat?

15. Re: .il code/file questions

• Posted by "Kat" <gertie at visionsix.com> Nov 19, 2004
• 661 views

On 19 Nov 2004, at 0:23, Andy Serpa wrote:

> 
> 
> posted by: Andy Serpa <ac at onehorseshy.com>
> 
> Robert Craig wrote:
> > 
> > Pete Lomax wrote:
> > > Am I missing something here?
> > 
> > Probably not, though I don't completely understand your point.
> > 
> > At this time I feel I've opened things up a lot.
> > I'm giving away 30% of the interpreter source as PD. I'm selling
> > the rest for $79. Wait until 2.5 has been out for
> > a while before trying to get me to consider wonderful new ways
> > of opening things up. I'll be able to make a much better
> > decision when some people actually start to do something with
> > the PD and/or $79 source. Users will also understand better
> > by that time what they can do, and what they want to do.
> > If what they want to do is take full control of the source,
> > add a bunch of "features", run at full speed, and put 
> > me out of business, they'll have a long wait.
> > 
> 
> I'm really having a tough time figuring out where the threat to your business
> comes from.  People can already create modified versions of the interpreter
> than
> run at full speed by buying the source from you.  So your defensive strategy
> is
> to make sure that doing that is not useful for anything?  I for one was ready
> to
> plunk down my money for the source, the binder, & the translator, but now
> knowing that I won't actually be able to use the binder or the source for any
> useful purpose -- i.e. create executables / actually be able to develop
> software
> -- what's the point?  This effectively reduces the "purposeful" new features
> of
> 2.5 to crash_routine() and the $ shorthand symbol.  So now I wondering if I
> should even bother using 2.5 at all.  What we're proposing creates a demand
> for
> your binder since it would be the only way to run .il code at full speed. 
> This
> all seems so obvious I have a hard time accepting that you even understand
> what
> we mean.
> 
> Take a simple example.  In v2.5, the '$' symbol now represents length(this
> sequence).  Ok great.  So let's say I want to add some other stuff like that
> to
> cut down on my own typing.  So I modify the front-end to add some new
> shorthand.
>  For instance, maybe I'd have:
> 
> s &&= x
> 
> be equivalent to: s = append(s,x).
> 
> And maybe I'd implement assign on declaration, so I do this:
> 
> integer x = 4.
> 
> Just basic pre-processor type stuff.
> 
> Problem is, if I make those modifications, I CAN'T USE THEM!  Because now I
> can't translate or bind programs than contain those shorthands.  So if I can't
> even do simple pre-processor type stuff, then attempting to add more complex
> new
> features (new functions, built-in support for external libraries, etc.) is
> also
> out of the question.  
> 
> So again, how would the above threaten you, esp. if I have to buy your binder
> or
> translator still in order to do the binding or translating?  Your .il format
> can
> remain proprietary, and everybody wins.  What's the problem?  You keep talking
> about people releasing enhanced versions of the language itself, but anyone
> CAN
> ALREADY DO THAT by buying the source from you (and breaking the license, of
> course).  How is this a new or different threat?

I agree with this and with Derek,, what was the point to separating a 
front/back end if we cannot make full common sense use of the source to 
feed legal il code to the back end, and still bind that legal il code to the
back
end for exe and dll apps? What did you do that we aren't understanding, 
Robert? You say the il code is to remain hidden behind non-dissemination 
clauses, but we still cannot make it run with our own frontends (like for goto, 
case, with... localinclude, etc etc) using the RDS backend that we buy, 
because ... i forget why. Is this meant to put an end to projects like Bach? 
Just what was your vision for 2.5, Rob??

Kat

17. Re: .il code/file questions

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Nov 19, 2004
• 680 views

Robert Craig wrote:
> 
> Pete Lomax wrote:
> > Am I missing something here?
> 
> Probably not, though I don't completely understand your point.
> 
> At this time I feel I've opened things up a lot.
> I'm giving away 30% of the interpreter source as PD. I'm selling
> the rest for $79. Wait until 2.5 has been out for
> a while before trying to get me to consider wonderful new ways
> of opening things up. I'll be able to make a much better
> decision when some people actually start to do something with
> the PD and/or $79 source. Users will also understand better
> by that time what they can do, and what they want to do.
> If what they want to do is take full control of the source,
> add a bunch of "features", run at full speed, and put 
> me out of business, they'll have a long wait.

Rob, I think we understand your concern, however, I don't think anyone
has properly articulated what they're asking for.  We can currently
examine the PD front end and see the guts of il code and the symbol
table.  What we don't have is a way of turning that into an il file
that the backend can execute.

What I think is being asked for is basically a breaking up of bind.il,
so that instead of it compiling the il, it takes this as input, and then
does the magic shrouding and whatnot.  I suppose you could call it an
il translator.

Basically, you'd have to specify an input format for a pre-il file,
including anything that's needed from the front end, and then your 
code puts it into the format that the backend needs.  You could sell
this as part of the binding feature, or even separately.  Then people
could distribute their custom code as il files, but anyone who wanted to
use the custom language would need to buy your binding package.  Spun 
that way, it seems like a possible increase on the revenue stream.
Plus, of course, you could cherry pick what's out there for future 
releases.

It would give nearly immediate relief to those who have namespacing issues
(like what my modified interpreter addressed--if I can do it in C, then
I can *definitely* to it in Eu) or the include/cannonical paths issue.

So, to summarize, I don't think it's really opening anything else up,
but it does give an extra incentive to buy the binding package, and the
binding process becomes a two step process.

Matt Lewis

19. Re: .il code/file questions

• Posted by Jonas Temple <jtemple at yhti.net> Nov 19, 2004
• 689 views

Tommy Carlier wrote:
> 
> Derek Parnell wrote:
> > It's confirmed: I've am a moron. Sorry. 
> > 
> > I kept thinking that RDS would be reasonable, but I'm wasting my time here. 
> > 
> > I'll tidy up Win32lib and complete the contest, then I'm gone.
> 
> I wish you all the luck in the world. 

Wish him luck!?!?!?  We should be BEGGING him to stay!  Derek, on behalf of
the MANY of us who DEPEND on Win32Lib PLEASE STAY!!!!! (on vitural bended 
knee)  There are only a handful of people who would be able to take over
Win32Lib (myself not included) and I fear if you leave it will die!

> The community won't be the same without you.

I wholeheartedly agree.  Let's face it...without Win32Lib most of the Eu 
newbies would run away scared.  I realize there are other Windows
libraries and certainly "hats off" to their creators but I would guess 
that +/-75% of all Euphoria Windows programs were written with Win32Lib.

Derek your efforts are appreciated here and if you go ... (breaks down 
sobbing) ... then ... (sob) ... you'll certainly be missed!

Jonas Temple
http://www.yhti.net/~jktemple

21. Re: .il code/file questions

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 19, 2004
• 691 views

On Fri, 19 Nov 2004 15:09:27 +0000, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:

>You just want your $79 from every person in the chain, and then we can
>do what we like. Sounds fair play to me.

One last thing, before anyone jumps on me. If you create an
application as opposed to an interpreter, the end users do not have to
pay a fee, though you may have to distribute it bound because of the
restriction on redistributing myexw.exe (if, that is, it uses any new
language features you have devised)

Regards,
Pete

23. Re: .il code/file questions

• Posted by Mario Steele <eumario at trilake.net> Nov 19, 2004
• 679 views

Matt Lewis wrote:
> 
> Robert Craig wrote:
> > 
> > Pete Lomax wrote:
> > > Am I missing something here?
> > 
> > Probably not, though I don't completely understand your point.
> > 
> > At this time I feel I've opened things up a lot.
> > I'm giving away 30% of the interpreter source as PD. I'm selling
> > the rest for $79. Wait until 2.5 has been out for
> > a while before trying to get me to consider wonderful new ways
> > of opening things up. I'll be able to make a much better
> > decision when some people actually start to do something with
> > the PD and/or $79 source. Users will also understand better
> > by that time what they can do, and what they want to do.
> > If what they want to do is take full control of the source,
> > add a bunch of "features", run at full speed, and put 
> > me out of business, they'll have a long wait.
> 
> Rob, I think we understand your concern, however, I don't think anyone
> has properly articulated what they're asking for.  We can currently
> examine the PD front end and see the guts of il code and the symbol
> table.  What we don't have is a way of turning that into an il file
> that the backend can execute.
> 
> What I think is being asked for is basically a breaking up of bind.il,
> so that instead of it compiling the il, it takes this as input, and then
> does the magic shrouding and whatnot.  I suppose you could call it an
> il translator.
> 
> Basically, you'd have to specify an input format for a pre-il file,
> including anything that's needed from the front end, and then your 
> code puts it into the format that the backend needs.  You could sell
> this as part of the binding feature, or even separately.  Then people
> could distribute their custom code as il files, but anyone who wanted to
> use the custom language would need to buy your binding package.  Spun 
> that way, it seems like a possible increase on the revenue stream.
> Plus, of course, you could cherry pick what's out there for future 
> releases.
> 
> It would give nearly immediate relief to those who have namespacing issues
> (like what my modified interpreter addressed--if I can do it in C, then
> I can *definitely* to it in Eu) or the include/cannonical paths issue.
> 
> So, to summarize, I don't think it's really opening anything else up,
> but it does give an extra incentive to buy the binding package, and the
> binding process becomes a two step process.
> 
> Matt Lewis
> 

Hey all,

No, it's not a illusion, I get back online, 3 days after 2.5a is released.
WOOT!

First off, I just have to give my thumbs up to RobC for the work he has
done.  It looks exceptionally good.

Now, onto more matters, that actually deal with the thread at question.

I know, alot of people's gripes, and such on this subject, and I first
want to start off by defending RobC.  I don't know if many of you realize
this or not, but Robert has tooken a big ass leap from 2.4 to 2.5, and no
one has come to terms with appreciating this.  I'm not placing blame on
anyone here, I'm just pointing out the ovious.  Putting in full trace
support on the Public Domain Version of Euphoria, Increasing the speed
and compatability of Euphoria, to possibly offer versions on diffrent OS'
(Mac is still one I want to see it on), and even putting out a Open Source,
full version of the Interpreter code, for anyone to see, use, hack, slash,
dice, and slice, then call it thier own, is one tremendous leap forward.

But, at the same time, I do agree, with alot of you, about the restrictions
that still are implaced apon the language.  And I think Matt has provided
a more clear explination to what the users want.  And I'm gonna to clerify
this to a more certian extent, at which even Rob can appreciate the
possibilities that can come from doing this kind of deal.

As Matt has suggested, there is room to create a Euphoria To IL Tool, in
which Euphoria code, is fed to the system, to create IL Code.  This method
is the best, and most suitable causes for anyone here.  I don't think
anyone here, can honestly say, they want to see the hard code facts of
every peice of the IL Specification.  If I am wrong, please, speak up.

On the other hand, addressing Rob's fear that it would cut into his profits,
I would only like to say this.  Imagine if you would Rob, that one of us
creates a Off Bread language, or hybrid.  For example, Let's say, I want
to make a Euphoria and BASIC Hybrid.  Diffrent Syntax, and such, with my
own way of working things out.  I can build off of what euphoria offers
right now, with the PD Eu Version of the Interpreter, and make my own
scheme for binding files, and such.  Unfortunatly, this also means, that
as you have said in the release notes, it would be slower then your
Euphoria Interpreter.

But, if we use the previous suggestion, of creating a Intermediate
Euphoria to IL Converter, we bring forth a new way to improve things.
For you see, if I create this EuBASIC language, and say someone wants it,
get's it, and wants to compile programs, to run at fastest speeds, then
they can go back to RDS, and get the Binder System, in which to bind the
EuIL Code, to the backend, and make a Executable.

Because of this, the language relies soely on Euphoria to make executables,
as well as it's own code.  Now, to some, this may seem like a pre-proccess
language, but, in truth of it all, Euphoria itself, is a pre-process
language, so is C/C++, and any other language out there.  Before the code
can be run, it has to be compiled down into Byte Wise Code, weither it be
by pre-interpretation, or be it from run time interpretation.  The only
thing extra, in this hole deal, would be the conversion of whatever syntax
someone decides to use, into Euphoria type syntax.  Which euphoria then
turns into IL Code, for use with the Backend.  It's only adding a extra
step to the allready well established chain of events to making a program.

It would actually be doing, what C/C++ does allready, as Matt pointed out
with Linking.  And you don't see C/C++ Hurting all to much.  Personally,
I belive.... no, change that to I know..... that doing something of this
sort, would not be taking away from income that you get on Euphoria now
Robert, infact, you could look at it this way, that it would actually be
putting Euphoria out there, with more flexable features for the user, and
still comes back to you, in any event.

As one wise man once said, `Reap your harvest, but be sure to pay your
workers well.`  Think about it.

L8ers,
Mario

25. Re: .il code/file questions

• Posted by Tommy Carlier <tommy.carlier at telenet.be> Nov 19, 2004
• 653 views

cklester wrote:
> Tommy, sounds like you need to up the release date on that Win4Eu stuff.

I have a working version. With 'working version', I mean: you can create
the following types of Controls:
- Window

There is no documentation yet, except the few comments in the code.
I could release it, but it wouldn't be very impressive. It also wouldn't
be very useful for most people.

--
Recycle your pets.
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

27. Re: .il code/file questions

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 19, 2004
• 727 views

Pete Lomax wrote:
> 
> On Fri, 19 Nov 2004 15:09:27 +0000, Pete Lomax
> <petelomax at blueyonder.co.uk> wrote:
> 
> >You just want your $79 from every person in the chain, and then we can
> >do what we like. Sounds fair play to me.
> 
> One last thing, before anyone jumps on me. If you create an
> application as opposed to an interpreter, the end users do not have to
> pay a fee, though you may have to distribute it bound because of the
> restriction on redistributing myexw.exe (if, that is, it uses any new
> language features you have devised)
> 
Actually, Pete, you will NOT BE ABLE TO BIND IT (if it uses new features).  That
is the point I am making.  If you make new features, there is NO WAY TO USE THEM
IF YOU WANT TO CREATE EXECUTABLES.  Seems pretty silly.

29. Re: .il code/file questions

• Posted by cklester <cklester at yahoo.com> Nov 19, 2004
• 677 views

Tommy Carlier wrote:
> cklester wrote:
> > Tommy Carlier wrote:
> > > There is no documentation yet, except the few comments in the code.
> > > I could release it, but it wouldn't be very impressive. It also wouldn't
> > > be very useful for most people.
> > Are you still on schedule to release a documented, impressive, useful
> > version by December 25th, 2004? Merry Christmas!!! :)
> I never gave anybody a release date, or even thought about one.

:D Well, I asked Santa Claus for it!!! And he better deliver. :P

(I know you haven't given a release date. I was just pushin' ya. :) )

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

31. Re: .il code/file questions

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 19, 2004
• 693 views

Pete Lomax wrote:
> 
> On Thu, 18 Nov 2004 23:29:46 -0800, Robert Craig
> <guest at RapidEuphoria.com> wrote:
> 
> >Probably not, though I don't completely understand your point.
> The point is the words that you use, not that you necessarily offer
> anything radically different. Please correct me if I am wrong:
> 
> The new eu.ex is open source. I can modify it and distribute it as I
> please (but it's a tad slow).

Yes. In fact it's more than just "open source". For example,
the popular GNU license forces you to make your changes open. 
This PD source has no restrictions like that. You can make an
open or closed source and/or commercial program
and sell it for a million dollars.

> Assuming I don't modify execute.e, then if I purchase the source, it's
> a simple thing to create a full-featured (bar legacy shrouded code
> support), full speed interpreter (say myexw.exe).

Yes, for private use, not wide distribution.
I can imagine some company needing/wanting to make
a small change to Euphoria. This would allow them
to do so, possibly saving thousands of dollars of 
effort for $79.

Most (90%?) of the people who previously purchased
the source product had no intention of widely distributing modified
versions of Euphoria. Obviously, on this mailing list there
are several people with the publicly-stated intention,
and past history, of trying to develop Euphoria-like languages
regardless of the effect that has on RDS's bottom line. 
...I know, I know, you all want the best for Euphoria. 
You want to selflessly lead the Euphoria community to 
the "promised land". You don't want to put RDS out of business. 
You just want to clone Euphoria and distribute it free, 
at full speed, with open source, to all comers. 

> I can send myexw.exe to you, and it will or will not appear in the
> archive at your discretion.

Yes. If it provides some benefit to those who are using *Euphoria*,
I'll probably post it.

> Now, despite having purchased the source, I'm still at liberty to
> distribute the PD bits I modified, but not myexw.exe (which is the
> main change to the 2.5 license)

Yes you can distribute the PD stuff.
 
> I am allowed to tell people where to buy the source.
> I can supply instructions for recreating myexw.exe, or, if someone can
> prove they have purchased the source, I can send them myexw.exe.
> 
> As I re-read the new source license, it dawns upon me that maybe this
> is what you meant all along.
> 
> It all now seems a lot more reasonable to me.
> 
> You just want your $79 from every person in the chain, and then we can
> do what we like. Sounds fair play to me.

Yes, you can work with others on the source and you can
give your version of Euphoria to others, e.g. people
who have contracted with you to do a special app,
but everyone must pay $79 for a source license.

> One last thing, before anyone jumps on me. If you create an
> application as opposed to an interpreter, the end users do not have to
> pay a fee, though you may have to distribute it bound because of the
> restriction on redistributing myexw.exe (if, that is, it uses any new
> language features you have devised)

I don't think that's spelled out explicitly,
but the license does not say you can distribute
executables in bound or packaged form without the $79/person rule
kicking in. Nor does it say you can build/distribute something
other than an interpreter and avoid the $79 rule.

Of course the rules are completely different if you
want to port Euphoria to a new platform that it
doesn't already run on.

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

33. Re: .il code/file questions

• Posted by Ken Orr <orr_kenneth at yahoo.ca> Nov 20, 2004
• 685 views

Robert Craig wrote:
> 
> The Source Code product lets you make any changes you like, 
> to either the front end, or the back-end. The only "catch" 
> is that the interpreter you create must be for your own use. 
> You can't distribute it to the world (unless it runs on a new
> platform).

I suppose that Would rule out foreign languages versions also (i.e. Portuguese,
Russian,
French, etc). Eh?

 
> The Public Domain source lets anyone in the world, for free,
> make any changes they like to the way the Euphoria interpreter works.
> The only "catch" is that it runs slower than
> the official interpreter. Translating it helps, but it's 
> still slower.

Can I distribute an application and/or interpreter baased on modified Public
Domain eu source or
that is out too?

Ken

35. Re: .il code/file questions

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 20, 2004
• 689 views

codepilot Gmail Account wrote:

> Let me see here for a moment whats going on, just to see if I properly
> understand it all.
> 2.5 is
> 1. Addition of $ shorthand
> 2. front end euphoria parser Public Domain
> 3. New Backend.exe and BACKENDW.EXE thingies

4. The front end is not only Public Domain but also Open Source now
   (very instructive)!
5. A bound program can now provide a complete ex.err dump!
6. The internal changes make maintainance and adding new features much
   easier for RDS.
7. Compiler optimizations (probably due to the internal changes).
...

> Ok, now 1 is well understood.
> 2, the front end being PD is good, but can't be changed and still be
> able to bind/translate output bad, i guess change=slow eueu thing.
> 3, totally not understanding purpose, I guess there for binding too,
> but why are the in the public package if they can't be used without
> Registering?

No, 'backend.exe' is not for binding, but for running "shrouded" files
("shrouding" means something different for 2.5 than for versions < 2.5).
Say I bought the 2.5 binder/shrouder, and I put a "shrouded" program
'coolprog.il' on the User Contributions page. Then you need 'backend.exe'
to run that program, that's why it is in the public package. 
See 'bind.htm' for details.

Although prediction is difficult, especially about the future ,
I think that the number of "shrouded" contributions (in addition to
their respective source code) might increase. This is because source
code programs now start up (sometimes significantly) *slower* than with
Eu 2.4, while bound/shrouded programs now start up *faster* than with Eu
2.4.
Eu 2.4 also has a (sometimes significant) difference in startup time
between source code programs and bound/shrouded programs. This
difference has increased in Eu 2.5. So if I contribute a huge Eu 2.5
program, and want also newbies (who probably don't have the
binder/shrouder themselves) to be able run it, then I'll contribute
that program in bound/shrouded form.

> Perhaps I'm totally confused, so get your marketing people to start a
> consumer education program, or clearly outline these things somewhere,
> please.
>
> Daniel
> PS. I'm really happy that euphoria is taking some major steps, I just
> can't quite tell where it's going.

<snipped old text>

Regards,
   Juergen

37. Re: .il code/file questions

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 20, 2004
• 715 views

Tommy Carlier wrote:

> Derek Parnell wrote:
>> It's confirmed: I've am a moron. Sorry.
>>
>> I kept thinking that RDS would be reasonable, but I'm wasting my time here.
>>
>> I'll tidy up Win32lib and complete the contest, then I'm gone.
>
> I wish you all the luck in the world. You've been one of the greatest
> contributors, and an inspiration to us all. You've encouraged people to
> create programs, you've dedicated a lot of time and effort to Win32Lib,
> which has grown a lot lately, with many new marvelous features.
> I really feel the Euphoria community could use more people like you,
> who are not afraid to tell what they think, but who are always honest
> and trying to help others.
> The community won't be the same without you.

I wholeheartedly agree to your words, Tommy.

Derek, maybe you want to reconsider your decision? Pleeeeeeeease. 

Regards,
   Juergen

-- 
    |\      _,,,---,,_
    /,`.-'`'    -.  ;-;;,_
   |,4-  ) )-,_..;\ (  `'-'
  '---''(_/--'  `-'\_)

39. Re: .il code/file questions

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 21, 2004
• 706 views

Andy Serpa wrote:

> Robert Craig wrote:
>>
>> Pete Lomax wrote:
>>> Am I missing something here?
>>
>> Probably not, though I don't completely understand your point.
>>
>> At this time I feel I've opened things up a lot.
>> I'm giving away 30% of the interpreter source as PD. I'm selling
>> the rest for $79. Wait until 2.5 has been out for
>> a while before trying to get me to consider wonderful new ways
>> of opening things up. I'll be able to make a much better
>> decision when some people actually start to do something with
>> the PD and/or $79 source. Users will also understand better
>> by that time what they can do, and what they want to do.
>> If what they want to do is take full control of the source,
>> add a bunch of "features", run at full speed, and put
>> me out of business, they'll have a long wait.

<snip>

> Take a simple example.  In v2.5, the '$' symbol now represents
> length(this sequence).  Ok great.  So let's say I want to add some
> other stuff like that to cut down on my own typing.  So I modify the
> front-end to add some new shorthand.  For instance, maybe I'd have:
>
> s &&= x
>
> be equivalent to: s = append(s,x).
>
> And maybe I'd implement assign on declaration, so I do this:
>
> integer x = 4.
>
> Just basic pre-processor type stuff.
>
> Problem is, if I make those modifications, I CAN'T USE THEM!  Because
> now I can't translate or bind programs than contain those shorthands.

The latter is right, but that doesn't mean you can't use them at all.
When you change eu.ex, then you have your own modified Euphoria
interpreter. Using the Eu 2.5 translator, you can produce a standalone
eu.exe program from it.
Please don't get me wrong. I understand that you (and probably most of
us) want that their modified front-end is able to produce IL code, that
will be executed by the fast official 'backend.exe'. I just wanted to
point the above out, because I think we should be precise, in order not
to increase the current confusion here. 

> So if I can't even do simple pre-processor type stuff, then attempting
> to add more complex new features (new functions, built-in support for
> external libraries, etc.) is also out of the question.
>
> So again, how would the above threaten you, esp. if I have to buy your
> binder or translator still in order to do the binding or translating?
> Your .il format can remain proprietary, and everybody wins.  What's the
> problem?

I believe this could be a problem:
Say you create a fancy Eu front-end, that produces official IL code.
When you buy the binder, than you can make your own Euphoria interpreter,
that is as fast as the official interpreter, but has additional features.
This is threatening RDS, no? *Only you* have to buy the binder, the
users of your interpreter will not have to do so, like currently (and in
the past) no Eu user had to buy the binder.

A solution for RDS IMHO could be to make the license of the binder
similar to the license of the source code product: You are only allowed
to give your modified interpreter to people, who registered the binder.

Does that make sense? I'm not sure whether or not I'm also confused by
all this stuff. 

> You keep talking about people releasing enhanced versions of
> the language itself, but anyone CAN ALREADY DO THAT by buying the
> source from you (and breaking the license, of course).

This would be illegal.

> How is this a new or different threat?

*If* my above considerations apply (what I actually don't know), then
that could be threatening, no?
The existence of illegal threats is no reason for deliberately adding
legal threats.

Regards,
   Juergen

-- 
Have you read a good program lately?

41. Re: .il code/file questions

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Nov 21, 2004
• 695 views

Juergen Luethje wrote:
> 
> Matt Lewis wrote:
> >
> > Basically, you'd have to specify an input format for a pre-il file,
> > including anything that's needed from the front end, and then your
> > code puts it into the format that the backend needs.  You could sell
> > this as part of the binding feature, or even separately.  Then people
> > could distribute their custom code as il files, but anyone who wanted to
> > use the custom language would need to buy your binding package.
> 
> But when people distribute their custom code as EXE files (modified
> standalone Euphoria interpreter), things will look different, if I'm not
> too much confused. So maybe the license should only allow to distribute
> such "customized interpreters" in the form of IL files.

Er...not exactly.  What I'm suggesting is that, as part of the binding
package (or perhaps even separately), Rob provides an analog to 
bind.il.  It takes il code in an "unshrouded" format.  This could be
as simple as (from within the modified front end):

il_file = open( file_name, "w" )
    print( il_file, il_code )
    print( il_file, symtab )
    close(il_file)

Now, instead of bind.il running the frontend on regular Eu source, it
takes the il file and does whatever shrouding it would normally do,
and/or bind it to backend.exe.  The person who does this will have to
own the binder (just like right now).  Anyone else can run the bound
or shrouded code, because it works with backend.exe.  Anyone who wants
to actually work with the modified front end (i.e., its extensions or
new syntax or whatever) would need to buy the binder from Rob.  There's
no new licensing issues.
 
Matt Lewis

43. Re: .il code/file questions

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 21, 2004
• 683 views

Kat wrote:

> On 20 Nov 2004, at 16:56, Robert Craig wrote:
>
>> Juergen Luethje wrote:
>>> BTW, Rob:
>>> Can we do something like
>>>
>>> }}}
<eucode>
>>> include cool_lib.il
>>> </eucode>
{{{

>>>
>>> ?
>>
>> No. Not yet.
>> There aren't as many people wanting to make shrouded
>> libraries, as there are wanting to make bound or shrouded programs,
>> so I've put that aside for the time being.
>
> It's not so much a matter of a shrouded include as a pre-parsed include
> to save startup time!
>
> Kat

Absolutely! And I asked the question in exactly that context (which Rob
had snipped). Currently, using the Eu 2.5 alpha interpreter, the startup
time e.g. for several Win32Lib demo programs is unbearable for me.
Yes, my PC is older than 3 years, but everything except of Eu 2.5 alpha
runs fine here, and buying a new PC just for Eu 2.5 alpha would mean
"a little" too high price for the upgrade.

The only ways that I see to solve this problem is, to significantly
reduce the parsing time of the new interpreter front-end, or to make it
possible, that pre-parsed code (= IL files) can be included -- maybe
with a new keyword such as "link" rather than "include"?

Regards,
   Juergen

45. Re: .il code/file questions

• Posted by sixs <sixs at ida.net> Nov 22, 2004
• 692 views

Hello, <cid:part1.00090300.01070909 at ida.net>
I am looking at this program listing and I see win32lib as the include 
statement. I thought your programs didn't need win32lib or am i 
confused? for instant:
W32TBAR.EXW <cid:part1.00090300.01070909 at ida.net>

Jim

Bernie Ryan wrote:

>
>
>posted by: Bernie Ryan <xotron at bluefrog.com>
>
>Juergen Luethje wrote:
>  
>
>>Absolutely! And I asked the question in exactly that context (which Rob
>>had snipped). Currently, using the Eu 2.5 alpha interpreter, the startup
>>time e.g. for several Win32Lib demo programs is unbearable for me.
>>Yes, my PC is older than 3 years, but everything except of Eu 2.5 alpha
>>runs fine here, and buying a new PC just for Eu 2.5 alpha would mean
>>"a little" too high price for the upgrade.
>>
>>The only ways that I see to solve this problem is, to significantly
>>reduce the parsing time of the new interpreter front-end, or to make it
>>possible, that pre-parsed code (= IL files) can be included -- maybe
>>with a new keyword such as "link" rather than "include"?
>>    
>>
>Juergen:
>
>This is my biggest and only objection to ver. 2.5.
>We donate our time to write large usefull programs and libraries
>and RDS defeats all our efforts and time spent by coming out with
>a product that completely disregards our work.
>
>I have built my w32engin.ew library so that a user only needs
>to include this single library with NO EXTRA include file
>to build any windows program. It can run win32lib code or
>"C" style windows code and can be easily extended.
>
>A user with the public domain version is not going want to
>use any library that takes forever to load and parse.
>
>RDS's answer to the snail speed loading problem is to break it
>up into pieces and use seperate files depending on what the
>user wants to use it for. I don't think I should have to code
>my libraries to correct for a problem that was created by RDS.
>
>Whats wrong with RDS solving the real problem  ?
>
>Users of Euphoria are from a world-wide user base and some
>of them may not have the money to pay 80 dollars for the
>source or buy a fast computer just to run Euphoria at a 
>reasonable speed.
>
>It will be just a matter of time when someone that has
>ver 2.3 or 2.4 source will decide to write their own back-end
>by looking at the source and emulating the back-end.
>RDS will then lose control of a good programming langauge;
>who wants to see 1500 different versions of Euphoria out
>there. Not me.
>
>I only want to see one version of Euphoria that works
>properly that has one developer that listens to my
>requests which I am willing to pay for.  
>
>Bernie
>
>My files in archive:
>w32engin.ew mixedlib.e eu_engin.e win32eru.ew
>
>Can be downloaded here:
>>http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
>
>
>
>