- Pharo-dev - lists.pharo.org

[Pharo5] Status: 23 open issues

by marcus.denker＠inria.fr

Hi, There are now 23 open issues tagged for Milestone âPharo5â. https://pharo.fogbugz.com/f/filters/125/5-0-All The plan is to release in 2 weeks. Please check if - all these issues are real show-stoppers. The idea is that e.g. everything that was already a problem in Pharo4 can not be a showstopper, as we did release Pharo4â¦ - Did you report an issue that is not listed here? New issues are do now pre-fill the form with âPharo6â, but then, if an issue was reported e.g. last week and nobody realised it was in the wrong milestone, I guess it can be said that this issue by default is not a show-stopperâ¦ - If you have this âobviousâ bug that is so obvious that you did not even report it: Keep in mind that it will *not* be fixed as we do not know about it. It does not exist. Marcus

April 20, 2016

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

by Henrik Johansen

> On 20 Apr 2016, at 9:54 , Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Apr 20, 2016, at 9:37 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> >>> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> 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. >> AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. >> Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. > > The fact that AnnouncementSet is a Set is actually debatable because it basically reuses the implementation, not the type. I agree, it would be better if AnnouncementSet didn't inherit the full Set API. > Indeed, Set does allow for removing items, but I was referring to excluding items which is a slightly different use case (like is the case for Exceptions). Ah, exclusions are a different matter from removal, that sounds like a good change indeed! My point was, messing with the subscription to alter what is being delivered outside of registration/de-registration, would lead to hard(er)-to-understand code; that's would not be the case for exclusions like: announcer when: SuperAnnouncement - SpecificAnnouncementImNotInterestedIn do: [:ann | ... ] Cheers, Henry

April 20, 2016

Re: [Pharo-dev] unzip:to:

by Damien Cassou

Valentin Ryckewaert <valentin.ryckewaert(a)gmail.com> writes: > Hello, > > I understood the problem with pathString and I'm ok with your opinion but I > would like to come back on the first one "fullfilename" as I understand it, > it must be a basename ? > When I read the implementation with fullfilename which would be a path > '/aPath/foo.zip'. > > newName := fullFileName copyUpToLast: FileSystem disk extensionDelimiter. > newName would be in that case : /aPath/foo' > > unzipped := FileStream newFileNamed: (pathString asFileReference / newName) > fullName. > Here the newFileNamed: parameter will be '/aPathDestination/aPath/foo' so > it could be something like '/home/home/foo' it's not correct according to > me. > > As I understand it, this message only works if fullFileName is 'foo.zip' > and is in the folder which contain Pharo image as we can't specify a path. I agree with Valentin. I have the impression this method can only unzip files in the working directory. That's a bit strange :-). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 20, 2016

Re: [Pharo-dev] unzip:to:

by Valentin Ryckewaert

Hello, I understood the problem with pathString and I'm ok with your opinion but I would like to come back on the first one "fullfilename" as I understand it, it must be a basename ? When I read the implementation with fullfilename which would be a path '/aPath/foo.zip'. newName := fullFileName copyUpToLast: FileSystem disk extensionDelimiter. newName would be in that case : /aPath/foo' unzipped := FileStream newFileNamed: (pathString asFileReference / newName) fullName. Here the newFileNamed: parameter will be '/aPathDestination/aPath/foo' so it could be something like '/home/home/foo' it's not correct according to me. As I understand it, this message only works if fullFileName is 'foo.zip' and is in the folder which contain Pharo image as we can't specify a path. Valentin 2016-04-19 20:40 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 19/4/16 15:53, Valentin Ryckewaert a Ã©crit : > > I mean, fileRef basename is myZip.zip and workingDirectory is the place > files will go after being unziped but how does we find the file named > fileRef basename ? > > > > 'foo.txt' asFileReference -> a fileRef > > 'foo.txt' asFileReference basename. > > (FileSystem disk workingDirectory / 'foo.txt') basename > > this is explained in the File chapter. > > > Can you open a bug entry to improve the comment of the method? > > > 2016-04-19 15:46 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> >> 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>: >> >>> 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>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 20, 2016

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

by Tudor Girba

Hi, > On Apr 20, 2016, at 9:37 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> 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. > AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. > Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. The fact that AnnouncementSet is a Set is actually debatable because it basically reuses the implementation, not the type. Indeed, Set does allow for removing items, but I was referring to excluding items which is a slightly different use case (like is the case for Exceptions). > IMHO, if the logic is "I want to handle this announcement some of the time", that is much easier to understand if handled explicitly in announcement handling code, rather than through state changes to the announcement delivery. I disagree. I have a project which has about 50 different signals, and I am interested in all but one. Listing all 49 would be impractical and not particularly clear. Furthermore, when you have inheritance, it becomes even more complicated. You have the same case with exceptions and there we allow exclusions for good reasons. > As I think Glamour is a poster child for, current usage patterns can already be hard to follow ;) I do not understand this statement in the context of this email. Cheers, Doru > Cheers, > Henry -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

April 20, 2016

Re: [Pharo-dev] About CommentPane

by lb

Hi, Serge, Nice to meet you. Welcome to China again, I live in shanghai. pudong new area. Best Regards! Bing Liang

April 20, 2016

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

by Henrik Johansen

> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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. AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. IMHO, if the logic is "I want to handle this announcement some of the time", that is much easier to understand if handled explicitly in announcement handling code, rather than through state changes to the announcement delivery. As I think Glamour is a poster child for, current usage patterns can already be hard to follow ;) Cheers, Henry

April 20, 2016

Re: [Pharo-dev] About CommentPane

by Serge Stinckwich

Nice to see you again Bing Liang :-) We interact some months ago. BTW, where are you located in China ? I will made a short stop next week at Hong Kong. Welcome in the Pharo community. See you On Wed, Apr 20, 2016 at 12:05 PM, lb <liangbing64(a)126.com> wrote: > The commentPane is opened, when package is changed, the commentPane > should > > 1. be closed > 2. be empty > 3. or still keep old content ? (current state) > > > Cheers > > Bing Liang > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 20, 2016

Re: [Pharo-dev] About CommentPane

by lb

Hi, Stef, Thank you. I come from shanghai china and study Pharo for several years. I want to write some my own language comment , so i wrote a tool for me. the comment text pane and my comment pane need to switch. so I ask this silly question. Pharo 5.0 I used. Best Regards! Bing Liang

April 20, 2016

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

by stepharo

Le 19/4/16 15:46, Tudor Girba a Ã©crit : > 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 :(. +1 :) > >> #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 20, 2016