[Pharo-dev] XML writer in the default image
As reported a while ago (https://pharo.fogbugz.com/default.asp?7412#80347), the TestRunner is crashing when test failures accidentally spit out XML sensitive characters: https://ci.inria.fr/pharo/view/all/job/Pharo-3.0-Regression-Tests/304/VM=vm,label=pharo-linux64.ci.inria.fr/consoleFull I don't really see a reason to generate XML by concatenating strings, so I wonder whether we could include the XMLWriter in the default image? This way I could finally fix the HDTestRunner with very little effort.
Re: [Pharo-dev] --no-quit option of eval command handler broken ?
I can confirm. However, if you save the image in interactive mode it works again. On 2013-08-14, at 17:09, Sven Van Caekenberghe wrote: > Hi, > > I have the impression that the --no-quit option of the eval command line > handler is broken in 3.0 latest. > > This used to work > > ./pharo Pharo.image --no-quit eval 'ZnServer startDefaultOn: 8080.' > > while now, only this works > > ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [1 hour asDelay > wait] repeat.' > > Can anyone confirm this ? Maybe with another example ? > > It is a bit hard to debug: nothing happens with --no-quit, no error, no log > file… > > Sven > > >
[Pharo-dev] --no-quit option of eval command handler broken ?
Hi, I have the impression that the --no-quit option of the eval command line handler is broken in 3.0 latest. This used to work ./pharo Pharo.image --no-quit eval 'ZnServer startDefaultOn: 8080.' while now, only this works ./pharo Pharo.image eval 'ZnServer startDefaultOn: 8080. [1 hour asDelay wait] repeat.' Can anyone confirm this ? Maybe with another example ? It is a bit hard to debug: nothing happens with --no-quit, no error, no log file… Sven
Re: [Pharo-dev] Uniformizing Pharo
ah looks very nice, indeed much more powerful than my hack. If you have time, switch to real regular expressions, because things like > add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: > #converting); will easily produce false positives. For instance #assert: will end up in converting, which is not what you want ;) => /as[A-Z][a-zA-Z]*/ for instance does a much better job On 2013-08-14, at 15:24, Stéphane Ducasse wrote: > Ok I checked and I prefer the one I used because you can express nice rules :) > My next step will be to check the tests again, hack/replace the > methodClassifier and code with the hacked version for a while > and push everything in the system. Now I will look to see how to make them > polymorphic because the classifier is simpler > > Here is the default rules list (I added bench from the other list). > > What is nice is that > - we can express that the superclass should be used in last resort > - I filtered the extensions for now. > > > > defaultCategorizationRules > > "The order is relevant, the categorizer uses the first rule matching - > DF" > > ^OrderedCollection new > add: MethodCategorizationRule forAccessors; > > "initialize" > add: (MethodCategorizationRule whenSelectorMatches: > 'initialize*' categorizeIn: #initialization); > add: (MethodCategorizationRule whenSelectorMatches: 'init*' > categorizeIn: #initialization); > add: (MethodCategorizationRule whenSelectorMatches: 'default*' > categorizeIn: #defaults); > > add: (MethodCategorizationRule whenSelectorMatches: 'as*' > categorizeIn: #converting); > add: (MethodCategorizationRule whenSelectorMatches: 'hash' > categorizeIn: #comparing); > "order is important" > > "testing" > add: (MethodCategorizationRule whenSelectorMatches: 'is*' > categorizeIn: #testing); > add: (MethodCategorizationRule whenSelectorMatches: 'has*' > categorizeIn: #testing); > > add: (MethodCategorizationRule whenSelectorMatches: '=' > categorizeIn: #comparing); > > > add: (MethodCategorizationRule whenSelectorMatches: 'new' > categorizeIn: #'instance creation'); > add: (MethodCategorizationRule whenSelectorMatches: 'setting' > categorizeIn: #'settings'); > > add: (MethodCategorizationRule whenSelectorMatches: 'printOn:' > categorizeIn: #printing); > add: (MethodCategorizationRule whenSelectorMatches: 'storeOn:' > categorizeIn: #printing); > > add: (MethodCategorizationRule whenSelectorMatches: '*copy*' > categorizeIn: #copying); > > add: (MethodCategorizationRule whenSelectorMatches: 'draw*' > categorizeIn: #drawing); > add: (MethodCategorizationRule whenSelectorMatches: 'bench*' > categorizeIn: #benchmarking); > add: (MethodCategorizationRule whenSelectorMatches: 'signal*' > categorizeIn: #signalling); > add: (MethodCategorizationRule whenSelectorMatches: 'add*' > categorizeIn: #adding); > add: (MethodCategorizationRule whenSelectorMatches: 'remove*' > categorizeIn: #adding); > > add: (MethodCategorizationRule whenSelectorMatches: 'open*' > categorizeIn: #opening); > add: (MethodCategorizationRule whenSelectorMatches: 'update*' > categorizeIn: #updating); > add: (MethodCategorizationRule whenSelectorMatches: 'change*' > categorizeIn: #updating); > > add: (MethodCategorizationRule whenSelectorMatches: 'accept*' > categorizeIn: #'visitor accepting'); > add: (MethodCategorizationRule whenSelectorMatches: 'visit*' > categorizeIn: #visiting); > > add: (MethodCategorizationRule whenSelectorMatches: 'menu*' > categorizeIn: #menus); > > add: (MethodCategorizationRule whenSelectorMatches: 'value' > categorizeIn: #value); > > "test cases" > add: (MethodCategorizationRule > whenSelectorMatches: 'test*' > andClassInheritsFrom: TestCase > categorizeIn: #tests); > > add: (MethodCategorizationRule > whenSelectorMatches: 'setUp' > andClassInheritsFrom: TestCase > categorizeIn: #'setup'); > add: (MethodCategorizationRule > whenSelectorMatches: 'tearDown' > andClassInheritsFrom: TestCase > c
Re: [Pharo-dev] Uniformizing Pharo
Ok I checked and I prefer the one I used because you can express nice rules :) My next step will be to check the tests again, hack/replace the methodClassifier and code with the hacked version for a while and push everything in the system. Now I will look to see how to make them polymorphic because the classifier is simpler Here is the default rules list (I added bench from the other list). What is nice is that - we can express that the superclass should be used in last resort - I filtered the extensions for now. defaultCategorizationRules "The order is relevant, the categorizer uses the first rule matching - DF" ^OrderedCollection new add: MethodCategorizationRule forAccessors; "initialize" add: (MethodCategorizationRule whenSelectorMatches: 'initialize*' categorizeIn: #initialization); add: (MethodCategorizationRule whenSelectorMatches: 'init*' categorizeIn: #initialization); add: (MethodCategorizationRule whenSelectorMatches: 'default*' categorizeIn: #defaults); add: (MethodCategorizationRule whenSelectorMatches: 'as*' categorizeIn: #converting); add: (MethodCategorizationRule whenSelectorMatches: 'hash' categorizeIn: #comparing); "order is important" "testing" add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #testing); add: (MethodCategorizationRule whenSelectorMatches: 'has*' categorizeIn: #testing); add: (MethodCategorizationRule whenSelectorMatches: '=' categorizeIn: #comparing); add: (MethodCategorizationRule whenSelectorMatches: 'new' categorizeIn: #'instance creation'); add: (MethodCategorizationRule whenSelectorMatches: 'setting' categorizeIn: #'settings'); add: (MethodCategorizationRule whenSelectorMatches: 'printOn:' categorizeIn: #printing); add: (MethodCategorizationRule whenSelectorMatches: 'storeOn:' categorizeIn: #printing); add: (MethodCategorizationRule whenSelectorMatches: '*copy*' categorizeIn: #copying); add: (MethodCategorizationRule whenSelectorMatches: 'draw*' categorizeIn: #drawing); add: (MethodCategorizationRule whenSelectorMatches: 'bench*' categorizeIn: #benchmarking); add: (MethodCategorizationRule whenSelectorMatches: 'signal*' categorizeIn: #signalling); add: (MethodCategorizationRule whenSelectorMatches: 'add*' categorizeIn: #adding); add: (MethodCategorizationRule whenSelectorMatches: 'remove*' categorizeIn: #adding); add: (MethodCategorizationRule whenSelectorMatches: 'open*' categorizeIn: #opening); add: (MethodCategorizationRule whenSelectorMatches: 'update*' categorizeIn: #updating); add: (MethodCategorizationRule whenSelectorMatches: 'change*' categorizeIn: #updating); add: (MethodCategorizationRule whenSelectorMatches: 'accept*' categorizeIn: #'visitor accepting'); add: (MethodCategorizationRule whenSelectorMatches: 'visit*' categorizeIn: #visiting); add: (MethodCategorizationRule whenSelectorMatches: 'menu*' categorizeIn: #menus); add: (MethodCategorizationRule whenSelectorMatches: 'value' categorizeIn: #value); "test cases" add: (MethodCategorizationRule whenSelectorMatches: 'test*' andClassInheritsFrom: TestCase categorizeIn: #tests); add: (MethodCategorizationRule whenSelectorMatches: 'setUp' andClassInheritsFrom: TestCase categorizeIn: #'setup'); add: (MethodCategorizationRule whenSelectorMatches: 'tearDown' andClassInheritsFrom: TestCase categorizeIn: #'setup'); "baselines, versions..." add: (MethodCategorizationRule whenSelectorMatches: 'version*' andClassMatches: 'ConfigurationOf*' categorizeIn: #'versions'); add: (MethodCategorizationRule whenSelectorMatches: 'baseline*' andClassMatches: 'ConfigurationOf*
Re: [Pharo-dev] Uniformizing Pharo
> Did you use the method categorizer that is already in the image? > > => MethodClassifier > > it implements already a lot of rules, so you should plug in your tool there > or remove MethodClassifier and make it work with nautilus. otherwise we have > a lot of duplicated functionality. I was not aware of it I will look at it. In fact there was a method categorizer in a nice package with tests and I took this one and adapted it. I will check the rules. Stef
Re: [Pharo-dev] Uniformizing Pharo
Did you use the method categorizer that is already in the image? => MethodClassifier it implements already a lot of rules, so you should plug in your tool there or remove MethodClassifier and make it work with nautilus. otherwise we have a lot of duplicated functionality. On 2013-08-14, at 02:44, Stéphane Ducasse wrote: > On Aug 14, 2013, at 4:38 AM, Igor Stasenko wrote: > >> i wonder, if we can modify the compiler, so that when it sees that >> method's selector has well known name, it categorizing method >> automatically under right category :) >> (dunno however, what to do about existing code, when you recompiling it) > > we will integrate the categorizer close to the code browser and may be later > the compiler > > >> >> On 14 August 2013 04:32, Sean P. DeNigris wrote: >>> Stéphane Ducasse wrote I started to be fed up about protocol inconsistencies >>> >>> Amen >>> >>> >>> Stéphane Ducasse wrote So I will propose a set of rules (and a tool - I'm working on it) to automatically categorize methods. ... Now we discussed today with esteban for initialize* we will use 'initialization' >>> >>> Yay! >>> >>> >>> >>> - >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Uniformizing-Pharo-tp4703357p4703577.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >
[Pharo-dev] [update 3.0] #30336
Uniformity comes to you :) 30336 - - issue 11420 Monticello is looking for all ancestors even when there are none https://pharo.fogbugz.com/default.asp?11420 - issue 11408 https://pharo.fogbugz.com/default.asp?11408 https://pharo.fogbugz.com/default.asp?11408 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Zodiac-Extra-StephaneDucasse.10.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Zodiac-Core-StephaneDucasse.34.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Zinc-HTTP-StephaneDucasse.377.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Zinc-Character-Encoding-Core-StephaneDucasse.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/UIManager-StephaneDucasse.110.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Transcript-StephaneDucasse.11.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-StephaneDucasse.559.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-StephaneDucasse.1212.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Scanning-StephaneDucasse.5.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-StephaneDucasse.7.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Core-StephaneDucasse.11.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.611.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-StephaneDucasse.27.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Tools-StephaneDucasse.104.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-StephaneDucasse.900.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Serial Port-StephaneDucasse.23.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-FileRegistry-StephaneDucasse.27.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-FilePackage-StephaneDucasse.93.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-StephaneDucasse.139.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Clipboard-StephaneDucasse.30.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Announcements-StephaneDucasse.51.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/StartupPreferences-StephaneDucasse.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-StephaneDucasse.227.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-StephaneDucasse.129.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-StephaneDucasse.55.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-StephaneDucasse.62.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-StephaneDucasse.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-StephaneDucasse.150.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-StephaneDucasse.37.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-StephaneDucasse.33.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-StephaneDucasse.373.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Shout-StephaneDucasse.195.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UITesting-StephaneDucasse.15.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UI-StephaneDucasse.75.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-StephaneDucasse.90.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-StephaneDucasse.133.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Containers-StephaneDucasse.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-StephaneDucasse.27.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-StephaneDucasse.74.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-StephaneDucasse.26.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneDucasse.55.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Core-StephaneDucasse.188.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Changes-StephaneDucasse.44.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RecentSubmissions-StephaneDucasse.199.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-StephaneDucasse.254.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDucasse.886.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-StephaneDucasse.103.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Geometry-StephaneDucasse.11.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-EventEnhancements-StephaneDucasse.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/PackageInfo-StephaneDucasse.109.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-StephaneDucasse.197.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-StephaneDucasse.387.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NonInteractiveTranscript-StephaneDucasse.8.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NewList-StephaneDucasse.54.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Network-UUID-StephaneDucasse.27.
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/423/ 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion
Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?
Thanks for the feedback. Please let us know if you find problems…. because we could not find the original code which was probably never in the source management. So we really enjoy seeing your code running on Pharo :) Stef On Aug 14, 2013, at 1:06 PM, NISHIHARA Satoshi wrote: > I've just noticed github message > - added missing methods for SerialPlugin > https://github.com/pharo-project/pharovm/commit/f7c0b24ffde391c93fc479ab7ba1e0fe185bc669 > > and tested MIDIPlugin with 214 VM and Pharo-20618.image. > IT WORKS! > > thank you!! > > > > 2013/8/5 Igor Stasenko : >> On 4 August 2013 18:35, laurent laffont wrote: >>> Hi, >>> >>> I was looking about MIDI on Linux today, and may be that's related. On >>> Linux, for the MIDI plugin, there's 2 files: >>> - sqUnixMIDIALSA.inc >>> - sqUnixMIDINone.inc >>> >>> it seems sqUnixMIDINone is build, and not ALSA one. In >>> /platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c: >>> #if defined(USE_MIDI_ALSA) >>> # include "sqUnixMIDIALSA.inc" >>> #else >>> # include "sqUnixMIDINone.inc" >>> #endif >>> >>> USE_MIDI_ALSA is set in a configure script, and if I understand correctly, >>> it is not used with the cmake process ? Anyway, I've changed to: >>> #include "sqUnixMIDIALSA.inc" >>> >>> and the file compile, but fail to link. It seems gcc doesn't have the needed >>> -l flag to link to alsa lib, but I don't know where to specify this (I >>> suppose somewhere in VMMaker ?) >>> >> Look for CPlatformConfig and its descendants. >> >>> Cheers, >>> >>> Laurent >>> >>> >>> >>> >>> >>> On Sun, Aug 4, 2013 at 5:09 PM, NISHIHARA Satoshi wrote: is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? Stéphane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 on Mac 10.8.3. but I can't use MIDIPlugin on Mac OSX 10.6.8. SimpleMIDIPort>>#midiIsSupported -> false SimpleMIDIPort>>#primPortCount -> 0 vm: Pharo.app(13/03/13) Pharo-126.app(13/05/04) Pharo-145.app(13/05/31) Pharo-169.app(13/07/10) Pharo-186.app(13/07/15) Pharo-187.app(13/07/19) Pharo-188.app(13/07/31) I would like to know whether it is a problem of all those that are using 10.6.8 or personal trouble. -p.s.- On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, SimpleMIDIPort>>#midiIsSupported -> true SimpleMIDIPort>>#primPortCount -> 1 regards. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >
Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?
Ah yes... I forget to send a mail to the list, but I spent monday fixing the MIDI plugin :P cool to know that it worked! Esteban On Aug 14, 2013, at 1:06 PM, NISHIHARA Satoshi wrote: > I've just noticed github message > - added missing methods for SerialPlugin > https://github.com/pharo-project/pharovm/commit/f7c0b24ffde391c93fc479ab7ba1e0fe185bc669 > > and tested MIDIPlugin with 214 VM and Pharo-20618.image. > IT WORKS! > > thank you!! > > > > 2013/8/5 Igor Stasenko : >> On 4 August 2013 18:35, laurent laffont wrote: >>> Hi, >>> >>> I was looking about MIDI on Linux today, and may be that's related. On >>> Linux, for the MIDI plugin, there's 2 files: >>> - sqUnixMIDIALSA.inc >>> - sqUnixMIDINone.inc >>> >>> it seems sqUnixMIDINone is build, and not ALSA one. In >>> /platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c: >>> #if defined(USE_MIDI_ALSA) >>> # include "sqUnixMIDIALSA.inc" >>> #else >>> # include "sqUnixMIDINone.inc" >>> #endif >>> >>> USE_MIDI_ALSA is set in a configure script, and if I understand correctly, >>> it is not used with the cmake process ? Anyway, I've changed to: >>> #include "sqUnixMIDIALSA.inc" >>> >>> and the file compile, but fail to link. It seems gcc doesn't have the needed >>> -l flag to link to alsa lib, but I don't know where to specify this (I >>> suppose somewhere in VMMaker ?) >>> >> Look for CPlatformConfig and its descendants. >> >>> Cheers, >>> >>> Laurent >>> >>> >>> >>> >>> >>> On Sun, Aug 4, 2013 at 5:09 PM, NISHIHARA Satoshi wrote: is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? Stéphane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 on Mac 10.8.3. but I can't use MIDIPlugin on Mac OSX 10.6.8. SimpleMIDIPort>>#midiIsSupported -> false SimpleMIDIPort>>#primPortCount -> 0 vm: Pharo.app(13/03/13) Pharo-126.app(13/05/04) Pharo-145.app(13/05/31) Pharo-169.app(13/07/10) Pharo-186.app(13/07/15) Pharo-187.app(13/07/19) Pharo-188.app(13/07/31) I would like to know whether it is a problem of all those that are using 10.6.8 or personal trouble. -p.s.- On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, SimpleMIDIPort>>#midiIsSupported -> true SimpleMIDIPort>>#primPortCount -> 1 regards. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >
Re: [Pharo-dev] inria jenkins got much faster
Yes, we are always using the latest :). I just saw now the report about #20619. http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/81515 Wow, this is a phenomenal boost! Thank you very much. Doru On Wed, Aug 14, 2013 at 11:46 AM, Esteban Lorenzano wrote: > if you are using latest 2.0, that's probably because the integration of > the RPackageSet cache. > the previous slowdown was exponential, so big projects like moose took > *really* much time to load. > > Esteban > > > On Aug 14, 2013, at 11:43 AM, Tudor Girba wrote: > > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the > Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from > 11 minutes to 3 minutes. This is fantastic, but I do not know why the > difference occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the > infrastructure. > > Anyone has any idea as to why this happens? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Updating the Pharo Contributors listing
Many people already submitted their details and I edited a couple of entries manually to add at least an email address, so the list is already looking better: http://contributors.pharo.org Please spread the word and convince everyone to step in and update their info. On 12 Aug 2013, at 17:12, Sven Van Caekenberghe wrote: > Dear Fellow Pharoers, > > As some of you may know, we have a page listing Pharo Contributors > > http://www.pharo-project.org/community/contributors > > This page was manually constructed and urgently needs an update. > Based on the code behind the Pharo Consultants page > > http://consultants.pharo.org > > we want a similar data driven, statically generated page for Pharo > Contributors > > http://contributors.pharo.org > > the new page is based on some of the old data, but needs updating. Many > people are missing as well. So please, please, edit the template and send me > your new or up to date information. > > PharoContributor new > name: 'Stéphane Ducasse'; > id: 'stephaneducasse'; > email: 'stephane.duca...@inria.fr'; > website: 'http://stephane.ducasse.free.fr/'; > description: 'Research director at INRIA Lille leading the RMoD Team. Pharo > board member and president of ESUG.'; > image: 'http://stephane.ducasse.free.fr/StefFingerOnNose128.jpg'; > yourself > > PharoContributor new > name: 'Camillo Bruni'; > email: 'camillobr...@gmail.com'; > description: 'Cosmopolitan Swiss Hacker, currently at INRIA'; > yourself > > Some notes: > > - id is only needed when your name contains non-ascii characters > - email will default to pharo-dev@lists.pharo.org if missing > - website will default to a Google search for your name if a URL is missing > - image can be omitted if you have a Gravatar, else it becomes a smiley > - images will be rescaled to fit in 128x128, the URL needs to remain > accessible > - description is a pure text String, no markup is allowed > - the description does not have to be too formal > - the page is statically generated, only then do changes take effect > > Regards, > > Sven, on behalf of the Pharo Board. > > PS: If you are curious, the code for generating this page can be found at > > http://www.smalltalkhub.com/#!/~Pharo/PharoPeople >
Re: [Pharo-dev] inria jenkins got much faster
if you are using latest 2.0, that's probably because the integration of the RPackageSet cache. the previous slowdown was exponential, so big projects like moose took *really* much time to load. Esteban On Aug 14, 2013, at 11:43 AM, Tudor Girba wrote: > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the Moose > job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 > minutes to 3 minutes. This is fantastic, but I do not know why the difference > occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the infrastructure. > > Anyone has any idea as to why this happens? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"
Re: [Pharo-dev] inria jenkins got much faster
On 14 Aug 2013, at 11:43, Tudor Girba wrote: > Hi, > > I just noticed that the Jenkins jobs got much faster. For example, the Moose > job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 > minutes to 3 minutes. This is fantastic, but I do not know why the difference > occurs. > > It seems that the difference started yesterday before 15:00: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) > > As it affected multiple jobs, I suspect it has to do with the infrastructure. > > Anyone has any idea as to why this happens? Is it not related to the RPackage caching that significantly improves code loading ? > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"
[Pharo-dev] inria jenkins got much faster
Hi, I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. It seems that the difference started yesterday before 15:00: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) As it affected multiple jobs, I suspect it has to do with the infrastructure. Anyone has any idea as to why this happens? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] [update 3.0] #30334
yes I saw it too On Aug 14, 2013, at 10:23 AM, Sebastian Tleye wrote: > I think 11417 was not well integrated, the changes are not in the latest > image. > > > 2013/8/13 Stéphane Ducasse > [update 3.0] #30334 > 30334 > - > > - issue 11418 RBBrowserEnvironment definesClass: is unfinished > https://pharo.fogbugz.com/default.asp?11418 > > - issue 11417 Test for checking repeated code in superclasses must not watch > in nativeBoost classes > https://pharo.fogbugz.com/default.asp?11417 > > - issue 11415 More green tests for BehaviorTest and MetaclassTest > https://pharo.fogbugz.com/default.asp?11415 > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.609.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-StephaneDucasse.23.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneDucasse.52.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDucasse.64.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.546.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDucasse.41.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-package-StephaneDucasse.1.diff > > >
[Pharo-dev] [update 3.0] #30335
30335 - - issue 11415 More green tests for BehaviorTest and MetaclassTest https://pharo.fogbugz.com/default.asp?11415 - issue 11406 Cleaning categories: Object https://pharo.fogbugz.com/default.asp?11406 - issue 11251 Add coherent icons set for up/down/top/bottom actions https://pharo.fogbugz.com/default.asp?11251 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-StephaneDucasse.883.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.512.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.547.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1560.diff
Re: [Pharo-dev] [update 3.0] #30334
I think 11417 was not well integrated, the changes are not in the latest image. 2013/8/13 Stéphane Ducasse > [update 3.0] #30334 > 30334 > - > > - issue 11418 RBBrowserEnvironment definesClass: is unfinished > https://pharo.fogbugz.com/default.asp?11418 > > - issue 11417 Test for checking repeated code in superclasses must not > watch in nativeBoost classes > https://pharo.fogbugz.com/default.asp?11417 > > - issue 11415 More green tests for BehaviorTest and MetaclassTest > https://pharo.fogbugz.com/default.asp?11415 > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-StephaneDucasse.609.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-StephaneDucasse.23.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneDucasse.52.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDucasse.64.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.546.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDucasse.41.diff > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-package-StephaneDucasse.1.diff > > >
