Re: [Jscheme-user] Problems loading contributed scheme code+install stuff

[Timothy J H. <tjh...@br...>]

Hi Joseph,
   I'm away from work for a week (with a Mac but no Linux, and hence no 
jdk1.5...)
I'll look into it when I return, but I think the problem is in the 
implementation of
quasistrings. Tatu Tarvainen diagnosed the problem in an jscheme-devel 
email
last October 22 (2004):

> Some Java-calls don't seem to work under JDK 1.5.0.
> Using quasi-strings fails, because the StringBuffer append method 
> fails.
>
> This happens with the latest jscheme jar and the CVS version.
> I think the reflective access to the append method fails because in 
> Java
> 5 the java.lang.StringBuffer class inherits from a new
> java.lang.AbstractStringBuilder class which is not public and also
> provides the append method.
>

Since I work mainly on the Mac I haven't been using jdk1.5. I'll 
install it on my
Linux box when I return and see how it works. The fix is probably to 
modify
the code implementing quasistrings by replacing all  (.append sb ...) 
calls with
(.StringBuffer.append sb ....)

In jscheme/src/jsint/primproc.scm modify the following procedure

(define (!{} . args)
   ;; KRA 21JUN04: This is like (apply string-append (flaten args)).
   (let loop
       ((args args)
        (sb (StringBuffer.)))
     (cond ((null? args) (.toString sb))
           ((pair? (car args))
            (loop (cons (car (car args))
                        (cons (cdr (car args)) (cdr args))) sb))
           ((null? (car args)) (loop (cdr args) sb))
           (else (.append sb (U.stringify (car args) #f))
                 (loop (cdr args) sb)))))

by replacing the .append with .StringBuffer.append

That's my best guess for fixing the problem....
I'll try it when I return on Monday, but you could try it earlier if you
want.





On Feb 22, 2005, at 6:20 PM, Joseph Toman wrote:

>
>
>
>
> A) These are in reverse order, but the transcript below is so long I 
> thought this might get lost. After B) I tried getting the current 
> codebase from CVS and building it. I'm sure this marks me as not being 
> a true-believer, but wouldn't a Makefile or a build.xml be perhaps 
> less exciting, but ultimately more useful ? Suffice to say I couldn't 
> get it
> to build, though I got very close once I abandoned the default method 
> and built an Eclipse project for it. build.CompilingLoadlet uses 
> internal sun.* classes which apparently didn't make it to JDK 1.5,
Ahhh. I'll have to look into this also.
The pure JScheme approach is nice because it works on all platforms 
(except of course when a new version of Java requires
breaks it temporarily....) and you don't need to download any 
additional tools (cygwin, ant, ...)
I'll track down those sun.* dependencies.

Thanks for the bug report and diagnosis!

Best,
---Tim---

> which is of course why you're not supposed to use them. There are also 
> a lot of static method calls being made as if they weren't static, 
> which is odd.
>
> B) When I try to load many of the files in the elf directory,
> I get the typical result below. Ideas?
>
> JScheme 7.1 (8/5/04 12:39 PM) http://jscheme.sourceforge.net
> >(load "elf/basic.scm")
>  ** WARNING: Error during load (lineno 23): jsint.BacktraceException[
>
> (.append sb (U.stringify (car args )#f ))
>   args = ("\nExample of using import and define-method.  \n(describe 
> x) uses JDK 1.2 AccessibleObject to desc...
>   sb =
>   loop = (lambda !{}~1 (args sb)...)
>   args= = ("\nExample of using import and define-method.  \n(describe 
> x) uses JDK 1.2 AccessibleObject to desc...
>   sb= =
>   args = ("\nExample of using import and define-method.  \n(describe 
> x) uses JDK 1.2 AccessibleObject to desc...
>
> ---snip---