bugKawa - Bugs: bug #19263, ...

 
 

bug #19263: /usr/local/lib/slib/require.scm:139:6: unbound location slib

Submitter:  Aubrey Jaffer <jaffer>
Submitted:  Fri 09 Mar 2007 08:47:36 PM UTC
   
 
Category:  Scheme language Severity:  3 - Normal
Item Group:  Run-time exception Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 27 Apr 2007 10:12:34 PM UTC, comment #9: 

 | From: Per Bothner <INVALID.NOREPLY@gnu.org>
 | Date: Thu, 26 Apr 2007 21:31:21 +0000
 |
 | Follow-up Comment #8, bug #19263 (project kawa):
 |
 | "So there are still issues with colon in variable names."
 |
 | I just checked in a patch which should help.

Yes it does.  It gets further in loading JACAL.  I reordered
slib/hash.scm so it loads.  But now JACAL fails to load because
there are colon-prefixed functions in both jacal/types.scm and
jacal/poly.scm which call functions in the other file.

I don't mind reordering a few files for Kawa's sake; but a major
reorganization of JACAL source is unreasonable.  Any ideas?

Aubrey Jaffer <jaffer>
Thu 26 Apr 2007 09:31:19 PM UTC, comment #8: 

"So there are still issues with colon in variable names."

I just checked in a patch which should help.

Per Bothner <bothner>
Group administrator
Thu 26 Apr 2007 06:52:19 PM UTC, comment #7: 

 | From: Per Bothner <INVALID.NOREPLY@gnu.org>
 | Date: Mon, 02 Apr 2007 07:13:05 +0000
 |
 | Follow-up Comment #6, bug #19263 (project kawa):
 |
 | The immediate problem is that the require function contains a
 | reference to slib:provided? before the definition of
 | slib:provided?...  A less ugly work-around is to move the
 | definitions of slib:provided?  earlier in require.scm.

Okay; I have reordered slib/require.scm so that it now loads into
Kawa.

 | Another problem happens with require and slib:require.
 |
 | Note that I really don't want to use require.scm at all in Kawa.
 | If slib is compiled, and we hook into the builtin-in require
 | syntax (not function) this particular problem becomes moot.

slib/require.scm will serve until it gets replaced.

Then I tried to run JACAL; but it chokes on the local variable names
in jacal/sexp.scm:

  (define (batch1)
    (do ((math:exit-saved math:exit)
(var-news-saved var-news)
(math:prompt #f))
        ...

Changing it to:

  (define (batch1)
    (define math:exit-saved math:exit)
    (define var-news-saved var-news)
    (define math:prompt #f)
    (do ()
...

gets past that hurdle; then it chokes on:

      ((call-with-current-continuation
(lambda (math:exit-cnt)

So there are still issues with colon in variable names.

Aubrey Jaffer <jaffer>
Mon 02 Apr 2007 07:13:04 AM UTC, comment #6: 

The immediate problem is that the require function contains a reference to slib:provided? before the definition of slib:provided?.  This is Ok when the whole file is processed as a unit, which happens when is compiled.  However, when a file is loaded, Kawa processes each top-level form individually, to be more compatible with other Scheme imeplementatiobs.  In this case, it doesn't realize there is a definition of slib:provided? when it comiles the require functions, so it compiles it as ($lookup$ slib 'provided?).

An ugly work-around is to wrap the entire body of require.scm by a (begin ...).  A less ugly work-around is to move the definitions of slib:provided? earlier in require.scm.

Another problem happens with require and slib:require.

Note that I really don't want to use require.scm at all in Kawa.    If slib is compiled, and we hook into the builtin-in require syntax (not function) this particular problem becomes moot.

Per Bothner <bothner>
Group administrator
Sun 01 Apr 2007 06:41:02 PM UTC, comment #5: 

 | Follow-up Comment #6, bug #19262 (project kawa):
 |
 | I checked into SVN some fixes to colon-handling.  If there are
 | still colon-related problems, could you send me a test-case with
 | instructions?

Download the development version of SLIB:
http://swiss.csail.mit.edu/ftpdir/users/jaffer/slib.zip

or checkout the CVS repository:
https://savannah.gnu.org/cvs/?group=slib


Install SLIB and put the attached "kawa.init" into the slib directory.
"cd slib"; then:

$ kawa
#|kawa:1|# (load "kawa.init")
#|kawa:2|# (require 'random)
/usr/local/lib/slib/require.scm:139:6: unbound location slib
at gnu.mapping.Location.get(Location.java:67)
at atInteractiveLevel$66.require(require.scm:138)
at atInteractiveLevel$66.apply1(require.scm:136)
at gnu.expr.ModuleMethod.apply1(ModuleMethod.java:182)
at gnu.expr.ModuleMethod.apply(ModuleMethod.java:153)
at gnu.mapping.CallContext.runUntilDone(CallContext.java:251)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:296)
at kawa.Shell.run(Shell.java:260)
at kawa.Shell.run(Shell.java:185)
at kawa.Shell.run(Shell.java:166)
at kawa.repl.main(repl.java:870)

If you can get past this problem, SLIB will try to write a file
"slibcat" to (implementation-vicinity), which "kawa.init" sets to
"/usr/local/src/kawa/".  Change "kawa.init" appropriately.


(file #12366)

Aubrey Jaffer <jaffer>
Mon 26 Mar 2007 12:01:27 AM UTC, comment #4: 


> The big difference between colon and dot is that dot was not a legal character in identifiers in R4RS.


But dot is valid is R5RS, so it's not a very strong argument.  Though if colon is more common a Scheme code than dot, that is a valid point.

However, there is code in Kawa to handle "legacy" code that uses colon as an identifier constituent.  It might be worthwhile trying to figure out why that isn't working.  If you send me something that isn't working because of colon handling I can take a look.

> Would using dot instead of colon be a possibility for Kawa?


There are tradeoffs.  It hurts XML and Common Lisp compatibility.
It would reduce "overloading" of the ':' character, but increase it for '.'.  It would be more compatible with Java syntax.

Most critical: it would be yet another change in Kawa syntax.  I can ask what people think - if I like it myself.

 > | Note if slib functions are shipped with Kawa it may be easonable add some optimizations.

> How would they be maintained; as patches against source; as

uncommitted CVS changes?

The current slib imports are just checked into the Kawa SVN sources.  Simple for me and people using Kawa.  The downside is that merging with a new slib release may require manual merging.

> But why not compile SLIB files and save in a distribution.  Won't the compiled size be smaller than the source?


The Kawa compile ".class" files tend to be larger than the source files, but they are highly compressible.

It's just that I think the Kawa source distribution should contain source files.  I have considered making and shipping a "kawa-extra" .jar file for various useful compiled classes, to make it easier to use Kawa for various applications.  A compiled slib could go into the kawa-extras.jar.  Or they could go into the min kawa.jar - but only if the source files are in the Kawa source distribution and SVN.

But lets worry about the technical issues first!


Per Bothner <bothner>
Group administrator
Sun 25 Mar 2007 10:55:33 PM UTC, comment #3: 

 | Date: Sun, 18 Mar 2007 22:51:07 -0700
 | From: Per Bothner <per@bothner.com>
 |
 | Kawa supports, partly for slib compatibility:
 |    (require 'symbol)
 | But there is a table that maps each symbol to a Java class,
 | and this mapping is done at compile-time.

Okay.  that table can serve as SLIB's catalog in Kawa.

 | I can certainly extend this table.  And/or we can provide a
 | mechanism to extend this mapping depending on the compile-time
 | environment.
 |
 | >  | However, the other complication is thta Kawa uses a "colon
 | >  | notation" for various purposes.  Basically:
 | >  |   foo:bar
 | >  | -means get the compoent with (literal) name bar if the value
 | >  | of (evaluating) foo.
 | >
 | > Kawa seems to be going it alone on this one.  I don't know of any
 | > other Scheme using ":" this way; and the nascent R6RS is not
 | > doing so.
 |
 | However, Common Lisp uses ':' for qualified symbols, as does the
 | XML world.  Kawa's use of ':' is basically a generalization (or at
 | least compatible with) these existing uses.
 |
 | Other Scheme implementations support a "dot notation" to name Java
 | fields, methods, and classes.  That isn't all that different -
 | Kawa's "colon notation" isn't that different from "dot notation" in
 | principle - but is more consistent and useful, I think.

The big difference between colon and dot is that dot was not a legal
character in identifiers in R4RS.  SLIB is fully compatible with R4RS,
having no symbols with dot in them.

Would using dot instead of colon be a possibility for Kawa?

 | > Can you provide some read-time control to make ":" just a normal
 | > character in symbols?
 |
 | ... I'd prefer some flag that change the reader.

Okay.

 | ...
 | Note if slib functions are shipped with Kawa it may be reasonable
 | add some optimizations.

How would they be maintained; as patches against source; as
uncommitted CVS changes?

 | Another factor is modularization and namespace management: It is
 | desirable to keep "module-internal" implementation functions and
 | variable "private" if such a module system is available.
 |
 | > As for DEFINE being renamed DEFINE-CONSTANT, that could be done by
 | > rewriting the files at installation time.  SLIB's functions
 | > FILE->EXPORTS or FEATURE->EXPORTS can be used to discover which
 | > functions are exported (is that the relevant distinction?).
 |
 | Yes.
 |
 | > ...
 | >  | out-of-the box, ideally without an init file.
 | >
 | > Okay.  Would this involve SLIB being part of Kawa.jar?
 |
 | That is the model I've explored in gnu/kawa/slib - selected parts
 | of slib are compiled to Java classes in the gnu.kawa.slib package.
 | (Though I've some other Scheme modules in the same package.)
 |
 | An alternative is a script (or Makefile rule) that would compile
 | Slib into an slib.jar file.  Kawa applications that use slib would
 | add slib.jar to their "classpath".
 |
 | The advantage of a script to build a separate slib.jar is that it
 | can be updated when slib is updated.  Another is that I'm not sure
 | everything in slib makes sense for Kawa, at least for as part of
 | kawa.jar.  For example Kawa has its own pretty-printer and an
 | implementation of CL-style format; it might be better for the slib
 | versions on those functions on Kawa to be a wrapper around the
 | builtin Kawa functions.  Of course that takes some work, especially
 | if the Kawa versions are missing slib functionality.

Only files chosen for Kawa compilation should be put in the jar.  Kawa
could maintain a list of SLIB and wrapper files to compile.

 | I do think the best way to require a feature under Kawa is to map a
 | feature to a class name, and then use the Java CLASSPATH mechanism
 | to find the class in a .jar archive.

That sounds good.

 | But that only works for compiled classes - though one could write
 | an "slib classloader" that compiles an slib source file on-the-fly
 | when needed.

But why not compile SLIB files and save in a distribution.  Won't the
compiled size be smaller than the source?

Aubrey Jaffer <jaffer>
Mon 19 Mar 2007 01:54:32 AM UTC, comment #2: 

 | From: Per Bothner <INVALID.NOREPLY@gnu.org>
 | Date: Fri, 16 Mar 2007 17:20:31 +0000
 |
 | Hm.  In Kawa require is syntax.  It basically is a compile-time "import
 | module" statement.

Programs call SLIB REQUIRE with a quoted argument; so that may serve
to distinguish the cases.

 | However, the other complication is thta Kawa uses a "colon notation" for
 | various purposes.  Basically:
 |   foo:bar
 | -means get the compoent with (literal) name bar if the value of
 | (evaluating) foo.

Kawa seems to be going it alone on this one.  I don't know of any
other Scheme using ":" this way; and the nascent R6RS is not doing so.
Can you provide some read-time control to make ":" just a normal
character in symbols?

 | Kawa does have some "compatibility hacks": If the compiler sees a
 | defining for the name |foo:bar| (and no definition of the symbol
 | |foo|) it will then treat foo:bar as referring to the former
 | definition.

There are many functions in SLIB which are defined both with a prefix
and without a prefix.  Is it okay if |foo:bar| and bar (as opposed to
|bar|) are defined?

We could write a program which creates Kawa copies of all the SLIB
modules having their ":" symbols wrapped in "|"s.

 | I'm in the process of trying to clean up top-level declaration, and
 | specifically the interaction between the run-time environment and
 | the compile-time top-level scope, so this stuff may change a bit.
 | In fact, it is possible what you've experienced may be something
 | that should be fixed.
 |
 | Kawa is focused on compilation.  I've imported a few slib packages
 | - see gnu/kawa/slib.

I compared "printf.scm"s; nearly all the changes were from the SLIB
side, mostly character constants.  Only two Kawa declarations were
added -- I don't think they would make any significant difference.
The function starting:

  (define-constant (stdio:round-string (str :: <string>) ndigs strip-0s)
    (let* ((n (- (string-length str) 1))
      ...

really shouldn't need to declare STR because the first call with
STRING-LENGTH clearly constrains STR to be a string.

As for DEFINE being renamed DEFINE-CONSTANT, that could be done by
rewriting the files at installation time.  SLIB's functions
FILE->EXPORTS or FEATURE->EXPORTS can be used to discover which
functions are exported (is that the relevant distinction?).

 | I'm open to changes to the Kawa system so Kawa can support slib

I have submitted two bugs for the issues gating Kawa/SLIB.

 | out-of-the box, ideally without an init file.

Okay.  Would this involve SLIB being part of Kawa.jar?  Not anchored
in a filesystem, and lacking GETENV, locating SLIB from Java is
difficult.

SLIB allows any implementation to integerate its compiled SLIB modules
(and non-SLIB modules).  SCM creates its catalog entries in
http://cvs.savannah.gnu.org/viewcvs/scm/scm/mkimpcat.scm?view=markup
which, supporting 4 types of dynamic linking, is more complicated than
a mkimpcat would be for other Scheme implementations.

Aubrey Jaffer <jaffer>
Fri 16 Mar 2007 05:20:30 PM UTC, comment #1: 

Hm.  In Kawa require is syntax.  It basically is a compile-time "import module" statement.

However, the other complication is thta Kawa uses a "colon notation" for various purposes.  Basically:
  foo:bar
-means get the compoent with (literal) name bar if the value of (evaluating) foo.

Kawa does have some "compatibility hacks": If the compiler sees a defining for the name |foo:bar| (and no definition of the symbol |foo|) it will then treat foo:bar as referring to the former definition.

I'm in the process of trying to clean up top-level declaration, and specifically the interaction between the run-time environment and the compile-time top-level scope, so this stuff may change a bit.  In fact, it is possible what you've experienced may be something that should be fixed.

Kawa is focused on compilation.  I've imported a few slib packages - see gnu/kawa/slib.

I'm open to changes to the Kawa system so Kawa can support slib out-of-the box, ideally without an init file.

Per Bothner <bothner>
Group administrator
Fri 09 Mar 2007 08:47:36 PM UTC, original submission:  

I am trying to port SLIB to Kawa.  The attached file loads without incident; but trying to require a package gives an "unbound location slib" error (appended).  slib/require.scm defines both require and slib:require.  Is this conflicting with the Kawa "require" syntax?

bash-3.1$ kawa --pedantic -f kawa.init -s
#|kawa:1|# require
#<procedure require>
#|kawa:2|# (slib:require 'random)
/usr/local/lib/slib/require.scm:139:6: unbound location slib
at gnu.mapping.Location.get(Location.java:67)
at atInteractiveLevel$65.require(require.scm:138)
at atInteractiveLevel$65.apply1(require.scm:136)
at gnu.expr.ModuleMethod.apply1(ModuleMethod.java:182)
at gnu.expr.ModuleMethod.apply(ModuleMethod.java:153)
at gnu.mapping.CallContext.runUntilDone(CallContext.java:251)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:296)
at kawa.Shell.run(Shell.java:230)
at kawa.Shell.run(Shell.java:172)
at kawa.Shell.run(Shell.java:159)
at kawa.repl.processArgs(repl.java:377)
at kawa.repl.main(repl.java:828)

Aubrey Jaffer <jaffer>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #12366:  kawa.init added by jaffer (12KiB - application/octet-stream)
file #12166:  kawa.init added by jaffer (12KiB - application/octet-stream - slib initialization file for kawa.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bothner (Posted a comment)
  • -email is unavailable- added by jaffer (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-04-01 jaffer Attached File- Added kawa.init, #12366
    2007-03-16 bothner StatusNone Need Info
    2007-03-09 jaffer Attached File- Added kawa.init, #12166

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code