error building from source (2011/03/27)

[marcomaggi]

With current checkout of master branch I get:

$ ./gen-git-build.sh
Condition components:
1. &who who: ascii-tab
2. &message message: "multiple definitions of identifier"
3. &syntax form: ascii-tab
subform: #f
error error in raise: returned from non-continuable exception


Exception:
error in raise: returned from non-continuable exception

Stack trace:
1. throw: <subr>
2. (raise c): baselib.scm:943
3. apply: <subr>

(Happy to see you in Japan are fine!)
--
Marco Maggi

[okuoku]

Hi,

2011/3/27 marcomaggi <mrc...@gmail.com>:

> With current checkout of master branch I get:
>
> $ ./gen-git-build.sh
>  Condition components:
>  1. &who           who: ascii-tab

Current master branch requires correct SRFI library installed.
If you've just "git pull" for updating tree, please do a fresh checkout
(i.e. "git clone") and remove your psyntax-mosh cache (~/.mosh).

SRFI-19 was broken at this commit
https://github.com/higepon/mosh/commit/faaf0119e0d616f4c908166613cd840b90e42e65#diff-2
and if you installed this particular revision, please uninstall this first.

Alternatively, pre-bootstrapped tarball is always available at
http://storage.osdev.info/pub/mosh/mosh-current.tar.gz
but this may slightly old from higepon/master (it is based on my
release branch at
https://github.com/okuoku/mosh
).

[marcomaggi]

On Mar 27, 10:10 am, okuoku <oku...@gmail.com> wrote:
> Alternatively, pre-bootstrapped tarball is always available athttp://storage.osdev.info/pub/mosh/mosh-current.tar.gz

> but this may slightly old from higepon/master (it is based on my
> release branch athttps://github.com/okuoku/mosh
> ).

Fine, I successfully installed from the "current" tarball, but I still
get the same error when rebuilding the master branch from a freshly
cloned mosh repository: the problem is in SRFI 48? If I ignore the
error and let it go on, I get en error because "svn" cannot be
executed on my system: tracking Mosh development is becoming
difficult...

Anyway, the true problem I have is that I get the following error when
precompiling my libraries or running the tests with a clean .mosh
cache:

$ make mfasl

--- Compiling for Mosh Scheme
test -f ../src/libraries/compile-all.mosh.sps && MOSH_LOADPATH=./
fasl.d:/usr/local/lib/scheme /usr/local/bin/mosh --verbose ../src/
libraries/compile-all.mosh.sps
Condition components:
1. &error
2. &who who: compiler
3. &message message: "[internal error] iform-count-size-upto:
unknown iform tag:16"
4. &irritants irritants: ()

error error in raise: returned from non-continuable exception


Exception:
error in raise: returned from non-continuable exception

Stack trace:
1. throw: <subr>
2. (raise c): baselib.scm:943

3. (rec-list iform-list cnt): baselib.scm:6609
4. (rec iform cnt): baselib.scm:6561
5. (rec iform cnt): baselib.scm:6561
6. (rec iform cnt): baselib.scm:6561
7. (rec iform cnt): baselib.scm:6561
8. (rec-list iform-list cnt): baselib.scm:6609
9. (rec iform cnt): baselib.scm:6561
10. (rec iform cnt): baselib.scm:6561
11. (rec iform cnt): baselib.scm:6561
12. (rec iform cnt): baselib.scm:6561
13. (pass2/optimize-closure lvar lambda-node): baselib.scm:6510
14. (pass2/optimize-closure lvar lambda-node): baselib.scm:6510
15. apply: <subr>
16. (pass2/$let iform closures): <unknown location>
17. (pass2/$let iform closures): <unknown location>
18. (pass2/$lambda iform closures): <unknown location>
19. (compile-w/o-halt sexp): baselib.scm:9222

it is impossible for me to reduce it to a small test case so I can
only give you a tarball[1]:

# unpack then:
$ cd nausicaa-scheme-0.2d4
$ mkdir build
$ cd build
$ ../configure --enable-mosh
$ make sls mtest file=generics-ordinary

or:

$ cd src/libraries
$ MOSH_LOADPATH=$PWD make --verbose compile-all.mosh.sps

The problem is triggered by the "src/libraries/nausicaa/language/
generics.sls" file and is related to using the library in the file
"src/librarires/nausicaa/language/generics/properties.sls", whose
bindings are imported with prefix "prop." in "generics.sls". If I
comment out everything using such library: the code compiles fine; the
offending code is the %REGISTER-METHOD subfunction in the body of the
ADD-METHOD macro definition: if I replace its body with #f the code
runs (it does not perform the intended operation, but it runs without
the error above).

What the code is trying to do (and it works in Petite Chez) is to
attach, at expand time, a property to the identifier of a macro; the
property is a record instance. When such value is accessed by
%REGISTER-METHOD the error occurs.

The code does not work with Vicare/Ikarus either, or, more precisely:
running it without precompiling works, running it after precompilation
of libraries fails because the property value is not created correctly
at expand time. It seems to me that Vicare fails for a different
problem.

HTH

[1] http://github.com/downloads/marcomaggi/nausicaa/nausicaa-scheme-tmp-src.tar.bz2
--
Marco Maggi

[okuoku]

2011/3/27 marcomaggi <mrc...@gmail.com>:

> On Mar 27, 10:10 am, okuoku <oku...@gmail.com> wrote:

- snip -

> Fine, I successfully installed from the "current" tarball, but I still
> get the same error when rebuilding the master branch from a freshly
> cloned mosh repository: the problem is in SRFI 48?

Hmm... I think we need an option for -nostdlib as gcc.

Would you mind trying with nmosh? Likewise:

nmosh --loadpath=lib misc/scripts/gen-alias-libs.sps
nmosh --loadpath=lib misc/scripts/gen-nmosh-stubs.sps
nmosh --loadpath=lib misc/scripts/gen-corelibmk.sps

I think this would work. If not, you might have another SRFI collection
in your MOSH_LOADPATH environment variable(or a new bug have found :-P).

> If I ignore the
> error and let it go on, I get en error because "svn" cannot be
> executed on my system: tracking Mosh development is becoming
> difficult...

Mosh bootstrapping relies googlecode's subversion service and
its availability is quite low today... This is why I had decided keep updating
mosh-current.tar.gz.

> Anyway, the true problem I have is that I get the following error when
> precompiling my libraries or running the tests with a clean .mosh
> cache:

- snip -

> --- Compiling for Mosh Scheme
> test -f ../src/libraries/compile-all.mosh.sps && MOSH_LOADPATH=./
> fasl.d:/usr/local/lib/scheme /usr/local/bin/mosh --verbose ../src/
> libraries/compile-all.mosh.sps
>  Condition components:
>  1. &error
>  2. &who             who: compiler
>  3. &message         message: "[internal error] iform-count-size-upto:
> unknown iform tag:16"
>  4. &irritants       irritants: ()
> error     error in raise: returned from non-continuable exception

It seems you've hit some mosh's VM bytecode compiler bug.

> The code does not work with Vicare/Ikarus either, or, more precisely:
> running it without precompiling works, running it after precompilation
> of libraries fails because the property value is not created correctly
> at expand time. It seems to me that Vicare fails for a different
> problem.

R6RS does't guarantee the same object accessible between expand-phase
and run-phase.
I think we need some additional API for controlling this behavior.
(e.g. Guarantee to preserve SRFI-39 parameter object values between phases.)

[marcomaggi]

On Mar 27, 3:41 pm, okuoku <oku...@gmail.com> wrote:
> It seems you've hit some mosh's VM bytecode compiler bug.

This is currently a show-stopper for me; I want to try to nail the
problem with a smaller demonstration source. Can you give me some
hint on the cause of the error? Should I focus on libraries import
levels?

I use the same technique of expand-time identifier-properties both in
the (--- classes ---) libraries and the (--- generics ---) libraries,
and only when I added it to the generics libraries the bug has
revealed itself; so it seems something specific to that chunk of code.
--
Marco Maggi

[okuoku]

2011/4/6 marcomaggi <mrc...@gmail.com>:

> On Mar 27, 3:41 pm, okuoku <oku...@gmail.com> wrote:
>> It seems you've hit some mosh's VM bytecode compiler bug.
>
> This is currently a show-stopper for me; I want to try to nail the
> problem with a smaller demonstration source.  Can you give me some
> hint on the cause of the error?

I think it's psyntax-mosh specific and Higepon might know about it
more than me..

> Should I focus on libraries import
> levels?

No. Probably.

Would you mind if i port your library into nmosh? I know porting
libraries into explicit-phasing R6RS
might lose some code readability and there is only 2 or 3
explicit-phasing R6RS implementation(nmosh, Larceny, Gambit-R6RS)...

[marcomaggi]

On Apr 6, 2:01 pm, okuoku <oku...@gmail.com> wrote:
> I think it's psyntax-mosh specific and Higepon might know about it
> more than me..

In the original code I was able to narrow it down to this: in the file
"generics.sls" I have (around line 533):

(define-syntax* (add-method stx)
(define (%register-method generic-id arg-type-ids)
(let* ((prop (or (prop.generic-properties-ref generic-id)
(synner "invalid identifier as generic function name" generic-
id)))
---

if I replace the macro use:

(synner "invalid identifier as generic function name" generic-id)

with:

(syntax-violation 'add-method "invalid identifier as generic function
name" stx generic-id)

which does exactly the same thing, no error shows. I unsuccessfully
tried to replicate the problem with the following library+program
which has the definition of DEFINE-SYNTAX*:

(library (proof)
(export define-syntax*)
(import (rnrs))
(define-syntax define-syntax*
(lambda (stx)
(syntax-case stx ()
((_ (?name ?stx) ?body0 ?body ...)
(and (identifier? #'?name) (identifier? #'?stx))
(with-syntax ((SYNNER (datum->syntax #'?name 'synner)))
#'(define-syntax ?name
(lambda (?stx)
(define SYNNER
(case-lambda
((message)
(SYNNER message #f))
((message subform)
(syntax-violation '?name message (syntax->datum ?stx) (syntax-
>datum subform)))))
?body0 ?body ...))))))))
;;program
(import (rnrs)
(proof))

(define-syntax* (doit stx)
(define (make id)
(let* ((a (or (sin 2)
(synner "error message" id)))
(b (cos 3))
(c (tan 0.2)))
(write 'here)
#f))
(syntax-case stx ()
((id)
(make #'id))))

(doit)

no error shows: it appears the code needs to be "more complicated".

> Would you mind if i port your library into nmosh?

I suggest you to wait some days; I have just finished initial support
for Racket, so I am already messing with import levels. Trying the
code with "nmosh" is as easy as doing:

$ make mfasl MOSH=nmosh

and when I try it I get some errors on import levels, but also an
error which may be related to the way nmosh instantiates libraries
with diamond inheritance: I have to investigate it further. It is
more efficient if I give it a spin first (from what I have seen today,
nmosh is significantly less resource consuming than the last time I
tried it).
--
Marco Maggi

[higepon]

Hi.
Sorry for late reply.

> Condition components:
> 1. &error
> 2. &who who: compiler
> 3. &message message: "[internal error] iform-count-size-upto:

Following commint may fix the problem.

https://github.com/higepon/mosh/commit/41be327a03254df681332fb3959cae5fa93cfbb2

Could you try git clone and build?

Cheers.

> --
> You received this message because you are subscribed to the Google Groups "Mosh Developer Disscus" group.
> To post to this group, send email to mosh-develo...@googlegroups.com.
> To unsubscribe from this group, send email to mosh-developer-di...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mosh-developer-discuss?hl=en.
>
>

[marcomaggi]

On Apr 7, 3:48 pm, higepon <hige...@gmail.com> wrote:
> https://github.com/higepon/mosh/commit/41be327a03254df681332fb3959cae...

>
> Could you try git clone and build?

I still get the error.
--
Marco Maggi

[higepon]

> I still get the error.

Do you get the same error?
You need to start from git clone to be sure the compiler is rebuild.

Cheers.

[marcomaggi]

On Apr 8, 1:13 am, higepon <hige...@gmail.com> wrote:
> > I still get the error.
>
> Do you get the same error?
> You need to start from git clone to be sure the compiler is rebuild.

Will doing "git clean -dxf" be enough? Is there no "make distclean"
for such a step?

--
Marco Maggi

[marcomaggi]

On 6 Apr, 14:01, okuoku <oku...@gmail.com> wrote:
> Would you mind if i port your library into nmosh?

Here, I created and pushed a new branch "nmosh"[1] if you are still in
the mood you can fork from that; if you want to extract libraries and
distribute them independently, I suggest you to wait until the next
beta revision: there are still changes coming and some reorganisation,
too.

You should work only with code under the "scheme" subdirectory, the
other projects have not been updated. All the libraries compile with
both mosh and nmosh; some tests fail with mosh because of issues
already reported; some additional tests fail with nmosh for
miscellaneous reasons; a lot of tests work.

The building infrastructure does not detect the "nmosh" executable,
only "mosh"; you must select "nmosh" explicitly on the command line of
"make" with:

$ make MOSH=nmosh ...

In addition to "make mfasl" to compile all the libraries and "make
mtest" to run all the tests, I added Mosh specific rules to the
makefiles: "mfasl-lang" to compile only the (nausicaa) language
libraries; "mfasl-basic" to compile only the basic libraries; "mfasl-
high" to compile only the high level libraries; the corresponding
programs are under "scheme/src/libraries".

The REAME file explains how to select a single test file, for example
to run only "test-matches.sps" you can do:

$ make mtest MOSH=nmosh file=matches

additionally, all the tests are wrapped in PARAMETRISE forms which
define "test sections"; to run only the "expressions" section in "test-
matches.sps" you can do:

$ make mtest MOSH=nmosh file=matches name=expressions

additionally, if you want to run only the specific test case:

(check (stuff) => result)

modify it as:

(check 'this (stuff) => result)

then run:

$ make mtest MOSH=nmosh file=the-file name=this

test selection is rough, but it works.

Best wishes.

[1] https://github.com/marcomaggi/nausicaa/branches
--
Marco Maggi

[marcomaggi]

After the "git clean" and a rebuild everything worked! Thanks.
--
Marco Maggi

[higepon]

> Will doing "git clean -dxf" be enough?  Is there no "make distclean"
> for such a step?

make distclean
cd boot
make clean
make
cd ..
make

will force recompile the compiler.

Cheers.

[higepon]

Sorry.
./configure is also required.

[okuoku]

2011/4/8 marcomaggi <mrc...@gmail.com>:

> On 6 Apr, 14:01, okuoku <oku...@gmail.com> wrote:
>> Would you mind if i port your library into nmosh?
>
> Here, I created and pushed a new branch "nmosh"[1] if you are still in
> the mood you can fork from that;

Awesome. I'm going to add this into my nmosh testsuite.
Thanks!