This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Applet and Servlet Compile Options


> Perhaps we need to formalize this.  Maybe Translator needs a
> new method named commitModule or finishModuleHeader.  This
> would set SUPERTYPE_SPECIFIED if applet or servet is requested.
> It would also set a flag that the module header is done, perhaps
> ModuleExp#HEADER_FINISHED.  Then for example module-name would
> report an error if HEADER_FINISHED is set.  Likewise some
> of the module-compile-option would only be allowed in the header.
>

Ok, this is the approach I have taken for the new patch I attached. I
added a new method in Translator named `finishModuleHeader`. I was
unsure where to call the method exactly. If you could tell me where to
put it if it's at the wrong location, it would be great.

I removed the SUPERTYPE_SPECIFIED flag from `pushNewModule` and put in
the `finishedModuleHeader`. It's working good from the tests I have
made.

The only missing part is the
`HttpRequestContext.importServletDefinitions = 2;` flag. This piece of
code was set when `--servlet` was specified from the command line.
>From my findings, it was used only at one place, in the Scheme
language static initializer to load specific class into the language
instance.

    instance.loadClass(withServlets > 1 ? "gnu.kawa.servlet.servlets"
: "gnu.kawa.servlet.HTTP");

For now, the patch I attached does not set it anymore. However, it
seems to work ok from my testing by having a servlet compiled with the
new option and then started in a servlet container (Jetty Runner in my
case). So, I'm not sure what is the purpose of this flag exactly and
how I should integrate it into my patch. Should I check if servlet is
defined in the new `finishHeaderModule` and then load the class in the
Scheme language instance?

> Right now, if you compile a module like:
>
> (require whatever)
> (module-name bar)
>
> You get a rather uninformative error message:
>
> /tmp/foo.scm:2:1: duplicate module-name: old name: foo
>
> If we have a HEADER_FINISHED flag we could do better - e.g.:
>
> /tmp/foo.scm:2:1: module-name must be set in module header

With the new `finishedHeaderModule`, I aslo added the checks to ensure
that module header clauses are specified only in the module header.

The logic is the following. The code will check if the current syntax
is a module clause. If it's not and module header is not finished, we
call `finishModuleHeader`. If the syntax is a module header clause but
headers are already finished, it reports an error saying that
`syntax.getName()`. I'm unsure if the error reporting method I used is
the right one. Here the messages printed with the patch:

(compiling module-name-ok.scm to org.kawa.test.module.ok)
(compiling module-name-redefined.scm to module$Mnname$Mnredefined)
module-name-redefined.scm:2:1: module-name must be set in module header
module-name-redefined.scm:2:1: duplicate module-name: old name:
module$Mnname$Mnredefined

What do you think? Would it be possible to discard the second error
message somehow?

Regards,
Matt

Attachment: module-compile-options.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]