Re: GSoC status report

> * Daniel Jour <[email protected]> [2016-05-10 02:27:03 +0200]:
>
> Sam wrote:
>> There are so many such bugs in CLISP that Daniel will be able to spend
>> the whole summer on them.
>> Fixing them requires an effort: investigating when they were introduced,
>> testing the fix, &c &c.
>> This is important work, but it is out of the project's scope.
>
> The "main goal" is getting a release done. For that CLISP should build and
> pass its self tests on the "supported platforms" (linux, bsd, windows - more
> is better), right?
>
> Do we have any bugs in the bug tracker that must be considered
> "release critical",
> that is there cannot be a release without them being fixed? (I'm trying to
> build a list of things "to do".)

Probably none.

> Sam wrote:
>> Daniel has a huge task ahead of him:
>>
>> He has 6 weeks until June 20, 2016 (Mid-Term Evaluation) to pass
>> the first hurdle: build CLISP on
>> 1. linux (one flavor),
>> 2. bsd (one flavor),
>> 3. windows (mingw?).
>
> I think we should also define "build" a bit better, since CLISP can be build
> in quite a few different configurations. Of the top of my head there's
>
> * ffcall

yes, this is mission-critical for many users.

> * dynamic modules

yes, this is mission-critical for many users.

> * unicode

yes, this is extremely useful.

> * readline

yes, this is not hard to get working and it is useful.

> * threads (POSIX, WIN32, SOLARIS?)

no, this is still "experimental" (IOW, causes segfaults under known
conditions).

> * jitc (lightning)

no, I don't think this ever became "usable"

> Then, CLISP can also be build without libsigsegv.

libsigsegv is required for Generational GC.
it's an absolute must have.
the reason --ignore-absence-of-libsigsegv is even there is for initial
porting work. any serious use of clisp requires libsigsegv.

> Btw: Are there any known "out of tree" modules for CLISP?

Fred and Don Cohens might have some, but let's not worry about these for
now.

> Regarding configurations: What about the different garbage collectors / object
> representations? (TYPECODES vs HEAPCODES)

I would leave this to configure, except for ...

> What about "64bit support"?

... Fixnums must be 48 bits on any 64-bit architecture.

> Next, a short status report:
> Apart from reading further through the code I've now setup everything I need
> to build on linux, netbsd (freebsd comming, too) and windows (10 with mingw).
> All of these are running on amd64, I plan to add x86 VMs soon.

sounds good.

> I also tried to build CLISP on these platforms, naturally. The results:
>
>  * netbsd, ./configure, (FFI: no, readline: no, sigsegv: yes): build fails
>  due to an issue with mmap, though this seems to be "fixed" downstream by
>  disabling mmap support.

disabling mmap is fine.
FFI is not so much, but this is a lower priority platform.

BTW, please take a look at clisp/unix/PLATFORMS and clisp/unix/INSTALL.

>  * linux, ./configure, (defaults) with gc checker: builds, passes
>  tests except ffi 64 bit (HAVE_LONG_LONG seems to be undefined for

not too good, but I sure we can figure this out eventually.

>  whatever reason).  Same without gc checker.

Cool.

>  * linux, ./configure (tried a minimum config): builds, tests segfault
>  when trying to run a socket server, possibly due to a corrupted error
>  message.

I am confused: how is this different from above?

>  * windows, ./configure (FFI: no, readline: no, sigsegv: NO): builds

sigsegv - must have.

>  with some minor manual intervention (path handling issues), passes
>  tests except path handling (though this might be related to MinGW,
>  not sure if this is really a bug) and a socket failure (though this
>  could be caused by the firewall going off during the test).

fine.

> In general, the configure / build "system" seems to be a bit (emergency)
> patched. Some parts are "handwritten" ... why not use (all of) autotools?
> (this would also allow easy integration with libtool, btw)

this has been on the TODO list for a long time ...

> Sam wrote:
>> If he cannot build CLISP on Windows in 6 week, this is what will happen.
>
> I know that this is currently rather vague, but too me it doesn't look
> too bad atm, most of CLISP seems to work (though thinking of some of
> the scarier parts of the code this really surprises me :D This code
> really "evolved/grew" over time ... it's funny that some of it is
> older than me).

You did not even scratch the surface, sorry.

The real problem is, as I said before, with gnulib files in modules.

You need to build at least the following modules:
base (i18n, regexp, syscalls, readline)
full (rawsock, bindings, asdf, pcre, new-clx)
all others for which you can _easily_ get the back end (berkeley-db,
fastcgi, gdbm, libsvm, pari, postgresql, zlib)

Many modules come with their own test suites which can be run with "make
mod-check", and I bet rawsock will fail on windows spectacularly.

You will have to update CLISP with 6 years worth of gnulib updates, and
also figure out how to make it work on windows.
This is the meat of the project.
This is what the midterm eval will hinge on.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000
http://www.childpsy.net/ http://jihadwatch.org http://iris.org.il
http://thereligionofpeace.com http://camera.org http://americancensorship.org
Conscience is like a hamster: it is either asleep or gnawing.

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel