Re: [Pharo-project] A Pharo launcher

[Erwan Douaille]

Same with Fernando :
http://forum.world.st/Pharo-Launcher-app-td4238576.html

2013/4/24 Serge Stinckwich 

> Nice initiative ! There was already something similar done by
> a korean guy: HwaJong Oh (https://twitter.com/Daliot )
> called Pharo Launcher that works only for mac os x.
>
> Regards,
>
> On Mon, Apr 22, 2013 at 11:14 PM, Damien Cassou 
> wrote:
> > I think the idea to have a Pharo launcher that lets the user pick a
> > Pharo template (either bare pharo 2.0, pharo+seaside,
> > pharo+seaside+mongodb+
> > magritte+voyage, pharo+pier, ...) and then create
> > a new image the user must save somewhere is important. I want people
> > to have one Pharo icon on their desk and just click it (like in
> > Eclipse, word processors, virtual box...). Here is a set of
> > requirements for such an application, please comment.
> >
> > - must be implemented in Pharo 2.0 with maintained technology (spec or
> glamour)
> > - must be cross-platform (we want 1 application for all Pharo users)
> > - must download the list of templates from internet (so that we don't
> > have to update the application all the time)
> > - must propose different kinds of template (stable/unstable, desktop/web)
> > - must rapidly create an image out of the selected template (either by
> > downloading Fueled packages, or by downloading ready-made images)
> > - must cache the created images so that they do not have to be
> > recreated all the time (except when a newer version is available)
> > - must force the user to copy the created image so he can freely
> > change it and crash it without impacting the cache of created images.
> > - must present a list of recently launched images so that the user can
> > just pick a recent image instead of creating a new one
> >
> >
> > Please comment (and implement this idea)
> >
> > --
> > Damien Cassou
> > http://damiencassou.seasidehosting.st
> >
> > "Success is the ability to go from one failure to another without
> > losing enthusiasm."
> > Winston Churchill
> >
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>


-- 
Best regards,

Douaille Erwan 

Re: [Pharo-project] A Pharo launcher

[Serge Stinckwich]

Nice initiative ! There was already something similar done by
a korean guy: HwaJong Oh (https://twitter.com/Daliot )
called Pharo Launcher that works only for mac os x.

Regards,

On Mon, Apr 22, 2013 at 11:14 PM, Damien Cassou  wrote:
> I think the idea to have a Pharo launcher that lets the user pick a
> Pharo template (either bare pharo 2.0, pharo+seaside,
> pharo+seaside+mongodb+
> magritte+voyage, pharo+pier, ...) and then create
> a new image the user must save somewhere is important. I want people
> to have one Pharo icon on their desk and just click it (like in
> Eclipse, word processors, virtual box...). Here is a set of
> requirements for such an application, please comment.
>
> - must be implemented in Pharo 2.0 with maintained technology (spec or 
> glamour)
> - must be cross-platform (we want 1 application for all Pharo users)
> - must download the list of templates from internet (so that we don't
> have to update the application all the time)
> - must propose different kinds of template (stable/unstable, desktop/web)
> - must rapidly create an image out of the selected template (either by
> downloading Fueled packages, or by downloading ready-made images)
> - must cache the created images so that they do not have to be
> recreated all the time (except when a newer version is available)
> - must force the user to copy the created image so he can freely
> change it and crash it without impacting the cache of created images.
> - must present a list of recently launched images so that the user can
> just pick a recent image instead of creating a new one
>
>
> Please comment (and implement this idea)
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>



-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

[Pharo-project] [ANN] Pharo VM for Ubuntu moved!

[Damien Cassou]

After a request from Esteban, I changed the Pharo VM PPA location from
ppa:cassou/pharo to ppa:pharo/stable. Please issue the following
commands to update your system:

$ sudo rm -f /etc/apt/sources.list.d/cassou-emacs-quantal.list
$ sudo add-apt-repository ppa:pharo/stable
$ sudo apt-get update


Sorry for the additional effort

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-project] Metacello Preview

[Ben Coman]

DeNigris Sean wrote:

[cross posted to pharo-project and squeak-dev]

Dale has done some really cool work on Metacello! From the original 
announcement at 
http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-td4642064.html :
  
The Metacello Preview release provides the following features: 

 - Metacello Scripting API (user guide[1] and reference[2]) 
 - Metacello-Base package for inclusion in Squeak/Pharo base images 
 - support for git and GitHub (filetree:// and github:// repository loaded) 



In typical Dale fashion, he wants to provide our community with as much value as 
possible, so he's been tentative to release his "preview" version until he gets 
feedback from users and can tailor it to our real-world needs.

I feel, after checking with Dale, that integrating the preview into Pharo and 
Squeak trunk now will provide a balance between exposure and malleability, to 
make sure we have an API we'll all love by the next respective releases.

Cheers,
Sean
  
It natural to want to minimise harm to others by releasing something 
Clean And Shiny, but the other side of the coin is "Release Early 
Release Often" [1].  Although having said that, I notice my own 
behaviour is more CAS than RERO at the moment.  I'll have to work on that.


cheers -ben

[1] 
http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html

Re: [Pharo-project] Processes, what are they doing?

[Michael van der Gulik]

On Wed, Apr 24, 2013 at 11:58 AM, Igor Stasenko  wrote:

>
>
> In practice it means that one should not write:
> [ ... ] fork
>
> but
>
> [ ... ] forkWithDescription: 'i doing this that and there'
>
>
Was BlockContext>>forkNamed: removed from the image?

Gulik

-- 
http://gulik.pbwiki.com/

Re: [Pharo-project] Processes, what are they doing?

[Chris Muller]

On Tue, Apr 23, 2013 at 6:58 PM, Igor Stasenko  wrote:
> Have you ever seen the list of processes running under your OS?
> There's many, isn't?
> The operating systems may be different, but i'd like to tell, what is
> common between all of them:
>  - by looking at list of processes you have no idea what each of them
> there for, nor what are they doing.
>
> For instance, my  home windows machine has strange peaks of disk
> activity (when it supposed to be idle, since it is not touched
> more than a hour)...
> now this is annoying that i cannot ask system in easy way, what is
> going on and why such heavy disk activity is needed,
> and disable such "very important feature"..

Under Linux you can.

> Today's systems grown too large and too clever, where user more and
> more feels like a passenger (which request to stop the train can be
> silently ignored), rather than driver of the train who can stop it at
> any moment.
>
> ...snip...
>
> Sure thing, i am not proposing to change the world and fix today's
> operating systems, but what i thought that at least in Pharo we have a
> good
> opportunity to fix that.
>
> I think it would be beneficial to establish a quality standard (or at
> least make an attempt to move closer to it):
>  - each running process should have a description what its purpose and
> who/what running it, as well as how to terminate it in non-abrupt way.
>
> In practice it means that one should not write:
> [ ... ] fork
>
> but
>
> [ ... ] forkWithDescription: 'i doing this that and there'
>
> or even:
>
> [ ... ] forkWithDescription: 'i doing this that and there'
> toTerminateDo: [.. block for graciously terminating this process
> regardless in which state it currently is ]

When I want to name my process I simply avoid the fork shortcut:

  [ ... ] newProcess
  name: 'processing items' ;
  resume

I think this is elegant enough to not need forkWithDescription:.

> So, my question are you with me or not? :)
> And how far?
>
> 0 - keep things as they are
> ...
> 1 - deprecate all protocols which allow anonymous process creation,
> and force developers to always put a description for every #fork in
> their code.
> (or simply refuse to #resume the process unless its description is not nil ;)
>
> There is already field in Process - name. But it is not enforced by
> system that it should be never nil. I am not sure if we need both name
> and description
> or we need just one field (which will serve for both). What i am sure
> about is that anonymous processes are BAD.

I think all caps overstates it a bit.  Forcing the user into an
unnecessary API will not help achieve your goal of more lucidity in
the system.

Maybe a user just wants to open up a workspace and start playing
around with Smalltalk processes and show a stranger sitting next to on
a plane as a demo how easy it is.  He makes some processes in some
workspace code and "naming" them via temp variables.  So if he is
forced to type in a full descriptive name just to satisfy the API, it
is distracting so what is he gonna do?  "xxx" will be the name of his
processes because he didn't want to be bothered with that.  No
computer can force a human to be clean and organized.

I think this type of idea belongs more at an "App-Studio" level than
in the general-purpose programming kit (Pharo).  That's why
MaClientProcess is part of the core-extensions package of the "Ma"
application suite.  MaClientProcess provides app developers a nice
wrapper of a Process that handles name+description, current item being
worked, progress, pause, resume and graceful terminate.  The only
requirement of the app is that it send #advance to the MaClientProcess
occasionally to support graceful pause/resume/cancel.  Based on the
frequency the app sends #advance, MaClientProcess automatically
calculates the "rate" of processing items and, if its #taskSize: has
been specified, the calculated #timeRemaining.
<>

Re: [Pharo-project] Processes, what are they doing?

[Benoit St-Jean]

Or option #2.  Issue a warning for now and deprecated #fork.  This will give 
people some time to fix their code. 


 
-
Benoit St-Jean
Yahoo! Messenger: bstjean
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)


>
> From: Igor Stasenko 
>To: Pharo Development  
>Sent: Tuesday, April 23, 2013 7:58:26 PM
>Subject: [Pharo-project] Processes, what are they doing?
> 
>
>Have you ever seen the list of processes running under your OS?
>There's many, isn't?
>The operating systems may be different, but i'd like to tell, what is
>common between all of them:
>- by looking at list of processes you have no idea what each of them
>there for, nor what are they doing.
>
>For instance, my  home windows machine has strange peaks of disk
>activity (when it supposed to be idle, since it is not touched
>more than a hour)...
>now this is annoying that i cannot ask system in easy way, what is
>going on and why such heavy disk activity is needed,
>and disable such "very important feature"..
>Today's systems grown too large and too clever, where user more and
>more feels like a passenger (which request to stop the train can be
>silently ignored), rather than driver of the train who can stop it at
>any moment.
>
>Since i cannot tell, what each process doing on my machine.. i cannot
>control them.
>There's of course a solution: i should spend hours with google , read
>docs & manuals
>and in general, look for anywhere else, rather than simply ask a
>process: what are you doing, what is your responsibility and who runs
>you and why.
>
>Besides, if i cannot ask the process, my study of a system is more or
>less just a waste of time, because even if i learn everything,
>tomorrow it will be different OS version or different OS, where
>everything will be completely different, and there we starting over
>again: having a list of processes and no clue which is responsible for
>what and do you need it or not.
>
>Sure thing, i am not proposing to change the world and fix today's
>operating systems, but what i thought that at least in Pharo we have a
>good
>opportunity to fix that.
>
>I think it would be beneficial to establish a quality standard (or at
>least make an attempt to move closer to it):
>- each running process should have a description what its purpose and
>who/what running it, as well as how to terminate it in non-abrupt way.
>
>In practice it means that one should not write:
>[ ... ] fork
>
>but
>
>[ ... ] forkWithDescription: 'i doing this that and there'
>
>or even:
>
>[ ... ] forkWithDescription: 'i doing this that and there'
>toTerminateDo: [.. block for graciously terminating this process
>regardless in which state it currently is ]
>
>So, my question are you with me or not? :)
>And how far?
>
>0 - keep things as they are
>...
>1 - deprecate all protocols which allow anonymous process creation,
>and force developers to always put a description for every #fork in
>their code.
>(or simply refuse to #resume the process unless its description is not nil ;)
>
>There is already field in Process - name. But it is not enforced by
>system that it should be never nil. I am not sure if we need both name
>and description
>or we need just one field (which will serve for both). What i am sure
>about is that anonymous processes are BAD.
>
>-- 
>Best regards,
>Igor Stasenko.
>
>
>
>

[Pharo-project] Processes, what are they doing?

[Igor Stasenko]

Have you ever seen the list of processes running under your OS?
There's many, isn't?
The operating systems may be different, but i'd like to tell, what is
common between all of them:
 - by looking at list of processes you have no idea what each of them
there for, nor what are they doing.

For instance, my  home windows machine has strange peaks of disk
activity (when it supposed to be idle, since it is not touched
more than a hour)...
now this is annoying that i cannot ask system in easy way, what is
going on and why such heavy disk activity is needed,
and disable such "very important feature"..
Today's systems grown too large and too clever, where user more and
more feels like a passenger (which request to stop the train can be
silently ignored), rather than driver of the train who can stop it at
any moment.

Since i cannot tell, what each process doing on my machine.. i cannot
control them.
There's of course a solution: i should spend hours with google , read
docs & manuals
and in general, look for anywhere else, rather than simply ask a
process: what are you doing, what is your responsibility and who runs
you and why.

Besides, if i cannot ask the process, my study of a system is more or
less just a waste of time, because even if i learn everything,
tomorrow it will be different OS version or different OS, where
everything will be completely different, and there we starting over
again: having a list of processes and no clue which is responsible for
what and do you need it or not.

Sure thing, i am not proposing to change the world and fix today's
operating systems, but what i thought that at least in Pharo we have a
good
opportunity to fix that.

I think it would be beneficial to establish a quality standard (or at
least make an attempt to move closer to it):
 - each running process should have a description what its purpose and
who/what running it, as well as how to terminate it in non-abrupt way.

In practice it means that one should not write:
[ ... ] fork

but

[ ... ] forkWithDescription: 'i doing this that and there'

or even:

[ ... ] forkWithDescription: 'i doing this that and there'
toTerminateDo: [.. block for graciously terminating this process
regardless in which state it currently is ]

So, my question are you with me or not? :)
And how far?

0 - keep things as they are
...
1 - deprecate all protocols which allow anonymous process creation,
and force developers to always put a description for every #fork in
their code.
(or simply refuse to #resume the process unless its description is not nil ;)

There is already field in Process - name. But it is not enforced by
system that it should be never nil. I am not sure if we need both name
and description
or we need just one field (which will serve for both). What i am sure
about is that anonymous processes are BAD.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-project] NativeBoost label call

[Igor Stasenko]

Hi, Guido,
hmm... as far as i remember, there should be already support for that in asmjit.
I remember we did something about it not long ago.
But i will check.

On 23 April 2013 22:02, Guido Chari  wrote:
> Hi Igor,
>
> I need support to call labels in Waterfall. I used to have a changeset with
> this changes.
>
> But now i want to put Waterfall on Jenkins. So it would be easier if NB
> already has the implementation. Otherwise i would need to load a changeset
> after loading WF code through Metacello.
>
> I attach you my changes so you can check if you want to integrate them. If
> you prefer not to integrate them just tell me so i check for the other
> solution.
>
> Cheers,
> Guido.
>
>



-- 
Best regards,
Igor Stasenko.

[Pharo-project] NativeBoost label call

[Guido Chari]

Hi Igor,

I need support to call labels in Waterfall. I used to have a changeset with
this changes.

But now i want to put Waterfall on Jenkins. So it would be easier if NB
already has the implementation. Otherwise i would need to load a changeset
after loading WF code through Metacello.

I attach you my changes so you can check if you want to integrate them. If
you prefer not to integrate them just tell me so i check for the other
solution.

Cheers,
Guido.


AJLabelCall.st
Description: Binary data


NBLabel.st
Description: Binary data

[Pharo-project] the future of #stable in Metacello

[Dale Henrichs]

I've cross-posted to pharo and metacello mailing list ... I'd prefer that the 
ongoing (possibly gory discussion:) take place on the metacello list, but since 
symbolic versions have been discussed on the pharo list it might make sense to 
keep the discussion in the pharo list ...

First a bit of background. 

Symbolic versions were introduced because we were facing a situation where 
developers were breaking projects that were working fine in Pharo1.3 while 
porting them to Pharo1.4 and breaking Pharo1.4 behavior while fixing bugs in 
Pharo1.3 ...

Metacello was pretty new then and an attempt was being made to have folks use 
Pharo1.4 while it was still in development and there were enough changes in 
Pharo1.4 that some code would break in Pharo1.4 while working in Pharo1.3 ... 
The real problem though was that project dependencies became difficult to 
manage in a number of different dimensions:

  - projects would change existing versions to work on 
the new platform version and break the old platform
version
  - projects would create a new version that would run on
both platforms, so dependent projects would to depend
pon a new version
  - projects would create a new version that would run on
only one platform, so dependent projects would have to 
depend upon 2 different versions based on platform
version

These types of things in isolation would be manageable, but the rate of change 
was high and changes propogated faster than configuration managers could keep 
up with. Oh and don't forget the projects where the maintainers were not even 
using Metacello at all and a third party developer had to translate the 
projects changes to a configuration to keep things working...

Symbolic versions were introduced as a stopgap measure that made it possible 
for folks to easily declare which versions of the project were intended to be 
used on a particular platform. Dependent projects could depend upon the #stable 
version and the whole dependency management universe became simpler. Symbolic 
versions made it practical to port code to Pharo1.4 without impacting Pharo1.3 
and so on. 

Which brings us to the present and a slightly different situation, but first 
let's step back a bit and look at what we have in Metacello today.

In Metacello, a version is a label applied to a specific collection of mcz 
files. The collection of mcz files may be different depending upon which 
platform you happen to be loading the project into, but in the end, the same 
version on different platforms should give one the same set of functionality. 

Once a version has been released (indicated by a #release blessing) the 
contents of that collection of mcz files should never change ... If a change 
_is_ made, once should create a new version of the project to reflect that 
something has changed.

In Metacello there are platform attributes (i.e., #'pharo1.x', #'pharo1.4.x', 
#'pharo1.4.1.x', #'pharo2.x', etc.). The platform attributes can provide very 
fine-grained control over which mcz files need to be loaded into a particular 
version of a platform, but the mechanism only works if the underlying platform 
is consistently naming versions ... 

In Metacello symbolic versions are simply a tagging mechanism. Versions and 
symbolic versions can be used interchangeably. Any name/platform/version 
combination can be created.

We have been using the #stable convention for several years and it is 
definitely time to revisit it's use. However, we cannot drop the #stable 
convention without replacing it with another convention... otherwise we risk 
chaos, again:)

In Metacello one can specify dependencies in terms of specific version numbers 
(tight coupling) or a tag (very loose coupling). Allowing one to specify 
dependencies based on version ranges would provide an intermediate coupling 
that avoids the tight coupling of specific version numbers while avoiding the 
ambiguity of a convention based on the name of a tag (symbolic version).

If we introduce version range dependencies then individual projects can use a 
variety symbolic version names to properly represent their desired semantics. 

If we introduce version range dependencies then we must adopt a convention for 
how versions are named and that convention must be used pretty consistently 
within the community otherwise we may just have to return to the world of using 
#stable in self defense again ... 

As an alternative to a version numbering convention like Semantic 
Versioning[1], we could adopt a convention defining the semantics of a 
collection of symbolic version names 

I am a fan of Semantic Versioning, but it has some pretty specific rules that 
"must" be followed and all projects including the Smalltalk platforms 
(GemStone, Pharo and Squeak). Scan through the discussions surrounding Semantic 
Versions[2] to see what I'm talking about...

In the grand scheme of things I don't want Metacello to be locked into any one 
convention. I am will

Re: [Pharo-project] User account on Jenkins

[Camillo Bruni]

On 2013-04-23, at 20:15, Benjamin  wrote:

> You can register there by yourself, then there is a list of projects, pick 
> the one you are interested in, Admins will then get a mail to add you

you can do that here: https://ci.inria.fr/users/new


> On Apr 23, 2013, at 7:45 PM, Guido Chari  wrote:
> 
>> Who can add me to Jenkins server so i can add a project to the 
>> infrastructure?
> 

Re: [Pharo-project] Your earlier problems accessing Monticello

[Sven Van Caekenberghe]

OK, thx.

On 23 Apr 2013, at 19:42, Benjamin  wrote:

> If a slice is proposed, you should "resolve" the case which flags the issue 
> as Fix Review Needed
> 
> :)
> 
> Ben
> 
> On Apr 23, 2013, at 7:40 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 23 Apr 2013, at 19:18, Guido Chari  wrote:
>> 
>>> Sorry for the delay, but yes i confirm this solves my issue.
>> 
>> Thanks, that is good to know !
>> 
>>> What i see is that it is not yet integrated into 3.0
>> 
>> Yeah, it is ready for inclusion, maybe I gave it the wrong status.
>> 
>>  https://pharo.fogbugz.com/default.asp?10102
>>  
>> https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal-ConncetionClosed
>> 
>>> Cheers,
>>> Guido.
>>> 
>>> 
>>> 2013/3/23 Guido Chari 
>>> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back 
>>> home i will send you the confirmation.
>>> 
>>> Thanks 
>>> 
>>> 
>>> 2013/3/23 Camillo Bruni 
>>> Guido is right now in Lille :P so you have to wait for a week.
>>> From what I recall it was exactly that bug we had over in Argentina :)
>>> 
>>> On 2013-03-23, at 11:03, Sven Van Caekenberghe  wrote:
 Hi Guido,
 
 Some time ago you were unable to access Monticello from inside your 
 particular network situation.
 
 http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-tt4653446.html
 
 We just were able to solve a similar case.
 
 http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Smalltalkhub-because-of-setAcceptEncodingGzip-tt4677539.html
 
 Would it be possible to verify, first that your old problem still exists, 
 and then try again with the following patch.
 
 SocketStream>>next: count
  "Read count elements and return them in a collection.
  If the receiver is #atEnd before count elements were read, return a 
 smaller collection."
 
  ^ self nextInto: (self streamBuffer: count)
 
 That would be most helpful.
 
 Thx,
 
 Sven
 
 --
 Sven Van Caekenberghe
 http://stfx.eu
 Smalltalk is the Red Pill
 
 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-project] User account on Jenkins

[Benjamin]

You can register there by yourself, then there is a list of projects, pick the 
one you are interested in, Admins will then get a mail to add you

Ben

On Apr 23, 2013, at 7:45 PM, Guido Chari  wrote:

> Who can add me to Jenkins server so i can add a project to the infrastructure?

[Pharo-project] User account on Jenkins

[Guido Chari]

Who can add me to Jenkins server so i can add a project to the
infrastructure?

Re: [Pharo-project] Your earlier problems accessing Monticello

[Benjamin]

If a slice is proposed, you should "resolve" the case which flags the issue as 
Fix Review Needed

:)

Ben

On Apr 23, 2013, at 7:40 PM, Sven Van Caekenberghe  wrote:

> 
> On 23 Apr 2013, at 19:18, Guido Chari  wrote:
> 
>> Sorry for the delay, but yes i confirm this solves my issue.
> 
> Thanks, that is good to know !
> 
>> What i see is that it is not yet integrated into 3.0
> 
> Yeah, it is ready for inclusion, maybe I gave it the wrong status.
> 
>  https://pharo.fogbugz.com/default.asp?10102
>  
> https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal-ConncetionClosed
> 
>> Cheers,
>> Guido.
>> 
>> 
>> 2013/3/23 Guido Chari 
>> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back 
>> home i will send you the confirmation.
>> 
>> Thanks 
>> 
>> 
>> 2013/3/23 Camillo Bruni 
>> Guido is right now in Lille :P so you have to wait for a week.
>> From what I recall it was exactly that bug we had over in Argentina :)
>> 
>> On 2013-03-23, at 11:03, Sven Van Caekenberghe  wrote:
>>> Hi Guido,
>>> 
>>> Some time ago you were unable to access Monticello from inside your 
>>> particular network situation.
>>> 
>>> http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-tt4653446.html
>>> 
>>> We just were able to solve a similar case.
>>> 
>>> http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Smalltalkhub-because-of-setAcceptEncodingGzip-tt4677539.html
>>> 
>>> Would it be possible to verify, first that your old problem still exists, 
>>> and then try again with the following patch.
>>> 
>>> SocketStream>>next: count
>>>  "Read count elements and return them in a collection.
>>>  If the receiver is #atEnd before count elements were read, return a 
>>> smaller collection."
>>> 
>>>  ^ self nextInto: (self streamBuffer: count)
>>> 
>>> That would be most helpful.
>>> 
>>> Thx,
>>> 
>>> Sven
>>> 
>>> --
>>> Sven Van Caekenberghe
>>> http://stfx.eu
>>> Smalltalk is the Red Pill
>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-project] Your earlier problems accessing Monticello

[Sven Van Caekenberghe]

On 23 Apr 2013, at 19:18, Guido Chari  wrote:

> Sorry for the delay, but yes i confirm this solves my issue.

Thanks, that is good to know !

> What i see is that it is not yet integrated into 3.0

Yeah, it is ready for inclusion, maybe I gave it the wrong status.

  https://pharo.fogbugz.com/default.asp?10102
  
https://pharo.fogbugz.com/f/cases/10102/SocketStream-next-should-not-signal-ConncetionClosed

> Cheers,
> Guido.
> 
> 
> 2013/3/23 Guido Chari 
> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back home 
> i will send you the confirmation.
> 
> Thanks 
> 
> 
> 2013/3/23 Camillo Bruni 
> Guido is right now in Lille :P so you have to wait for a week.
> From what I recall it was exactly that bug we had over in Argentina :)
> 
> On 2013-03-23, at 11:03, Sven Van Caekenberghe  wrote:
> > Hi Guido,
> >
> > Some time ago you were unable to access Monticello from inside your 
> > particular network situation.
> >
> > http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-tt4653446.html
> >
> > We just were able to solve a similar case.
> >
> > http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Smalltalkhub-because-of-setAcceptEncodingGzip-tt4677539.html
> >
> > Would it be possible to verify, first that your old problem still exists, 
> > and then try again with the following patch.
> >
> > SocketStream>>next: count
> >   "Read count elements and return them in a collection.
> >   If the receiver is #atEnd before count elements were read, return a 
> > smaller collection."
> >
> >   ^ self nextInto: (self streamBuffer: count)
> >
> > That would be most helpful.
> >
> > Thx,
> >
> > Sven
> >
> > --
> > Sven Van Caekenberghe
> > http://stfx.eu
> > Smalltalk is the Red Pill
> >
> >
> 
> 
> 
> 

Re: [Pharo-project] (was: Moose-dev) #stable and Metacello

[Dale Henrichs]

Diego,

I realize that you may not like the name #stable, but the mechanism behind 
#stable is what you want.

In current usage, the #stable version is the 'recommended version'. 

Dale

- Original Message -
| From: "Diego Lont" 
| To: pharo-project@lists.gforge.inria.fr
| Sent: Monday, April 22, 2013 5:39:19 AM
| Subject: Re: [Pharo-project] (was: Moose-dev) #stable and Metacello
| 
| Dale, Stef,
| 
| I like to have "a recommended version" as default and not #'stable'. Because
| I still want to recommend a version, even is this isn't stable. I can use
| the blessings to mark it as "development" or "release".
| 
| Using a 'recommended version' also makes it clear, that it depends on the
| project (both using as used) wether is is wise to use this version or not.
| For Moose 4.8 the 'recommended version' is the release candidate.
| 
| Diego
| 
| On Apr 18, 2013, at 9:55 PM, stephane ducasse wrote:
| 
| > 
| > On Apr 18, 2013, at 6:29 PM, Dale Henrichs  wrote:
| > 
| >> Stef,
| >> 
| >> I think it is clear that #stable is not the right name, but I also think
| >> it is better to have one "badly named," commonly used symbolic version
| >> rather than a bunch of different names for the same thing…
| > 
| > yes
| > but this can be confusing.
| >> Eventually we should change the convention, but I don't think we need to
| >> hurry and do so:)
| > 
| > first we need a tool to manage configuration for real.
| > 
| > Stef
| > 
| >> 
| >> Dale
| >> 
| >> - Original Message -
| >> | From: "stephane ducasse" 
| >> | To: "Moose-related development" 
| >> | Sent: Wednesday, April 17, 2013 10:04:50 PM
| >> | Subject: [Moose-dev] Re: #stable and Metacello (was  Re:
| >> |  ConfigurationOfGlamourSeaside)
| >> | 
| >> | Dale
| >> | 
| >> | I thought that stable should be called milestoneDevelopment.
| >> | I will add a note to the metacello chapter and versionner will handle
| >> | the
| >> | patterns we see.
| >> | 
| >> | Stef
| >> | 
| 

Re: [Pharo-project] [squeak-dev] Metacello Preview

[Dale Henrichs]

Some status:

The Preview is functional (all tests passing:) on GemStone (included in base 
for GLASS 1.0-beta.9), Squeak 4.3 through 4.5 (is Squeak4.5 the trunk?) and 
Pharo 1.1 through 1.4. Christophe Demarey is helping me port the Metacello 
Preview/Metacello Scripting API to Pharo2.0. 

For the Squeak guys ... I did finally address the bug that was bugging me, but 
I'm still interested in some real world feedback ... There are a handful of 
users, but I haven't gotten enough bug reports to satisfy me that it is being 
beaten on:)

Dale

- Original Message -
| From: "DeNigris Sean" 
| To: pharo-project@lists.gforge.inria.fr, "The general-purpose Squeak 
developers list"
| 
| Sent: Tuesday, April 23, 2013 9:15:40 AM
| Subject: [squeak-dev] Metacello Preview
| 
| [cross posted to pharo-project and squeak-dev]
| 
| Dale has done some really cool work on Metacello! From the original
| announcement at
| http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-td4642064.html
| :
| 
| 
| The Metacello Preview release provides the following features:
| 
| - Metacello Scripting API (user guide[1] and reference[2])
| - Metacello-Base package for inclusion in Squeak/Pharo base images
| - support for git and GitHub (filetree:// and github:// repository loaded)
| 
| In typical Dale fashion, he wants to provide our community with as much value
| as possible, so he's been tentative to release his "preview" version until
| he gets feedback from users and can tailor it to our real-world needs.
| 
| I feel, after checking with Dale, that integrating the preview into Pharo and
| Squeak trunk now will provide a balance between exposure and malleability,
| to make sure we have an API we'll all love by the next respective releases.
| 
| Cheers,
| Sean
| 
| 
| 

Re: [Pharo-project] Your earlier problems accessing Monticello

[Guido Chari]

Sorry for the delay, but yes i confirm this solves my issue.

What i see is that it is not yet integrated into 3.0

Cheers,
Guido.


2013/3/23 Guido Chari 

> Yes, i'm sure this will do the fix. Nevertheless, as soon as i come back
> home i will send you the confirmation.
>
> Thanks
>
>
> 2013/3/23 Camillo Bruni 
>
>> Guido is right now in Lille :P so you have to wait for a week.
>> From what I recall it was exactly that bug we had over in Argentina :)
>>
>> On 2013-03-23, at 11:03, Sven Van Caekenberghe  wrote:
>> > Hi Guido,
>> >
>> > Some time ago you were unable to access Monticello from inside your
>> particular network situation.
>> >
>> >
>> http://forum.world.st/Unable-to-use-Monticello-in-last-images-from-Jenkins-tt4653446.html
>> >
>> > We just were able to solve a similar case.
>> >
>> >
>> http://forum.world.st/Problem-downloading-packages-with-Monticello-from-Smalltalkhub-because-of-setAcceptEncodingGzip-tt4677539.html
>> >
>> > Would it be possible to verify, first that your old problem still
>> exists, and then try again with the following patch.
>> >
>> > SocketStream>>next: count
>> >   "Read count elements and return them in a collection.
>> >   If the receiver is #atEnd before count elements were read, return
>> a smaller collection."
>> >
>> >   ^ self nextInto: (self streamBuffer: count)
>> >
>> > That would be most helpful.
>> >
>> > Thx,
>> >
>> > Sven
>> >
>> > --
>> > Sven Van Caekenberghe
>> > http://stfx.eu
>> > Smalltalk is the Red Pill
>> >
>> >
>>
>>
>>
>

[Pharo-project] Metacello Preview

[DeNigris Sean]

[cross posted to pharo-project and squeak-dev]

Dale has done some really cool work on Metacello! From the original 
announcement at 
http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-td4642064.html :
> The Metacello Preview release provides the following features: 
> 
>  - Metacello Scripting API (user guide[1] and reference[2]) 
>  - Metacello-Base package for inclusion in Squeak/Pharo base images 
>  - support for git and GitHub (filetree:// and github:// repository loaded) 

In typical Dale fashion, he wants to provide our community with as much value 
as possible, so he's been tentative to release his "preview" version until he 
gets feedback from users and can tailor it to our real-world needs.

I feel, after checking with Dale, that integrating the preview into Pharo and 
Squeak trunk now will provide a balance between exposure and malleability, to 
make sure we have an API we'll all love by the next respective releases.

Cheers,
Sean

[Pharo-project] [update 3.0] #30056

[Esteban Lorenzano]

30056
-

10363 Boolean clean up
https://pharo.fogbugz.com/f/cases/10363

Diff information:
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/NativeBoost-Core-EstebanLorenzano.118

[Pharo-project] [update 3.0] #30055

[Marcus Denker]

Ups. forgot to send this:

30055
-

10353 Add release test to check uniqueness of SystemAnnouncer
https://pharo.fogbugz.com/f/cases/10353

10357 Simplify #selectedMethodSource in Nautilus
https://pharo.fogbugz.com/f/cases/10357

10369 KeyChain deadlock
https://pharo.fogbugz.com/f/cases/10369

10370 Spec mino fix
https://pharo.fogbugz.com/f/cases/10370

10371 add #compiler to Behavior
https://pharo.fogbugz.com/f/cases/10371

Diff information:
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tests-MarcusDenker.528
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Widgets-MarcusDenker.127
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Core-MarcusDenker.103
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Polymorph-Widgets-MarcusDenker.796
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Nautilus-MarcusDenker.444
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1402
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1371
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/KeyChain-MarcusDenker.31
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.386

Re: [Pharo-project] A Pharo launcher

[Damien Cassou]

On Tue, Apr 23, 2013 at 3:34 PM, Goubier Thierry  wrote:
> Is that just me or I expected to be able to do that from the configurations
> browser ?

yes and no. The problem is that Pharo takes ages to load a
configuration in the image. Also, I would like to use this launcher as
the main entry point. I want to get a list of the recent images used
for example.


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-project] A Pharo launcher

[Goubier Thierry]

Is that just me or I expected to be able to do that from the 
configurations browser ?


Start bare image, read nice description of all sorts of interesting 
stuff, select configuration, choose install and save image... Including 
the option to get a production server (i.e. trimForRelease if appropriate).


Thierry

Le 23/04/2013 00:21, Sven Van Caekenberghe a écrit :

Excellent idea, good list of features.

I like the idea of writing this tool in Pharo itself: eating your own dogfood 
and more flexibility.

Sven

On 22 Apr 2013, at 18:14, Damien Cassou  wrote:


I think the idea to have a Pharo launcher that lets the user pick a
Pharo template (either bare pharo 2.0, pharo+seaside,
pharo+seaside+mongodb+
magritte+voyage, pharo+pier, ...) and then create
a new image the user must save somewhere is important. I want people
to have one Pharo icon on their desk and just click it (like in
Eclipse, word processors, virtual box...). Here is a set of
requirements for such an application, please comment.

- must be implemented in Pharo 2.0 with maintained technology (spec or glamour)
- must be cross-platform (we want 1 application for all Pharo users)
- must download the list of templates from internet (so that we don't
have to update the application all the time)
- must propose different kinds of template (stable/unstable, desktop/web)
- must rapidly create an image out of the selected template (either by
downloading Fueled packages, or by downloading ready-made images)
- must cache the created images so that they do not have to be
recreated all the time (except when a newer version is available)
- must force the user to copy the created image so he can freely
change it and crash it without impacting the cache of created images.
- must present a list of recently launched images so that the user can
just pick a recent image instead of creating a new one


Please comment (and implement this idea)

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill








--
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-project] A Pharo launcher

[Guillermo Polito]

On Tue, Apr 23, 2013 at 3:26 PM, Ben Coman  wrote:

> Damien Cassou wrote:
>
>> I think the idea to have a Pharo launcher that lets the user pick a
>> Pharo template (either bare pharo 2.0, pharo+seaside,
>> pharo+seaside+mongodb+
>> magritte+voyage, pharo+pier, ...) and then create
>> a new image the user must save somewhere is important. I want people
>> to have one Pharo icon on their desk and just click it (like in
>> Eclipse, word processors, virtual box...). Here is a set of
>> requirements for such an application, please comment.
>>
>> - must be implemented in Pharo 2.0 with maintained technology (spec or
>> glamour)
>> - must be cross-platform (we want 1 application for all Pharo users)
>> - must download the list of templates from internet (so that we don't
>> have to update the application all the time)
>>
>>
> be able to specify a LAN repository for templates - get this location from
> initialization script or from environment variables


That would be cool for organization specific needs...


>
>  - must propose different kinds of template (stable/unstable, desktop/web)
>> - must rapidly create an image out of the selected template (either by
>> downloading Fueled packages, or by downloading ready-made images)
>> - must cache the created images so that they do not have to be
>> recreated all the time (except when a newer version is available)
>> - must force the user to copy the created image so he can freely
>> change it and crash it without impacting the cache of created images.
>> - must present a list of recently launched images so that the user can
>> just pick a recent image instead of creating a new one
>>
>>
>> Please comment (and implement this idea)
>>
>> --
>> Damien Cassou
>> http://damiencassou.**seasidehosting.st
>>
>> "Success is the ability to go from one failure to another without
>> losing enthusiasm."
>> Winston Churchill
>>
>>
>>
>>
>
>
>

Re: [Pharo-project] A Pharo launcher

[Ben Coman]

Damien Cassou wrote:

I think the idea to have a Pharo launcher that lets the user pick a
Pharo template (either bare pharo 2.0, pharo+seaside,
pharo+seaside+mongodb+
magritte+voyage, pharo+pier, ...) and then create
a new image the user must save somewhere is important. I want people
to have one Pharo icon on their desk and just click it (like in
Eclipse, word processors, virtual box...). Here is a set of
requirements for such an application, please comment.

- must be implemented in Pharo 2.0 with maintained technology (spec or glamour)
- must be cross-platform (we want 1 application for all Pharo users)
- must download the list of templates from internet (so that we don't
have to update the application all the time)
  
be able to specify a LAN repository for templates - get this location 
from initialization script or from environment variables

- must propose different kinds of template (stable/unstable, desktop/web)
- must rapidly create an image out of the selected template (either by
downloading Fueled packages, or by downloading ready-made images)
- must cache the created images so that they do not have to be
recreated all the time (except when a newer version is available)
- must force the user to copy the created image so he can freely
change it and crash it without impacting the cache of created images.
- must present a list of recently launched images so that the user can
just pick a recent image instead of creating a new one


Please comment (and implement this idea)

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill


  

Re: [Pharo-project] Metacello for Pharo 2 and Pharo 3 ?

[stephane ducasse]

we should define the 3.0.x tag in the image.

Stef


> Hi,
> 
> is there already a #'pharo3.0.x' tag in metacello when we want to have 
> different package version in Pharo 3.0 instead of 2.0 ? I tried
> 
> spec for: #'pharo3.0.x' version: '0.2'
> 
> and it didn't 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-project] Metacello for Pharo 2 and Pharo 3 ?

[Clément Bera]

yeah I heard these symbol were hardcoded in metacello so they don't work by
default.

There's no tag yet for pharo 3.0.


2013/4/23 Goubier Thierry 

> Hi,
>
> is there already a #'pharo3.0.x' tag in metacello when we want to have
> different package version in Pharo 3.0 instead of 2.0 ? I tried
>
> spec for: #'pharo3.0.x' version: '0.2'
>
> and it didn't 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
>
>


-- 
Clément Béra
Mate Virtual Machine Engineer
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*

[Pharo-project] Metacello for Pharo 2 and Pharo 3 ?

[Goubier Thierry]

Hi,

is there already a #'pharo3.0.x' tag in metacello when we want to have 
different package version in Pharo 3.0 instead of 2.0 ? I tried


spec for: #'pharo3.0.x' version: '0.2'

and it didn't 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

[Pharo-project] [update 3.0] #30054

[Marcus Denker]

30054
-

10107 SimpleButtonMorph inconsistency for label: and label:font:
https://pharo.fogbugz.com/f/cases/10107

10190 Failing test: Code critics / Manifest 
(Workaround to get green tests: failing test is in the tracker)
https://pharo.fogbugz.com/f/cases/10190

10372 remove CustomParserTest
https://pharo.fogbugz.com/f/cases/10372

10364 remove allowBlockArgumentAssignment setting
https://pharo.fogbugz.com/f/cases/10364


Diff information:
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Core-MarcusDenker.198
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Settings-Compiler-MarcusDenker.5
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1400
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Manifest-Tests-MarcusDenker.34
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.384
http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CompilerTests-MarcusDenker.134