Re: relative includes in r7rs library definitions

Re: relative includes in r7rs library definitions

[Seth Alves]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]


On 11/21/2014 10:35 AM, Per Bothner wrote:
>
>
> On 11/21/2014 05:55 AM, Seth Alves wrote:
>> If a library definition has an (include ...) clause, it works out 
>> best if the path is considered relative to the sld file.
>> Kawa appears to consider the path to be relative to users current 
>> working directory.
>
> Note the latter is the value of the (current-path) parameter, not the 
> directory of the JVM process.
>
> Section 4.1.7 of the r7rs document says:
>>
>>    Note: Implementations are encouraged to search for files in
>>    the directory which contains the including file, and to provide
>>    a way for users to specify other directories to search.
>>
>> Would it be possible to get kawa to act this way?
>
> The problem is that Kawa (and other Scheme implementations) has both
> include and include-relative.  Historical include was relative to the
> current path, while include-relative is relative to the current file.

But isn't the (include ...) which is the child of an r7rs 
(define-library ...) different than these other forms of include? This 
one should be relative-only so that r5rs .scm files can be wrapped by 
.sld files and so that the user doesn't accidentally load something 
unexpected.

If both are paths checked, I'm confused about why my example fails. 
(I'll re-attach for the list).

>
> My compromise is that *both* functions search both locations,
> but include first searches current-directory and then file-relative,
> and include-relative does the opposite.
>
> I think this is a reasonable compromise betwn backward-compatibility 
> and r7rs.
>
> I might add a parameter to change the default.  Just as we have 
> -Dkawa.import.path
> we could have -Dkawa.include.path.
>
> P.S. Any reason why you're not using the Kawa mailing list for these 
> questions?
> I think that would be more appropriate.

Sorry, just doing lazy reply-tos.  I'll switch to the list.

     -seth


[-- Attachment #2: kawa-relative-include.tar.gz --]
[-- Type: application/gzip, Size: 440 bytes --]

Re: relative includes in r7rs library definitions

[Per Bothner]

On 11/21/2014 10:56 AM, Seth Alves wrote:
> If both paths [including-file-relative and current-directory-relative] are checked,
>  I'm confused about why my example fails. (I'll re-attach for the list).

There was an oops in the logic for Path.search.  I checked in a fix.

I'm considering adding a "kawa.include.path" property (by analogy with
"kawa.import.path").  I need to decide on a syntax to mean "relative to
the importing file".  I'm considering using '|' - which is an illegal
character in Windows file names.  A path like "|/utils" would search
the utils subdirectory of the directory containing the current file.

Using this syntax, currently the search path for include-relative is "|:." while
the search path for plain include is ".:|", where "." is the value of
(current-path).  The defaults would remain the same, but the "kawa.import.path"
property would override the default for include.  The search path for
include-relative would be "|" followed by the path for include.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: relative includes in r7rs library definitions

[Seth Alves]

Okay, the fix works for me.  The r7rs define-library (include ...) 
appears to search from the current directory before searching from the 
including file's directory.  If the order of these two were reversed, I 
would be happy.  I would also be happy with your proposed 
kawa.import.path property.

     -seth

On 11/23/2014 02:56 PM, Per Bothner wrote:
>
>
> On 11/21/2014 10:56 AM, Seth Alves wrote:
>> If both paths [including-file-relative and 
>> current-directory-relative] are checked,
>>  I'm confused about why my example fails. (I'll re-attach for the list).
>
> There was an oops in the logic for Path.search.  I checked in a fix.
>
> I'm considering adding a "kawa.include.path" property (by analogy with
> "kawa.import.path").  I need to decide on a syntax to mean "relative to
> the importing file".  I'm considering using '|' - which is an illegal
> character in Windows file names.  A path like "|/utils" would search
> the utils subdirectory of the directory containing the current file.
>
> Using this syntax, currently the search path for include-relative is 
> "|:." while
> the search path for plain include is ".:|", where "." is the value of
> (current-path).  The defaults would remain the same, but the 
> "kawa.import.path"
> property would override the default for include.  The search path for
> include-relative would be "|" followed by the path for include.

Re: relative includes in r7rs library definitions

[Per Bothner]

On 11/23/2014 02:56 PM, Per Bothner wrote:
> I'm considering adding a "kawa.include.path" property (by analogy with
> "kawa.import.path").  I need to decide on a syntax to mean "relative to
> the importing file".  I'm considering using '|' - which is an illegal
> character in Windows file names.  A path like "|/utils" would search
> the utils subdirectory of the directory containing the current file.
>
> Using this syntax, currently the search path for include-relative is "|:." while
> the search path for plain include is ".:|", where "." is the value of
> (current-path).  The defaults would remain the same, but the "kawa.import.path"
> property would override the default for include.  The search path for
> include-relative would be "|" followed by the path for include.

I checked this in.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: relative includes in r7rs library definitions

[Seth Alves]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]


Here's a contrived example of the situation I'd like kawa to handle.  
The directory structure looks like this:

./test-kawa.scm
./foo.sld
./foo.scm
./blerg/foo.sld
./blerg/foo.scm

The two foo.scm files define functions of the same name but with 
different return values.  The two foo.sld files wrap their respective 
foo.scm files into r7rs libraries.  test-kawa.sld imports both and 
avoids a name conflict with (prefix ...).

Without -Dkawa.include.path='|:.' it prints:

this is the second one
this is the second one

(unless I cd to another directory before running the script... *then* I 
get the desired output.  This helps illustrate why search paths should 
be relative to the including file, not the user's current directory)

with it, I get a crash.

./test-kawa.scm:12:32: unexpected exception while compiling: 
java.lang.IllegalArgumentException: Illegal character in path at index 
37: ./scheme/base.sld-Dkawa.include.path=|
java.lang.IllegalArgumentException: Illegal character in path at index 
37: ./scheme/base.sld-Dkawa.include.path=|
     at java.net.URI.create(URI.java:859)

The output I'm hoping for is

this is the first one
this is the second one

Please see attached.

     -seth

On 11/25/2014 12:03 AM, Per Bothner wrote:
>
>
> On 11/23/2014 02:56 PM, Per Bothner wrote:
>> I'm considering adding a "kawa.include.path" property (by analogy with
>> "kawa.import.path").  I need to decide on a syntax to mean "relative to
>> the importing file".  I'm considering using '|' - which is an illegal
>> character in Windows file names.  A path like "|/utils" would search
>> the utils subdirectory of the directory containing the current file.
>>
>> Using this syntax, currently the search path for include-relative is 
>> "|:." while
>> the search path for plain include is ".:|", where "." is the value of
>> (current-path).  The defaults would remain the same, but the 
>> "kawa.import.path"
>> property would override the default for include.  The search path for
>> include-relative would be "|" followed by the path for include.
>
> I checked this in.


[-- Attachment #2: kawa-relative-include-redux.tar.gz --]
[-- Type: application/gzip, Size: 565 bytes --]

Re: relative includes in r7rs library definitions

[Per Bothner]

On 11/25/2014 07:12 AM, Seth Alves wrote:
> with [ -Dkawa.include.path='|:.' ] , I get a crash.
>
> ./test-kawa.scm:12:32: unexpected exception while compiling: java.lang.IllegalArgumentException: Illegal character in path at index 37: ./scheme/base.sld-Dkawa.include.path=|
> java.lang.IllegalArgumentException: Illegal character in path at index 37: ./scheme/base.sld-Dkawa.include.path=|
>      at java.net.URI.create(URI.java:859)

I'm not seeing anything like that.  Looks like Kawa is getting invoked with the second
-D option being pasted onto the first.  I'd verify this by printing out the
args (one to a line) in the top of the main method in kawa/repl.scm.

> The output I'm hoping for is
>
> this is the first one
> this is the second one

Works for me:

$ ./test-kawa.scm
this is the first one
this is the second one



-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: relative includes in r7rs library definitions

[Seth Alves]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

I see... the shell script is mangling the arguments together.  This 
patch (attached) makes it work for me.

     -seth


On 11/25/2014 12:39 PM, Per Bothner wrote:
>
>
> On 11/25/2014 07:12 AM, Seth Alves wrote:
>> with [ -Dkawa.include.path='|:.' ] , I get a crash.
>>
>> ./test-kawa.scm:12:32: unexpected exception while compiling: 
>> java.lang.IllegalArgumentException: Illegal character in path at 
>> index 37: ./scheme/base.sld-Dkawa.include.path=|
>> java.lang.IllegalArgumentException: Illegal character in path at 
>> index 37: ./scheme/base.sld-Dkawa.include.path=|
>>      at java.net.URI.create(URI.java:859)
>
> I'm not seeing anything like that.  Looks like Kawa is getting invoked 
> with the second
> -D option being pasted onto the first.  I'd verify this by printing 
> out the
> args (one to a line) in the top of the main method in kawa/repl.scm.
>
>> The output I'm hoping for is
>>
>> this is the first one
>> this is the second one
>
> Works for me:
>
> $ ./test-kawa.scm
> this is the first one
> this is the second one
>
>
>


[-- Attachment #2: kawa-sh-patch --]
[-- Type: text/plain, Size: 822 bytes --]

Index: bin/kawa.sh.in
===================================================================
--- bin/kawa.sh.in	(revision 8173)
+++ bin/kawa.sh.in	(working copy)
@@ -29,7 +29,7 @@
         for arg in "$@"; do
             case "$arg" in
                 -D* | -J*)
-                    jvm_args+="$arg"
+                    jvm_args+=" $arg"
                     shift
                 ;;
                 *) break
@@ -36,7 +36,7 @@
                 ;;
             esac
         done
-        exec ${JAVA-"java"} -Dkawa.command.line="${command_line}" "${jvm_args[@]}" kawa.repl ${no_console} "$@"
+        exec ${JAVA-"java"} -Dkawa.command.line="${command_line}" ${jvm_args[@]} kawa.repl ${no_console} "$@"
         ;;
     *)
         exec ${JAVA-"java"} -Dkawa.command.line="${command_line}" kawa.repl ${no_console} "$@"

Re: relative includes in r7rs library definitions

[Per Bothner]

On 11/25/2014 04:40 PM, Seth Alves wrote:
> I see... the [kawa.sh] script is mangling the arguments together.  This patch (attached) makes it work for me.

What shell are you using?  The patch doesn't handle arguments with spaces.
Dealing with space (and special characters) is why the script uses bash/ksh arrays.

The problems seems to be that this statement:
     jvm_args+="$arg"
does string appending, rather than array appending.

I experimented some, and it looks like the following works, at least on ksh:
     jvm_args+=("$arg")

An alternative that may be more portable (though it also goes beyond Posix):
     jvm_args[i++]="$arg"

That assumes i has been initialized to 0 (before the for loop):
     i=0

Could you try one of:
     jvm_args+=("$arg")
     jvm_args[i++]="$arg"
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: relative includes in r7rs library definitions

[Seth Alves]

These both seem to work for me.  I'm running on Ubuntu 14.04, the shell 
I get is /bin/bash:

ii  bash           4.3-7ubuntu1 amd64        GNU Bourne Again SHell

Also on this system is /bin/sh (which kawa's configure does not choose)

ii  dash           0.5.7-4ubunt amd64        POSIX-compliant shell

     -seth


On 11/25/2014 11:30 PM, Per Bothner wrote:
> I experimented some, and it looks like the following works, at least 
> on ksh:
>     jvm_args+=("$arg")
>
> An alternative that may be more portable (though it also goes beyond 
> Posix):
>     jvm_args[i++]="$arg" 

Re: relative includes in r7rs library definitions

[Per Bothner]

On 11/25/2014 11:30 PM, Per Bothner wrote:
> On 11/25/2014 04:40 PM, Seth Alves wrote:
>> I see... the [kawa.sh] script is mangling the arguments together.  This patch (attached) makes it work for me.
> ....
> An alternative that may be more portable (though it also goes beyond Posix):
>      jvm_args[i++]="$arg"

Checked this in.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

include vs include-relative

[Per Bothner]

The question raised by Seth is: should the include form *by default* act
like include-relative by first searching relative to the current file?

This question only changs the default  and it's a 1-line change, so it
easy to make.  More detail:

Option 1: The default search order include, as currently checked in:
First current working directory (as returned by (current-path); then the
directory of the file containing the include form.  Or expressed in the
syntax of the kawa.include.path property: ".:|"

Option 2: The other way round, i.e. "|".".  The makes the default for include
the same as the default for include-relative.

Regardless: The would only change the default.  Setting the kawa.include.path
property (or the Include.searchPath ThreadLocal) overrides the default path.

Also regardless: include-relative would search the directory of the file containing
the include form, and *then* whatever search path is specified for include (default
or non-default).

Advantage of Option 1: Better historical compatibility.  Plus it's weird having
both include and include-relative if they do the same thing (at least by default).

Advantage of Option 2: 99% of the time you probably *do* want to first search
relative.  Plus it is more compatible with spirit of the r7rs recommendation.

Anyone else have an opinion?
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/