June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13276

by Marcus Denker

13276 ----- Issue 4452: Build of 1.3 full is broken http://code.google.com/p/pharo/issues/detail?id=4452 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 26, 2011

Re: [Pharo-project] [ANN] Pharo Kernel now in auto-build

by StÃ©phane Ducasse

**YES**! Imagine that all the packages published somehwere could be executed analysed ... for each updates. We will get there stef > On Sun, Jun 26, 2011 at 4:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Pavel's 2.1 MB kernel is now on the new Jenkins for 1.4: >> >> https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ >> >> This means a 2.2MB headless image is now build (shrunk?) after each update. >> >> 1.3 to follow... > > Jenkins is currently sleeping, make him work!!! > > Thank you very much Marcus, this CI stuff is really driving us forward

June 26, 2011

Re: [Pharo-project] [ANN] Pharo Kernel now in auto-build

by Damien Cassou

On Sun, Jun 26, 2011 at 4:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Pavel's 2.1 MB kernel is now on the new Jenkins for 1.4: > > Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ > > This means a 2.2MB headless image is now build (shrunk?) after each update. > > 1.3 to follow... Jenkins is currently sleeping, make him work!!! Thank you very much Marcus, this CI stuff is really driving us forward -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 26, 2011

[Pharo-project] [ANN] Pharo Kernel now in auto-build

by Marcus Denker

Hi, Pavel's 2.1 MB kernel is now on the new Jenkins for 1.4: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ This means a 2.2MB headless image is now build (shrunk?) after each update. 1.3 to follow... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 26, 2011

Re: [Pharo-project] UIManager>>chooseFileName* flavour to get full path?

by Schwab,Wilhelm K

+1 about answering the full path; that should be the default. Attached is (beware a Linux bias) a Pharo-specific recreation of Dolphin's File class. One can readily quibble about the design, which puts file name manipulation methods on the class-side of File. But, that's how Dolphin does it, and I have a lot of Dolphin code that needs a home on Linux, so I wasn't interested in purity - I just wanted the stuff to work :) I had to change separators and lose drive letters, but it has overall worked fairly well. FWIW (mostly to Dolphin users), I added #path to DirectoryEntry (it answers self fullName), for compatibility with Dolphin's WIN32_FIND_DATA; then DirectoryEntry takes over - or so it seems looking at my code. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Saturday, June 25, 2011 4:04 PM To: Pharo Development Subject: [Pharo-project] UIManager>>chooseFileName* flavour to get full path? Hi! I was wondering why UITheme>>chooseFileNameIn: title: patterns: path: preview: and UITheme>>chooseFileNameIn: title: extensions: path: preview: do fd := FileDialogWindow basicNew previewType: preview; initialize; title: title; answerFileName. And actually there is no variant using answerPathName what is a bit more useful because it answers the entire path to the selected file... Thanks! Guille

June 26, 2011

[Pharo-project] [Jenkins] 1.4 jenkins setup improved

by Marcus Denker

Some progress on Jenkins: -> image and all zips are now names Pharo-1.4 (not Core) -> there is now a one-click image (build using same script /vm as 1.3) -> image is saved to image directory as "Pharo-1.4" for other jobs to build on top. https://ci.lille.inria.fr/pharo/job/Pharo%201.4/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 26, 2011

[Pharo-project] [update 1.3] #13275

by Marcus Denker

Issue 4450: TimeProfileBrowser broken in Pharo OneClick 1.3, PharoCore1.3, Pharo 1.4a http://code.google.com/p/pharo/issues/detail?id=4450 Issue 4446: latestSource:location: and latestVersionOf:location: http://code.google.com/p/pharo/issues/detail?id=4446 Issue 4435: initializersEnabled http://code.google.com/p/pharo/issues/detail?id=4435 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 26, 2011

Re: [Pharo-project] SqueakSource down

by Pavel Krivanek

...and up again On Sun, Jun 26, 2011 at 12:22 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > SqueakSource is down. > > -- Pavel >

June 26, 2011

[Pharo-project] SqueakSource down

by Pavel Krivanek

SqueakSource is down. -- Pavel

June 26, 2011

Re: [Pharo-project] Merge tool. No way to cherry pick the changes?

by StÃ©phane Ducasse

no backport is no cherry picking. Stef On Jun 25, 2011, at 10:18 PM, Nicolas Cellier wrote: > Isn't it one of the features supported by backport ? > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… > > Nicolas > > 2011/6/23 Igor Stasenko <siguctua(a)gmail.com>: >> On 22 June 2011 23:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> Perhaps the "non-applicable" could be streamlined. >>>>>> I.e., "keep current version" = not applicable. >>>>>> >>>>> yes, could be.. >>>>> but that logic are only for conflics.. and i didn't wanted to mess >>>>> with it because its a lot more work. >>>> >>>> btw, Stephane, this is a good topic for dealing with it on friday, if >>>> you don't have anything else in mind. >>> >>> ok >>> did you run MC tests? >>> I htink that we should invest more in running tests. >>> >> >> well, the changes i made are not intrusive, i mean it will work as before >> unless user plays with this flag using UI. >> So, MC will behave exactly as before and there is no problem from that side. >> >>> >>> >>>>> Because strangely , instead of using field to indicate a conflict (in >>>>> MCPatchOperation record) it does something strange and overly >>>>> complicated >>>>> (MCConflict). >>>>> >>>>> So, then each entry could contain >>>>> 'isApplicable' >>>>> and >>>>> 'isConflicting' >>>>> >>>>> and once user resolves the conflict, the isConflicting should be set to false, >>>>> while isApplicable are uniformly to indicate which version to use >>>>> (current or incoming one), when merging. >>>>> >>>>> >>>>>> No need for the extra menu item then. >>>>>> >>>>>> Regards, Gary >>>>>> >>>>>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>> Sent: Wednesday, June 22, 2011 3:40 PM >>>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes? >>>>>> >>>>>> >>>>>>> Here the code >>>>>>> http://code.google.com/p/pharo/issues/detail?id=4439 >>>>>>> >>>>>>> please tell me if it works for you. >>>>>>> I tested on simple merge and it works fine (the changes which i marked >>>>>>> as not applicable are not loaded). >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

June 26, 2011