GSoC status report

A good portion of "community bonding time" is already over, so I guess it's
a good time for a new status report, along with some new questions :)

I start with the "heavy" questions:

Jörg wrote:
> I'm not saying that the bugs in the bug tracker don't need prioritization
> as a general matter.

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".)

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
* dynamic modules
* unicode
* readline
* threads (POSIX, WIN32, SOLARIS?)
* jitc (lightning)

Then, CLISP can also be build without libsigsegv. What configurations are the
most interesting ones?

Jörg Höhle wrote:
> This would p.o. lots of people, but you could consider building clisp
> without FFI, that's quite a task already. Please discuss priorities with
> your mentor.

AFAIK the FFI is a pretty important piece of CLISP, so I guess it should
"stay", right? (It's - according to the self tests - working, at least on linux)
Btw: Are there any known "out of tree" modules for CLISP?

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

What about "64bit support"? (I'd consider that important, but it's currently
"broken" in the sense that it doesn't get configured even when the target
would support it.)


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.

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.
 * linux, ./configure, (defaults) with gc checker: builds, passes tests
 except ffi 64 bit (HAVE_LONG_LONG seems to be undefined for whatever reason).
 Same without gc checker.
 * linux, ./configure (tried a minimum config): builds, tests segfault when
 trying to run a socket server, possibly due to a corrupted error message.
 * windows, ./configure (FFI: no, readline: no, sigsegv: NO): builds 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).

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)

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).


Sam wrote:
> I don't want you to lose focus.

That's something I'm also concerned of, so I'm paying extra attention to not
digress. If you notice me losing time on something that's not critical for
the release, then just tell me :)

------------------------------------------------------------------------------
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