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

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by ClÃ©ment Bera

2016-03-25 18:30 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > >> Not exactly related to Announcement, but I remember when I first port >> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >> change/update when objects in the canvas changed. It was terribly slow, >> and later opted for a top-down update in the list of object. >> >> So some sometime what look like a cool stuff (decoupled objects) is just >> a drag. >> >> Regarding optimizing, I share my opinion here months ago, I think Pharo >> need consolidation releases: no new features, only bugs fix and speed >> improvement. There are enough new features in Pharo for a couple of >> years, but the product need to *be* solid and *feel* solid. >> > > +1 > > Agreed. >> Hilaire >> >> Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : >> > On 25-03-16 11:49, Nicolai Hess wrote: >> >> Morphic drasticallly slower ? I would expect morphic code is mostly >> >> the same in pharo and squeak. If pharo is slower, this is a good >> >> starting point for optimising. Can you gives some hints? >> > I do not have the impression that morphic is so much slower. >> > We had/have a problem of too many announcements being send and >> > too many redraws happening. >> > >> > Stephan >> > >> > >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

March 25, 2016

Green builds on Github

by Max Leske

Hi, Just wanted to let you know that the Github builds are now all green (since now the DateAndTime issue in Squeak has been fixed), i.e. Pharo-alpha, Pharo 5.0, Pharo 4.0, Squeak-trunk, Squeak-4.6, Squeak-4.5 on both OS X and Linux. See for yourself here: https://github.com/theseion/Fuel. Note that the sources are still being hosted on Smalltalkhub. Iâm triggering the builds through the TravisCI API when I run a build on the INRIA CI. Iâd like to thank Tobias Pape and Fabio Niephaus for their help in setting this up and for creating the SmalltalkCI infrastructure for TravisCI. Cheers, Max

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Nicolai Hess

2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > Not exactly related to Announcement, but I remember when I first port > DrGeo to Squeak (at that time Pharo did not exist) I used a lot of > change/update when objects in the canvas changed. It was terribly slow, > and later opted for a top-down update in the list of object. > > So some sometime what look like a cool stuff (decoupled objects) is just > a drag. > > Regarding optimizing, I share my opinion here months ago, I think Pharo > need consolidation releases: no new features, only bugs fix and speed > improvement. There are enough new features in Pharo for a couple of > years, but the product need to *be* solid and *feel* solid. > +1 > > Hilaire > > Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : > > On 25-03-16 11:49, Nicolai Hess wrote: > >> Morphic drasticallly slower ? I would expect morphic code is mostly > >> the same in pharo and squeak. If pharo is slower, this is a good > >> starting point for optimising. Can you gives some hints? > > I do not have the impression that morphic is so much slower. > > We had/have a problem of too many announcements being send and > > too many redraws happening. > > > > Stephan > > > > > > -- > Dr. Geo > http://drgeo.eu > > >

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Hilaire

Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object. So some sometime what look like a cool stuff (decoupled objects) is just a drag. Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid. Hilaire Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : > On 25-03-16 11:49, Nicolai Hess wrote: >> Morphic drasticallly slower ? I would expect morphic code is mostly >> the same in pharo and squeak. If pharo is slower, this is a good >> starting point for optimising. Can you gives some hints? > I do not have the impression that morphic is so much slower. > We had/have a problem of too many announcements being send and > too many redraws happening. > > Stephan > > -- Dr. Geo http://drgeo.eu

March 25, 2016

Re: [Pharo-dev] fullscreen on MacOS (possible VM bug)

by J.F. Rick

In further details, when it is green-button maximized, then I can run "Display fullscreenOn" and it doesn't crash. I also upgraded the desktop to the latest OS (10.11.4) but that doesn't fix it. Cheers, Jeff On Fri, Mar 25, 2016 at 11:12 AM J.F. Rick <self(a)je77.com> wrote: > Hi, > > I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn". > On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop > (MacMini, 4k display, OS 10.11.3), the screen goes to black for several > seconds and the VM crashes. I am attaching the crash.dmp file. Note that > this is a new Pharo4.0 I just downloaded from pharo.org. > > If I maximize the screen using the green button on the Pharo window, it > does not crash. But, it does mean that anytime I move my cursor towards the > top the Apple menus appear. That's not ideal for this purpose but could be > acceptable. When I quit and restart Pharo, it doesn't come back in full > screen mode. Is there Pharo code I can run to have it be in this kind of > fullscreen mode without user action? > > Cheers, > > Jeff > >

March 25, 2016

Re: [Pharo-dev] Squeak 5 on Raspberry Pi

by Dimitris Chloupis

well so far for me at least pharo 5 works ok perfomance wise on my quad core imac and my dual core macbook air. The only serious slow down I have is when loading images but I suspect this code is forked from Squeak anyway. System Browser was indeed a big issue with large classes but after FastTable it works fine. Overall I am very happy with Pharo. But I also avoid heavy computation with pharo. I am in favor of optimization coming later on development cycle. Like all things we need to grow a community of interested pharo developers that will us Pi not just as a toy but a useful device , the more we have the more likely is that someone will step in front of others to fix some of those issues. Personally I have a Pi which I bought mostly to support the project , I never found a reason to use it. I am actually on the opposite side of hi-tech graphics which also Pharo does not support at all. So I step in and bring that support to Pharo because I need it and because I love Pharo. Problems dont magically solve themselves, we need more contributors. On Fri, Mar 25, 2016 at 2:33 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > On 25 Mar 2016, at 12:52, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > On 25 Mar 2016, at 07:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Yeah this is very well-known. Note that here we are talking about the pi B > with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A > to open Nautilus on the stack vm while the Squeak UI was usable. > > The Pharo UI has been focusing on IDE features at the cost of performance, > such as auto-completion, better RB integration, Nautilus, new debugging > tools... None of the current tools (Nautilus, GTInspector, GTPlayground, > ...) are fast enough for slower devices, some of them are barely fast > enough for a laptop (for example at some point there was no auto-refresh on > GTInspector because of performance). It's not clear if it's due to the new > tools themselves as Morphic is drastically slower too on Pharo. > > The Squeak UI has been focusing on performance and stability. It is very > convenient for slow devices but also for slow VM like for example the debug > VM. > > The official answer to this problem is that Block/Brick will be faster so > it will solve all this problems. We will see. > > > yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally > it will solve some problems (the ones related to Morphic), but current lack > of performance on Pharo tools is not because of Morphic but because of some > non optimised choices. > For example, months ago I got pissed because our current list > implementation was not fast enough for our tools and thatâs why I made > FastTable: because it was evident we needed a better design for it. It > speeded the startup of Nautilus by an order of magnitude. This is a widget > developed with Morphic, but with a not-naive approach, so is fast. > As lists, some others widgets (notably tree) could be optimisedâ¦ > But this will not be the solution of the problem either: we need to spend > time on optimisation. Nautilus is not a good tool (we all know it has > design problems all around) but with the time had improve and not using it > is almost enjoyableâ¦ but for example, the new debugger (which Iâm not > criticising as a tool, I like it a lot) makes me hurtâ¦ is slower than > eclipse debugger and thatâs a lot to say. > > > That is a good one :). There is an open issue with the blinking problem > when you accept code which makes it appear slower than it actually is, but > we are stuck with it and we could benefit from help. > > Also new inspector: is good, but canât we optimise it? maybe we need to > make some concession, but is the moment of doing it. > > > The optimization we should do now is to replace the appearances of > MorphTreeMorph with FastTable. This would imply that the Raw presentation > would not longer have a tree (because it is not supported in FastTable). I > would be very happy if we could do that. Do we agree on this? > > > actually there is a tree implementation based on fast table, but Iâm not > sure is production ready (Cyril can say something about). > But anyway since I never understood why we have a tree there (since we > will âopenâ attribute in next panel), I do agree, strongly :) > > > Recently Iâm noticing a slowdown in Spotter: I believe is because one of > his categories is refreshing to the network but Iâm not sure: this slowdown > is not production acceptable, for me is a Show Stopper because it kills the > usability of the tool (of a tool who is great, but it HAS to be fast, > otherwise is useless). > > > Could you be more specific about the Spotter problem that you see? > > > not sure, I open and it takes some seconds to actually show anything. I > thought it was caused because of the catalog refresh to populate projects, > but Iâm not sure. > In any case, load catalog projects in spotter is cool, but we need to find > a better implementation. One that does not freezes spotter until it refresh > (remember, Pharo is also used in places with crapy connection or not > connection at all). > > > Also, in the last couple of days Alex Syrel improved the speed of Spotter > significantly. It is not yet integrated. It would be useful to get feedback > on this because maybe we missed something. > > > Mea culpa: more than once I have not protested even knowing than solution > X was â10% slower than the older one, but thatâs ok, we can live with itââ¦ > guess what? once you accumulate enough of those 10% penalties, you have a > barely usable system. > > We need to concentrate efforts on performance. There will not be magical > solution: if we do not spend time on enhance tools for performance, they > will be not good enough. > > Can I ask you guys to spend some time optimising tools, before we release > Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for > it in FogBugz). > > > It would indeed be useful to get more eyes spent on this. > > > yes! > > if you want to suffer, do this experiment: > 1. open a Pharo2 and open debugger on anything > 2. then Pharo3, 4 and 5â¦ feel the incremental slowdown > 3. cry :â( > > Esteban > > > Cheers, > Doru > > > Esteban > > > > > > 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > [Squeak 5 is] so *fast* (I have it running next to > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping > along at Windows desktop speeds on the Pi (Model B). > > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com <http://nabble.com>. > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > >

March 25, 2016

Re: [Pharo-dev] [squeak-dev] [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue

by Eliot Miranda

Hi Holger, let's collaborate on this. You and I and lots of others want this to be done. But in fixing the below bug my priorities are to a) deliver a fix promptly b) write the code so that either kqueue or epoll or select will be used based on HAVE_KQUEUE & HAVE_EPOLL defines So if I deliver a fix don't think that I'm against having a proper event-driven or idling VM, I just don't have it in my head yet and want the bug fixed and kqueue/epoll available asap. On Thu, Mar 24, 2016 at 11:42 PM, Holger Freyther <holger(a)freyther.de> wrote: > > > > On 25 Mar 2016, at 00:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > Dear Eliot, > > > > Fabulous, thank you! replace the self halts with e.g. self assert: > (clientSocket dataAvailable = (clientSocket readSemaphore excessSignals > > 0)), and we even have a test. I have work to do tomorrow but hope I should > be able to debug this soon. I'll add kqueue and epoll support when I fix > it. > > before going to kqueue, could you have a look at my hack to create a > completely idle VM? Once the VM has moved to kqueue it seems one can not > get a SIGIO for the "kqueue descriptor"[1] itself and I don't know if SIGIO > remains working for the individual file descriptors. > > holger > > > [1] > https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_event.c#L1735 > > -- _,,,^..^,,,_ best, Eliot

March 25, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Christophe Demarey

Hi Alex, I just publish a configuration of the Session Manager with this change (not yet in Pharo). Please could you test if it is ok for you? you can load it with: Metacello new smalltalkhubUser: 'Pharo' project: 'SessionManager'; configuration: 'SessionManager'; fetch. Metacello new smalltalkhubUser: 'Pharo' project: 'SessionManager'; configuration: 'SessionManager'; version: '1.7'; load Cheers, Christophe > Le 4 fÃ©vr. 2016 Ã 13:42, Aliaksei Syrel <alex.syrel(a)gmail.com> a Ã©crit : > > Hi Christophe > > Thanks for the answer :) > What you proposed indeed fixes the issue. it would be great to have it! > > Because Bloc Universe knows which space is currently running I can detect which UI manager is needed. So I just hacked "new" in bloc ui manager: > > new > ^ super new space: (%ask universe for correct space%) > > Ugly but works, until refactoring of SessionManager is done. > > Please continue your great job :) > > > Cheers, > Alex

March 25, 2016

Re: [Pharo-dev] [Ann] New version of Ghost

by Christophe Demarey

> Le 25 mars 2016 Ã 14:54, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > Hi > > 2016-03-25 9:47 GMT+01:00 Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>>: >> Abstract proxy classes uses Ghost name instead of Proxy: there are GHObjectGhost and GHClassGhost. >> GHProxyHandler renamed to GHGhostBehaviour. Concrete ghosts should implement #ghostBehaviour instead of #proxyHandler. > > Why did you rename these classes? > I find the new names obscure and they do not provide a clue of what is the purpose of the class. Old names were clear and easily understandable. > > Nice you ask. It can raise interesting discussion. > > In previous version we have three classes to support basic object proxy: > GHInterceptionDelegator > GHProxyTrap > GHAbstractProxy > And now due to DNU approach it just one: > GHObjectGhost > > And I guess you would call it GHObjectProxy or GHAbstractProxy. Lets look at wikipedia: > > A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes > > So proxy is supposed to substitute some other object. But in many cases we not have other object. In many cases we construct special kind of objects which perform messages in not smalltalk way. For example imaging that we want to implement javascript prototypes (there was related post https://clementbera.wordpress.com/2016/02/17/mind-twister-toying-with-objec… <https://clementbera.wordpress.com/2016/02/17/mind-twister-toying-with-objec…>). Prototype is definitely not kind of proxy. Or think about Mock object. It is not proxy too. > So generally Ghost is not about proxies. It is exactly about supernatural objects. With Ghost we construct special objects which behave in not natural smalltalk way. so is most magic than surnatural ;) > And in that perspective classic proxy is most primitive example of it. It just delegates all messages to another object (with little bit of logic). > > Maybe you would suggest another name: GHInterceptionDelegator (what the name for GHGhostClass in that case?). > But why we not call Object same way too (InterceptionDelegator)? Natural smalltalk objects just delegate message processing to methods from class methodDictionary (which is hidden by VM). > > So for me ObjectGhost reflects perfectly real intention of it. It is base class to construct unnatural smalltalk objects. And ClassGhost is unnatural object which can play role of natural object classes. > > Now lets look at ProxyHandler vs GhostBehaviour. ProxyHandler play role of Behavior (Class) but for proxies. It defines how proxies will handle messages. But why we not call smalltalk Behaviour as ObjectHandler? > I hope now you see logic behind my names and ghost metaphor. Ghost models special objects with similar terms from natural objects: Object -> ObjectGhost and Behavior -> GhostBehaviour. Thanks for the answer. I now see more the rationale behind your naming but it is not obvious at a first sight. If not there, please explain it in documentation, comments. > I changed title of Ghost project to: > Ghost is framework to implement unnatural smalltalk objects like proxies and prototypes., >> New kind of proxies: >> GHObjectVirus. It is special kind of GHClassProxy. It infects real object to intercept it messages. From meta level infected object looks like healthy object which means that meta messages are executed by infected object itself. As class virus looks like real victim > > Same remark here. The name is fun but it does not give any clue on the purpose of the class. Why not use GHMessageInterceptor? > > And following such approach we will have GHInterceptionDelegator (for objects) and GHMessageInterceptor (for classes). Is it good? > I will describe virus more detailed soon. But maybe you remember there was very old advice from famous books: don't create classes which ends with -ER or -OR. (I not found original source but google shows many followers > http://www.yegor256.com/2015/03/09/objects-end-with-er.html <http://www.yegor256.com/2015/03/09/objects-end-with-er.html> > http://objology.blogspot.fr/2011/09/one-of-best-bits-of-programming-advice.… <http://objology.blogspot.fr/2011/09/one-of-best-bits-of-programming-advice.…>) you have it in âSmalltalk best practicesâ for sure Thanks for the detailed answer Denis, Christophe

March 25, 2016

fullscreen on MacOS (possible VM bug)

by J.F. Rick

Hi, I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn". On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop (MacMini, 4k display, OS 10.11.3), the screen goes to black for several seconds and the VM crashes. I am attaching the crash.dmp file. Note that this is a new Pharo4.0 I just downloaded from pharo.org. If I maximize the screen using the green button on the Pharo window, it does not crash. But, it does mean that anytime I move my cursor towards the top the Apple menus appear. That's not ideal for this purpose but could be acceptable. When I quit and restart Pharo, it doesn't come back in full screen mode. Is there Pharo code I can run to have it be in this kind of fullscreen mode without user action? Cheers, Jeff

March 25, 2016