error in compile phase of running a script

[GoogleCodeExporter]

I get the following stack trace when loading a test script (somewhat
complicated) with Mosh revision 1836. The same script runs fine with
Ikarus, Larceny and Ypsilon. This stack trace tells me nothing about my
code, does it tell something to you?

I would really like to do the debugging myself, but on my netbook this
stack trace comes after 43 seconds (measured with "time" utility), while,
for example, Ypsilon completes successfully in less than 4 seconds. This
makes it too time consuming for me to hunt down the form that causes it.

Anyway, it seems that it is not my code that goes wrong... I can provide
more informations if you ask for it.

CALL: stack expansion
CALL: stack expansion
CALL: stack expansion
 Condition components:
 1. &error    
 2. &who             who: compiler
 3. &message         message: "wrong number of arguments: lambda requires
2, but got 1 at #f"
 4. &irritants       irritants: ()

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

 Stack trace:
    1. throw: <subr>
    2. (raise c):  compiler-with-library.scm:889
    3. error: <subr>
    4. (adjust-arglist reqargs optarg iargs name): 
compiler-with-library.scm:6586
    5. (lambda call): <unknown location>
    6. (for-each-1 proc lst):  compiler-with-library.scm:169
    7. (pass2/local-call-optimizer lvar lambda-node): 
compiler-with-library.scm:6671
    8. (pass2/local-call-optimizer lvar lambda-node): 
compiler-with-library.scm:6671
    9. apply: <subr>
    10. (for-each proc ll):  compiler-with-library.scm:159
    11. (pass2/$let iform closures): <unknown location>
    12. (pass2/$let iform closures): <unknown location>
    13. (pass2/$call iform closures): <unknown location>
    14. (pass2/$call iform closures): <unknown location>
    15. (pass2/$lambda iform closures): <unknown location>
    16. (pass2/$local-assign iform closures): <unknown location>
    17. (pass2/$seq iform closures): <unknown location>
    18. (pass2/$seq iform closures): <unknown location>
    19. (pass2/$lambda iform closures): <unknown location>
    20. (pass2/$call iform closures): <unknown location>
      ... (more stack dump truncated)

Original issue reported on code.google.com by mrc....@gmail.com on 22 Jun 2009 at 7:45

[GoogleCodeExporter]

I'm sorry for the inconvenience.
Wrong number of arguments call of named let may cause this error as follows.

(let loop ([i 0])
  (if (= 1 i)
      i
      (loop 1 2)))

I'll add more detailed information to error message.
Please give me a few days to fix this.

Original comment by hige...@gmail.com on 23 Jun 2009 at 3:19

[GoogleCodeExporter]

Hi.

Now error message has the name of procedure called.

% ./mosh  k.scm
 Condition components:
 1. &error    
 2. &who             who: compiler
 3. &message         message: "wrong number of arguments: loop requires 1, but got 2"
 4. &irritants       irritants: ()
error     error in raise: returned from non-continuable exception

Can this help you?

Original comment by hige...@gmail.com on 23 Jun 2009 at 3:55

• Changed state: Accepted

[GoogleCodeExporter]

Yes, thanks! The stack trace by Mosh revision 1839 is below. I found the bug. 
Weird
that the same code worked fine with Ikarus, Larceny and Ypsilon and failed only 
with
Mosh...

The true problem is the execution time. I did no measurements in the last 
month, but
my feeling is that Mosh has become really slower; its execution time of one shot
scripts is becoming comparable to the one of Larceny. This changes the way one 
has to
think about Mosh as a tool; for example for (non-precompiled) scripts it is 
unusable.
Of course it is up to you to decide how to position it.

By the way, is it time to report errors in usage of precompiled Mosh libraries 
or
should I wait some more?

 Condition components:
 1. &error    
 2. &who             who: compiler
 3. &message         message: "wrong number of arguments: loop requires 2, but got 1"
 4. &irritants       irritants: ()

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

 Stack trace:
    1. throw: <subr>
    2. (raise c):  compiler-with-library.scm:889
    3. error: <subr>
    4. (adjust-arglist reqargs optarg iargs name src):  compiler-with-library.scm:6594
    5. (lambda call): <unknown location>
    6. (for-each-1 proc lst):  compiler-with-library.scm:169
    7. (pass2/local-call-optimizer lvar lambda-node):  compiler-with-library.scm:6689
    8. (pass2/local-call-optimizer lvar lambda-node):  compiler-with-library.scm:6689
    9. apply: <subr>
    10. (for-each proc ll):  compiler-with-library.scm:159
    11. (pass2/$let iform closures): <unknown location>
    12. (pass2/$let iform closures): <unknown location>
    13. (pass2/$call iform closures): <unknown location>
    14. (pass2/$call iform closures): <unknown location>
    15. (pass2/$lambda iform closures): <unknown location>
    16. (pass2/$local-assign iform closures): <unknown location>
    17. (pass2/$seq iform closures): <unknown location>
    18. (pass2/$seq iform closures): <unknown location>
    19. (pass2/$lambda iform closures): <unknown location>
    20. (pass2/$call iform closures): <unknown location>
      ... (more stack dump truncated)

Original comment by mrc....@gmail.com on 23 Jun 2009 at 6:25

[GoogleCodeExporter]

>Yes, thanks! The stack trace by Mosh revision 1839 is below. I found the bug. 
Weird
> that the same code worked fine with Ikarus, Larceny and Ypsilon and failed 
only with
> Mosh...

Thank you for retrying.
It is possible that the bug point is never executed on run time.
Mosh detects some wrong arguments errors not on run time but on compilation 
time.

> The true problem is the execution time. I did no measurements in the last 
month, but
> my feeling is that Mosh has become really slower

First of all, you may use debug build mosh?

If you ever did as follows, Mosh is built as debug version.(All of MOSH_ASSERT 
are
enabled).
Debug version is much slower(but safe to develop Mosh).
./configure --enable-developer
Just try
./configure && make clean && make

If you use release build, use "-p" option that enables profiler.
This shows you what procedures are slow.
If you found some procedures which are much slower than you expected, please 
show me
the code.

Cheers.

Original comment by hige...@gmail.com on 23 Jun 2009 at 8:10

[GoogleCodeExporter]

> you may use debug build mosh?

I will give it a try.

> If you found some procedures which are much slower
> than you expected, please show me the code.

Execution looks fast from what I can see printing messages on a terminal; it is
compilation that takes up all the time. Running the test script with the "-p" 
option
of Mosh I see a total run time at the bottom line of 41300 msecs, but the "time"
utility counts almost 53 seconds of total time (Mosh start up, compilation and 
run
times).

So precompilation is a must. Mind you, I am NOT asking to you to start 
optimising the
compiler right now, I am just stating what is the user perception.

Original comment by mrc....@gmail.com on 23 Jun 2009 at 8:45

[GoogleCodeExporter]

Thank you.

Ok, I have some stacked ToDos, I will try to two things.

Try to make compilation time shorter.(R6RS expantion time)

Then auto precompilation support as Ypsilon does on background.

Original comment by hige...@gmail.com on 24 Jun 2009 at 8:53

[GoogleCodeExporter]

Original comment by hige...@gmail.com on 24 Jun 2009 at 8:54

• Changed state: Fixed

[GoogleCodeExporter]

>I did no measurements in the last month, but
my feeling is that Mosh has become really slower;

You're right!
Changes as follows made Mosh 5 times slower!.

http://code.google.com/p/mosh-scheme/source/diff?spec=svn1819&r=1819&format=side
&path=/trunk/RecordProcedures.cpp

Fixed.

Original comment by hige...@gmail.com on 3 Jul 2009 at 6:35

[GoogleCodeExporter]

Compilation becomes a little bit faster.

% time ./mosh   --loadpath=nausicaa/scheme/src/libraries/
nausicaa/scheme/tests/test-random.sps 
./mosh --loadpath=nausicaa/scheme/src/libraries/   2.27s user 0.05s system 99% 
cpu
2.342 total

rev1913.

And will be more. 

Original comment by hige...@gmail.com on 12 Jul 2009 at 11:57

[GoogleCodeExporter]

I am not sure of this, with the newer revision 1913 I get (running them multiple
times and taking the fastest run):

===> test file ../tests/test-random.sps with Mosh

*** testing random

; *** checks *** : 115 correct, 0 failed.
real 16.22
user 16.11
sys 0.10

===> test file ../tests/test-strings-high.sps with Mosh

*** testing strings

; *** checks *** : 478 correct, 0 failed.
real 18.29
user 18.20
sys 0.07

while with the older revision 1908 I get (run one time, taken whatever it was):

===> test file ../tests/test-random.sps with Mosh

*** testing random

; *** checks *** : 115 correct, 0 failed.
real 14.99
user 14.86
sys 0.11

===> test file ../tests/test-strings-high.sps with Mosh

*** testing strings

; *** checks *** : 478 correct, 0 failed.
real 16.97
user 16.87
sys 0.07

Of course running the tests includes running time and compilation time, but I 
doubt
that running time got worse of a solid second (this is on my netbook with Intel 
Atom
CPU).

Original comment by mrc....@gmail.com on 12 Jul 2009 at 7:43

[GoogleCodeExporter]

Thank you for your feedback.
The result of benchmark seems strange.

By the way, Added some optimization today.
rev 1915.
complation becomes faster on my OSX.

Original comment by hige...@gmail.com on 13 Jul 2009 at 4:57

[GoogleCodeExporter]

Please don't use trunk rev 1918 which is broken.

Now I'm trying auto-pre-compilation mode.(almost working)

Original comment by hige...@gmail.com on 16 Jul 2009 at 3:08

[GoogleCodeExporter]

On rev 1921, auto-compile-cache works (at least on my Ubuntu and OSX).

Cache is located on $(HOME)/.mosh.
--disable-acc and --clean-acc options are available.

(1) first time
% time ./mosh --loadpath=nausicaa/scheme/src/libraries/
nausicaa/scheme/tests/test-recursion.sps
*** testing recursion

; *** checks *** : 1 correct, 0 failed.

(2) second time
./mosh --loadpath=nausicaa/scheme/src/libraries/   1.71s user 0.03s system 95% 
cpu
1.821 total
sewashi% time ./mosh --loadpath=nausicaa/scheme/src/libraries/
nausicaa/scheme/tests/test-recursion.sps
*** testing recursion

; *** checks *** : 1 correct, 0 failed.
./mosh --loadpath=nausicaa/scheme/src/libraries/   0.11s user 0.04s system 93% 
cpu
0.158 total

Original comment by hige...@gmail.com on 17 Jul 2009 at 3:12

[GoogleCodeExporter]

I did no measurements, yet, but it seems that revision 1822 really speeds up
first-time compilation of libraries+run time of scripts.

Original comment by mrc....@gmail.com on 18 Jul 2009 at 7:52

[GoogleCodeExporter]

> I did no measurements, yet, but it seems that revision 1822 really speeds up

Did you mean revision 1922?

Original comment by hige...@gmail.com on 19 Jul 2009 at 2:00

[GoogleCodeExporter]

> Did you mean revision 1922?

Yes, sorry.

Original comment by mrc....@gmail.com on 19 Jul 2009 at 6:50