Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Elias Mårtenson]

First of all, I'm a newcomer to APL and even though I've hit 40 I feel
somewhat like the new kid on the block. :-)

I haven't advocated plenty of new quad-commands or changes to the core
language (although there are certainly a few of those that I'd like to see
too, but I respect Jürgens wishes and vision for the project).

The native function interface was designed in order to be able to implement
libraries that go beyond what the core APL language allows (file management
is an obvious one, the SQL support being another, and the Emacs mode also
needed to be able to communicate directly with the core interpreter through
a back-channel which required yet another native library).

The benefit of the native libraries is that they are standalone and can be
developed my anyone and they don't need to be delivered as part of the GNU
APL distribution. My SQL library is a good example of this as it's
completely separate (that said, if Jürgen is willing, I'm happy to see it
included in the core).

All of the libraries that I suggested integration with would be implemented
in a similar manner. It is no more an extension to GNU APL than libxml is
an extension to C. It's just a library that happens to be implemented on
top of a platform.

Like it or not, in order to be able to effectively use the tool (and even,
dare I say it, attract some new user?) there needs to be an easy way to
interact with the rest of the world. The world uses things like JSON, XML,
spreadsheets and graphical monitors (notice the correlation with my list in
the previous mail? :-) ).

Another community that I'm involved in is that of Common Lisp. This
community have some similarities to APL in the sense that it's an old
language (older than APL in fact) whose community is fairly small. In the
last few years, Common Lisp has experienced a resurgence of sorts with new
developers starting to use the language. It's nowhere near the size of the
Ruby community for example, but it's large enough to be viable right now.

Arguably the biggest contributor to the resurgence of Common Lisp was the
Quicklisp  project which is a library manager
that allows a developer to use a single command to download a library that
provides some functionality, and it will be automatically installed along
with any dependencies it may have. It can also update all libraries to the
latest version using a single command. This project alone transformed what
was an incredibly painful process requiring the developer to first identify
what library he actually needed (there was no central repository) and then
download it along with all dependencies and then attempting to get all of
those running on his Common Lisp implementation of choice.

With Quicklisp, the process of installing, say, the XML library (called
"cxml") was now reduced to typing (ql:quickload "cxml"). Just imagine the
difference this makes to a newcomer.

This is what I would like to see for GNU APL. We obviously can't match
Common Lisp in the breadth of libraries but we can at least make it easy to
access the available functionality to "do stuff".

Ideally, I'd like to be able to type something similar to )COPY XXX where
*XXX* is some library name, and everything would be loaded automatically
(both APL code and the native code).

Regards,
Elias

On 23 April 2014 08:06, Peter Teeson  wrote:

> David's is a thoughtful email which which we should consider without
> prejudice.
> The ISO standard makes clear, in chapter 4, what it means to be compliant.
>
> When I worked at IPSA Ken Iverson's office was just a couple away from
> mine.
> He was very thoughtful of what should be added/extended to the language
> and the QUAD's.
> At the time we were adding shared variables, fairly new at that time and
> long before APL2.
>
> IPSA APL had a component file system, BSS, initially written by Larry
> Breed.
> Because it was essential, it was integrated into IPSA APL and we had a set
> of Quad functions to use it.
> I cannot recall now but I'm pretty sure they were not part of the APL/360
> manual.
>
> When we were exploring new capabilities we used to model them in APL first
> and there were
> special privileges, really restricted to only some zoo members, to be able
> to run them.
> Later on they might be written in Assembly, which was the implementation
> language used at that time.
>
> Because I'm old now  I suggest that we
> err on the side of caution.
> Because the present GNU APL is the best thing that has come along in
> years, it would be a pity to
> burden it with the sort of feature creep that has happened to far to many
> pieces of SW. Much ado about nothing.
>
> Perhaps the place for the experimenting with these sort of things is in a
> branch, not the trunk.
> And like fine wine let them ferment and mature in order to get the full
> flavour and benefit.
> (Which reminds me time to pour a glass of red cab/sauv)
>
> If I have misunderstood the gist of the various proposals then feel free
> to

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Peter Teeson]

Blake said:
> "This means creating a quad function to load, execute, and interface with 
> shared libraries (so/dll/etc).  
>   It also means standard ways of communicating data back and forth"
clap clap clap. +1.

That's basically the idea of what we did at IPSA. 
As for the file system it was built separately but interfaced with the 
interpreter through the same idea. 
I could in fact ask one of my former colleagues with whom I'm still in touch as 
he was the maintainer.

And I think GNU APL is a great gift and Jürgen's herculean effort to bring us 
this far is beyond compare.

respect…

Peter

Re: [Bug-apl] apl-cf (Component Files for GNU APL) on Github

[Blake McBride]

Thanks!  Really appreciate it!

--blake


On Tue, Apr 22, 2014 at 6:53 PM, David B. Lamkins wrote:

> I've pushed apl-cf to Github.
>
> The only change (since the last tarball posted to bug-apl) is the
> addition of a README.md file.
>
> https://github.com/TieDyedDevil/apl-cf
>
>
>
>
>

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Blake McBride]

Greetings,

Your email sparked many thoughts.  Not that my opinion necessarily counts
for anything, I think this should be GNU APL's priority list:

1.  Fix all known bugs and portability issues as they are discovered.

2.  Support all of APL's standard defined features (i.e. trace, stop, etc.)

3.  Create a generic mechanism whereby APL can be arbitrarily extended
without re-compiling its source.  This means creating a quad function to
load, execute, and interface with shared libraries (so/dll/etc).  It also
means standard ways of communicating data back and forth.  Doing it this
way, all extensions can/should be done via shared libraries and APL glue
code.  This way modules (shared libraries & APL glue code) can be added for
component or keyed file systems, GUI libraries, Regex, XML, etc..  The APL
source would have to be enhanced a bunch of times to increase the
generality of its interface to the external object.  This would occur as
limitations or inconsistencies are discovered.  After a time, this
interface will stabilize.  I know GNU APL already has this, I just think it
needs to mature - and it will as we hit the interface with a greater
variety of needs.

Just thinking out loud for a moment, perhaps a GNU APL developer library
can be built that the shared objects can utilize.  It would provide
functions to translate APL objects to and from C/C++ objects and other
functionality that would make it easier to write the extension modules.


You state:  "The obvious question is: Why would we want another open-source
APL?"

Another?  There are only two other open-source APL system worth even
mentioning:  NARS2000 & OpenAPL.

NARS2000, while good, suffers from two problems.  First it is
(unfortunately and unnecessarily) bound to Windows.  The second problem is
that it has insufficient persistence capabilities - only the rawest.
 Already GNU APL puts it to shame.

OpenAPL is an old hack that was whipped together in a short time and never
really worked.

IMO, GNU APL is a thing of beauty.  It's available in source, it's close to
complete, it's portable, it is well supported by the author and the
community.  And, with all the off-putting, insulting communities out there,
the GNU APL community is fantastic!  I have waited 30 years for something
like this, and I like and appreciate it!

So, I think there is nothing like GNU APL.  It is a gift.  As the generic
interface is enhanced, and more modules are built, this could become
extremely powerful.  In fact, I think GNU APL can surpass the APL vendors
easily.  Given source access opens up the system to many, many developers.
 Just think about Linux.  The stability and efficiency of Linux far
surpasses that of Windows and even Mac OS/X.

With respect to the compiler bit, APL has always stressed the use of array
processing rather than loops.  APL is at a good place with respect to the
increase of multi-processors.  The value of a compiler decreases as one
increasingly does thing in an APL/array oriented way.  The interpreter
orientation of most APL's enables much or APL's development conveniences,
appeal, and productivity.  I think an APL compiler is the subject of a
different project.

Just some thoughts.  Thanks.

Blake



On Tue, Apr 22, 2014 at 4:10 PM, David B. Lamkins wrote:

> Just for the sake of discussion, and not because I specifically object
> to any of the proposed library bindings: It'd be nice to see some
> motivation for mapping new libraries into/onto APL.
>
> I know that Dyalog APL has all of the features proposed by Elias (and
> more). I don't, however, assign much weight to the "keeping up with the
> Jones'" argument. There's already a solution (Dyalog) for programmers
> who need some combination of those features. (Granted, Dyalog is not
> free. On the other hand, they've invested many hundreds of person years
> of programmer effort into their product.)
>
> As a long-time student of APL, I try to be sensitive to the thinking
> that served as the foundation of the APL design. The history of APL
> tells us that the designers tried to be careful about considering how
> new features would fit into the language.
>
> With the commercialization of APL, IBM's competitors strove to
> differentiate themselves by introducing new features which were mutually
> incompatible, leading to vendor lock-in and fragmentation of the
> market.
>
> Given that GNU APL hews to an established standard, there's a chance for
> other development teams to introduce comparable products. Having a
> common language (something that the surviving commercial APL vendors
> don't have) is, I think, a competitive benefit.
>
> The obvious question is: Why would we want another open-source APL?
>
> GNU APL is (modulo the occasional bug) a capable and nearly-complete
> implementation of IBM/ISO APL. That's good news.
>
> On the other hand GNU APL is (by design) an interpreted language, with
> all that implies. There's going to be an upper-bound on performance
> based upon not having a 

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Peter Teeson]

David's is a thoughtful email which which we should consider without prejudice.
The ISO standard makes clear, in chapter 4, what it means to be compliant.

When I worked at IPSA Ken Iverson's office was just a couple away from mine.
He was very thoughtful of what should be added/extended to the language and the 
QUAD's.
At the time we were adding shared variables, fairly new at that time and long 
before APL2.

IPSA APL had a component file system, BSS, initially written by Larry Breed.
Because it was essential, it was integrated into IPSA APL and we had a set of 
Quad functions to use it.
I cannot recall now but I'm pretty sure they were not part of the APL/360 
manual.

When we were exploring new capabilities we used to model them in APL first and 
there were
special privileges, really restricted to only some zoo members, to be able to 
run them. 
Later on they might be written in Assembly, which was the implementation 
language used at that time.

Because I'm old now  I suggest that we err on 
the side of caution.
Because the present GNU APL is the best thing that has come along in years, it 
would be a pity to
burden it with the sort of feature creep that has happened to far to many 
pieces of SW. Much ado about nothing.

Perhaps the place for the experimenting with these sort of things is in a 
branch, not the trunk.
And like fine wine let them ferment and mature in order to get the full flavour 
and benefit.
(Which reminds me time to pour a glass of red cab/sauv)

If I have misunderstood the gist of the various proposals then feel free to 
correct me.

respect…

Peter

[Bug-apl] apl-cf (Component Files for GNU APL) on Github

[David B. Lamkins]

I've pushed apl-cf to Github.

The only change (since the last tarball posted to bug-apl) is the
addition of a README.md file.

https://github.com/TieDyedDevil/apl-cf

[Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[David B. Lamkins]

Just for the sake of discussion, and not because I specifically object
to any of the proposed library bindings: It'd be nice to see some
motivation for mapping new libraries into/onto APL.

I know that Dyalog APL has all of the features proposed by Elias (and
more). I don't, however, assign much weight to the "keeping up with the
Jones'" argument. There's already a solution (Dyalog) for programmers
who need some combination of those features. (Granted, Dyalog is not
free. On the other hand, they've invested many hundreds of person years
of programmer effort into their product.)

As a long-time student of APL, I try to be sensitive to the thinking
that served as the foundation of the APL design. The history of APL
tells us that the designers tried to be careful about considering how
new features would fit into the language.

With the commercialization of APL, IBM's competitors strove to
differentiate themselves by introducing new features which were mutually
incompatible, leading to vendor lock-in and fragmentation of the
market. 

Given that GNU APL hews to an established standard, there's a chance for
other development teams to introduce comparable products. Having a
common language (something that the surviving commercial APL vendors
don't have) is, I think, a competitive benefit.

The obvious question is: Why would we want another open-source APL? 

GNU APL is (modulo the occasional bug) a capable and nearly-complete
implementation of IBM/ISO APL. That's good news.

On the other hand GNU APL is (by design) an interpreted language, with
all that implies. There's going to be an upper-bound on performance
based upon not having a compiler that can take full advantage of the
underlying hardware. While this might not be an issue for many people,
it's not difficult to imagine applications for which a significant
performance boost would be an advantage. 

I can certainly envision that someone may want to branch and rework (or
completely reimplement) GNU APL as a compiler.

To the extent that the current GNU APL community introduces extensions
to the language the work of subsequent maintainers is made that much
more difficult, particularly in the case where the details of an
extension have a temporal nature (i.e. things that are the way they are
due to convention rather than underlying principles).

I'd argue that everything on Elias's list is guided by convention. Data,
document and graphics formats come and go. (APL has been around for 50
years. How many graphics, data interchange and document formats have
come and gone in that period?) Even something as pervasive as regex
needs to be qualified by the question: "which regex?". To my way of
thinking (more on this in the summary) this argues against building
dependencies into the core language for the sake of these features. In
other words: by all means let's build some useful libraries that can be
bound by the existing quad-FX mechanism. But let's think long and hard
before we let support for any of these new libraries require specific
new APIs or datatypes in the core of GNU APL.

Again, I don't mean to shoot down your wish list, Elias. I would,
however, like to initiate a dialog regarding the best way to address
your concerns without introducing "accidental complexity" into the core
of the GNU APL language.

For example, let's talk about graphics.

One of the first questions that comes to mind is this: Even if all you
do is read and write image files, how do you deal with the image data
type in APL? Do you introduce the notion of a blob? Does the blob have
associated metadata? How does the interpreter need to change to deal
with blobs? Alternatively, let's say that we invent a mapping from
images to APL data and back to images. APL, particularly as an
interpreted language, would probably not be most programmers' first
choice as a tool to create or manipulate images. What's the use case
driving APL as an intermediary rather than some other tools designed
specifically to work with images?

I'll stop here because I'm laboring under a lot of assumptions, many of
which may be wrong. Perhaps I'm missing the point entirely.

On the other hand, I have an admitted prejudice against design by
accretion. I believe that a software system design is best served by
careful consideration of how all of the parts interact. It's fairly easy
to add features to software; it's exceedingly difficult to keep software
from suffering bit-rot as a result of feature accumulation.

Again, I think it would help us all to have some concrete examples of
applications that would best be served by any new features / libraries /
extensions.


On Tue, 2014-04-22 at 22:33 +0800, Elias Mårtenson 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:
> net

Re: [Bug-apl] 2 questions wrt editing my programs

[Peter Teeson]

Thanks Jürgen & Elias for your responses. I will explore both approaches. 
In fact I have downloaded Emacs for OS X from  but 
not yet installed it.

As a long time user of BBEdit, a great text editor for Mac, I've also 
downloaded the free TextWrangler app.
It's also from Bare Bones Software and is almost the same as BBEdit except for 
some language specific extras.

If I wanted to try using it as the editor for GNU APL what is the interface I 
need to use or craft?
I guess this is another way of asking how Elias was able to make things work 
with Emacs.

respect….

Peter

[Bug-apl] Fwd: Re: 2 questions wrt editing my programs

[Elias Mårtenson]

I accidentally sent this to Jürgen only. Here it is for the rest of the
list.

Regards,
Elias
-- Forwarded message --
From: "Elias Mårtenson" 
Date: 23 Apr 2014 01:13
Subject: Re: [Bug-apl] 2 questions wrt editing my programs
To: "Jürgen Sauermann" 
Cc:

I must say that that sounds a bit more work than I have. In an attempt to
blow my own horn, let me try to explain how Emacs does it.

I start GNU APL inside Emacs, which opens the interpreter inside a buffer
(a buffer is simply the editor content, but it can also be more like a
terminal. It's text, basically). You can switch between buffers, show
several buffers at the same time, and buffers don't even need to be
displayed, and you can easily switch between them by pressing C-x b (that's
control-x followed by b).

In the APL interaction buffer you can use GNU APL just like you do in a
terminal with a few exceptions: First of all, you have access to the APL
input methods, allowing you to easily type APL symbols. Secondly, if you
press TAB you will get auto-expansion of symbols. There are also some other
features (like a spreadsheet editor for matrixes).

Now, if you open another buffer with a plain APL file and enter a function
definition, you can simply move the cursor to any line in the function and
press C-c C-c. This will send the function definition to the running APL
session (it will be running in the buffer even though it might not be
visible). If an error occurred while sending the function definition, it
will be marked in the buffer. If all works well the function will flash
briefly to show what was sent (I point that out for no other reason than
that I find it cool :-) ).

Now, another neat feature is that you can in any APL buffer (either the one
where the interpreter is running or any text file with APL code) place the
cursor on a symbol and press M-. (that's meta-period, where meta is usually
the Alt key on a PC). This displays the file that contains the definition
of the function and places the cursor on the first line of said function.
This is a very efficient way to navigate to the location of a function
definition.

There are also other features such as integrated documentation, allowing
you to display docs for any APL symbol (this information is displayed in
separate buffers).

Another feature is the "trace" feature that opens a separate buffer
displaying the content of a variable. Whenever the variable changes the
buffer is updated in realtime. This is the same feature that was used in
the game of life demo that Dyalog showed in a Youtube video.

This message is getting long, and I'm typing this on my phone. Perhaps I
should make a Youtube video showing off these features.

Regards,
Elias
On 23 Apr 2014 00:39, "Juergen Sauermann" 
wrote:

> Hi Peter,
>
> the built-in ∇-editor should almost work like "Editor 1" described in the
> IBM language reference
> manual for APL2, chapter 9. When you are scripting GNU APL then you can
> define functions in your
> script like this:
>
> )ERASE AVERAGE
> ∇Z←AVERAGE B
> Z←(+/B)÷⍴B
> ∇
>
> Having that said, this is how I work:
>
> I use multiple xterm windows (for easy cut-and-paste of APL code).
>
> In the 1. window I edit an APL script using vi (!).
>
> In a second window I start that script when I have edited a function to
> see if it works.
>
> Since I am an APL newbie, I have a 3rd window with GNU APL running
> interactively to try out
> small things. In this window I sometimes edit small functions with the
> ∇-editor.
>
> Regarding other ways of importing functions, you could write a small
> function using FILE_IO that
> reads an entire text file (containing one function) and ⎕FX it. There are
> lots of other possibilities,
> e.g.having a makefile instead of window 2 and use ":make from within vi.
> That saves one window.
> The method above works best for me, though.
>
> /// Jürgen
>
>
> On 04/22/2014 12:33 AM, Peter Teeson wrote:
>
>> (1) Where is docn for the built in function editor when running in
>> terminal mode?
>> (I have the IBM manuals - should I be looking there? Also I am not
>> familiar with emacs or vi)
>> (I'm only familiar with the IPSA one)
>>
>> (2) Can I use an external text editor and interface with quad FX?
>>
>> Because I now want to get on with my original intent which is to solve a
>> problem using APL
>> rather than C/C++ since APL is much better suited for that purpose - lots
>> of arrays involved.
>>
>> TIA
>>
>> respect….
>>
>> Peter
>>
>>
>
>

Re: [Bug-apl] 2 questions wrt editing my programs

[Juergen Sauermann]

Hi Peter,

the built-in ∇-editor should almost work like "Editor 1" described in 
the IBM language reference
manual for APL2, chapter 9. When you are scripting GNU APL then you can 
define functions in your

script like this:

)ERASE AVERAGE
∇Z←AVERAGE B
Z←(+/B)÷⍴B
∇

Having that said, this is how I work:

I use multiple xterm windows (for easy cut-and-paste of APL code).

In the 1. window I edit an APL script using vi (!).

In a second window I start that script when I have edited a function to 
see if it works.


Since I am an APL newbie, I have a 3rd window with GNU APL running 
interactively to try out
small things. In this window I sometimes edit small functions with the 
∇-editor.


Regarding other ways of importing functions, you could write a small 
function using FILE_IO that
reads an entire text file (containing one function) and ⎕FX it. There 
are lots of other possibilities,
e.g.having a makefile instead of window 2 and use ":make from within vi. 
That saves one window.

The method above works best for me, though.

/// Jürgen


On 04/22/2014 12:33 AM, Peter Teeson wrote:

(1) Where is docn for the built in function editor when running in terminal 
mode?
(I have the IBM manuals - should I be looking there? Also I am not familiar 
with emacs or vi)
(I'm only familiar with the IPSA one)

(2) Can I use an external text editor and interface with quad FX?

Because I now want to get on with my original intent which is to solve a 
problem using APL
rather than C/C++ since APL is much better suited for that purpose - lots of 
arrays involved.

TIA

respect….

Peter

Re: [Bug-apl] Tk/Tcl interface

[Blake McBride]

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  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  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  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 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  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 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  wrote:
>>
>>> Just an idea.
>>>
>>>
>>
>

>>>
>>
>

Re: [Bug-apl] Tk/Tcl interface

[Elias Mårtenson]

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  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  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 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  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 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  wrote:
>
>> Just an idea.
>>
>>
>

>>>
>>
>

Re: [Bug-apl] Tk/Tcl interface

[Elias Mårtenson]

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

> Just an idea.
>
>

>>>
>>
>

Re: [Bug-apl] Tk/Tcl interface

[Blake McBride]

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  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  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 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  wrote:
>>>
 Just an idea.


>>>
>>
>

Re: [Bug-apl] Tk/Tcl interface

[Elias Mårtenson]

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  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 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  wrote:
>>
>>> Just an idea.
>>>
>>>
>>
>

Re: [Bug-apl] Tk/Tcl interface

[Blake McBride]

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  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  wrote:
>
>> Just an idea.
>>
>>
>