did not work either :(
Really I wonder if we will succeed to have a modular system one day.
If we do not exercise it it will never happen.
Stef
unloadNautilus
#Nautilus asClass cleanUp.
KMRepository reset.
KMPragmaKeymapBuilder release.
#NautilusUI asClass
On 30 Nov 2013, at 09:07, Stéphane Ducasse stephane.duca...@inria.fr wrote:
did not work either :(
Really I wonder if we will succeed to have a modular system one day.
If we do not exercise it it will never happen.
Yes. And this is related to the #cleanUp scripts, too: When doing “Smalltalk
On 30 Nov 2013, at 09:48, Marcus Denker marcus.den...@inria.fr wrote:
On 30 Nov 2013, at 09:07, Stéphane Ducasse stephane.duca...@inria.fr wrote:
did not work either :(
Really I wonder if we will succeed to have a modular system one day.
If we do not exercise it it will never happen.
Ok I will continue but this is try and error and I cannot see anything because
once it crashes…. it crashes.
Stef
On Nov 30, 2013, at 9:52 AM, Marcus Denker marcus.den...@inria.fr wrote:
On 30 Nov 2013, at 09:48, Marcus Denker marcus.den...@inria.fr wrote:
On 30 Nov 2013, at 09:07,
I do not understand why
{#Nautilus. #PackageTreeNautilus} do: [:each | each asClass resetGroups].
or
GroupManager current reset (does not exist) and
followed by
5 timesRepeat:[Smalltalk garbageCollect.].
do not get rid of the registration especially since they are weak
So now what I'm doing
It's interesting that I have never seen this error. And the Jenkins job is
able to unload it too...
https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKernel3.0-FromTopShrink/
-- Pavel
2013/11/30 Stéphane Ducasse stephane.duca...@inria.fr
Pavel I tried your scripts (see
It's interesting that I have never seen this error. And the Jenkins job is
able to unload it too...
https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKernel3.0-FromTopShrink/
may because you remove more :)
and the ui kills it or something like that.
Stef
-- Pavel
On Nov 27, 2013, at 4:29 PM, Esteban Lorenzano esteba...@gmail.com wrote:
hi,
I think is nothing to do with PackageTree but with the fact that now groups
are shown (and because of that created),
So, probably reseting the groups before unloading would do the trick.
{Nautilus.
Each group registers to event. Now I will try to unregister them all.
The problem is that there is a registration mechanism somewhere :)
Screen Shot 2013-11-29 at 10.13.30 PM.pdf
Hi esteban
I'm looking for a change due to the TreePackage introduction.
Before I could simply do something like the following to unload Nautilus
Smalltalk tools remove: #browser.
Smalltalk tools register: Browser as: #browser.
(MCWorkingCopy forPackage: (MCPackage
hi,
I think is nothing to do with PackageTree but with the fact that now groups
are shown (and because of that created),
So, probably reseting the groups before unloading would do the trick.
{Nautilus. PackageTreeNautilus} do: #resetGroups.
Esteban
On Wed, Nov 27, 2013 at 8:05 AM, Stéphane
Do you do that on an image where Nautilus was not opened? I remove Nautilus
using this script without errors.
deletePackages := [:packageNames |
SystemNavigation default removeAllButPackages: ((MCWorkingCopy
allManagers collect: #packageName) asSortedCollection copyWithoutAll:
packageNames).
2013/11/28 Hernán Morales Durand hernan.mora...@gmail.com
Hi Pavel,
El 27/11/2013 16:57, Pavel Krivanek escribió:
Do you do that on an image where Nautilus was not opened? I remove
Nautilus using this script without errors.
deletePackages := [:packageNames |
SystemNavigation default
13 matches
Mail list logo
