[Pharo-dev] Question on Unclassified / _UnpackagedPackage
Hi all, I'm looking at classes without package and/or without system category. Nautilus offers a _UnpackagedPackage; some code in Class use 'Unclassified' when compiling without explicit category. So far, creating an 'Unclassified' class does not register in _UnpackagedPackage (however, I do see an 'Unclassified' RPackage with, of course, no MCWorkingCopy associated). anybody knows how this is supposed to work? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] RFB on Pharo3
Ohh, I misread the mail. Sorry. Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. Doru On Mon, Jan 20, 2014 at 3:27 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 20 Jan 2014, at 15:26, Tudor Girba tu...@tudorgirba.com wrote: Thank you. Could you please open an issue and propose a slice for this? RFB is an external package, right ? Doru On Mon, Jan 20, 2014 at 1:57 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi there, this is causing a debugger to be open in the deprecated method RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] fix: RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: Smalltalk os name; space; nextPutAll: Smalltalk os version; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Making Platform Installers
On Mon, Jan 20, 2014 at 3:25 PM, Tudor Girba tu...@tudorgirba.com wrote: Where can I find the code for this? https://github.com/pharo-project/pharo-ci build-dmg and build-windows-installer -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] RFB on Pharo3
I think we should use Metacello versions for this, no? Doru Sent from my iPhone On Jan 20, 2014, at 15:39, Sven Van Caekenberghe s...@stfx.eu wrote: On 20 Jan 2014, at 15:30, Tudor Girba tu...@tudorgirba.com wrote: Ohh, I misread the mail. Sorry. Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. But if he does that, RFB will no longer work on 2.0 And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). Doru On Mon, Jan 20, 2014 at 3:27 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 20 Jan 2014, at 15:26, Tudor Girba tu...@tudorgirba.com wrote: Thank you. Could you please open an issue and propose a slice for this? RFB is an external package, right ? Doru On Mon, Jan 20, 2014 at 1:57 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi there, this is causing a debugger to be open in the deprecated method RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] fix: RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: Smalltalk os name; space; nextPutAll: Smalltalk os version; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] RFB on Pharo3
On 20 Jan 2014, at 16:04, Tudor Girba tu...@tudorgirba.com wrote: I think we should use Metacello versions for this, no? Yes, that is one option, that is what I meant by 'having 2 code versions'. But it is a lot of hassle for one little platform difference. Maybe the project already has some platform specific code, then it would be easier to play along. Doru Sent from my iPhone On Jan 20, 2014, at 15:39, Sven Van Caekenberghe s...@stfx.eu wrote: On 20 Jan 2014, at 15:30, Tudor Girba tu...@tudorgirba.com wrote: Ohh, I misread the mail. Sorry. Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. But if he does that, RFB will no longer work on 2.0 And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). Doru On Mon, Jan 20, 2014 at 3:27 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 20 Jan 2014, at 15:26, Tudor Girba tu...@tudorgirba.com wrote: Thank you. Could you please open an issue and propose a slice for this? RFB is an external package, right ? Doru On Mon, Jan 20, 2014 at 1:57 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi there, this is causing a debugger to be open in the deprecated method RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] fix: RFBSessiondesktopName Answer the name of the desktop, constructed from the image, host and platform names. RFBSession new desktopName ^String streamContents: [:stream | stream nextPutAll: SmalltalkImage current imageName asFileReference basename; nextPut: $@; nextPutAll: server localHostName; nextPutAll: ' ['; nextPutAll: Smalltalk os name; space; nextPutAll: Smalltalk os version; nextPut: $]. interactive ifFalse: [stream nextPutAll: ' - view only']] -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] unload all
excellent like that I can work on the loading part I love sooo writing configurations. Stef On 20 Jan 2014, at 12:18, Pavel Krivanek pavel.kriva...@gmail.com wrote: Here is the job: https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKernel3.0-FromTopShrink/ -- Pavel 2014/1/20 Sven Van Caekenberghe s...@stfx.eu On 19 Jan 2014, at 09:44, Pavel Krivanek pavel.kriva...@gmail.com wrote: 2014/1/18 Sven Van Caekenberghe s...@stfx.eu On 18 Jan 2014, at 20:53, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: COOOLLL !! +1 And interesting as well (I want to understand how to unload NB, for example). For simplicity I use the attached code. The image needs to be restarted after NB unloading. To do it properly, we need to solve this issues: https://pharo.fogbugz.com/f/cases/12624/make-image-startup-independent-on-NativeBoost https://pharo.fogbugz.com/f/cases/11869/NativeBoost-usage-in-PreferenceStartup-raises-an-exception-on-StackVM -- Pavel Ben On 18 Jan 2014, at 16:37, Pavel Krivanek pavel.kriva...@gmail.com wrote: Hi, I finally successfully created a script that is able to unload everything *by Monticello* except kernel packages, network, Monticello, Gofer and related packages. I will setup a job when Jenkins will be healthy again. It uses several temporary patches that we need to solve properly: - make NativeBoost optional - make UserManager optional - small super-easy issue https://pharo.fogbugz.com/f/cases/12679/change-package-of-ClassTrait-soleInstance The size of resultant image is about 6.6 MB, 4.9 MB without MC data and caches. BTW in the full image Monticello data have about 5MB. The image has no Undeclared nor obsolete classes and is really able to load something using Gofer. With some care we can make it usable base for the next remodularization effort. Cheers, -- Pavel cleanAfterNB.stunloadNB.st Thanks for the scripts, Pavel. I was already looking at the environment stuff, it is good to see that the problem is confined to that area. When I continue trying to make a 3.0 image run on the Raspberry Pi, I will try using this script. Sven
Re: [Pharo-dev] Smalltalk Impact
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
Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel
Benjamin wrote: Hi Ben, I've gave that a go and had some success, but it raised an architectural question I ask near the end. I've documented my investigation here in case it is of use to others new to Spec or the Spec documentation being developed. Spec documentation is actually under heavy construction :) May I keep this content for further quotation? Sure thing. That was part of my original intention. So the question this leads up to is... Should child ComposableModels all reference the same WindowModel as their owner? The thing is, the isn’t var window doesn’t point to the same, but the method `window` does :) Could you try something like: PhLTitledTreeModelrepository: aRepository repositoryHolder value: aRepository. self repository whenChangedSend: #refresh to: self. "--subscription-of-concern" self refresh. self whenBuiltDo: [ self window whenClosed: [ self repository unsubscribe: self ] ] Thanks for your investigation :) Ben 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... -- ComposableModeltopWindowHolder ^ owner ifNil: [ window ] ifNotNil: [ :o | o topWindowHolder ]. -- ComposableModelwhenWindowClosed: aBlock self topWindowHolder value ifNotNil: [ :w | w whenClosedDo: aBlock ] ifNil: [ self topWindowHolder whenChangedDo: [ :w | w whenClosedDo: aBlock ] ]. -- PhLTitledTreeModelrepository: 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 -- PharoLauncherinitialize super initialize. self whenWindowClosed: [ self inform: 'Works for top level owner' ]. -- And optionally you could now have... ComposableModelwindow ^ self topWindowHolder value -- 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/ cheers -ben
Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel
On 20 Jan 2014, at 13:51, b...@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 :) -- ComposableModeltopWindowHolder ^ owner ifNil: [ window ] ifNotNil: [ :o | o topWindowHolder ]. -- ComposableModelwhenWindowClosed: aBlock self topWindowHolder value ifNotNil: [ :w | w whenClosedDo: aBlock ] ifNil: [ self topWindowHolder whenChangedDo: [ :w | w whenClosedDo: aBlock ] ]. -- PhLTitledTreeModelrepository: 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 -- PharoLauncherinitialize super initialize. self whenWindowClosed: [ self inform: 'Works for top level owner' ]. -- And optionally you could now have... ComposableModelwindow ^ 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
Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel
Benjamin wrote: On 20 Jan 2014, at 13:51, b...@openinworld.com wrote: 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 :) I don't want to unsubscribe #refresh in PhLTitledTreeModelinitialize. I _really_ want to unsubscribe #refresh immediately after the subscribe #refresh is set up. -- ComposableModeltopWindowHolder ^ owner ifNil: [ window ] ifNotNil: [ :o | o topWindowHolder ]. -- ComposableModelwhenWindowClosed: aBlock self topWindowHolder value ifNotNil: [ :w | w whenClosedDo: aBlock ] ifNil: [ self topWindowHolder whenChangedDo: [ :w | w whenClosedDo: aBlock ] ]. -- PhLTitledTreeModelrepository: 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 -- PharoLauncherinitialize super initialize. self whenWindowClosed: [ self inform: 'Works for top level owner' ]. -- And optionally you could now have... ComposableModelwindow ^ self topWindowHolder value — topWindowHolder sounds a bit hackish :) I tried to avoid calling in #windowHolder but would that preferred? Do you have another suggestion? btw, the 'window' i-var of ComposableModel seems like it should be 'windowHolder' 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
Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel
On 20 Jan 2014, at 14:37, b...@openinworld.com wrote: I don't want to unsubscribe #refresh in PhLTitledTreeModelinitialize. 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
[Pharo-dev] RFB on a headless Pharo 3
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/
Re: [Pharo-dev] RFB on a headless Pharo 3
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 sebast...@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/
Re: [Pharo-dev] RFB on a headless Pharo 3
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 RFBSessiondesktopName 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
[Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
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-Compilation/40/artifact/results.tar.gz 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
Re: [Pharo-dev] [Moose-dev] [ANN] MessageTally in GTInspector
this is not only loading the challenges. we should handle cross cutting changes. Stef On 20 Jan 2014, at 11:05, Tudor Girba tu...@tudorgirba.com wrote: I think I understand the implications. Moose comes with these tools out of the box, so for people that work with Moose it makes perfect sense to work with tools from the future :). Btw, you can work with the bare GToolkit (only the components needed for Pharo) from here: https://ci.inria.fr/moose/job/gtoolkit/lastSuccessfulBuild/artifact/gtoolkit.zip I also think that the dependency problem is an important one, but it is orthogonal with the work on producing the IDE. I want to get these tools in Pharo, and I want to spend the energy in ensuring modularity, too. The components of the GToolkit are modular now. If at some point we decide to integrate them, the simplest thing we can do is to create the job that ensures their unloadability before the integration. Another option is to go back to a Core image and build the working image. I think we should reevaluate this option in the light of the latest Monticello speedups. For example, the current build time for a GToolkit image is 1.5 mins (loads Glamour, Roassal, Graph-ET, GToolkit) which is not a lot. Doru On Mon, Jan 20, 2014 at 8:53 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On 19 Jan 2014, at 22:58, Alexandre Bergel alexandre.ber...@me.com wrote: This is gorgeous. The Moose distribution of Pharo looks like to be better suitable for code development than the vanilla one. This makes me remember the Development image of Damien. Do you really ***understand*** the implications? Because once people will start to put dependencies everytwhere on roassal and start to run smalllint on your code and …. that you will have to follow it and merge and …. you will look at the problem. Without unload process that is systematically exercised, tools to manage dependencies and a process to build and support modular images we will end up with a monolithic system. I just tried to unload ProfStef and it was full of left instance behind. I tried to unload Nautilus for example and RB. Stef Alexandre On Jan 18, 2014, at 8:29 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi, The GTInspector just became a performance analysis tool, too. You can simply inspect a MessageTally and you get several useful views that help you identify performance problems. You can read a more detailed description here: http://www.humane-assessment.com/blog/assessing-pharo-performance-with-gtinspector/ As an appetizer, I attached a screenshot with a Graph-ET chart (thank you Daniel Aviv for developing this engine). MessageTally-chart.png To play with the code, you can just work in the latest Moose 5.0 image: https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-5.0.zip Please let me know what you think. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [COTDC] 108 - NewValueHolder
I had some questions about NewValueHolder and I figured, why not revive COTDC?! The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? - is the Value Holder part of the name accurate in light of [1]. Obviously repurposing a term people may already be familiar with is a bad idea. In fact the important part here seems not the holding of the value, but the notification of changes. It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what? - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples [1] http://en.wikipedia.org/wiki/Lazy_loading p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Making Platform Installers
I have done a tool for PhaROS distribution, that is for deploying a package into a middleware, it lets you define the layout of folders, is prepared to add ways of writing ( actually it has implemented the version for local file system, but it should be easy to implement remote deploying ). It let you download vm, image , sources, and it has two post processing places for adding hooks: one in the image that is making the installation, other in the image is being installed. It has a silent mode of execution, when it does run everything in headless Even when it was mean for deploying on middleware, it should be useful. There are two actual disclaimers: is not working in windows yet, you will need to code a bit to specify the layout of installation (is not that is really bad, but is not done yet) http://car.mines-douai.fr/squeaksource/@vLtUOBuLaxNWsghP/UmsTHzMp So tell me if you need it. 2014/1/18 Sean P. DeNigris s...@clipperadams.com Are there up-to-date instructions - or better yet CI scripts - or even better Smalltalk CI scripts :) - to make installers for Mac/Windows/Unix? How about if one can not install anything? Mac is easy enough, as a bundle has everything hidden in one, but what about Windows? Can one do better than a batch file + Pharo.ini specifying the image? Or an sh file + folder-with-everything-else for unix? - Cheers, Sean -- View this message in context: http://forum.world.st/Making-Platform-Installers-tp4737775.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] RFB on a headless Pharo 3
Also try RFBLog dumpLogToTranscript: true before running. Then a dump on the Transcript will appear. There you will see that there is a DNU for a Cursor instance which does not understand #maskForm in method #sendCursorShape: Interesting enough ivar newCursor is an instance of Cursor - but and only subclass like CursorWithMask understand #maskForm. It is initialized in #initServer:socket:reverse: with Cursor currentCursor returning - either a Cursor instance when I inspect it using the menu - a CursorWithMask instance when I inspect it using CMD keys No time to dig deeper today. Keep us informed about your progress. An updated ConfigurationOfRFB would be nice... Bye T.
Re: [Pharo-dev] Making Platform Installers
Hi Santiago, when sending a link from a SqueakSource instance please send the project name like: http://car.mines-douai.fr/squeaksource/MyKillerApp.html The link you used http://car.mines-douai.fr/squeaksource/@vLtUOBuLaxNWsghP/UmsTHzMp was an active session and can not be used by others since it will alway end up on the frontpage. Bye T.
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
On 20 Jan 2014, at 15:36, Sean P. DeNigris s...@clipperadams.com wrote: I had some questions about NewValueHolder and I figured, why not revive COTDC?! I loved it :) The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? I am a class holding any object inside its unique instance variable. Each time the instance variable value changes, an announcement is emitted. The instance variable is accessed through `value` and `value:` while the registration is done by `whenChangedDo: aBlock`. In addition, infinite loops of propagation are prevented. Use case: you have two lists A, and B, and you want to keep their selection synchronised. So when A selection changes, you set B selection. But since B selection changes, you set A selection, and so on… This case is prevented by the use of value holders. - is the Value Holder part of the name accurate in light of [1]. Nope :( Obviously repurposing a term people may already be familiar with is a bad idea. It’s called NewValueHolder because it’s a re-implementation of ValueHolder :) I did not checked the name :P In fact the important part here seems not the holding of the value, but the notification of changes. Indeed It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what?” I like Reactive too. It sounds like we are doing cool things :P - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples Might be yes, I did not checked the users of ValueHolder in a while. p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item” Probably a bad hack I did :P Ben
Re: [Pharo-dev] [Moose-dev] [ANN] MessageTally in GTInspector
On 20 Jan 2014, at 19:47, Johan Fabry jfa...@dcc.uchile.cl wrote: Stef, are you asking for aspects? :-P No just managing mess :) On Jan 20, 2014, at 12:48 PM, Pharo4Stef pharo4s...@free.fr wrote: this is not only loading the challenges. we should handle cross cutting changes. Stef On 20 Jan 2014, at 11:05, Tudor Girba tu...@tudorgirba.com wrote: I think I understand the implications. Moose comes with these tools out of the box, so for people that work with Moose it makes perfect sense to work with tools from the future :). Btw, you can work with the bare GToolkit (only the components needed for Pharo) from here: https://ci.inria.fr/moose/job/gtoolkit/lastSuccessfulBuild/artifact/gtoolkit.zip I also think that the dependency problem is an important one, but it is orthogonal with the work on producing the IDE. I want to get these tools in Pharo, and I want to spend the energy in ensuring modularity, too. The components of the GToolkit are modular now. If at some point we decide to integrate them, the simplest thing we can do is to create the job that ensures their unloadability before the integration. Another option is to go back to a Core image and build the working image. I think we should reevaluate this option in the light of the latest Monticello speedups. For example, the current build time for a GToolkit image is 1.5 mins (loads Glamour, Roassal, Graph-ET, GToolkit) which is not a lot. Doru --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
I commented the code in a slice that apparently was not integrated. But yes this is a good idea. - to have more code review - to revive the COTDC I had some questions about NewValueHolder and I figured, why not revive COTDC?! The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? - is the Value Holder part of the name accurate in light of [1]. Obviously repurposing a term people may already be familiar with is a bad idea. In fact the important part here seems not the holding of the value, but the notification of changes. It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what? - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples [1] http://en.wikipedia.org/wiki/Lazy_loading p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] PhD Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications
Encore ?? Personne ne veut venir, c’est ça ? :P Ben On 20 Jan 2014, at 17:01, jannik laval jannik.la...@gmail.com wrote: The position is available now. Interested candidates may apply as soon as possible. Title: Ph.D. Student Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications Location: Mines de Douai and ENSTA Brest (France) Advisor and contacts: Noury Bouraqadi (noury.bouraq...@mines-douai.fr) Luc Fabresse (luc.fabre...@mines-douai.fr) Loïc Lagadec (loic.laga...@ensta-bretagne.fr) Jannik Laval (jannik.la...@mines-douai.fr) Profile: the candidate must must hold a recent Master of Science degree in Computer Science or Software Engineering and must have solid skills in dynamic reflective language (Smalltalk). Description of the work: The goal of this PhD is to study Smalltalk integration with FPGAs for robotic applications. This integration will enable us get the best from both worlds. Developers are provided with a high-level dynamic reflective language (Smalltalk) for building and debugging their applications. Still, we can have high performances by projecting part of the programs into FPGAs. These reconfigurable hardware chips can achieve performance faster than C programs, while consuming much less energy. The work to do can decompose into the following tasks: -Build reference robotic applications fully in Pharo Smalltalk using actual robots (see http://car.mines-douai.fr/robots/) -Analyze these applications to identify critical parts to project on FPGAs to significantly increase performances (speed, energy) -Do the actual projection to FPGA and evaluate performances of the transformed applications -Generalize the approach and define a methodology for turning Smalltalk code into FPGA -Propose a solution to automate the methodology The Ph.D student will receive a grant which net amount is approximately 1420 euros per month for 3 years (36 months). He will be co-supervised by Loïc Lagadec from the ENSTA-Bretagne (Lab-STICC, Brest) and Jannik Laval, Luc Fabresse and Noury Bouraqadi from Ecole des Mines de Douai (CAR, http://car.mines-douai.fr/). The first 18th month will be spent in Douai (Lille area), while the last half of the PhD will be spent in Brest. However, during the full 3 years, there will be a strong interaction with co-supervisers from both labs. Bibliography: -A Robust Layered Control System For A Mobile Robot. R. Brooks. IEEE Journal of Robotics and Automation. Vol. 2. Num 1. March, 1985. -RCS: A Cognitive Architecture for Intelligent MultiAgent Systems. J.S. Albus and A. J. Barbera. Proceedings of the 5th IFAC/EURON Symposium on Intelligent Autonomous Vehicles (IAV 2004). Lisbon, Portugal, 2004. -Handbook of Robotics. Bruno Siciliano and Oussama Khatib editors. Springer. 2008. -Multi-Level Simulation of Heterogeneous Reconfigurable Platforms. D. Picard and L. Lagadec. International Journal of Reconfigurable Computing. 2012. -High-level synthesis for FPGAs: From Prototyping to Deployment. Jason cong and stephen neuendorffer and juanjo noguera and kees vissers and zhiru zhang. IEEE Transactions on Computer-aided design of integrated circuits and systems. Vol. 30. Num 4. April, 2011. -The MOLEN Polymorphic Processor. S. Vassiliadis and S. Wong and G. Gaydadjiev and K. Bertels and G. Kuzmanov and E. Moscu Panainte. IEEE Transactions on Computers. 2004. -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] PhD Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications
No one guy accepted and left after a couple of weeks. We know that bad pattern. Stef Encore ?? Personne ne veut venir, c’est ça ? :P Ben On 20 Jan 2014, at 17:01, jannik laval jannik.la...@gmail.com wrote: The position is available now. Interested candidates may apply as soon as possible. Title: Ph.D. Student Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications Location: Mines de Douai and ENSTA Brest (France) Advisor and contacts: Noury Bouraqadi (noury.bouraq...@mines-douai.fr) Luc Fabresse (luc.fabre...@mines-douai.fr) Loïc Lagadec (loic.laga...@ensta-bretagne.fr) Jannik Laval (jannik.la...@mines-douai.fr) Profile: the candidate must must hold a recent Master of Science degree in Computer Science or Software Engineering and must have solid skills in dynamic reflective language (Smalltalk). Description of the work: The goal of this PhD is to study Smalltalk integration with FPGAs for robotic applications. This integration will enable us get the best from both worlds. Developers are provided with a high-level dynamic reflective language (Smalltalk) for building and debugging their applications. Still, we can have high performances by projecting part of the programs into FPGAs. These reconfigurable hardware chips can achieve performance faster than C programs, while consuming much less energy. The work to do can decompose into the following tasks: -Build reference robotic applications fully in Pharo Smalltalk using actual robots (see http://car.mines-douai.fr/robots/) -Analyze these applications to identify critical parts to project on FPGAs to significantly increase performances (speed, energy) -Do the actual projection to FPGA and evaluate performances of the transformed applications -Generalize the approach and define a methodology for turning Smalltalk code into FPGA -Propose a solution to automate the methodology The Ph.D student will receive a grant which net amount is approximately 1420 euros per month for 3 years (36 months). He will be co-supervised by Loïc Lagadec from the ENSTA-Bretagne (Lab-STICC, Brest) and Jannik Laval, Luc Fabresse and Noury Bouraqadi from Ecole des Mines de Douai (CAR, http://car.mines-douai.fr/). The first 18th month will be spent in Douai (Lille area), while the last half of the PhD will be spent in Brest. However, during the full 3 years, there will be a strong interaction with co-supervisers from both labs. Bibliography: -A Robust Layered Control System For A Mobile Robot. R. Brooks. IEEE Journal of Robotics and Automation. Vol. 2. Num 1. March, 1985. -RCS: A Cognitive Architecture for Intelligent MultiAgent Systems. J.S. Albus and A. J. Barbera. Proceedings of the 5th IFAC/EURON Symposium on Intelligent Autonomous Vehicles (IAV 2004). Lisbon, Portugal, 2004. -Handbook of Robotics. Bruno Siciliano and Oussama Khatib editors. Springer. 2008. -Multi-Level Simulation of Heterogeneous Reconfigurable Platforms. D. Picard and L. Lagadec. International Journal of Reconfigurable Computing. 2012. -High-level synthesis for FPGAs: From Prototyping to Deployment. Jason cong and stephen neuendorffer and juanjo noguera and kees vissers and zhiru zhang. IEEE Transactions on Computer-aided design of integrated circuits and systems. Vol. 30. Num 4. April, 2011. -The MOLEN Polymorphic Processor. S. Vassiliadis and S. Wong and G. Gaydadjiev and K. Bertels and G. Kuzmanov and E. Moscu Panainte. IEEE Transactions on Computers. 2004. -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Smalltalk Impact
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. Hi ron What I can tell you is that I invested a lot into squeak (I’m still the guy with the largest number of books about squeak: sbe, botsinc, squeak(fr)), videos, lectures, journal articles, web site, so it was not an easy solution. But this was an important one to keep my smalltalk love and not jump into something or quit definitively. I still want a really cool system to build multimedia systems of the future and for that I dream about robust and cool (clean, lean nicely designed) infrastructure. So we will see where we go. Stef
Re: [Pharo-dev] PhD Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications
Then I hope they will find someone quickly :) Ben PS: My french mail was supposed to be private, but it seams that email is a too complex tool for me :( On 20 Jan 2014, at 17:19, Stéphane Ducasse stephane.duca...@inria.fr wrote: No one guy accepted and left after a couple of weeks. We know that bad pattern. Stef Encore ?? Personne ne veut venir, c’est ça ? :P Ben On 20 Jan 2014, at 17:01, jannik laval jannik.la...@gmail.com wrote: The position is available now. Interested candidates may apply as soon as possible. Title: Ph.D. Student Position on Dynamic Reflective Language Integration with FPGAs for Robotic Applications Location: Mines de Douai and ENSTA Brest (France) Advisor and contacts: Noury Bouraqadi (noury.bouraq...@mines-douai.fr) Luc Fabresse (luc.fabre...@mines-douai.fr) Loïc Lagadec (loic.laga...@ensta-bretagne.fr) Jannik Laval (jannik.la...@mines-douai.fr) Profile: the candidate must must hold a recent Master of Science degree in Computer Science or Software Engineering and must have solid skills in dynamic reflective language (Smalltalk). Description of the work: The goal of this PhD is to study Smalltalk integration with FPGAs for robotic applications. This integration will enable us get the best from both worlds. Developers are provided with a high-level dynamic reflective language (Smalltalk) for building and debugging their applications. Still, we can have high performances by projecting part of the programs into FPGAs. These reconfigurable hardware chips can achieve performance faster than C programs, while consuming much less energy. The work to do can decompose into the following tasks: -Build reference robotic applications fully in Pharo Smalltalk using actual robots (see http://car.mines-douai.fr/robots/) -Analyze these applications to identify critical parts to project on FPGAs to significantly increase performances (speed, energy) -Do the actual projection to FPGA and evaluate performances of the transformed applications -Generalize the approach and define a methodology for turning Smalltalk code into FPGA -Propose a solution to automate the methodology The Ph.D student will receive a grant which net amount is approximately 1420 euros per month for 3 years (36 months). He will be co-supervised by Loïc Lagadec from the ENSTA-Bretagne (Lab-STICC, Brest) and Jannik Laval, Luc Fabresse and Noury Bouraqadi from Ecole des Mines de Douai (CAR, http://car.mines-douai.fr/). The first 18th month will be spent in Douai (Lille area), while the last half of the PhD will be spent in Brest. However, during the full 3 years, there will be a strong interaction with co-supervisers from both labs. Bibliography: -A Robust Layered Control System For A Mobile Robot. R. Brooks. IEEE Journal of Robotics and Automation. Vol. 2. Num 1. March, 1985. -RCS: A Cognitive Architecture for Intelligent MultiAgent Systems. J.S. Albus and A. J. Barbera. Proceedings of the 5th IFAC/EURON Symposium on Intelligent Autonomous Vehicles (IAV 2004). Lisbon, Portugal, 2004. -Handbook of Robotics. Bruno Siciliano and Oussama Khatib editors. Springer. 2008. -Multi-Level Simulation of Heterogeneous Reconfigurable Platforms. D. Picard and L. Lagadec. International Journal of Reconfigurable Computing. 2012. -High-level synthesis for FPGAs: From Prototyping to Deployment. Jason cong and stephen neuendorffer and juanjo noguera and kees vissers and zhiru zhang. IEEE Transactions on Computer-aided design of integrated circuits and systems. Vol. 30. Num 4. April, 2011. -The MOLEN Polymorphic Processor. S. Vassiliadis and S. Wong and G. Gaydadjiev and K. Bertels and G. Kuzmanov and E. Moscu Panainte. IEEE Transactions on Computers. 2004. -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Making Platform Installers
On Mon, Jan 20, 2014 at 4:50 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: May be we should turn that into a chapter. that's on my todo, I told you already :-). Because now, I know how to create installers for Mac and Windows and how to create deb packages for Debian/Ubuntu. I also know a bit about preparing an image for deployment. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Making Platform Installers
super cool On 20 Jan 2014, at 21:25, Damien Cassou damien.cas...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:50 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: May be we should turn that into a chapter. that's on my todo, I told you already :-). Because now, I know how to create installers for Mac and Windows and how to create deb packages for Debian/Ubuntu. I also know a bit about preparing an image for deployment. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Making Platform Installers
Thanks Torsten! here it goes. http://car.mines-douai.fr/squeaksource/MiddlewareDeployer.html 2014/1/20 Torsten Bergmann asta...@gmx.de Hi Santiago, when sending a link from a SqueakSource instance please send the project name like: http://car.mines-douai.fr/squeaksource/MyKillerApp.html The link you used http://car.mines-douai.fr/squeaksource/@vLtUOBuLaxNWsghP/UmsTHzMp was an active session and can not be used by others since it will alway end up on the frontpage. Bye T.
Re: [Pharo-dev] Smalltalk Impact
the way I see it the fork really worked in your favor as Pharo is doing very well so far. Its hard to fork but even harder to share the same vision. Personally I really love the fact that Pharo is made up of open minded people and that you are open to new ideas, yet you have the discipline to set realistic goals and achieve them. I have no doubt that Pharo can only get more popular because this combination, I think, is what modern coding really lacks. On Monday, 20 January 2014, 22:20, Stéphane Ducasse stephane.duca...@inria.fr wrote: 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. Hi ron What I can tell you is that I invested a lot into squeak (I’m still the guy with the largest number of books about squeak: sbe, botsinc, squeak(fr)), videos, lectures, journal articles, web site, so it was not an easy solution. But this was an important one to keep my smalltalk love and not jump into something or quit definitively. I still want a really cool system to build multimedia systems of the future and for that I dream about robust and cool (clean, lean nicely designed) infrastructure. So we will see where we go. Stef
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe s...@stfx.eu wrote: 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. Strange ... When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI . No PharoDebug.log output. Because that do not crash just over lag. Due to the UI. Events ? Multi-processing ? How ? Use Jean-Baptiste's VM from here: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Compilation/40/artifact/results.tar.gz 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 Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com
Re: [Pharo-dev] Making Platform Installers
On Mon, Jan 20, 2014 at 9:33 PM, Pharo4Stef pharo4s...@free.fr wrote: super cool first draft: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Deployment/Deployment.pier.html -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
NewValueHolder? the name sounds like a Squeak strategy: keep backward compatibility as long as possible. Since Pharo values cleanlyDesigned backwardCompatible, I would expect ValueHolder-LegacyValueHolder and NewValueHolder-ValueHolder. We had too many NewParagraph, etc... in the past, history does not necessarily have to repeat itself ;) 2014/1/20 Stéphane Ducasse stephane.duca...@inria.fr I commented the code in a slice that apparently was not integrated. But yes this is a good idea. - to have more code review - to revive the COTDC I had some questions about NewValueHolder and I figured, why not revive COTDC?! The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? - is the Value Holder part of the name accurate in light of [1]. Obviously repurposing a term people may already be familiar with is a bad idea. In fact the important part here seems not the holding of the value, but the notification of changes. It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what? - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples [1] http://en.wikipedia.org/wiki/Lazy_loading p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] [pharo-project/pharo-core] 88ae1c: 30711
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 88ae1cfac835af58191d4ebccf4dc2bf60707ca2 https://github.com/pharo-project/pharo-core/commit/88ae1cfac835af58191d4ebccf4dc2bf60707ca2 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-01-20 (Mon, 20 Jan 2014) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/source code area/defaultClassDescriptor.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/selectedClassDescription.st M Nautilus.package/PackageTreeNautilusUI.class/instance/source code area/defaultClassDescriptor.st A Nautilus.package/extension/Class/instance/definitionForNautilus.st A Nautilus.package/extension/ClassDescription/instance/definitionForNautilus.st A Nautilus.package/extension/TraitDescription/instance/definitionForNautilus.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script364.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30711.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/SpecDebugger.class/class/utilities/closeAllDebuggers.st A Traits.package/TClass.class/instance/subclass creation/subclass_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/subclass_uses_instanceVariableNames_classVariableNames_category_.st M Traits.package/TClass.class/instance/subclass creation/subclass_uses_instanceVariableNames_classVariableNames_poolDictionaries_category_.st Log Message: --- 30711 12163 New class template without poolDictionaries: line https://pharo.fogbugz.com/f/cases/12163 12632 window menu close all debuggers does not work anymore https://pharo.fogbugz.com/f/cases/12632 http://files.pharo.org/image/30/30711.zip
[Pharo-dev] you spin me around...
Hi!Juraj worked on rotating text. People have been asking for it for years…With Roassal 2:-=-=-=-=-=-=-=-=-=-=| v shape |v := RTView new.shape := RTRotatedLabel new.shape angleInDegree: [ :cls | cls numberOfMethods negated / 1.5 ].shape text: [ :cls | ' ', cls name ].shape color: (Color black alpha: 0.2).v addAll: (shape elementsOn: Collection withAllSubclasses).v canvas color: Color white.v open-=-=-=-=-=-=-=-=-=-=More screenshots and more examples on:https://www.facebook.com/media/set/?set=a.573528479400420.1073741841.340543479365589type=1Excellent job Juraj!Before the end of January, we will make a big big announcement. We, the profilers, are working hard these days on a fantastic infrastructure for a better and stronger visual experience.Cheers,Alexandre--_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:Alexandre Bergel http://www.bergel.eu^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
It is the history of a prototype ending in the system :) Ben On 20 Jan 2014, at 18:02, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: NewValueHolder? the name sounds like a Squeak strategy: keep backward compatibility as long as possible. Since Pharo values cleanlyDesigned backwardCompatible, I would expect ValueHolder-LegacyValueHolder and NewValueHolder-ValueHolder. We had too many NewParagraph, etc... in the past, history does not necessarily have to repeat itself ;) 2014/1/20 Stéphane Ducasse stephane.duca...@inria.fr I commented the code in a slice that apparently was not integrated. But yes this is a good idea. - to have more code review - to revive the COTDC I had some questions about NewValueHolder and I figured, why not revive COTDC?! The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? - is the Value Holder part of the name accurate in light of [1]. Obviously repurposing a term people may already be familiar with is a bad idea. In fact the important part here seems not the holding of the value, but the notification of changes. It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what? - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples [1] http://en.wikipedia.org/wiki/Lazy_loading p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] RFB on a headless Pharo 3
Sharing some experiences… This is on a fresh image with RFB installed and manually patched about the os name and version and removing Beeper invocations. Strangely, after using it with UI and connecting with a vnc client for a while, I’ve stopped the RFB service in this image and then saved Then I’ve tried to run it gui-less suryia:rfb sebastian$ pharo-vm/Pharo.app/Contents/MacOS/Pharo -vm-display-null Pharo.image unknown option: -vm-display-null Usage: [option...] [imageName [argument...]] [option...] -- [argument...] Common options: --help print this help message, then exit --memory size[mk]use fixed heap size (added to image size) --headless run in headless (no window) mode (default: false) --nohandlers disable sigsegv sigusr1 handlers Notes: imageName defaults to `Pharo.image'. If `--memory' is not specified then the heap will grow dynamically. arguments are ignored, but are processed by the Squeak image. The first argument normally names a Squeak `script' to execute. Precede arguments by `--' to use default image. trying with —nodisplay suryia:rfb sebastian$ pharo-vm/Pharo.app/Contents/MacOS/Pharo --nodisplay Pharo.image unknown option: --nodisplay Usage: [option...] [imageName [argument...]] [option...] -- [argument...] Common options: --help print this help message, then exit --memory size[mk]use fixed heap size (added to image size) --headless run in headless (no window) mode (default: false) --nohandlers disable sigsegv sigusr1 handlers Notes: imageName defaults to `Pharo.image'. If `--memory' is not specified then the heap will grow dynamically. arguments are ignored, but are processed by the Squeak image. The first argument normally names a Squeak `script' to execute. Precede arguments by `--' to use default image. trying with —headless suryia:rfb sebastian$ pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless Pharo.image Usage: [--no-preferences|--preference-file=FILE][subcommand] [--help] [--copyright] [--version] [--list] [ --no-quit ] --help print this help message --copyright print the copyrights --versionprint the version for the image and the vm --list list a description of all active command line handlers --no-quitkeep the image running without activating any other command line handler subcommand a valid subcommand in --list Preference File Modification: --preference-file load the preferences from the given FILE --no-default-preferencesdo not load any preferences from the default locations Documentation: A PharoCommandLineHandler handles default command line arguments and options. The PharoCommandLineHandler is activated before all other handlers. It first checks if another handler is available. If so it will activate the found handler. no crash dumps no PharoDegug.log this time =/ ideas? On Jan 20, 2014, at 3:58 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: 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 sebast...@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/
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
2014/1/20 Benjamin benjamin.vanryseghem.ph...@gmail.com On 20 Jan 2014, at 15:36, Sean P. DeNigris s...@clipperadams.com wrote: I had some questions about NewValueHolder and I figured, why not revive COTDC?! I loved it :) The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? I am a class holding any object inside its unique instance variable. Each time the instance variable value changes, an announcement is emitted. we should distinguish between storing a object and change a value. At the moment, NewValueHolder announces every time we store into this value holder regardless wether the value changed.
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
On 20 Jan 2014, at 19:24, Nicolai Hess nicolaih...@web.de wrote: we should distinguish between storing a object and change a value. At the moment, NewValueHolder announces every time we store into this value holder regardless wether the value changed. That’s true. It was not clear enough :) Thanks, Ben
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
Benjamin Van Ryseghem-2 wrote In addition, infinite loops of propagation are prevented. Is that what lock is all about? I was wondering... - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066p4738129.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] you spin me around...
On 20 January 2014 23:21, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! Juraj worked on rotating text. People have been asking for it for years… With Roassal 2: -=-=-=-=-=-=-=-=-=-= | v shape | v := RTView new. shape := RTRotatedLabel new. why you need separate class for 'rotated' label? i suppose you also need RTRotatedAndScaledLabel, RTRotatedAndScewedLabel .. as well as other (infinite) number of permutations with 'something-ed' and 'Label'. or its just a prototype? shape angleInDegree: [ :cls | cls numberOfMethods negated / 1.5 ]. shape text: [ :cls | ' ', cls name ]. shape color: (Color black alpha: 0.2). v addAll: (shape elementsOn: Collection withAllSubclasses). v canvas color: Color white. v open -=-=-=-=-=-=-=-=-=-= More screenshots and more examples on: https://www.facebook.com/media/set/?set=a.573528479400420.1073741841.340543479365589type=1 Excellent job Juraj! Before the end of January, we will make a big big announcement. We, the profilers, are working hard these days on a fantastic infrastructure for a better and stronger visual experience. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Best regards, Igor Stasenko. 1487299_575836899169578_843345537_n.png
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
Hi Jean Baptiste, On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud jbaptiste.arn...@gmail.com wrote: On 20 Jan 2014, at 19:32, Sven Van Caekenberghe s...@stfx.eu wrote: 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. Strange ... Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know. When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI . Hmm, it really didn't do anything, I try again. No PharoDebug.log output. Because that do not crash just over lag. Due to the UI. I just meant to say there were no errors ;-) Sending USR1 didn't reveal much either (no weird loops). I still think there is something wrong, does it work for you ? Sven Events ? Multi-processing ? How ? Use Jean-Baptiste's VM from here: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Compilation/40/artifact/results.tar.gz 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 Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com
[Pharo-dev] NewVersionBrowser
Hi, I finished case 11714 https://pharo.fogbugz.com/default.asp?11714NewVersionBrowser needs to be finished. The changes are integrated and the case is closed. What I did, I create a new SLICE with Benjamins latest changes cleaned from all merge conflicts. Add the missing pieces for diff display with DiffMorph Finished the menu There is currently one issue with the version list sorting, I 'll make a new bug entry for this, soon. If you encounter any issues, please don't reopen this case but create a new one. I omit the Tools registry changes until I have done some more testings and there are no issues left. I have remaining question: With the side-by-side diff where to put the selected version and where the prior version? Currently (Old-)VersionBrowser shows the selected version on the right and the prior version on the left. This looks a bit strange. I would like to chang this.
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
On 20 Jan 2014, at 19:31, Sean P. DeNigris s...@clipperadams.com wrote: Benjamin Van Ryseghem-2 wrote In addition, infinite loops of propagation are prevented. Is that what lock is all about? I was wondering... Yes :) Ben
Re: [Pharo-dev] NewVersionBrowser
On 20 Jan 2014, at 20:18, Nicolai Hess nicolaih...@web.de wrote: Hi, I finished case 11714 NewVersionBrowser needs to be finished. The changes are integrated and the case is closed. Cool :) I have remaining question: With the side-by-side diff where to put the selected version and where the prior version? Currently (Old-)VersionBrowser shows the selected version on the right and the prior version on the left. That is how it is in “all” the diff in Pharo :) old on the left, new on the right. This looks a bit strange. Why? Ben
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
I made an issue summarizing this thread. I'll take care of it when comments die down here… https://pharo.fogbugz.com/default.asp?12684 - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066p4738150.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Making Platform Installers
Super very cool! Thank you for this. It is important. Doru On Mon, Jan 20, 2014 at 9:33 PM, Pharo4Stef pharo4s...@free.fr wrote: super cool On 20 Jan 2014, at 21:25, Damien Cassou damien.cas...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:50 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: May be we should turn that into a chapter. that's on my todo, I told you already :-). Because now, I know how to create installers for Mac and Windows and how to create deb packages for Debian/Ubuntu. I also know a bit about preparing an image for deployment. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Anyone with the passwd to edit http://book.pharo-project.org/book/PharoTools/
On 18 Jan 2014, at 11:26, Marcus Denker marcus.den...@inria.fr wrote: 10231 collaboractive Book: Page about Pharo Tools is out of date https://pharo.fogbugz.com/f/cases/10231 — the action needed to close this issue tracker entry is to remove the Other Pharo Non Core Packages” section. If this issue is not fixed until Feb1, I will close it and replace it with “remove DNS entry book.pharo-project.org”. Marcus
Re: [Pharo-dev] Making Platform Installers
Excellent After we can flesh it nicely. Stef On 20 Jan 2014, at 21:55, Damien Cassou damien.cas...@gmail.com wrote: On Mon, Jan 20, 2014 at 9:33 PM, Pharo4Stef pharo4s...@free.fr wrote: super cool first draft: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Deployment/Deployment.pier.html -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] NewVersionBrowser
On 21 Jan 2014, at 00:19, Nicolai Hess nicolaih...@web.de wrote: Hi, I finished case 11714 NewVersionBrowser needs to be finished. The changes are integrated and the case is closed. Very nice! I omit the Tools registry changes until I have done some more testings and there are no issues left. I have remaining question: With the side-by-side diff where to put the selected version and where the prior version? Currently (Old-)VersionBrowser shows the selected version on the right and the prior version on the left. This looks a bit strange. I would make sure it works the same as the Monticello diff… and left original, right change seems to be what it does? Marcus
Re: [Pharo-dev] Anyone with the passwd to edit http://book.pharo-project.org/book/PharoTools/
On 21 Jan 2014, at 07:59, Marcus Denker marcus.den...@inria.fr wrote: On 18 Jan 2014, at 11:26, Marcus Denker marcus.den...@inria.fr wrote: 10231 collaboractive Book: Page about Pharo Tools is out of date https://pharo.fogbugz.com/f/cases/10231 — the action needed to close this issue tracker entry is to remove the Other Pharo Non Core Packages” section. If this issue is not fixed until Feb1, I will close it and replace it with “remove DNS entry book.pharo-project.org”. Marcus why don’t you say that this is a bit updated. How do you think that we can manage it? It is not possible. Now do you that there is tokyoTyrant? I would let it. Stef Marcus
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
Hi nicolas. I do not remember but it seems that I did a slice to move NewValueHolder out of Spec inside their own package. Then we should rename and remove the old one but it takes time and if somebody does it will go faster. Stef NewValueHolder? the name sounds like a Squeak strategy: keep backward compatibility as long as possible. Since Pharo values cleanlyDesigned backwardCompatible, I would expect ValueHolder-LegacyValueHolder and NewValueHolder-ValueHolder. We had too many NewParagraph, etc... in the past, history does not necessarily have to repeat itself ;) 2014/1/20 Stéphane Ducasse stephane.duca...@inria.fr I commented the code in a slice that apparently was not integrated. But yes this is a good idea. - to have more code review - to revive the COTDC I had some questions about NewValueHolder and I figured, why not revive COTDC?! The current comment is: A NewValueHolder is a new implementation of ValueHolder based on Announcements. Of course, ValueHolder doesn't have a class comment. Wikipedia claims a value holder is a generic object that handles the lazy loading behavior, and appears in place of the object's data fields [1]. So: - what is a NewValueHolder? - is the Value Holder part of the name accurate in light of [1]. Obviously repurposing a term people may already be familiar with is a bad idea. In fact the important part here seems not the holding of the value, but the notification of changes. It seems more like an event in FRP. How about ReactiveVariable or AnnouncingVariable, since it combines the storage of a variable with announcing of changes? I like Reactive a bit better because those familiar with FRP will get the idea that it's notifying dependents, Announcing maybe begs the question announcing what? - should it replace ValueHolder, which is used only by ExclusiveWeakMessageSend and WidgetExamples [1] http://en.wikipedia.org/wiki/Lazy_loading p.s. [OT] valueChanged: oldValue to: newValue seems fishy. It is only used in one place in the image in this weird way pickedItemsHolder valueChanged: true to: item - Cheers, Sean -- View this message in context: http://forum.world.st/COTDC-108-NewValueHolder-tp4738066.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [COTDC] 108 - NewValueHolder
Since nobody looks at it: here are the issue (they contain class comments). https://pharo.fogbugz.com/default.asp?12572 https://pharo.fogbugz.com/default.asp?12486 Apparently all the work I did around Spec is not reviewed. May be I should push them without waiting from any feedback. Stef
Re: [Pharo-dev] [Moose-dev] you spin me around...
-=-=-=-=-=-=-=-=-=-= | v shape | v := RTView new. shape := RTRotatedLabel new. why you need separate class for 'rotated' label? i suppose you also need RTRotatedAndScaledLabel, RTRotatedAndScewedLabel .. as well as other (infinite) number of permutations with 'something-ed' and 'Label'. or its just a prototype? I asked myself the same. Why Label can not do everyhing? Stef shape angleInDegree: [ :cls | cls numberOfMethods negated / 1.5 ]. shape text: [ :cls | ' ', cls name ]. shape color: (Color black alpha: 0.2). v addAll: (shape elementsOn: Collection withAllSubclasses). v canvas color: Color white. v open -=-=-=-=-=-=-=-=-=-= More screenshots and more examples on: https://www.facebook.com/media/set/?set=a.573528479400420.1073741841.340543479365589type=1 Excellent job Juraj! Before the end of January, we will make a big big announcement. We, the profilers, are working hard these days on a fantastic infrastructure for a better and stronger visual experience. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Best regards, Igor Stasenko. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] Anyone with the passwd to edit http://book.pharo-project.org/book/PharoTools/
On 21 Jan 2014, at 08:46, Stéphane Ducasse stephane.duca...@inria.fr wrote: On 21 Jan 2014, at 07:59, Marcus Denker marcus.den...@inria.fr wrote: On 18 Jan 2014, at 11:26, Marcus Denker marcus.den...@inria.fr wrote: 10231 collaboractive Book: Page about Pharo Tools is out of date https://pharo.fogbugz.com/f/cases/10231 — the action needed to close this issue tracker entry is to remove the Other Pharo Non Core Packages” section. If this issue is not fixed until Feb1, I will close it and replace it with “remove DNS entry book.pharo-project.org”. Marcus why don’t you say that this is a bit updated. To whom? Where? What? What I want is that someone closes the issue tracker entry with “DONE”. How do you think that we can manage it? Someone with the password need to *do it*. I do not know how things can happen if nobody does it. Especially simple things. (I do not have the pass, so I can not do anything) It is not possible. Now do you that there is tokyoTyrant? No, isn’t that a database? I have no idea even what it could mean in the context of this discussion... Marcus