> Does this cause any regression? Only a temporary inconvenience, and only during development, not operationally.
I was killing and relaunching the process to update the J script. A less brutal solution would be to rely on my init, triggered inside JHS by my app, to clear out old code. I think Jsoftware has taken the right decision for j806. It seems to resist launching multiple copies of jconsole. Hitherto I've been developing for a single-use JHS server. I need to start thinking how best to share one server between many client apps. There are several ways to do it. But the best way will only emerge from experience. My current best is to use the client's process-ID (pid) as part of the name of the J locale which services the app. On Thu, May 4, 2017 at 5:47 AM, bill lam <[email protected]> wrote: > You are correct the way how j terminates has changed in j806. > Previously, when executing 2!:55 in j engine will call exit() > which terminates the running process > in j806, 2!:55 will call front-end (jconsole,jqt...) and the > front-end decides how to terminate. Does this cause any > regression? > > Чт, 04 май 2017, Ian Clark написал(а): > > For the record, let me confirm I've also got j806 Beta working inside the > > bundle (=macOS app) I'm developing. > > > > But there is a difference between j806 and j805 in how jconsole behaves > > when the app kills and re-launches the JHS server, plus whether it's > > possible for multiple copies of the jconsole "process" to coexist. I > won't > > clutter the list with stuff that's of no interest to anyone but me, but I > > will post my results if anyone is hitting contingent issues. > > > > It's no great matter AFAIC – I can program round the differences. I > merely > > note it in passing. > > > > On Fri, Apr 28, 2017 at 3:28 PM, Ian Clark <[email protected]> > wrote: > > > > > I've got a cutdown j805 installation working inside the bundle (=the > app). > > > So thanks for your advice, @Bill. > > > > > > For the record (i.e. for anyone trying to do what I did), Xcode copies > > > "resources" (j scripts, in my case) into a substantially different file > > > structure inside the "product" (=bundle it builds) than I have in the > > > project folder. But Xcode can be told to treat entire folders as > resources > > > – and these it copies without messing them up. > > > > > > Or making trouble over any dylibs they contain. > > > > > > But then you have the problem of finding the runtime path to jconsole > in > > > order to launch it. > > > The Swift object: Bundle.main.path --only finds files at the top level > of > > > the /Resources/ folder. > > > > > > There are 2 ways round this I know of… > > > > > > (a) launch a new special shell script I place at the top level of > > > /Resources/ (which Bundle.main.path readily finds for me) --which in > turn > > > calls jconsole where it typically resides: viz inside /bin/ > > > > > > (b) pick any file: (…/Resources/anyfile.anyextension), find its path > via > > > Bundle.main.path, then string-process it to build the actual path: > > > (.../Resources/bin/jconsole) > > > > > > I've used (b) just to get it to work. But that's so fragile and dodgy > I'll > > > probably go over to (a). Which does have the advantage I can move the > > > command line arguments out of the Swift code and into the shell script > > > (…where IMO they belong!) > > > > > > BTW just in passing… from what I read in the Apple security > documentation, > > > they'd like me to move that stuff the other way!! Because shell scripts > > > inside the distributed app (the bundle) can be edited by anyone using > > > TextEdit. Whereas inside Swift code the path arguments are concealed. > And > > > to edit the Swift code you'd need to install Xcode and get hold of my > > > source code. (Which I plan to make Open Source anyway, ha-ha!) > > > > > > On Thu, Apr 27, 2017 at 11:55 PM, Ian Clark <[email protected]> > wrote: > > > > > >> Thanks, Bill. That's a useful checklist of what I need. > > >> > > >> On Thu, Apr 27, 2017 at 3:16 AM, bill lam <[email protected]> > wrote: > > >> > > >>> profile.ijs expects a J install to work, it would be easier > > >>> if you duplicate the j base install inside your datenow folder, > > >>> eg > > >>> > > >>> . > > >>> ├── addons > > >>> │ └── ide > > >>> │ └── jhs > > >>> │ ├── config > > >>> │ ├── demo > > >>> │ └── js > > >>> │ ├── codemirror > > >>> │ │ ├── j > > >>> │ │ └── util > > >>> │ ├── d3 > > >>> │ ├── jquery > > >>> │ │ └── smoothness > > >>> │ │ └── images > > >>> │ └── webgl > > >>> ├── bin > > >>> │ └── icons > > >>> ├── system > > >>> │ ├── config > > >>> │ ├── defs > > >>> │ ├── main > > >>> │ └── util > > >>> └── tools > > >>> ├── ftp > > >>> ├── regex > > >>> └── zip > > >>> > > >>> --- user/config/startup.ijs <<<<< your script > > >>> > > >>> put jconsole and libj.dylib under the bin, and it should find > > >>> the boot.ijs in system/util. Check the value of BINPATH and LIBFILE > > >>> tweak profilex.ijs to assign ~user folder inside this bundle, > > >>> the command to run your own script would be inside > > >>> user/config/startup.ijs. > > >>> > > >>> Чт, 27 апр 2017, Ian Clark написал(а): > > >>> > @Bill > > >>> > jconsole finds libj.dylib perfectly well. Especially if they're > both > > >>> in the > > >>> > same folder, like /bin/. (Inside a bundle, that's: /Resources/.) > I'm > > >>> 100% > > >>> > certain now. > > >>> > > > >>> > The reason I originally blamed jconsole? I was getting this fatal > > >>> runtime > > >>> > error: > > >>> > ————————————————— > > >>> > dyld: Library not loaded: libj.dylib > > >>> > Referenced from: > > >>> > /Users/ianclark/Library/Developer/Xcode/DerivedData/datenow- > > >>> gyuykqedjlmrnceezgclwsaipghz/Build/Products/Debug/datenow.ap > > >>> p/Contents/MacOS/datenow > > >>> > Reason: image not found > > >>> > ————————————————— > > >>> > I thought it was coming from jconsole, but it wasn't. It was the > Apple > > >>> Code > > >>> > Police. The workaround was simply not to tell Xcode that the dylib > was > > >>> > present. > > >>> > > > >>> > jconsole could still find it – no trouble – but it was failing > because > > >>> it > > >>> > created a bad SystemFolders_j_ . Therefore it couldn't find > boot.ijs. > > >>> (Only > > >>> > a living working JE would get as far as that.) > > >>> > > > >>> > Thanks for telling me about NSGetExecutablePath. I might have a > use for > > >>> > that. But not inside a bundle, where Bundle (Swift) or NSBundle > > >>> > (Objective-C) works perfectly well for me. It finds libj.dylib even > > >>> when > > >>> > Xcode doesn't know it's there. It's part of my runtime diagnostics. > > >>> > > > >>> > My architecture now works ok. But it is fragile and critical at > build > > >>> time. > > >>> > I now have a lot of code in there to tell me exactly what goes > wrong. I > > >>> > know I will need it when I migrate to macOS Sierra. > > >>> > > > >>> > On Wed, Apr 26, 2017 at 3:07 AM, bill lam <[email protected]> > wrote: > > >>> > > > >>> > > jconsole already has tried hard to find the absolute path of > itself. > > >>> For > > >>> > > mac, it calls > > >>> > > _NSGetExecutablePath > > >>> > > in jeload.c , you may debug to find why it failed to load > > >>> libj.dylib. if > > >>> > > the result from the function call is correct, then it should a > > >>> security > > >>> > > issue or bundle cannot be accessed as a normal file system. > > >>> > > > > >>> > > On 26 Apr, 2017 9:51 am, "Ian Clark" <[email protected]> > wrote: > > >>> > > > > >>> > > > Thanks, @Bill. I looked for a man-file and searched the wiki > but > > >>> > > overlooked > > >>> > > > the user manual. > > >>> > > > > > >>> > > > @Eric - thanks, that may solve my problem. > > >>> > > > > > >>> > > > Is it a "real" problem? Yes. > > >>> > > > > > >>> > > > Do I really need it – for the end-user? Maybe / maybe not. > > >>> > > > > > >>> > > > I'm trying to embed jconsole directly in a Mac app, to simplify > > >>> > > > distribution to non-J-experts. Currently I need to instruct the > > >>> customer > > >>> > > to > > >>> > > > install J, and the app launches jconsole via a fixed absolute > > >>> > > > path: /Applications/j64-805/bin/jconsole > > >>> > > > > > >>> > > > I could solve the problem with a fully-fledged installer, but > I'd > > >>> rather > > >>> > > > offer a single monolithic app which can simply be downloaded > and > > >>> run from > > >>> > > > anywhere. > > >>> > > > > > >>> > > > An app is really a disguised folder called a "bundle". Apart > from > > >>> that, > > >>> > > it > > >>> > > > acts like an ordinary folder for most purposes… > > >>> > > > Except for libj.dylib (ideally needs to go in the bundle too), > > >>> which > > >>> > > Xcode > > >>> > > > is being unexpectedly awkward about, in ways I don't fully > > >>> understand. > > >>> > > > Everything I've tried so far gets defeated: jconsole runs with > a > > >>> command > > >>> > > > line but reports it can't find its dylib, even though I copy > it to > > >>> the > > >>> > > same > > >>> > > > directory inside the bundle. I suspect it's yet another ad-hoc > > >>> security > > >>> > > > band-aid from Apple. > > >>> > > > > > >>> > > > I reason that if I actually tell jconsole where libj.dylib is > > >>> (…the one I > > >>> > > > want it to use), that might fix it. Will report back when I've > > >>> made sense > > >>> > > > of what works and what doesn't. There's a raft of things to > try. > > >>> > > > > > >>> > > > > > >>> > > > On Wed, Apr 26, 2017 at 12:35 AM, Eric Iverson < > > >>> [email protected] > > >>> > > > > > >>> > > > wrote: > > >>> > > > > > >>> > > > > A recent (806) change to jconsole added an undocumented new > > >>> parameter: > > >>> > > > -lib > > >>> > > > > path/jlib.dylib > > >>> > > > > > > >>> > > > > It is undocumented because I figured it should only be used > in > > >>> special > > >>> > > > > development circumstances. It would be interesting if you > have a > > >>> real > > >>> > > use > > >>> > > > > case for normal use. > > >>> > > > > > > >>> > > > > On Tue, Apr 25, 2017 at 6:15 PM, Ian Clark < > > >>> [email protected]> > > >>> > > > wrote: > > >>> > > > > > > >>> > > > > > OS X questions... > > >>> > > > > > > > >>> > > > > > On what default path does jconsole expect to find > libj.dylib ? > > >>> > > > > > > > >>> > > > > > Can the actual path be specified as a command line > argument to > > >>> > > > jconsole? > > >>> > > > > > > > >>> > > > > > Where can I find a list of permissible command line > arguments > > >>> for > > >>> > > > > jconsole? > > >>> > > > > > ------------------------------ > ------------------------------ > > >>> > > ---------- > > >>> > > > > > 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/forum > > >>> s.htm > > >>> > > ------------------------------------------------------------ > > >>> ---------- > > >>> > > For information about J forums see > http://www.jsoftware.com/forum > > >>> s.htm > > >>> > > > > >>> > ------------------------------------------------------------ > ---------- > > >>> > For information about J forums see http://www.jsoftware.com/ > forums.htm > > >>> > > >>> -- > > >>> regards, > > >>> ==================================================== > > >>> GPG key 1024D/4434BAB3 2008-08-24 > > >>> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > > >>> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > > >>> ------------------------------------------------------------ > ---------- > > >>> For information about J forums see http://www.jsoftware.com/ > forums.htm > > >>> > > >> > > >> > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
