August 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20245

by Mariano Martinez Peck

On Tue, Aug 7, 2012 at 10:32 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > We are starting to have a lot of failing tests again > > CompressionTests.Archive.ZipArchiveTest.testCreateWithRelativeNames > CompressionTests.Archive.ZipArchiveTest.testZip > FileSystem.Tests.Disk.DiskFileSystemTest.testEntryAt > FileSystem.Tests.Memory.MemoryFileSystemTest.testEntryAt > KernelTests.Chronology.StopwatchTest.testSingleTiming > KernelTests.Chronology.StopwatchTest.testStartStop > KernelTests.Chronology.TimeStampTest.testComparing > KernelTests.Chronology.TimeStampTest.testSorting > Zinc.Tests.ZnLogSupportTests.testLogEvent > RPackage.Tests.RPackageWithDoTest.testInvariant > Tests.Release.ReleaseTest.testMethodsWithUnboundGlobals > Tests.Release.ReleaseTest.testUndeclared > > I think that we have to upgrade the monkey checking to stop such > regressions... > > Shouldn't Jenkins help us here? > -- Pavel > > On Mon, Aug 6, 2012 at 4:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > 20245 > > ----- > > > > Issue 6510: update zinc > > http://code.google.com/p/pharo/issues/detail?id=6510 > > > > Issue 6514: Add allDefinedExtensionMethods to RPackage > > http://code.google.com/p/pharo/issues/detail?id=6514 > > > > Issue 6521: RPackageOrganizer>>initialize does not initialize from > scratch > > http://code.google.com/p/pharo/issues/detail?id=6521 > > > > Issue 6523: Bug in RPackage >> systemSubPackages > > http://code.google.com/p/pharo/issues/detail?id=6523 > > > > Issue 6526: RPackage is not removing extensions from a removed class > > http://code.google.com/p/pharo/issues/detail?id=6526 > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 7, 2012

Re: [Pharo-project] [update 2.0] #20245

by Pavel Krivanek

We are starting to have a lot of failing tests again CompressionTests.Archive.ZipArchiveTest.testCreateWithRelativeNames CompressionTests.Archive.ZipArchiveTest.testZip FileSystem.Tests.Disk.DiskFileSystemTest.testEntryAt FileSystem.Tests.Memory.MemoryFileSystemTest.testEntryAt KernelTests.Chronology.StopwatchTest.testSingleTiming KernelTests.Chronology.StopwatchTest.testStartStop KernelTests.Chronology.TimeStampTest.testComparing KernelTests.Chronology.TimeStampTest.testSorting Zinc.Tests.ZnLogSupportTests.testLogEvent RPackage.Tests.RPackageWithDoTest.testInvariant Tests.Release.ReleaseTest.testMethodsWithUnboundGlobals Tests.Release.ReleaseTest.testUndeclared I think that we have to upgrade the monkey checking to stop such regressions... -- Pavel On Mon, Aug 6, 2012 at 4:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20245 > ----- > > Issue 6510: update zinc > http://code.google.com/p/pharo/issues/detail?id=6510 > > Issue 6514: Add allDefinedExtensionMethods to RPackage > http://code.google.com/p/pharo/issues/detail?id=6514 > > Issue 6521: RPackageOrganizer>>initialize does not initialize from scratch > http://code.google.com/p/pharo/issues/detail?id=6521 > > Issue 6523: Bug in RPackage >> systemSubPackages > http://code.google.com/p/pharo/issues/detail?id=6523 > > Issue 6526: RPackage is not removing extensions from a removed class > http://code.google.com/p/pharo/issues/detail?id=6526 >

Aug. 7, 2012

[Pharo-project] Script passing and StartupPreferences

by Sean P. DeNigris

It seems that (in 1.4, not sure about 2.0) if an image is launched with a script (e.g. "cogvm my.image my.st"), StartupPreferences are never run. Is that what's intended? I just realized, for instance, that all my images that were built by my Jenkins server (which pass a script as above) aren't using my shared cache (which is set in the preferences) and are downloading from http every time, yuck... Cheers, Sean -- View this message in context: http://forum.world.st/Script-passing-and-StartupPreferences-tp4643406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 7, 2012

[Pharo-project] Jenkins: SCM polling activity overload

by Sean P. DeNigris

See https://ci.lille.inria.fr/pharo/descriptor/hudson.triggers.SCMTrigger/ : There are more SCM polling activities scheduled than handled, so the threads are not keeping up with the demands. Check if your polling is hanging, and/or increase the number of threads if necessary. The following polling activities are currently in progress: Project â Running for Scripts-download 18 hr -- View this message in context: http://forum.world.st/Jenkins-SCM-polling-activity-overload-tp4643404.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 7, 2012

Re: [Pharo-project] Integrating Issue 6524: StartupPreferences loads non-Smalltalk files

by Sean P. DeNigris

Sean P. DeNigris wrote > > I'd like to get this integrated ASAP. > Someone, anyone!! ;-) j/k. This is a pretty simple change that has been reviewed by a smart human (Mariano). My preferences won't load in 2.0 until it's integrated. Thanks, Sean -- View this message in context: http://forum.world.st/Integrating-Issue-6524-StartupPreferences-loads-non-S… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 7, 2012

[Pharo-project] SqueakSource is down

by DeNigris Sean

http://www.downforeveryoneorjustme.com/http://www.squeaksource.com

Aug. 7, 2012

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Frank Shearar

On 6 August 2012 21:09, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: >> >> Hi! >> >> Last days I was playing to replace the image startup/shutdown mechanism >> via a pragma subscription because I was pissed off with how difficult is to >> integrate the change of a new startup in the system. The idea is: >> - reduce the mess on subscription/unsubscription, initialization, etc >> - reduce dependencies of external packages in core packages. >> >> This way, if you want to subscribe a class side method to be executed on >> startup, you annotate it: >> >> SomeClass>>startUp: resuming >> <systemStartup: #application> >> self blahblah. >> >> SomeClass>>startUp: quitting >> <systemShutdown: #kernel> >> self blahblah. > > > > > You need before: and after:. IMO, you also need to support multiple befores > or afters. I think that's much better than a priority scheme. You also need a tool to visualise the resulting DAG, if you want to understand the order in which the resulting methods will execute. Dumping the pragmas in an appropriate manner in a dotfile would be ample. frank > Also, as I said in response to Igor's message, you can register when pragma > methds are added/removed, rather than looking for methods when > initialization/shutdown is run. > >> >> >> Now, instead of an order in classes startup, I played with the idea of >> having run levels (which I named #kernel, #application and #user because I >> was not inspired :P). Then I replaced the whole system startup and It's >> working... >> >> The code is very simple, you can have a look at the category System-Tasks >> which can be downloaded from: >> >> MCGemstoneRepository >> location: 'http://ss3.gemstone.com/ss/PharoTaskForces' >> user: '' >> password: '' >> >> SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2 >> >> >> Be careful, that package contains the startup code + the replacement of >> the old startup by the new one :). >> >> Now, I'd like to have some feedback, u like it? u buy it? which should be >> the names for the run levels? how many run levels should we have? :P >> >> Cheers, >> Guille > > > > > -- > best, > Eliot >

Aug. 6, 2012

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Eliot Miranda

On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > Hi! > > Last days I was playing to replace the image startup/shutdown mechanism > via a pragma subscription because I was pissed off with how difficult is to > integrate the change of a new startup in the system. The idea is: > - reduce the mess on subscription/unsubscription, initialization, etc > - reduce dependencies of external packages in core packages. > > This way, if you want to subscribe a class side method to be executed on > startup, you annotate it: > > SomeClass>>startUp: resuming > <systemStartup: #application> > self blahblah. > > SomeClass>>startUp: quitting > <systemShutdown: #kernel> > self blahblah. > You need before: and after:. IMO, you also need to support multiple befores or afters. I think that's much better than a priority scheme. Also, as I said in response to Igor's message, you can register when pragma methds are added/removed, rather than looking for methods when initialization/shutdown is run. > > Now, instead of an order in classes startup, I played with the idea of > having run levels (which I named #kernel, #application and #user because I > was not inspired :P). Then I replaced the whole system startup and It's > working... > > The code is very simple, you can have a look at the category *System-Tasks > * which can be downloaded from: > > MCGemstoneRepository > location: 'http://ss3.gemstone.com/ss/PharoTaskForces' > user: '' > password: '' > > SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2 > > > Be careful, that package contains the startup code + the replacement of > the old startup by the new one :). > > Now, I'd like to have some feedback, u like it? u buy it? which should be > the names for the run levels? how many run levels should we have? :P > > Cheers, > Guille > -- best, Eliot

Aug. 6, 2012

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Eliot Miranda

On Sun, Aug 5, 2012 at 2:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 August 2012 23:37, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > I have the impression that you will need a finer order at least for the > kernel. > > so putting > >> SomeClass>>startUp: quitting > >> <systemShutdown: #kernel priority: 1000> > >> self blahblah. > > > > looks to me the way to go and yes we should clean that part two. > > > > Now what is the gain to have pragma and not just a class side method > returning a number? > > > > Stef > > > the downside of it, that you apparently more slower than explicit > subscription (you have to scan > over all methods with such pragma). > No. Registration can be done when methods are added or removed. Pragmas don't have to be scanned on each invocation. Instead the need is for a hook when methods are added or removed, and such hooks exist. > > i cannot remember what solution i proposed.. ah ok.. i recall. > i proposed to introduce a session-awareness. i.e. an object holds a > reference to a session object > and before each access to its some session-specific resource it should > check if session has changed or not. > and if session is obsolete, then you know that you must reinitialize > (meaning do a startup). > this is what i did in NB: it does not registering for startup, but > instead it initializing at first attempt to use it. So if nobody using > it, nothing happens (means no extra cycles burned at startup for > nothing). > This also solves nicely a problem with priority of service initialization: > - imagine service A requires service B to function, > but user code attempts to access a service A first. Now since service > A will try to access a service B first, > as result, a service B will be naturally (re)initialized first. > Like that, you don't even need to think (or make sure), who should be > (re)initialized first, because chain of priority automatically adjusts > itself according to program flow. > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Aug. 6, 2012

Re: [Pharo-project] New feature in Nautilus

by StÃ©phane Ducasse

On Aug 6, 2012, at 6:51 PM, Benjamin wrote: > I will ;) > > Be first, I will rest ( sleeping in my hammock seams to be a reallyyyyy good idea ^^ ) :) Indeed rat because ESUG, I should do the same. Now I'm getting less tired so this is good to feel that. I will reread dune :) Stef

Aug. 6, 2012