Re: [Larceny-users] directory-files

[William D Clinger]

Sven wrote:
 So, now I am using the following definition (I hope this one will live a
 little longer):
 
 (define call-with-input-pipe (lambda (command pred)
   (let* ((results (process (if (string? command)
  command
  (reduce-r (lambda (arg result)
  (string-append arg   result))
command
  (result (pred (car results
 (close-input-port (car results))
 (close-output-port (cadr results))
 (unix/waitpid (caddr results))
 result)))

For an additional increment of robustness, you might
try the following (untested) version:

(define (call-with-input-pipe command pred)
  (let ((results (process (if (string? command)
command
(reduce-r (lambda (arg result)
(string-append arg   result))
  command)
(dynamic-wind
 (lambda () #t)
 (lambda () (pred (car results)))
 (lambda ()
   (close-input-port (car results))
   (close-output-port (cadr results))
   (unix/waitpid (caddr results))

The dynamic-wind will ensure that the ports get closed
and the unix/waitpid is called even if something goes
wrong during the computation performed by pred.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Object systems and macro transformers

[William D Clinger]

TJ wrote:
 1. Are there any object systems for Larceny? Preferably CLOS style
 systems. If not, how do I adapt tinyclos for use in Larceny?

There are many object systems for Scheme, and some of
them have been ported to Larceny.  I'm not sure which
ones are available or best supported, so I'll let
someone else answer this question.

 2. How do I use the procedure (environment-set-macro! ...) ?

Don't.  That procedure is Larceny-specific, and will
probably go away in the moderately near future.  It
exists and is documented primarily for the developers
of Larceny itself; that section of the documentation
should be more emphatic about the importance of not
using those procedures in user code.  The statement
that environments are occasionally useful in user
code really means environments are hardly ever useful
in user code, should be considered only by advanced
programmers, and even then only as a last resort.

The error you reported was caused by your use of
syntax-rules in an illegal context.  I can guess
why you thought syntax-rules would work in that
context, but the conceptual model that led you to
believe syntax-rules would work in that context
bears scant resemblance to the ugly reality.  Your
mental model may be close to the R6RS model; when
Larceny adopts that model, environment-set-macro!
will no longer work as it does now, and it will
be safer for everyone just to make it go away.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Getting unix-era time in Larceny

[William D Clinger]

David Rush wrote:
 I'm sure there is a straightforward way to get this that my incipient
 migraine is preventing me from finding. The closest I have seen so far
 appears to be the entry point osdep_cpuclock or possibly
 osdep_realclock down in the Rts innards. I can't see how either of
 these get surfaced to procedures at the repl.
 
 And just to be difficult, I do need it to work on windows :) Any suggestions?

This probably isn't what you want, but explaining why
it isn't what you want might help me to understand
what you want:

(define (user-time) (memstats-user-time (memstats)))

(define (system-time) (memstats-system-time (memstats)))

Those things return cpu time (user or system) in milliseconds,
e.g.

 (user-time)
100

 (system-time)
40

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] more on read-dispatch-vec

[William D Clinger]

Ed wrote:
   ; Symbol starters.
   
   (do ((c 128 (+ 1 c)))
   ((= c 256))
 (vector-set! read-dispatch-vec c read-dispatch-symbol-starter))
  
   (do ((i 0 (+ i 1)))
   ((= i 256))
 (if (char-alphabetic? (integer-char i))
 (vector-set! read-dispatch-vec i read-dispatch-symbol-starter)))
 
 Shouldn't that second do loop only need to run through 127?

As written, the two loops are independent (and the
first loop is an apparent hack, of majorly questionable
correctness).  Making the second loop depend upon
the questionable first loop would make the code even
more fragile than it is.  We don't want to increase
the fragility of this code to save a few microseconds
at initialization time.

As Felix noted earlier, this code has to go away pretty
soon anyway because it has to be rewritten for Unicode.

 BTW, is there a public repository that I can make patches against?

Only a small group of Larceny developers are allowed to
make changes to the Larceny source repository.  You can
check out the source yourself, however, and update it to
keep up with our changes.  See http://larceny.ccs.neu.edu/trac/

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Update of libraries and syntax-case available

[William D Clinger]

Thank you!

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Weak references

[William D Clinger]

David Rush wrote:
 I'm pretty sure that both PLT and Gambit have weak-reference and/or
 object-finalization systems and I will try to take a look in the next
 few days  to express a preference.

Okay.

 In the meantime, I guess I will
 have to find out just how much memory I'm going to end up using
 without fancy cache expiration machinery.  It's always good to measure
 first :)

Bounded caches with timeouts are easy to implement
in Larceny.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] an announcement from Abdulaziz Ghuloum

[William D Clinger]

Abdulaziz Ghuloum has asked implementors to post the
following announcement to their implementation-specific
mailing lists.  Ghuloum's announcement was first posted
to comp.lang.scheme and to the R6RS discussion list.

To avoid confusion, we need to add that Larceny v0.95
will be using Andre van Tonder's portable implementation
of the R6RS library and syntax-case systems, which is
not the system described by the announcement below.

Will



From: Abdulaziz Ghuloum [EMAIL PROTECTED]
Newsgroups: comp.lang.scheme
Subject: ANN: new version of the portable R6RS library and syntax-case system
Date: Sun, 28 Oct 2007 16:21:20 -0400

Greetings,

I would like to announce the availability of a new revision of
the portable R6RS library and syntax-case system.  You can
download the latest version and obtain more information from:
http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/

The implementation provides:
   * support for R6RS library and script top-level forms
 including enforcement of version/subversion constraints.
   * complete implementation of the (rnrs syntax-case (6)) library.
   * complete implementation of the (rnrs eval (6)) library
 (using the implementation's core evaluator).
   * expanders for all of R6RS's syntax forms, including
 define-recod-type and define-condition-type, both of which
 expand to calls to the procedural records layer.

The implementation runs and bootstraps itself successfully
under the following Scheme implementations:

   * Bigloo 3.0b
   * Chez Scheme 7.2
   * Chicken 2.710
   * Gambit 4.0 beta 20
   * Gauche 0.8.11
   * Ikarus (Build 2007-09-24)
   * Larceny 0.93
   * MIT-Scheme 7.7.90.+
   * MzScheme v371 [3m]
   * Petite Chez Scheme 7.2
   * Scheme48 1.7
   * SISC (1.16.6)

If your implementation is not listed above, and you would like
to see it supported, please contact me directly.

If you have any problems running the system, please email me
directly or post questions and bug reports to the launchpad
page:
http://launchpad.net/r6rs-libraries/

Aziz,,,



___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] ANN: Larceny v0.95 First Safety

[William D Clinger]

Larceny v0.95, First Safety, is now available
for download at http://larceny.ccs.neu.edu/

Larceny v0.95 is the first public release of a
multiplatform implementation that supports all
four de facto standards for Scheme: IEEE/ANSI,
R5RS, ERR5RS, and the R6RS [1,2,3,4].  Larceny
v0.95 is also the first complete implementation
of an R6RS-compatible system.

Larceny makes ERR5RS and R6RS libraries available
to all ERR5RS programs, R6RS top-level programs,
and Scheme scripts.  Larceny's ERR5RS mode offers
an interactive read/eval/print loop that allows
programmers to define and to import libraries,
and to load libraries and code from files, while
remaining almost fully compatible with the R5RS
and interoperable with both R5RS and R6RS code.
In Larceny's R6RS-compatible modes, libraries may
be defined within the file that contains the R6RS
top-level program or Scheme script; we urge all
other implementors of the R6RS to support this
vitally important extension of that standard.

Larceny's R6RS-compatible modes are not fully
R6RS-conforming, but most deviations merely
omit one of the punitive portability checks
mandated by the R6RS.  These omissions do not
affect the execution of production code, and
do not compromise Larceny's traditional safety.

Some of First Safety's new features are of beta
quality; its evocative version name reminds you
it's not quite fair to condemn a whole program
because of a single slip-up.  We will improve
compatibility, performance, and debugging of
ERR5RS and R6RS modes in future releases.

We are grateful to Andre van Tonder for letting
us use his portable implementation of libraries,
syntax-case, and the ERR5RS-compatible top level.
We acknowledge the contributions by Harold Ancell,
David Rush, and other SchemePunks who worked on
the design of ERR5RS.  We appreciate Microsoft's
support for projects that will use Common Larceny
[5].

William D Clinger
Felix S. Klock II



[1]  IEEE Standard for the Scheme Programming
Language.  IEEE Std 1178-1990.

[2]  Richard Kelsey, William Clinger, and Jonathan
Rees [editors].  Revised^5 Report on the Algorithmic
Language Scheme.  Higher-Order and Symbolic
Computation, Volume 11, Issue 1, August 1998, pages
7-105.  Online at
http://www.brics.dk/~hosc/11-1/
http://www.schemers.org/Documents/Standards/
http://www-swiss.ai.mit.edu/~jaffer/Scheme.html

[3]  http://scheme-punks.org/wiki/index.php?title=ERR5RS:Charter

[4]  http://www.r6rs.org/

[5]  In the v0.95 release, native Larceny and Petit
Larceny support ERR5RS, R6RS, and Snow but Common
Larceny does not.  Future releases of Common Larceny
are likely to support ERR5RS and the R6RS but not
Snow.

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] command-line bug

[William D Clinger]

Tom Gordon wrote:
 Is this the right channel for reporting Larceny bugs?

Yes it is.  Congratulations on the first bug report!

 In  v.05, the R6RS command-line procedure should, I believe, return a
 list, not a vector.

Thanks!  I expect we'll post the obvious patch and
workaround this weekend, along with a few other bug
fixes.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] confusing the lexer

[William D Clinger]

Thanks, Jed.  I have created a ticket for this.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] ERR5RS Default Record Printer

[William D Clinger]

Ray Racine asked:
 Is (record-updater (record-type-descriptor thread-rtd) 'printer) ...)
 valid ERR5RS or shall it be considered as a Larceny and therefore
 non-portable extension?

That's Larceny-specific and therefore non-portable.
There are likely to be some implementations of ERR5RS
that implement ERR5RS records as R6RS records, which
means the record printer may not be customizable.

(Some implementations of R6RS records may support a
similar extension, but portable code can't rely on
any extension at all, and certainly can't rely on
extensions being compatible with Larceny's.)

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] freezing for garbage collection?

[William D Clinger]

David Rush wrote:
 Given that Larceny was originally meant to be a platform for trying various
 GC schemes (no pun intended) is it perhaps time to find a gifted student in
 need of a senior project to write a bounded-incremental collector?

Last week, after giving a talk on that very problem for
a meeting of our local student chapter of the ACM, I met
several gifted students who seemed to have some interest.

 My read of the literature is that such a collector is a fairly well-solved
 problem...

Real-time collectors generally sacrifice considerable
throughput.  Maintaining throughput while bounding the
worst-case pause time remains a goal of current research.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] freezing for garbage collection?

[William D Clinger]

Matt Parker wrote:
 Will running the game in a thread work?

No.

 I tried running it with your options and there were still pauses (less
 frequent, but just as large delays).

That will be a problem with all of Larceny's current
garbage collectors (and with other stop-the-world
collectors, including Chicken's).  Generational
collectors make the delays less frequent, but don't
do anything to reduce their duration.

So far as I know, there are no implementations of
Scheme whose garbage collectors can meet your needs.
Marc Feeley has said he was working on a real-time
collector for Gambit, but I don't know its current
status.  We are working on a new collector for
Larceny that should meet your requirements, but it
isn't finished yet.

 Could I set it so there are frequent
 small garbage collections, like one after every frame of the game, with
 no apparent pause?

The settings I gave you already increase the frequency
of minor collections, and reduce the duration of most
major collections, but there is currently no way to
eliminate all of Larceny's full collections.

 Perhaps I could manually call the collector after every frame?

That won't help either.

 I really
 can't have any noticeable pauses in the game since it will mess up the
 AI's behavior.

We understand the problem.  We have designed a collector
that should work for you, but we don't expect to release
it until this fall.  If you are willing to test the new
collector for us, however, then we might have something
for you to try a little sooner.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] freezing for garbage collection?

[William D Clinger]

Matt Parker wrote:
 I have been using chicken scheme already and it doesn't ever freeze the
 screen from garbage collection (I don't know why not).  It also happens
 to be quite slow compared to larceny or even maybe gambit-c.  I tried
 using gambit once and it did the same freezes.

In that case, there is one more thing you should try.

Chicken doesn't attempt to collect compiled code or
static data.  Larceny does, and I think that's the
most likely reason you're noticing these freezes
in Larceny but not Chicken.  You can prevent Larceny
from attempting to collect your compiled code and
static data by creating your own heap image that
contains your entire program, like this:

% larceny -stopcopy
 (load myprogram)  ; load your entire program,
  ; but don't start it
 (dump-interactive-heap myprogram.heap)
 (exit)

(Instead of dump-interactive-heap, you might prefer to
use dump-heap; see the Larceny User Manual.)

Then create a split heap:

% larceny -heap myprogram.heap -reorganize-and-dump

That creates myprogram.heap.split, which you can rename
and use as your initial heap:

% mv myprogram.heap.split mypgm
% larceny -heap mypgm -areas 3

If that doesn't help, then we might have been wrong in
thinking the freezes are caused by garbage collection.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] SRFIs in R6RS mode

[William D Clinger]

In private correspondence with Ken Dickey, it seems
he mainly wanted to know how to import some of
Larceny's predefined R5RS procedures into an R6RS
program.  The lib/R6RS/larceny/records.sls file
contains an example of the primitives syntax used
to do this:

(library (larceny records printer)
  (export rtd-printer rtd-printer-set!)
  (import (primitives rtd-printer rtd-printer-set!)))

This should be documented in the Larceny User Manual,
but is not.

As for using SRFIs in ERR5RS or R6RS, there is at
present no portable way to do that because:

1.  The R6RS does not specify a portable way for
R6RS programs to import *any* libraries other than
those specified by the ratified R6RS documents.

2.  The SRFI editors have not yet decided what
naming conventions to use for SRFI libraries in
ERR5RS and R6RS programs.

Larceny deals with problem #1 by supporting ERR5RS
and several extensions to the R6RS.  As for problem
#2, I understand that one of the SRFI editors has
drafted a proposal; if that proposal is approved by
the SRFI editors, then I expect to implement it for 
Larceny.

As a temporary workaround, ERR5RS programs that use
R5RS SRFIs can load SRFIs on the command line by
naming the files that implement the SRFIs at the
end of the larceny command line following the --
option, but this workaround doesn't work for R6RS
programs or Scheme scripts.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Flush output port on r6rs script exit? + misc larceny questions

[William D Clinger]

Ryan Newton wrote:
 It seems like Larceny doesn't flush output on exit from an R6RS script?

That's news to me, but it sounds plausible.  I'll
look into it.

 I need process, and can get to it under normal larceny with (require
 'unix).  But I can't figure out how to get to it from within an R6
 library.

I don't know of any way to get to it from R6RS mode
(so we should invent a way), but this will get to
it from ERR5RS mode:

% larceny -err5rs -- -e (require 'unix)

(import (rnrs) (primitives process))

The reason that hack doesn't work in R6RS mode is
that R6RS programs are responsible for interpreting
the command-line arguments as they see fit, so the
-e argument doesn't work.

 This is a small change, but it seems that larceny doesn't yet
 search .larceny.sls.  Perhaps I could implement this change...

That's ticket #517, which is one of many critical
tickets that have piled up during this semester.
The semester is now over.  As of Friday, resolving
those tickets will be my first priority.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Heaps in err5rs: giant heaps, errors loading, extra slow compile with -stopcopy

[William D Clinger]

Ryan Newton wrote:
 I've got a large R6RS project.  I'm having problems with compile-
 stale and also with trying to build my libraries incrementally using
 explicit dependencies represented in a makefile.  (I can elaborate on
 that if anyone is curious.)

Using compile-stale on Linux, I am able to reproduce
the Client was expanded against a different build of
this library bug but not the unable to open file
bug.  I can't seem to reproduce either bug under
Solaris, which is of course a clue.

 I *could* load my project all at once from source (in about 5 min).

That's about 260 lines per second, which is in line
with the compilation speed we're getting on our Linux
machine.

 They wouldn't give me incremental builds, I was thinking that heaps
 might save me.  Load from source (5 min), dump heap, and then have a
 very fast startup and execution time.

That should have been a reasonable workaround until
we can fix and then improve compile-stale.

 Alas, I'm running into some problems.  First, adding -stopcopy causes
 my system to take not five minutes to load but 43!!  (It takes 43 min
 in either -err5rs or -r6rs mode.)  When it's done it saves a 73
 megabyte heap file.  (Chez saves a 10mb heap file.)

Something must be going wrong here.  Quite possibly
there are at least two different things going wrong,
one to cause the poor load time and the other to
cause the bloated heap file.

At the moment, I can only speculate.

Some possibilities for the poor load time:

bug in compiler (such as using eq? hash tables,
which are much slower with the stop-and-copy
collector than with the generational)

bug in Larceny's stop-and-copy garbage collector
(unlikely)

stop-and-copy collection really is that much
slower when Twobit is compiling a large
program

Some possibilities for the bloated heap file:

bug causing the compiler to preserve source code
or variable names

grotesquely inefficient code generation

R6RS bloat (but that should be independent of the collector)

 Neither of those problems are necessarily total show stoppers.  But
 then I get an error on load:

 [EMAIL PROTECTED] ~/wavescript/src]  $ larceny -heap larc.heap
 Larceny v0.961 Fluoridation (May  8 2008 16:17:32,
 precise:Linux:unified)
 Larceny Panic: Sys/alloc.c;368: Assertion failed.
 Aborted

 When I try with smaller examples, not loading so much stuff, then
 loading from heap works.  But it dies with the 73mb heap file.

 Looking at the code, here is the assert line:

assert( dest  slots 
dest+data.descriptor_slots-1  slots );

Ouch!  We haven't seen any trouble with heaps that
grow as large as a gigabyte, but we don't have any
experience with loading such large heap files and
there might be some interaction with heap loading.
Another possibility is that the heap dumper might
have a bug that causes it to create a malformed heap
file.

It would be interesting to know whether you get the
same error with

$ larceny -stopcopy -heap larc.heap

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Larceny Runtime - SIGPIPE Handled?

[William D Clinger]

Ray Racine wrote:
 My test case is pretty easy on my side, but I'm struggling for a simple
 test case for the Larceny developers to test cross O/S.

I think we can proceed on the basis of what you've
already given us.  OTOH, we may have a SIGPIPE put
Larceny in the debugger by default, just as a SIGFPE
already does, but programmers can write an exception
handler to ignore it instead.

Thanks!

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] sqlite3 FFI

[William D Clinger]

Pete wrote:
 I'm new to larceny and have chosen to use it for a project because it
 supports R6RS. How can I figure out what SRFIs are supported in R6RS mode
 (any?)

That's easy:  No SRFIs are supported in R6RS mode.
SRFI 97 proposes a way to organize SRFIs as libraries
that would be compatible with ERR5RS and R6RS, but
there is as yet no agreement on whether the name of
a library version of SRFI 6 (for example) should be
(srfi 6), (srfi vi), (srfi n6), or something else
altogether.  See http://srfi.schemers.org/srfi-97/

While we're waiting for SRFI 97 to be approved, you
can load many Larceny-supported SRFIs into Larceny's
ERR5RS mode via this trick:

% larceny -err5rs -- -e (require 'srfi-6)
Larceny v0.961 Fluoridation (Dec 31 2007 17:21:19, precise:Linux:unified)
larceny.heap, built on Mon Dec 31 17:21:43 EST 2007
ERR5RS mode (no libraries have been imported)

 (import (rnrs)
  (primitives open-input-string
  open-output-string
  get-output-string))

That's Larceny-specific, of course, and works only
in ERR5RS mode.

 and specifically is there an sqlite3 R6RS library?

Not that I've heard of.

 If an FFI is
 available and reasonably documented, I'd be willing to produce a sqlite3
 wrapping library for larceny.

That'd be great.  Larceny does indeed have an FFI,
which is somewhat documented but not well documented.
See http://larceny.ccs.neu.edu/doc/ and specifically
http://larceny.ccs.neu.edu/doc/user-manual.chunked/ar01s10.html#id2559833

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] stdout from larceny

[William D Clinger]

Peter Keller wrote:
 Can turning on/off this stuff be put into a command line argument or
 environment variable? (And maybe have it defaulted to off?)

The autoloading messages are suppressed for R6RS
programs (but not for ERR5RS) in Larceny's current
code base (but not in the v0.961 release of last
January).

We expect to have a bug-fix release, probably
numbered v0.962, by mid-June.  If you can't
wait, you can download the development version
of the lib/R6RS directory via

svn export http://larceny.ccs.neu.edu/svn/trunk/larceny_src/lib/R6RS

After doing that, replace lib/R6RS in Larceny's
root directory with the downloaded lib/R6RS.  You
will then have to compile the ERR5RS/R6RS runtime
and standard libraries by following the steps
documented in section 2.3.1 of the Larceny user
manual at


http://larceny.ccs.neu.edu/doc/user-manual.chunked/ar01s02.html#InstallationSection

That will also fix several R6RS bugs in v0.961.

If you want to suppress the autoloading messages
for ERR5RS as well, see changeset:5433 at

https://trac.ccs.neu.edu/trac/larceny/changeset/5433/trunk/larceny_src

That changeset will show you how to suppress the
messages for R6RS mode without having to download
the current development version of lib/R6RS.  You
would still have to recompile the ERR5RS/R6RS
runtime and standard libraries, but that's no big
deal.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] No binding available for rtd-accessor in library (rnrs conditions)

[William D Clinger]

Martin Rodgers wrote:
 I successfully tested the following code with 3 other R6RS
 implementations, so I'm unhappy to report that Larceny
 complains about a missing binding.

We, however, are happy you reported it.  Thank you.

You can fix this bug in your installation by adding one
line to lib/R6RS/rnrs/conditions.sls and recompiling the
R6RS runtime as described in step 4 of doc/HOWTO-BUILD
or section 2.3.1 of the current user manual.  See

https://trac.ccs.neu.edu/trac/larceny/ticket/549
https://trac.ccs.neu.edu/trac/larceny/changeset/5640
http://larceny.ccs.neu.edu/doc/user-manual.chunked/ar01s02.html#InstallationSection

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Typo in list.sch for assoc-string

[William D Clinger]

Ray Racine wrote:
 I am on a roll today. :)

Thanks, Ray.  Those bugs are now tickets #552 and #553.

Their fixes missed v0.962 by just a couple of days.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] Larceny v0.962 now available for download

[William D Clinger]

Larceny v0.962 is now available for download at

http://www.ccs.neu.edu/home/will/Larceny/

This release mostly just fixes bugs without adding
many new features.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] ANN: Larceny v0.963 Fluoridation (yet another bug fix release)

[William D Clinger]

Larceny and Petit Larceny v0.963 are now available
for download at

http://larceny.ccs.neu.edu/

Larceny v0.963 fixes about 20 bugs in the recent
v0.962 release that were identified by (or with
the help of) the PLT Scheme R6RS test suite that
Matthew Flatt announced in comp.lang.scheme one
week ago yesterday.

Larceny v0.963 still fails 45 of 8843 tests in
revision 10978 of the R6RS test program.  These
failures are confined to 4 of the 24 standard
libraries tested, two of which have one failure
each.  Of the 45 failures, 35 occur within
(rnrs io ports), and correspond to unimplemented
or deprecated features of that library.  Most
other test failures involve negative zero or
branch cuts in inexact arithmetic.

We believe Larceny implements the most important
99.5% of the R6RS, but we will continue to make
improvements.  Thank you for your patience and
support.

We must also thank Matthew Flatt for making his
excellent R6RS test program available to other
implementors of the R6RS.

William D Clinger
Felix S. Klock II

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] ANN: Common Larceny v0.964 is now available

[William D Clinger]

Common Larceny v0.964 is now available at

http://www.ccs.neu.edu/home/will/Larceny/

Common Larceny still lacks the ERR5RS and R6RS modes
of native Larceny and Petit Larceny, but v0.964 adds
compile-on-load and the v0.963 bug fixes to its R5RS
mode.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] CommonLarceny 0.964

[William D Clinger]

jeff bopp wrote:
 Hi guys, the download link to the new Common Larceny (0.964) seems
 to be broken.

Indeed it was.  I had forgotten to add the links.  Fixed now.
Thanks for telling us.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] A very broken error message

[William D Clinger]

David Rush wrote:
 The transcript below says it all. Yes, the macro is erroneous, but I
 made this mistake in the middle of a much larger macro definition, and
 well...cdr: () is not a pair just isn't very informative, although
 now that I know what went wrong I can see how it would arise.

 I don't know if this is bad enough to consider a bug, but I did want
 to raise it in hopes of a better tomorrow :)

Thanks!  Logged as ticket #589:
https://trac.ccs.neu.edu/trac/larceny/ticket/589

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Probably a daft question

[William D Clinger]

David Rush wrote:
 But has anyone done a GTK+ set of bindings for Larceny yet?

Felix Klock has prototyped this, but I don't know its current
state.  I'll let him fill in the details, but it will probably
be a couple of days before he'll have time to respond.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] Larceny v0.97b1 now available for beta testing

[William D Clinger]

Larceny and Petit Larceny v0.97b1 are now available
for beta testing.  See http://larceny.ccs.neu.edu/
for downloads.

Some of the more important differences between the
v0.97b1 beta release and the planned v0.97 release
are:

Common Larceny is not part of the beta release.

This beta release still does not recognize the
.larceny.sls file suffix.

Larceny's R6RS mode still limits R6RS top-level
programs and libraries to Latin-1.  In R5RS and
ERR5RS modes, however, load-from-port can still
be used to load R5RS and ERR5RS programs and
libraries from UTF-8 or UTF-16 files.

Differences between v0.97b1 and v0.963 include:

Command-line options for selecting Latin-1 or
UTF-8 transcoding for (current-input-port) and
(current-output-port).

Corrected string-titlecase to break words as
specified by Unicode Annex 29.

R6RS semantics for arithmetic.

Expanded the bignum range from 2^21 bits (a
little over half a million decimal digits) to
2^29 bits (a little over 160 million decimal
digits).

Some bignum operations are faster (less slow).

Added r5rs:load and r5rs:require for loading
or requiring R5RS programs and libraries from
ERR5RS or R6RS code.

Faster (less slow) compilation of some large
libraries and programs.  (A complete build of
Larceny from source now takes about 5 minutes
on most of our development machines, which is
down from 8 minutes a year ago.  Subsequent
rebuilds still take about 15 seconds.)

compile-stale-libraries is a little faster
(less slow) and more reliable (less unreliable).

Improved (less poor) profiling.

Improved implementations of SRFI 1, SRFI 13,
SRFI 69.

The guard syntax now calls raise-continuable
instead of raise when all clauses' tests are
false.

R6RS file options are now fully implemented
(except on Windows, where no-truncate still
doesn't work).

Implemented a closer approximation to our
best guess as to the R6RS semantics intended
for set-port-position!.

Larceny v0.97b1 still fails 2 of 8907 tests in
revision 11372 of PLT Scheme's R6RS test program.
One of the failed tests is caused by Larceny's
non-enforcement of the letrec* restriction; the
other involves an arcane interaction between meta
levels, rename-on-import, and free-identifier=?.

We believe Larceny implements the most important
99.98% of the R6RS, but we will continue to make
improvements.  Thank you for your patience and
support.

William D Clinger
Felix S. Klock II

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Compiler - Intermediate Representation

[William D Clinger]

Ray Racine wrote:
 Is there a way to dump out the compiler intermediate representation(s) from
 the various passes up to MacScheme IR for a given R6RS module?

Yes, it should be possible to do this using the Twobit
timing hook.  lib/Experimental/twobit-timer.sch
contains an example of its use, but you'll care about
the third argument to the timer procedure, which is
the input or output for the indicated phase of Twobit.

For most phases, you will probably want to use the 
make-readable procedure to reduce the apparent size
of the input or output.  Viewing MacScheme assembly
language is a little more difficult; I normally set
listify? to true and use the assemble procedure.  

I haven't used the timer hook for this, however, and
all of the above is off the top of my head.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] fixnum math

[William D Clinger]

Ray Racine noticed:
 fx math is unexpectedly slower.

Yes.  This is mentioned in the note at the end of
Larceny User Manual section 8.11 [1].

Larceny's GreatPrimOpCleanUp [2] will improve   matters
by making the R6RS fx operations run at the same speed
as the generic operations, but the R6RS fx operations
will never be any faster than the generic operations
in Larceny because the R6RS requires all fx operations
to check their arguments and also their result.

At one point, the R6RS editors intended to provide
an unsafe mode in which the R6RS fx operations might
be faster than the generic operations, but unsafe fx
operations were removed from the draft R6RS at the
insistence of at least two discussants, one of whom
was Aziz Ghuloum.  The idea that fx operations should
be faster than generic operations still persists, but
that idea is not consistent with the R6RS as ratified.

Larceny may eventually provide a Larceny-specific
library that exports Larceny-specific versions of
the R6RS fx operations that run faster than the
generic operations.  The Larceny-specific versions
would be unsafe in the R6RS sense, because they 
would be incompatible with the R6RS operations,
but they would be safe in the traditional sense
of the word safe.

Will

[1] http://larceny.ccs.neu.edu/doc/user-manual-alt.html#R6rsArithmeticSection
[2] https://trac.ccs.neu.edu/trac/larceny/wiki/GreatPrimOpCleanUp

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] recursive lists and C-c problems

[William D Clinger]

Marco Maggi wrote:
   I am new to Larceny (10 minutes) taking a look at
 larceny-0.963-bin-native-ia32-linux86)

v0.97b1 is newer and should have fewer bugs.

 and I see
 that this script goes into an endless loop:

 (import (rnrs)
   (rnrs mutable-pairs (6)))

 (write (let ((v '(1 #f)))
  (set-car! (cdr v) v)
  v))
 (newline)

 when run with scheme-script. Ikarus and the last
 Ypsilon do not, so I wonder why Larceny chooses to
 fill my terminal with (1 until I hit Control-c. :)

The R6RS does not specify any finite notation for
circular pseudo-lists, and the R6RS also forbids
extensions to its syntax that could express circular
pseudo-lists.

Attempts to print circular pseudo-lists in R6RS-conforming
systems should result in infinite output.  Ikarus and
Ypsilon, like Larceny, may default to a non-conforming
mode in which they have extended the R6RS notations,
contrary to the R6RS's explicit language concerning
extensions; if so, then Ikarus and Ypsilon should
provide some kind of switch that will force them into
a conforming mode, at least with regard to lexical
and datum syntax.  In Larceny, the #!r6rs flag serves
that purpose; you might try that in Ikarus and Ypsilon.

 After hitting C-c, I see that the debugger is here
 and I can exit it with q. And I am left with a prompt?

Yes.  It isn't a very useful prompt, since nothing is
in scope, but it's a prompt.

 Does it mean that I am forbidden to create a set[ug]id
 script with Larceny?

I think that's up to your operating system.  Larceny
is normally executed via a shell script, and the OS
(for security) may ignore the set[ug]id attribute of
shell scripts.

Control-C is not the only security problem that should
concern you.  Although Larceny checks for accidental
problems with the R6RS top-level program and libraries
being executed, it does not even try to guard against
malicious manipulation of the program and libraries.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] recursive lists and C-c problems

[William D Clinger]

Marco Maggi wrote:
 v0.97b1 is newer and should have fewer bugs.

 Is it also still open to very small non-language
 related changes?

Yes.

 Fine. But is there a switch that makes larceny print
 some non-infinite output in
 R6RS-compatible-mode-for-everything-else?

No, but there should be.  I'm waiting to see what
happens with SRFI 38 and SRFI 97.

 It would suffice to have a command line switch that
 makes the process exit whenever an exception is not
 blocked.

For what purpose(s) would that suffice?  If by
exception you mean an R6RS exception, then it
seems to me you could do that yourself by installing
a handler.  Furthermore that seems like the only
portable way to do it; you can't count on all
implementations of the R6RS having exactly the
same set of random extensions to the language.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] finding libraries

[William D Clinger]

Marco Moggie wrote:
 Of course I can write a shell script that
 makes use of an environment variable to build
 the -path argument, but... make it simple!

You could, for example, edit the startup.sch file
documented in sections 3.2.4 of Larceny's User
Manual.  If you prefer to use an environment
variable, then you could edit the shell scripts
provided with Larceny.

 The second problem is that Larceny neither
 supports loading a library for (uriel lang)
 from the file:

 dir-in-path/uriel/lang/main.sls

 nor loading (uriel lang compat) from:

 dir-in-path/uriel/lang/compat.larceny.sls

 at least I have found nothing for this in the
 documentation.

Larceny's mapping from library names to file
names is documented in section 5.4 of its User
Manual.  Larceny's mapping is similar to the
mapping that was suggested in a draft of the
non-binding appendixes to the R6RS but was
withdrawn from the non-binding appendixes that
the R6RS editors regarded as final.  You can
put (uriel lang) in either of

dir-in-path/uriel/lang.sls
or  dir-in-path/uriel.sls

Similarly, you can put (uriel lang compat) in

dir-in-path/uriel/lang/compat.sls
or  dir-in-path/uriel/lang.sls
or  dir-in-path/uriel.sls

v0.97 is also expected to allow

dir-in-path/uriel/lang/compat.larceny.sls

but we do not intend to support any further
extensions in this direction until there is
a more coherent standard.

 Other implementation do this,
 what do you think?

I have been an outspoken critic of the R6RS's
failure to specify *any* portable means by which
R6RS programs can add their own libraries to
those documented within the R6RS documents
themselves.  My criticisms fell on deaf ears,
and the predicted portability problems have
come to pass.

All extensions you described are completely
implementation-dependent.  We are willing to
cooperate with other implementors to help solve
this vexing problem, but we are not willing to
implement all of the mappings that have already
been invented or will be invented in the future.
This issue needs urgent resolution by a SRFI or
some other standard that can extend or supersede
the R6RS.

When such a standard exists, Larceny will almost
certainly implement it.  In the meantime, Larceny
already supports the most widely supported mapping
from library names to file names, but even that
mapping is not supported by all implementations of
the R6RS.  At this time, there is no portable
solution to the problem, and nothing we could do
to Larceny would create a portable solution.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] recursive lists and C-c problems

[William D Clinger]

David Van Horn wrote:
 Are you just waiting for SRFI 97 to go final?

I have also been waiting for the end of the semester
so I'd have time to work on v0.97 again.  With the
end of the semester upon us, I'm just waiting to see
whether there will be any further changes to SRFI 97
before I start to implement the libraries it proposes.

I don't expect to implement all of those legacy SRFIs
for v0.97, but I do expect to implement SRFI 38 because
we have had multiple requests for it, and because I can
easily produce a completely portable version of it from
my reference implementation of get-datum [1].

Will

[1] http://www.ccs.neu.edu/home/will/R6RS/

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] ANF size error with 0.97b1

[William D Clinger]

Marco Maggi (and I hope I typed it right this time!) wrote:
 Is it something to report as a bug?

The ANF size: reports come from the compiler, and
provide an estimate of the code size.  Those messages
were added to help us track down some performance
bugs in compiler optimization.

They shouldn't be generated in R6RS mode, so that is
indeed a bug.  It would probably be better for me to
file that bug report.

 (I failed to understand how to
 load Larceny's SRFIs from larceny -r6rs, I
 will have to read the guide more carefully.)

SRFI 41 is the only SRFI that Larceny v0.97b1 supports
in R6RS mode.  We expect to add a bunch of SRFIs as
R6RS libraries after SRFI 97 becomes final, which is
expected to happen soon.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] finding libraries

[William D Clinger]

Jon Wells wrote:
 Has there ever been any discussion of allowing import clauses to appear
 anywhere other than the toplevel...

Yes, there has been some discussion.  However...

 So one could...

(import (rnrs))
   :
(if some-arbitrary-condition
   (import (a guff))
   (import (different guff)))
   :
refer to things exported by guff

That would be a bad idea for several reasons.  For
one thing, the scope of the conditional imports
would be unclear; to drive that point home, consider
what happens when you import in one branch of the
conditional but not in the other.  It would then be
impossible to compile the scope of the conditional
imports because the compiler wouldn't even know the
names being imported.  Even if the compiler were
able to figure that out, you'd have to describe
some semantics for the case where the sets of
identifiers imported by the conditional imports
were different, and I don't think you'd be able
to come up with a reasonable semantics for that.

Hence no one has proposed conditional imports in
the form you suggested above.

Furthermore the R6RS forbids all such extensions,
presumably in an attempt to improve portability of
R6RS code.  Implementations that claim to implement
the R6RS while providing such extensions would be
violating one of the absolute requirements of
the R6RS.

I have to admit that some of the R6RS's absolute
requirements are really dumb.  That is part of
why no one has yet released an R6RS-conforming
implementation.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] ANF size error with 0.97b1

[William D Clinger]

Marco Moggi wrote:
 I have NOT tried to precompile the libraries.

Since the ANF size: messages are coming from
the compiler, precompiling the libraries would
eliminate those messages from the run-time output. 

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Probably not a bug in R6RS, but...

[William D Clinger]

David Rush wrote:
 Should I report this as a bug?

I don't think you need to file a bug ticket.  The use
of \ as an escape character within symbols is not a
legal R5RS, ERR5RS, or R6RS syntax, and is already
deprecated (see the read-traditional-weirdness?
parameter [1]).  If this is considered to be a bug,
the most likely way we'd fix it is to drop support
for that weirdness or to change the defaults so you
couldn't use any of the traditional weirdness without
some kind of #!traditional-weirdness flag.

In any event, the \ escape appears to be working as
documented, so the only bug here would be with its
traditional semantics or with our decision to support
that semantics.

You could use the Greek letter lambda instead of a
backslash, and I think that's likely to become a
common convention as more implementations support
Unicode.  In Larceny v0.97b1, however, that works
only for interactive ports and only when the -utf8
option was specified on the command line.  (It's
possible to use UTF-8 or UTF-16 in source code files,
but doing so is too awkward and undocumented for
non-wizards.)  For now, you can use \x3bb; in source
files and the Greek letter lambda at the REPL.

Depending on your machine, of course, it may be more
trouble to type a real Greek lambda than to type the
traditional lambda or the R6RS \x3bb;.  Oh well.

Will


[1] https://trac.ccs.neu.edu/trac/larceny/wiki/LexicalConversion

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] error compiling cons form

[William D Clinger]

Ticket #600 is fixed as of changeset:5880.

I didn't realize that Felix was working on the problem,
so I tracked it down independently.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] on porting to larceny

[William D Clinger]

Marco Moggi wrote:
 The built in PARAMETERIZE does not act as a
 LETREC-like form:

That has been logged as a requested enhancement
(ticket #601).

 If I have not missed it in the source, the FFI
 does not implement peekers and pokers for long
 double and long long.  They are unusual, but if
 the cost of adding them is small...

I don't think they are supported by all C compilers,
so trying to support them in our basic FFI might
compromise portability.  Perhaps they should go into
a dynamically loadable library.

 the phrase You can checkout the source
 anonymously by following the instructions at
 SvnHttpCheckout. does not jump into my eyes.
 IMHO it should.

I revised the main Wiki page.

 Cough... sorry for making myself a nuisance,
 but can LARCENYLIBPATH be renamed to
 LARCENY_LIBPATH? It would be more readable.

Will do.

 I tried to run compiled Larceny programs using
 the binfmt_misc Linux  kernel module, but it has
 not worked  because larceny -r6rs  -program does
 not like compiled files.

I don't know anything about binfmt_misc, but I do
know that Larceny runs compiled top-level programs
via a larceny -r6rs -program mypgm command.

 I cannot use COMPILE-STALE-LIBRARIES because
 when  there are the following files in the same
 directory:

 compat.ikarus.sls
 compat.larceny.sls
 compat.ypsilon.sls

 Larceny attempts to compile all of them, not only
 the larceny.sls one.

That has been logged as a requested enhancement
(ticket #602).

 If I now run programs that import the libraries
 sometimes they work, other times I get the Client
 was expanded against a different build of this
 library.

Are you saying that you have some program A that
works sometimes but not others, without any
intervening changes to program A or to any of the
libraries or to any compiled files at all?

Or are you saying that it works for some programs
but not for others?

 Even when running the Larceny REPL, doing:

  (import (rnrs))
  (import (uriel foreign))

 raises the error about (uriel  cstring), but in
 Uriel's compilation script I have:

 | (compile-library uriel/cstring.sls
 |  uriel/cstring.larceny.slfasl)
 | (compile-library uriel/foreign.sls
 |  uriel/foreign.larceny.slfasl)

 so cstring is compiled first.  I dunno what to do.

It sounds as though (uriel foreign) might import some
library L that (hereditarily) imports some library L2
that (hereditarily) imports (uriel cstring), and that
your script is either failing to compile L2 or is
compiling it before (uriel cstring).  But that's just
a guess.

 Is there an automagic way to get a list of non-R6RS
 Larceny bindings that may be useful in R6RS mode?

Almost.  Larceny's apropos procedure can be used to
compute a list of *all* variables present within the
current interaction environment.  That list will
include some (but not all) R6RS bindings as well
as Larceny's bindings, and it will also include
bindings for deprecated features you shouldn't use.

% larceny
Larceny v0.97a2 (alpha test)
 (require 'apropos)
#t
 (apropos )
(%get-int %get-long %get-pointer %get-short ...)

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Re

[William D Clinger]

Marco Maggi wrote:
 So setting errno is a mandatory feature.

As of revision 5884, get-errno and set-errno! are
present in Larceny's R5RS mode and can be imported
into ERR5RS and R6RS modes using the primitives
extension.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] assertion failure in stats_start_timer

[William D Clinger]

Marco Maggi wrote:

 When running my test suite for POSIX
 functions, I get an assertion failure
 on Sys/stats.c line 283.

Logged as ticket #604:

  https://trac.ccs.neu.edu/trac/larceny/ticket/604

Should be fixed by changeset:5889.

Please let us know if that fixes it, so we
can close the ticket.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] srfi-19 testing and larceny-5889 errors

[William D Clinger]

Marco Maggi wrote a test program...
 which shows errors when loading (srfi :19)
 from Larceny into Larceny-5889.

I have fixed a few bugs in Larceny's implementation of
(srfi :19 time).  Most of these were bugs in the reference
implementation.  (It is unclear to me whether the nanosecond
argument to make-time should be allowed to be greater than
or equal to 10^9.  The reference implementation sometimes
assumed that argument was strictly less than 10^9, but
also contained at least one line of code that tried to
compensate if the nanosecond field of a time was a trifle
larger than 10^9.)

As noted in a FIXME comment, something is wrong with the
SRFI 19 specifications of ~U, ~V, and ~W as well as ~x.
I have assumed that the reference implementation of ~U
and ~W is correct, which means that the specification
of ~U is correct (but is slightly different from Marco's
interpretation) and the specification of ~W is correct
except for the stated range of results.

I don't know what to do about ~V, whose specification
and reference implementation both appear to be incorrect.
I just left its implementation alone.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] GLUT and GL bindings ported from Ypsilon

[William D Clinger]

Eduardo Cavazos wrote:
 I ported the gl and glut FFI bindings which come with Ypsilon to
 Larceny

Very nice!  Thank you!

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] library form for gl.scm

[William D Clinger]

Eduardo Cavazos wrote:
 If I load it via either one of these:

 ~ # larceny -- /scratch/_gl-test-case-a.scm

 ~ # larceny -err5rs -- /scratch/_gl-test-case-a.scm

 I get this error:

 ERROR detected during macro expansion:
 Definition out of context
 (define libGL (foreign-file libGL.so.1))

Sorry, I had missed that you were loading the file
via Larceny's -- hack.  That hack works only in R5RS
and ERR5RS modes; in either mode the file is loaded
as R5RS code, so the library form looks like a call
to a procedure named library.  Definitions are
illegal in the argument positions of procedure calls,
so you're getting an R5RS syntax error.

Now that all of the forms in the body of the library
are definitions, you should be able to load the file
into ERR5RS mode like this:

# larceny -err5rs
ERR5RS mode (no libraries have been imported)

 (import (rnrs) (larceny load))
 (load /scratch/_gl-test-case-a.scm)

You could also rename the file so it ends with .sls,
place it in a directory named larceny, and add the
parent of the larceny directory to your library path.
Then you could import it like this:

# larceny -path dir -err5rs
ERR5RS mode (no libraries have been imported)

 (import (rnrs) (larceny gl))

We should probably add a library macro to Larceny's
standard heap, and define that macro so the error
message will tell you the problem came from trying
to use the library syntax in R5RS mode.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] err5rs and srfis

[William D Clinger]

Ed Cavazos wrote:
 Is there a way to load srfi 27 while in err5rs mode?

In the current development system, you'd import
(srfi :27 random-bits), and that's how you'll import
it when v0.97 is released.  We expect v0.97 will
provide most of the libraries listed in SRFI 97.

That doesn't work in v0.97b1 and earlier releases,
mainly because we were waiting for SRFI 97 to define
the naming convention.  As a temporary workaround,
if you aren't using the development system, you can
download lib/SRFI/srfi/%3a27.sls and rename both the
file and the library [1].

 If not, it seems like a bunch of libraries in the
 distribution are only usable in R5RS mode. Is the
 plan to make ERR5RS mode the main mode eventually?

I hope an R7RS will remove the need to have three
separate modes in Larceny (or four if you count
Scheme scripts).

ERR5RS is, in my opinion, a model for the R7RS to
emulate.  If the R7RS is similar to ERR5RS, then
Larceny will probably be updated to support R7RS
as its main mode.

At this time, however, no one knows what the R7RS
will be like, or even whether there will be an R7RS.
We'll have to see what happens.

Will


[1] https://trac.ccs.neu.edu/trac/larceny/wiki/SvnHttpCheckout

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] profiling code

[William D Clinger]

Eduardo Cavazos wrote:
 I'm interested in finding out where *my* code is spending all it's time.
 :-) Is there a profiler for Larceny?

Yes, but it has very crude resolution.  In R5RS mode:


 (require 'profile)
#t
 (run-with-profiling
   (lambda ()
 (let* ((x1 (vector-list (make-vector 100 13)))
(x2 (append x1 '()))
(y (vector-list (make-vector 100 x1)))
(z (vector-list (make-vector 100 x2
   (equal? y z
 %  topmost named procedure
98  equal?
2  run-with-profiling

 %  active procedures
100  r5rs-entry-point
100  repl
100  run-with-profiling
98  equal?


 Available in ERR5RS mode?

Yes.  By the way, the following example generalizes
to work with any R5RS library that doesn't export
macros.


 (import (rnrs base)
  (primitives r5rs:require run-with-profiling))

 (r5rs:require 'profile)
#t

 (run-with-profiling
   (lambda ()
 (let* ((x1 (vector-list (make-vector 100 13)))
(x2 (append x1 '()))
(y (vector-list (make-vector 100 x1)))
(z (vector-list (make-vector 100 x2
   (equal? y z
 %  topmost named procedure
97  equal?
2  run-with-profiling
1  append

 %  active procedures
100  r5rs-entry-point
100  repl
100  run-with-profiling
97  equal?
1  append


Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] profiling spirales

[William D Clinger]

Eduardo Cavazos wrote:
 So what do the numbers mean? There are two tables
 which are output each time.

Roughly speaking, the first table shows the percentage
of time each procedure is executing its own code.  The
second table shows the percentage of time each procedure
is executing its own code or is suspended while waiting
for the result of some procedure it calls.  Hence the
percentages for the second table will always be at least
as high as for the first table.

Your profiles show that about 20% of the time is being
spent in %flonum-bignum.  I doubt whether your problem
really needs any bignum arithmetic at all, so I suspect
that you are using exact numbers for calculations that
were intended to use inexact numbers.

That, I think, is the most likely reason Larceny is
running slower than Ypsilon.  Interpreted systems
often perform well on benchmarks that do a lot of
bignum arithmetic, because there is no interpretation
involved during the bignum calculations themselves.
Furthermore Larceny's bignum arithmetic is known to be
especially slow, so an interpreter can easily be faster
than Larceny on a bignum-intensive benchmark.

I'd suggest you go through your code and convert every
arithmetic operation that should be taking inexact
arguments into the corresponding flonum-specific
operation.  For example, change + to fl+.  Then you'll
get an exception every time an exact argument is passed
to one of the flonum-specific operations, and that will
make it easier for you to track down the exact numbers
that (in all likelihood) are making the program run so
slowly.

The flonum-specific operations should be significantly
faster than the generic operations, so the transformed
program (after you have debugged it) should run faster
in both Larceny and in Ypsilon.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] make-bytevector and bytevector-copy

[William D Clinger]

Ed wrote:
 So my question is, is the first version of 'get-modelview-matrix'
 shown above inherently hot?

Maybe.  The other possibilities are that
(glGetDoublev GL_MODELVIEW_MATRIX bv) takes a long
time or that the profiler is overcounting calls to
foreign procedures for some reason.

In any case, calling bytevector-copy instead of
make-bytevector won't buy you much (if anything),
and it may make your code harder to understand or
to debug.  There's no reason why bytevector-copy
should run faster than make-bytevector; in fact,
I'd expect make-bytevector to run faster than
bytevector-copy.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] using srfi 27 and some other issues

[William D Clinger]

Marijn Schouten wrote:
 I've been working on packaging larceny 0.97b1 for Gentoo, partly
 because I wanted to try it out on a small physics simulation project
 that I'm working on.  I'd like to detail some of the difficulties I
 ran into.

Thank you for reporting these things to us.

 in doc/UserManual there are a lot of files with names that end in
 .txt which lead me to believe they were just plain text. Apparently
 they are something else. Perhaps the misleading extension could be
 changed?

Those are AsciiDoc ( http://www.methods.co.nz/asciidoc/ )
input files.  I don't know AsciiDoc well enough to know
whether the extension matters, but I'll look into it.
Those files are not included with binary versions of
Larceny; we include the HTML and PDF files produced from
those files instead.

 An error that I could not understand. It turns out I was using an illegal
 function name starting with a hyphen: -energy/J-plus

That has never been a legal identifier in Scheme, but
a lot of implementations fail to detect that error.  The
R6RS requires implementations to raise exceptions for that
class of lexical error.  For consistency, Larceny raises
those exceptions in all modes.

 I'm really non-plussed that such names are illegal, but at least the
 error message should be much clearer and it would be great if it would
 include a line number.

The current development system reports the line number,
as will v0.97 when it is released.

A wholesale cleanup of Larceny's error messages is in
progress, but will take time.

 My program uses SRFI 27 (random sources) and so I added a
 (require 'srfi-27) at the beginning. Then I got this:
 
 $ larceny -nobanner -- ising.scm -e (main 100)
 
 
 Error: Undefined global variable srfi-9.
 Entering debugger; type ? for help.
 debug

As Larceny's R5RS mode is currently configured, you have to
(require 'srfi-0) before using cond-expand or requiring any
SRFIs that use cond-expand, directly or indirectly.

If that remains true in v0.97, then we should do a better
job of documenting it.

 Finally I would like to note that having to double ctrl-D to
 exit each repl is very annoying. To quit the above invocation
 I have to ctrl-D 8 times.

That's odd.  It may be OS-dependent, as I don't have to do
that.  We'll look into it.

Thanks again for your bug reports.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] missing SRFI-43 (vector library)

[William D Clinger]

Marijn wrote:
 it seems that SRFI-43 (vector library) is not (yet) supported. I'd
 really like to use it. Are there any plans for adding it?

I spent part of Friday writing tests for SRFI 43, which
uncovered a previously unreported bug in the reference
implementation.  When I have fixed that bug, I will add
SRFI 43 to the development system.

Larceny v0.97 will support most SRFIs listed in SRFI 97.
For the list of those SRFIs that are already supported
in the current development system, see
http://www.ccs.neu.edu/home/will/R6RS/srfi97status.html

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] running fasl's

[William D Clinger]

In my previous message, I said SRFI 19 twice when I meant
SRFI 27.  (I modified Larceny's implementations of both
SRFIs within the last few days, and got them confused.)

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] running fasl's

[William D Clinger]

As of revision:6120, Larceny's implementation of random-integer
from SRFI 27 is considerably faster than before.  If that has
been holding you back, you might want to replace the old versions
of lib/SRFI/srfi-27.sch and lib/SRFI/srfi/%3a27.sls with the new
ones relative to

https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] procedure introspection

[William D Clinger]

Jose A Ortega Ruiz (jao) wrote:
 Unless procedure-arity is extended to provide them, i'd be using
 procedure-expression to get the arguments' *names*, to display short
 help notices in emacs echo area (using eldoc).

Larceny already retains the variable names, but we never
extended src/Lib/Common/procinfo.sch to provide access to
them.  How about we add procedure-arguments to fix that?

 Is there a similar facility for macros?

No.

 While we're at it, i've got a couple more questions:
 
 - is there (or could there be in future versions) a way to obtain a list
   of callers and callees of a given procedure?

Not really.

In higher order languages like Scheme, the general problem
is undecidable, so you'd have to settle for an approximation.

Larceny's compiler computes a first-order approximation that's
limited to the compilation unit, but I doubt whether that
would be good enough for your purposes.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] incremental development in ERR5RS/larceny

[William D Clinger]

Jose A Ortega Ruiz (jao) wrote:
 Now, i'm wondering to what extent such an interactive way of hacking is
 possible in ERR5RS and, in particular, its Larceny incarnation (R6RS
 being out of the question since it ditchs the REPL). If i'm
 understanding things correctly, the ERR5RS equivalent of, say, a CL
 package would be an R6RS-style library. What i would like is to be able
 to eval or re-eval a library A's body forms individually, so that other
 libraries using A would use the new definition automatically. But that
 doesn't make sense for libraries, since their evaluation semantics are
 defined as a whole, and they must be reloaded as a whole when modified,
 right?

Right.

 So, if i'm getting this right, the closer i can get in Larceny to my
 ideal world is re-compiling and re-loading the library at hand (and all
 the libraries that import it) everytime i modify any form in its body or
 import/export specifications.

Right.  In native Larceny, you wouldn't have to compile the
changed library, because native Larceny compiles everything
it loads.

Note, however, that re-importing the library won't do anything,
because libraries are imported only once.  You really would have
to call the ERR5RS load procedure (which you can import from the
(larceny load) or (err5rs load) libraries) to load the library
after making the change.

And then you'd still have to import the library again to make
the loaded library replace its original version in your REPL,
and you have to re-load (not re-import) all libraries that
depend on the changed library as well.

 And it actually makes no sense to think
 about evaluating expressions in a library's namespace (as you would do
 for instance in s48 with ,in, or in CL after an in-package form).

It might make sense, but there would be a lot of questions
about its semantics, and there is no provision for it in the
R6RS, in ERR5RS, or in Larceny.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] turning on optimizations

[William D Clinger]

Marijn wrote:
 Am I doing it wrong or is there something that is just not
 implemented yet here?

Larceny's benchmark-block-mode doesn't work, and hasn't for
some time.  The incremental compiler just ignores that switch,
but compile-file reports the error you encountered if that
switch is turned on.  We should delete that switch until we
fix it again.  I apologize for the time you wasted on it.

For a small program like the one you posted, you can get the
effect of block compilation by enclosing the definitions of
your program within a let, like this:

(define main
  (let ()
(define (SPIN+) +1)
...
(define (main delta-t measurements)
  ...)
main))

For your program, in Larceny, that made little difference.
Gambit is probably performing some optimizations that Larceny
isn't.  For example, Gambit's compiler may notice that (N)
always returns the same result; Larceny's compiler doesn't.

In Larceny, you can profile your code like this:

 (require 'Debugger/profile)
 (profile (main 10 100))

That profile told me your program was spending a quarter of
its time in half-delta-E-for-flip and another quarter in expt.

Changing (N) to compute (expt (L) (D)) only once made your
program run 20% faster.

I noticed some mixed-mode arithmetic, so I used fixnum-specific
and flonum-specific operations to detect and then to eliminate
(most of) the mixed-mode arithmetic.  I also replaced the two
uses of the (apply + (map ... ...)) idiom with loops.  Those
changes made your program run about 40% faster in Larceny, and
would probably improve its performance in Gambit as well.

After those changes, Larceny's profiler told me the program was
spending 90% of its time in the init-sample procedure, which
includes the time spent in random-real.  That probably means
its performance in Larceny, following those changes, is limited
by the speed of Larceny's implementation of random-real.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] turning on optimizations

[William D Clinger]

Marijn wrote:
 Do you really mean init-sample here?

My mistake!  I was confused by a defect in the profiler.
My transformation of your code (to mimic block compilation)
turned your entire program into an anonymous closure, which
(being nameless) would never show up in the profiler!  The
loop1 I was seeing in the profile was not the loop1 in your
code (after my renaming of loops), but a loop1 in Larceny,
probably in the REPL.

I'll look at the execution profile for your program some
more after I fix the profiler to be less confusing.

 I was wondering about that. I recently changed all the global
 constants to functions in an attempt to help the compiler
 recognize that these things are just constants.

Compilers are more likely to recognize them as constants if
they're constants.

 In C these would be macros, in C++ constant variables, but I
 don't know what the best way is to express the same thing in
 Scheme.

I think it's okay to use macros for this, but your reliance
on constant-folding was okay too.

The problem is that not all Scheme compilers fold constants.
In particular, Twobit (Larceny's compiler) folds some constants
(e.g. sums and differences of small exact integers) but is very
conservative about constant folding because Twobit is often used
as a cross-compiler, where the host system may be something other
than Larceny.  Some host systems may not support bignums, or may
use floating-point precisions other than IEEE double.  To avoid
those problems, Twobit never folds operations that involve
inexact constants, and never folds operations whose results
might be bignums.  That's why Twobit never performs constant
folding for exp.  Twobit probably should fold (expt 40 2), but
expt is not currently one of the operations that Twobit folds,
mainly because expt is likely to involve bignums, non-integral
rationals, floating point, or non-real numbers.

 What is the best way to do that? Macros, force/delay, some other method,
 explicit set! maybe?

I'd suggest you define procedures that compute the values of
computed constants from the input parameters, and use those
procedures to define constants.  The rest of your program
would then use those defined constants instead of the procedures
that computed them.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Syntax violations need syntax

[William D Clinger]

Logged as ticket #622.  Fixed by changeset:6150.

Thanks!

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] first steps with Larceny

[William D Clinger]

Michele Simionato wrote:
 It seems anyway that sweet-macros do not work out of the
 box with Larceny (some error Too many ...'s). I will
 try to nail the issue down to a simple test case.

Thanks to you and Derick for that bug report.  It has been
logged as ticket #637.

 FWIW, so far, sweet-macros has been able to find bugs in all
 R6RS implementations of syntax-case, except mzscheme

This bug is Larceny-specific.  Andre van Tonder's macro
expander is not at fault.

Will


___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] first steps with Larceny

[William D Clinger]

Concerning the syntax bug (ticket #637 [1]), I wrote:
 This bug is Larceny-specific.  Andre van Tonder's macro
 expander is not at fault.

I think I was wrong about that.

I have checked in a possible fix that passes all my tests
but may still not be right.  Please let me know of any
more bugs you find.

Will

[1] https://trac.ccs.neu.edu/trac/larceny/ticket/637

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] compiling using the twobit heap

[William D Clinger]

Dimitris Vardoulakis wrote:
 which file in the source code shows what happens when I type a
 definition in the repl?

src/Asm/Shared/link-lop.sch

Apparently the link-lop-segment procedure is not available at
top level in the twobit heap.  If you want to use it yourself,
I think the best way to get at it is to add it to the list of
exported procedures in src/Build/seal-twobit.sch, and then
rebuild twobit.heap.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] [plt-scheme] Re: side effects in R6RS modules

[William D Clinger]

Matthias Felleisen wrote:
 For whatever reasons, the editors moved the only piece of mathematics
 semantics (which doesn't include modules and macros) to the appendix,
 for reasons that still escape me. Well, they don't really. If you
 don't have a tool for arbitrating two distinct interpretations of
 an informal document, you can always claim that both are correct and
 if you so desire, you can claim one of them is, eh, smart? :-)

Although Matthias may not wish to know the actual reasons
for having an appendix that describes a formal semantics
for part of R6RS, those reasons were documented by formal
comments 222, 226, 227, and especially 236 [1,2,3,4].

Will

[1] http://www.r6rs.org/formal-comments/comment-222.txt
[2] http://www.r6rs.org/formal-comments/comment-226.txt
[3] http://www.r6rs.org/formal-comments/comment-227.txt
[4] http://www.r6rs.org/formal-comments/comment-236.txt

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] [plt-scheme] Re: side effects in R6RS modules

[William D Clinger]

Matthias Felleisen wrote:
 You'd be surprised. I have read those 'formal comments'; I just don't  
 think they contain any reasons to downgrade the formal semantics into  
 an optional appendix. Not one. Not a single one.

Well, no one ever said the R6RS was perfect.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Evaluate expr at startup does not work for import

[William D Clinger]

Marijn Schouten wrote:
 I noticed that it doesn't seem to work when you try to import at startup.

In Larceny, all code that is evaluated using the -e
command-line option must be written in R5 Scheme.
That allows you to load R5RS code at startup, even
if the mode is ERR5RS.

I suppose we could add an -eERR5RS command-line option,
but right now we're trying to figure out how to reduce
the number of command-line options we have to support.

In R6RS mode, of course, the -e command-line option isn't
interpreted at all.

 I would like to start larceny in a way that loads syntax-case before loading
 whatever file I want to run (also in the same command). Is that possible?

I don't think that's feasible in Larceny's ERR5RS mode.
On the other hand, it sounds as though you may be trying
to run something as a batch program, in which case R6RS
mode might work for you.

 PS My svn troubles were caused by using neon-0.28.4. I've downgraded to
 neon-0.28.3 and now svn works fine again.

Thank you for following up on that.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] ANN: Larceny v0.97 Funny in the Head

[William D Clinger]

Larceny v0.97 (Funny in the Head) is now available
for download at http://larceny.ccs.neu.edu/

This release delivers several improvements over v0.96:

Larceny now defaults to UTF-8 transcoding on Unix
systems, including Linux and MacOS X.  Latin-1
can still be specified from the command line.

Larceny's mapping from ERR5RS/R6RS library names
to files now recognizes a .larceny.sls suffix and
a LARCENY_LIBPATH environment variable.

Larceny supports the SRFI 97 naming convention for
ERR5RS/R6RS libraries, and implements all but 7
of the 49 R6RS-compatible SRFIs listed by SRFI 97.

Implementations of several SRFIs have been improved.

A new procedure, r5rs:require, allows R5RS libraries
to be required by ERR5RS or R6RS code.

compile-stale-libraries is a little faster
(less slow) and more reliable (less unreliable).

Faster (less slow) compilation of large libraries
and programs.  Faster system builds.

Improved (less poor) profiling.

Arithmetic conforms to both R5RS and R6RS semantics.

Fixnum-specific, flonum-specific, mixed-mode, and
some bignum operations are faster (less slow).

The bignum range has been expanded to 2^29 bits
(over 160 million decimal digits).

string-titlecase has been corrected to break words
as specified by Unicode Annex 29.

The guard syntax now calls raise-continuable
instead of raise when all clauses' tests are
false.

R6RS file options are fully implemented (except on
Windows, where no-truncate still doesn't work).

A closer approximation to our best guess as to the
R6RS semantics intended for set-port-position! has
been implemented for all file and string ports.

When Larceny is launched from a dumped heap image,
all eq? and eqv? hashtables rehash themselves
automatically.

On exit, all open ports are closed and output buffers
are flushed.

Common Larceny now supports ERR5RS and R6RS modes,
assuming you're patient enough to compile the R6RS
runtime and the standard R6RS libraries and SRFI
libraries.

We thank Dave Herman for improving Larceny's web site.

William D Clinger
Felix S Klock II

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Bug in syntax-rules expander (R6RS semantics changed?)

[William D Clinger]

 One can always get the effect specified by R5RS by wrapping a (let  
 () ...) around the (let-syntax ...), which could itself be specified  
 as a separate syntax-rules macro.

Good point.  I'll log this as a bug, and think about
the backwards compatibility issues some more.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Importing (srfi :19 time)

[William D Clinger]

 But, notice the warnings. Did you get those?

Yes.  That might be related to dynamic recompilation
by the FFI, but I'll have to check.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Performance Of SHA-256 Implementation

[William D Clinger]

Ray Racine wrote:

 The answer is correct, however, the 1 sec calculation time is a bit longer
 than anticipated along with the 4 million allocated words.  I understand why
 bitwise manipulations are going to be slower in dynamically typed language
 with type tag bits.  Thought I'd toss it out in the hopes someone may spot a
 low hanging fruit change in my implementation, recommend some compiler
 options etc.   At a minimum it might make a decent benchmark for grading
 (rnrs arithmetic bitwise) implementations.

Thanks.  Felix has already pointed you to the workarounds
appropriate for the current system.  Some of the allocation
may come from bignums generated as intermediate values.

There is hope for improvement in future releases.  Most of
the current inefficiency comes from implementing the R6RS
semantics without regard for performance.  The great primop
cleanup began with v0.97 Funny in the Head, but only a
few bitwise operations were improved, and almost all of the
improvements applied mainly to bignums, not fixnums.  Most
of the changes in the next release are likely to consist of
minor bug fixes and performance improvements.  The bitwise
and bytevector operations are among the lowest-hanging fruit
for that release.

 P.S. Noticed the Larceny SVN and mail list has been a bit quiet. Anything
 new and notable coming down on the Larceny front? 64Bit? Native threads?

Our main priority right now is Felix's thesis defense and
completing transfer of his maintenance responsibilities to
me.  So far as new releases of Larceny go, integrating his
new garbage collector is the first priority.  A 64-bit
Larceny is essential, but we'll do a 64-bit Petit Larceny
first because Sassy doesn't support the 64-bit instructions
we need, and coming up with the 64-bit runtime will be easier
if we don't have to change the compiler and assembler at the
same time.  I think 64 bits is a higher priority than native
threads.

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] ratification vote for R7RS-small

[William D Clinger]

The Scheme Language Steering Committee (SLSC) has announced a
vote on whether the ninth draft R7RS produced by Working Group 1
should be endorsed by the SLSC.

Votes are due by the end of Sunday, May 13, 2013.  For full
instructions on how to vote, with explanation of what the vote
is about, please see

http://lists.scheme-reports.org/pipermail/scheme-reports/2013-April/003299.html

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Larceny Panic: Can't allocate an object of size ...

[William D Clinger]

Sven Hartrumpf wrote:

> Is there a way to avoid the following compiler crash?

Sorry about that.

In my experience, this error means Larceny's assembler tried
to create a single monolithic chunk of x86 machine code whose
size was the reported 17536520 bytes, which is larger than
the maximum object size Larceny currently supports.

The best workaround I know of is to force Larceny's compiler
to break that one huge chunk of x86 machine code into smaller
chunks.  You can probably do that using the lambda-optimization
compiler switch to disable lambda optimization, but that's a
rather blunt approach even if it works.

It would be better to identify specific lambda expressions
(including those implied by the (define (f x ...) ...) syntax)
you're willing to have called using the general closure-calling
mechanism instead of the optimized mechanism, which uses a
PC-relative branch instead of an indirect branch.  Once you've
forced the compiler to allocate separate code segments for
enough lambda expressions, you will no longer have a single
code segment larger than the 16 megabyte limit.

To force the compiler to allocate a separate code segment for
selected lambda expressions, I'd recommend defining new macros
DEFINE, LAMBDA, and HIDE such that

(DEFINE (f x ...) ...)

expands into

(define f (LAMBDA (x ...) ...0))

and

(LAMBDA (...) ...)

expands into

(hide (lambda (...) ...))

where hide is an obfuscated identity procedure such as

(define (hide x)
  (vector-ref (vector x x 0)
  (random 2)))

whose only purpose is to defeat compiler optimizations that
might otherwise result in combining lambda expressions into
some huge machine code segment.

> This is the 32bit compiler; will the 64bit compiler help here?

Yes, this problem will mostly go away when we have a 64-bit
version of Larceny.  Although there are likely to be various
other system constraints that will limit the size of a single
code segment even in 64-bit systems, those limits will probably
be so large that almost nobody ever runs into them.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] user-defined features for cond-expand

[William D Clinger]

Sven Hartrumpf wrote:

> Many Scheme implementations allow to define a feature for cond-expand, e.g.
> in Chicken, -feature mydebug
> in Bigloo,  -srfimydebug
> etc.
> 
> How to do this when compiling with Larceny (R7RS)?

That's a good idea, but Larceny doesn't support it.  I'll add that as a
requested enhancement.

Workaround: You can add an otherwise meaningless (but well-formed) library
file to some directory within your library path, and let cond-expand test
whether that library is available.

That's less desirable because it's a global change to your file structure
rather than a command-line option, but it might be the best way to proceed
until Larceny starts to support the suggested enhancement.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] cyclic library dependency

[William D Clinger]

Alex Shinn wrote:

> Where does R6RS state it forbids cyclic libraries?

That's a consequence of R6RS Section 7.3, and is stated
a bit more directly in the (never-ratified) R6RS Rationale
Section 7.

What I'm about to quote is easier to understand if you recall
that, in the absence of macros, all variables are referenced
at phase 0.  From R6RS Section 7.3:

If any of a library’s definitions are referenced at
phase 0 in the expanded form of a program, then an
instance of the referenced library is created for
phase 0 before the program’s definitions and
expressions are evaluated. This rule applies
transitively: if the expanded form of one library
references at phase 0 an identifier from another
library, then before the referencing library is
instantiated at phase n, the referenced library
must be instantiated at phase n.

Note the word "must" in that last sentence.  Note also the
two uses of the word "before".  If some library B imports
another library A, then the above says library A "must" be
instantiated "before" library B is instantiated.

A library can't be instantiated at level 0 before it is
instantiated at level 0, so cyclic library dependencies
are forbidden by the R6RS absolute requirement ("must")
quoted above.

The R6RS Rationale Section 7 says:

The library system does not address the following
goals, which were considered during the design
process:

  * independent compilation
  * mutually dependent libraries
  * separation of library interface from library
implementation
  * local modules and local imports

The only one of those four that is clearly forbidden by
an absolute requirement of the R6RS is the second one:
mutually dependent libraries.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] understanding compiler messages

[William D Clinger]

Sven Hartrumpf wrote:

> I am porting a large R5RS program to R7RS, module by module.
> But I am stuck at the following cryptic message:
> 
> > rlwrap larceny -r7rsc
> Larceny v0.98+ "General Ripper" (Jan 12 2016 13:24:38, precise:Linux:unified)
> larceny.heap, built on Di 12. Jan 13:27:54 CET 2016
> 
> > (import (larceny compiler))
> 
> > (compile-file "general.sld")
> Compiling general.sld
> Reading larceny.scm
> Reading general.scm
> 
> 
> Error: unhandled condition:
> Compound condition has these components: 
> #
> #
> who : "car"
> #
> message : "car: not a pair: #f \n"
> 
> Entering debugger; type "?" for help.

This is clearly a bug in Larceny's module/macro expander.  From
the backtrace, it looks like it's a bug in the compress procedure,
so it's probably related to Larceny bug tickets #733 and #740.

I'm going to have to take some time and figure out what's wrong
with that compress procedure.  I don't know whether there was a
latent bug in that procedure that only started to show up or be
reported in v0.98, or whether the changes I made for R7RS are
causing it to be passed some incorrect inputs.

I appreciate the improvement you suggested for HOWTO-BUILD, and
have made that change.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] understanding compiler messages

[William D Clinger]

Sven, I pushed a fix for bug #740 that will probably fix the
module/macro expander problem you encountered.  Please try it
and let me know.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] ANF size greater than 80000

[William D Clinger]

Sven Hartrumpf wrote:

> When compiling large programs, I see the following warning:
> "ANF size greater than 8
> Some global optimizations were not performed."
> 
> How important are these optimizations for the speed of resulting .slfasl 
> files?

Those optimizations range from having hardly any effect
(which is common) to cutting the run time in half (much
less common).  You might be able to estimate the effect
for your application by compiling some smaller kernel
with and without the global-optimization compiler switch.

> If very important:
> Is it possible to change the variable anf-threshold in src/Compiler/pass3.sch?
> What values should I try? (Long compile times would be no problem for me.)

You can make those thresholds as large as you want, but
let me warn you that the compile time can be a surprisingly
high-degree polynomial function of the threshold.

The problem is that those optimizations are still using a
linked-list representation of available expressions.  Using
purely functional red/black trees instead should be viable
and would probably eliminate any practical need for that
threshold.  Red/black trees are on my wish list; it's one
of the easier things to do that would significantly improve
Larceny's compiler.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] open-input-file "unable to open file" on 8GB file

[William D Clinger]

David Rush wrote:

> I'm running larceny 0.98, for which I have written a number of logfile
> analysis programs, but I can't seem to get started on my latest (and
> largest) log file.

I was not aware of this problem, but Sven Hartrumpf's response is correct:
Larceny is unable to create or to read files larger than 2 GiB because it
was built in 32-bit mode, and the 2 GiB limit is built into the standard
32-bit libraries.

> Do I have to wait for 64-bit Larceny?

You won't be able to use Scheme's standard file i/o on files larger than
2 GiB until Larceny moves to 64 bits.

Sven suggested a workaround, however:

> A work-around (for bigloo) is to read from standard input (and not from a 
> file),
> but I have not tested this with larceny.

I have confirmed that this workaround works in Larceny.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Error on trying to get started

[William D Clinger]

Russell Wallace wrote:

> I've downloaded larceny on Windows and I'm trying to use it to run a
> minimal test script, like (print 42). When I run larceny.bat without
> arguments I get a repl, but when I run it with test.scm as an argument, I
> get 'error: deprecated heap file syntax'. What am I doing wrong?

It sounds as though you should be typing

larceny < test.scm
or
larceny -- test.scm

The second of those shouldn't work unless you're using the -r5rs option,
which is the default.

For a summary of command-line syntax, type

larceny --help

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] HOWTO procedure-name-set! ?

[William D Clinger]

Ken Dickey wrote:

> I am using R7 code but also procedure-name-set! which has just become 
> unavailabel with -r7r6.
> 
> Is there a 'lenient option?
> 
> Can I do an (import (cruft ..)) ?

Yes.  (import (primitives procname ...)) will import procname ...
from Larceny's underlying R5RS layer.

> What is the proper way to get procedure-name-set! and friends back into the 
> global environment?

% ./larceny --r7rs
Larceny v0.99a1 (alpha test) (May 17 2016 19:31:23, precise:Linux:unified)
larceny.heap, built on Tue May 17 19:31:43 EDT 2016

> (import (primitives procedure-name-set!))

> (define foo (lambda (x) (* x x)))
foo

> foo
#

> (procedure-name-set! foo 'bar)
#f

> foo
#


Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] Larceny v0.99a1 available for alpha/beta testing

[William D Clinger]

Larceny v0.99 will be released in a couple of weeks.  It will fix
bugs, improve R7RS conformance, and add several new SRFI libraries
while upgrading others.

Version 0.99a1 is available for downloading and alpha/beta testing
from our nightly build page: http://larceny.ccs.neu.edu/nightly/
Its core components should be stable and ready to go into the
v0.99 release.  From now until that release, I'll be working on
documentation and improving our implementation of recent SRFIs.

Please let us know if you find problems in version 0.99a1.

Will Clinger

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] apropos for Larceny

[William D Clinger]

KenD quoting Lars T Hansen:

> > There's also an apropos function already. Try (require 'apropos) to load
> > it.
> > 
> > --lars
> 
> Thanks.  I missed that.
> 
> Er, how does one import that with/into -r7rs mode?

Like this:

> (import (primitives r5rs:require))

> (r5rs:require 'apropos)
#t

> (import (primitives apropos)) ; could have been done by earlier import

> (apropos "conso")
(console-error-port
  console-error-port-factory
  console-input-port
  console-input-port-factory
  console-output-port
  console-output-port-factory)


This does not find macros, which use a different mechanism.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] library name clashes in larceny with the -r7rs -program options

[William D Clinger]

John Bignucolo wrote:

> I ran into a problem when I tried to change the program to use the
> string-join function from SRFI-13.
> 
> The '-r7rs' '-program' options require that you import everything you need.
> Since string-join is part of SRFI-13 I thought all I needed to do was:
> 
> (import (scheme base)
> (scheme load)
> (scheme write)
> (scheme process-context)
> (srfi 13))

> But this generated an error:
> 
> Syntax violation: import
> 
> Different bindings for identifier imported from libraries () and (srfi :13
> strings)
> 
> Form: string-for-each

A lot of the SRFI specifications are incompatible with R7RS
libraries or R6RS libraries or other SRFI libraries.  You have
to resolve those conflicts on your own, because Larceny can't
just guess which definition you want.

In this case, the specs for string-map and string-for-each
in SRFI 13 are incompatible with their R7RS specifications.
There are various ways to resolve that.  If you don't need
string-map and string-for-each, or you are willing to work
with the R7RS versions of those procedures, you can write

(import (scheme base)
(except (srfi 13) string-map string-for-each))

> I was able to able to get it work by changing the srfi import
> definition to be:
> 
> (only (srfi 13) string-join)

That's another good way to resolve the conflicts, and it's
an even better way if string-join is all you need.

> But this resulted in a five-fold increase in runtime, due I assume,
> to a longer startup time required to find string-join:

The longer startup time is caused by the implementation of
(srfi 13) in Larceny.  The (srfi 13) library imports the
(srfi :13) library, which imports six R6RS libraries, two
other SRFI libraries, the R7RS (scheme base) library, and
the (larceny shivers-syntax) library, which defines the
macros Olin Shivers used to write his implementation of
(srfi 13).  Some of those libraries may import yet other
libraries.

It just takes a while to load all those libraries.

You can examine the source code for those libraries in

lib/SRFI/srfi/13.sld
lib/SRFI/srfi/%3a13.sls

(et cetera)

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Larceny-users] v1.3 release candidate

[William D Clinger]

The nightly builds available this morning (for Linux and macOS only)
are candidates for a release of Larceny v1.3 late next week.  Please
let us know of any problems you discover.

Nightly build page:

http://www.cesura17.net/%7Elarcenists/Nightly/

Nightly build of user manual:

http://www.cesura17.net/~larcenists/Nightly/doc/user-manual-alt.html


Will Clinger

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] ARM Chromebook build progress (Ubuntu via Crouton; Acer Chromebook 13)

[William D Clinger]

Ken Dickey encountered the following error during a build
from source that appears to have been unpacked from
larceny-0.99-src.tar.gz :

--> Error: unhandled condition:
Compound condition has these components: 
#
#
who : compile-library
#
message : "contains non-library code"
#
irritants : ("._original.sls")

Ken wrote:

> Looks like the file indicated is
>   lib/R6RS/err5rs/records/syntactic/._original.sls
> 
> ..which seems to be an artifact of git.

That file (and numerous other files whose names begin with
"._") came from unpacking

http://www.larcenists.org/LarcenyReleases/larceny-0.99-src.tar.gz

Those files should not have been present within the source
distribution.  They contain gibberish related to an Apple
"feature" known as com.apple.quarantine:

https://developer.apple.com/library/content/releasenotes/Carbon/RN-LaunchServices/index.html

In short, the error you are encountering was caused by my use
of an Apple Macintosh and a Firefox browser when packaging the
source code for the larceny-0.99-src.tar.gz file.  

I have created a new larceny-0.99-src.tar.gz file, without the
"._" files, and copied that corrected file to the larcenists.org
site.  I will avoid using Apple products when creating the v1.3
files for download.

Thank you for bringing this problem to my attention.

Will

___
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

Re: [Larceny-users] Larceny-users Digest, Vol 70, Issue 1

[William D Clinger]

Thank you for testing the release candidate.

I apologize for being so slow to respond.  I've been on vacation and away
from the Internet for a week.

"KenD"  wrote:

> There appears to be a difference in R6 environments running in -r7rs mode
> between the x86 and ARM runtimes.  
> 
> My daily machine in an ARM Chromebook where test cases all pass, but I get
> a test failure on both the x86 release candidate and, when I checked, the
> x86 release as well.
> 
> Setup and run trace and details attached.

I am unable to reproduce this problem.  After cloning your Crosstalk
repository and changing the "/home/kend/" in sis.scm to "/tmp/", all
tests passed with v0.99 (as shown in the attached temp1.txt).  With
the nightly build available this morning, which should be equivalent
to the nightly build you used because none of the source code changed
while I was away, the tests are run in reverse order and there are
three test failures (as shown in the attached temp2.txt), but I did
not get the "undefined global variable: make-error-string-predicate"
error you got.

>From your second message:

> I took a quick run at building arm7 Larceny from a github clone.
> 
> The image runs fine as "larceny" but with either the -r7rs or -r7r6
> command line flags exhibits a problem:

Looks like you forgot to build the R7RS runtime as described in
http://www.cesura17.net/~larcenists/Nightly/doc/user-manual-alt.html#CompilingStdLibSection

I'll see if there's an easy way to generate an error message when
that happens.

Will
% larceny -r7rs -path .
Larceny v0.99 "Goldie" (May 25 2016 01:16:34, precise:Linux:unified)
larceny.heap, built on Wed May 25 01:17:00 EDT 2016

> (import (scheme load))

> (load "sis.scm")

> (load-source-bootstrap)

> (load "sis-tests.scm")

> (run-source-tests)

===> Starting  Tests for: st-conditions
===> Completed Tests for: st-conditions

===> Starting  Tests for: st-date-time
===> Completed Tests for: st-date-time

===> Starting  Tests for: st-parse
===> Completed Tests for: st-parse

===> Starting  Tests for: st-number
===> Completed Tests for: st-number

===> Starting  Tests for: st-boolean
===> Completed Tests for: st-boolean

===> Starting  Tests for: st-set
===> Completed Tests for: st-set

===> Starting  Tests for: st-xlate
===> Completed Tests for: st-xlate

===> Starting  Tests for: st-array
===> Completed Tests for: st-array

===> Starting  Tests for: st-object
===> Completed Tests for: st-object

===> Starting  Tests for: st-error-obj
===> Completed Tests for: st-error-obj

===> Starting  Tests for: st-symbol
===> Completed Tests for: st-symbol

===> Starting  Tests for: st-list
===> Completed Tests for: st-list

===> Starting  Tests for: st-dictionary
===> Completed Tests for: st-dictionary

===> Starting  Tests for: st-string
===> Completed Tests for: st-string

===> Starting  Tests for: st-stream
===> Completed Tests for: st-stream

===> Starting  Tests for: st-tokenizer
===> Completed Tests for: st-tokenizer

===> Starting  Tests for: st-character
===> Completed Tests for: st-character

===> Starting  Tests for: st-core-classes
===> Completed Tests for: st-core-classes

===> Starting  Tests for: st-blockClosure
===> Completed Tests for: st-blockClosure

===> Starting  Tests for: st-kernel
===> Completed Tests for: st-kernel

Test Results for testing
TOTAL PASSED: 213
TOTAL FAILED: 0
TOTAL EXCEPTIONS: 0
% mkdir /tmp/Temp/larceny-nightly-bin-native-ia32-linux86/lib/R6RS/kend
% cp *.sls !$
cp *.sls /tmp/Temp/larceny-nightly-bin-native-ia32-linux86/lib/R6RS/kend
% /tmp/Temp/larceny-nightly-bin-native-ia32-linux86/larceny -r7rs
Larceny v1.3b6 (Aug  4 2017 01:16:30, precise:Linux:unified)
larceny.heap, built on Fri Aug  4 01:16:55 EDT 2017

> (import (scheme load))

> (load "sis.scm")

> (load-source-bootstrap)

> (load "sis-tests.scm")

> (run-source-tests)

===> Starting  Tests for: st-set
===> Completed Tests for: st-set

===> Starting  Tests for: st-kernel
===> Completed Tests for: st-kernel

===> Starting  Tests for: st-list
===> Completed Tests for: st-list

===> Starting  Tests for: st-character
===> Completed Tests for: st-character

===> Starting  Tests for: st-error-obj
===> Completed Tests for: st-error-obj

===> Starting  Tests for: st-blockClosure
===> Completed Tests for: st-blockClosure

===> Starting  Tests for: st-tokenizer
===> Completed Tests for: st-tokenizer

===> Starting  Tests for: st-stream
===> Completed Tests for: st-stream

===> Starting  Tests for: st-parse
===> Completed Tests for: st-parse

===> Starting  Tests for: st-boolean
===> Completed Tests for: st-boolean

===> Starting  Tests for: st-string
===> Completed Tests for: st-string

===> Starting  Tests for: st-array
===> Completed Tests for: st-array

===> Starting  Tests for: st-number
===> Completed Tests for: st-number

===> Starting  Tests for: st-date-time
===> Completed Tests for: st-date-time

===> Starting  Tests for: st-core-classes
===> Completed Tests for: