April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] RefsHunter

by Max Leske

YESSSS!!!! (insert *micdrop*) > On 19 Apr 2016, at 15:44, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > when we were trying to fix memory leaks in the system in last weeks, it was very handy to create a small tool that shows a shortest path of backward references from one object to another one. Our tool is named RefsHunter and you can find it in the Catalog of Pharo 5. > > You can use Gofer if you want to load it without tests to the minimal Pharo: > > Gofer new > smalltalkhubUser: 'PavelKrivanek' project: 'RefsHunter'; > package: 'RefsHunter-Core'; > load. > > The RefsHunter creates a temporary snapshot of all objects in the image and then collects information about all non-weak backward references. After that you can ask on the shortest path from one object to another one. That is useful for example when you still have got some leaking instance in the image and you want to see how is it linked with the global space. > > Example: > > | rh | > rh := RefsHunter snapshot. > rh wayFrom: (Array>>#asArray) to: Smalltalk specialObjectsArray. > > Notice that this tool is very memory demanding and it is not good idea to make a new RefsHunter snapshot when you still have some previous snapshot in the object memory. > > Cheers, > -- Pavel

April 19, 2016

Re: [Pharo-dev] [HELP WANTED] Pre-release "First impressions count" round starting

by Damien Cassou

Esteban Lorenzano <estebanlm(a)gmail.com> writes: > So, Iâm asking for reports and fixes and improvements that are not > bugfixes (even if been bug-free is the best first impression we can > have) but you believe is needed to cause a good first sight of this > release. an up-to-date Ubuntu PPA is important for anyone using Ubuntu. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 19, 2016

Re: [Pharo-dev] Add download+uncompress behavior to Metacello?

by stepharo

packaged them first :) Stef Le 19/4/16 15:14, HernÃ¡n Morales Durand a Ã©crit : > > Is there a chance to get this methods (or any better versions of them) > added to Metacello? > > >>extractZip: fileRef in: dst > " If fileRef is a ZIP archive, uncompress its contents in dst and > delete it " > > | zipArchive | > (fileRef fullName endsWith: '.zip') > ifFalse: [ ^ self ]. > zipArchive := ZipArchive new. > [ zipArchive > readFrom: fileRef fullName; > extractAllTo: dst ] > ensure: [ zipArchive close ]. > fileRef delete > > > >>extractGZip: fileRef in: dst > " If fileRef is a ZIP archive, uncompress its contents in dst and > delete it " > > | unzipped | > (fileRef fullName endsWith: '.gz') > ifFalse: [ ^ self ]. > unzipped := GZipReadStream unzip: fileRef basename to: dst. > (Smalltalk hasClassNamed: #OSProcess) > ifTrue: [ > (Smalltalk at: #OSProcess) thisOSProcess > waitForCommandOutput: 'tar xvf ' , unzipped asFileReference fullName. > fileRef delete. > unzipped asFileReference delete ] > > >>uncompress: fileRef > " Private - Uncompress fileRef to the current working directory " > > | dst | > dst := FileSystem workingDirectory. > self extractZip: fileRef in: dst. > self extractGZip: fileRef in: dst. > > >>downloadResourcesFrom: urlString > " Private - Download files from urlString " > > ^ [ ZnEasy get: urlString ] > on: ZnEntityTooLarge > do: [ : ex | ex resume ]. > > > I use them to download external resources for my projects as follows: > > First I add a #preLoadDoIt: send in my baseline: > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec preLoadDoIt: #preLoad. > .... > > >>preLoad > > | url fileRef response | > > self logCr: '====== Downloading my resource files...'. > url := self platformFilesUrl asZnUrl. > fileRef := FileSystem disk workingDirectory / url pathSegments last. > (response := self downloadResourcesFrom: url) isSuccess > ifTrue: [ > self logCr: '====== Writing resource file...'. > fileRef writeStreamDo: [ : stream | stream nextPutAll: > response contents ] ] > ifFalse: [ self error: 'Cannot download data files' ]. > self logCr: '====== Uncompressing files...'. > self uncompress: fileRef. > > HernÃ¡n >

April 19, 2016

Re: [Pharo-dev] [Ann] New version of Mocketry 3.0

by Tudor Girba

Hi, > On Apr 6, 2016, at 6:13 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-06 14:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Just the English does not sound quite well for statements like: > mock should got someMessage > mock should not got anotherMessage. > > I know that there was a long discussion about naming these. I do not remember the outcome, but still I think other alternatives would be better: > mock should haveReceived someMessage. > mock should not haveReceived anotherMessage. > or even > mock shouldnt haveReceived anotherMessage. > > You right. There was discussion and I made decision :) > Some of people suggest "should got" which is very short version and I like it. I know it is not completely correct from English perspective but it is readable enough and understandable. It is your prerogative :), but âshould got" sounds broken :(. > #shouldnt can be good. But usually we not use "should not" assertions. Only when we really want to deny certain condition we write it such way. In that cases full form of "should not" feels better for me. > But it is always personal choice. So I made decision. (many my tests uses "should not" :)) I think âshould not" sounds fine like it is. Cheers, Doru > I think I would favor: > mock stub someMessage toReturn: 1000. > or > mock stub someMessage returns: 1000. > > What do you think? > > Same here. > Mocketry is very old and it was always idea of will:. You can also put block for expected action: > mock stub someMessage will: [#yourResult]. > (mock stub someMessageWith: Any) will: [:arg | arg + 1]. > -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

April 19, 2016

Re: [Pharo-dev] unzip:to:

by stepharo

Le 19/4/16 15:41, Valentin Ryckewaert a Ã©crit : > How does unzip:to: access to the file ? I do not get your question? > It must be in the workingDirectory? Read the code luke.... unzip: fullFileName to: pathString "Unzip the contents of the file specified by the full path name fullFileName to the location given by pathString." | zipped buffer unzipped newName | newName := fullFileName copyUpToLast: FileSystem disk extensionDelimiter. pathString asFileReference ensureCreateDirectory. unzipped := FileStream newFileNamed: (pathString asFileReference / newName) fullName. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unzipped ifNil: [self error: pathString, ' looks incorrect']. [ unzipped binary. zipped := self on: (FileStream readOnlyFileNamed: fullFileName). buffer := ByteArray new: 50000. [zipped atEnd] whileFalse: [unzipped nextPutAll: (zipped nextInto: buffer)]] ensure: [ zipped close. unzipped close]. ^ newName > > > 2016-04-19 15:06 GMT+02:00 HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: > > I use it a lot to uncompress external resources like this: > > fileRef := .... > GZipReadStream unzip: fileRef basename to: FileSystem > workingDirectory. > > but it could be used to pass a directory as String I guess. > Comment should be corrected. > > > 2016-04-19 9:54 GMT-03:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > unzip: fullFileName to: pathString > "Unzip the contents of the file specified by the full path > name fullFileName to the location given by pathString." > > so we would expect to pass a string in the second argument? > > the unique sender of it in the system > > unzip: fullFileName > "Unzip the contents of a gzipped file specified by its > full file name to the current working directory" > > ^ self unzip: fullFileName to: FileSystem disk > workingDirectory > > > but the implementation seems to indicate that fullFileName is > should be a string as well as pathString > > unzip: fullFileName to: pathString > "Unzip the contents of the file specified by the full path > name fullFileName to the location given by pathString." > > | zipped buffer unzipped newName | > newName := fullFileName copyUpToLast: FileSystem disk > extensionDelimiter. > pathString asFileReference ensureCreateDirectory. > unzipped := FileStream newFileNamed: (pathString > asFileReference / newName) fullName. > unzipped ifNil: [self error: pathString, ' looks incorrect']. > [ unzipped binary. > zipped := self on: (FileStream readOnlyFileNamed: > fullFileName). > buffer := ByteArray new: 50000. > [zipped atEnd] whileFalse: [unzipped nextPutAll: (zipped > nextInto: buffer)]] > ensure: [ > zipped close. > unzipped close]. > ^ newName > > Am I correct to think that the comments are not really good > enough? > > Stef > > > > >

April 19, 2016

[ANN] RefsHunter

by Pavel Krivanek

Hi, when we were trying to fix memory leaks in the system in last weeks, it was very handy to create a small tool that shows a shortest path of backward references from one object to another one. Our tool is named RefsHunter and you can find it in the Catalog of Pharo 5. You can use Gofer if you want to load it without tests to the minimal Pharo: Gofer new smalltalkhubUser: 'PavelKrivanek' project: 'RefsHunter'; package: 'RefsHunter-Core'; load. The RefsHunter creates a temporary snapshot of all objects in the image and then collects information about all non-weak backward references. After that you can ask on the shortest path from one object to another one. That is useful for example when you still have got some leaking instance in the image and you want to see how is it linked with the global space. Example: | rh | rh := RefsHunter snapshot. rh wayFrom: (Array>>#asArray) to: Smalltalk specialObjectsArray. Notice that this tool is very memory demanding and it is not good idea to make a new RefsHunter snapshot when you still have some previous snapshot in the object memory. Cheers, -- Pavel

April 19, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Sven Van Caekenberghe

You might want to read https://medium.com/concerning-pharo/lampsort-revisited-visualised-6652055ef… that discusses object logging and what you can do with it. My take on this is that if you write your code to produce log events (as Announcements), you can do whatever you want in the end. There is no real need to depend on some framework. > On 19 Apr 2016, at 15:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Beacon is being used systematically. We even said we will integrate it in the image for Pharo 5 at the end of last year, but after the agitated start of the year, I did not push it anymore to not increase the level of agitation. > > The only class name that encountered some opposition was BoundedBeacon. > > We also agreed that the only things we want from SystemLogger were the concrete connections to external storage. This was not done, but the idea was that we should first integrate them and then allow people to extend it with bindings to external storage. > > I use Beacon on a regular basis, and I extended it recently with a couple of more Signal types that can capture exceptions and stack information. You now also have a better integration in the inspector to be able to start/pause an in-memory log stream. In the process I also added the possibility to remove Announcements from an AnnouncementSet and I would like to push this in Pharo 6.0. One thing I would work on is to add to Annoucements the possibility of filtering announcements based on instances not just types. This is a longer term plan. > > Another thing to do is to ensure that the log signals are not expensive to create. For example, the ExceptionSignal, ContextStackSignal and MethodStackSignal manipulate thisContext right at creation time, while this should happen only when we actually capture it in a BoundedBeacon to manipulate/store it in a specific way. This part should be refined. > > @Dennis: it would be great to join efforts. The two frameworks look similar, but there are 2 significant differences: > 1. SystemLogger has its own log events propagation mechanism, Beacon uses Announcements. > 2. SystemLogger relies on levels of filtering, Beacon uses the mechanisms from Announcements to pick and choose at a fine grain level which log signals should be logged. > > For reference: > - description: http://www.humane-assessment.com/blog/beacon/ > - repository: http://www.smalltalkhub.com/#!/~Pharo/Beacon > > Cheers, > Doru > > >> On Apr 19, 2016, at 2:59 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 18/4/16 18:28, Denis Kudriashov a Ã©crit : >>> Hello. >>> >>> Year ago Beacon and SystemLogger were announced. There was big discussion about them. And there were plans to provide single solution. What was done around that? >> >> Nothing. We should have done it at Cambridge and we just discussed. >> I did not like some Beacon class names because they are totally confusing. >>> >>> What exactly should be merged between this libraries? Was Beacon or SystemLogger planned to be end solution? >> We planned to merge SystemLogger into Beacon to use announcements >>> We definitely need legacy logging tool for Pharo. And I am going to work on this direction. >>> Personally I prefer metaphor and names from Beacon. But both libraries implement similar idea. >> Remember that you want to have them short especially for the main one. This is why in SystemLogger >> we have Log instead of what it is LogObject if I remember correctly. >>> >>> Best regards, >>> Denis >> >> > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > >

April 19, 2016

Re: [Pharo-dev] unzip:to:

by Valentin Ryckewaert

How does unzip:to: access to the file ? It must be in the workingDirectory? 2016-04-19 15:06 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > I use it a lot to uncompress external resources like this: > > fileRef := .... > GZipReadStream unzip: fileRef basename to: FileSystem workingDirectory. > > but it could be used to pass a directory as String I guess. > Comment should be corrected. > > > 2016-04-19 9:54 GMT-03:00 stepharo <stepharo(a)free.fr>: > >> unzip: fullFileName to: pathString >> "Unzip the contents of the file specified by the full path name >> fullFileName to the location given by pathString." >> >> so we would expect to pass a string in the second argument? >> >> the unique sender of it in the system >> >> unzip: fullFileName >> "Unzip the contents of a gzipped file specified by its full file name >> to the current working directory" >> >> ^ self unzip: fullFileName to: FileSystem disk workingDirectory >> >> >> but the implementation seems to indicate that fullFileName is should be a >> string as well as pathString >> >> unzip: fullFileName to: pathString >> "Unzip the contents of the file specified by the full path name >> fullFileName to the location given by pathString." >> >> | zipped buffer unzipped newName | >> newName := fullFileName copyUpToLast: FileSystem disk >> extensionDelimiter. >> pathString asFileReference ensureCreateDirectory. >> unzipped := FileStream newFileNamed: (pathString asFileReference / >> newName) fullName. >> unzipped ifNil: [self error: pathString, ' looks incorrect']. >> [ unzipped binary. >> zipped := self on: (FileStream readOnlyFileNamed: fullFileName). >> buffer := ByteArray new: 50000. >> [zipped atEnd] whileFalse: [unzipped nextPutAll: (zipped nextInto: >> buffer)]] >> ensure: [ >> zipped close. >> unzipped close]. >> ^ newName >> >> Am I correct to think that the comments are not really good enough? >> >> Stef >> >> >> >> >

April 19, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Tudor Girba

Hi, Beacon is being used systematically. We even said we will integrate it in the image for Pharo 5 at the end of last year, but after the agitated start of the year, I did not push it anymore to not increase the level of agitation. The only class name that encountered some opposition was BoundedBeacon. We also agreed that the only things we want from SystemLogger were the concrete connections to external storage. This was not done, but the idea was that we should first integrate them and then allow people to extend it with bindings to external storage. I use Beacon on a regular basis, and I extended it recently with a couple of more Signal types that can capture exceptions and stack information. You now also have a better integration in the inspector to be able to start/pause an in-memory log stream. In the process I also added the possibility to remove Announcements from an AnnouncementSet and I would like to push this in Pharo 6.0. One thing I would work on is to add to Annoucements the possibility of filtering announcements based on instances not just types. This is a longer term plan. Another thing to do is to ensure that the log signals are not expensive to create. For example, the ExceptionSignal, ContextStackSignal and MethodStackSignal manipulate thisContext right at creation time, while this should happen only when we actually capture it in a BoundedBeacon to manipulate/store it in a specific way. This part should be refined. @Dennis: it would be great to join efforts. The two frameworks look similar, but there are 2 significant differences: 1. SystemLogger has its own log events propagation mechanism, Beacon uses Announcements. 2. SystemLogger relies on levels of filtering, Beacon uses the mechanisms from Announcements to pick and choose at a fine grain level which log signals should be logged. For reference: - description: http://www.humane-assessment.com/blog/beacon/ - repository: http://www.smalltalkhub.com/#!/~Pharo/Beacon Cheers, Doru > On Apr 19, 2016, at 2:59 PM, stepharo <stepharo(a)free.fr> wrote: > > > > Le 18/4/16 18:28, Denis Kudriashov a Ã©crit : >> Hello. >> >> Year ago Beacon and SystemLogger were announced. There was big discussion about them. And there were plans to provide single solution. What was done around that? > > Nothing. We should have done it at Cambridge and we just discussed. > I did not like some Beacon class names because they are totally confusing. >> >> What exactly should be merged between this libraries? Was Beacon or SystemLogger planned to be end solution? > We planned to merge SystemLogger into Beacon to use announcements >> We definitely need legacy logging tool for Pharo. And I am going to work on this direction. >> Personally I prefer metaphor and names from Beacon. But both libraries implement similar idea. > Remember that you want to have them short especially for the main one. This is why in SystemLogger > we have Log instead of what it is LogObject if I remember correctly. >> >> Best regards, >> Denis > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

April 19, 2016

Re: [Pharo-dev] [HELP WANTED] Pre-release "First impressions count" round starting

by Esteban A. Maringolo

I am an eternal newcomer, so count me in. Regards! Esteban A. Maringolo 2016-04-19 10:25 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I will start the âfirst impressions countâ round for this release. > For those who donât know what Iâm talking about, is a small cycle of improvements onâ¦ well, âfirst impressionsâ a newbie will have when downloading Pharo for a first time. > > So, Iâm asking for reports and fixes and improvements that are not bugfixes (even if been bug-free is the best first impression we can have) but you believe is needed to cause a good first sight of this release. > > This does not means everything will be implemented (no time for everything) but I want to collect your ideas/proposals/etc. > > thanks, > Esteban

April 19, 2016