October 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Codepage 437

by Norbert Hartl

Thanks Sven. I'll look into this soon and will provide feedback. Norbert > Am 20.10.2015 um 18:38 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > I added the following: > > === > Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.41 > Author: SvenVanCaekenberghe > Time: 20 October 2015, 6:35:23.106957 pm > UUID: c6b0b265-827d-439b-b241-81bce4c56dc3 > Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.40 > > Introduction of ZnByteEncoder class>>#newFromUrl: > Refactoring introduced #top123FromUnicodeSpec: > === > Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.23 > Author: SvenVanCaekenberghe > Time: 20 October 2015, 6:36:04.004228 pm > UUID: 265ff0e3-85df-47d2-8821-f9979aca15a0 > Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.22 > > Added ZnCharacterEncoderTests>>#testByteEncoderFromUrl > === > > So now you can do > > ZnByteEncoder newFromUrl: 'http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT'. > > But you better cache that instance somewhere. > > Sven > > On 20 Oct 2015, at 16:07, stepharo <stepharo(a)free.fr> wrote: >> >> >> Excellent! >> You rock sven! >> >> Le 20/10/15 14:22, Sven Van Caekenberghe a Ã©crit : >>> Norbert, >>> >>>> On 20 Oct 2015, at 14:11, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Is there any way to read a codepage 437 encoded file with pharo? >>>> >>>> thanks, >>>> >>>> Norbert >>> This could be done with ZnByteEncoder, but that encoding is not provided by default. So you need to generate a new mapping method, luckily this can be done automagically: >>> >>> ZnByteEncoder generateByteToUnicodeSpec: 'http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT'. >>> >>> Put it on the class side and plug it in #mappingToIdentifiers and #initialize again. I guess you maybe could provide a one-shot instance, but I have never done that and adding it as known encoding will be easier at first. >>> >>> I am sure you will figure it out ;-) >>> >>> Let me know how it goes, maybe it would be a good idea to allow one-shot encoder instances based just on a spec from unicode.org >>> >>> Sven >>> >>> >>> >> >> > >

Oct. 22, 2015

Re: [Pharo-users] Feedback on #assert: vs. #assert:equals:

by stepharo

Le 22/10/15 12:03, Peter UhnÃ¡k a Ã©crit : > This is why I pretty much stopped using #assert: altogether, > however note that sometimes it is better to avoid boolean completely, > because the feedback of it is low > > Imagine: > > self assert: collection isEmpty > > versus > > self assert: collection size equals: 0 > > versus > > self assert: collection asArray equals: #() > > > The first one is in my opinion easiest to read and understand it's > purpose, but if the test fails it provides the least amount of > feedback, while the last one is complete opposite - hardest to read, > but if it fails provides most of the feedback. > > So you need to look to strike a balance, however I do agree that > `#assert: nonBoolean` should be a failing test and not an error. +1 > > Peter > > > On Thu, Oct 22, 2015 at 3:21 AM, Nahuel Garbezza <n.garbezza(a)gmail.com > <mailto:n.garbezza@gmail.com>> wrote: > > Hi everyone, > > I'm using Pharo for teaching and we use TDD since the beginning. > I've noticed that if you use #assert: on a test, like this: > > self assert: object messageReturningBoolean > > It gives you strange results in terms of feedback if the result is > not a boolean. I would expect an AssertionFailed (yellow test) but > I got a NonBooleanReceiver (red test). > > What we do in our course is to write the assertion like this: > > self assert: object messageReturningBoolean equals: true > > So we got a "expected true but was <other object>" error which is > a lot more helpful to the students. > > I was thinking that is better to have #assert: implementation > based on #assert:equals:. It is like saying #assert:equals: is the > "primitive" assertion message, which makes sense to me since you > are always comparing if an object is equal to another, there's no > reason to handle the booleans' case differently. > > What do you think? > > Thank you! > > Nahuel > >

Oct. 22, 2015

Re: [Pharo-users] Feedback on #assert: vs. #assert:equals:

by Peter UhnÃ¡k

This is why I pretty much stopped using #assert: altogether, however note that sometimes it is better to avoid boolean completely, because the feedback of it is low Imagine: self assert: collection isEmpty versus self assert: collection size equals: 0 versus self assert: collection asArray equals: #() The first one is in my opinion easiest to read and understand it's purpose, but if the test fails it provides the least amount of feedback, while the last one is complete opposite - hardest to read, but if it fails provides most of the feedback. So you need to look to strike a balance, however I do agree that `#assert: nonBoolean` should be a failing test and not an error. Peter On Thu, Oct 22, 2015 at 3:21 AM, Nahuel Garbezza <n.garbezza(a)gmail.com> wrote: > Hi everyone, > > I'm using Pharo for teaching and we use TDD since the beginning. I've > noticed that if you use #assert: on a test, like this: > > self assert: object messageReturningBoolean > > It gives you strange results in terms of feedback if the result is not a > boolean. I would expect an AssertionFailed (yellow test) but I got a > NonBooleanReceiver (red test). > > What we do in our course is to write the assertion like this: > > self assert: object messageReturningBoolean equals: true > > So we got a "expected true but was <other object>" error which is a lot > more helpful to the students. > > I was thinking that is better to have #assert: implementation based on > #assert:equals:. It is like saying #assert:equals: is the "primitive" > assertion message, which makes sense to me since you are always comparing > if an object is equal to another, there's no reason to handle the booleans' > case differently. > > What do you think? > > Thank you! > > Nahuel >

Oct. 22, 2015

Re: [Pharo-users] Artefact and WideString

by Sven Van Caekenberghe

> On 22 Oct 2015, at 11:14, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 21/10/2015 22:26, olivier auverlot a Ã©crit : >> Hi Hilaire, >> >> Take a look in the Artefact demos. I think there are a PDF document >> with a monetary character. >> > > Indeed ((128 asCharacter) asString). I am pretty sure this is wrong. The Unicode code point for the Euro symbol is decimal 8364 and not 128. https://en.wikipedia.org/wiki/Euro_sign > But this character does not print > on the web with Unicode encoding. > Unified support will be great, object with EURO symbol could be printed > as is both in Seaside and Artefact. > So not sure what's wrong. > > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > >

Oct. 22, 2015

Re: [Pharo-users] Fossil and Filetree

by Thierry Goubier

2015-10-22 11:16 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Le 22/10/2015 10:47, Thierry Goubier a Ã©crit : > > Still, with all the people interested by Fossil, I think the > > motivation is there. And it would be nice to see a bit of refactoring > > to decouple the format from the specific commands used for the > > specific VCS. > > > Decoupling was my first though looking at the code. So it makes it > bigger than a small hack as initially though ;) > Of course ;) It started as a small hack and has grown a bit since... Thierry > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > >

Oct. 22, 2015

Re: [Pharo-users] Fossil and Filetree

by Hilaire

Le 22/10/2015 10:47, Thierry Goubier a Ã©crit : > Still, with all the people interested by Fossil, I think the > motivation is there. And it would be nice to see a bit of refactoring > to decouple the format from the specific commands used for the > specific VCS. > Decoupling was my first though looking at the code. So it makes it bigger than a small hack as initially though ;) Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 22, 2015

Re: [Pharo-users] Artefact and WideString

by Hilaire

Le 21/10/2015 22:26, olivier auverlot a Ã©crit : > Hi Hilaire, > > Take a look in the Artefact demos. I think there are a PDF document > with a monetary character. > Indeed ((128 asCharacter) asString). But this character does not print on the web with Unicode encoding. Unified support will be great, object with EURO symbol could be printed as is both in Seaside and Artefact. So not sure what's wrong. Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 22, 2015

Re: [Pharo-users] Fossil and Filetree

by Thierry Goubier

2015-10-22 10:40 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Le 21/10/2015 22:03, Thierry Goubier a Ã©crit : > > > > Just use the ConfigurationOfGitFileTree available in your > > Configuration browser in the image ;) > > > > Or > > > > Metacello new > > configuration: 'GitFileTree'; > > repository: > > 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main'; > > load > > > > Thierry > > Okay, thanks. > Not sure I can handle it right now, there are a lot of know-how about > git and fossil implicated. > Yes, I guess so. Still, with all the people interested by Fossil, I think the motivation is there. And it would be nice to see a bit of refactoring to decouple the format from the specific commands used for the specific VCS. Thierry > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > >

Oct. 22, 2015

Re: [Pharo-users] Fossil and Filetree

by Hilaire

Le 21/10/2015 22:03, Thierry Goubier a Ã©crit : > > Just use the ConfigurationOfGitFileTree available in your > Configuration browser in the image ;) > > Or > > Metacello new > configuration: 'GitFileTree'; > repository: > 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main'; > load > > Thierry Okay, thanks. Not sure I can handle it right now, there are a lot of know-how about git and fossil implicated. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 22, 2015

Smalltalk Meetup in ZÃ¼rich: Nov 10, 2015

by Joachim Tuchel

Dear Smalltalk fans in the ZÃ¼rich area, if you happen to have a free slot in your calendars for November 10th, 2015 (I guess 19:30 will be a good time to start), I have something for you: We would like to get together with Smalltalkers of all flavors to chat about the latest news, tools and projects at a restaurant near Bahnhof HardbrÃ¼cke, like we did several times in 2014. I think it's time to catch up and I know Peter, Philippe and Michal feel the same. So please send me a note and let me know if you'd like to join us for an evening of Smalltalk... I'll reserve a table and let you know exactly where we meet. If you are not in the ZÃ¼rich area but don't mind travelling to meet us, feel free to come! Hope to see you soon in ZÃ¼rich! Joachim

Oct. 22, 2015