The port to Allegro console version was completed two days ago. The
code is not public yet. *Thanks included to people who posted to my
query 'two questions on Allegro'.*
FYI, the Allegro compiler messages were silenced by a mixture of code
changes and muffling the remaining recalcitrant messages. The saving
image problem was not solved and remains a mystery and I'm talking to
Franz who are very helpful. However Qi startup by loading the FASL
file is quick (< 5 secs).
The graphical Allegro remains more of a challenge because of case
settings and package problems, but this can wait for now.
I hope to release this version but, because this is a commissioned
port, it may be delayed by a month or so.
cheers
Mark
On 20 Apr, 08:34, Vagif Verdi <···········@gmail.com> wrote:
> Oh man! I was hoping SBCL or lispworks port will come next :(
I was corrupted by £ ! ;)
Mark
Mark Tarver wrote:
> On 20 Apr, 08:34, Vagif Verdi <···········@gmail.com> wrote:
>> Oh man! I was hoping SBCL or lispworks port will come next :(
>
> I was corrupted by � ! ;)
What are actually the parts that are implementation-dependent and
prevent Qi from being plain portable Common Lisp?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 20 Apr, 09:46, Pascal Costanza <····@p-cos.net> wrote:
> Mark Tarver wrote:
> > On 20 Apr, 08:34, Vagif Verdi <···········@gmail.com> wrote:
> >> Oh man! I was hoping SBCL or lispworks port will come next :(
>
> > I was corrupted by £ ! ;)
>
> What are actually the parts that are implementation-dependent and
> prevent Qi from being plain portable Common Lisp?
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
All the parts that are not part of CLTL - quit and save functions -
the names
of compiled files (i.e. their extensions), the routines for invoking
compiled images,
the way the Lisp compiler gives off warnings, the default case
settings ......
...... and also quirky stuff. CMU needs a FORCE-OUTPUT at one point
whereas CLisp does not. That sort of thing.
Mark
Mark
Is it possible to implement Qi as a common lisp library ?
And if it is why didn't you choose that?
BTW Congratulation for the port i hope lispworks will
fallow soon.
bboi
On 20 Apr, 13:48, fireblade <·················@gmail.com> wrote:
> Mark
>
> Is it possible to implement Qi as a common lisp library ?
> And if it is why didn't you choose that?
>
> BTW Congratulation for the port i hope lispworks will
> fallow soon.
>
> bboi
Not sure exactly what it means to 'implement Qi as a CL library'.
Do you mean, to be able to load Qi into your running Lisp image and
use it just like any Lisp program - staying in Lisp?
You can do that! I've not set it up that way, but its not hard.
The port challenges do not totally disappear though - and the Qi top
level is the best way to program with Qi since you can still LOAD Lisp
files into it, toggle type checking, use the QUOTE-free syntax, and
repeat line entries with !.
Portability was not the main objective when Qi was released. Speed
and code
reliability were more important (+ correctness proofs + formal
semantics +
documentation etc.). No point in making portability top if people
don't want the
system! Now there is a demand - portability becomes important. With
Allegro, CMU and CLisp pegged the next candidates are SBCL and
Lispworks. After that what? Maybe MCL and PowerLisp.
Qi will move towards what Bill Clemson called 'Lisp with batteries
included' - that is a modern Lisp-based functional programming
environment with the features that programmers want for doing serious
apps. A lot of these features exist in CL implementations but lie
outside the CLTL specification which is nearly 20 years old and so you
get these differences (e.g. like how you call the OS from Lisp).
These differences put off noobs a lot.
Qi will progressively iron out these differences by placing a layer of
type secure abstraction over these implementation differences so that
you get command over these resources without worrying about what
version of CL you are running. The price of this is that the porter
(= me :() has to work hard juggling features and reading boring
doc.
Qi is really about the modernisation of CL. A topic that has divided
the CL community for a long time and for which no generally agreed
solution has been reached.
Mark
On 2007-04-20 11:56:48 -0400, Mark Tarver <··········@ukonline.co.uk> said:
> With
> Allegro, CMU and CLisp pegged the next candidates are SBCL and
> Lispworks.
This is good news for me since these are the two implementations I use
most. I'm also pretty certain that a fair number of lispers are in the
same boat.
Best of luck with Qi.
On 21 Apr, 05:29, Raffael Cavallaro <················@pas-d'espam-s'il-
vous-plait-mac.com> wrote:
> On 2007-04-20 11:56:48 -0400, Mark Tarver <··········@ukonline.co.uk> said:
>
> > With
> > Allegro, CMU and CLisp pegged the next candidates are SBCL and
> > Lispworks.
>
> This is good news for me since these are the two implementations I use
> most. I'm also pretty certain that a fair number of lispers are in the
> same boat.
>
> Best of luck with Qi.
Hi,
Thanks - Xmas may have come early for you because it looks as if
someone on Qilang
has got a successful port of Qi to SBCL.
Mark