January 2014 - Pharo-dev - lists.pharo.org

Pharo 3.0 on Raspberry Pi - Yes/No

by Sven Van Caekenberghe

Hi, Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi. Yes: pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710 pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z No errors. No: When doing something more complex, like: pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701) The HTTP Server does respond normally to one request and then seems to hang. When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. No PharoDebug.log output. Events ? Multi-processing ? How ? Use Jean-Baptiste's VM from here: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Com… Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all). So, we're getting closer... If anyone is interested, I could make some kind of all in one download. Sven

Jan. 20, 2014

Re: [Pharo-dev] RFB on a headless Pharo 3

by Torsten Bergmann

Hi Sebastian, I havent tried but from problems in the past [1] and [2] and a short look at the code I guess it could again be related to #deprecated stuff. If you look at RFBSession>>desktopName it again sends deprecated methods in the expression: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; Fix it by using Smalltalk os name Smalltalk os version instead. Note the additional method then permits chaining. Maybe that is the problem. Have fun T. [1] http://forum.world.st/RFB-in-2-0-td4685418.html [2] http://samadhiweb.com/blog/2012.11.04.headless.rfb.html

Jan. 20, 2014

Re: [Pharo-dev] RFB on a headless Pharo 3

by Sebastian Sastre

If you want to reproduce the issue: 1. Take a fresh image wget -O- get.pharo.org/30+vm | bash 2. start it with UI and in a workspace load RFB Gofer new url:'http://www.smalltalkhub.com/mc/PharoExtras/RFB/main'; package: 'RFB'; load. 3. then run RFBServer current allowRemoteConnections: true; setFullPassword: âcacaâ; start: 8. 4. connect with chicken VNC or your favourite client to 5908, all should be okay (if you have in mind the bug/fix about os platform) 5. quit image saving 6. you can now open it with UI and all will be nice and good or youâll have an image that canât start in headless mode =/ still investigating... contributions are very welcome sebastian o/ On Jan 20, 2014, at 3:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Guys > > Just checking while investigating the issue... > > Were any of you here able to connect a VNC client to a headless Pharo 3? > > I can do that to a Pharo 2 (seting a morphic ui manager on it) but I'm having issues with 3 > > Did you tried that? any luck? insights? > > sebastian > > o/

Jan. 20, 2014

RFB on a headless Pharo 3

by Sebastian Sastre

Guys Just checking while investigating the issue... Were any of you here able to connect a VNC client to a headless Pharo 3? I can do that to a Pharo 2 (seting a morphic ui manager on it) but I'm having issues with 3 Did you tried that? any luck? insights? sebastian o/

Jan. 20, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by Benjamin

On 20 Jan 2014, at 14:37, btc(a)openinworld.com wrote: > I don't want to unsubscribe #refresh in PhLTitledTreeModel>>initialize. > I _really_ want to unsubscribe #refresh immediately after the subscribe #refresh is set up. But it does not prevent you to register to the event whenever you want :) Could you give a try and tell me? > I tried to avoid calling in #windowHolder but would that preferred? > Do you have another suggestion? I was not talking about the name, more the implementation :P (but not more than #window :) ) > btw, the 'window' i-var of ComposableModel seems like it should be 'windowHolder' I think all the other variable should be name without holder at the end :) Ben

Jan. 20, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

Jan. 20, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by Benjamin

On 20 Jan 2014, at 13:51, btc(a)openinworld.com wrote: > Sure thing. That was part of my original intention. Cool :) Thanks > When I try... > self whenBuiltDo: [ self halt. self window whenClosedDo: [ self halt. self repository unsubscribe: self ] ]. > none of the halts occur. > > However I got what I needed with the followingâ¦ did you try to register in the initialize method ? Because if you register once the application is already open, it may not work :) > ---------- > ComposableModel>>topWindowHolder > ^ owner > ifNil: [ window ] > ifNotNil: [ :o | o topWindowHolder ]. > ---------- > ComposableModel>>whenWindowClosed: aBlock > self topWindowHolder value > ifNotNil: [ :w | w whenClosedDo: aBlock ] > ifNil: [ self topWindowHolder whenChangedDo: [ :w | w whenClosedDo: aBlock ] ]. > ---------- > PhLTitledTreeModel>>repository: aRepository > self assert: self repository isNil description: 'Changing the repository is not allowed because we would have to change the context as well'. > repositoryHolder value: aRepository. > self repository whenChangedSend: #refresh to: self. > self whenWindowClosed: [ self repository unsubscribe: self. self inform: 'Works for composed sub-items'. ] . > self refresh > ---------- > PharoLauncher>>initialize > super initialize. > self whenWindowClosed: [ self inform: 'Works for top level owner' ]. > ---------- > And optionally you could now have... > ComposableModel>>window > ^ self topWindowHolder value > âââââ topWindowHolder sounds a bit hackish :) I think this can be achieved with the whenBuiltDo:, I should investigate :) > > If those ComposableModel additions are okay, I'll submit a slice on Case 12677 (renamed to "ComposableModel subcomponents need to act on window close") > https://pharo.fogbugz.com/f/cases/12677/ You can also submitted here: https://github.com/SpecForPharo/spec if you want :) (and become a Spec contributor :P) Ben

Jan. 20, 2014

Re: [Pharo-dev] Making Platform Installers

by btc＠openinworld.com

Jan. 20, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

Jan. 20, 2014

Re: [Pharo-dev] Smalltalk Impact

by Ron Teitelbaum

> > Lets rest it. as people might guess, I am still sad about Squeak. lets say it like > that: I *really* *really* believed in it (the whole thing, dynabook and all), and I > still think one could have done much better than we have. > > And it's not a problem that it failed: it is a problem hat it was hold back explicitly > that makes me sad. How great could it have been! > > Just imagine a system that is improved, radically, over 20 years. every day a bit, > every year a release, building always on top of a stable base created before... > > Marcus The Pharo fork made me sad too. I wonder sometime if I had put in more time if I could have helped settle the rift and keep the community together. There is a lot of good work going on with Pharo now so maybe the fork was a good thing but I do wish we could all be working on one code base instead. I'm sure I will get used to the split eventually. Ron

Jan. 20, 2014