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

CollectionValueHolder ValueAdded ValueRemoved

by Peter UhnÃ¡k

This is something that was discussed some time ago but never resolved. To summarize: When working with CollectionValueHolder one can only see whether the collection as a whole changed and not how, e.g. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ col := OrderedCollection new asValueHolder. col add: 1. col add: 2. col add: 3. col add: 4. col whenChangedDo: [ :c :changedValue | 1halt. ]. "col = #(1 2 3 4)" col add: 4. "whenChangedDo: c = col, changedValue = 4" col remove: 4. "whenChangedDo: c = col, changedValue = 4" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the last two cases the changedValue is the same so I can't tell from the block if the value was added or removed. My proposition: * introduce (at least) two more Announcements: ValueAdded and ValueRemoved * add messages #whenAddedDo:/#whenChangedDo: * maybe add #when:do: so it can be used as an announcable object (valueHolder when: ValueSomething do: [ :ann | ... ]) The ValueAdded/ValueRemoved would be fired when an item is added, resp. removed. Thierry also proposed to add an index (I'd make it optional). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ col whenAddedDo: [ :col :addedValue :optionalIndex | "here we know for sure that value was added" ]. col whenRemovedDo: [ :col :addedValue :optionalIndex | "here we know for sure that value was removed" ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Finally Thierry mentioned a way to handle situations where values are replaced (either single one or multiple ones). As this is edge use-case and the current behavior is pretty much random I wouldn't address the replacement unless a defined use case emerges. Any thoughts, Peter

March 3, 2016

Re: [Pharo-dev] Mocking networkâ¦

by Skip

Yes I agree. The way I test the GitHub API now is by running a local server which returns my JSON representation.. I looked at other API bindings to GitHub written in ruby to find an approach for testing[1]. A nice feature I saw there was recording requests in a "Cassette". This way you run your requests once "live", and afterwards everything can be done offline 1: https://github.com/peter-murach/github#7-testing 2016-03-03 9:01 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Look guys, > > I know that you can start a super smart discussion about the approaches to > test network-related stuff. > > But my question was super simple. If Iâm writing something that accesses > github I can write a test for handling request limit error. And in ruby I > can say: âok in this test when you get a request to https://githubâ¦â¦â¦â¦/SomePathThatITest > hive a response with this number and this headersâ. And then I can test the > result. If I cannot do this in Pharo, then I will not test it, itâs that > easy. > > Cheers. > Uko > > > On 03 Mar 2016, at 03:53, Chris Muller <ma.chris.m(a)gmail.com> wrote: > > > > I use a framework designed for testing network programs. Depending on > > the test, it launches 3-5 "player" copies of the image solely for > > participation in the tests. The controlling image runs the unit > > tests, which each send their dance of rpc messages to the players to > > make them run the tests in a controlled fashion. > > > > The failure tests involve setting a boolean flag in the server image > > that causes it to execute "Smalltalk quitPrimitive" from a place deep > > in the system -- i.e., at one place in mid disk-write, to exercise the > > recovery code. > > > > This approach to testing network programs is heavier-weight than a > > mock and doesn't integrate well with the SUnit browser. But it does > > provide me a comfortable context that assures me it really does work > > over the network. Back then, I was wanting to learn and practice my > > TCP socket programming anyway, so it was hard for me to allocate time > > to learning a mock which.. at the end of the day, I knew, would nag me > > to wonder whether my program would really work over the network for > > real. > > > > > > On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >> Er. How do you reliably inject arbitrary network faults in your > >> localhost network again? > >> > >> frank > >> > >> On 2 March 2016 at 08:27, Chris Muller <asqueaker(a)gmail.com> wrote: > >>> A mock network will never test as thoroughly as locahost network.. > >>> > >>> 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 3, 2016

A question about the Dark Theme main background color

by Sven Van Caekenberghe

I know that colours are a matter of taste, but I have a question about the Dark Theme main background color. Here is a screenshot of my 4.0 image: Versus the same in 5.0 Note how the background of the contents of windows is much darker, the contrast being very hard. Was this an intentional change ? Does the majority prefer that colour ? How can I change it back to the softer one ? Thx, Sven BTW: Also note how much less space there is for the real code (yes I use pretty large fonts, but they are the same in both), how much space is lost in decoration around code in Nautilus, how busy it looks ... just my opinion.

March 3, 2016

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

by Serge Stinckwich

On Thu, Mar 3, 2016 at 10:43 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > Hi, > > That's a very good idea. > For now, I use a Pharo-R binding to make the statistics, but it is better if it is directly in the image. > > For my part, it should be nice to have: > - Principal Component Analysis > - Time series I already a very simple time series class. What kind of operations you want to do on time series ? > - Correlation with several variables (Correlation matrix) + significance tests (pearson, spearman...) > - Standard statistical tests: normality, variance, mean, distribution > - And the more important is to have nice tools to visualize the data (Box plot, histogram, scatterplots, PCA ones) with a simple API for standard things but that we can customize. The best is that we are able to draw regression lines on them. But I think that is more a Roassal part. You have to ask Alex to the viz :-) Please join the SciSmalltalk ml in order to express your needs ;-) -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 3, 2016

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

by Blondeau Vincent

Hi, That's a very good idea. For now, I use a Pharo-R binding to make the statistics, but it is better if it is directly in the image. For my part, it should be nice to have: - Principal Component Analysis - Time series - Correlation with several variables (Correlation matrix) + significance tests (pearson, spearman...) - Standard statistical tests: normality, variance, mean, distribution - And the more important is to have nice tools to visualize the data (Box plot, histogram, scatterplots, PCA ones) with a simple API for standard things but that we can customize. The best is that we are able to draw regression lines on them. But I think that is more a Roassal part. Thanks for the initiative, Cheers, Vincent > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de > stepharo > EnvoyÃ© : mercredi 2 mars 2016 14:17 > Ã : Pharo Development List; Any question about pharo is welcome; Didier > Besset; Souissi Sami > Objet : [Pharo-users] Call about Numerical Methods in Pharo :) > > 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) > > - 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. > > - 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 :) > > > Stef > !!!************************************************************************************* "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

March 3, 2016

Re: [Pharo-dev] Mocking networkâ¦

by Denis Kudriashov

Hi. I just want to mention another interesting opportunity for mocking network. In past we built system which retrieves information from various web services without documentation about data formats and protocols. We created mock library which caches retrieved information from first calls and then in test we got network responses without internet requests. By demand we ran tests with empty cache to check that all services not change their protocols. It was really boost our productivity. It will be nice to get such feature in Pharo. 2016-03-03 9:01 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Look guys, > > I know that you can start a super smart discussion about the approaches to > test network-related stuff. > > But my question was super simple. If Iâm writing something that accesses > github I can write a test for handling request limit error. And in ruby I > can say: âok in this test when you get a request to https://githubâ¦â¦â¦â¦/SomePathThatITest > hive a response with this number and this headersâ. And then I can test the > result. If I cannot do this in Pharo, then I will not test it, itâs that > easy. > > Cheers. > Uko > > > On 03 Mar 2016, at 03:53, Chris Muller <ma.chris.m(a)gmail.com> wrote: > > > > I use a framework designed for testing network programs. Depending on > > the test, it launches 3-5 "player" copies of the image solely for > > participation in the tests. The controlling image runs the unit > > tests, which each send their dance of rpc messages to the players to > > make them run the tests in a controlled fashion. > > > > The failure tests involve setting a boolean flag in the server image > > that causes it to execute "Smalltalk quitPrimitive" from a place deep > > in the system -- i.e., at one place in mid disk-write, to exercise the > > recovery code. > > > > This approach to testing network programs is heavier-weight than a > > mock and doesn't integrate well with the SUnit browser. But it does > > provide me a comfortable context that assures me it really does work > > over the network. Back then, I was wanting to learn and practice my > > TCP socket programming anyway, so it was hard for me to allocate time > > to learning a mock which.. at the end of the day, I knew, would nag me > > to wonder whether my program would really work over the network for > > real. > > > > > > On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >> Er. How do you reliably inject arbitrary network faults in your > >> localhost network again? > >> > >> frank > >> > >> On 2 March 2016 at 08:27, Chris Muller <asqueaker(a)gmail.com> wrote: > >>> A mock network will never test as thoroughly as locahost network.. > >>> > >>> 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 3, 2016

Re: [Pharo-dev] TextConverter is broken

by Max Leske

Thank you everyone for the explanations. How would you feel about opening an issue for Pharo 6 to remove TextConverter? > On 03 Mar 2016, at 01:04, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > In other words Max, if you correctly invoke > > MacRomanTextConverter initializeLatin1MapAndEncodings. > > Then the old converter retrieves a good health. > Now that you know that, you can remove the old converters and keep Zn modernized ones ;) That does indeed fix the problem. > > 2016-03-03 0:56 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: > > > 2016-03-02 23:16 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Not sure I'd say Squeak's (5.0 at least) MacRoman conversion is free of bugs > either, at least the "legacy" ByteTextConverter subclass in Pharo passes the > following: > > "U+0152, Latin capital ligature OE is codepoint 16rCE in mac-roman" > ((Character value: 16r0152) asString convertToEncoding: 'mac-roman') first > charCode = 16rCE. > > "Codepoint 170 in MacRoman is TM sign, U+2122" > ((Character value: 170) asString convertFromEncoding: 'mac-roman') first > charCode = 16r2122. > > Cheers, > Henry > > > > Yes, you're right, it's because squeak tables did and still use CP1252 instead of ISO8859-L1 and thus do not match unicode. That might have made sense when porting from mac to windows while keeping ByteString, but at least since the switch to unicode that's bogus. I guess it's still here because some in image fonts would support cp1252 but I am too tired to check it now... > > My mistake is that character unicode 216 -> MacRoman was already false in Pharo 1.1. > It was false because Pharo picked a a bogus table manually crafted from the internet pages (from Sophie project?) > > Then Sven did correct the table by automagically decoding the url... > But this didn't correct anything because the initializeLatin1MapAndEncodings was never invoked (it was missing already in Pharo 1.1). > Unfortunately, those maps are a speed-up cache and will mask the correction of table if not updated. > > In Squeak, initializeLatin1MapAndEncodings was called from class side initialization right from the beginning, but this was forgotten during the port to Pharo, that would be interesting to know why... > > Ah yes, lazy initialization made it work without the need for class initialization, but that was a one shot gun, not robust to further table changes, that's the drawback of being lazy. > > So, most probably code was too complex and this is enough to explain the mistakes. > Why was it too complex? > Because it was an optimization for speed (fast scanning of bytes NOT NEEDING ANY conversion). > And the initialization was too much convoluted because it was reusing convoluted multilngual API. > My feeling is that it's an effect of the "least possible change that could possibly extend functionality". > > For me, it's never enough to say "old converters were broken". > There's allways to learn from one mistake and that's why I'm asking. > My feeling is that Pharo guys allways sprint and never look behind. > This is at the risk of repeating some mistake... > > > > -- > View this message in context: http://forum.world.st/TextConverter-is-broken-tp4882039p4882095.html <http://forum.world.st/TextConverter-is-broken-tp4882039p4882095.html> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > >

March 3, 2016

Little how to

by stepharo

Hi guys for the mooc I would like have a list of how to that students should look in the system and implement. The idea is to show to the participants that Pharo is open and that they can find information. For example, - extracting a sprite from a png file - access a time service of the web Now I would love to get your ideas and their solution. Stef

March 3, 2016

Re: [Pharo-dev] TextConverter is broken

by Sven Van Caekenberghe

> On 03 Mar 2016, at 00:56, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2016-03-02 23:16 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > Not sure I'd say Squeak's (5.0 at least) MacRoman conversion is free of bugs > either, at least the "legacy" ByteTextConverter subclass in Pharo passes the > following: > > "U+0152, Latin capital ligature OE is codepoint 16rCE in mac-roman" > ((Character value: 16r0152) asString convertToEncoding: 'mac-roman') first > charCode = 16rCE. > > "Codepoint 170 in MacRoman is TM sign, U+2122" > ((Character value: 170) asString convertFromEncoding: 'mac-roman') first > charCode = 16r2122. > > Cheers, > Henry > > > > Yes, you're right, it's because squeak tables did and still use CP1252 instead of ISO8859-L1 and thus do not match unicode. That might have made sense when porting from mac to windows while keeping ByteString, but at least since the switch to unicode that's bogus. I guess it's still here because some in image fonts would support cp1252 but I am too tired to check it now... > > My mistake is that character unicode 216 -> MacRoman was already false in Pharo 1.1. > It was false because Pharo picked a a bogus table manually crafted from the internet pages (from Sophie project?) > > Then Sven did correct the table by automagically decoding the url... > But this didn't correct anything because the initializeLatin1MapAndEncodings was never invoked (it was missing already in Pharo 1.1). > Unfortunately, those maps are a speed-up cache and will mask the correction of table if not updated. > > In Squeak, initializeLatin1MapAndEncodings was called from class side initialization right from the beginning, but this was forgotten during the port to Pharo, that would be interesting to know why... > > Ah yes, lazy initialization made it work without the need for class initialization, but that was a one shot gun, not robust to further table changes, that's the drawback of being lazy. > > So, most probably code was too complex and this is enough to explain the mistakes. > Why was it too complex? > Because it was an optimization for speed (fast scanning of bytes NOT NEEDING ANY conversion). > And the initialization was too much convoluted because it was reusing convoluted multilngual API. > My feeling is that it's an effect of the "least possible change that could possibly extend functionality". > > For me, it's never enough to say "old converters were broken". > There's allways to learn from one mistake and that's why I'm asking. > My feeling is that Pharo guys allways sprint and never look behind. > This is at the risk of repeating some mistake... Yes, it was a bit cheap to say the old ones were broken, I just tried with the new ones and saw that there was no problem there (luckily ;-); of course this little bug is fixable. However, the old ones are bad/broken in many ways: semantics, api, behaviour, error handling, lack of functionality, hacked implementation. Also, the new ones have already been around for many years in Zn and have been in use ever since to do any and all HTTP encoding/decoding in Pharo since 1.3. Now, it is not easy to replace one for the other at the lower levels, due to the (intentional/by-design) API differences. The high level view is well explained in the first part of the Character Encoding and Resource Meta Description chapter of the Enterprise Pharo book (http://files.pharo.org/books/enterprisepharo/book/Zinc-Encoding-Meta/Zinc-E…) Sven

March 3, 2016

Re: [Pharo-dev] Mocking networkâ¦

by Norbert Hartl

I think that is one of the good points. If I test an interface of sending an request and getting a response I'm not interested in network stuff. I want to test my software and not my network stack. And I like to force errornous behavior in order to test error handling of my software. Finally I want to habe reliable tests which is hard to achieve if you allocate system resources. That means I don't want to randomly shuffle port numbers and hope it doesn't clash if tests are executed in parallel. It is just that mocks are hard to apply. Norbert > Am 02.03.2016 um 22:15 schrieb Chris Muller <ma.chris.m(a)gmail.com>: > > 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 3, 2016