I haven't decided what to do yet. I'd like to have some input from others as to what's the best naming style is. All-lowercase? Upper and lower like the SQL mode now? camelCase?
Regards, Elias On 8 May 2014 11:16, Blake McBride <blake1...@gmail.com> wrote: > Any luck on getting the SQL library up-to-date? (I'd like to start work > on the keyed file system, but I am waiting on this fix.) > > Thanks! > > Blake > > > On Sun, May 4, 2014 at 2:12 AM, Elias Mårtenson <loke...@gmail.com> wrote: > >> The SQL library needs to be changed to support the new API. I will fix >> this soon (within a day or so). >> >> I'm also thinking of renaming the functions, making them all lower case. >> This is something that seems more popular. >> >> Regards, >> Elias >> >> >> On 4 May 2014 07:19, Blake McBride <blake1...@gmail.com> wrote: >> >>> Greetings, >>> >>> I updated GNU APL & Emacs mode and it does appear to work now. Thanks a >>> lot! I think I understand the issue but it leads me to the following >>> question. When loading other libraries (such as sqlite, component file >>> system, etc.) the same issue would arise. What happens if you open the >>> shared library and then do a )load? Although a )load should wipe out any >>> APL functions, I wouldn't expect it to unload shared libraries. I would >>> think shared libraries would represent something at a higher level than a >>> workspace. It sounds like you fixed this for Emacs mode. Two questions: >>> >>> Does this fix the problem for the other shared libraries I mentioned? >>> >>> Is there something those shared library authors need to change? >>> >>> Thanks!! >>> >>> Blake >>> >>> >>> >>> On Sat, May 3, 2014 at 12:33 PM, Juergen Sauermann < >>> juergen.sauerm...@t-online.de> wrote: >>> >>>> Hi, >>>> >>>> changed in SVN 243. I also added the caller argument in close_fun() and >>>> in the eval_XXX() functions. >>>> Maybe you want to update back. >>>> >>>> /// Jürgen >>>> >>>> >>>> >>>> On 05/03/2014 06:48 PM, Elias Mårtenson wrote: >>>> >>>> close_fun in emacs_mode is still declared to return void. >>>> >>>> I've changed the declaration in my development branch. Ideally you >>>> could pick up the updated version. >>>> >>>> >>>> https://github.com/lokedhs/gnu-apl-mode/blob/master/native/emacs.cc#L126 >>>> >>>> Regards, >>>> Elias >>>> >>>> >>>> On 4 May 2014 00:41, Juergen Sauermann >>>> <juergen.sauerm...@t-online.de>wrote: >>>> >>>>> Hi, >>>>> >>>>> OK. I have changed the code so that dlclose() is only performed if >>>>> close_fun() exists and returns true when called. The declaration >>>>> of close_fun() was changed accordingly. >>>>> >>>>> Blake, can you please check if this works? SVN 242. >>>>> >>>>> /// Jürgen >>>>> >>>>> >>>>> >>>>> On 05/03/2014 05:44 PM, Elias Mårtenson wrote: >>>>> >>>>> I definitely don't want that. The Emacs library can only be loaded >>>>> once, and it can't be unloaded. It has backend threads working. >>>>> >>>>> This relates back to the previous discussion we had on the >>>>> feasibility unloading libraries and )CLEAR'ing native functions. >>>>> >>>>> A native library (at least the Emacs one :-) ) needs a way to >>>>> protect itself from unloading. >>>>> >>>>> Still, )ERASE needs to work, since one obviously needs to be able to >>>>> run it from within Emacs. >>>>> >>>>> Regards, >>>>> Elias >>>>> >>>>> >>>>> On 3 May 2014 23:41, Juergen Sauermann >>>>> <juergen.sauerm...@t-online.de>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> maybe a native function is erased? You can turn >>>>>> UserFunction__enter_leave on to see if that happens. >>>>>> You should also get a callback on close_fun() if you have set it. >>>>>> >>>>>> The )LOAD command in Blake's example does a )CLEAR first which then >>>>>> )ERASE all variables and functions (including native functions). I >>>>>> could >>>>>> reset all callbacks on )CLEAR, but that may kind of disconnect emacs >>>>>> from >>>>>> the interpreter. Not sure if you want that. I would also say that the >>>>>> entity >>>>>> that registers a callback should also clear it. >>>>>> >>>>>> BTW: If have improved the ]OWNERS display so that sub-values of a >>>>>> variable V, >>>>>> which were incorrectly displayed as having no owner, now show the >>>>>> variable >>>>>> that contains them. SVN 241. >>>>>> >>>>>> /// Jürgen >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >
