[Pharo-dev] Question on Unclassified / _UnpackagedPackage

2014-01-20 Thread Goubier Thierry

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

2014-01-20 Thread Tudor Girba
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

2014-01-20 Thread Damien Cassou
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

2014-01-20 Thread Tudor Girba
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

2014-01-20 Thread Sven Van Caekenberghe

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

2014-01-20 Thread Stéphane Ducasse
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

2014-01-20 Thread 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




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

2014-01-20 Thread btc




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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread btc




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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread 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/

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

2014-01-20 Thread 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 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

2014-01-20 Thread 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 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

2014-01-20 Thread 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-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

2014-01-20 Thread Pharo4Stef
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

2014-01-20 Thread Sean P. DeNigris
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

2014-01-20 Thread Santiago Bragagnolo
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

2014-01-20 Thread Torsten Bergmann
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

2014-01-20 Thread Torsten Bergmann
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Pharo4Stef

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

2014-01-20 Thread Stéphane Ducasse
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Stéphane Ducasse
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

2014-01-20 Thread Stéphane Ducasse

 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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Damien Cassou
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

2014-01-20 Thread Pharo4Stef
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

2014-01-20 Thread Santiago Bragagnolo
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

2014-01-20 Thread dimitris chloupis
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

2014-01-20 Thread Jean Baptiste Arnaud

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

2014-01-20 Thread Damien Cassou
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

2014-01-20 Thread Nicolas Cellier
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

2014-01-20 Thread GitHub
  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...

2014-01-20 Thread Alexandre Bergel
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Sebastian Sastre

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-01-20 Thread Nicolai Hess
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Sean P. DeNigris
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...

2014-01-20 Thread Igor Stasenko
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

2014-01-20 Thread Sven Van Caekenberghe
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

2014-01-20 Thread Nicolai Hess
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Benjamin
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

2014-01-20 Thread Sean P. DeNigris
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

2014-01-20 Thread Tudor Girba
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/

2014-01-20 Thread Marcus Denker

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

2014-01-20 Thread Stéphane Ducasse
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

2014-01-20 Thread Marcus Denker

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/

2014-01-20 Thread Stéphane Ducasse

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

2014-01-20 Thread Stéphane Ducasse
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

2014-01-20 Thread Stéphane Ducasse
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...

2014-01-20 Thread Stéphane Ducasse
 
 
 -=-=-=-=-=-=-=-=-=-=
 | 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/

2014-01-20 Thread Marcus Denker

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