- Pharo-dev - lists.pharo.org

[Pharo-project] Testing Pharo OneClick 1.3

by HernÃ¡n Morales Durand

Sorry no time to open tickets. Open Monticello Browser Hit +Config Hit Ok Hit Cancel Hit Cancel Hit Cancel ... OBSystemBrowser openOnClass: Behavior select ObsoleteSubclasses class variable hit mouse right-button Create a category Create a class inside this category Create another category (empty) Rename the first category to be the second one Nothing happens Tools -> Recover Lost Changes Select any of the last 5 entries MNU SystemNavigation default browseAllUnimplementedCalls. MNU HernÃ¡n

Sept. 1, 2011

Re: [Pharo-project] RB API

by StÃ©phane Ducasse

> > On my dead slow single-core server from the year 2000 it takes 5 minutes to load RB, OB and run all test and lint rules (if no other builds run at the same time). I assume that it is possible to load the necessary packages on a modern machine in under 1 min right after each commit. > > Also note that with builder.sh one can do incremental builds, that is to update the image from the previous build. I am not currently using this trick anywhere, but it makes builds even on my slow machines almost instantanious. We will see but right now we do have the resources to think and build more infrastructure. Stef

Sept. 1, 2011

Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release

by Alexandre Bergel

I know this, but I haven't bumped into a serious problem, even when multiple people are committing. I am the only to create a new version though. It has always worked as a charm. Alexandre Le 31 aoÃ»t 2011 Ã 18:26, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > Hi, > > For development involving multiple people in the same time, you cannot rely on hardcoded package versions in configurations, because there is no merge support, so you will never know when you are missing a version. > > The only model that works reliably now is to depend on a baseline for development. That means that when you develop, you integrate relentlessly the latest package versions. > > When you release you can use the same baseline and hardcode the package versions. > > Cheers, > Doru > > > On 31 Aug 2011, at 23:02, Alexandre Bergel wrote: > >> Dale and I worked on the MetacelloBrowser. I believe the UI needs to be polished. Probably having something based on Glamour would cool to have. >> I worked on Versionner because I just need a commit button. >> >> Cheers, >> Alexandre >> >> >> On 31 Aug 2011, at 17:57, Igor Stasenko wrote: >> >>> is it just me, or there are more people who know nothing about it? >>> >>> i know how to do a parallel programs, >>> but i have no means to know what happens in parallel to my little universe unless i can read it from some well known source :) >>> >>> On 31 August 2011 23:46, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> :-) >>> I use Versionner for simple case and the MetacelloBrowser for more complicated stuff. >>> Check at the screenshot. You see, there is a commit button :-) It saves all the dependent packages, create a new version, ask you for the comment, and save the config. I rarely use the Monticello browser actually. >>> >>> <Screen Shot 2011-08-31 at 17.24.53.png> >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 31 Aug 2011, at 17:23, Igor Stasenko wrote: >>> >>>> On 31 August 2011 23:19, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>>> For development configuration is useless and just time sink. >>>>> >>>>> I strongly disagree. Metacello was sold to please users. Actually, I use it for me, the developper. I create a new version at each commit. It works wonderfully. >>>>> >>>> >>>> sorry, but if during development you need to do 2 commits of 20 >>>> packages , calculate how much time it would take for you to >>>> manuallly update a configuration for each update. >>>> it is time sink. >>>> >>>> if you do that once per day, its okay.. but for every commit . no. its >>>> is absurd. >>>> >>>>> Alexandre >>>>> >>>>> >>>>>> But for release it has completely different purpose: it helps us to >>>>>> identify what exactly and what version of it will be put in final >>>>>> version. And gives a simple and concrete answer how to reproduce it, >>>>>> in case of need. >>>>>> Since we're are talking about release, i don't see how we could do >>>>>> that without configurations. >>>>>> >>>>>> Yes, sure it could be done manually to manifest all packages and their >>>>>> version(s) included into release, but it still means that >>>>>> someone has to do it one way or another. >>>>>> >>>>>> >>>>>> On 31 August 2011 23:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>> Marcus >>>>>>> >>>>>>> We only do what is possible :) >>>>>>> >>>>>>> - for the configurations of let us take what exist. We cannot control everything. I do not have the time and knowledge for that. >>>>>>> Lukas decided that configurations are evil. Ok perfect now we fix them when we know what should be loaded. >>>>>>> >>>>>>> - Then for example to integrate the broken highlight I need the code first. I still do not know which slice to load in 1.3. >>>>>>> Two days ago I spent time on it loading the wrong slice. So I decided that I will not stress. >>>>>>> >>>>>>> So we will fix that either in 1.3 or in 1.4 as time allows it. >>>>>>> And more more important: no stress we are payed enough to stress and do stuff that hurts us. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>>> On Aug 31, 2011, at 8:22 PM, Lukas Renggli wrote: >>>>>>>> >>>>>>>>> The image contains outdated versions of RB and OB that miss some >>>>>>>>> critical fixes. >>>>>>>> >>>>>>>> How can I know? >>>>>>>> >>>>>>>> It is is build using the latest MetaCello config... if the config needs to be updated, >>>>>>>> it needs to be updated. It does not happen by itself. >>>>>>>> >>>>>>>>> Also there some proposed fixes don't seem to be >>>>>>>>> included <http://code.google.com/p/pharo/issues/list?q=milestone%3D1.3> >>>>>>>>> yet? >>>>>>>>> >>>>>>>> No... I have not yet found the energy to do that. >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>>> -- >>>>>>>> Marcus Denker -- http://marcusdenker.de >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> -- >>> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- > www.tudorgirba.com > > "Value is always contextual." > > > >

Sept. 1, 2011

Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release

by GermÃ¡n Arduino

+1 2011/8/31 Dale Henrichs <dhenrich(a)vmware.com>: > There were some Metacello performance issues that popped up when using the MetacelloBrowser, so I was reluctant to publicize the MetacelloBrowser until the issues were resolved. While working on tODE, I isolated and fixed the performance issues, so the next release of Metacello (soonish) will have fixes for the performance issues and then the MetacelloBrowser will be ready to be used ... it does need some GUI polish ... > > Dale > > ----- Original Message ----- > | From: "Alexandre Bergel" <alexandre.bergel(a)me.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, August 31, 2011 2:02:55 PM > | Subject: Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release > | > | Dale and I worked on the MetacelloBrowser. I believe the UI needs to > | be polished. Probably having something based on Glamour would cool > | to have. > | I worked on Versionner because I just need a commit button. > | > | Cheers, > | Alexandre > | > | > | On 31 Aug 2011, at 17:57, Igor Stasenko wrote: > | > | > is it just me, or there are more people who know nothing about it? > | > > | > i know how to do a parallel programs, > | > but i have no means to know what happens in parallel to my little > | > universe unless i can read it from some well known source :) > | > > | > On 31 August 2011 23:46, Alexandre Bergel <alexandre.bergel(a)me.com> > | > wrote: > | > :-) > | > I use Versionner for simple case and the MetacelloBrowser for more > | > complicated stuff. > | > Check at the screenshot. You see, there is a commit button :-) It > | > saves all the dependent packages, create a new version, ask you > | > for the comment, and save the config. I rarely use the Monticello > | > browser actually. > | > > | > <Screen Shot 2011-08-31 at 17.24.53.png> > | > > | > Cheers, > | > Alexandre > | > > | > > | > On 31 Aug 2011, at 17:23, Igor Stasenko wrote: > | > > | >> On 31 August 2011 23:19, Alexandre Bergel > | >> <alexandre.bergel(a)me.com> wrote: > | >>>> For development configuration is useless and just time sink. > | >>> > | >>> I strongly disagree. Metacello was sold to please users. > | >>> Actually, I use it for me, the developper. I create a new > | >>> version at each commit. It works wonderfully. > | >>> > | >> > | >> sorry, but if during development you need to do 2 commits of 20 > | >> packages , calculate how much time it would take for you to > | >> manuallly update a configuration for each update. > | >> it is time sink. > | >> > | >> if you do that once per day, its okay.. but for every commit . no. > | >> its > | >> is absurd. > | >> > | >>> Alexandre > | >>> > | >>> > | >>>> But for release it has completely different purpose: it helps us > | >>>> to > | >>>> identify what exactly and what version of it will be put in > | >>>> final > | >>>> version. And gives a simple and concrete answer how to reproduce > | >>>> it, > | >>>> in case of need. > | >>>> Since we're are Â talking about release, i don't see how we could > | >>>> do > | >>>> that without configurations. > | >>>> > | >>>> Yes, sure it could be done manually to manifest all packages and > | >>>> their > | >>>> version(s) included into release, but it still means that > | >>>> someone has to do it one way or another. > | >>>> > | >>>> > | >>>> On 31 August 2011 23:03, StÃ©phane Ducasse > | >>>> <stephane.ducasse(a)inria.fr> wrote: > | >>>>> Marcus > | >>>>> > | >>>>> We only do what is possible :) > | >>>>> > | >>>>> Â Â Â Â - for the configurations of let us take what exist. We > | >>>>> Â Â Â Â cannot control everything. I do not have the time and > | >>>>> Â Â Â Â knowledge for that. > | >>>>> Â Â Â Â Lukas decided that configurations are evil. Ok perfect > | >>>>> Â Â Â Â now we fix them when we know what should be loaded. > | >>>>> > | >>>>> Â Â Â Â - Then for example to integrate the broken highlight I > | >>>>> Â Â Â Â need the code first. I still do not know which slice to > | >>>>> Â Â Â Â load in 1.3. > | >>>>> Â Â Â Â Two days ago I spent time on it loading the wrong slice. > | >>>>> Â Â Â Â So I decided that I will not stress. > | >>>>> > | >>>>> So we will fix that either in 1.3 or in 1.4 as time allows it. > | >>>>> And more more important: no stress we are payed enough to > | >>>>> stress and do stuff that hurts us. > | >>>>> > | >>>>> Stef > | >>>>> > | >>>>>> On Aug 31, 2011, at 8:22 PM, Lukas Renggli wrote: > | >>>>>> > | >>>>>>> The image contains outdated versions of RB and OB that miss > | >>>>>>> some > | >>>>>>> critical fixes. > | >>>>>> > | >>>>>> How can I know? > | >>>>>> > | >>>>>> It is is build using the latest MetaCello config... if the > | >>>>>> config needs to be updated, > | >>>>>> it needs to be updated. It does not happen by itself. > | >>>>>> > | >>>>>>> Also there some proposed fixes don't seem to be > | >>>>>>> included > | >>>>>>> <http://code.google.com/p/pharo/issues/list?q=milestone%3D1.3> > | >>>>>>> yet? > | >>>>>>> > | >>>>>> No... I have not yet found the energy to do that. > | >>>>>> > | >>>>>> Â Â Â Marcus > | >>>>>> > | >>>>>> -- > | >>>>>> Marcus Denker -- http://marcusdenker.de > | >>>>>> > | >>>>>> > | >>>>> > | >>>>> > | >>>>> > | >>>> > | >>>> > | >>>> > | >>>> -- > | >>>> Best regards, > | >>>> Igor Stasenko AKA sig. > | >>>> > | >>> > | >>> -- > | >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | >>> Alexandre Bergel Â http://www.bergel.eu > | >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | >>> > | >>> > | >>> > | >>> > | >>> > | >>> > | >>> > | >> > | >> > | >> > | >> -- > | >> Best regards, > | >> Igor Stasenko AKA sig. > | >> > | > > | > -- > | > > | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | > Alexandre Bergel Â http://www.bergel.eu > | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | > > | > > | > > | > > | > > | > > | > > | > > | > -- > | > Best regards, > | > Igor Stasenko AKA sig. > | > | -- > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | Alexandre Bergel Â http://www.bergel.eu > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | > | > | > | > | > | > | > > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Sept. 1, 2011

Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release

by Dale Henrichs

I have longer term plans to support merging...but no support right now... Dale ----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 31, 2011 3:26:50 PM | Subject: Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release | | Hi, | | For development involving multiple people in the same time, you | cannot rely on hardcoded package versions in configurations, because | there is no merge support, so you will never know when you are | missing a version. | | The only model that works reliably now is to depend on a baseline for | development. That means that when you develop, you integrate | relentlessly the latest package versions. | | When you release you can use the same baseline and hardcode the | package versions. | | Cheers, | Doru | | | On 31 Aug 2011, at 23:02, Alexandre Bergel wrote: | | > Dale and I worked on the MetacelloBrowser. I believe the UI needs | > to be polished. Probably having something based on Glamour would | > cool to have. | > I worked on Versionner because I just need a commit button. | > | > Cheers, | > Alexandre | > | > | > On 31 Aug 2011, at 17:57, Igor Stasenko wrote: | > | >> is it just me, or there are more people who know nothing about it? | >> | >> i know how to do a parallel programs, | >> but i have no means to know what happens in parallel to my little | >> universe unless i can read it from some well known source :) | >> | >> On 31 August 2011 23:46, Alexandre Bergel | >> <alexandre.bergel(a)me.com> wrote: | >> :-) | >> I use Versionner for simple case and the MetacelloBrowser for more | >> complicated stuff. | >> Check at the screenshot. You see, there is a commit button :-) It | >> saves all the dependent packages, create a new version, ask you | >> for the comment, and save the config. I rarely use the Monticello | >> browser actually. | >> | >> <Screen Shot 2011-08-31 at 17.24.53.png> | >> | >> Cheers, | >> Alexandre | >> | >> | >> On 31 Aug 2011, at 17:23, Igor Stasenko wrote: | >> | >>> On 31 August 2011 23:19, Alexandre Bergel | >>> <alexandre.bergel(a)me.com> wrote: | >>>>> For development configuration is useless and just time sink. | >>>> | >>>> I strongly disagree. Metacello was sold to please users. | >>>> Actually, I use it for me, the developper. I create a new | >>>> version at each commit. It works wonderfully. | >>>> | >>> | >>> sorry, but if during development you need to do 2 commits of 20 | >>> packages , calculate how much time it would take for you to | >>> manuallly update a configuration for each update. | >>> it is time sink. | >>> | >>> if you do that once per day, its okay.. but for every commit . | >>> no. its | >>> is absurd. | >>> | >>>> Alexandre | >>>> | >>>> | >>>>> But for release it has completely different purpose: it helps | >>>>> us to | >>>>> identify what exactly and what version of it will be put in | >>>>> final | >>>>> version. And gives a simple and concrete answer how to | >>>>> reproduce it, | >>>>> in case of need. | >>>>> Since we're are talking about release, i don't see how we | >>>>> could do | >>>>> that without configurations. | >>>>> | >>>>> Yes, sure it could be done manually to manifest all packages | >>>>> and their | >>>>> version(s) included into release, but it still means that | >>>>> someone has to do it one way or another. | >>>>> | >>>>> | >>>>> On 31 August 2011 23:03, StÃ©phane Ducasse | >>>>> <stephane.ducasse(a)inria.fr> wrote: | >>>>>> Marcus | >>>>>> | >>>>>> We only do what is possible :) | >>>>>> | >>>>>> - for the configurations of let us take what exist. We | >>>>>> cannot control everything. I do not have the time and | >>>>>> knowledge for that. | >>>>>> Lukas decided that configurations are evil. Ok perfect | >>>>>> now we fix them when we know what should be loaded. | >>>>>> | >>>>>> - Then for example to integrate the broken highlight I | >>>>>> need the code first. I still do not know which slice to | >>>>>> load in 1.3. | >>>>>> Two days ago I spent time on it loading the wrong slice. | >>>>>> So I decided that I will not stress. | >>>>>> | >>>>>> So we will fix that either in 1.3 or in 1.4 as time allows it. | >>>>>> And more more important: no stress we are payed enough to | >>>>>> stress and do stuff that hurts us. | >>>>>> | >>>>>> Stef | >>>>>> | >>>>>>> On Aug 31, 2011, at 8:22 PM, Lukas Renggli wrote: | >>>>>>> | >>>>>>>> The image contains outdated versions of RB and OB that miss | >>>>>>>> some | >>>>>>>> critical fixes. | >>>>>>> | >>>>>>> How can I know? | >>>>>>> | >>>>>>> It is is build using the latest MetaCello config... if the | >>>>>>> config needs to be updated, | >>>>>>> it needs to be updated. It does not happen by itself. | >>>>>>> | >>>>>>>> Also there some proposed fixes don't seem to be | >>>>>>>> included | >>>>>>>> <http://code.google.com/p/pharo/issues/list?q=milestone%3D1.3> | >>>>>>>> yet? | >>>>>>>> | >>>>>>> No... I have not yet found the energy to do that. | >>>>>>> | >>>>>>> Marcus | >>>>>>> | >>>>>>> -- | >>>>>>> Marcus Denker -- http://marcusdenker.de | >>>>>>> | >>>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>> | >>>>> | >>>>> | >>>>> -- | >>>>> Best regards, | >>>>> Igor Stasenko AKA sig. | >>>>> | >>>> | >>>> -- | >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | >>>> Alexandre Bergel http://www.bergel.eu | >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | >>>> | >>>> | >>>> | >>>> | >>>> | >>>> | >>>> | >>> | >>> | >>> | >>> -- | >>> Best regards, | >>> Igor Stasenko AKA sig. | >>> | >> | >> -- | >> | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | >> Alexandre Bergel http://www.bergel.eu | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | >> | >> | >> | >> | >> | >> | >> | >> | >> -- | >> Best regards, | >> Igor Stasenko AKA sig. | > | > -- | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > Alexandre Bergel http://www.bergel.eu | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | > | > | > | > | > | | -- | www.tudorgirba.com | | "Value is always contextual." | | | | |

Sept. 1, 2011

Re: [Pharo-project] Scriptable CompileMethod interface

by Nicolas Cellier

Well if you are browsing from a console like interface, then yes, these might be useful. Let me make some funky suggestions with pure sugar, just to let you type less in a console: If you want sub implementors, then use Bag / for telling to look under Bag hierarchy (Bag />> #at:) For reversing the direction and look super, it can be nothing else but a backslash (Bag \>> #at:) It also works with super super (Bag \\>> #at:) Requesting all the super implementors requires a wild card of course (Bag \*>> #at:) If you want both, it could have been with /\>> but it is much simpler with a single wild card (Bag *>> #at:) Just reverse the >> and... (Bag << #at:) could return the senders of #at: within Bag. If you don't like it, I have an excuse: it's late here ;) Bye Nicolas 2011/9/1 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/9/1 Camillo Bruni <camillo.bruni(a)inria.fr>: >> >> On 2011-09-01, at 00:54, Nicolas Cellier wrote: >>> 2011/9/1 Camillo Bruni <camillo.bruni(a)inria.fr>: >>>> Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦ >>>> >>>> It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦ >>>> >>>> (Object >> #at:) overrides Â Â Â "return all direct overrides of this method" >>>> (Bag >> #at:) super Â Â Â Â Â Â "return the method I override" >>>> (Bag >> #at:) superChain Â Â Â Â "return all implementations in superclasses" >>>> (Object >> #name) senders >>>> (Object >> #name) implementors >>>> >>>> instead of doing something like >>>> >>>> SystemNavigation default allCallsOn: #name Â "(BTW I would prefer allSendersOf: #name)" >>>> >>>> What do you think? Does this make sense or not? >>>> >>>> cami >>>> >>> >>> I'm not convinced. >>> (Object >> #name) senders >>> 1) works only if you know a class that implements #name >>> 2) technically it won't return the senders of (Object >> #name) but >>> the senders of (AnyOtherClass >> #name) >> >> Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. >> Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so. >> >> >>> (Object >> #name) implementors >>> 1) same as above, you must first know an implementorâ¦ >> >> Again, you start from an existing implementation (Object >> #name) just happens to be a random example.. >> >>> (Bag >> #at:) super /superChain >>> is a bit better, but there is again no garanty that Bag implements >>> at:, still I might want to see all implementors in superclasses. >> >> Nope, (Bag >> #at:) will fail if the method doesn't exist. >> >>> Nicolas >> >> >> I guess what you want meant is the same navigation interface on Symbol: >> >> #name implementors >> #foo:bar: senders >> #at: superChain: Bag Â Â Â Â Â "definitely needs another name :)" >> #at: implementorsAbove: Bag Â "might be betterâ¦" >> >> cami >> > > Yes, but this will reopen the Symbol/Selector thread ;) > > Nicolas >

Sept. 1, 2011

Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release

by Dale Henrichs

There were some Metacello performance issues that popped up when using the MetacelloBrowser, so I was reluctant to publicize the MetacelloBrowser until the issues were resolved. While working on tODE, I isolated and fixed the performance issues, so the next release of Metacello (soonish) will have fixes for the performance issues and then the MetacelloBrowser will be ready to be used ... it does need some GUI polish ... Dale ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel(a)me.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 31, 2011 2:02:55 PM | Subject: Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release | | Dale and I worked on the MetacelloBrowser. I believe the UI needs to | be polished. Probably having something based on Glamour would cool | to have. | I worked on Versionner because I just need a commit button. | | Cheers, | Alexandre | | | On 31 Aug 2011, at 17:57, Igor Stasenko wrote: | | > is it just me, or there are more people who know nothing about it? | > | > i know how to do a parallel programs, | > but i have no means to know what happens in parallel to my little | > universe unless i can read it from some well known source :) | > | > On 31 August 2011 23:46, Alexandre Bergel <alexandre.bergel(a)me.com> | > wrote: | > :-) | > I use Versionner for simple case and the MetacelloBrowser for more | > complicated stuff. | > Check at the screenshot. You see, there is a commit button :-) It | > saves all the dependent packages, create a new version, ask you | > for the comment, and save the config. I rarely use the Monticello | > browser actually. | > | > <Screen Shot 2011-08-31 at 17.24.53.png> | > | > Cheers, | > Alexandre | > | > | > On 31 Aug 2011, at 17:23, Igor Stasenko wrote: | > | >> On 31 August 2011 23:19, Alexandre Bergel | >> <alexandre.bergel(a)me.com> wrote: | >>>> For development configuration is useless and just time sink. | >>> | >>> I strongly disagree. Metacello was sold to please users. | >>> Actually, I use it for me, the developper. I create a new | >>> version at each commit. It works wonderfully. | >>> | >> | >> sorry, but if during development you need to do 2 commits of 20 | >> packages , calculate how much time it would take for you to | >> manuallly update a configuration for each update. | >> it is time sink. | >> | >> if you do that once per day, its okay.. but for every commit . no. | >> its | >> is absurd. | >> | >>> Alexandre | >>> | >>> | >>>> But for release it has completely different purpose: it helps us | >>>> to | >>>> identify what exactly and what version of it will be put in | >>>> final | >>>> version. And gives a simple and concrete answer how to reproduce | >>>> it, | >>>> in case of need. | >>>> Since we're are talking about release, i don't see how we could | >>>> do | >>>> that without configurations. | >>>> | >>>> Yes, sure it could be done manually to manifest all packages and | >>>> their | >>>> version(s) included into release, but it still means that | >>>> someone has to do it one way or another. | >>>> | >>>> | >>>> On 31 August 2011 23:03, StÃ©phane Ducasse | >>>> <stephane.ducasse(a)inria.fr> wrote: | >>>>> Marcus | >>>>> | >>>>> We only do what is possible :) | >>>>> | >>>>> - for the configurations of let us take what exist. We | >>>>> cannot control everything. I do not have the time and | >>>>> knowledge for that. | >>>>> Lukas decided that configurations are evil. Ok perfect | >>>>> now we fix them when we know what should be loaded. | >>>>> | >>>>> - Then for example to integrate the broken highlight I | >>>>> need the code first. I still do not know which slice to | >>>>> load in 1.3. | >>>>> Two days ago I spent time on it loading the wrong slice. | >>>>> So I decided that I will not stress. | >>>>> | >>>>> So we will fix that either in 1.3 or in 1.4 as time allows it. | >>>>> And more more important: no stress we are payed enough to | >>>>> stress and do stuff that hurts us. | >>>>> | >>>>> Stef | >>>>> | >>>>>> On Aug 31, 2011, at 8:22 PM, Lukas Renggli wrote: | >>>>>> | >>>>>>> The image contains outdated versions of RB and OB that miss | >>>>>>> some | >>>>>>> critical fixes. | >>>>>> | >>>>>> How can I know? | >>>>>> | >>>>>> It is is build using the latest MetaCello config... if the | >>>>>> config needs to be updated, | >>>>>> it needs to be updated. It does not happen by itself. | >>>>>> | >>>>>>> Also there some proposed fixes don't seem to be | >>>>>>> included | >>>>>>> <http://code.google.com/p/pharo/issues/list?q=milestone%3D1.3> | >>>>>>> yet? | >>>>>>> | >>>>>> No... I have not yet found the energy to do that. | >>>>>> | >>>>>> Marcus | >>>>>> | >>>>>> -- | >>>>>> Marcus Denker -- http://marcusdenker.de | >>>>>> | >>>>>> | >>>>> | >>>>> | >>>>> | >>>> | >>>> | >>>> | >>>> -- | >>>> Best regards, | >>>> Igor Stasenko AKA sig. | >>>> | >>> | >>> -- | >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | >>> Alexandre Bergel http://www.bergel.eu | >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | >>> | >>> | >>> | >>> | >>> | >>> | >>> | >> | >> | >> | >> -- | >> Best regards, | >> Igor Stasenko AKA sig. | >> | > | > -- | > | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > Alexandre Bergel http://www.bergel.eu | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | > | > | > | > | > | > | > | > -- | > Best regards, | > Igor Stasenko AKA sig. | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | |

Aug. 31, 2011

Re: [Pharo-project] [Pharo-users] PLEASE HELP testing Pharo 1.3 One Click [WAS] Pharo 1.3 release

by GermÃ¡n Arduino

2011/8/31 Igor Stasenko <siguctua(a)gmail.com> > is it just me, or there are more people who know nothing about it? > > I never hear about it neither :S Look as a very useful tool ......

Aug. 31, 2011

Re: [Pharo-project] Scriptable CompileMethod interface

by Nicolas Cellier

2011/9/1 Camillo Bruni <camillo.bruni(a)inria.fr>: > > On 2011-09-01, at 00:54, Nicolas Cellier wrote: >> 2011/9/1 Camillo Bruni <camillo.bruni(a)inria.fr>: >>> Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦ >>> >>> It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦ >>> >>> (Object >> #at:) overrides Â Â Â "return all direct overrides of this method" >>> (Bag >> #at:) super Â Â Â Â Â Â "return the method I override" >>> (Bag >> #at:) superChain Â Â Â Â "return all implementations in superclasses" >>> (Object >> #name) senders >>> (Object >> #name) implementors >>> >>> instead of doing something like >>> >>> SystemNavigation default allCallsOn: #name Â "(BTW I would prefer allSendersOf: #name)" >>> >>> What do you think? Does this make sense or not? >>> >>> cami >>> >> >> I'm not convinced. >> (Object >> #name) senders >> 1) works only if you know a class that implements #name >> 2) technically it won't return the senders of (Object >> #name) but >> the senders of (AnyOtherClass >> #name) > > Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. > Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so. > > >> (Object >> #name) implementors >> 1) same as above, you must first know an implementorâ¦ > > Again, you start from an existing implementation (Object >> #name) just happens to be a random example.. > >> (Bag >> #at:) super /superChain >> is a bit better, but there is again no garanty that Bag implements >> at:, still I might want to see all implementors in superclasses. > > Nope, (Bag >> #at:) will fail if the method doesn't exist. > >> Nicolas > > > I guess what you want meant is the same navigation interface on Symbol: > > #name implementors > #foo:bar: senders > #at: superChain: Bag Â Â Â Â Â "definitely needs another name :)" > #at: implementorsAbove: Bag Â "might be betterâ¦" > > cami > Yes, but this will reopen the Symbol/Selector thread ;) Nicolas

Aug. 31, 2011

Re: [Pharo-project] Scriptable CompileMethod interface

by Camillo Bruni

On 2011-09-01, at 00:54, Nicolas Cellier wrote: > 2011/9/1 Camillo Bruni <camillo.bruni(a)inria.fr>: >> Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦ >> >> It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦ >> >> (Object >> #at:) overrides "return all direct overrides of this method" >> (Bag >> #at:) super "return the method I override" >> (Bag >> #at:) superChain "return all implementations in superclasses" >> (Object >> #name) senders >> (Object >> #name) implementors >> >> instead of doing something like >> >> SystemNavigation default allCallsOn: #name "(BTW I would prefer allSendersOf: #name)" >> >> What do you think? Does this make sense or not? >> >> cami >> > > I'm not convinced. > (Object >> #name) senders > 1) works only if you know a class that implements #name > 2) technically it won't return the senders of (Object >> #name) but > the senders of (AnyOtherClass >> #name) Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so. > (Object >> #name) implementors > 1) same as above, you must first know an implementorâ¦ Again, you start from an existing implementation (Object >> #name) just happens to be a random example.. > (Bag >> #at:) super /superChain > is a bit better, but there is again no garanty that Bag implements > at:, still I might want to see all implementors in superclasses. Nope, (Bag >> #at:) will fail if the method doesn't exist. > Nicolas I guess what you want meant is the same navigation interface on Symbol: #name implementors #foo:bar: senders #at: superChain: Bag "definitely needs another name :)" #at: implementorsAbove: Bag "might be betterâ¦" cami

Aug. 31, 2011