[gambit-list] Gambit version for medical apps?

Marc Feeley feeley at iro.umontreal.ca
Tue Jul 5 08:56:47 EDT 2016


I guess the best approach would be to create a “v4.7.0-lts” branch in the Gambit git repo.  Then any fixes to issues that are discovered could be added to that branch specifically.  However, nothing that adds functionality would be added to an “lts” branch as this might break existing functionality.

As development of the master branch progresses, a newer release of Gambit that is stable could be identified and a new “lts” branch could be created.  This would happen every 2 years or so, similarly to Ubuntu.

Due to the overhead of doing this, I would appreciate if someone stepped forward to oversee the management of this process.  Matthias, would you be willing to do this?

Marc


> On Jul 4, 2016, at 9:11 PM, Gorges, Matthias <MGorges at cw.bc.ca> wrote:
> 
> Hi Brad,
>> Whether any of this happens depends entirely on Marc.
> Yes, it is a scary thought that we develop mission critical software using a library with a very low bus factor (https://en.wikipedia.org/wiki/Bus_factor). If Gambit wouldn't work as beautifully as it does, we could consider switching LambdaNative's underlying Scheme compiler (ChezScheme?).
> 
>> I might suggest, though, that a specific, relatively recent version
>> of Gambit be nominated for "long term support" and that problems 
>> from all platforms be reported against that *one* version.
> That sounds like a good plan - maybe 4.7.2 with a few patches to make arm64 work?
> 
>> If I understand correctly, you're currently using different 
>> versions on different platforms because of bugs and workarounds
>> on those different platforms for different versions of Gambit.
> Correct - we mainly use 4.7.0 and 4.7.2 internally, which are both from before the big refactoring towards multiple output language support. After 4.7.3 there are some freezing (and segfault) issues in Android when using usb-serial devices. The 4.7.0 reason is that the last time we tried to upgrade to 4.7.9 our team wasted about a month trying to pin down a fatal crash, which was eliminated by rolling back to the older libgambc version. Two Android crash examples below:
> 
> Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys'
> pid: 6106, tid: 6119, name: Thread-128  >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3ff00028 
> Stack frame #00  pc 0070c678  /data/app-lib/org.ecemgroup.clip-1/libpayloadshared.so: Routine heartbeat_interrupt_handler at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/os_time.c:971
> Stack frame #01  pc 000004fc  [vectors]
> 
> Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys'
> pid: 25772, tid: 25855, name: Thread-238  >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 
> Stack frame #00  pc 00000000  <unknown> 
> Stack frame #01  pc 00713004  /data/app-lib/org.ecemgroup.clip-2/libpayloadshared.so (___raise_interrupt_vmstate+40): Routine ___raise_interrupt_vmstate at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/setup.c:98
> 
> 
> Thanks Matthias
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list