From mulix at mulix.org Thu May 5 06:56:03 2005 From: mulix at mulix.org (Muli Ben-Yehuda) Date: Thu, 5 May 2005 09:56:03 +0300 Subject: [movitz-devel] [PATCH] ll-testing needs muerte.init Message-ID: <20050505065603.GF6708@granada.merseine.nu> I get the following error with current CVS: Reader error at 5523 on #: Package "MUERTE.INIT" not found. [Condition of type COMMON-LISP::READER-PACKAGE-ERROR] The following trivial patch fixes it for me: Index: losp/los0.lisp =================================================================== RCS file: /project/movitz/cvsroot/movitz/losp/los0.lisp,v retrieving revision 1.41 diff -u -r1.41 los0.lisp --- losp/los0.lisp 3 May 2005 20:13:07 -0000 1.41 +++ losp/los0.lisp 5 May 2005 06:43:30 -0000 @@ -28,8 +28,6 @@ (require :lib/net/ip4) (require :lib/repl) -(require :ll-testing) - (defpackage muerte.init (:nicknames #:los0) (:use #:common-lisp @@ -44,6 +42,8 @@ #:muerte.ip4 #:muerte.mop #:muerte.x86-pc.serial)) + +(require :ll-testing) (require :los0-gc) ; Must come after defpackage. -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ From ffjeld at common-lisp.net Thu May 5 10:58:13 2005 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Thu, 05 May 2005 12:58:13 +0200 Subject: [movitz-devel] Re: [PATCH] ll-testing needs muerte.init References: <20050505065603.GF6708@granada.merseine.nu> Message-ID: <2h4qdi2b3u.fsf@vserver.cs.uit.no> Thanks for the report and patch. I chose to just remove the offending function, as it's not really supposed to live there.. ll-testing is more or less a scratch buffer where I put some .. well, low-level testing code. Anyway, I did a compile from scratch now, and it should work. -- Frode Vatvedt Fjeld From sabetts at vcn.bc.ca Mon May 9 21:06:48 2005 From: sabetts at vcn.bc.ca (Shawn Betts) Date: Mon, 09 May 2005 21:06:48 +0000 Subject: [movitz-devel] Re: [PATCH] ll-testing needs muerte.init In-Reply-To: <2h4qdi2b3u.fsf@vserver.cs.uit.no> (Frode Vatvedt Fjeld's message of "Thu, 05 May 2005 12:58:13 +0200") References: <20050505065603.GF6708@granada.merseine.nu> <2h4qdi2b3u.fsf@vserver.cs.uit.no> Message-ID: <86br7kun13.fsf@shitbender.gagrod> Frode Vatvedt Fjeld writes: > Thanks for the report and patch. I chose to just remove the offending > function, as it's not really supposed to live there.. ll-testing is > more or less a scratch buffer where I put some .. well, low-level > testing code. Anyway, I did a compile from scratch now, and it should > work. Is there a way to compile not from scratch? create-image seems to build from scratch everytime. -Shawn From ffjeld at common-lisp.net Tue May 10 06:46:08 2005 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 10 May 2005 08:46:08 +0200 Subject: [movitz-devel] Re: [PATCH] ll-testing needs muerte.init References: <20050505065603.GF6708@granada.merseine.nu> <2h4qdi2b3u.fsf@vserver.cs.uit.no> <86br7kun13.fsf@shitbender.gagrod> Message-ID: <2h3bsv1sun.fsf@vserver.cs.uit.no> Shawn Betts writes: > Is there a way to compile not from scratch? create-image seems to > build from scratch everytime. Certainly there is. The basic function for doing this is movitz-compile-file, which compiles the contents of a file into *image*. You'll want to set up one of the emacs-modes, either my movitz/movitz-mode.el (a rather ugly hack over Franz' ELI, and requires ACL), or Luke's stuff in movitz/ide/ which presumably is better although I don't use it myself so I can't vouch for how in-sync it is with Slime etc (but patches are welcome). As any lisper knows, incremental compiles is essential :) I regularly do compiles, disassemble, macroexpand, dump-image-and-run-bochs, etc. from inside emacs buffers. -- Frode Vatvedt Fjeld From sabetts at vcn.bc.ca Sun May 29 16:37:46 2005 From: sabetts at vcn.bc.ca (Shawn Betts) Date: Sun, 29 May 2005 16:37:46 +0000 Subject: [movitz-devel] defvar and reboots Message-ID: <86ll5y9eed.fsf@shitbender.gagrod> Hello, I've found that in some cases defvar and defparameter cause movitz to reboot upon loading. initializing the variable with nil a number seems to work fine, but a cons or a function call causes a reboot. The following causes a reboot: (defvar *commands* (make-hash-table) "A hash table of commands") I'm going to try to dig into it a bit, but I have a feeling it'll get over my head pretty fast. Is this a known problem? Is it easy to fix? :) So far I've been able to rearrange my code to avoid the problem but my code is such that this case is a bit difficult to get around. -Shawn From ffjeld at common-lisp.net Sun May 29 22:15:21 2005 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Mon, 30 May 2005 00:15:21 +0200 Subject: [movitz-devel] Re: defvar and reboots References: <86ll5y9eed.fsf@shitbender.gagrod> Message-ID: <2hy89xvfuu.fsf@vserver.cs.uit.no> Shawn Betts writes: > I've found that in some cases defvar and defparameter cause movitz > to reboot upon loading. initializing the variable with nil a number > seems to work fine, but a cons or a function call causes a > reboot. The following causes a reboot: > > (defvar *commands* (make-hash-table) > "A hash table of commands") A reboot I would guess means an exception is triggered before exception-handlers are installed. And that exception I guess would be triggered by trying to allocate memory (as make-hash-table obviously does) before dynamic memory allocation is initialized. Verify that your file with the defvar top-level form comes after at least lib/malloc-init (but preferrably also the other two, muerte/print and x86-pc/textmode, and whatever you have that is equivalent to the genesis function in los0.lisp) in the load-sequence that gets printed at dump-time. Just now I tried to add such a defvar to los0.lisp, and it turns out that make-hash-table also requires CLOS to be bootstrapped, and if that wasn't already done (explicitly) then the kernel would die, though slightly more gracefully than just rebooting. I just checked in a couple of tweaks that fixes this behavior, so that now only some warnings should be seen (about auto-bootstrapping CLOS) in such cases. -- Frode Vatvedt Fjeld