Re: [Jprogramming] Unbox request for requests

[Thomas Costigliola]

The drawback of having a separate library is that all of the utilities 
for working with J arrays are not available, unless you call back 
dynamically to the limited API exposed from the J library, which is 
clunky. Or was it implied that you statically link the add-on library 
with J?

Another issue that has bothered me is that the package manager cannot 
guarantee that the latest version of all the add-ons are consistent with 
each other, i.e., two packages that both depend on package X may not 
work with the current latest version of X and there is no way to go back 
to the previous version of X (is there?) or have multiple versions 
installed.

I've been toying with the idea of a plug-in system where J would read a 
directory of shared libraries which would provide foreign conjunctions. 
The build system would take care of linking to the J functions if 
necessary and they would be distributed as part of the release to ensure 
compatibility with the engine. Unlike add-ons, plug-ins would be for 
utilities that don't use J scripts. This would allow people to 
contribute "native" extensions without having to touch the J sources.

On 03/10/2016 11:02 AM, Marshall Lochbaum wrote:
For CSV/JSON loading and storing, I think the best approach would be to
write C functions that convert these formats to and from J nouns. A J
noun is the type A from jtype.h (line 41), and you can use that header
or pieces of it directly. Then just call the shared library from J. This
could be added to the package manager (see Lapack for an example of a J
library that ships with C libraries).

Jd does something similar for CSVs, although the J side consists of one
memory-mapped file per column rather than a J noun.

I'm planning on writing some better documentation for the J source at
some point, and one of the things I will address is how to manipulate J
objects in C.

Marshall

On Thu, Mar 10, 2016 at 09:46:20AM -0600, John Baker wrote:
Two remarks:

1) If you opt for optimized CSV loading consider supporting two load modes.
One the standard table representation and the other the inverted column
representation. If the code can scale to many millions of rows quickly it
would be very handy and better than anything you are likely to achieve with
J code.

2) As for JSON.  Again simple converters are easily the hard part is when
JSON complexity is high and data volumes get large.

It's good to see people experimenting with forks.

Cheers

On Thu, Mar 10, 2016 at 9:35 AM, Thomas Costigliola <fo...@iocane.net>
wrote:


Great list Joe, I'll respond to each below...
On Mar 9, 2016 7:26 AM, Joe Bogner <joebog...@gmail.com> wrote:
Some wishlist ideas (some are likely controversial):

1. Optimized CSV/TSV loading and writing
I think some people like to keep the core language small and use the
standard library and addons for higher level tools. However, this is so
useful and prevalent in J that I think its a good fit and will help to
modernize and grow the language. Can you provide some details on how you
think built in support should work?

2. JSON support
Same as above.

3. Parallel processing (big topic, but maybe something bite-sized for
now - just to show some progress)
I had the idea to use the c11 thread primitives to add asynchronous
operations. This will most likely be the next big project.

4. Sockets built-in (comparing to k/kona's simple way of retrieving
web data or ipc)
This is the same as 1 and 2 for me. I'd like to hear some ideas on how the
interface should be designed.

5. More interop: .NET/Java
I have no personal interest in those specifically, but contributions are
always welcome.
And then maybe a bit more tactical:
1. Method of getting memory address of current J instance:
http://www.jsoftware.com/pipermail/source/2014-May/000581.html
2. Method of cleaning up instance memory on linux:
http://www.jsoftware.com/pipermail/source/2015-February/000663.html
Very useful, I'll implement these soon.


-------- Original message --------
From: Joe Bogner <joebog...@gmail.com>
Date: 3/9/2016  7:26 AM  (GMT-05:00)
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] Unbox request for requests

Some wishlist ideas (some are likely controversial):

1. Optimized CSV/TSV loading and writing
2. JSON support
3. Parallel processing (big topic, but maybe something bite-sized for
now - just to show some progress)
4. Sockets built-in (comparing to k/kona's simple way of retrieving
web data or ipc)
5. More interop: .NET/Java

And then maybe a bit more tactical:
1. Method of getting memory address of current J instance:
http://www.jsoftware.com/pipermail/source/2014-May/000581.html
2. Method of cleaning up instance memory on linux:
http://www.jsoftware.com/pipermail/source/2015-February/000663.html


On Tue, Mar 8, 2016 at 7:32 AM, Thomas Costigliola <fo...@iocane.net>
wrote:

So far Unbox has a couple of bug fixes and build system changes not in
the standard source release. I have begun working on a re-implementation of
gerunds that should fix some bugs and allow some new features. This is
working out to be a somewhat long term project and I'd like to keep things
fresh and exciting in the meantime.
Please post your top BUG and/or FEATURE wishlists.


----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm



--
John D. Baker
bakerj...@gmail.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm