Publish as Parcel fails
Locked
 
|
Hi,
I've encountered the following problems many times but didn't report it yet. After using an image for a while, publishing a package as parcels fails. In particular there is an attempt to close open streams (ExternalStream closeOpenStreamsNamed:) if they match a particular filename which is nil in this cases. I haven't figured out a scheme when this one happens but it might be related to using the image on Windows and Mac. Once it occurred I have to start with a fresh image. Is this bug know? Is there a workaround? Regards, Steffen _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
It doesn't sound known. Are you saying that you've moved the
same image around between different machines? If so, that sounds like
perhaps there are files associated with those or with other parcels that
are no longer found. But if it's just trying to close them, I think that
shouldn't be a big problem. Also, are you publishing the same thing as
parcels repeatedly? It sounds like that would come up from
"Rescuing" sources for code still in the image from old parcel
files. Have you perhaps published the parcels somewhere, but then moved
to a machine where they are no longer visible at that path? Or that the
current directory has changed?
At 07:08 AM 2010-11-01, Steffen Märcker wrote: Hi, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Thomas Am 01.11.2010 18:55, schrieb Alan Knight: It doesn't sound known. Are you saying that you've moved the same image around between different machines? If so, that sounds like perhaps there are files associated with those or with other parcels that are no longer found. But if it's just trying to close them, I think that shouldn't be a big problem. Also, are you publishing the same thing as parcels repeatedly? It sounds like that would come up from "Rescuing" sources for code still in the image from old parcel files. Have you perhaps published the parcels somewhere, but then moved to a machine where they are no longer visible at that path? Or that the current directory has changed? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Alan Knight-2
Hi,
yes, I am moving the same image between different machines. On the new machine I set the new source paths via SourceFileManager>>changeSourceDirectoryFrom:to: During development I am regularly saving my packages as parcels. When I move to the other machine I move the whole directory, including all loaded parcels. Do I have to adjust the current directory too? Perhaps It might be good If the environment stores the source paths as relative paths instead of absolute paths? I consider the possibility to run the very same development environment on different machines as a real strength. Regards, Steffen Am 01.11.2010, 18:55 Uhr, schrieb Alan Knight <[hidden email]>: > It doesn't sound known. Are you saying that you've moved the same image > around between different machines? If so, that sounds like perhaps there > are files associated with those or with other parcels that are no longer > found. But if it's just trying to close them, I think that shouldn't be > a big problem. Also, are you publishing the same thing as parcels > repeatedly? It sounds like that would come up from "Rescuing" sources > for code still in the image from old parcel files. Have you perhaps > published the parcels somewhere, but then moved to a machine where they > are no longer visible at that path? Or that the current directory has > changed? > > At 07:08 AM 2010-11-01, Steffen Märcker wrote: >> Hi, >> >> I've encountered the following problems many times but didn't report it >> yet. After using an image for a while, publishing a package as parcels >> fails. In particular there is an attempt to close open streams >> (ExternalStream closeOpenStreamsNamed:) if they match a particular >> filename which is nil in this cases. I haven't figured out a scheme when >> this one happens but it might be related to using the image on Windows >> and >> Mac. Once it occurred I have to start with a fresh image. >> >> Is this bug know? >> Is there a workaround? >> >> Regards, Steffen >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Parcels which you load from the distribution will normally
be maintained as logical paths relative to the $VISUALWORKS environment
variable/registry setting. That makes them work correctly whether you
move the image to a different machine, or to a different location on the
same machine.
If you load a parcel via another mechanism, then it will depend on the filename object that was used to load it. Unfortunately, if you load it via e.g. the file browser or the load dialog, it will tend to be an absolute filename, although that depends on what your parcel path is and where the file was located. But saving it in the current directory and loading it from there will result in one that isn't relative to $VISUALWORKS. If you are using a mechanism of your own to load these, then you can make it use files that are relative, or, preferably, defined with respect to some environment variable. One simple way of doing this, if you're using the image directory, and you leave your images in the same place they're installed, is to add $(VISUALWORKS)/image to your parcel path, and remove ".". Then the path for parcels loaded via the dialog will be relative to that, and moving the whole directory between machines would work fine. Other situations might require slightly more. At 08:00 AM 2010-11-02, Steffen Märcker wrote: Hi, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Thanks for your advice!
Does this imply that it's not possible to load a parcel which location will be a path relative to the image's directory? Regards, Steffen Am 02.11.2010, 16:50 Uhr, schrieb Alan Knight <[hidden email]>: > Parcels which you load from the distribution will normally be maintained > as logical paths relative to the $VISUALWORKS environment > variable/registry setting. That makes them work correctly whether you > move the image to a different machine, or to a different location on the > same machine. > > If you load a parcel via another mechanism, then it will depend on the > filename object that was used to load it. Unfortunately, if you load it > via e.g. the file browser or the load dialog, it will tend to be an > absolute filename, although that depends on what your parcel path is and > where the file was located. But saving it in the current directory and > loading it from there will result in one that isn't relative to > $VISUALWORKS. If you are using a mechanism of your own to load these, > then you can make it use files that are relative, or, preferably, > defined with respect to some environment variable. > > One simple way of doing this, if you're using the image directory, and > you leave your images in the same place they're installed, is to add > $(VISUALWORKS)/image to your parcel path, and remove ".". Then the path > for parcels loaded via the dialog will be relative to that, and moving > the whole directory between machines would work fine. Other situations > might require slightly more. > > At 08:00 AM 2010-11-02, Steffen Märcker wrote: >> Hi, >> >> yes, I am moving the same image between different machines. On the new >> machine I set the new source paths via >> >> SourceFileManager>>changeSourceDirectoryFrom:to: >> >> During development I am regularly saving my packages as parcels. When I >> move to the other machine I move the whole directory, including all >> loaded >> parcels. Do I have to adjust the current directory too? Perhaps It might >> be good If the environment stores the source paths as relative paths >> instead of absolute paths? I consider the possibility to run the very >> same >> development environment on different machines as a real strength. >> >> Regards, Steffen >> >> >> >> Am 01.11.2010, 18:55 Uhr, schrieb Alan Knight <[hidden email]>: >> >>> It doesn't sound known. Are you saying that you've moved the same image >>> around between different machines? If so, that sounds like perhaps >>> there >>> are files associated with those or with other parcels that are no >>> longer >>> found. But if it's just trying to close them, I think that shouldn't be >>> a big problem. Also, are you publishing the same thing as parcels >>> repeatedly? It sounds like that would come up from "Rescuing" sources >>> for code still in the image from old parcel files. Have you perhaps >>> published the parcels somewhere, but then moved to a machine where they >>> are no longer visible at that path? Or that the current directory has >>> changed? >>> >>> At 07:08 AM 2010-11-01, Steffen Märcker wrote: >>>> Hi, >>>> >>>> I've encountered the following problems many times but didn't report >>>> it >>>> yet. After using an image for a while, publishing a package as parcels >>>> fails. In particular there is an attempt to close open streams >>>> (ExternalStream closeOpenStreamsNamed:) if they match a particular >>>> filename which is nil in this cases. I haven't figured out a scheme >>>> when >>>> this one happens but it might be related to using the image on Windows >>>> and >>>> Mac. Once it occurred I have to start with a fresh image. >>>> >>>> Is this bug know? >>>> Is there a workaround? >>>> >>>> Regards, Steffen >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> -- >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>> [hidden email] >>> [hidden email] >>> http://www.cincom.com/smalltalk > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |