Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

2016-02-04 12:21 GMT+01:00 Esteban Lorenzano : > Hi, > > We are on “just bugfixes” since some time now… I delayed the announcement > because Epicea still needs to enter and we didn’t manage to include it yet. > But well… with the exception of Epicea, no new features will be included > un Pharo 5…

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

I´ve just released a new version and updated the fogbugz case. I hoep it works now. How did you repdoruce the error Vincent? Martin On Thu, Feb 4, 2016 at 6:24 PM, stepharo wrote: > Thanks vincent! > > Le 4/2/16 16:25, Blondeau Vincent a écrit : > > I just tried to integrate and the tests a

Re: [Pharo-dev] pharo-minimal-vm

One thing you can do is to compile the VM without the external plugins as they are optional. It disables some features (git, Cairo, SDL, ...) but it decreases the memory footprint. This can also be done after the compilation by removing the plugins in the VM folder. In addition you can use a stack

[Pharo-dev] pharo-minimal-vm

Is there a minimal-VM that can be used to run the minimal-IMAGE [1] ? It would be nice for [1] to include an a step PharoVMBuilder buildUnix32minimal. since the VM is also part of "how small can we go". My reason for asking is that also less generated VM code might shorten the edit-compile-r

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

On Thu, Feb 4, 2016 at 7:21 PM, Esteban Lorenzano wrote: > Hi, > > We are on “just bugfixes” since some time now… I delayed the announcement > because Epicea still needs to enter and we didn’t manage to include it yet. > But well… with the exception of Epicea, no new features will be included un

Re: [Pharo-dev] Best way to access icons?

On Fri, Feb 5, 2016 at 5:21 AM, stepharo wrote: > Hi guys > > I do not have the answer but I hate such patterns > > Smalltalk ui icons iconNamed: #protocolExtension. > > To me a tools using an icon should declare the icons as a ***local*** > ressources. +100. At a minimum this should probabl

[Pharo-dev] Pharo mooc registration is available

https://www.france-universite-numerique-mooc.fr/courses/inria/41010/session01/about?platform=hootsuite

Re: [Pharo-dev] System Browser class pane strange behaviour

Le 3/2/16 14:32, Ben Coman a écrit : I have a talent for breaking things ;) ... me too but you are a lot better than me helping identifying the cause :) Found some strange behaviour here... I open System Browser select package AST-Core select class ASTCache make code pane dirty by typing 1

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

Thanks vincent! Le 4/2/16 16:25, Blondeau Vincent a écrit : I just tried to integrate and the tests are failing when reopening the image. Just added the opening of the session file at the right place and the closing of the file at the end of the critical section. Now, it works fine for me

Re: [Pharo-dev] Best way to access icons?

Hi guys I do not have the answer but I hate such patterns Smalltalk ui icons iconNamed: #protocolExtension. To me a tools using an icon should declare the icons as a ***local*** ressources. We could imagine that there is a IconContainer and that as a tool I declare that I want an icons a

Re: [Pharo-dev] Contributing to Pharo

2016-02-04 13:09 GMT+01:00 Henrik Johansen : > > > On 04 Feb 2016, at 10:26 , Thierry Goubier > wrote: > > > > Le 04/02/2016 10:04, Nicolas Cellier a écrit : > >> I don't understand broken history either. > >> Yes there can be .mcz name clashes but UUID history is stored together > >> in metadata

Re: [Pharo-dev] [Vm-dev] Simple versus Recursive Mutexes

Hi Ben. 2016-02-04 18:16 GMT+01:00 Ben Coman : > SimpleMutex>>critical: aBlock > Processor activeProcess == owner > ifTrue: [self error: 'recursive locks will kill you' ]. > ^ super critical: aBlock > This can be easily implemented with current primitive (I use inverted v

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

Wow, thank you very much for the contribution Vincent! I'm analyzing your changes. Martin On Thu, Feb 4, 2016 at 12:25 PM, Blondeau Vincent < vincent.blond...@worldline.com> wrote: > I just tried to integrate and the tests are failing when reopening the > image. Just added the opening of the ses

Re: [Pharo-dev] [ANN] Pomodoro for Pharo 2.0

Hello, First time user of Pharo - I just got pomodoro up running, but how to close it? Thanks! -- Ipstone -- View this message in context: http://forum.world.st/ANN-Pomodoro-for-Pharo-2-0-tp4678427p4875915.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Best way to access icons?

On Thu, Feb 4, 2016 at 7:19 AM, Aliaksei Syrel wrote: > Hi > > For ages to access an icon we used: > >> Smalltalk ui icons protocolPrivateIcon > > > Smalltalk ui icons returns an instance of ThemeIcons. > After refactoring (case https://pharo.fogbugz.com/f/cases/16651 >

Re: [Pharo-dev] Contributing to Pharo

On 2/4/16 9:48 AM, Esteban A. Maringolo wrote: 2016-02-04 14:39 GMT-03:00 Ben Coman : Pertinent is Joel's description of how Microsoft Excel's tipping point [1] in competing against Lotus123 was when it became able to export to Lotu123 format. Making it easy for people to move from git back

Re: [Pharo-dev] Contributing to Pharo

On 2/4/16 9:39 AM, Ben Coman wrote: On Fri, Feb 5, 2016 at 1:08 AM, Dale Henrichs wrote: On 2/3/16 10:53 PM, Thierry Goubier wrote: Le 03/02/2016 23:58, Dale Henrichs a écrit : On 02/03/2016 02:34 PM, Thierry Goubier wrote: Le 03/02/2016 22:51, Eliot Miranda a écrit : On Wed, Feb 3,

Re: [Pharo-dev] Contributing to Pharo

2016-02-04 14:39 GMT-03:00 Ben Coman : > Pertinent is Joel's description of how Microsoft Excel's tipping point > [1] in competing against Lotus123 was when it became able to export to > Lotu123 format. Making it easy for people to move from git back to > Monticello lower the barrier for entry fo

Re: [Pharo-dev] Best way to access icons?

On 04-02-16 17:55, Esteban Lorenzano wrote: On 04 Feb 2016, at 17:38, Stephan Eggermont wrote: On 04-02-16 17:00, Esteban Lorenzano wrote: Smalltalk ui icons iconNamed: #protocolExtension. Still ugly, but I’m not happy with the idea of a selector-per-icon… Why do you see that as a problem

Re: [Pharo-dev] Contributing to Pharo

On Fri, Feb 5, 2016 at 1:08 AM, Dale Henrichs wrote: > > > On 2/3/16 10:53 PM, Thierry Goubier wrote: >> >> Le 03/02/2016 23:58, Dale Henrichs a écrit : >>> >>> >>> >>> On 02/03/2016 02:34 PM, Thierry Goubier wrote: Le 03/02/2016 22:51, Eliot Miranda a écrit : > > > > On

Re: [Pharo-dev] Contributing to Pharo

On 04-02-16 17:22, Dale Henrichs wrote: Stephan, Have you described this anywhere? Not very much http://forum.world.st/Overhead-in-mczs-MCVersionInfo-td4869374.html MCHttpRepository location: 'http://smalltalkhub.com/mc/StephanEggermont/MonticelloProjects/main' user: '' pa

Re: [Pharo-dev] Contributing to Pharo

On 2/3/16 10:53 PM, Thierry Goubier wrote: Le 03/02/2016 23:58, Dale Henrichs a écrit : On 02/03/2016 02:34 PM, Thierry Goubier wrote: Le 03/02/2016 22:51, Eliot Miranda a écrit : On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier mailto:thierry.goub...@gmail.com>> wrote: Hi Eliot,

Re: [Pharo-dev] Best way to access icons?

Thanks, Esteban :) As compromise > Smalltalk ui icons iconNamed: #something is ok for now. Cheers Alex On Thu, Feb 4, 2016 at 5:55 PM, Esteban Lorenzano wrote: > > > On 04 Feb 2016, at 17:38, Stephan Eggermont wrote: > > > > On 04-02-16 17:00, Esteban Lorenzano wrote: > >> Smalltalk ui icon

Re: [Pharo-dev] Contributing to Pharo

Stephan, Have you described this anywhere? Dale On 2/4/16 4:21 AM, Stephan Eggermont wrote: On 04-02-16 13:09, Henrik Johansen wrote: Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. I don't think anyone looked into why it happe

Re: [Pharo-dev] Best way to access icons?

> On 04 Feb 2016, at 17:38, Stephan Eggermont wrote: > > On 04-02-16 17:00, Esteban Lorenzano wrote: >> Smalltalk ui icons iconNamed: #protocolExtension. >> >> Still ugly, but I’m not happy with the idea of a selector-per-icon… > > Why do you see that as a problem? For me the problem is more t

Re: [Pharo-dev] Best way to access icons?

On 04-02-16 17:00, Esteban Lorenzano wrote: Smalltalk ui icons iconNamed: #protocolExtension. Still ugly, but I’m not happy with the idea of a selector-per-icon… Why do you see that as a problem? For me the problem is more the trainwreck. Stephan

Re: [Pharo-dev] Best way to access icons?

Smalltalk ui icons iconNamed: #protocolExtension. Still ugly, but I’m not happy with the idea of a selector-per-icon… they will never be enough and well… is like a monolithic vision. Not that what we have is much better, but you can consider it an iteration :) Esteban > On 04 Feb 2016, at 16:1

[Pharo-dev] Best way to access icons?

Hi For ages to access an icon we used: > Smalltalk ui icons protocolPrivateIcon Smalltalk ui icons returns an instance of ThemeIcons. After refactoring (case https://pharo.fogbugz.com/f/cases/16651 ) all methods to access icon (for example protocolPrivat

[Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

I just tried to integrate and the tests are failing when reopening the image. Just added the opening of the session file at the right place and the closing of the file at the end of the critical section. Now, it works fine for me (under W7 of course ;): Name: Ombu-VincentBlondeau.191 Author: Vi

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

Hi, > On Feb 4, 2016, at 3:16 PM, Damien Cassou wrote: > > Esteban Lorenzano writes: > >> We are on “just bugfixes” since some time now… I delayed the announcement >> because Epicea still needs to enter and we didn’t manage to include it yet. >> But well… with the exception of Epicea, no new

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

> On 04 Feb 2016, at 15:16, Damien Cassou wrote: > > Esteban Lorenzano writes: > >> We are on “just bugfixes” since some time now… I delayed the announcement >> because Epicea still needs to enter and we didn’t manage to include it yet. >> But well… with the exception of Epicea, no new featur

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

Esteban Lorenzano writes: > We are on “just bugfixes” since some time now… I delayed the announcement > because Epicea still needs to enter and we didn’t manage to include it yet. > But well… with the exception of Epicea, no new features will be included un > Pharo 5… just bugfixes (and we have

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Guille Polito writes: > And yes, linux VM's are not shipped with the UUID plugin... at least not > since 2014/2013... if you tell me what to change, I can release new VM sources in http://files.pharo.org/vm/src/vm-unix-sources/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success

[Pharo-dev] [pharo-project/pharo-core] 3fac82: 50566

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3fac822ec0bd8a92bc78c3f7e731559c26079de8 https://github.com/pharo-project/pharo-core/commit/3fac822ec0bd8a92bc78c3f7e731559c26079de8 Author: Jenkins Build Server Date: 2016-02-04 (Thu, 04 Feb 2016

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50566 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

> On 04 Feb 2016, at 14:02, Henrik Johansen > wrote: > >> >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe wrote: >> >> >>> On 04 Feb 2016, at 11:55, Guille Polito wrote: >>> >>> Good news, so far, installing NeoUUID and replacing UUID class >> new by: >>> >>> UUID class >> new >>>

Re: [Pharo-dev] Contributing to Pharo

Le 04/02/2016 13:21, Stephan Eggermont a écrit : On 04-02-16 13:09, Henrik Johansen wrote: Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. I don't think anyone looked into why it happened. My experiment in creating one file for a

Re: [Pharo-dev] Contributing to Pharo

Le 04/02/2016 14:32, Nicolas Cellier a écrit : 2016-02-04 10:26 GMT+01:00 Thierry Goubier mailto:thierry.goub...@gmail.com>>: Le 04/02/2016 10:04, Nicolas Cellier a écrit : [... cut ] Or is it the fact that some .mcz could be missing? Consider this is a feature, MC tool

Re: [Pharo-dev] Contributing to Pharo

2016-02-04 10:26 GMT+01:00 Thierry Goubier : > Le 04/02/2016 10:04, Nicolas Cellier a écrit : > >> I don't understand broken history either. >> Yes there can be .mcz name clashes but UUID history is stored together >> in metadata no? >> > > Yes. > > If some tool only trust .mcz name without checki

Re: [Pharo-dev] Contributing to Pharo

Le 04/02/2016 13:09, Henrik Johansen a écrit : Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. I don't think anyone looked into why it happened. It was done on purpose for the Pharo 3 release to reduce the amount of memory used

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

2016-02-04 11:29 GMT+01:00 Guille Polito : > And yes, linux VM's are not shipped with the UUID plugin... at least not > since 2014/2013... > > Also, I believe the plugin is not compiled as internal since it is not > listed in > > Smalltalk vm listBuiltinModules. > Smalltalk vm listLoadedModules. >

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe wrote: > > >> On 04 Feb 2016, at 11:55, Guille Polito wrote: >> >> Good news, so far, installing NeoUUID and replacing UUID class >> new by: >> >> UUID class >> new >> ^NeoUUIDGenerator new next >> >> seems to work. At it looks that I can

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

> On 04 Feb 2016, at 12:21, Esteban Lorenzano wrote: > > Hi, > > We are on “just bugfixes” since some time now… I delayed the announcement > because Epicea still needs to enter and we didn’t manage to include it yet. > But well… with the exception of Epicea, no new features will be included un

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

Hi Christophe Thanks for the answer :) What you proposed indeed fixes the issue. it would be great to have it! Because Bloc Universe knows which space is currently running I can detect which UI manager is needed. So I just hacked "new" in bloc ui manager: new > ^ super new space: (%ask univers

Re: [Pharo-dev] Contributing to Pharo

On Thu, Feb 4, 2016 at 5:26 PM, Thierry Goubier wrote: > In the meantime, Cuis has completely given up managing packages in > Smalltalk: all is done in git externally. Thats very interesting to hear - since 2012 even... http://www.jvuletich.org/Cuis/CuisAndGitHub.html and interesting to compare

Re: [Pharo-dev] Contributing to Pharo

On 04-02-16 13:09, Henrik Johansen wrote: Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. I don't think anyone looked into why it happened. My experiment in creating one file for a whole project would be a suitable starting poin

Re: [Pharo-dev] Contributing to Pharo

> On 04 Feb 2016, at 10:26 , Thierry Goubier wrote: > > Le 04/02/2016 10:04, Nicolas Cellier a écrit : >> I don't understand broken history either. >> Yes there can be .mcz name clashes but UUID history is stored together >> in metadata no? > > Yes. > >> If some tool only trust .mcz name witho

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

> On 04 Feb 2016, at 11:55, Guille Polito wrote: > > Good news, so far, installing NeoUUID and replacing UUID class >> new by: > > UUID class >> new >^NeoUUIDGenerator new next > > seems to work. At it looks that I can trust again my commits. > > Thanks Sven :) OK. Now, the idea is that

[Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

Hi, We are on “just bugfixes” since some time now… I delayed the announcement because Epicea still needs to enter and we didn’t manage to include it yet. But well… with the exception of Epicea, no new features will be included un Pharo 5… just bugfixes (and we have a lot of bugfixes incoming… th

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Good news, so far, installing NeoUUID and replacing UUID class >> new by: UUID class >> new ^NeoUUIDGenerator new next seems to work. At it looks that I can trust again my commits. Thanks Sven :) Now I do not know how this should be solved, nor if this is reproducible in a machine other t

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Well, maybe we do not need a plugin, but then the fallback code is not generating unique enough UUIDs :/ Maybe it is a side effect of Spur? I'll try to patch the UUID generator in the image with the Neo one and test if it solves my problem... I just want to commit :'( On 02/04/2016 11:36 AM

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

It beats the hell out of me why we need a plugin (apart from speed) and why the fallback should not work (i.e. generate duplicates). It is not rocket science or magic, right ? I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo on StHub). It is pretty simple and fast. > On 04

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... Also, I believe the plugin is not compiled as internal since it is not listed in Smalltalk vm listBuiltinModules. Smalltalk vm listLoadedModules. On 02/04/2016 11:12 AM, Guille Polito wrote: On 02/0

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: But StHub did not change for a long time, no ? I know... Saving to an HTTP MC repo is nothing more than an HTTP PUT. You should be able to do that manually with just ZnClient. Well, yes. But I'm just clicking the save button on the montice

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

But StHub did not change for a long time, no ? Saving to an HTTP MC repo is nothing more than an HTTP PUT. You should be able to do that manually with just ZnClient. > On 04 Feb 2016, at 10:52, Guille Polito wrote: > > So far, I'm blaming Smalltalkhub: > > - I create a new empty package. > -

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

So far, I'm blaming Smalltalkhub: - I create a new empty package. - I commit it to a local directory, it works ok. - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted e.g., http://www.smalltalkhub.com/#!/~Guille/playgr

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! I'll keep trying to reproduce and

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

Hi Alex, First, note that the current UIManager selection and the StartupUIManager appears from a cleanup on the old UIManager selection that existed. The idea is that the UIManagerSessionHandler will run in low priority and set a startup UIManager during startup (when you cannot ensure that

Re: [Pharo-dev] Contributing to Pharo

Le 04/02/2016 10:04, Nicolas Cellier a écrit : I don't understand broken history either. Yes there can be .mcz name clashes but UUID history is stored together in metadata no? Yes. If some tool only trust .mcz name without checking UUID, consider it's a bug, and let's correct it (there is som

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Hi guille Esteban got some problems with MC recently so it would be good to have a reproducible case. Stef Le 4/2/16 10:07, Guille Polito a écrit : Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken.

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

Hi Alex, Thanks for your detailed explanation. To me,the design of the current UIManger is not good enough. UIManager has too much pre-occupations. He is in charge of: providing different implementation of interactive requests, depending if the current UI manager is interactive or not, if the UI

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. Attached screenshot of what monticello shows me. I'm on debian jessie 64bits. Maybe it has something to do? On 02/03/2016 03:41 PM, Guille Polito wrot

Re: [Pharo-dev] Contributing to Pharo

I don't understand broken history either. Yes there can be .mcz name clashes but UUID history is stored together in metadata no? If some tool only trust .mcz name without checking UUID, consider it's a bug, and let's correct it (there is some in Monticello Configuration Map) Or is it the fact that

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

Hi Alex, First, note that the current UIManager selection and the StartupUIManager appears from a cleanup on the old UIManager selection that existed. The idea is that the UIManagerSessionHandler will run in low priority and set a startup UIManager during startup (when you cannot ensure that