November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Large difference in image size when loading configuration

by Sven Van Caekenberghe

On 11 Nov 2013, at 16:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: > >> Image size goes back to: >> >> 29.068.612 >> >> Looks like all package contents are cached in the imageâ¦ > > But by a factor 3 ?? It seems that for each repository instance up to 512 (!) versions can be cached in memory (instance variable cache), including all their version info, full ancestry until the middle ages, and definitions, including source code and meta data, in the snapshot. This is really massive. The package-cache already contains this data, non-parsed, I know. Still, the in memory cache should be managed way better, using LRU or something like that. >> Phil >> >> >> >> On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Phil, what happens if you evaluate (and save after) to the big image: >> >> MCFileBasedRepository flushAllCaches. >> 3 timesRepeat: [Smalltalk garbageCollect]. >> >> >> On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> [User.Techlab] â du -hs package-cache >> 5.3M package-cache >> >> Phil >> >> On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> What is the total size of the package-cache, like du -hs ? >> Could it be the same size of the difference in image size ? >> That would mean that the contents of the packages themselves is cached in the image... >> >> On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: >> >>> I am experiencing the following while loading my configuration. >>> >>> REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main >>> ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack --install=0.4 >>> >>> Everything loads fine. >>> >>> But: >>> >>> with a package-cache/ empty, the final image is: 44.452.060 with a changes file of: 10.831.877 >>> >>> with a primed package-cache (meaning, letting the mczs in place and starting with a fresh image), the final image is: 29.480.912 with a changes file of: 10.830.899 >>> >>> That's quite a huge difference. >>> >>> I tried again to be sure (fresh image and empty package-cache, then fresh image only) and, weirdly enough, even if the difference in size was the same, the sizes themselves weren't.the same... >>> >>> 44.446.152 - 10.830.899 >>> 29.986.284 - 10.831.543 >>> >>> Maybe that's due to a GC occurring differently between the two. >>> >>> But this gives the impression that one cannot load a base image, apply a configuration, and end up with the same image twice. Weird. >>> >>> Why is this difference so large in the first place ? >>> >>> Phil >>> >>> >>> >>> >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Sven Van Caekenberghe

Nicolas, Is it currently possible to load some latest version of Xtream into Pharo 3.0 ? If yes, from which repository using which Configuration ? I know that at ESUG 2012, Sean and Martin worked a bit on getting all different versions better in sync. It would be cool if we could at least load it, separate from the transition strategy (I agree with your proposal BTW), because many people do not know or have not seen what we are actually talking about. The clean, start from scratch approach of Xtreams also includes a much tighter and semantically better defined API. IMHO, a consequence is that #get / #next and #put: / #nextPut: are not just plain aliases (a modern use of exception handling is one big difference). The compatibility layer might be more of a challenge. The biggest gain is of course if clients switch to the newer API ;-) Sven On 12 Nov 2013, at 14:31, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > It's just a matter of selecting a strategy. I've proposed two: > A) create a wrapper class for legacy Stream compatibility selectors > B) create extensions for Legacy Stream compatibility selectors > My preference goes to A) > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: ...), otherwise we will import all the cruft in Xtream and would go back to our starting point... > Once the minimal support written (a few hours should be enough), we should gradually switch each every legacy Stream usage -> Xtream. > > An area which require more work is those Streams that have mixed conventions (one portion is interpreted as text, another as binary). > In theory that's easy, we just have two streams and they both wrap on a low level binary stream, but that means we have to be very cautious with buffers and caches. > > Another area of work is usage of ugly selectors like name (we try to access the file name from the Stream API, arghh). Those usages are bad and require a rewrite. > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> or of course, you start looking at porting XStreams to pharo ;), which on the long run will >> solve many more problems. The current situation is not that satisfactory > > having experience with it and thinking about a plan for the beginning of 40 would be great. > I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice. > Stef > >

Nov. 12, 2013

Re: [Pharo-dev] PharoV20.source

by StÃ©phane Ducasse

you want as less as possible thing in the vm. Stef On Nov 12, 2013, at 8:46 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Why not to include this file in the VM? > It often happens to me that this place is wrongly placed. When this happens, Pharo just shows a white screen, without letting what is the error. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Nov. 12, 2013

Re: [Pharo-dev] Monticello SmalltalkHub no longer asks for credentials

by StÃ©phane Ducasse

sean this is strange because this morning I used my credentials in oscar image so that he can publish in the inbox and it failed systematically and I could not understand why. I do not know if this is related Now the MC permission denied did not help much On Nov 12, 2013, at 6:17 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > btc wrote >> Before logging an issue, can someone confirm that (from a least build >> #30545) saving via Monticello to Smalltalkhub does not ask for >> credentials, but just fails with MCPermissionDenied? > > This is a "feature". Before, when the dialog appeared, there was no way to > get rid of it. It would just keep coming back, over and over, until you > supplied credentials. If the dialog was important to you, please figure out > a way to have it easily cancelable for those of us who never use it... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Monticello-SmalltalkHub-no-longer-asks-for-credential… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by StÃ©phane Ducasse

On Nov 12, 2013, at 2:31 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > It's just a matter of selecting a strategy. I've proposed two: > A) create a wrapper class for legacy Stream compatibility selectors > B) create extensions for Legacy Stream compatibility selectors > My preference goes to A) if I understand correctly I prefer A too. Because like that we can decide to even throw away later the wrapper and a wrapper is like a clear API. > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: ...), otherwise we will import all the cruft in Xtream and would go back to our starting point... > Once the minimal support written (a few hours should be enough), we should gradually switch each every legacy Stream usage -> Xtream. > > An area which require more work is those Streams that have mixed conventions (one portion is interpreted as text, another as binary). > In theory that's easy, we just have two streams and they both wrap on a low level binary stream, but that means we have to be very cautious with buffers and caches. > > Another area of work is usage of ugly selectors like name (we try to access the file name from the Stream API, arghh). Those usages are bad and require a rewrite. > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> or of course, you start looking at porting XStreams to pharo ;), which on the long run will >> solve many more problems. The current situation is not that satisfactory > > having experience with it and thinking about a plan for the beginning of 40 would be great. > I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice. > Stef > >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by StÃ©phane Ducasse

On Nov 12, 2013, at 2:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > And of course, I forgot all the usages of ReadWriteStream. > I started rewriting some usage in Squeak, and good news, 95% of usage is unecessary, a WriteStream is sufficient. :) if you want to push some of these changes please do. In the past we renamed all the hardcoded names with nsStream to be able to plug another but we never went further. Stef > > > 2013/11/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > It's just a matter of selecting a strategy. I've proposed two: > A) create a wrapper class for legacy Stream compatibility selectors > B) create extensions for Legacy Stream compatibility selectors > My preference goes to A) > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: ...), otherwise we will import all the cruft in Xtream and would go back to our starting point... > Once the minimal support written (a few hours should be enough), we should gradually switch each every legacy Stream usage -> Xtream. > > An area which require more work is those Streams that have mixed conventions (one portion is interpreted as text, another as binary). > In theory that's easy, we just have two streams and they both wrap on a low level binary stream, but that means we have to be very cautious with buffers and caches. > > Another area of work is usage of ugly selectors like name (we try to access the file name from the Stream API, arghh). Those usages are bad and require a rewrite. > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> or of course, you start looking at porting XStreams to pharo ;), which on the long run will >> solve many more problems. The current situation is not that satisfactory > > having experience with it and thinking about a plan for the beginning of 40 would be great. > I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice. > Stef > > >

Nov. 12, 2013

Issue with last line / line ending between FileTree and other repositoroes

by Mariano Martinez Peck

Hi Dale, During Smalltalks, you helped me to start loading my code into GemStone. For that, we created a temp FileTree repository so that we could easily edit/save and retry the load. That saved us modifying the code elsewhere, commit, load again etc... Cool! But now I have a problem... I am trying to merge from filetree to my original repo. And when I do a diff (Monticello "Changes"), ALL methods look like modified. FileTree either: - Removed last empty lines - Changed the last dot of the last line. - Removed last space of the last line So...in summary, it is like if it has changed always the very last character (whether it is a space, a dot or an empty line). Maybe this is related to crlf I don't know. But it is a pain because it looks like I am committing 5k changes! hahaha and I cannot easily see what I have really changed. Is this a known problem? Any workaround? I will send you by private email some screenshots. Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 12, 2013

PharoV20.source

by Alexandre Bergel

Hi! Why not to include this file in the VM? It often happens to me that this place is wrongly placed. When this happens, Pharo just shows a white screen, without letting what is the error. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 12, 2013

Re: [Pharo-dev] integrated issues are still open

by Camillo Bruni

On 2013-11-12, at 19:41, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I just stumbled upon issue 12138 which was integrated in version 30565 Correction, I meant 12134, which was marked as duplicate of 12138, ok makes sense now :) > https://github.com/pharo-project/pharo-core/commit/170c9fa725fb394589d6c621… > but it is still in an open state. Is this on purpose? > If not we should quickly go over the integrated issues and check that they are all closed. > > Another thing I just saw is the the commit messages of the last 3 commits (30565 - 30567) have > a different format. Is this on purpose? > It would be very nice if they were all the same for future analysis this might be very helpful.

Nov. 12, 2013

Re: [Pharo-dev] Monticello SmalltalkHub no longer asks for credentials

by btc＠openinworld.com

Nov. 12, 2013