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.
Be warned with constants, they are in memory twice. Once in your source, and
once in the allocated memory for that constant. However, fortunately,
Euphoria, being one-pass will remove the memory the constant is using the
first time it reads the constant decleration. However, this is, when the
program is *not* bound. Otherwise, the executable is loaded, as a whole,
into the memory by the operating system.
Like I said, why bind, when memory is such an issue. You're much better off
using David's resource memory and a seperate resource file, if you do like
your game to be an executable.
> 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".
So, why not insert a dummy statement, so the binder does not remove them.
Something like:
object dummy
dummy = my_unused_object
Btw, being totally unused, is very rare, for things of this size.
The 'removal' is better applied upon *routines* and associated comments that
are part of libraries included, but not used by the program at all.
> Would I seriously bind under this kind of condition, while still testing
> and with the temporary comment still in place? Yes, I would....
Yes, to check the amount of memory. A simple calculation would do as well,
but, true I see a very rare case.
> 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.
Optional. Precizely why I at least want the front-end of the binder, which
might not be more than a few library calls, open-source. Also, for better
integration with development enviroments, for example.
> 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.
Wary ? Actually, inlining should only occur in certain routines and not all
routines.
Sometimes, inlining could *slow* down the program rather than *speeding* it
up.
Something to do wiht cache-sizes, I suppose.
But below a minimum and above a maximum size of statements, inline should
speed it up.
> >> 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.
That's not my point. The error-messages you were refering to do not apply to
bind.
Btw, the error message, can't make any sense anyway, since all identifers
are 'tokinezed' as well.
You wouldn't know which variables it is about.
Short and simple: if my routine had an error, euphoria does not need to
know it was inlined, it would not see the difference with the real code, and
thus, you do not loose the advantage. You run the code again, unshrouded,
unbound and you get a clean, fresh, normal, human-readable error-message.
> 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.
The problem already existed: error messages from bound programs are hard to
decipher.
> >> >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.
Again, the only reason the binder/shrouded itself has been shrouded, is to
sheal the encryption routines.
Many other tools (take a look in your /bin directory) are fully coded.
You really think, Euphoria's power comes from its parsing routines ?
The parsing routines, my guess, in the binder, aren't even close to those in
the interpreter.
Why ? Because they 1) are for different purposes. 2) are written, and
optimized for different languages 3) are/will-be one-pass/2-pass.
Whatever it is, its Robert's choice, but I, for one, would love to see some
standard parsing routines that return Euphoria code in some structured
sequence, as a standard Euphoria library. (shrouded or not 
> 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.
I didn't count example code either. Go have a look at your /bin directory.
> >> 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.
I wasn't talking about open-source. I can completely understand his choice.
All I ask for, is when he develops his new parsing routines, in Euphoria
code, for the binder (the 2-pass parser), why not make them as generic as
possible and available as include files. (shrouded or not).
And have the front-end of the binder open-source, which may just look like:
------- bind.ex
include bind.e -- shrouded file
puts (fh, bind ( encrypt ( shroud ( the_code ) ) ) )
-------------
Nothing given away here, yet it can be integrated much easier with
development tools and such.
> 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.
You obviously missed my point, what I wanted, and more precizely _why_ I
wanted it it that way.
I couldn't care less about open-source, I detest C-code and I don't intent
to copy Euphoria.
Ralf
|
Not Categorized, Please Help
|
|
