Re: [Bug-apl] SQL interface needs a workspace

[Elias Mårtenson]

Well, I never said you can't use a workspace. Right now everything about the libraries and packages are very much in flux, which is why I have not spent much time thinking about distribution.

There clearly needs to be a nice, encapsulated, way to distribute libraries with a native component. I think we'll deal with that once the pure APL package system is done.

Finally, I think we simply have to agree to disagree on the value of various traditional APLisms. There are plenty of things I would like to see modernised, but I haven't even mentioned most of those because there are much more important things to deal with. Besides, Jürgen's opinion is generally closer aligned to yours than mine, so I'm clearly outnumbered. :-)

Regards,

Elias

On 15 May 2014 23:37, Blake McBride <address@hidden> wrote:

Dear Elias,

I will add the SQL workspace to my upcoming keyed file system.  Should I add a README for your SQL library to my keyed file package too?

Regarding workspaces and their opaque format, this is exactly the same argument as my nested array argument.  Are we going to debate and ignore the IBM APL standard, or support it?

BTW, your postgresql fix works great.  Thanks!!

Blake

On Thu, May 15, 2014 at 10:18 AM, Elias Mårtenson <address@hidden> wrote:

Actually, I have already mentioned to Jürgen that we need some way of specifying a default serach path for )LOAD and friends. However, I have not seen it as particularly important yet since we don't have a completed package manager yet.

I personally dislike workspaces and I know I'm not alone in the desire to have plain source files instead of an opaque format. Therefore, I don't really have any particular drive to make it. But, go right ahead and make one if you feel that would be useful.

Regards,

Elias

On 15 May 2014 22:30, Blake McBride <address@hidden> wrote:

Greetings,

I am in the process of writing a proposed README.txt file for the SQL interface to GNU APL.  That package comes with a file named sql.apl that is a shell script to startup GNU APL with the SQL shared library and APL routines already loaded.

IMO, that method of loading it has a few problems.  It only works from the distribution directory unless the user knows (without understanding the pieces) what paths need to be changed - which is undocumented.  It is further complicated by the need for the startup path of APL and its relation to the workspaces directory used by APL.  All this is way too much for a newbie.

The second problem is that that script pre-loads needed APL functions.  Again, when a newbie loads their own workspace, they will lose the APL routines.

My suggestion, without necessarily removing sql.apl, is to have that package include an actual workspace that can be loaded.  That workspace would be a copy of sql.apl except that:

1.  sql∆∆load_library world be renamed to SQL∆LoadLibrary to be consistent with the other functions in that workspace.

2.  SQL∆LoadLibrary will take an argument specifying the full path of lib_sql.so rather than having it hard-coded.

Along with some documentation, I think this will make the SQL library a lot easier to use for newbies.

Thanks.

Blake