On Mon, Sep 7, 2009 at 10:53 AM, erik quanstrom wrote:
>> maybe the bootstrap can be done with linuxemu.
>
> wouldn't that just give you yet another linux elf binary?
>
you are right. it must know how to compile correct a.out(6).
iru
On Mon, Sep 7, 2009 at 9:54 AM, John Floren wrote:
> On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums wrote:
>> Well, lisp != common lisp aside, I wouldn't mind a native CL system. I
>> haven't looked at the SBCL backend in quite sometime, but, assuming it's not
>> terribly insane, that would be a
> maybe the bootstrap can be done with linuxemu.
wouldn't that just give you yet another linux elf binary?
- erik
I was going to use SBCL to cross compile SBCL for Plan9.
On Mon, Sep 7, 2009 at 8:54 AM, John Floren wrote:
> On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums
> wrote:
> > Well, lisp != common lisp aside, I wouldn't mind a native CL system. I
> > haven't looked at the SBCL backend in quite somet
Clozure might be enough as well; it's C, but I've no idea how many POSIXisms
are in the source...
On Mon, Sep 7, 2009 at 9:19 AM, Fernan Bolando wrote:
> On Mon, Sep 7, 2009 at 8:54 PM, John Floren wrote:
> > On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums
> wrote:
> >> Well, lisp != common lisp
On Mon, Sep 7, 2009 at 8:54 PM, John Floren wrote:
> On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums wrote:
>> Well, lisp != common lisp aside, I wouldn't mind a native CL system. I
>> haven't looked at the SBCL backend in quite sometime, but, assuming it's not
>> terribly insane, that would be a
On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums wrote:
> Well, lisp != common lisp aside, I wouldn't mind a native CL system. I
> haven't looked at the SBCL backend in quite sometime, but, assuming it's not
> terribly insane, that would be a decent route. Most CL work that isn't
> specific to one
Well, lisp != common lisp aside, I wouldn't mind a native CL system. I
haven't looked at the SBCL backend in quite sometime, but, assuming it's not
terribly insane, that would be a decent route. Most CL work that isn't
specific to one of the proprietary systems (Allegro, LispWorks, &c.) is
written
lisp has been discuss in 9fans several times already
Anybody started porting clisp, gcl or any of the main lisp compilers?
I have been going at it on-and-off for some time never really
progressed, I was hoping
someone already started and got bored with it. I am hoping to use that
as a starting poi
On Tue, 08 Jul 2008 22:12:10 BST C H Forsyth <[EMAIL PROTECTED]> wrote:
> if you make it executable, i think you should also find that the resulting
> executable has its contents read into memory on demand (ie, a page fault
> causes
> a read from the executable file), which might suit you.
Right
if you make it executable, i think you should also find that the resulting
executable has its contents read into memory on demand (ie, a page fault causes
a read from the executable file), which might suit you.
On Tue, 08 Jul 2008 08:07:59 PDT "David Leimbach" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 8, 2008 at 7:08 AM, Dave Eckhardt
> <[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
> wrote:
>
> > > cmucl is directly executable but it has only enough
> > > intelligence to load a big lisp.core, which contains
On Tue, Jul 8, 2008 at 7:08 AM, Dave Eckhardt
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
wrote:
> > cmucl is directly executable but it has only enough
> > intelligence to load a big lisp.core, which contains
> > all the smarts.
>
> If these core files aren't generated all *that* often,
> one could wr
> cmucl is directly executable but it has only enough
> intelligence to load a big lisp.core, which contains
> all the smarts.
If these core files aren't generated all *that* often,
one could write a tool which would turn a core file
into a byte array, link a new lisp executable, and
exec() that.
On Mon, Jul 7, 2008 at 1:47 PM, Bakul Shah
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
wrote:
> On Mon, 07 Jul 2008 13:21:33 PDT "David Leimbach" <[EMAIL PROTECTED]>
> wrote:
> > (format t "Hello, World!~%")
> >
> > basically gets "read" then compiled then executed right? (thinking REPL
> > here)
> >
On Mon, 07 Jul 2008 13:21:33 PDT "David Leimbach" <[EMAIL PROTECTED]> wrote:
> (format t "Hello, World!~%")
>
> basically gets "read" then compiled then executed right? (thinking REPL
> here)
>
> Right? At least that's how SBCL works based on my understanding.
Well, it is not a read-eval-print
It's not entirely true that reads are not cached. The file servers of
course maintain large ram caches (or they should), and the clients can
request client-side caching with mount -C (the MCACHE flag), as is
normally done for the root:
; ns | grep '.-.*C'
mount -aC '#s/boot' /root
On Mon, 07 Jul 2008 20:55:36 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > It contains executable code but it is not an executable in
> > the sense you don't directly feed it to exec(2). A lisp
>
> in the script you gave earlier
> #!/usr/local/bin/cmucl -script
> (format t "Hell
On Mon, Jul 7, 2008 at 1:15 PM, Bakul Shah
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
wrote:
> On Mon, 07 Jul 2008 20:55:36 BST Charles Forsyth <[EMAIL PROTECTED]>
> wrote:
> > > It contains executable code but it is not an executable in
> > > the sense you don't directly feed it to exec(2). A lisp
> It contains executable code but it is not an executable in
> the sense you don't directly feed it to exec(2). A lisp
in the script you gave earlier
#!/usr/local/bin/cmucl -script
(format t "Hello, World!~%")
cmucl is directly executable but that's presumably the original
lisp im
On Mon, 07 Jul 2008 14:45:53 EDT erik quanstrom <[EMAIL PROTECTED]> wrote:
> i'm assuming by "core file" you don't mean executable.
> plan 9 already keeps an executable cache.
It contains executable code but it is not an executable in
the sense you don't directly feed it to exec(2). A lisp
proce
On Mon, Jul 7, 2008 at 11:45 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> i'm assuming by "core file" you don't mean executable.
> plan 9 already keeps an executable cache.
>
A Lisp core file can be equated to a specially formatted executable. The
Lisp environment is sort of a loader for thes
i'm assuming by "core file" you don't mean executable.
plan 9 already keeps an executable cache.
> Presumably the reads are cached?
reads are not cached. read on plan 9 is syncronous.
there is no block cache.
> Even so, there will the cost of copying to the segment. Or can
> one create multi
[Questions in the third para below.]
CMUCL "initializes" its state essentialy by loading a
previously dumped core image file. This is slow the first
time around but once the ~25MB core image is cached,
execution is really fast and you have access to a lot of
goodies. So a script like
#!/usr/loca
24 matches
Mail list logo
