Great ideas. I've been spending a bunch of time trying to correct my Unicomp keyboard mapping with xkbcomp. There is clearly a limit to my intelligence, and xkbcomp is it! It is easy to correct key assignments, but I haven't yet figured out how to setup mappings for RAlt+Control (the Unicomp keyboard has 5 characters on some keys). I spent a bunch of hours on it yesterday with no luck. I've now joined the x.org email list. I will try to get help there. (Please let me know if you know anyone who can help. More document references won't be helpful.)
It is cumbersome using APL without a correct keyboard. Fixing the mapping will help me a lot. I'll be able to move on. If no one writes a keyed file system by then, I'll do it. Incidentally, I've only had very minor use of sqlite in the past. The interface created for APL has encouraged my to look a little deeper at sqlite. It is more interesting than I thought... Thanks. Blake On Tue, Apr 22, 2014 at 9:33 AM, Elias Mårtenson <loke...@gmail.com> wrote: > Oh, and a few other libraries I feel would be useful to have wrappers > around include: > > - Regex: > http://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html > - JSON > - XML > - Images loading and saving (libpng for example, or even easier: > netpbm) > - Ability to directly load spreadsheet files? (LibreOffice and Excel). > I suppose one could easily go through CSV though. > > There are plenty of others, but those are the ones I have missed. > Especially Regex would be incredibly helpful when reading texual input and > you want to get it into some kind of array-based format for APL processing. > > Regards, > Elias > > > On 22 April 2014 22:25, Elias Mårtenson <loke...@gmail.com> wrote: > >> You want to implement it? >> >> I'm thinking that a wrapper around libcurl would be very useful as well. >> I know it can be implemented on top of socket primitives, but there is a >> lot of intelligence in libcurl that would be painful to reimplement. >> >> http://curl.haxx.se/libcurl/c/ >> >> Regards, >> Elias >> >> >> On 22 April 2014 22:23, Blake McBride <blake1...@gmail.com> wrote: >> >>> I strongly agree. Also, sockets will give us better direct access to >>> Web technology (i.e. web services). >>> >>> Thanks. >>> >>> Blake >>> >>> >>> On Tue, Apr 22, 2014 at 9:18 AM, Elias Mårtenson <loke...@gmail.com>wrote: >>> >>>> I'd love to add trace (step) functionality to the Emacs mode, if the >>>> underlying functionality is available. Jürgen? >>>> >>>> A native library for sockets is an obvious feature to add. It should be >>>> rather trivial to do so. >>>> >>>> GUI interface is, in fact, less important in my opinion. These days >>>> most people do GUI's using web technologies anyway. >>>> >>>> Regards, >>>> Elias >>>> >>>> >>>> On 22 April 2014 22:12, Blake McBride <blake1...@gmail.com> wrote: >>>> >>>>> I know the history of J, and I agree with what they did. I also fully >>>>> agree with your observations regarding Tk. GTK+ is a far better choice >>>>> than Tk. There is one important difference though. Integrating GTK+ is a >>>>> huge job! Integrating Tk is much easier. Bang for the buck, Tk is a good >>>>> first pass at enabling a GUI interface of some sort. >>>>> >>>>> The work done on APL's file systems and code cleanups are far more >>>>> important to me. I just think that adding sockets and a GUI interface at >>>>> some point would present GNU APL as a total solution. Having said all >>>>> that, however, I certainly think the present course of tightening up the >>>>> code, adding more standard APL facilities (trace, stop, etc.), and a file >>>>> system are top priority. I am just bring up some of theses ideas. >>>>> >>>>> Thanks! >>>>> >>>>> Blake >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 21, 2014 at 9:52 PM, Elias Mårtenson <loke...@gmail.com>wrote: >>>>> >>>>>> The J community seems to be pretty excited about their QT interface. >>>>>> Tk is easy to use, but results in horrible-looking applications that >>>>>> doesn't integrate well with the rest of the interface. >>>>>> >>>>>> If I were to implement support for a GUI framework, it'd be either >>>>>> GTK+ or Android, depending on whether I wanted to target desktops or >>>>>> mobile >>>>>> devices. >>>>>> >>>>>> That said, I have no intention to do either so my opinions on this >>>>>> matters approximately this much: ⍬ >>>>>> >>>>>> Do you have plans to implement this Tk support? If so, I will applaud >>>>>> your efforts and my preferences for other frameworks will not stop me >>>>>> from >>>>>> helping if I can. >>>>>> >>>>>> Regards, >>>>>> Elias >>>>>> >>>>>> >>>>>> On 22 April 2014 09:30, Blake McBride <blake1...@gmail.com> wrote: >>>>>> >>>>>>> Just an idea. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
