> -----Original Message-----
> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
> Sent: Thursday, August 06, 1998 1:30 PM
> To: Classpath
> Subject: Re: 1.1 vs. 1.2 revisited
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > LOW_MEM (optimize code to use as little memory as possible, rather
> > than speed, as we currently look at)
>
> I don't like this option. Do you know of any programs where they
> actively maintain a low memory/high memory version, which ships with
> the same source tree?
>
> This is just _way_ to complex to realisticly support.
>
You don't have to support it anywhere you don't want to.
But there are a lot of things I could do that take less memory and more
time. One notable place where this can be improved is in String, by
stripping away the extra optimization data (start_pos and cached hash code
come to mind). Not like every single class has to have both, just key ones
where a big difference can be made.
I want to point out that these options are only defined for this
project, not intrinsic to the preprocessor, and of course they should be a
consensus of all of us.
> > LESS_NATIVE (try to use absolutely as little native code as possible).
> > MORE_NATIVE (move more stuff into native than usual).
>
> I fail to see the purpose of these as well.
>
Actually, I was trying to accomodate your problem. I don't really like
these defines either. But what defines would you use to accomplish your
purpose? Will they be general enough to make some general statement?
> > I can bang the thing out over the weekend if everyone likes it.
>
> Would it be better if the preprocessor was part of guavac?
>
I think jpre should be a separate program ... "compiles only under guavac"
is not the intent of the project, far as I know. Though we could make it so
and I still wouldn't have a problem. Is guavac written in Java at all?
Then a bootstrap problem would be had. Otherwise, we're fine.
> --
> Paul Fisher * [EMAIL PROTECTED]
>
>
