Opened 9 years ago

Closed 9 years ago

#803 closed enhancement (worksforme)

New IDE preference item request

Reported by: plkrueger Owned by: gb
Priority: normal Milestone:
Component: IDE Version: trunk
Keywords: Cc:

Description

If the CCL IDE bundle is moved out of the CCL directory and executed, certain functions will fail (e.g. just do #&NSApp in the listener and see what happens). This is because the ccl: logical translation no longer points to the CCL directory, but rather to whatever directory the bundle is in. This is set by the init-ccl-directory-for-ide function. This could also be a problem for any saved applications depending on what they do. There are various ways this could be addressed: 1) add a new value into the Info.plist identifying the CCL directory and use it to initialize the ccl: translation 2) Modify init-ccl-directory-for-ide to search for the right directory 3) create a physical link to the CCL directory in the bundle somewhere and use that as the translation for the ccl: logical directory, 4) add a user preference that identifies where the CCL directory is and use that to initialize the translation. I prefer #4 because it is easier to change if the bundle is moved to a different machine or if the CCL directory is moved at some point. #2 is intriguing but depending on how the search is done, could take a significant amount of time. So I am requesting an enhancement to the IDE that adds a preference item identifying the CCL directory. It should default to the value currently used. In the meantime I will assure that applications that my tools generate will reset the logical translation in some way.

Change History (4)

comment:1 Changed 9 years ago by gb

  • Owner set to gb
  • Status changed from new to assigned

There used to be a preferences item for this; I think that there still is, but don't think that it's used anymore. The idea breaks down if one has multiple versions of CCL installed (and they all share the same preferences file).

At one point, there was support for storing/finding the interface directory inside the bundle. (That was mostly intended to address problems with the bridge, where it needed to runtime database lookups in order to invoke ObjC methods.) I don't know if that support still exists.

The IDE initializes the CCL directory (the translations for the "ccl" logical host) based on the directory that contains the bundle. That's simple, and has the nice property of effectively being a relative pathname; one can move the containing directory anywhere in the filesystem; it does mean that the bundle isn't entirely standalone. It's not clear that that's too onerous; it only affects certain applications (the IDE itself and anything that behaves sort of like a Lisp development system at least some of the time.)

At one point, there may have been support for finding the CCL directory inside the bundles (e.g., if bundle/Resources/CCL exists and looks plausible, use it.) That's also effectively a relative path.

Both of these approaches (the status quo and "ccl inside the bundle") are likely to be more robust than schemes which store an absolute path persistently; the differences have to do with packaging (and with what support exists in tools like BUILD-APPLICATION.)

A large class of potential applications (those that aren't partly "lisp development systems") aren't affected by this.

As a related issue, it may be useful to have a documented/fit for public consumption way of setting CCL's translations, if only to supported exceptional cases and/or debugging. (One might want to be able to telnet into a running Currency Converter to debug it and have access to #/ and friends while doing so.)

comment:2 Changed 9 years ago by plkrueger

I searched a little more thoroughly than I did previously and found the *ccl-directory* preference set to "" in start.lisp. As near as I can tell it isn't referenced anywhere.

Given this I'd modify my request and break it into two parts:

1) Since the default preference is currently set to "", leave it that way. Make a modest change to init-ccl-directory-for-ide: (defun init-ccl-directory-for-ide ()

(let* ((bundle-path (#/bundlePath (#/mainBundle ns:ns-bundle)))

(parent (#/stringByDeletingLastPathComponent bundle-path)) (path (ccl::ensure-directory-pathname

(if (string= *ccl-directory* "")

(lisp-string-from-nsstring parent) *ccl-directory*))))

(ccl::replace-base-translation "ccl:" path)))

This keeps the current behavior if no user preference is set and uses it if it is set somehow. This would permit me to add a mechanism for setting the user preference in some fashion other than via the preferences panel. I'm not sure precisely how I'll do that yet, but at least the job is somewhat easier. Perhaps part of that mechanism is the public way of setting CCL's translation that you wished for in the last paragraph of your comment.

2) Modify the preferences panel to include this preference as time permits.

I still think it's reasonable for an individual user who has problems with the default behavior to set their own preference for which ccl directory to use. That would override whatever application default was set. The need may be relatively rare, but it's available when it arises. I can (and if you accept part #1 above will) provide a function that can be called to do the same thing that selecting something in a preference panel would do, but that is a non-standard sort of operation for a Cocoa application.

You are of course correct that the only time this really comes into play is when you generate a stand-alone application that includes IDE resources (either for debugging or because you want them there as part of your application) or if you decide to move the IDE bundle out of the CCL directory for some reason. Generating a stand-alone executable that includes IDE resources for debugging purposes is precisely one of the models that my new application tools support, which is how I ran into this problem in the first place.

Although I considered it briefly myself, I don't think looking for directories inside the bundle is the right way to go; too difficult for the user to modify it if that is ever needed. There are many precedents for preferences that are directory or file names, so that doesn't really bother me.

comment:3 Changed 9 years ago by gb

Using a globally saved preference means that every application (every variant of the CCL IDE) that shares the same preferences file would try to use the same value. This doesn't work as well in practice as one might think it would: it leads to obscure errors when the preference refers to a CCL directory from another version of CCL, among other things.

Obviously, this is less of a problem if the application uses its own preferences file and if there's only likely to ever be one version of the application installed. I don't think that the IDE itself should encourage anyone to persistently/globally change the CCL directory; that's just too sticky.

Note that the file "home:ccl-ide-init" gets loaded (if it's present) just before the event loop starts. That file could contain something like:

(if (equal (application-bundle-name) "foo.app")
  (set-ccl-directory ...)) ; or maybe something better

comment:4 Changed 9 years ago by plkrueger

  • Resolution set to worksforme
  • Status changed from assigned to closed

Using the home:ccl-ide-init file was something I hadn't considered and could provide a reasonable work-around. For most of the users that I'm thinking about you probably wouldn't even qualify the change by the app bundle name since you would almost always want to point at the single installed CCL directory on your system, whether the app being run is the normal IDE or something derived from it. I'll give this a try. You can certainly make the argument that if you're using a lisp listener in your app you should be able to handle an init file. Do this once and you solve the problem for all bundles that include IDE resources and use normal top-level functions. If you want to call this a solution I'll buy it, assuming tests don't turn up any problems. I'll call this resolved for now and reopen if I run into problems.

I have some other quibbles with previous comments about preferences, but with a viable work-around we can ignore that unless I run into some other problem.

Note: See TracTickets for help on using tickets.