[mkcl-devel] Native compilation on Windows

[Jean-Claude Beaudoin]

On Mon, Nov 5, 2012 at 4:54 AM, Ralph Möritz <ralph.moeritz at outlook.com>wrote:

> Thanks Jean-Claude,
>
> apoligies for top posting.


I don't make a fuss about it but I think that those that do have somewhat
of a point...


> MKCL 1.1.1 tested & working on my machine (Win7 x64).


Thanks.


> WRT ucd.dat would you mind elaborating on that? If it's legacy stuff that
> isn't really necessary anymore then how could one go about removing it?
> (The fewer runtime dependencies the better!)
>

Yes, the fewer the better.

In file "ucd.dat", ucd stands for Unicode Character Database. The content
of ucd.dat
is a derivative of file UnicodeData.txt published by the Unicode Consortium
that is produces by a utility
program that can be found in MKCL's contrib/unicode directory. File ucd.dat
once loaded provides the basic
attributes of each Unicode character, like uppercase, lowercase, alpha or
digit...

File ucd.dat was inherited by MKCL from ECL 9.6.2 when MKCL was forked from
it.  Its existence as a
separate external file is basically a bad idea (wrong point in the memory
versus time design space).
ECL recognized this lately and moved away from it in ECL 12.7.1. Therefore
I consider the existence
of ucd.dat as a legacy bug that needs to be fixed and I will include that
fix in MKCL 1.1.2.

That fix will have the nice property of making sure that mkcl_boot() will
no longer blow up if
it cannot access MKCL's loadable modules directory as it does now on
ucd.dat.
Module loading may still require setting MKCL_LIBDIR in some configurations
but at least
failure on #'load (or #'require) will not happen during the boot process
and could then be
handled through usual condition handling in user code.

As to "how could one go about removing it?",  well it is the usual Read The
Source Code
(or Use The Source, Luke :-) and have fun watching all the arbitrary,
undocumented
magic numbers embedded in there...  It is basically a pain, but if you want
to share that
pain I'll be glad to accommodate you.

Cheers,

Jean-Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mkcl-devel/attachments/20121106/6c6f9040/attachment.html>