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

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

by phil＠highoctane.be

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. 1, 2016

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

by Sven Van Caekenberghe

> On 1 Nov 2016, at 21:21, 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. Why not go the Spec way ? window := TextModel new text: 'Smalltalk version.'; title: 'My Workspace'; openWithSpec. window model text: 'Smalltalk garbageCollect.' I do agree that it is not obvious in GT. Sven

Nov. 1, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Yuriy Tymchuk

And roassal is not working probably because of some Cairo bindings > On 1 Nov 2016, at 10:39, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I cannot see the text I type into the Spotterâs search bar. Otherwise everything is great so far. > > Uko > >> On 29 Oct 2016, at 17:09, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 28/10/2016 Ã 15:18, Esteban Lorenzano a Ã©crit : >>> >>>> On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier(a)gmail.com >>>> <mailto:thierry.goubier@gmail.com>> wrote: >>>> >>>> apart from the missing SSL support which makes loading complex stuff >>>> from github a bit painfull, it seems to be usable enough. >>> >>> I should work on this :) >> >> Anything we can be of help on this? >> >> In the meantime, I'm becoming expert at writing wget requests to github to get tarballs of smalltalk projects :) >> >> Thierry >> >>> Esteban >> >> > >

Nov. 1, 2016

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

by Dimitris Chloupis

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. 1, 2016

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

by Attila Magyar

> And with message based approach this problem not exists at all. 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]/). But I dont want to go off topic. I just disagree that this arbitrary and subjective feature makes something "modern" or not. Anyways, good luck with Mocketry. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 1, 2016

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

by phil＠highoctane.be

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. 1, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 48592d: 60274

by Marcus Denker

> > Log Message: > ----------- > 60274 > Moose This is: 18884 Inspecting a large Bag crashes the Image 18224 Scrolling Spotter creates draw damage outside of its bounds

Nov. 1, 2016

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

by Denis Kudriashov

2016-11-01 18:27 GMT+01:00 Attila Magyar <m.magyar3(a)gmail.com>: > > They have strings. And first mock libraries used message names as strings > > They are not the same. Method rename and find senders works with symbols > but > not with strings. Some rarely used refactorings might not work, although > this is probably a technical limitation of the refactoring engine and not a > conceptual one. > No matter. This is what we have. And with message based approach this problem not exists at all. 2016-11-01 18:27 GMT+01:00 Attila Magyar <m.magyar3(a)gmail.com>: > > not believe that anybody would prefer writing > > In Ruby this would look like something like this. > > allow(socket).to receive(:connect).with(address, port, timeout) { > do_something } > This is exactly what I said: with C-like syntax it is normal but not with keyword messages. > > Not so different and many people use this. Probably lot more than the users > of Mocketry + BabyMock together. > (Anyways probably I wouldn't use a mock library to stub an object like a > socket. It is not my own type, too low-level abstraction. It results > brittle > tests no matter what syntax is used.) It was just example where everybody could see agliness of string based approach. > > > It leads to more code which you will write again and again in your tests > > If I have too many code for setting up expectations and mocks that is a > clear clue that something went wrong in my test, I use mocks in most unit tests. So in every test I will need to repeat all this code. > and I rather have a mock > library that makes this painful early on. It is really easy to make a mess > with mock object based tests. This is why I still prefer jMock over any > other mock object library (mockito, easymock) in Java. JMock is a highly > opinionated library that deliberately doesn't support features like deep > stubbing, partial mocking and other black magic stuffs. BabyMock follows a > similar philosophy. Smalltalk is super powerful language which allows easily create and run tons of spaghetti code. But with C++ it is sometime impossible to just compile spaghetti code. So C++ prevents programmers from writing bad code because without discipline you can't run your program. So if you want to be good programmer choose C++. (sorry for sarcasm)

Nov. 1, 2016

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

by Dimitris Chloupis

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. 1, 2016

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

by Esteban Lorenzano

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 <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 <mailto:holger@freyther.de>> wrote: > > > On 23 Sep 2016, at 02:44, Ronie Salgado <roniesalg(a)gmail.com <mailto:roniesalg@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 <http://marianopeck.wordpress.com/>

Nov. 1, 2016