- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Uniformizing Pharo

by Sean P. DeNigris

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.

Aug. 14, 2013

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

by Igor Stasenko

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] The point of extending NativeBoost-Win32 more than neccessary?

by Torsten Bergmann

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. 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. You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... Thx T.

Aug. 13, 2013