May 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] running tests logged?

by Nicolas Cellier

Another possibility if you have a debugger is to use printAllStacks() . Works on linux with gdb at least... 2009/5/3 Igor Stasenko <siguctua(a)gmail.com>: > Hello, is there any way to log results whilie tests are running using > test runner? > My image hungs during one of tests, and i want to discover at which one. > Any hints , where i could hook to write into file entries like: > > running TestedClass>>testmerhod .... done (failed/passed etc). > > Btw, such files could be useful for exchange. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

Re: [Pharo-project] running tests logged?

by StÃ©phane Ducasse

may be the extension of keith but not in the dummy version we use. If I remember paolo extended them in GNUSmalltlk stef On May 3, 2009, at 12:17 PM, Igor Stasenko wrote: > Hello, is there any way to log results whilie tests are running using > test runner? > My image hungs during one of tests, and i want to discover at which > one. > Any hints , where i could hook to write into file entries like: > > running TestedClass>>testmerhod .... done (failed/passed etc). > > Btw, such files could be useful for exchange. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

[Pharo-project] running tests logged?

by Igor Stasenko

Hello, is there any way to log results whilie tests are running using test runner? My image hungs during one of tests, and i want to discover at which one. Any hints , where i could hook to write into file entries like: running TestedClass>>testmerhod .... done (failed/passed etc). Btw, such files could be useful for exchange. -- Best regards, Igor Stasenko AKA sig.

May 3, 2009

Re: [Pharo-project] MC merging in presence of trait -> DNU

by StÃ©phane Ducasse

to reproduce it try to merge CollectionsTests which are in PharoTaskForces project. stef On May 3, 2009, at 11:19 AM, StÃ©phane Ducasse wrote: > MCAddition>>shortSummary > > ... > self definition selector <- DNU selector > ... > > > So I would love to have time to look at MC1.5 but no time.... > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

[Pharo-project] MC merging in presence of trait -> DNU

by StÃ©phane Ducasse

MCAddition>>shortSummary ... self definition selector <- DNU selector ... So I would love to have time to look at MC1.5 but no time.... Stef

May 3, 2009

[Pharo-project] PseudoContext is obsolete

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=791 Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 2, 2009 11:32:54 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] 10296 available for download > > > > On Sat, May 2, 2009 at 9:33 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Hi eliot > > > is pseudoContext obsolete? > > yes. The StackVM does context-to-stack mapping without PseudoContext. > > > Stef > > For the psuedocontext I think you should check with Eliot I though he > said that class was no longer needed? > > > On 5/2/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > on fgorge > > https://gforge.inria.fr/frs/?group_id=1299 > > Pay attention that > > - copy and paste does not work (at least on mac) > > - you cannot obtain this image by doing a simple update from > 10281 > > > - font update at startup as a preference > (fixes http://code.google.com/p/pharo/issues/detail?id=689) > > - Issue 749: Put back ensureEndsWith: > > - event part one done manually > > - New event part two > > - literalsDo: fix again > > - fix polling argh (not copy and paste :)) > > - with manual premable for Delay fixing (sorry no copy and paste so > painful to write down all the details). > > - apply the last part of DelayCleanup.1.cs from > http://bugs.squeak.org/view.php?id=7321 > > - Remove Delay upper bound limitation > > - SharedQueue>>findFirst: > > - BlockClosure>>asText > > - InputEventSensor>>flushNonKbdEvents > > - literals do -> literalsDo: > > - StreamingOnOrderedCollection > > - Fixing conflict notion in traits since now trait methods are copied. > > - removing powermanagement > enhancing scriptLoader to ask for preamble or postscript > > - 762 MethodContext>>runSimulated:contextAtEachStep > - 772 isSuspended fix > - 770 copy and paste fix - igor suggestions > (still does not work after InputEventSensor > installPollingEventSensorFramework > > - sensor fixes again > > - issue 787: Change compactClassesArray for stackVm and Cog > - issue 783 better errorReportOn: of ContextPart > - issue 789: PseudoContext class initialize removed > > - issue 758: faster font rendering > - issue 790: BookMorph other removal > - issue 786: closing stream on remoteString > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

igor do you have a pointer on ephemerons because I forgot the details and these details are important. stef

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

On May 3, 2009, at 2:37 AM, Igor Stasenko wrote: > 2009/5/3 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> Beware: there are two issues here, not one. >> >> (a) the faulty remoteString code is ill behaved. Fine that can be >> fixed or as Igor suggested refactored to oblivion. >> > IMO this should be done sooner or later. Its a pain to see it. > Oh well, too bad, this is not the only thing which requires > attention :) > >> (b) The deeper issue is that we affected how finalization works so >> that this ill behavior now causes application failure. >> If in the past it worked, now it doesn't I don't see anyone really >> having a good answer other than perhaps my guess, >> and how do we get back to the point were ill behaviour by *my* code >> won't cause Socket Failures. >> > I used finalization in my code multiple times. It didn't caused many > problems, if you know how to do it right (by taking an implementation > into account). > >> No doubt people have ugly code that is *silently* busted like >> RemoteString, but they don't know it. >> And as you saw actually finding the culprit is difficult. >> >> Lastly some people DO use finalization to do resource cleanup on >> purpose, not as a safety fallback, so they will >> be impacted I think by the new Pharo behaviour. >> > It looks like i missed this part. Where i can read details about what > is altered in finalization, which could break things? In this thread or the one related john mentioned it. > > >> Wasn't finalization tagged as bloated and need fixing? Igor I'm sure >> suggested a few things before the flurry of >> code for optimizing semaphores and process switching? >> > Yes, i proposed a little change to VM (just a couple lines of code in > single method + registering additional special object) > which would allow us more direct finalization. > It not makes weak refs to be a full pledged ephemerons, but much > easier to adopt in VM. And besides you wont find any finalization code > in squeak which relies on ephemeron's special behavior -- reference > 'value' slot weakly, only when reference in 'key' slot is dies. > > http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.… > > >> On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Nicolas Cellier

2009/5/3 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Beware: there are two issues here, not one. > > (a) the faulty remoteString code is ill behaved. Fine that can be > fixed or as Igor suggested refactored to oblivion. > > (b) The deeper issue is that we affected how finalization works so > that this ill behavior now causes application failure. > If in the past it worked, now it doesn't I don't see anyone really > having a good answer other than perhaps my guess, > and how do we get back to the point were ill behaviour by *my* code > won't cause Socket Failures. > > No doubt people have ugly code that is *silently* busted like > RemoteString, but they don't know it. > And as you saw actually finding the culprit is difficult. > > Lastly some people DO use finalization to do resource cleanup on > purpose, not as a safety fallback, so they will > be impacted I think by the new Pharo behaviour. > > Wasn't finalization tagged as bloated and need fixing? Igor I'm sure > suggested a few things before the flurry of > code for optimizing semaphores and process switching? > Yes! RemoteString patch is what I would call "un pansement sur une jambe de bois" unless it has more of "un arbre qui cache la forÃªt".. We need to write a SUnit TestCase stressing the finalization mechanism and identify what's going on. Debugging such low level high priority multi-process may imply instrumenting the VM though... Nicolas > On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > >> Yes but why don't we close them with an ensure or something like that. >> I mean is the logic of the connection making it that we cannot use >> ensure or this is just a legacy? >> >> On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: >> >>> Well somewhere someone needs to close the socket before it is >>> *forgotten* >>> >>> On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: >>> >>>> I would like to know why does the system rely on finalisation to >>>> release socket >>>> Apparently david mentioned that this is the source of huge problems. >>>> So what would be the alternative? >>>> >>>> Stef >>> > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

On May 3, 2009, at 1:46 AM, John M McIntosh wrote: > Beware: there are two issues here, not one. > > (a) the faulty remoteString code is ill behaved. Fine that can be > fixed or as Igor suggested refactored to oblivion. > > (b) The deeper issue is that we affected how finalization works so > that this ill behavior now causes application failure. > If in the past it worked, now it doesn't I don't see anyone really > having a good answer other than perhaps my guess, > and how do we get back to the point were ill behaviour by *my* code > won't cause Socket Failures. Yes this was also implied in my remark. > No doubt people have ugly code that is *silently* busted like > RemoteString, but they don't know it. > And as you saw actually finding the culprit is difficult. > > Lastly some people DO use finalization to do resource cleanup on > purpose, not as a safety fallback, so they will > be impacted I think by the new Pharo behaviour. I agree! > > > Wasn't finalization tagged as bloated and need fixing? Igor I'm sure > suggested a few things before the flurry of > code for optimizing semaphores and process switching? > > On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > >> Yes but why don't we close them with an ensure or something like >> that. >> I mean is the logic of the connection making it that we cannot use >> ensure or this is just a legacy? >> >> On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: >> >>> Well somewhere someone needs to close the socket before it is >>> *forgotten* >>> >>> On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: >>> >>>> I would like to know why does the system rely on finalisation to >>>> release socket >>>> Apparently david mentioned that this is the source of huge >>>> problems. >>>> So what would be the alternative? >>>> >>>> Stef >>> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009