Major bugs: - An .optUnget test gets null unexpectedly under CLISP and OpenMCL - try writing independent tests for path-loader to see if the problem is there - The standard rune-in-E code doesn't work (at last try it runs the script then goes off into an infinite loop with something counting up) - if the mismatch printing in updoc fails, it won't be caught by the chainer, leaving us with Lost Signal - Auditors get more authority than they should: all the state of the audited object. - Closing sockets is not supported at all. Minor bugs: - clrune doesn't work because file__uriGetter doesn't accept relative paths. This is a design issue. - NaN/Infinity aren't sufficiently faked on lisps not exposing them. - for run-program, add interfaces to process-kill and process-close so that the io-handler-pound test doesn't leak fds Internal bugs: - The standard makeBrand is (correctly) not DeepFrozen, so DeepFrozen special-cases its EventuallyDeepFrozen peekBrand. Little features: - FlexSet - serialization-base primitives: __optUncall where needed, selfless where needed, Loader#optUncall. - have updoc stop running a given script if a mismatch has occurred and a later step depends on a lexical binding made/shadowed by that step Big features: - more complete socket IO - more complete file IO - Character stream encoding/decoding. - term trees - true vats - boot-comm system - threaded vats - Audited Selfless for E-objects - Pluribus Code cleanups not marked in the code: - reorganize: rename elib.lisp once it's been pared down to just the external macros and stuff - reorganize: rename tables2.lisp now that elib-tables.lisp is gone - make sure we have vm.updoc tests for rebinding boundaries' presence and absence Optimizations: - Perhaps instead of EscapeExpr, MatchBind, etc, immediately reifying ejectors, they could make ejector bindings whose get-code creates the ejector. The straightforward places to take advantage of this would be in trinary-define and CallExpr where the receiver is an ejector binding's value. --- For encoding/decoding: sb-ext:octets-to-string byte-vector &key :external-format :start :end sb-ext:string-to-octets string &key :external-format :start :end :null-terminate for an incomplete utf8 sequence, octets-to-string will signal SB-IMPL::END-OF-INPUT-IN-CHARACTER, whose nearest external superclass is SB-INT:CHARACTER-DECODING-ERROR. * (sb-mop:class-precedence-list (find-class 'SB-IMPL::END-OF-INPUT-IN-CHARACTER)) --- E-in-S-expression syntax ideas (not necessarily to be implemented any time soon) (def l (list l)) (do (def (list l__1 lR__3) (Ref :promise)) (def res__5 (def l (__makeList :run l__1))) (lR__3 :resolve l) res__5) (do (def simplifyFQName #) (def makeAdvisoryInterface obj :implements DeepFrozen (to (:run typeDesc) (as any) (def advisoryInterface obj :extends (__makeGuard advisoryInterface) (to (:audit objectExpr witness) (as any) false) (to (:coerce specimen _) (as any) specimen) (to (:__printOn (as TextWriter out)) (as void) (out :print (simplifyFQName (typeDesc :getFQName)))))))) --- Arbitrary anonymous functions as type specifiers: (lambda (guard) (let ((sym (make-symbol (e-quote guard)))) (setf (symbol-function sym) (lambda (specimen) (eeq-is-same-yet (e. guard |coerce| specimen) specimen))) `(satisfies ,sym))) --- This unfinished scrap of code from vtable-case-entry wouldn't have worked, but might have some use later (let* ((name (format nil "~A#~A" type-name mverb)) (sym ; These are feature conditionals to remind me that they must be set at compile time anyway. #-e.intern-vtable-methods (make-symbol name) #+e.intern-vtable-methods (loop for i from 1 for free = name then (format nil "~A-dup-~A" name i) while (find-symbol name :e.elib.vtable-methods) finally (return (intern free :e.elib.vtable-methods))))) `(apply #-e.intern-vtable-methods (named-lambda ,sym ,@(cdr desc)) #+e.intern-vtable-methods ,(progn (...)) ,@prefix-args ,args-sym)) --- Possibly for use in float next/previous methods http://paste.lisp.org/display/10847 ------ Begin Forwarded Message ------- Subject: Re: A function returning the next representable floating point value of an argument From: Bruno Haible Newsgroups: comp.lang.lisp Date: 24 May 2005 19:39:44 GMT Christophe Rhodes wrote: >> (t (multiple-value-bind (significand exponent integer-sign) >> (integer-decode-float f) >> (let ((result (float (* (1+ significand) >> (expt (float-radix f) exponent)) >> f))) > > Hmm. Without thinking /too/ hard about this, I'd venture that this > isn't going to work in an implementation which represents its floating > point values as IEEE single-floats, for F at the boundary between one > exponent and the next, in round-to-even rounding mode. > ... > This would seem to be generating the next float further away from > zero, not the next greatest float, for negative f. You are right. But this one should work, uniformly producing the next greater single-float, considering -0.0 and +0.0 as equal and ignoring the problem of "denormalized floats": (defun single-float-above (f) "Return the next representable single-float value greater than F." (check-type f single-float) (cond ((zerop f) least-positive-single-float) ((= most-positive-single-float f) (error "~f is most-positive-single-float." f)) (t (multiple-value-bind (significand exponent integer-sign) (integer-decode-float f) (if (minusp integer-sign) (progn (when (zerop (logand significand (- significand 1))) (setq significand (* (float-radix f) significand)) (setq exponent (- exponent 1))) (float (* (1+ (- significand)) (expt (float-radix f) exponent)) f)) (float (* (1+ significand) (expt (float-radix f) exponent)) f)))))) The 'logand' part probably needs to be changed if (float-radix f) is not 2. However, I don't know how the significand (mantissa) is normalized in implementations where (float-radix f) is 4 or 16 or something like this. P.S.: What do you need this for? You can implement TYPEP and SUBTYPEP without needing this kind of operation on floating-point numbers. Bruno -------- End Forwarded Message -------- --- Notes on crypto required for upcoming inter-vat protocol: http://www.eros-os.org/pipermail/e-lang/2005-June/010762.html http://www.eros-os.org/pipermail/e-lang/2005-June/010764.html http://www.eros-os.org/pipermail/e-lang/2005-June/010765.html > Tyler, what cyphersuite does VatTP-on-TLS use? The acceptable cyphersuites are determined by the Keyspace implementation. Right now, there's just one implementation of the Keyspace interface: org.waterken.url.tls.sha1withrsa.Keyspace. For this Keyspace, the acceptable ciphersuites are, in order of preference: /** * The acceptable ciphersuites. */ private static final String[] ACCEPTABLE = new String[] { "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "SSL_RSA_WITH_RC4_128_SHA", "SSL_RSA_WITH_3DES_EDE_CBC_SHA" }; Tyler http://www.eros-os.org/pipermail/e-lang/2005-July/010880.html