Re: Comments on ORAC
CChris wrote:
>
> Pete Lomax wrote:
> >
> >
> > My bad, I really meant to say conditional compilation is only useful
> > for fixed literal constants, such as "constant ASSERT=1" then
> > "if ASSERT then", and/or stripping out assert() and trace() statements,
> > but not conditional includes imho. In the docs you listed:
> > * OS version string/{type,major,minor}
> > * Current video mode
> > * Screen size (text-mode)/resolution (graph mode).
> > * Current printer flags: technology (laser, inkjet, dot-matrix), PCL, etc..
> > * dpi values for screen and printer
> > * keyboard layout string
> > * Locale string or id
> > * Unicode support (current CP should be enough)
> > Now, if *ANY* of those were applied in the next public release of
> > Edita, or wxEuphoria, not too many people would likely be happy.
> > In other words I am not inspired with confidence by a system that
> > proposes to do such things, and given the choice I would disable such
> > permanently.
Heh. You *can't* turn off Unicode in wxEuphoria. Nyah nyah.
In fact, I think that you shouldn't even allow those. A cleaner solution
is probably to add some sort of command line switch to the interpreter:
$ exu -dDEBUG=1 myapp.ex
$ ecu -dDEBUG=1 myapp.ex
#if DEBUG=1 include libdebug.e
#else include librelease.e
#if DEBUG=1 assert()
Of course, the backend, bound and translated executables don't take any
special switches, since those decisions have all been made already. I
was actually just thinking about adding this concept of interpreter level
command switches this morning, specifically for extending the EUINC path:
$ exu -i$EUDIR/include/somelib myapp.ex
We'd probably want to do something creative with the result of
command_line(). I'd suggest stripping out the interpreter level stuff,
and maybe adding a new built in like interpreter_switch() or something
in order to access those options.
>
> > > Oh. BTW, what does Backward Compatibility mean? I never really knew what
> > > that was..
> > > .. does someone have a dictionary..?
> >
> > I think it means suitable for retarded people 
>
> Agreed.
I guess I really am special like my mom always told me.
> > > > Indirect routine calls:
> > > If we could do: xDeleteObject(hWnd) well, that would be just great.
> > > If someone could please tell me how to detect the difference between
> > > an integer that is the result of a dll link and an integer that is
> > > a routine_id
> >
> > CChris might know whether it is possible to merge the routine_id and
> > c_func tables in the backend or not.
> >
> > Alternatively, why not just add say #30000000 to define_c_proc results,
> > #20000000
> > to define_c_func, and #10000000 to routine_ids of procedures?
> >
> > Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
> > and if and_bits(n,#10000000) then it is a procedure else a function,
> > and mask these things with #0FFFFFFF before use.
>
> Merging is probably doable - there are always some pitfalls in merging things
> that are not processed in exactly the same way. I'd suggest rather using the
> lower 2 bits to stand for func vs proc and routine_id vs defined_c_routine.
> Basic
> indexes would increment by 4, and getting the table offset would be done by a
> fast >>2.
I don't see any benefit to merging the tables. You still have a check
to see what type of thing you're dealing with, but you've inflated the
required memory usage.
If you simply add something on the high bit, it's still a fast operation
to convert: id & 0x1fffffff (or whatever the correct value would be) to get
the location in the table.
Matt
|
Not Categorized, Please Help
|
|
