From ffjeld at common-lisp.net  Fri Jun 10 12:32:34 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Fri, 10 Jun 2005 14:32:34 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no> <86acm44syr.fsf@shitbender.gagrod>
Message-ID: <2h64wmqtnh.fsf@vserver.cs.uit.no>

[second attempt, apparently there's some trouble with gmane or clnet
 or ..wherever]

Shawn Betts <sabetts at vcn.bc.ca> writes:

> Since vectors aren't resizable I manually resized the buffer data
> vector by creating a new, larger array, and copying the data
> over. Maybe that's what happened behind the scenes anyway :).
>
> In other cases where I accumulated data into an array with
> vector-push-extend, I was able to hardcode the size of the array and
> use a fill pointer.

I've just committed some code to implement adjustable vectors. It's
incomplete and most likely buggy still, but hopefully at least the
basic vector-push-extend etc. should work.

-- 
Frode Vatvedt Fjeld



From ffjeld at common-lisp.net  Thu Jun  9 22:25:06 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Fri, 10 Jun 2005 00:25:06 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no> <86acm44syr.fsf@shitbender.gagrod>
Message-ID: <2haclzqibh.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> Since vectors aren't resizable I manually resized the buffer data
> vector by creating a new, larger array, and copying the data
> over. Maybe that's what happened behind the scenes anyway :).
>
> In other cases where I accumulated data into an array with
> vector-push-extend, I was able to hardcode the size of the array and
> use a fill pointer.

I've just committed some code to implement adjustable vectors. It's
incomplete and most likely buggy still, but hopefully at least the
basic vector-push-extend etc. should work.

-- 
Frode Vatvedt Fjeld



From ffjeld at common-lisp.net  Sat Jun 11 10:08:02 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Sat, 11 Jun 2005 12:08:02 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no> <86acm44syr.fsf@shitbender.gagrod>
Message-ID: <2h1x79qk8t.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> I found a weird bug, too. I can't seem to create a trivial function
> to reproduce it though. basically, I have:
>
> (defun foo ()
>   (let (a)
>     (labels ((do1 ()
> 		  ;; do stuff and then
> 		  (when <stuff>
> 		    (setf a <a struct>)))
> 	     (do2 ()
> 		  ;; recursively call do2, do stuff, and then call..
> 		  (do1)))
>       (do2)
>       a)))
>
> and (foo) returns NIL instead of <a struct>. I'll keep looking into
> it for now..

If you can find the function as it was when the compiler failed, I can
look into this.

> I also go a vector-push extending error in some cases when calling
> format

This should be fixed now, with the new adjustable arrays. Btw. I had
format set up a target string of starting size 

  (+ (length control-string)
     (* 8 (count #\~ control-string)))

and anyone has a view on whether this is reasonable then please speak
up.

Otherwise it turned out that my work a couple of weeks ago with
threading (and segmentation) did various things that would cause weird
bugs to occur during GC and interrupts. This should also be fixed now.

-- 
Frode Vatvedt Fjeld



From ffjeld at common-lisp.net  Thu Jun 16 09:01:04 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Thu, 16 Jun 2005 11:01:04 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no> <86acm44syr.fsf@shitbender.gagrod>
Message-ID: <2h8y1aptf3.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> I found a weird bug, too. I can't seem to create a trivial function to
> reproduce it though. basically, I have:
>
> (defun foo ()
>   (let (a)
>     (labels ((do1 ()
> 		  ;; do stuff and then
> 		  (when <stuff>
> 		    (setf a <a struct>)))
> 	     (do2 ()
> 		  ;; recursively call do2, do stuff, and then call..
> 		  (do1)))
>       (do2)
>       a)))
>
> and (foo) returns NIL instead of <a struct>. I'll keep looking into
> it for now..

I think I've nailed this bug, too. The problem was actually that
function arguments were being re-ordered (in terms of execution order)
by the compiler, and your code had a case where argument 2 was a local
function-call that modified the lexical variable that was argument 4,
and when 4 was evaluated before 2 then the side-effect of 2 wasn't
visible. There was code in the compiler to avoid this problem, but it
was incorrect. But now hopefully it's good.

-- 
Frode Vatvedt Fjeld



From ffjeld at common-lisp.net  Thu Jun 16 09:11:25 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Thu, 16 Jun 2005 11:11:25 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no> <86acm44syr.fsf@shitbender.gagrod>
Message-ID: <2h1x72psxu.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> I had to hardcode the :size for make-hash-table, since they don't
> resize.

Now they do resize. As a side-effect of this, I scaled down the
default size of hash-tables created at dump-time (since it's no longer
so critical if they go full..) and this decreased the image size by
abut 100 KB :-)

-- 
Frode Vatvedt Fjeld



From sabetts at vcn.bc.ca  Fri Jun  3 01:01:02 2005
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Fri, 03 Jun 2005 01:01:02 +0000
Subject: [movitz-devel] adjust-array and basic-vector
Message-ID: <86psv445kh.fsf@shitbender.gagrod>

Hi,

I noticed that adjust-array isn't implemented (and hash resizing). The
basic-vector binary-type has a section called data. The comment
suggests the data is stored right there..as opposed to pointing to
where the data is stored. Is this so?

If so, won't this be problematic for resizing the vector?

-Shawn


From ffjeld at common-lisp.net  Fri Jun  3 05:36:41 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Fri, 03 Jun 2005 07:36:41 +0200
Subject: [movitz-devel] Re: adjust-array and basic-vector
References: <86psv445kh.fsf@shitbender.gagrod>
Message-ID: <2hr7fkt312.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> I noticed that adjust-array isn't implemented (and hash
> resizing). The basic-vector binary-type has a section called
> data. The comment suggests the data is stored right there..as
> opposed to pointing to where the data is stored. Is this so?

Yes.

> If so, won't this be problematic for resizing the vector?

That's right, such a vector cannot be adjustable. But this isn't
really a problem with the basic-vector layout as such, rather the
point is that there needs to be (at least) one other data-structure
that implements adjustable (and/or displaced, multi-dimensional)
arrays.

This could I suppose be done simply by building on the existing stuff,
e.g. by using defstruct etc on the losp/.. side of things. A number of
functions in array.lisp would have to be modified, and also several
things in typep.lisp, to integrate it properly with the type-system.

Hash resizing can be implemented independently of this, since the
hash-table object already gives you an indirect link to the vector
data. (And BTW note that EQ hash-tables aren't GC-safe yet,
either... for keys other than immediates and symbols, that is.)

-- 
Frode Vatvedt Fjeld



From sabetts at vcn.bc.ca  Sat Jun  4 19:53:15 2005
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Sat, 04 Jun 2005 19:53:15 +0000
Subject: [movitz-devel] Emacs on the metal
Message-ID: <86k6l9526s.fsf@shitbender.gagrod>

Hi,

For the past while I've been building a GNU Emacs clone written
entirely in common lisp. My intention was always to have it run on
movitz (it also runs on sbcl and cmucl with cl-ncurses). Today I
finally got it working on movitz.

Its a bit buggy on movitz :). I had to hack up some code here and there to
get around some of the current movitz limitations. Anyway there's a
screenshot and a kernel image here:

http://www.emmett.ca/~sabetts

I'll put the source in a tarball and post there soon, too.

To run it, load the image then run:

(lice::lice)

-Shawn


From ffjeld at common-lisp.net  Sun Jun  5 00:14:43 2005
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Sun, 05 Jun 2005 02:14:43 +0200
Subject: [movitz-devel] Re: Emacs on the metal
References: <86k6l9526s.fsf@shitbender.gagrod>
Message-ID: <2hhdgdu0b0.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> For the past while I've been building a GNU Emacs clone written
> entirely in common lisp. My intention was always to have it run on
> movitz (it also runs on sbcl and cmucl with cl-ncurses). Today I
> finally got it working on movitz.

Just tried your image in VMWare. Looks awesome! :-)

> Its a bit buggy on movitz :).

If you have something like a list of movitz quirks, let me have it and
I'll see if I can fix things now and then. (Patches are welcome too,
obviously..) I suppose improved arrays are on the top of the list.

-- 
Frode Vatvedt Fjeld



From sabetts at vcn.bc.ca  Sun Jun  5 17:24:44 2005
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Sun, 05 Jun 2005 17:24:44 +0000
Subject: [movitz-devel] Re: Emacs on the metal
In-Reply-To: <2hhdgdu0b0.fsf@vserver.cs.uit.no>
	(Frode Vatvedt Fjeld's message of "Sun, 05 Jun 2005 02:14:43 +0200")
References: <86k6l9526s.fsf@shitbender.gagrod>
	<2hhdgdu0b0.fsf@vserver.cs.uit.no>
Message-ID: <86acm44syr.fsf@shitbender.gagrod>

Frode Vatvedt Fjeld <ffjeld at common-lisp.net> writes:

>> Its a bit buggy on movitz :).
>
> If you have something like a list of movitz quirks, let me have it and
> I'll see if I can fix things now and then. (Patches are welcome too,
> obviously..) I suppose improved arrays are on the top of the list.

Here's a list of shortcuts I made to get lice working:

I couldn't figure out a way to get the lice files to load at the right
time. in los0.lisp it calls (genesis) at the end which initialised a
bunch of stuff and starts the repl. If I loaded my source before los0
then it'd keep rebooting. if i did it after, none of the variables
whose value was made by executing code would be initialized (they were
all NIL). I tried breaking genesis into 2 functions. The second one
I'd call from my lice lisp file. But then everytime i'd try to access
one my these variables it'd reboot. So I created an init function that
popuplated all the variables. Obviously lice doesn't need to be part
of the kernel. It could be loaded after the kernel is booted. But the
target lisp isn't complete enough..and where would it load lice from? :)

I had to hardcode the :size for make-hash-table, since they don't resize.

Since vectors aren't resizable I manually resized the buffer data
vector by creating a new, larger array, and copying the data
over. Maybe that's what happened behind the scenes anyway :).

In other cases where I accumulated data into an array with
vector-push-extend, I was able to hardcode the size of the array and
use a fill pointer.

In the display code I used a 1 dimensional array as a double buffer
and a second 2d array that was displaced to the 1d array. I had to
ditch the 2d array and just do the math myself to figure out where an
x,y coordinate mapped to.

I had a couple spots where I had to change the code because the
compiler couldn't "lend optional right now".

I had to comment out an s-expression because there's no
get-universal-time.

the lisp-interactive-mode didn't work because there's no
read-from-string, tho I found a simple-read-from-string, which would
probably work.

I found a weird bug, too. I can't seem to create a trivial function to
reproduce it though. basically, I have:

(defun foo ()
  (let (a)
    (labels ((do1 ()
		  ;; do stuff and then
		  (when <stuff>
		    (setf a <a struct>)))
	     (do2 ()
		  ;; recursively call do2, do stuff, and then call..
		  (do1)))
      (do2)
      a)))

and (foo) returns NIL instead of <a struct>. I'll keep looking into it
for now..

I also go a vector-push extending error in some cases when calling
format (I'm fairly certain it was because of format..but not 100%
sure). I wrote this to get around:

(defun fmt (fmt &rest args)
  "A movitz hack function. FORMAT sometimes gives an error, so i use this to get around it."
  (let ((s (make-array 100 :fill-pointer 0 :element-type 'character)))
    (apply #'format s fmt args)
    s))

Other than that it Just Worked :). There are still some places where I
get a vector-push extending error, which i haven't worked around yet.

-Shawn