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

Re: [Pharo-dev] Mocking networkâ¦

by Norbert Hartl

+1 > Am 03.03.2016 um 01:16 schrieb Frank Shearar <frank.shearar(a)gmail.com>: > > 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] Mocking networkâ¦

by Yuriy Tymchuk

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] [Pharo-users] Call about Numerical Methods in Pharo :)

by Serge Stinckwich

On Thu, Mar 3, 2016 at 6:25 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Stef, > > For bioinformatics research it would be **really** nice to have: > > - Tree creation algorithms: UPGMA, WPGMA. > - MCMC methods: Metropolis-adjusted Langevin algorithm (MALA and SMMALA), > Metropolis-coupled MCMC (MC3) would enable Bayesian inferences and to work > with evolution of genes. I cannot tell how important is to have such > algorithms implemented in Smalltalk. > - Mahalanobis distance for analyzing bacterial plasmids. > - Random Forest is used a lot for gene expression, protein-protein > interaction predictions, genome-wide association studies, etc . For the > argument "let's use FFI for it" please remember many of these methods are > extended, like enriched random forest, for research with specialized data. Can you add enhancement issues in the SciSmalltalk issue tracker : https://github.com/SergeStinckwich/SciSmalltalk/issues in order to keep them in mind ? We are trying to create a pure Smalltalk library, so we try to avoid FFI as much as possible :-) > There are implementations of naive Bayes classifier in NaturalSmalltalk > (which could be adapted to SciPharo) > http://smalltalkhub.com/#!/~hernan/NaturalSmalltalk Great, if we can move them to SciSmalltalk. > As a side note I found an interesting history report of SciPy. > From the slide 9 onwards: > > http://sssslide.com/www.slideshare.net/shoheihido/sci-pyhistory > > Presentation shows SciPy history (credited contributors with pictures, very > nice!). > As you can se they even have a Foundation NumFOCUS for raising money. For sure, money always help ;-) The only problem at the moment is that the Pharo community is much smaller at the moment than the Python one. Thank you for your help. -- 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 Serge Stinckwich

On Wed, Mar 2, 2016 at 11:39 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi ! > >> - 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 :) > > This is an excellent initiative! > I personally need the following: > - Shapiro-Wilk test to check for data normality > - Kruskal-Wallis to analyze differences in median values between samples > - Bonferroni-Dunn to support multiple comparison and controlling the group error rate > - Mann-Whitney U test is a nonparametric statistical test that operates over two samples of the same size. Great list ! At the moment, there is only Kolmogorov-Smirnov test implemented. Can you create issues in the SciSmalltalk issue tracker in order to keep track of your needs ? The issue tracker is here: https://github.com/SergeStinckwich/SciSmalltalk/issues You can also join the SciSmalltalk mailing-list: https://groups.google.com/forum/#!forum/scismalltalk Thank you Alex. -- 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 HernÃ¡n Morales Durand

Hi Stef, For bioinformatics research it would be **really** nice to have: - Tree creation algorithms: UPGMA, WPGMA. - MCMC methods: Metropolis-adjusted Langevin algorithm (MALA and SMMALA), Metropolis-coupled MCMC (MC3) would enable Bayesian inferences and to work with evolution of genes. I cannot tell how important is to have such algorithms implemented in Smalltalk. - Mahalanobis distance for analyzing bacterial plasmids. - Random Forest is used a lot for gene expression, protein-protein interaction predictions, genome-wide association studies, etc . For the argument "let's use FFI for it" please remember many of these methods are extended, like enriched random forest, for research with specialized data. There are implementations of naive Bayes classifier in NaturalSmalltalk (which could be adapted to SciPharo) http://smalltalkhub.com/#!/~hernan/NaturalSmalltalk As a side note I found an interesting history report of SciPy. >From the slide 9 onwards: http://sssslide.com/www.slideshare.net/shoheihido/sci-pyhistory Presentation shows SciPy history (credited contributors with pictures, very nice!). As you can se they even have a Foundation NumFOCUS for raising money. HernÃ¡n 2016-03-02 10:17 GMT-03:00 stepharo <stepharo(a)free.fr>: > 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 > > >

March 3, 2016

Re: [Pharo-dev] Mocking networkâ¦

by Chris Muller

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] Mocking networkâ¦

by Frank Shearar

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 Nicolas Cellier

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 ;) 2016-03-03 0:56 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 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... > > > >> >> -- >> View this message in context: >> http://forum.world.st/TextConverter-is-broken-tp4882039p4882095.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

March 3, 2016

Re: [Pharo-dev] TextConverter is broken

by Nicolas Cellier

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... > > -- > View this message in context: > http://forum.world.st/TextConverter-is-broken-tp4882039p4882095.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 2, 2016

Re: [Pharo-dev] sprites for games

by Alexandre Bergel

That would be fantasticâ¦. Alexandre > On Mar 2, 2016, at 11:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Yeah this is very good. Even better, this is sponsored by the LPC and new graphic materials under Creative Commons and other open licenses are released every year for this format. > > I think a generic binding to the png generated on this web site would be lovely. I'd love to add cast animations to my wizard game made in Pharo :-). I have only death and movement animations right now. It's a few hours of work only to integrate in the game I guess. > > One thing is that I would like to see the animations in GTInspector like it is possible top right of this web page and I don't know how to have a tab in GTInspector which refreshes itself at 60fps like I do on my Cairo surfaces on SDL windows (In fact on Cairo + SDL I can have 180fps on my game at maximum rate, but it's only 2D graphics, based on the profiler I am close to the maximum optimization potential of the current Pharo code and some frames are dropped from time to time due to GC). > > > > 2016-03-02 15:33 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > hey wow! who'd a thought such a thing existed. > cheers -ben > > On Wed, Mar 2, 2016 at 9:33 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > > > clement shows me this website > > > > http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/ > > > > and we could use them for building a fun game framework > > > > > > Stef > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2016