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

Re: [Pharo-dev] Mocking networkâ¦

by Norbert Hartl

> Am 02.03.2016 um 17:27 schrieb Chris Muller <asqueaker(a)gmail.com>: > > A mock network will never test as thoroughly as locahost network.. > Why? Please elaborate! Norbert > On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you donât want to rely on a network availability or test certain corner cases. >> >> Is there anything like this in Pharo? >> >> Uko >

March 2, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alexandre Bergel

> Experimenting with that I found Object>>veryDeepCopy with DeepCopier, and that lot of classes implements veryDeepCopyWith: deepCopier > Also it seems that it handles several cases without hanging ... > Do you have any opinion or advices on that ? > Did you use it ? I would do a recursive copy with a fixed amount of recursion. So, this is not a shallowCopy, and not a deepCopy, but somewhere in between. And the end user can decide. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2016

Re: [Pharo-dev] TextConverter is broken

by Sven Van Caekenberghe

All the ZnByteEncoders are automagically initialised from official specs, for MacRoman self generateByteToUnicodeSpec: 'http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT' > On 02 Mar 2016, at 21:09, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2016-03-02 20:18 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Max, > > > On 02 Mar 2016, at 19:57, Max Leske <maxleske(a)gmail.com> wrote: > > > > Just so I donât forget: this test fails (since at least 1.3). I have determined the correct value (175) independently with the respective tables and by using uconv. > > > > testConversionToFrom > > self assert: (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: 'mac-roman') = 'Ã¤Ã¶Ã¼'. > > self > > assert: ((Character value: 216) asString convertToEncoding: 'mac-roman') > > equals: (Character value: 175) asString > > > > As far as I can tell, this flaw is not exclusive to the mac-roman encoding. However, latin1 and UTF8 are probably fine. > > > > Max > > That is because you are using the wrong encoders. > > | encoder string | > encoder := #macroman asZnCharacterEncoder. > string := 'Ã¤Ã¶Ã¼'. > (encoder decodeBytes: (encoder encodeString: string)) = string. " => true" > encoder encodeString: (Character value: 216) asString. " => #[175]" > > We should probably replace the old ones with the newer ones in Pharo 6. > > Regards, > > Sven > > +1, why the hell maintaining two versions, one bogus? > > However, since this does not seem broken in Squeak, that makes a perfect example for investigating how and why such trivial error creeps in. > >

March 2, 2016

Re: [Pharo-dev] TextConverter is broken

by Nicolas Cellier

2016-03-02 20:18 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Max, > > > On 02 Mar 2016, at 19:57, Max Leske <maxleske(a)gmail.com> wrote: > > > > Just so I donât forget: this test fails (since at least 1.3). I have > determined the correct value (175) independently with the respective tables > and by using uconv. > > > > testConversionToFrom > > self assert: (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') > convertFromEncoding: 'mac-roman') = 'Ã¤Ã¶Ã¼'. > > self > > assert: ((Character value: 216) asString > convertToEncoding: 'mac-roman') > > equals: (Character value: 175) asString > > > > As far as I can tell, this flaw is not exclusive to the mac-roman > encoding. However, latin1 and UTF8 are probably fine. > > > > Max > > That is because you are using the wrong encoders. > > | encoder string | > encoder := #macroman asZnCharacterEncoder. > string := 'Ã¤Ã¶Ã¼'. > (encoder decodeBytes: (encoder encodeString: string)) = string. " => true" > encoder encodeString: (Character value: 216) asString. " => #[175]" > > We should probably replace the old ones with the newer ones in Pharo 6. > > Regards, > > Sven > +1, why the hell maintaining two versions, one bogus? However, since this does not seem broken in Squeak, that makes a perfect example for investigating how and why such trivial error creeps in.

March 2, 2016

Re: [Pharo-dev] TextConverter is broken

by Sven Van Caekenberghe

Max, > On 02 Mar 2016, at 19:57, Max Leske <maxleske(a)gmail.com> wrote: > > Just so I donât forget: this test fails (since at least 1.3). I have determined the correct value (175) independently with the respective tables and by using uconv. > > testConversionToFrom > self assert: (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: 'mac-roman') = 'Ã¤Ã¶Ã¼'. > self > assert: ((Character value: 216) asString convertToEncoding: 'mac-roman') > equals: (Character value: 175) asString > > As far as I can tell, this flaw is not exclusive to the mac-roman encoding. However, latin1 and UTF8 are probably fine. > > Max That is because you are using the wrong encoders. | encoder string | encoder := #macroman asZnCharacterEncoder. string := 'Ã¤Ã¶Ã¼'. (encoder decodeBytes: (encoder encodeString: string)) = string. " => true" encoder encodeString: (Character value: 216) asString. " => #[175]" We should probably replace the old ones with the newer ones in Pharo 6. Regards, Sven

March 2, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 29/02/2016 09:27, Alexandre Bergel wrote: > Having a solid Design by Contract mechanism is notoriously difficult to have. What you can do, is to have a shallow copy for now. If necessary, you may have a bounded deep copy. But do not use #deepCopy. They are many objects where you cannot do a #deepCopy, because it will copy the whole image, and it does not handle cycles. Hi Alexandre Thank you for your response, and sorry for responding late, I couldn't take time, my bad. Yes you are definitely right, design by contract implementation is difficult, there is lot of papers and research done by brilliant people on the subject, that's why I classified this work under POC on the readme page of smalltalkhub. I have no pretention to do a perfect dbc implmentation, I just want to see at first stage if a simple implementation based on the MetaLink can work. And it currently works, with some limitations : no returned value support, no old value support (for now), and some work to do on pragma syntax (like postconditionOf: suggested by Stef). I should be able to work on those points in few weeks. About old value support, right, no doubt that deepCopy will not work, but a shallow copy will certainly not pass checks too . Experimenting with that I found Object>>veryDeepCopy with DeepCopier, and that lot of classes implements veryDeepCopyWith: deepCopier Also it seems that it handles several cases without hanging ... Do you have any opinion or advices on that ? Did you use it ? Thanks -- Alain

March 2, 2016

Re: [Pharo-dev] Pharo Days 2016 Registration is open

by philippe.back＠highoctane.be

Working on it. Some more pictures http://www.exozt.be/?page_id=6 On Mar 2, 2016 7:24 PM, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> wrote: > Is there some list of recommended hotels like there was last year? > > Peter > > On Wed, Mar 2, 2016 at 5:34 PM, stepharo <stepharo(a)free.fr> wrote: > >> People from namur told me that the place is really cool. >> Good choice Phil. >> >> Stef >> >> Le 2/3/16 09:38, Sven Van Caekenberghe a Ã©crit : >> >> Registration for the Pharo Days 2016 is now open ! >>> >>> We are using EventBrite. You can buy tickets using PayPal and any credit >>> card. If absolutely necessary, you can opt for an off line payment. Please >>> register on time. >>> >>> http://www.eventbrite.com/e/pharo-days-2016-tickets-22454533113 >>> >>> For social registration you can use Doodle. >>> >>> http://doodle.com/poll/rsc86cqzxbgwr9tr >>> >>> Spread the word: http://pharodays2016.pharo.org. >>> >>> >> >> >

March 2, 2016

TextConverter is broken

by Max Leske

Just so I donât forget: this test fails (since at least 1.3). I have determined the correct value (175) independently with the respective tables and by using uconv. testConversionToFrom self assert: (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: 'mac-roman') = 'Ã¤Ã¶Ã¼'. self assert: ((Character value: 216) asString convertToEncoding: 'mac-roman') equals: (Character value: 175) asString As far as I can tell, this flaw is not exclusive to the mac-roman encoding. However, latin1 and UTF8 are probably fine. Max

March 2, 2016

Re: [Pharo-dev] [Pharo-users] Call about Numerical Methods in Pharo :)

by Serge Stinckwich

On Wed, Mar 2, 2016 at 2:17 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I met Didier Besset and we had a great hacking session and discussions with > Serge Stinckwich. > Didier would like to help Pharo and the numerical part of it. ***Big > thanks*** Didier. > > We would like to do several things: > > - Work on "Hows to" > The numerical methods in Pharo is good but the gap between us and the > math is too large :) > so the idea is to have a series of "how to ..." > - histomgram (simple, based on distribution) Yes this is important to have more exemples, because they are a lot of > - Improve the SciPharo/NumPha (previously SciSmalltalk) library > > This morning we started to implement a ComponentPrincipalDecomposition > by combining two of the > objects available in SciPharo. :-) > Then we started to enhance the distributions to make sure that we > can plug other distribution for having > controlled random number. Ok, did you commit the code ? > - Do a public call to know what is missing for you: this is this mail :) > Didier would like to work on concrete cases. I love that attitude > So tell us :) > > Hernan ?? > Alex: ?? pvalue? better distribution? > Vincent: covariance? CPA? > Philippe: times series > Serge R frames? > Sami: Better random number and various distributions? > > - Organise a two day lectures with practices on concrete case in > September with a recording session. > Either at IRD Bondy or Lille. > > - Make sure that the Numerical Method book will get on lulu :) with a > better cover and title :) Thank you Stef for pushing ! Can we move this discussion of the SciSmalltalk mailing-list ? -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 2, 2016

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

by Serge Stinckwich

On Wed, Mar 2, 2016 at 7:11 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > SciPharo? Not so great news from my POV. > What is so much pharo specific in this library? > Is Smalltalk scientific community large enough for yet another split? We can think of a more neutral name. Any idea for a new name ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 2, 2016