Oleg Kobchenko wrote: > Suppose, "JRAN" is located in the SVN folders. > These folders are mapped to the actual J subtree > on your disk, e.g. j/contrib or so. Then some of > the SVN API is exposed through a J library, e.g. rsync > (for remove sync); or lcheckin, lupdate, ldiff, lmerge, > rload, etc. Possibly using GUI or external differs. > > As a result, from J session, right at the fingertips, > you get instant availability of the most recent updates > from the libraries. Conversely, if you contribute to a > library, you can check-in right from J, and your changes > are instantly globaly available. > > Possible question: how to handle builds, something > that (continous) integration systems do. But for J > this could be simplified with zero build approach: > all code should work as is, as in ASP/PHP/scripting web > application. That's also true for python: it does > compile on demand in place, as in MoinMoin wiki.
It would be good to get a J application library formally up and running. The wiki and SVN give us the underlying tools needed, and the next step is to agree on design. We can think of the J library (scripts, tutorials, demos etc) as being in two distinct (non-overlapping) parts - a core library, and an addons library (the J application library, perhaps called JAL). The name "addons" is used here only for historical reasons. The core library is installed in the system directory, and the addons library installed in the addons directory. Jsoftware has overall responsibility for the core library, and that library is distributed with the system. The addons library is a community effort, and distribution is via the wiki and/or SVN. Addons should be smoothly integrated with the core library, so that installing an addon script makes it available just like a core script. That we still need a core library is because the J development system itself makes essential use of some scripts, for example to support the J session. On the other hand, there are several scripts currently distributed under system, that could be better moved to addons. Likely the core library would consist of everything needed to run a session, plus key applications like labs, plot and grid. The core library would continue to be available, as now, via SVN, and users can get permission to update it. Some issues that were raised: 1. "But I suggest instead of tweaking stdlib, we could maintain an effort for new common library(ies). Earlier it was discussed to having more intuitive string manipulation primitives, such as "substr"...." One question here is whether you want to replace, or extend the core libraries. I think extending is much better, and any problems in the core libraries should be fixed. For example, an addons "scriptutil" would start with a require 'strings', rather than try to replace the existing 'strings' script. 2. "There are functions which are redefined too often, such as "ts"...". This is a mistake, and should be cleaned up - but it is a core library issue, and should not affect addons. 3. "Suppose, "JRAN" is located in the SVN folders. These folders are mapped to the actual J subtree on your disk, e.g. j/contrib or so. Then some of the SVN API is exposed through a J library, e.g. rsync (for remove sync); or lcheckin, lupdate, ldiff, lmerge, rload, etc. Possibly using GUI or external differs...". SVN can be driven by a J application, so all this is quite possible. 4. "Possible question: how to handle builds, something that (continous) integration systems do. But for J this could be simplified with zero build approach: all code should work as is, as in ASP/PHP/scripting web application. That's also true for python: it does compile on demand in place, as in MoinMoin wiki." I prefer to keep source and the build separate, even if this is more work on the server, perhaps separate addons source and build repositories, or build files available outside of SVN. The python approach leads to fairly lengthy source files which are typically self-contained, whereas most J apps are built from a large number of much smaller source files that are not (and thus have more complex builds). We could probably set up post-commit build hooks in SVN for this. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
