Brian:
a A result is always produced. For example if I enter
"k =: 100" I see the 100 output as if I had typed
"]k =: 100". Is this intentional, or was it just easier to
do than eliminating the output?
The present interface to the J engine provides a JDo and JGetM. JDo
sends a sentence to the J engine; JGetM retrieves the value of a
named variable. It is something of a limitation that JDo does not
return the exact result produced by the engine. Instead you have to
store the result of a sentence in a named variable and use JGetM to
pass it back. As you guessed, for this example, it is more work than
it's worth to parse through the input sentence to determine whether a
result is "usually" seen. Of course, probably the only time you need
to work at this is if you are writing the code for a session manager
and you wish to emulate jconsole's behaviour. I have ideas for other
ways to interact with J than with a session log of inputs and outputs.
b Only single line inputs are permitted so multiple
line noun, verb, ... definitions must be loaded from a
file, not the input field.
On the File menu item is a "Load script" entry. Up pops a file open
panel and you can choose the script to load.
I also noticed that J 'load' and 'require' sentences
in scripts do not work. Am I doing something wrong, or is
that not implemented? I assume this is what you mean in your
description below about the system being able to
+ * find the path to a script located within the application bundle;
The Menu: File|New File can go outside the application
bundle, but the J scripts themselves cannot.
I don't understand what you mean by this feature.
The usual behaviour when starting J is that the profile.ijs script is
loaded. Many of the familiar verbs you expect are created by this
script (or sub-scripts). This includes load and require. However, in
the environment contemplated here, you may wish to have a different
script in play at start up. If your application is to be an
accounting system, for example, there is no point in distributing it
with the profile.ijs tree: you want something like accounts.ijs, an
application-specific script. However, in order to be able to include
such a script in the .app bundle (eg do a ^click on the .app; select
"show package contents" and go to Contents/Resources to find
start.ijs) your C code needs to be able to find the file within the
bundle. Hence, is included the little piece of magic "[[NSBundle
mainBundle] bundlePath]" in file jtask.m at line 35.
+ application is standalone and does not require J to be installed on
+ your system.
Where else could J be installed? On an intranet?
This is actually a false promise at the moment. I'm trying to follow
a common and most appealing feature on the Mac. Many applications are
installed by drag and drop of a .app bundle to a location of your
choice. Installation could not be simpler, and uninstall is both
simple and assured (no more application remnants left lying around;
no uninstallable applications). However to do that, the app must be
self-contained. This app has a problem right now: it needs to link to
the libj601.dylib file at load time and I don't know how to make the
linker use this file when it is contained within the .app/Contents/
Resources folder. If someone could help me here, I'll happily include
that wisdom in the commentary file for others to use.
Forgive my naivete, but is the main purpose of such
a client/server application to deliver a J application
to a client for whom you wish to limit the access to J
itself and provide only a gui interface -- webpage-like --
to the client, not the whole J system (like Alex Rufon's
J_CSharp application with .NET)?
I've described the structure of this application as client/server,
which it is. The user interface is done in Objective C (with Cocoa,
using XCode and Interface Builder). It sends sentences to the J
engine, which just happens to be running on the same machine. Imagine
the J engine, running the guts of the application on a different
machine and you've got a distributed client/server app. At this time,
I'm not sure whether the transport of sentences from the UI to J is
best done with sockets or Webobjects or something else, but that is
definitely one development path for the future. Your observation is
correct. The end user should not even be aware that J is involved
(except for the copyright notice).
The main purpose of this is to make applications that take advantage
of the best of both worlds. In my purely personal opinion, the Mac
user interface is head and shoulders above the others and the J
engine provides a superb data massaging environment, both fast to
develop and fast to execute. It does not trouble me that it's not
portable to the PC. If it is of interest, I've found that most of the
Objective C work proceeds smoothly and quickly. Apple provides
excellent documentation and good example code. There are naturally
times when pure C code is required (see InitWithJBinary in JData.m)
and that takes some work. What I've tried to do here is document how
I've done this, so that others need not reinvent the wheel.
Mike
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
