Thanks Bill. I understand you to mean there is no code inside jconsole
(j806) to prevent a second copy being launched.

I've just verified that I can launch 2 copies of jconsole (j806), if I try
hard enough.

The different behaviour of j805 and j806 with my code is not a problem. It
could be an advantage in favour of j806.

On Thu, May 4, 2017 at 2:56 PM, bill lam <[email protected]> wrote:

> There is no reason why multiple j806 jconsole instances can not run. You
> problem may come from jhs setting or browser.
>
> On May 4, 2017 9:28 PM, "Ian Clark" <[email protected]> wrote:
>
> > > 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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to