- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TextConverter is broken

by Henrik Sperre Johansen

There was a bug in the old byteToUnicodeSpec tables (missing 2's in some of the latter entries, one of which should have been 16e02D8). So initializeLatin1MapAndEncodings erroneously picked that over the correct D8. In a modern image, Sven has fixed the byteToUnicodeSpec (They're parsed directly from the Unicode site, so at least the hope is they are correct, at least), but the cache tables have not been updates, one can do this by executing: ByteTextConverter initialize. ByteTextConverter allSubclassesDo: [:each | each initializeLatin1MapAndEncodings]. Cheers, Henry -- View this message in context: http://forum.world.st/TextConverter-is-broken-tp4882039p4882079.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 2, 2016

Re: [Pharo-dev] Mocking networkâ¦

by Chris Muller

I assume the mock object does not exercise any real network code or primitives. On Wed, Mar 2, 2016 at 2:43 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> 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] Mocking networkâ¦

by Stephan Eggermont

On 02/03/16 17:27, Chris Muller wrote: > A mock network will never test as thoroughly as localhost network. Based on the posts of @danLuu and @aphyr I would say there is a lot to be said for mocking the network & file system. https://aphyr.com http://danluu.com/file-consistency/ Stephan

March 2, 2016

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