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. - mapStream.chunked doesn't check that the function returns the proper number of elements, and this is abused. - We need to take *default-pathname-defaults* off asdf:*central-registry*, so that E-on-CL images don't accidentally load code from the current directory; also think about what else in this vein might be needed. 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 - Inconsistency between Scope and eval: 'def &x := __makeFinalSlot(...); x := ...' right now is caught statically as a single expression but not if &x goes through a Scope - option #1: introduce synEnv - option #2: remove static assignment-to-final catching - The Updoc parser is sloppy and in need of tests. - .optUncall fails on unsettled arguments; should return null. - Keywords should be lowercase-only. Internal bugs: Little features: - serialization-base primitives: __optUncall where needed, selfless where needed, Loader#optUncall. - Investigate what SourceSpan#isOneToOne really means (as it is it seems to be ambiguous between "mixed-up" and "multiline") - __getAllegedType merging at the miranda-and-matcher interface - "lambda-args" syntax Big features: - Standalone images (no loading emakers from lib/, stubbed out ASDF, etc.). Use to make binaries for users who don't want to install CL+ASDF+dependencies. - Parse E code without requiring E-on-Java. - more complete socket IO - more complete file IO - finish term-tree system (matching, etc.) - Pluribus (now partially done). Subtasks: - Buffering __whenMoreResolved and __whenBroken on remote promises, to handle breakage and to eliminate unnecessary network traffic. - Using DelayedRedirectors in the resolution of remote promises. def redirector(shortening) { if (isFresh()) { localPromiseResolver.resolve(shortening) } else { def [p, r] := Ref.promise() localPromiseResolver.resolve(p) E.sendOnly(originalPromise, "__whenMoreResolved", [r.resolve]) } } - VatTP (encrypted wire protocol/connection-manager/negotiation layer). - De-stubbing Introducer/SturdyRef/IdentityMgr. - Incorporating LocatorUnum. - WormholeOp. - Try multi-process runner communication Threading is error-prone and not universally available; memory images and process creation are *more* available and much safer; - Try removing multi-vat-per-process support: if a vat = a process, then we can make more things global/compiled-in. - Disadvantages: interprocess serialization overhead; less shared resources - Threaded runners, if the multi-process version doesn't turn out sufficient. - Audited Transparent for E-objects - Implicit parallelism (requires thread-safety): - If the send queue has at the head several sends whose target and arguments are DeepFrozen and thread-safe, and at most one which isn't, then they may be run simultaneously. Looking at the result ref for such a send must wait for the thread to finish. - Map/filter/etc -- anything which invokes a callback repeatedly and independently -- could be parallelized; however, this can't be done for 'for' loops since the standard iteration protocol depends on external side-effects to produce results. - Lazy refs could be evaluated on idle processors. This is not that interesting unless lazy refs are exposed to the user (requiring the thunk to be DeepFrozen), in which case evaluation should also be controllable. Code cleanups not marked in the code: - See if makeSharedRefLink.emaker is improved by not using deSubgraphKit. We'd have to reimplement object graph walking, but wouldn't have to contort to fit Data-E. - 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. - Constant folding for calls when the receiver and args are DeepFrozen and known to terminate. --- 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)))))))) --- 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