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 <blake1...@gmail.com> 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 <loke...@gmail.com>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 <blake1...@gmail.com> 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 >>> >>> >> >
