Re: Bind features
Ralf Nieuwenhuijsen wrote:
>I just can't really come up with any 'real-life' example where you really
>want to a) bind, b) have unused constants remain for c) memory issues.
As a long-term goal, I'd like to make a game of some sort in Euphoria. I
have a few ideas I've been developing toward that goal. I've seen a few
Euphoria games already, and like with most other games, it's not uncommon
for these games to have many associated bitmap, sound, etc. files. Obviously,
I would expect mine to have associated files. Lately however, I've been
thinking through the benefits of putting some of the file data directly into
the source code, as constants.
If this is done, these files could wind up making large in-memory sequences,
either individually or in total. If the sequence(s) is/are used in primarily
one location in the program, which I comment out during testing/debugging,
I think I'd like any memory taken up by those constants to remain "occupied".
Would I seriously bind under this kind of condition, while still testing
and with the temporary comment still in place? Yes, I would....
It's not exactly an everyday scenario (you might not even consider it
"real-life"), but I wouldn't be in a hurry to dismiss it. Not that it matters;
letting the code removal be optional makes it a moot point.
>> >Secondly, now I think of it, bind could even do a lot of optimizations,
>and
>> >inline routines with less that X-number of statements.
>> >
>> >Routine-id can cause problems when 'inlining' and 'removing' un-used
>> >routines, however for each file routine-id is not used, all *local*
>routines
>> >can be removed. All un-used identifers should have issued a warning
>anyway.
>>
>> I've thought about the merits of inlining; especially in cases where
>> the routine is a function consisting of:
>>
>> function x (...)
>> return <expression>
>> end function
>>
>> the speed gains might be great (I'm constantly amazed at how relatively
>> low the overhead is for a routine call in Euphoria.) Of course, there's
>> still the routine_id problem (except for the local exception you
>described).
>
>Problem ? If its small enough to inline everywhere, you can easily keep the
>original routine in source code, so routine-id works correctly.
Mmm, interesting. I'm somewhat wary of that soulution, but rather
than wade through nagging quibbles (and considering I don't have an
alternative), I'll say it sounds like the simplest and most feasible
approach.
>> But another problem also comes to mind: error tracing. Pure, clean
>inlining
>> would mean that if your routine had an error, it would be very difficult
>to
>> track it to your routine. And if you included extra code, identifiers,
>etc.
>> to keep track of the fact that an "inlined" routine is being executed, and
>> what it's name is, you lose much of the advantage of inlining the code to
>> begin with.
>
>You bind you programs when you are developping and debugging them ?
>A lot of programs will crash, when bound, with the 300-statement thingie,
>since bind uses the pd-version of the interpreter, rather than the
>registered version. (logically)
Actually, if I were writing a program of such magnitude or value that I
intended to only distribute the bound version, I would *definitely* bind
and test things out periodically.
But yes, I also see your point. I'm so used to the registered version
that I've forgotten what it's like to hit that 300-statement limit.
Note: I'm not saying we should throw away the idea of inlining,
especially as a bind option. I was, however, thinking of problems that
might need to be addressed.
>> >Also, about the binder/shrouder: for editors and alike, why not keep the
>> >core in a library, shrouded, and the command-line interface as a dos32
>> >program ? (a simple interface that just used the core-library to shroud
>and
>> >bind program files)
>>
>> Well, if I were the one writing Euphoria, I don't think I'd want any of it
>> to be open source... *especially* parts of the binder, if that's what I
>> plan on using as an incentive to get people to register. Even making just
>> the main interface and parser freely available would seem like giving too
>> much away.
>
>Why ? It can only be used BY euphoria programs. Its not giving away C-code
>to parse Euphoria programs, it giving away Euphoria code to parse Euphoria
>code. Who would benefit ? Euphoria coders, the people that pay Robert's
>bill. It sounds logical to me.
Since my instinct would be to write a Euphoria parser in Euphoria using a
similar algorithm as in the C source, I'd probably be very wary of releasing
the parser, assuming the C algorithm wasn't open.
Clarification: by "any of it" I mean the C source code, and any important
Euphoria source code (read: the binder). I don't count example code (with
the possible exception of the editor), standard library routines like in
sort.e, etc.
>> Granted, I'd be interested in examining the code (NOT in modifying it),
>but
>> I think the chance of any of us ever doing that is close to nil.
>
>Rod, the binder is an shrouded Euphoria code. It is shrouded so we can't see
>the (optional) encryption code, so we can't crack it.
>All other parts of tools in Eu-code are fully open-source and even well
>commented.
>
>Guess, Robert is less paranoid than you assume.
As it stands, Rob hasn't seen fit to make Euphoria open-source (otherwise
we'd have the C code for the interpreter already, and we would be getting
it for Linux.) I definitely wouldn't mind if he made it so in the future,
but right now that doesn't seem likely.
Rob also hasn't seen fit to make the binder open-source. Encryption security
is an obvious reason not to, but considering its value even apart from that,
he might have still shrouded the program had there been no encryption option.
Or he might not have; Rob would have to respond to this thread himself for us
to know. I would still have shrouded it. That being so, if we never see parts
of the binder code available, I wouldn't be surprised. If we do, I'll be both
surprised and extremely interested. 
Rod Jackson
|
Not Categorized, Please Help
|
|
