Re: Bind features
> Ralf Nieuwenhuijsen wrote:
> >First of all, Rod's problem with 'altering' or 'removing' code because it
> >effects the program size, can be discarded.
> >If you want your programs to run on machines with so little memory, why
bind
> >in the first place ? (duh)
I'm assuming you were talking about conventional memory (where the
executable has to remain in)
If you talking about the type of program that would easily exceed extended
memory in program size, you might not be able to have it launch as an bound
program in the first place.
> I'm not sure I'm understanding you correctly here, Ralf. Are you saying
> a bound program takes up much more space in RAM than the interpreter and
> the unbound source would together?
No, the storage method however differs. Nevertheless, binding is not meant
for the very low-end systems.
I mean, I don't know any 286, without extended memory but with a 2.1 gig
harddrive, do you ?
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.
> >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.
> 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)
> >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.
> 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.
Ralf
|
Not Categorized, Please Help
|
|
