-
scgmille committed patchset 3511 of module sisc to the SISC CVS repository, changing 1 files.
2009-11-02 16:34:33 UTC by scgmille
-
http://sisc.cvs.sourceforge.net/viewvc/sisc/sisc/src/sisc/boot/repl.scm?revision=1.39&view=markup
line 50 property lookup looks backwards.
2009-07-14 19:25:55 UTC by nobody
-
-kanishka.
2009-07-10 23:00:49 UTC by nobody
-
from srfi-18
"The mutex primitives specified in this SRFI do not implement "recursive" mutex semantics; an attempt to lock a mutex that is locked implies that the current thread must wait even if the mutex is owned by the current thread (this can lead to a deadlock if no other thread unlocks the mutex)."
under mutex-lock
"It is not an error if the mutex is owned by the current thread (but the...
2009-07-10 22:57:28 UTC by nobody
-
after glancing at provide-library inside the brief file "sisc/src/sisc/modules/libraries.scm", another dirty workaround would be
-use require-library once to get the library name registered centrally and have the out of date library loaded
-use load with explicit path to correct library file.
i'm not sure if you are also using modules inside the files. but possibly, if you only needed to...
2009-07-10 00:38:12 UTC by nobody
-
[continuing, hit submit by mistake..]
(with/fc
(lambda (er ek)
(define-java-classes )
(let* ((e (error-message er)))
(if (instance-of? e )
...handle exception...
(throw er))))
(lambda ()
(sexp->xml:xml->sexp/file "missing.xml")
)))
2) but if you hit an error...
2009-07-09 23:00:46 UTC by nobody
-
from my independent findings -
1) if its something as basic as the actual xml file passed in doesn't exist, the libraries behavior is sufficient. (to be friendly, it could put a pretty wrapper to hide the internal java exception.). overall, i would write client code as follows:
(with/fc
(lambda (m e)
2009-07-09 22:44:11 UTC by nobody
