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
