[7.4] Command line parameters -psp and -pcl
Locked
[7.4] Command line parameters -psp and -pcl
 
|
Hi,
two observations I made while working with VWs parcel command line options: -psp (parcel seach path) is broken, see attached patch (path list must be a collection of filenames, not strings) -pcl behaves is a little bit odd: Consider an image with a subdirectory "parcels", which is set via -psp as the only parcel directory. "parcels" contains a parcel named "MyParcel.pcl" -pcl "parcels\MyParcel.pcl": Loads the parcel (Parcel loadParcelByName: detects that a valid filename was specified) -pcl "MyParcel.pcl": Does not load the parcel (Parcel loadParcelByName: does not detect that a valid filename was specified, it just checks the parcel name, which is "MyParcel", not "MyParcel.pcl") -pcl "MyParcel": Loads the parcel IMHO -pcl "MyParcel.pcl" should also work Regards, Holger <?xml version="1.0"?> <st-source> <time-stamp>From VisualWorks®, 7.4 of Montag, 5. Dezember 2005 on Mittwoch, 29. März 2006 at 17:47:09</time-stamp> <methods> <class-id>DeploymentOptionsSystem</class-id> <category>command-line options</category> <body package="KBasePatches" selector="parcelPath:">parcelPath: fileNameStream "Set the parcel path" <option: '-psp'> | parcelPathEntries list | parcelPathEntries := CommandLineInterest argumentsFrom: fileNameStream. list := List new: parcelPathEntries size. parcelPathEntries do: [: each | | dir | ( [ dir := ( SystemUtils makeFilenamePortable: each ) asFilename. dir isDirectory ] on: OsError do: [: ex | ex return: false ]) ifTrue: [ list add: dir ] ifFalse: [ ^ self notify: ( #IsNotADirectory << #dialogs >> '<1s> is not a directory' expandMacrosWith: dir ) ] ]. " set the parcel path " Parcel searchPathModel value: list.</body> </methods> </st-source> |
Re: [7.4] Command line parameters -psp and -pcl
|
|
At 10:58 AM 3/29/2006, Holger Kleinsorgen wrote:
>Hi, > >two observations I made while working with VWs parcel command line options: > >-psp (parcel seach path) is broken, see attached patch (path list must be a collection of filenames, not strings) Yes, this is known and was fixed in the 7.4.1 jan06.1 build (AR 50137). >-pcl behaves is a little bit odd: > >Consider an image with a subdirectory "parcels", which is set via -psp as the only parcel directory. "parcels" contains a parcel named "MyParcel.pcl" > > -pcl "parcels\MyParcel.pcl": Loads the parcel > (Parcel loadParcelByName: detects that a valid filename was specified) > > -pcl "MyParcel.pcl": Does not load the parcel > (Parcel loadParcelByName: does not detect that a valid filename was specified, it just checks the parcel name, which is "MyParcel", not "MyParcel.pcl") > > -pcl "MyParcel": Loads the parcel > >IMHO -pcl "MyParcel.pcl" should also work Yes, that makes sense. Created AR 50585. -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
RE: [7.4] Command line parameters -psp and -pcl
|
|
In reply to this post by Holger Kleinsorgen-4
From: Alan Knight [mailto:[hidden email]]
> >-pcl behaves is a little bit odd: > > > >Consider an image with a subdirectory "parcels", which is set via -psp as > the only parcel directory. "parcels" contains a parcel named > "MyParcel.pcl" > > -pcl "MyParcel.pcl": Does not load the parcel > >IMHO -pcl "MyParcel.pcl" should also work > > Yes, that makes sense. Created AR 50585. Thanks Alan! On a related note, why is . included so late in the default list of parcel paths? I was trying to override some outdated goodies by saving new versions from the public repository to *.pcl in the image directory, and adding them to a runtime.cnf file. If I didn't get the order in the .cnf file right, the 1st line's parcel would look for its prereq in the parcel path, and find the one in contrib rather than the one in the image directory - which was mentioned in the 2nd line of runtime.cnf. The 2nd line of runtime.cnf would then try to load the newer version of the same parcel (I'm not sure what happened then, since this was with a headless image, and I quickly rearranged the lines). BTW, I've really enjoyed using the command line parameters to build up our web application server from a virgin runtime.im each time it is started. Normal startup is as a service via srvany, but I also have a shortcut to start it as headfull. Here are four things I need to do then to make it useful for debugging: 1. Notifier beDevelopment 2. Web | Debug mode 3. Web | Server Console | Edit Server | Allow error notifiers on server 4. If you try to use breakpoints, you will get an error. Look up in the stack for the send that has "parse: t1 getSource" (ProbedCompiledMethod>>from:full:?) and change it to "parse: (t1 getSource ifNil: [t1 decompiledSource])" The latter may not be necessary in 7.4 - in 7.3 we had to use sourceless parcels, otherwise we got file sharing errors when we tried to update them because VW had streams open on the .pst source files. Steve |
RE: [7.4] Command line parameters -psp and -pcl
|
|
At 03:05 PM 3/29/2006, Steven Kelly wrote:
>From: Alan Knight [mailto:[hidden email]] >> >-pcl behaves is a little bit odd: >> > >> >Consider an image with a subdirectory "parcels", which is set via >-psp as >> the only parcel directory. "parcels" contains a parcel named >> "MyParcel.pcl" >> >> -pcl "MyParcel.pcl": Does not load the parcel >> >IMHO -pcl "MyParcel.pcl" should also work >> >> Yes, that makes sense. Created AR 50585. > >Thanks Alan! Well, my original thought on this was just to strip off the .pcl and treat it as a normal name, but after some objections I don't think that's actually a good idea. Parcel file names and the parcels inside them don't have to have the same name, and in fact there are a number of parcels in the distribution that don't have matching names. Automatically taking something intended as a filename and treating it as the parcel name could have some rather unexpected results. Also, as it is now, parcel file name search doesn't go through the search path at all. That is, the -pcl option will accept either a) an explicit file path b) a parcel name, to be searched in the path. So if you give it -pcl Foo.pcl that is treated as being the same as -pcl ./Foo.pcl So I guess the most reasonable approach to this would be that if given a name that looked like a parcel file name, but unqualified, it could look in the parcel search path for it, rather than treating it as a file reference in the current directory. >On a related note, why is . included so late in the default >list of parcel paths? No idea, and it seems like it ought to be first. Created AR 50592 for that. >I was trying to override some outdated goodies by saving new versions >from the public repository to *.pcl in the image directory, and adding >them to a runtime.cnf file. If I didn't get the order in the .cnf file >right, the 1st line's parcel would look for its prereq in the parcel >path, and find the one in contrib rather than the one in the image >directory - which was mentioned in the 2nd line of runtime.cnf. The 2nd >line of runtime.cnf would then try to load the newer version of the same >parcel (I'm not sure what happened then, since this was with a headless >image, and I quickly rearranged the lines). I think it ought to load it successfully over top of the older version, so should be fairly harmless. >BTW, I've really enjoyed using the command line parameters to build up >our web application server from a virgin runtime.im each time it is >started. Normal startup is as a service via srvany, but I also have a >shortcut to start it as headfull. Here are four things I need to do then >to make it useful for debugging: > >1. Notifier beDevelopment >2. Web | Debug mode >3. Web | Server Console | Edit Server | Allow error notifiers on server >4. If you try to use breakpoints, you will get an error. Look up in the >stack for the send that has "parse: t1 getSource" >(ProbedCompiledMethod>>from:full:?) and change it to "parse: (t1 >getSource ifNil: [t1 decompiledSource])" > >The latter may not be necessary in 7.4 - in 7.3 we had to use sourceless >parcels, otherwise we got file sharing errors when we tried to update >them because VW had streams open on the .pst source files. > >Steve -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
RE: [7.4] Command line parameters -psp and -pcl
|
|
In reply to this post by Steven Kelly
At 04:05 PM 3/29/2006, Steven Kelly wrote:
>From: Alan Knight [mailto:[hidden email]] >> >-pcl behaves is a little bit odd: >> > >> >Consider an image with a subdirectory "parcels", which is set via >-psp as >> the only parcel directory. "parcels" contains a parcel named >> "MyParcel.pcl" >> >> -pcl "MyParcel.pcl": Does not load the parcel >> >IMHO -pcl "MyParcel.pcl" should also work >> >> Yes, that makes sense. Created AR 50585. > >Thanks Alan! On a related note, why is . included so late in the default >list of parcel paths? I think I now have a good reason, which is that '.' in the parcel path doesn't do what you would think it would do, particularly with respect to prerequisites. That is, when searching for a prerequisite, it tells you to look in the directory that prerequisite came from. Apparently that's been the sematnics for quite some time. We may change that in the future, or at least map it to a different character that doesn't already have an expected meaning. In the meantime, I'm not sure that putting it first would be a good idea. -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
RE: [7.4] Command line parameters -psp and -pcl
|
|
In reply to this post by Holger Kleinsorgen-4
From: Alan Knight [mailto:[hidden email]]
> >Thanks Alan! On a related note, why is . included so late in the default > >list of parcel paths? > > I think I now have a good reason, which is that '.' in the parcel path > doesn't do what you would think it would do, particularly with respect to > prerequisites. That is, when searching for a prerequisite, it tells you to > look in the directory that prerequisite came from. Apparently that's been > the sematnics for quite some time. We may change that in the future, or at > least map it to a different character that doesn't already have an > expected meaning. In the meantime, I'm not sure that putting it first > would be a good idea. Sorry Alan, I don't quite understand what this means: "when searching for a prerequisite, it tells you to look in the directory that prerequisite came from". Do you mean "the directory containing the parcel that requested the prerequisite"? What if the request comes from a package? Or a CNF file? Or the command line? What special case has the . hack been made for in Parcel class >>ensureLoadedParcel:withVersion:for:? Are developers really expected to guess that when a parcel loads a prereq, it searches in the parcel path - except that . there is replaced by the requesting parcel's dir, and that same dir is appended to the end of the path list, and then the real current dir is appended after it :-/? If the odd semantics of . won't be corrected for whatever reason, could you simply add $(VISUALWORKS)/image as the first path? Or then use ./. which won't be recognized by the hack, and so will still point to the real default directory? (Clearly, we must fight horrible hacks with still more horrible hacks...) Cheers, Steve |
Re: [7.4] Command line parameters -psp and -pcl
|
|
Steven Kelly wrote:
> > If the odd semantics of . won't be corrected for whatever reason, could > you simply add $(VISUALWORKS)/image as the first path? Or then use ./. > which won't be recognized by the hack, and so will still point to the > real default directory? (Clearly, we must fight horrible hacks with > still more horrible hacks...) Urgh, can't we rename the current use of '.' to something like '_', I sense that it's use is mostly limited to base code delivered by Cincom, so a rename would probably be doable without making too many shops unhappy. I didn't know that the meaning of '.' is so much different from 'Current working directory', renaming it would make it more clear that something different is going on. Lets fight horrible hacks with clearer hacks :-) R - |
Re: [7.4] Command line parameters -psp and -pcl
|
|
Reinout Heeck wrote:
> Urgh, can't we rename the current use of '.' to something like '_', I sense > that it's use is mostly limited to base code delivered by Cincom, so a rename > would probably be doable without making too many shops unhappy. why not go one step further and add - $(CD) / $(CURRENTDIRECTORY) - $(PD) / $(PARCELDIRECTORY) or $(PREREQUISITEDIRECTORY) (dont know which one the two names make its behavior clearer) |
RE: [7.4] Command line parameters -psp and -pcl
|
|
In reply to this post by Holger Kleinsorgen-4
From: Holger Kleinsorgen [mailto:[hidden email]]
> Reinout Heeck wrote: > > Urgh, can't we rename the current use of '.' to something like '_', > > I sense that it's use is mostly limited to base code delivered by > > Cincom, so a rename would probably be doable without making too > > many shops unhappy. > > why not go one step further and add > - $(CD) / $(CURRENTDIRECTORY) > - $(PD) / $(PARCELDIRECTORY) or $(PREREQUISITEDIRECTORY) > (dont know which one the two names make its behavior clearer) I like the idea, and almost suggested it, but then looked at the code that implements this. Anything in $() is read as a "platform variable" - from the environment variables, and failing that from the VW registry key on Windows. Giving the names CD and PD special semantics would make a mess of things for any app that expected them to have the correct value. Under NT-based Windows, CD is already mapped to the current directory name, providing command extensions are turned on. CD is an "invisible" environment variable: you don't see it in the list reported by SET. Because of this it isn't seen by VW's CEnvironment. A CD value in the registry is however returned. Similarly, if you explicitly set an environment variable CD, VW will see that value. One interesting fact is that environment variable names on both Windows and Unix are forbidden from containing the character =. Maybe we could have $(=CD)? Or then get very Smalltalky and have a new syntax, $[Filename defaultDirectoryName] (not much use for PD, though)? Still, I'd much prefer to see the non-standard behaviour of . simply replaced with standard behaviour. The parent parcel's path is already added to the end of the parcel path list anyway, so it will be found. Even that could be dropped, and if you want to load a parcel and its prereqs from a directory that's not on the list, you simply add it to the list or load the parcels in prereq order with full paths for each. Steve |
Re: [7.4] Command line parameters -psp and -pcl
|
|
I wonder if something like ~PCL would be an intuitive representation for
the dependent parcel's directory? Dave Steven Kelly wrote: > From: Holger Kleinsorgen [mailto:[hidden email]] >> Reinout Heeck wrote: >>> Urgh, can't we rename the current use of '.' to something like '_', >>> I sense that it's use is mostly limited to base code delivered by >>> Cincom, so a rename would probably be doable without making too >>> many shops unhappy. >> why not go one step further and add >> - $(CD) / $(CURRENTDIRECTORY) >> - $(PD) / $(PARCELDIRECTORY) or $(PREREQUISITEDIRECTORY) >> (dont know which one the two names make its behavior clearer) > > I like the idea, and almost suggested it, but then looked at the code > that implements this. Anything in $() is read as a "platform variable" - > from the environment variables, and failing that from the VW registry > key on Windows. Giving the names CD and PD special semantics would make > a mess of things for any app that expected them to have the correct > value. > > Under NT-based Windows, CD is already mapped to the current directory > name, providing command extensions are turned on. CD is an "invisible" > environment variable: you don't see it in the list reported by SET. > Because of this it isn't seen by VW's CEnvironment. A CD value in the > registry is however returned. Similarly, if you explicitly set an > environment variable CD, VW will see that value. > > One interesting fact is that environment variable names on both Windows > and Unix are forbidden from containing the character =. Maybe we could > have $(=CD)? Or then get very Smalltalky and have a new syntax, > $[Filename defaultDirectoryName] (not much use for PD, though)? > > Still, I'd much prefer to see the non-standard behaviour of . simply > replaced with standard behaviour. The parent parcel's path is already > added to the end of the parcel path list anyway, so it will be found. > Even that could be dropped, and if you want to load a parcel and its > prereqs from a directory that's not on the list, you simply add it to > the list or load the parcels in prereq order with full paths for each. > > Steve > > |
Re: [7.4] Command line parameters -psp and -pcl
|
|
Dave Stevenson wrote:
> I wonder if something like ~PCL would be an intuitive representation for > the dependent parcel's directory? Another option would be to make an analogy to thisContext, something like thisParcelDirectory or perhaps just thisDirectory. That still leaves open what kind of escape characters to use to set it apart from normal directory names, although an obvious choice could be to not bother about setting it apart syntactically since that also seems to work pretty well in the case of thisContext. R - |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |