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

Re: [Pharo-dev] inria jenkins got much faster

by Sven Van Caekenberghe

On 14 Aug 2013, at 11:43, Tudor Girba <tudor(a)tudorgirba.com> 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"

Aug. 14, 2013

inria jenkins got much faster

by Tudor Girba

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"

Aug. 14, 2013

Re: [Pharo-dev] [update 3.0] #30334

by StÃ©phane Ducasse

yes I saw it too On Aug 14, 2013, at 10:23 AM, Sebastian Tleye <stleye(a)gmail.com> wrote: > I think 11417 was not well integrated, the changes are not in the latest image. > > > 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > [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-Steph… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneD… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDuc… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDu… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-p… > > >

Aug. 14, 2013

[update 3.0] #30335

by StÃ©phane Ducasse

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-StephaneDuc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-StephaneDucasse.512.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1560.d…

Aug. 14, 2013

Re: [Pharo-dev] [update 3.0] #30334

by Sebastian Tleye

I think 11417 was not well integrated, the changes are not in the latest image. 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > [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-Steph… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-StephaneD… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-StephaneDuc… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-StephaneDucasse.5… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-StephaneDu… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Generated-code-non-existing-p… > > >

Aug. 14, 2013

Re: [Pharo-dev] The point of extending NativeBoost-Win32 more than neccessary?

by StÃ©phane Ducasse

On Aug 14, 2013, at 4:05 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 August 2013 00:57, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Igor, >> >> I dont see this neither as "destructive" nor as "critics", especially since: >> >> - you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;) >> >> - I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. >> In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion >> only be a workaround in need for better modularization or one/many separate platform specific projects >> >> As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have >> more ideas for better modularization with the same idea of moving this to independent projects. >> >> I would suggest: >> >> 1. NB really just includes the core functionality of an external interface (FFI), including the support for calls >> and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image. >> >> 2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API >> functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo >> image. We can make it accessible via a Configurations that are easily loadable from the config browser. >> I will do that as soon as time permits. >> >> 3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) >> we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides >> native functionality but still allows platform independence of calling code. >> I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would >> mean to have: >> >> OSWindow new open >> >> while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux >> API's for opening a Window are used. >> >> Regarding last changes/commits: >> As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. >> Will also write a test for it when theres the next minute. >> >> I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, >> Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. >> Just be a little bit patient for the next possible time slot. >> > > Good to know that we are aligned in our vision. > >> Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working >> example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure >> is required it would serve as a good example for callbacks too. It would also help if the proper marshalling >> for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding. > > Window callbacks is ones that very tricky (and ones which usually most > important ones). > Because they called not at the moment when you call some external > function, but at the moment > when VM handling events (during interrupt). > >> You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... > > Yes, i will check, but i suspect it don't exists :) > >> >> Thx >> T. > > > > -- > Best regards, > Igor Stasenko. >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by StÃ©phane Ducasse

On Aug 14, 2013, at 4:38 AM, Igor Stasenko <siguctua(a)gmail.com> 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 <sean(a)clipperadams.com> 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. >

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by ClÃ©ment Bera

2013/8/14 Igor Stasenko <siguctua(a)gmail.com> > 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) > This is possible but I don't think it belongs to the compiler to do that. I would rather modify Behavior so when it adds a method with no protocol it categorize it efficiently according to its superclasses / subclasses selectors and protocols.. > > On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> 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. > >

Aug. 14, 2013

Re: [Pharo-dev] Access to issue tracker?

by Javier PimÃ¡s

Cool, it worked. Went to "forgot password", put the registered email and received a link to change my pass. Thanks! Just to note, the http link doesn't work for me, but using https instead works ok. On Tue, Aug 13, 2013 at 11:38 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I never tried the monkey/registration page. > But you should be able to login here: http://pharo.fogbugz.org > > - reset your password (since you don't have one yet) > - login at http://pharo.fogbugz.org > > I hope that helps. > > On 2013-08-13, at 01:01, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Same here > > > > El 13/08/2013 0:34, Javier PimÃ¡s escribiÃ³: > >> Hi, I don't know if it's just me or if I'm doing something wrong but I > >> was never able to get a user for the issue tracker. I enter here > >> <http://bugs.pharo.org/issues/register>, put a username, an email and > >> tick the not a monkey box in order to create an account. It redirects me > >> here <https://pharo.fogbugz.com/> but I never get a mail or anything I > >> could use to login, what I am doing wrong? > >> > >> Cheers, > >> Javier > >> > >> -- > >> Lic. Javier PimÃ¡s > >> Ciudad de Buenos Aires > > > > > > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 14, 2013

Re: [Pharo-dev] Uniformizing Pharo

by Igor Stasenko

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) On 14 August 2013 04:32, Sean P. DeNigris <sean(a)clipperadams.com> 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.

Aug. 14, 2013