CL on mono fails to compile Testsuite/Lib

[larceny-trac-import]

Reported by: pnkfelix on Tue May 16 13:55:29 2006 Well, we can get a bootstrap heap going, and my hacked up (build-twobit) completes without dying, so that's good.

But my first attempt to compile a file led to this:

% mono dotnet.heap.exe  -- Twobit.fasl 
CommonLarceny
CLR, Version=1.1.4322.2032
Scheme, Version=0.0.0.0, Culture=neutral
dotnet.heap, Version=0.0.0.0, Culture=neutral

DEBUG version of Scheme runtime.
CHECKED arithmetic
Initializing fixnum pool.
Initializing char pool.
Initializing registers.
Executing (go ...)
WARNING from macro expander:
Redefining 
let
WARNING from macro expander:
Redefining 
.call
asm-switches loaded

> compile
#<procedure compile>

> (compile '(lambda (x) x))
((27 ((3) (29 1) (24 1 .x|1) (37)) 0 #(#f (lambda (x) x) 1 #f #f (x))) (37))

> compile-file
#<procedure compile-file>

> (current-directory "Testsuite/Lib")
0

> (load "load-all-tests.sch")
Source file: "test.sch"
  compiled  -> "test.lap"
  assembled -> "test.lop"
  IL dumped -> "test.code-il"

ilasm /nologo /quiet /alignment=4096 /clock  /output:test.exe test.il

Unhandled Exception: System.ComponentModel.Win32Exception: Cannot find the specified file
in <0x001d4> System.Diagnostics.Process:Start_shell (System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process process)
in <0x0008c> System.Diagnostics.Process:Start_common (System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process process)
in <0x00050> System.Diagnostics.Process:Start (System.Diagnostics.ProcessStartInfo startInfo)
in <0x000f0> Scheme.RT.Syscall:system ()
in <0x00124> Scheme.RT.Syscall:dispatch (Int32 num_args, Sys num_proc)
in <0x00088> Scheme.Rep.SFixnum:op_syscall ()
in <0x0004c> ns_lib_common_malcode_1042861925c1.CodeVector_5_1:call (Int32 )
in <0x000a4> Scheme.RT.Call:trampoline (Scheme.Rep.Procedure p, Int32 argc)
in <0x000dc> Scheme.RT.Load:handleProcedure (Scheme.Rep.Procedure command, Scheme.Rep.SObject[] args)
in <0x001e0> Scheme.RT.Load:handleGo (System.String[] args)
in <0x001b4> Scheme.RT.Load:MainHelper (System.String[] args)
in <0x00014> Main:Main (System.String[] )

Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type.
in <0x0012c> Scheme.Rep.Procedure:getName ()
in <0x0013c> Scheme.Rep.Procedure:getName ()
in <0x00048> Scheme.Rep.Procedure:write (System.IO.TextWriter w)
in <0x00058> Scheme.Rep.SObject:ToString ()
in <0x00474> System.String:FormatHelper (System.Text.StringBuilder result, IFormatProvider provider, System.String format, System.Object[] args)
in <0x0004c> System.String:Format (IFormatProvider provider, System.String format, System.Object[] args)
in <0x00068> System.String:Format (System.String format, System.Object arg0, System.Object arg1)
in <0x00034> System.IO.TextWriter:Write (System.String format, System.Object arg0, System.Object arg1)
in <0x00048> System.IO.TextWriter:WriteLine (System.String format, System.Object arg0, System.Object arg1)
in <0x00318> Scheme.RT.Exn:dumpFrame (Scheme.Rep.SObject[] frame, Int32 i)
in <0x00090> Scheme.RT.Exn:dumpContinuation ()
in <0x00084> Scheme.RT.Exn:fullCoreDump (System.Exception e)
in <0x00010> Scheme.RT.Exn:fullCoreDump ()
in <0x001b0> Scheme.RT.Load:handleProcedure (Scheme.Rep.Procedure command, Scheme.Rep.SObject[] args)
%

[larceny-trac-import]

Author: pnkfelix I opened up Ticket #76 after I realized what the problem here was. So we're almost certainly not going to get the error message above anymore.

I don't want to close this ticket until I got a chance to see what our status is on attempting to compile Testsuite/Lib now.

[larceny-trac-import]

Author: pnkfelix punt

[larceny-trac-import]

Author: pnkfelix BlarGh, this is that damn time-dependant "test"; as a reminder, here's the note that goes with it:

   ; NOTE!  This test can fail because it computes a ratio of execution
   ; times of two identical programs, but the programs are not the sole
   ; determinant of how fast they run...  I have observed a factor-of-two
   ; difference on _identical_ binary code running in the _same_ process,
   ; where the only difference between the two was where in memory the
   ; code was located.

Why are we checking for this again? Could we at the very least lower the ratio to something more reasonable than expecting +/- 10% of variation? I'm going to change the test so that it prints out the ratio in the failure cases...

[larceny-trac-import]

Author: pnkfelix (the original bug that this test was introduced for, bug 105, had the following time ratios:

    > (time (test1))
    Words allocated: 474
    Words reclaimed: 0
    Elapsed time...: 4280 ms (User: 4270 ms; System: 0 ms)
    Elapsed GC time: 0 ms (in 0 collections.)
    100000000
    > (time (test2))
    Words allocated: 482
    Words reclaimed: 0
    Elapsed time...: 15787 ms (User: 15650 ms; System: 0 ms)
    Elapsed GC time: 0 ms (in 0 collections.)
    100000000

So if we wanted to keep this as a true "regression test" but make it something more reasonable in terms of not signalling false positives, we could try to detect a speed difference of 70% or more, rather than 10%...

[larceny-trac-import]

Author: tov mono punt

[larceny-trac-import]

Author: pnkfelix punt