April 2015 - Pharo-dev - lists.pharo.org

why we removed debugTest from nautilus?

by Esteban Lorenzano

does anyone knows? Esteban

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by Thierry Goubier

Le 09/04/2015 16:10, stepharo a Ã©crit : > > > Le 7/4/15 15:19, Thierry Goubier a Ã©crit : >> Le 07/04/2015 15:14, Tudor Girba a Ã©crit : >>> This setting should be removed. Does anyone have anything against that? >> >> Or, could settings be rewritten so that we don't regularly triggers >> DNUs and MNUs when we reload them? >> >> You know, just regular, declarative, boring settings instead of >> something which execute code on non-existent Classes half of the time... > > We started to extract tge configuration code out of pillar but we do not > know if it will work for settings. > So far no time to check. > > It is called cocoon on pharoextras Small remark on the documentation on Smalltalkhub: it is STON-based, not JSON-based. Will you make this an item (replace settings by Cocoon) on the roadmap for Pharo5? I know I would. Thierry

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by Thierry Goubier

Le 09/04/2015 16:10, stepharo a Ã©crit : > > > Le 7/4/15 15:19, Thierry Goubier a Ã©crit : >> Le 07/04/2015 15:14, Tudor Girba a Ã©crit : >>> This setting should be removed. Does anyone have anything against that? >> >> Or, could settings be rewritten so that we don't regularly triggers >> DNUs and MNUs when we reload them? >> >> You know, just regular, declarative, boring settings instead of >> something which execute code on non-existent Classes half of the time... > > We started to extract tge configuration code out of pillar but we do not > know if it will work for settings. > So far no time to check. > > It is called cocoon on pharoextras Seems fine. Just browsing through it. Maybe a tad complex, to have to subclass both a CCConfiguration and a CCSTONConfigurationInterpreter for the thing to work. Flexible and powerfull. Composable. Is missing some of the code needed for settings: a default place to store them, the GUI part (settings browser), and the logic run-once. As the previous one, gives the feeling that settings are not application driven, but system driven (and applications are passive receivers). It's a design choice, and I'm not entirely happy with that choice, because it has a tendency to force decoupling layers in apps so that they can control if and when they take in account external settings or in-image settings changes. Thierry

April 9, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Guillermo Polito

Hi! It took me a while to read this thread before answering. :) With Camille we spent some hours this afternoon to take a look at this bug. We added new test cases and managed to do a hack that solves all the issues we could spot. You can find a slice for it in the inbox Now, we would like to have much more testing on it. SLICE-Issue-14606-Cant-see-some-variables-values-while-debugging-closure-GuillermoPolito.2 Our conclusion looking at the issue is that some parts of Opal (particularly the parts that manage the temp mapping and the temp vector) should be rewritten. By the moment our fix looks more like a hack. Guille El lun., 6 de abr. de 2015 a la(s) 3:43 p. m., Ben Coman < btc(a)openinworld.com> escribiÃ³: > So the current status of this is "apparent" VM bug. Is it apparent enough > that for now should I stop banging my head against it from the image side? > > > Actually I am working 10 hour shifts the next three weeks during the power > station's annual maintenance outage, so my time is probably limited anyway. > cheers -ben > > On Mon, Apr 6, 2015 at 4:10 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 2015-04-05 17:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> >>>> Thanks both of you for the energy you put into Pharo. >>>> The tam really appreciates. >>>> This is because there are guys like you that Pharo is worth being done. >>>> Thanks for the tests. >>>> Esteban has apparently found the bug on the VM. >>>> >>>> Stef >>>> >>>> >>> Energy breeds energy. For me it was an opportunity to learn more deep >>> stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm >>> happy if I've been able to beat the high grass enough to flush the tiger >>> into the open where the marksman can take a shot at it. >>> >>> Nice to flush out a VM bug (can't be too many of those left ;). Let us >>> know when we can do testing on it. I guess I'll read more about it on >>> [vm-dev]. >>> >>> cheers -ben >>> >> >> >> If it's a VM bug, the VM folks would be really really interested by a bug >> report, especially if ever it may affect Eliot's branch. >> Even if it's a Pharo only bug, it is still very interesting to know, >> because there's allways something to learn from a bug. >> So I'm all ears... >> >> cheers >> >> Nicolas >> > >

April 9, 2015

Fwd: [ci-announces] Memory upgrade on Jenkins servers

by Christophe Demarey

Scheduled shutdown of jenkins servers: DÃ©but du message rÃ©expÃ©diÃ© : > De : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > Date : 9 avril 2015 17:10:23 HAEC > Ã : ci-announces(a)inria.fr > Objet : [ci-announces] Memory upgrade on Jenkins servers > RÃ©pondre Ã : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > > Dear users, > > In order to prevent issues related to memory saturation on Jenkins servers, > an upgrade will be performed on next Monday (April 13th, 2015) between > 09:45 and 11:15. Meanwhile, the Jenkins instances will be stopped. In order > to prevent any issue, you should stop your Jenkins instances before the > maintenance. > > Thank you for your understanding, > Emmanuel > > -- > Emmanuel Jeanvoine > Inria Research Engineer > +33 3 54 95 86 21 > http://www.loria.fr/~ejeanvoi/

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by stepharo

Le 7/4/15 15:19, Thierry Goubier a Ã©crit : > Le 07/04/2015 15:14, Tudor Girba a Ã©crit : >> This setting should be removed. Does anyone have anything against that? > > Or, could settings be rewritten so that we don't regularly triggers > DNUs and MNUs when we reload them? > > You know, just regular, declarative, boring settings instead of > something which execute code on non-existent Classes half of the time... We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check. It is called cocoon on pharoextras Stef > > Thierry > >> >> Doru >> >> On Tue, Apr 7, 2015 at 2:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> thatâs not FFI, is NBOpenGL :) >> >> > On 07 Apr 2015, at 14:35, Richard Wettel <wettel(a)gmail.com >> <mailto:wettel@gmail.com>> wrote: >> > >> > Hi >> > >> > I bumped into a broken setting in FFI (see attached Screenshot). >> > After I exported the settings, every time I open an image a DNU >> comes to greet me: >> > >> > NBGlxAPI class>>moduleName: >> > >> > From the implementation, it seems the setting does not make much >> sense. Or if it does to somebody, it is probably still missing some >> part. >> > >> > Cheers >> > Ricky >> > >> > <ffiSetting.PNG> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" > > >

April 9, 2015

Re: [Pharo-dev] almost ready to release except for two bugs

by Henrik Johansen

> On 09 Apr 2015, at 3:43 , stepharo <stepharo(a)free.fr> wrote: > > Esteban > > I got a kind of endless loop open a debugger.... but I cannot reproduce it :( Could it be you were debugging something involving "large" collections? (Say, a 30MB ByteArray ) inspecting/debugging such objects is impossible with the new tools generates so much overhead you get stuck in GC thrashing hell before they even open... Cmd-Dot to interrupt won't make things better, since the debugger that opens has the same object as self, and would take as long to generate the inspector item. I know it's too late for 4.0, but it would be nice if someone with the proper GT skills would look at SequenceableCollection gtInspectorItemsIn: to see if it couldn't be made a bit more efficient, for instance avoiding the whole display: [ :aCollection | (1 to: self size) collect: [ :index | index -> (self at: index) ] ]; shenanigans. Cheers, Henry

April 9, 2015

Re: [Pharo-dev] almost ready to release except for two bugs

by Norbert Hartl

> Am 09.04.2015 um 15:43 schrieb stepharo <stepharo(a)free.fr>: > > Esteban > > I got a kind of endless loop open a debugger.... but I cannot reproduce it :( > Ask camille if he could reproduce the bug of the RB rename method. > I experienced this a lot of times but I cannot reproduce either. I thought you can trigger it if you have one halt that opens the debugger and then proceed to the next code segment that contains a halt, too. But I'm not sure. I only know that sometimes I'm lucky after pressing cmd-. 50 times to open 50 debuggers but have an escape back into the UI thread. Most of the time it does not work. It just opens debugger windows but I do not get back control to do anything. Norbert > > Stef > > Le 9/4/15 11:42, Esteban Lorenzano a Ã©crit : >> Hi, >> >> Soâ¦ subject says all. >> We need to fix this two: >> >> - https://pharo.fogbugz.com/f/cases/14606 <https://pharo.fogbugz.com/f/cases/14606> >> - the NOT REPORTED IN TRACKER MC BUG! (What are you thinking guys? Report, report, REPORT!â¦ I failed the Jedi examenâ¦ without report the bug does not exist) >> >> and we are ready to go. >> >> Of course, we will try to fix between today and tomorrowâ¦ but even if we succeed, since âyou shall not go into production a fridayâ, release will be monday. >> >> cheers, >> Esteban >> >

April 9, 2015

Re: [Pharo-dev] almost ready to release except for two bugs

by stepharo

Esteban I got a kind of endless loop open a debugger.... but I cannot reproduce it :( Ask camille if he could reproduce the bug of the RB rename method. Stef Le 9/4/15 11:42, Esteban Lorenzano a Ã©crit : > Hi, > > Soâ¦ subject says all. > We need to fix this two: > > - https://pharo.fogbugz.com/f/cases/14606 > - the NOT REPORTED IN TRACKER MC BUG! (What are you thinking guys? > Report, report, REPORT!â¦ I failed the Jedi examenâ¦ without report the > bug does not exist) > > and we are ready to go. > > Of course, we will try to fix between today and tomorrowâ¦ but even if > we succeed, since âyou shall not go into production a fridayâ, release > will be monday. > > cheers, > Esteban >

April 9, 2015

Re: [Pharo-dev] Inspecting Slots raises an error

by Juraj Kubelka

Thank you! Juraj > 9. 4. 2015 v 6:27, Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On 09 Apr 2015, at 10:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 09 Apr 2015, at 03:38, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I have tried to inspect >>> Model allSlots >>> and if I click on a slot it raises an error "WordLayout does not understand #definesSlot:â >>> >>> Is it problem of Slots or of GT-Inspector definition? >> >> a bug in Slotâ¦ #definesSlot: should be defines higher in the hierarchy. >> >> Fix: >> >> https://pharo.fogbugz.com/f/cases/15315/Inspecting-Slots-raises-an-error >> > > In 40 #598 > > Marcus

April 9, 2015