#14636: ECL spkg : dirty workarounds?
--------------------------------------+-------------------------------------
       Reporter:  Snark               |         Owner:  jdemeyer    
           Type:  defect              |        Status:  new         
       Priority:  major               |     Milestone:  sage-pending
      Component:  packages: standard  |    Resolution:              
       Keywords:                      |   Work issues:              
Report Upstream:  N/A                 |     Reviewers:              
        Authors:                      |     Merged in:              
   Dependencies:                      |      Stopgaps:              
--------------------------------------+-------------------------------------

Comment (by nbruin):

 (1) unicode: I suppose there are no fundamental obstacles for that.
 However, you'll have to essentially rewrite the ecllib wrapper. With Py3
 this might become worthwhile, since that has unicode strings internally
 anyway (although undoubtedly stored with an encoding different from
 ecl's). Also, our main use, Maxima, is solidly pre-unicode, so I don't
 think there will be any benefits for us and probably extra problems from
 Maxima possibly getting unexpected data.

 (2) signals: ECL has very complex and ingenious infrastructure to deal
 with signals, and it expects to handle signals itself (which is a bit odd
 for a library). With threads enabled there will be a separate thread for
 asynchronous signals, and Boehm repurposes some exotic signals to sync
 threads on GC events. We cannot afford to submit to ECL's way of handling
 signals, so we do some pretty horrible stuff with signals when starting
 ECL anyway (and every time we call into ECL for longer times!) Disabling
 SIGCHLD is probably the least of your worries. Also, I don't think ECL
 does anything with SIGCHLD events anyway (other than possibly installing
 its own handler to provide a hook for ecl programs and which by default
 ignores the signal)

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14636#comment:4>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to