interrupt handlers session data slot

I've written a statistical profiler for Scheme48 that works by
instrumenting the interrupt handler for alarm interrupts.  It needs
access to the interrupt handler that it replaces, in order to defer to
it to actually handle the interrupt, and to revert to it when finished
profiling.

Unfortunately, there is, at the moment, no way in Scheme48 to get at a
current interrupt handler, so right now I'm hard-coding the actual
value of the session data key for the interrupt handler vector, which
is, of course, totally bogus, but which works provisionally.  It would
be better, I think, for the INTERRUPTS structure to export either the
session data key or a procedure INTERRUPT-HANDLER, by analogy with
SET-INTERRUPT-HANDLER!, that returns the current interrupt handler
procedure for a certain interrupt.

Thoughts?  Is there anything fundamentally wrong with this?  It's easy
to implement, anyway.

Scheme 48 fails to build from source on m68k with gcc 4

Hello!
There seems to be a problem building Scheme 48 1.3 on m68k using
GCC 4.0.4, as reported on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339602

The error is:

./build/build-usual-image . "`(cd . && echo $PWD)`/scheme" 'scheme48.image' './scheme48vm' \
        './build/initial.image'
Correcting byte order of resumed image.
not a bignum -1071103060
make[1]: *** [scheme48.image] Error 255

Any idea on what might cause this? I'm happy to provide any
further information if I'm told how to acquire it. 

Regards,
        -- Jorgen

--

-- 
((email . "forcer <at> forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))

Exporting from files with renaming

I'm trying to define a structure that is implemented in a file, but I
need to rename the names used in the file.  How can I do this?

One solution is to have an auxiliary structure that uses the original
names in the file and then the real structure opens the auxiliary one
and renames appropriately.  I ran into this in the context of
implementing SRFI 71.  The reference implementation defines
srfi-let/let*/letrec, but the interface should export them as
let/let*/letrec.

Is there a better way to do this than the following?

Thanks,
David

(define-interface srfi-71-interface
  (export ((let let* letrec) :syntax)
          ((values->list values->vector) :syntax)
          uncons
          uncons-2
          uncons-3
          uncons-4
          uncons-cons
          unlist
          unvector))

(define-structure srfi-71*
  (export ((srfi-let srfi-let* srfi-letrec) :syntax)
          ((values->list values->vector) :syntax)
          uncons

Re: Exporting from files with renaming

Here's a kludge that may work to avoid duplicating the whole
interface, although you will have to duplicate the renamings:

  (define-interface srfi-71-interface ...)

  (define-structure srfi-71-bogosity srfi-71-interface)

  (define-structure srfi-71-internal
      (interface-of (modify srfi-71-bogosity
                            (rename (let srfi-let)
                                    (let* srfi-let*)
                                    (letrec srfi-letrec))))
    (open (modify scheme ...))
    (files srfi-71))

  (def srfi-71 (modify srfi-71-internal
                       (rename (srfi-let let)
                               (srfi-let* let*)
                               (srfi-letrec letrec))))

This is, however, a horrible kludge, except for the last definition,
which you could use without the horrible kludge.  The module language
currently provides no way to modify interfaces themselves, only to
modify structures.

The Right Thing, I think, would be to introduce another kind of
object, a translation.  Interfaces would become lists of binding
descriptors, and structures would be triples of package, translation,
and interface.  Rename-on-import and rename-on-export would become
equally easy this way, and interfaces would be simplified.  Indeed, I

Re: Minor runtime feature

Heath Putnam <hp <at> heathputnam.com> writes:

> I've attached a tiny patch to make it possible for the user to handle
> deadlocks in scheme48's runtime as CML events:
>
> diff /tmp/scheme48-1.3/scheme/rts/root-scheduler.scm /usr/local/src/scheme48-1.3/scheme/rts/root-scheduler.scm
> 149,152d148
> < (define (current-deadlock-handler)
> <   (session-data-ref deadlock-handler))
> <   
> < 
> diff /tmp/scheme48-1.3/scheme/rts-packages.scm /usr/local/src/scheme48-1.3/scheme/rts-packages.scm
> 326,327c326
> < 					 call-when-deadlocked!
> < 					 current-deadlock-handler)
> ---
>> 					 call-when-deadlocked!)

I'm not sure a session-wide setting is the right thing---you might get
deadlock events from all kinds of sources, not just your own program.
I think the thing to do is to write your own scheduler that detects
deadlock, and thus create a proper scope for your deadlock events.
This way, you can also make assumptions about lazy-bum threads like
the one you mentioned:

> (spawn (lambda ()
>          (let loop () 
> 	   (sleep 1000)
>            (loop))))

Re: Minor runtime feature

   Date: Tue, 20 Jun 2006 20:06:08 +0200
   From: Michael Sperber <sperber <at> informatik.uni-tuebingen.de>

   Heath Putnam <hp <at> heathputnam.com> writes:

   > VM exception `wrong-type-argument' with no handler in place
   > opcode is: checked-record-ref
   > stack template id's: 2230 <- 2284 <-  <-  <-  <- 4700 <- 4666 <- 4671 <- 4717 <- 2349 <- 1441 <- 2346 <- 1441 <- 1627
<- 2132 <- 1441 <- 
   >
   >
   > I would like to know what the bug is.

   Do the template IDs show up in build/initial.debug?

I looked at this a couple months ago and concluded the following,
which I sent in an email that I guess I didn't cc to the list:

   Date: Tue, 11 Apr 2006 17:05:06 +0000
   From: "Taylor R. Campbell" <campbell <at> mumble.net>

   The obscure error you got, by the way, was due to blocking in the root
   scheduler, which must not happen.  The first stack frame was in
   SUSPEND-TO, where I am guessing it passed #F (as the value of the
   SCHEDULER parameter) to THREAD-CURRENT-TASK; SUSPEND-TO was called by
   MAYBE-COMMIT-AND-BLOCK, which passed for the SCHEDULER parameter the
   scheduler of the current thread.  Problem: the current thread, being
   the root scheduler thread, does not have a scheduler.  I presume that
   MAYBE-COMMIT-AND-BLOCK was called from somewhere in the rendezvous
   system, which follows from your use of synchronous channels in the

Re: Fix for broken CML sync routines

Heath Putnam <hp <at> heathputnam.com> writes:

> There is a bug in the CML library's synchronization routines.  The
> library uses with-new-proposal in a bad way: the wrap-proc of the
> synchronized event gets called with a different continuation than the
> sync. The continuation only resets the propsal and calls the original
> continuation. [...]

Oops.  I remember being careful about tail recursion in the original
CML implementation (with locks), but somehow forgot about it in the
transition to proposals.  I'll put (a variant of) your fix into the
next release.

Thanks for the detailed report & fix!

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Condition: (&interrupt post-gc)

I've been getting this &interrupt on a regular basis.
It seems to occur when I ask Scheme 48 to load (or ",in")
a fairly large file.  What is the proper recovery from
this strange interrupt?

Will

Re: Condition: (&interrupt post-gc)

   Date: Wed, 21 Jun 2006 22:05:12 -0400
   From: William D Clinger <will <at> ccs.neu.edu>

   I've been getting this &interrupt on a regular basis.
   It seems to occur when I ask Scheme 48 to load (or ",in")
   a fairly large file.  What is the proper recovery from
   this strange interrupt?

This indicates that Scheme48 thinks that the heap is still dangerously
full after a GC.  You can sometimes proceed with the ,PROCEED command,
but you might get a fatal heap overflow error if the problem persists.
If this happens, you can also expand the heap (whose size is fixed for
any particular Scheme48 instance -- at least, until the new GC is
released) using the `-h' command-line option.

expanding the ,BOUND? command

Attached is a small patch that expands the output of the ,BOUND?
command to make it more readable by humans and to set the focus object
to the binding, if there is one, in order, say, to inspect it further.
Apply with `patch -p1 <boundp.diff` from the top-level Scheme48
directory.  Does this sound like a good idea?

diff -ru scheme48-1.3~/scheme/env/debug.scm scheme48-1.3/scheme/env/debug.scm
--- scheme48-1.3~/scheme/env/debug.scm	2005-04-27 04:45:49.000000000 -0400
+++ scheme48-1.3/scheme/env/debug.scm	2006-06-22 12:06:09.000000000 -0400
 <at>  <at>  -657,10 +657,39  <at>  <at> 
 	(probe (package-lookup (environment-for-commands) name)))
     (if probe
 	(begin (display "Bound to " port)
-	       (write probe)
-	       (newline port))
+	       (cond ((binding? probe)
+                      (describe-binding probe port))
+                     (else
+                      (write probe port)
+                      (newline port)))
+               (set-focus-object! probe))
 	(write-line "Not bound" port))))

+(define (describe-binding binding port)
+  (let ((type (binding-type binding))
+	(location (binding-place binding))
+	(static (binding-static binding)))
+    (display (binding-type-description binding) port)
+    (write-char #\space port)