- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can't add a class-side instvar.

by Benjamin

Yes :) In Nautilus, there is an acceptor, an object knowing how to accept text depending of the contents. I bet the one used on class side is not the good one :) Ben On Jun 24, 2013, at 1:05 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > I reported this issue some time ago*, and is still reproducible in 30217. > > 1) open Nautilus > 2) select any class > 3) go class-side > 4) add a variable > > you will get a compilation error. > > Any idea? > > > *: https://pharo.fogbugz.com/f/cases/10734/Can-t-add-class-side-instance-varia… > > MartÃn >

June 24, 2013

Re: [Pharo-dev] Can't add a class-side instvar.

by Martin Dias

this last step was missing: 5) accept On Mon, Jun 24, 2013 at 1:05 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > I reported this issue some time ago*, and is still reproducible in 30217. > > 1) open Nautilus > 2) select any class > 3) go class-side > 4) add a variable > > you will get a compilation error. > > Any idea? > > > *: https://pharo.fogbugz.com/f/cases/10734/Can-t-add-class-side-instance-varia… > > MartÃn

June 24, 2013

Can't add a class-side instvar.

by Martin Dias

Hi I reported this issue some time ago*, and is still reproducible in 30217. 1) open Nautilus 2) select any class 3) go class-side 4) add a variable you will get a compilation error. Any idea? *: https://pharo.fogbugz.com/f/cases/10734/Can-t-add-class-side-instance-varia… MartÃn

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by Esteban Lorenzano

I never liked it, so I vote for removal :) On Jun 24, 2013, at 11:27 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: > >> Just remove it :) >> >> Doru > > Alternatively, start using it, and remove the rest of the is* methods on Object, which was the initial intent :P > > Of course, there's a tradeoff between locality of implementation and discoverability with (default) tools here, in that you get less implementors, and Object is cleaner, but at the cost that finding the actual meaning of is: in use in a specific piece of code outside of a debugger *can* be a painâ¦ > > In my mind, what's currently in use is the better tradeoff for day-to-day programming and maintenance . > > Extensions that don't require contrived protocol names for tool support would be a neat thing :) > > Cheers, > Henry

June 24, 2013

Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub?

by Nicolas Petton

yes, it should be :) On Jun 23, 2013, at 10:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Nicolas told me that he spent a day last week fixing some smalltalkhub bugs. > May be this is one is part of it. > > > On Jun 23, 2013, at 10:28 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> This is a typical, understandable problem. I had the same problem with my http://mc.stfx.eu Monticello repos once. The thing is that >> >> http://smalltalkhub.com/mc/dkh/metacello/main >> >> should redirect to >> >> http://smalltalkhub.com/mc/dkh/metacello/main/ >> >> not just serve the same content, because else the relative links are all wrong. >> >> You can try >> >> http://mc.stfx.eu/ZincHTTPComponents >> >> to see how it should work. >> >> And yes this is a StHub bug that can be fixed quite easily. >> >> Sven >> >> On 23 Jun 2013, at 22:04, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> >>> >>> ----- Original Message ----- >>> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >>> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> | Sent: Sunday, June 23, 2013 12:53:44 PM >>> | Subject: Re: [Pharo-dev] Metacello-ToolBox-dkh.131.mcz missing on smalltalkhub? >>> | >>> | >>> | On 2013-06-23, at 21:48, "Dale K. Henrichs" >>> | <dale.henrichs(a)gemtalksystems.com> wrote: >>> | >>> | > Cami, >>> | > >>> | > Did you confirm that smalltalkhub is producing incorrect urls? >>> | >>> | if you omit the trailing slash and click on a link of the version >>> | list in a browser, then yes. >>> | >>> >>> Cami, >>> >>> Smalltalkhub itself omits the trailing slash[1]: >>> >>> MCHttpRepository >>> location: 'http://smalltalkhub.com/mc/dkh/metacello/main' >>> user: 'dkh' >>> password: '' >>> >>> That's probably where I copied the link from to look at the full list of packages ... >>> >>> _I_ didn't do the omitting:) >>> >>> Dale >>> >>> [1] http://smalltalkhub.com/#!/~dkh/metacello >>> >> >> > -- Nicolas Petton http://www.nicolas-petton.fr

June 24, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Tests.Release.ReleaseTest.testObsoleteClasses

June 24, 2013

[update 3.0] #30218

by Marcus Denker

30218 ----- 10979 AlainTreeModel should use asString instead of printString to display items https://pharo.fogbugz.com/f/cases/10979 10880 PolyMorph part3 https://pharo.fogbugz.com/f/cases/10880 11000 Categorize All Monticello Methods https://pharo.fogbugz.com/f/cases/11000 10998 Add ReleaseTest>>testUnknownProcesses https://pharo.fogbugz.com/f/cases/10998 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.559.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.201… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/MonticelloGUI-MarcusDenker.23… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.819.d…

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by Henrik Johansen

On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: > Just remove it :) > > Doru Alternatively, start using it, and remove the rest of the is* methods on Object, which was the initial intent :P Of course, there's a tradeoff between locality of implementation and discoverability with (default) tools here, in that you get less implementors, and Object is cleaner, but at the cost that finding the actual meaning of is: in use in a specific piece of code outside of a debugger *can* be a painâ¦ In my mind, what's currently in use is the better tradeoff for day-to-day programming and maintenance . Extensions that don't require contrived protocol names for tool support would be a neat thing :) Cheers, Henry

June 24, 2013

Re: [Pharo-dev] why so many processes are running at startup time?

by Sven Van Caekenberghe

Igor, On 21 Jun 2013, at 13:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > Yes, the only thing i hate in this code is references to many different classes. > These processes actually represent various basic services of the system. > so i would prefer that these services register themselves somewhere, > like that we could have a clean code, something like: > > services collect: [:each | each process ] > > like that, you don't need to modify this method evry time you changing > the list/implementation etc. I implemented this on ReleaseTest, with a fixed list, for now. I understand your remark: some form of dependency injection is cleaner and more extensible/scaleable indeed. However, in this particular case, I am not 100% convinced: your dynamic list based on registration can only be as good as the registrars, if they make a mistake (failing to unregister), the list will become bad. Sven >> Sven >> >>> and get 6 processes remain: >>> (80) 745275392: Delay class>>handleTimerEvent >>> (60) Input events fetching process: InputEventFetcher>>waitForInput >>> (60) 1061945344: SmalltalkImage>>lowSpaceWatcher >>> (50) 946339840: WeakArray class>>finalizationProcess >>> (40s) Morphic UI process: nil >>> (10) 845938688: ProcessorScheduler class>>idleProcess >>> >>> is this OK? >>> >>> regards. >>> >>> >>> 2013/6/20 Marcus Denker <marcus.denker(a)inria.fr> >>> Hi, >>> >>> I think we should for now just kill them when building the image, I will check. >>> >>> On Jun 20, 2013, at 9:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>>> Hello, >>>> >>>> These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. >>>> Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. >>>> We will fix that within a few days. >>>> >>>> As a workaround, you can just kill these processes in your image for now ... >>>> >>>> Thanks for reporting the issue, >>>> >>>> >>>> >>>> >>>> 2013/6/20 NISHIHARA Satoshi <goonsh(a)gmail.com> >>>> There are 30 over processes are running at startup, Pharo-20607.image. >>>> >>>> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> >>>> >>>> regards. >>>> >>>> -- >>>> -- >>>> "NISHIHARA Satoshi" >>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>>> >>>> >>>> >>>> -- >>>> ClÃ©ment BÃ©ra >>>> Mate Virtual Machine Engineer >>>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >>> >>> >>> >>> >>> -- >>> -- >>> "NISHIHARA Satoshi" >>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >> >> > > >

June 24, 2013

MonticelloConfigurations Package

by Camillo Bruni

Has anybody a clue why there is a MonticelloConfigurations but it is not merged with the latest version in the Pharo30 repository? this looks a bit strange to me...

June 24, 2013