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

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Denis Kudriashov

2016-11-01 20:45 GMT+01:00 Attila Magyar <m.magyar3(a)gmail.com>: > Yes, it has different tradeoffs. For example you have to fill in the > parameters even if you want to ignore them, or it is difficult (maybe > impossibe) to express a parameter matcher that considers the relationship > of > multiple arguments (for example /allow: mock recv: #a:b:; with: [:a :b | a > > > b]/). > If you don't care about parameters you can use Any: socket stub connectTo: Any port: Any waitForConnectionFor: Any. Last case is a bit tricky of course but possible: mock stub a: [:arg1 | a := arg1. true] b: [:b | a > b] And it is easy to extend Mocketry for string based scenario: mock stub message: #a:b: with: [:a :b | a > b]. But I don't see value for this.

Nov. 2, 2016

Re: [Pharo-dev] Taskit multiple images?

by Denis Kudriashov

2016-11-02 10:38 GMT+01:00 Guille Polito <guillermopolito(a)gmail.com>: > Hi Uko, > > Short answer is: No, not yet. This is something we would like to do but I > cannot find the time to do it for real yet. > But you you start your cluster project?

Nov. 2, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60275 Home: https://github.com/pharo-project/pharo-core

Nov. 2, 2016

[pharo-project/pharo-core] 29d7cc: 60275

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 29d7cc8d305658489faca8484153d27fde23acfa https://github.com/pharo-project/pharo-core/commit/29d7cc8d305658489faca848… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: R Kernel.package/Object.class/instance/user interface/modelWakeUp.st M Kernel.package/Object.class/instance/user interface/modelWakeUpIn_.st R Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/modelWakeUp.st A Morphic-Widgets-Windows.package/extension/PasteUpMorph/instance/modelWakeUpIn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60274.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60275.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60274.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60275.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Finder.package/MethodFinder.class/instance/initialize/initialize.st M Traits.package/TClass.class/instance/copying/duplicateClassWithNewName_.st Log Message: ----------- 60275 19264 Coping a class using a Trait does not copy the Trait usage. https://pharo.fogbugz.com/f/cases/19264 19235 Remove Object>>#modelWakeUp https://pharo.fogbugz.com/f/cases/19235 http://files.pharo.org/image/60/60275.zip

Nov. 2, 2016

Re: [Pharo-dev] Let's talk with Dr Metacello: Moving Pharo to Github

by Guille Polito

Hi all again, Dale prepared a couple of slides for the discussion. We shared the slides in dropbox. Link is the following: https://www.dropbox.com/s/pxnme1wih60ud5e/Pharo%20Sources%20in%20Git.pdf?dl… So there are two probable paths from here: - Either we continue on discord and we try to follow the slides ourselves, - Or, depending on the number of people that is there, we may move it to skype where we can do screen sharing. Just to agilize it a bit, if you were willing to participate you can add me on skype: guillermopolito. See you on discord in a couple of of hours, Guille -------- Original Message -------- > Hi all, > > We arranged with Dale a public discussion on discord *this wednesday > at 8am PDT (15h Paris)*. The idea is to discuss about the alternatives > to store the Pharo sources in Git. > > Dale is already working on git since a couple of years, > > - he made has already experimented on a project using git submodules [1] > - he is managing the GSDevKit/GLASS project in a kind of ad-hoc > fashion (from what I understood in the discussion and looking at the > repo...) [2] > > I was analyzing a bit the pros and cons of git submodules and git > subtrees [3] > > The idea is that we discuss about these alternatives, we learn from > the experience of Dale, and try to define some points about the > architecture of Pharo source-code's storage in the future. > > See you there, > > [1] https://github.com/dalehenrich/amber-skeleton > <https://github.com/dalehenrich/amber-skeleton> > [2] https://github.com/GsDevKit/GsDevKit_home > <https://github.com/GsDevKit/GsDevKit_home> > [3] > https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-pro… > > > >

Nov. 2, 2016

Re: [Pharo-dev] Taskit multiple images?

by Guille Polito

Hi Uko, Short answer is: No, not yet. This is something we would like to do but I cannot find the time to do it for real yet. Guille -------- Original Message -------- > Hi, is it possible to compute data really really concurrently with Taskit by using multiple images? Because while doing some analysis I need to do boring computations on big collections and processing a collection concurrently can speedup things a lot. > > Uko

Nov. 2, 2016

Re: [Pharo-dev] Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}

by Sven Van Caekenberghe

> On 2 Nov 2016, at 07:37, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Impressive , Cuis has 13 times less classes than Pharo. Maybe I should give it a closer look afterall. Cuis is quite nice, impressive even. Ideal for learning and then some. But don't be fooled: it lacks lots and lots of things that you take for granted in Pharo. > Pity that does not translate well in hard disk space. Pharo 6 is 100mbs Cuis is just 70mbs. The VM alone is 50 mbs. > > On Wed, Nov 2, 2016 at 1:38 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Setting the Playground contents, yeah, I see what you mean. The old Workspace worked better there. > > I disagree with your view on the modularity. > > And Cuis is nice indeed (and the UI is fast) - https://github.com/Cuis-Smalltalk-Learning/Learning-Cuis shows the number of classes. Definitely less than Pharo. > > But it is not boostrap anything, sorry. It is the same code that has dependencies all over. Ok it is kind of a minimal image but not something one can call bootstrap. > > Check the original intent: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-January/118… > > So, starting from an empty object memory. That is important to have. So that we can rebuild in other ways. > > Phil > > > > On Tue, Nov 1, 2016 at 9:21 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I was trying just yesterday to do something super simple, change the contents of Playground via code. I used the inspector to navigate , I ended up running around and accomplish zero. > > Bootstraping will never make Pharo easy. Bootstraping is for making it smaller and more modular. Completely different thing. > > Pharo is super hard to hack because many of its APIs even for new tools like GTPlayground are huge pile of mess. The spaggetification of the Pharo image is beyond repair and needs a complete rewrite. But that is not going to happen any time this decade or the next. So for now we will have to compromise with the idea that Pharo code is hard and it will keep getting harder the more features are added even if the packages are reduced. > > On the other hand I am ok with hard code, as long as it gets the job done. > > Plus there was always a bootstraped "Pharo", Cuis, Wanna see how minimal and clean code looks like , take a deep look in Cuis, its a beauty. But Cuis is nowhere near as popular as Pharo. People prefer features over simplicity and , unfortunately , you cannot have both. I am willing to bet that we will still choose big Pharos image even when bootstrap becomes a reality. Its as if there is a lot of room to move here, most of the libraries inside Pharo are crucial to the system, others are very useful for user interaction. > > Unless of course we follow the example of Cuis and decided to reduce the features of Pharo, but I suspect that wont have many supporters. > > So yes its nice to have this extra options, no it wont make Pharo code much simpler. > > On Tue, Nov 1, 2016 at 9:39 PM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Bootstrapping is needed to escape the big ball of mud that the current image is. > It is already much much much better than Pharo 1x. > Having a smaller core can iron out a lot of issues and make it super stable. > And decouple the various parts. That is no small feat indeed. > And frankly it is super hard to understand how the whole thing actually works internally with all the stuff we have inside. > I see bootstrapping as being able to extract the nuclear core from the current vehicle and be able to inject it into new forms. > > Phil > > > On Tuesday, 1 November 2016, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > We already have a ton of ready made image in CI that pharolauncher has access to and it is very easy to build your own. I build my own images regularly with a makefile and startup script. You can do a lot of neat tricks with those two combinations. > > Because my image grows quite large lately I was thinking maybe make an image builder with pharo. Nothing fancy just a basic GUI that will ask me questions what I want to build and I can tick which image I want inside and let it run in the background. Essentially replacing both my makefile and my startup script. So far though I cannot say I really need it > > Why a test would corrupt the image, that makes no sense. I am using Pharo 5 years now and I did not have a single corrupted image, ever. > > Also about the claim that Pharo is "the best TDD" first time I heard that. What makes a system best for TDD ? its not as if TDD is anything sophisticated or even something new. The only difference is that lately it went from being a library to being a religion. > > You may compare Ruby all you want with Pharo but then that gives me motivation to compare Ruby with Python . Ruby basically has Ruby on Rails and then.... nothing. Great language , lousy library system. > > Bootstrapping is more than welcomed but I am sorry to say that , its not that important. > > You wanna proof , take a look at Python, huge library and coders love it. Actually the huge size of its library was always its best selling point. Python is pretty much everywhere nowdays and there is nothing stopping it. Not that is a surprise Python always prioritised minimalism and ease of use over amount of features , something desperately needed in todays incredible complex software demands. >

Nov. 2, 2016

Re: [Pharo-dev] Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}

by Dimitris Chloupis

Impressive , Cuis has 13 times less classes than Pharo. Maybe I should give it a closer look afterall. Pity that does not translate well in hard disk space. Pharo 6 is 100mbs Cuis is just 70mbs. The VM alone is 50 mbs. On Wed, Nov 2, 2016 at 1:38 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Setting the Playground contents, yeah, I see what you mean. The old > Workspace worked better there. > > I disagree with your view on the modularity. > > And Cuis is nice indeed (and the UI is fast) - > https://github.com/Cuis-Smalltalk-Learning/Learning-Cuis shows the number > of classes. Definitely less than Pharo. > > But it is not boostrap anything, sorry. It is the same code that has > dependencies all over. Ok it is kind of a minimal image but not something > one can call bootstrap. > > Check the original intent: > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-January/118… > > So, starting from an empty object memory. That is important to have. So > that we can rebuild in other ways. > > Phil > > > > On Tue, Nov 1, 2016 at 9:21 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > I was trying just yesterday to do something super simple, change the > contents of Playground via code. I used the inspector to navigate , I ended > up running around and accomplish zero. > > Bootstraping will never make Pharo easy. Bootstraping is for making it > smaller and more modular. Completely different thing. > > Pharo is super hard to hack because many of its APIs even for new tools > like GTPlayground are huge pile of mess. The spaggetification of the Pharo > image is beyond repair and needs a complete rewrite. But that is not going > to happen any time this decade or the next. So for now we will have to > compromise with the idea that Pharo code is hard and it will keep getting > harder the more features are added even if the packages are reduced. > > On the other hand I am ok with hard code, as long as it gets the job done. > > Plus there was always a bootstraped "Pharo", Cuis, Wanna see how minimal > and clean code looks like , take a deep look in Cuis, its a beauty. But > Cuis is nowhere near as popular as Pharo. People prefer features over > simplicity and , unfortunately , you cannot have both. I am willing to bet > that we will still choose big Pharos image even when bootstrap becomes a > reality. Its as if there is a lot of room to move here, most of the > libraries inside Pharo are crucial to the system, others are very useful > for user interaction. > > Unless of course we follow the example of Cuis and decided to reduce the > features of Pharo, but I suspect that wont have many supporters. > > So yes its nice to have this extra options, no it wont make Pharo code > much simpler. > > On Tue, Nov 1, 2016 at 9:39 PM phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > Bootstrapping is needed to escape the big ball of mud that the current > image is. > It is already much much much better than Pharo 1x. > Having a smaller core can iron out a lot of issues and make it super > stable. > And decouple the various parts. That is no small feat indeed. > And frankly it is super hard to understand how the whole thing actually > works internally with all the stuff we have inside. > I see bootstrapping as being able to extract the nuclear core from the > current vehicle and be able to inject it into new forms. > > Phil > > > On Tuesday, 1 November 2016, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > We already have a ton of ready made image in CI that pharolauncher has > access to and it is very easy to build your own. I build my own images > regularly with a makefile and startup script. You can do a lot of neat > tricks with those two combinations. > > Because my image grows quite large lately I was thinking maybe make an > image builder with pharo. Nothing fancy just a basic GUI that will ask me > questions what I want to build and I can tick which image I want inside and > let it run in the background. Essentially replacing both my makefile and my > startup script. So far though I cannot say I really need it > > Why a test would corrupt the image, that makes no sense. I am using Pharo > 5 years now and I did not have a single corrupted image, ever. > > Also about the claim that Pharo is "the best TDD" first time I heard that. > What makes a system best for TDD ? its not as if TDD is anything > sophisticated or even something new. The only difference is that lately it > went from being a library to being a religion. > > You may compare Ruby all you want with Pharo but then that gives me > motivation to compare Ruby with Python . Ruby basically has Ruby on Rails > and then.... nothing. Great language , lousy library system. > > Bootstrapping is more than welcomed but I am sorry to say that , its not > that important. > > You wanna proof , take a look at Python, huge library and coders love it. > Actually the huge size of its library was always its best selling point. > Python is pretty much everywhere nowdays and there is nothing stopping it. > Not that is a surprise Python always prioritised minimalism and ease of use > over amount of features , something desperately needed in todays incredible > complex software demands. > > >

Nov. 2, 2016

Re: [Pharo-dev] [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Mariano Martinez Peck

Thanks Esteban, If tomorrow you confirm it, please let me know. Cheers, On Tue, Nov 1, 2016 at 3:49 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I think it already got inside in the development branch (still not the > official one). > I will check better tomorrow. > > Esteban > > On 1 Nov 2016, at 16:34, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi Holger, Esteban, et all > > What is the status of https://github.com/pharo-project/pharo-vm/pull/108 > ? > Will this be finally integrated or not? Because I updated OSSubprocess to > take benefit of this PR (OSSubprocess is much better with this PR), but I > will have to revert it if the PR is not merged :( > > Thanks, > > > > > > On Fri, Sep 23, 2016 at 5:40 AM, Holger Freyther <holger(a)freyther.de> > wrote: > >> >> > On 23 Sep 2016, at 02:44, Ronie Salgado <roniesalg(a)gmail.com> wrote: >> > >> > Hi Holger, >> >> Hi! >> >> >> > Currently the events given by this API are only holding a copy of the >> raw inotify event in rawEvent and a copy of the raw path in rawPath. >> Further work is required for translating the events into a more platform >> independent interface, and for supporting OS X and Windows with this API. >> However, this is already something that could be useful to you. >> >> if I see it correctly you start a poll loop (wait 100ms then call epoll >> wait)? Would you be interested to try to use AioEventHandler with the >> primitive I proposed? >> >> regards >> holger >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Nov. 2, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 11/01/2016 07:28 AM, test wrote: > Hi Martin, > thanks for this analysis, i really appreciate it. you did proof that, as > you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: > 0.1.". please excuse me - i seriously think it was very friendly of you > to do this detailed analysis -, but my argument never was, that if i use > Float>roundTo: this produces problematic floating-point-errors. if it > produces floating-point-errors they wouldnt be unexpected. i thought > this would be clear from my previous posts. what i tried to say is, that > i am a simple user and pharo shouldnt expect from me, that i know, that > if i want a result looking a bit more like 1.2, i should use "(x > asFraction roundTo:(1/10))asFloat" instead of "x roundTo:0.1". the > #round: method circumvents the irritating part of Float calcs imo in an > inexpensive way, and rounding numbers is imo not a very exotic task, but > to presume that i figure out (x asFraction roundTo:(1/10))asFloat by > myself is simply expecting too much from me. otoh now i that i know how > to do it, it's not a problem for me, if the majority wants to deprecate > #roundTo:. > Thank you again for the careful analysis > werner Hi Werner, Thanks for your comments. I posted the analysis because I did the analysis (and thought some others might want to see it), and I did the analysis because I wanted to find out whether that answer was right. Some Smalltalks are pretty bad in similar areas of Float handling. But aside from all the fine points, if you want a floating-point number to "look" nice and human-readable, (x asFraction roundTo:(1/10))asFloat will work, but I still recommend not rounding the number itself, but rounding the printing of the number. This is not a Pharo thing, it's an any-language-with-floats thing. In C you have printf, etc. In Pharo, you can use for instance: 1.19 printShowingDecimalPlaces: 1 ==> '1.2' This makes it easier for someone reading the code to see the intent. Regards, -Martin

Nov. 2, 2016