[ANN] ManKai Common Lisp 1.0.0 (Release Candidate 1)
Jean-Claude Beaudoin
I am pleased to announce the availability of Release Candidate 1 of ManKai Common Lisp 1.0.0 which is the initial public
step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
MKCL is hosted on common-lisp.net at http://common-lisp.net/project/mkcl/.
Here is a copy of its ANNOUNCEMENT file:
===========================================================
Announcement of MKCL version 1.0.0
==================================
This is ManKai Common Lisp (MKCL).
MKCL aims to be a full implementation of the Common Lisp language in
compliance with the ANSI X3J13 Common Lisp standard.
MKCL finds its origin in the source code of the ECL project
and, like ECL, it tries to bring to full maturity the lineage of the
Kyoto Common Lisp (KCL) family but in a modern yet
more contained and better controlled context.
MKCL strives for greater reliability and stability in a quest for
the ease of use that thus result.
MKCL supports the operating systems Linux and Microsoft Windows, running
on top of Intel x86 or AMD64 compatible processors.
MKCL is a multi-threaded only implementation.
Notes for this release
======================
This release is the first one of MKCL, it includes an entirely new
architecture for signal handling that we hope will improve very
significantly the overall robustness of the whole MKCL system.
This release of MKCL improves thread-safety friendliness through:
- thread-safe CLOS metadata.
- light-weight CLOS class redefinition (ie: in a more Flavors-like style)
- load-time evaluation of function names
- closeable generic functions.
===========================================================
Cheers,
Jean-Claude Beaudoin
Bien faire et laisser braire
Spiros Bousbouras
Jean-Claude Beaudoin <jean.claud...@gmail.com> wrote:
>
> I am pleased to announce the availability of Release Candidate 1 of ManKai Common Lisp 1.0.0 which is the initial public
> step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
>
> MKCL is hosted on common-lisp.net at http://common-lisp.net/project/mkcl/.
Where does the name come from ?
[...]
> MKCL finds its origin in the source code of the ECL project
> and, like ECL, it tries to bring to full maturity the lineage of the
> Kyoto Common Lisp (KCL) family but in a modern yet
> more contained and better controlled context.
So what are the differences from ECL in practical terms ?
> MKCL strives for greater reliability and stability in a quest for
> the ease of use that thus result.
Once again this is a bit theoretical. What practical considerations led
the creators to create an ECL fork ? And who are the creators ?
[...]
> MKCL is a multi-threaded only implementation.
What does "multi-threaded only" mean ?
> Notes for this release
> ======================
>
> This release is the first one of MKCL, it includes an entirely new
> architecture for signal handling that we hope will improve very
> significantly the overall robustness of the whole MKCL system.
So there is an older MKCL system ? Is this something that was only used
privately ?
> This release of MKCL improves thread-safety friendliness through:
>
> - thread-safe CLOS metadata.
>
> - light-weight CLOS class redefinition (ie: in a more Flavors-like style)
>
> - load-time evaluation of function names
>
> - closeable generic functions.
It would be useful if the page mentioned the requirements for compiling
like library dependencies for example. I'm sure the information exists in
the downloaded files but it saves time to have it on the web.
--
Should array indices start at 0 or 1 ? My compromise of 0.5 was
rejected without, I thought, proper consideration.
Stan Kelly-Bootle
Juanjo
> On Wed, 20 Oct 2010 07:26:17 -0400
>
>
> > I am pleased to announce the availability of Release Candidate 1 of ManKai Common Lisp 1.0.0 which is the initial public
> > step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
>
> the creators to create an ECL fork ? And who are the creators ?
Indeed this is quite a good question, for Jean-Claude never bothered
to state any discrepancy in the maintenance or design of ECL. He did a
good contribution, in terms of signal handling, but after that he went
silent. Long time after that I read about his multithreaded CLOS
efforts and now this fork is presented. It is not that I feel hurt,
but I am amazed at how much effort is sometimes wasted in new ego
boosting activities instead of contributing to create a collaborative
maintenance structure for existing and successful projects. My best
wishes. Maybe this means I can now stop working on ECL and instead of
struggling to create an community without success, pass the torch to
someone else.
Juanjo
Pascal J. Bourguignon
Not so fast! AFAWK, Jean-Claude is a comunity of 1.
http://common-lisp.net/pipermail/mkcl-devel/ is empty.
--
__Pascal Bourguignon__ http://www.informatimago.com/
D Herring
> MKCL finds its origin in the source code of the ECL project
> and, like ECL, it tries to bring to full maturity the lineage of the
> Kyoto Common Lisp (KCL) family but in a modern yet
> more contained and better controlled context.
So I follow ECL fairly closely and was not conscious of this fork
happening.
Why? I'm curious about the discussions I must have missed.
Did Juanjo reject your patches? Is there some fundamental
incompatibility with his work? Have you considered merging back?
Its good that CL has several competing implementations; but one per
developer is a bit much.
Thanks,
Daniel
D Herring
> and, like ECL, it tries to bring to full maturity the lineage of the
> Kyoto Common Lisp (KCL) family but in a modern yet
> more contained and better controlled context.
So I follow ECL fairly closely and was not conscious of this fork
Spiros Bousbouras
D Herring <dher...@at.tentpost.dot.com> wrote:
>
> Its good that CL has several competing implementations; but one per
> developer is a bit much.
It would be interesting to have for several languages the following
statistics:
#(implementations of the language) / #(applications written in the language)
#(implementations of the language) / #(users of the language)
I suspect that Common Lisp would score rather high , likely 3rd after
Scheme and Forth. And that would be remarkable considering the size of
Common Lisp. Whether a high score is a good thing I don't know.
--
To be or to be cool ? That is the question.
Nils M Holm
> It would be interesting to have for several languages the following
> statistics:
> #(implementations of the language) / #(applications written in the language)
> #(implementations of the language) / #(users of the language)
> I suspect that Common Lisp would score rather high , likely 3rd after
> Scheme and Forth. And that would be remarkable considering the size of
> Common Lisp. Whether a high score is a good thing I don't know.
I would say it's a good thing, because it shows that the language
is fun/interesting to implement. In the case of Forth and Scheme
(which I have both implemented multiple times) one could argue that
it is done so often because it is easy. In the case of CL this
argument definitely falls flat.
--
Nils M Holm | http://t3x.org
Jean-Claude Beaudoin
> On Wed, 20 Oct 2010 07:26:17 -0400
> Jean-Claude Beaudoin <jean.claud...@gmail.com> wrote:
>> MKCL is hosted on common-lisp.net at http://common-lisp.net/project/mkcl/.
>
> Where does the name come from ?
>
ManKai is the romanji spelling of a Japanese expression that translates into "Full Bloom".
It is a reference to the historical origins of the largest bulk of the code
in Kyoto, Japan where the cherry trees go into "Man Kai" every spring.
> So what are the differences from ECL in practical terms ?
>
Grab the source code, compile it and read it. It should be obvious by then.
I am much too busy writing code to go on top of MKCL to elaborate on this...
> And who are the creators ?
>
As stated in the Copyright statement, I, Jean-Claude Beaudoin is the latest
contributor to its code.
>> MKCL is a multi-threaded only implementation.
>
> What does "multi-threaded only" mean ?
>
Multi-thread support is a built-in standard issue in MKCL, it is not an option.
>
> So there is an older MKCL system ? Is this something that was only used
> privately ?
>
MKCL was forked from ECL 9.6.2 and has been developed privately by me since then.
> It would be useful if the page mentioned the requirements for compiling
> like library dependencies for example. I'm sure the information exists in
> the downloaded files but it saves time to have it on the web.
>
That is because there is none beyond what is normal standard issue on any
reasonably recent Linux distribution. Same thing for MS-Windows XP onward
as long as a reasonably recent MinGW is setup to compile the source code.
Tamas K Papp
> Spiros Bousbouras wrote:
>
>> So what are the differences from ECL in practical terms ?
>
> Grab the source code, compile it and read it. It should be obvious by
> then. I am much too busy writing code to go on top of MKCL to elaborate
> on this...
That really says it all. Thanks for providing such a clear signal, I
almost tried MKCL.
Regards,
Tamas
Francogrex
<jean.claude.beaud...@gmail.com> wrote:
> I am pleased to announce the availability of Release Candidate 1 of ManKai Common Lisp 1.0.0 which is the initial public
> step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
>
> MKCL is hosted on common-lisp.net athttp://common-lisp.net/project/mkcl/.
This seems nothing more than ECL re-hacked (and probably butchered
along the way). Please do not try to pass it off as a "new
implementation".
Francogrex
> step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
>
kodifik
> step toward the full 1.0.0 release of ManKai Common Lisp (MKCL).
>
"Cannot find the external symbol PROCESS-RUN-FUNCTION in #<"MP"
package>."
>
> Bien faire et laisser braire
Bien dit.
Jean-Claude Beaudoin
>
> "Cannot find the external symbol PROCESS-RUN-FUNCTION in #<"MP"
> package>."
>
All the mp:process-* functions got renamed to their equivalent mp:thread-*.
If you expect some semi-standard interface in that area I suggest that
you do this:
(require 'bordeaux-threads)
>> Bien faire et laisser braire
>
> Bien dit.
Je persiste et je signe.
Cheers,
Jean-Claude Beaudoin
Madhu
| On Oct 20, 1:26 pm, Jean-Claude Beaudoin
|> I am pleased to announce the availability of Release Candidate 1 of
|> ManKai Common Lisp 1.0.0 which is the initial public step toward the
|> full 1.0.0 release of ManKai Common Lisp (MKCL).
|>
|> MKCL is hosted on common-lisp.net athttp://common-lisp.net/project/mkcl/.
|
| This seems nothing more than ECL re-hacked (and probably butchered
| along the way). Please do not try to pass it off as a "new
| implementation".
You seem to allege that Jean-Claude is passing this off as a "new
implementation."
Nowhere has Jean-Claude tried to pass this off as a "new
implementation", in the 2 messages he has posted so far. You need to
improve on your reading comprehension before launching attacks on
Jean-Claude.
In the parts of the message you snipped out, He says explicitly that it
is based on ECL.
>* Jean-Claude Beaudoin <i9mkcn$l0r$1...@news.eternal-september.org> :
>Wrote on Wed, 20 Oct 2010 07:26:17 -0400:
>
>| MKCL finds its origin in the source code of the ECL project
>| and, like ECL, it tries to bring to full maturity the lineage of the
>| Kyoto Common Lisp (KCL) family but in a modern yet
>| more contained and better controlled context.
And again,
>* Jean-Claude Beaudoin <i9os3t$uv6$1...@news.eternal-september.org> :
>Wrote on Thu, 21 Oct 2010 03:50:12 -0400:
>
>| MKCL was forked from ECL 9.6.2 and has been developed privately by me
>| since then.
In both cases he acknowledges where it is derived from. Do not blame
deficiencies in your own understanding on others.
As to your "probably butchered" aspersion, if you re-read that message
in "Notes for this release", section you can see he states how it
differs from ECL.
--
Madhu
Francogrex
> Nowhere has Jean-Claude tried to pass this off as a "new
> implementation", in the 2 messages he has posted so far. You need to
> improve on your reading comprehension before launching attacks on
> Jean-Claude.
Oh "Jean-Claude", so sorry... Either you are supporting this travesti
or you are sucking him (or both). Either way you suck as much as he
does. On the other hand, we continue supporting the "real" lisp
community in its efforts, despite hacks like yous.
Francogrex
>
> | On Oct 20, 1:26 pm, Jean-Claude Beaudoin
> |> I am pleased to announce the availability of Release Candidate 1 of
> |> ManKai Common Lisp 1.0.0 which is the initial public step toward the
> |> full 1.0.0 release of ManKai Common Lisp (MKCL).
> |>
> |> MKCL is hosted on common-lisp.net athttp://common-lisp.net/project/mkcl/.
> |
> | This seems nothing more than ECL re-hacked (and probably butchered
> | along the way). Please do not try to pass it off as a "new
> | implementation".
>
> You seem to allege that Jean-Claude is passing this off as a "new
> implementation."
>
> Nowhere has Jean-Claude tried to pass this off as a "new
> implementation", in the 2 messages he has posted so far. You need to
> improve on your reading comprehension before launching attacks on
> Jean-Claude.
Oh "Jean-Claude", so sorry... Either you are supporting this travesti
Tim Bradshaw
> Oh "Jean-Claude", so sorry... Either you are supporting this travesti
> or you are sucking him (or both). Either way you suck as much as he
> does. On the other hand, we continue supporting the "real" lisp
> community in its efforts, despite hacks like yous.
It's kind of the point of open-source software that you can fork it if
you want: I don't think there's cause to get all upset when someone
does that. I probably disagree with amost all the design decisions
that went into his work (based on the dicussions on CLL a while ago),
but I think it's a good thing he can take an implementation, fork it,
and play with these options.
Tamas K Papp
I guess that forking used to mean a big thing in the past, and forks
did divide user communities. I think that people get upset by forks
because they associate them with these things.
But nowadays, "forking" a project can be something very trivial, and
just mean that somebody started playing around with the code. Eg with
git, it is one of the convenient mechanism for contributing, you can
fork something by a few clicks, improve it, and then let the
maintanier know (a "pull request"). I think that almost all of my CL
libraries on Github got "forked" this way at some point.
Best,
Tamas
Pascal J. Bourguignon
Indeed. And if there's a problem in forking, it's quickly self
resolving. When Jean Claude will notice that ECL has made progress since
0.9.4, and want to integrate the changes, he'll realize that it might be
worth the pain to have his patches integrated into ECL instead.
Anton Vodonosov
radical to be integrated into original ECL, or it's too many efforts
to integrate them or what?