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


On 03/04/2013 07:21 PM, Matthieu Vachon wrote:
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.

Thanks!


One quick buglet - the comment HEADER_FINISHED was copied
from USE_DEFINED_CLASS.

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.

For now, call it a the start of finishModule, and the start of require.scanForDefinitions (before checking PROLOG_PARSING).

It might be needed to cal it before regular definitions, but
probably not.

Also, make finishModuleHeader idempotent:  I.e. if HEADER_FINISHED
is already set, just return.

Also, drop the isModuleHeaderSyntax.  Instead, define a method
checkInModuleHeader().  This would check HEADER_FINISHED, and if
set report an error.  Call this from the various Syntax's scan methods.
I think this is more robust/extensible, rather than listing up
various syntaxes in isModuleHeaderSyntax/


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).

What happens if you compile the servlet with: --warn-undefined-variable --warn-unknown-member --warn-as-error while the functions define in those two modules?

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?

That may be appropriate.



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?

If you have module_name#scanForm call checkInModuleHeader then you can probably use that to supress the second error - perhaps by having checkInModuleHeader return a boolean. -- --Per Bothner per@bothner.com http://per.bothner.com/


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