October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] When using Autotest + TilingWindowManager, the sarch dialog is unaccesible

by Mariano Martinez Peck

On Thu, Oct 27, 2011 at 7:07 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > ** > I'm sure I had some fixes for this... must find! > > please please :) > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Thursday, October 27, 2011 5:51 PM > *Subject:* Re: [Pharo-project] When using Autotest + TilingWindowManager, > the sarch dialog is unaccesible > > On Thu, Oct 27, 2011 at 2:26 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi (alain?). When using Autotest + TilingWindowManager , if I then I am >> in the system browser and press cmd + f, the search dialog is too much in >> the top left of the screen. I cannot type in there, and I cannot move it. >> Look the attached screenshot. >> So... any ideas how we can fix that? what about just giving focus (bring >> to front) to the search windows just after opening it ? >> >> > Hi, > > I'm not aware of the consequences, but if you remove: > EditorFindReplaceDialogWindow>>open > > (thus using SystemWindow>>open instead) > > the dialog is placed the same way as SystemWindows and does not open behind > docked bars. > > Laurent > > > > > >> thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 27, 2011

Re: [Pharo-project] When using Autotest + TilingWindowManager, the sarch dialog is unaccesible

by Mariano Martinez Peck

On Thu, Oct 27, 2011 at 6:51 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Thu, Oct 27, 2011 at 2:26 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi (alain?). When using Autotest + TilingWindowManager , if I then I am >> in the system browser and press cmd + f, the search dialog is too much in >> the top left of the screen. I cannot type in there, and I cannot move it. >> Look the attached screenshot. >> So... any ideas how we can fix that? what about just giving focus (bring >> to front) to the search windows just after opening it ? >> >> > Hi, > > I'm not aware of the consequences, but if you remove: > EditorFindReplaceDialogWindow>>open > > (thus using SystemWindow>>open instead) > > the dialog is placed the same way as SystemWindows and does not open behind > docked bars. > > Good. Thanks Laurent, at least I have a workarround :) > Laurent > > > > > >> thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 27, 2011

Re: [Pharo-project] When using Autotest + TilingWindowManager, the sarch dialog is unaccesible

by Gary Chambers

I'm sure I had some fixes for this... must find! Regards, Gary ----- Original Message ----- From: laurent laffont To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, October 27, 2011 5:51 PM Subject: Re: [Pharo-project] When using Autotest + TilingWindowManager, the sarch dialog is unaccesible On Thu, Oct 27, 2011 at 2:26 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: Hi (alain?). When using Autotest + TilingWindowManager , if I then I am in the system browser and press cmd + f, the search dialog is too much in the top left of the screen. I cannot type in there, and I cannot move it. Look the attached screenshot. So... any ideas how we can fix that? what about just giving focus (bring to front) to the search windows just after opening it ? Hi, I'm not aware of the consequences, but if you remove: EditorFindReplaceDialogWindow>>open (thus using SystemWindow>>open instead) the dialog is placed the same way as SystemWindows and does not open behind docked bars. Laurent thanks in advance, -- Mariano http://marianopeck.wordpress.com

Oct. 27, 2011

Re: [Pharo-project] When using Autotest + TilingWindowManager, the sarch dialog is unaccesible

by laurent laffont

On Thu, Oct 27, 2011 at 2:26 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi (alain?). When using Autotest + TilingWindowManager , if I then I am in > the system browser and press cmd + f, the search dialog is too much in the > top left of the screen. I cannot type in there, and I cannot move it. > Look the attached screenshot. > So... any ideas how we can fix that? what about just giving focus (bring > to front) to the search windows just after opening it ? > > Hi, I'm not aware of the consequences, but if you remove: EditorFindReplaceDialogWindow>>open (thus using SystemWindow>>open instead) the dialog is placed the same way as SystemWindows and does not open behind docked bars. Laurent > thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 27, 2011

[Pharo-project] Issue 4696: Rename Smalltalk>>garbageCollectAndReport and Smalltalk>>bytesLeftString

by Bernardo Ezequiel Contreras

Hi all, i would like to fixed this issue 4696<http://code.google.com/p/pharo/issues/detail?id=4696>. could we agree on the new names? read the issue and please add your propose. thanks.

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Andrea BrÃ¼hlmann

I don't remember me wanting a collect: to return a set any time of my life, so I would agree. Clara Allende schrieb: > I would spect it to return aBag, for example. > > On 27 October 2011 12:13, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> wrote: > >> Hi Clara, >> >> You don't need to worry about the receivers class, but about the result you >> wish to have... There are 2 possibilities what the result will be: either >> the same kind as the original collection or something else! If you mind >> about the result, you need to tell the system what the result should look >> like :-) > > > But I just want to use it! > >> In your case, it is important that the result is no Set, so this is why you >> need to tell the system to collect the grades as an OrderedCollection or >> whatever. It doesn't matter if the students are a Set or not then! > > > Indeed. IN THIS CASE it's important that the result is not a Set. But why? > Because the receiver is a Set!!! I do not send a asBag message to every > collect: result I get, so why should I do that here? What you're saying is > that I need to be aware that the receiver is a Set, which sucks. Otherwise, > I should send asBag every time I use collect:, just in case the receiver is > a Set... That doesn't sound good. > > >> self students collect: #grade as: OrderedCollection >> >> Do you have another solution in mind? Maybe you expect Set>collect: to >> return anOrderedCollection by Default? This would make sense for your >> students grades and for many more cases, but then, the implementation would >> break the rule "Collections always return results on an new instance of its >> own #species". >> > > And why couldn't we break the rule in this case? Again, this works for the > others collections and the other messages, and I'm ok with it. But not with > collect: :S > >> Andrea >> >> >> >> >> >> Clara Allende schrieb: >> >> Ok, but this means I have to worry of the receiver's class before I send >>> collect:, so as I don't fuck it all up.... and I don't want to think about >>> that!!! See, if I want the collection of grades of the students, I would >>> like to do this: >>> >>> grades >>> ^self students collect: [.aStudent | aStudent grades] >>> >>> regardless of whatever is the class of students... This does the trick >>> for >>> all the collections, except for Set. And I donÂ´t know if students is an >>> instance of Set, and I really don't want to think if it is or not. If I >>> don't want repeated students and I create my collection as an instance of >>> Set, an i.e.; I want to calculate the average, then I'm screwed because >>> the >>> collection I get from the collect: wasn't the want that I wanted. >>> So, I have to know previously that my collection is an instance of Set, or >>> if it isn't, so as to know if I have to convert it first.... >>> >>> And if I use collect: as:, as you suggest, this means the collections are >>> no >>> longer polymorphic for me :( >>> Sorry, maybe I'm really stupid, but I don't know how that message solves >>> best the problem than redefining collect: for Set. For the particular case >>> I >>> don't want the repeated objects (which AFAIK is not so common) I could >>> send >>> asSet. >>> >>> On 27 October 2011 11:05, Henrik Sperre Johansen < >>> henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 27.10.2011 15:40, Clara Allende wrote: >>>> I know, but our students don't :) So they ran into problems because the >>>>> message send didn't answer what they were specting.... because it makes >>>>> sense that if I want to transform the objects in my collection, I might >>>>> get >>>>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm >>>>> just >>>>> putting myself on student's shoes :P >>>>> >>>>> The consistency rule to remember for #collect:/#select:/#reject: is >>>> that >>>> they will return a collection of the receiver's species. >>>> #collect:as: was added as a general answer to the situation your students >>>> ran into :) >>>> >>>> set := Set withAll: #(1 2 3 4 5 6 7 8). >>>> result := set collect: #even as: Bag. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>>

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Clara Allende

I would spect it to return aBag, for example. On 27 October 2011 12:13, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> wrote: > Hi Clara, > > You don't need to worry about the receivers class, but about the result you > wish to have... There are 2 possibilities what the result will be: either > the same kind as the original collection or something else! If you mind > about the result, you need to tell the system what the result should look > like :-) But I just want to use it! > In your case, it is important that the result is no Set, so this is why you > need to tell the system to collect the grades as an OrderedCollection or > whatever. It doesn't matter if the students are a Set or not then! Indeed. IN THIS CASE it's important that the result is not a Set. But why? Because the receiver is a Set!!! I do not send a asBag message to every collect: result I get, so why should I do that here? What you're saying is that I need to be aware that the receiver is a Set, which sucks. Otherwise, I should send asBag every time I use collect:, just in case the receiver is a Set... That doesn't sound good. > self students collect: #grade as: OrderedCollection > > Do you have another solution in mind? Maybe you expect Set>collect: to > return anOrderedCollection by Default? This would make sense for your > students grades and for many more cases, but then, the implementation would > break the rule "Collections always return results on an new instance of its > own #species". > And why couldn't we break the rule in this case? Again, this works for the others collections and the other messages, and I'm ok with it. But not with collect: :S > > Andrea > > > > > > Clara Allende schrieb: > > Ok, but this means I have to worry of the receiver's class before I send >> collect:, so as I don't fuck it all up.... and I don't want to think about >> that!!! See, if I want the collection of grades of the students, I would >> like to do this: >> >> grades >> ^self students collect: [.aStudent | aStudent grades] >> >> regardless of whatever is the class of students... This does the trick >> for >> all the collections, except for Set. And I donÂ´t know if students is an >> instance of Set, and I really don't want to think if it is or not. If I >> don't want repeated students and I create my collection as an instance of >> Set, an i.e.; I want to calculate the average, then I'm screwed because >> the >> collection I get from the collect: wasn't the want that I wanted. >> So, I have to know previously that my collection is an instance of Set, or >> if it isn't, so as to know if I have to convert it first.... >> >> And if I use collect: as:, as you suggest, this means the collections are >> no >> longer polymorphic for me :( >> Sorry, maybe I'm really stupid, but I don't know how that message solves >> best the problem than redefining collect: for Set. For the particular case >> I >> don't want the repeated objects (which AFAIK is not so common) I could >> send >> asSet. >> >> On 27 October 2011 11:05, Henrik Sperre Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> >> On 27.10.2011 15:40, Clara Allende wrote: >>> >>> I know, but our students don't :) So they ran into problems because the >>>> message send didn't answer what they were specting.... because it makes >>>> sense that if I want to transform the objects in my collection, I might >>>> get >>>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm >>>> just >>>> putting myself on student's shoes :P >>>> >>>> The consistency rule to remember for #collect:/#select:/#reject: is >>> that >>> they will return a collection of the receiver's species. >>> #collect:as: was added as a general answer to the situation your students >>> ran into :) >>> >>> set := Set withAll: #(1 2 3 4 5 6 7 8). >>> result := set collect: #even as: Bag. >>> >>> Cheers, >>> Henry >>> >>> >>> >>> >>> >> >> > -- > AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER > | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN > | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH > > -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds

Oct. 27, 2011

Re: [Pharo-project] 1.3Core build moved to Jenkins

by Marcus Denker

On Oct 27, 2011, at 3:54 PM, Marcus Denker wrote: > Hi, > > With https://pharo-ic.lille.inria.fr being decommissioned, we are moving everything to Jenkins: > > https://ci.lille.inria.fr/pharo/ > > > > TODO: > > -> Full (building now) This now builds successfully: https://ci.lille.inria.fr/pharo/view/Pharo%201.3/job/Pharo%201.3/ Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Mariano Martinez Peck

On Thu, Oct 27, 2011 at 3:26 PM, Diaz Trepat, Ramiro < ramiro.diaz.trepat(a)jpmorgan.com> wrote: > Collections always return results on an new instance of its own #species. > **** > > That is fabulous to me. It is what's desired most times. > But also for #collect: ? I think I see the point of Carla. Do you see a relation between the receiver collection class and the collection class of what you want to collect? I don't see a relation at all. So why would returning the same would help here? Again, I am ONLY talking about #collect. Wouldn't be better to always answer, say, ORderedCollection (I guess it is quite common and usuful) and then only is desired something different use #asSomething or even collect:as: ? Cheers > **** > > With that in mind, if you expected a bag or something else, you should > convert (asXXX) before the collect.**** > > Cheers**** > > ** ** > > r.**** > > ** ** > > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Clara Allende > *Sent:* 27 October 2011 14:15 > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* [Pharo-project] aSet collect: answers aSet??**** > > ** ** > > > Hi guys.. > This morning some students came with an exercise like this: > (Set with: 1 with: 2 with:3 with:4 with:5) collect:[:e | e even]. a > Set(false true) > > But they don't want to get aSet, (regardless this particular example > doesn't make sense)... the question is, why if I send collect: to aSet I get > aSet and not aBag? What happens if I *want* repeated elements after the > transformation? :( And when did this behavior change? > -- **** > > "*Most good programmers do programming not because they expect to get paid > or get adulation by the public, but because it is fun to program.*" **** > > Linus Torvalds**** > > ** ** > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of securities, > accuracy and completeness of information, viruses, confidentiality, legal > privilege, and legal entity disclaimers, available at > http://www.jpmorgan.com/pages/disclosures/email. > -- Mariano http://marianopeck.wordpress.com

Oct. 27, 2011

Re: [Pharo-project] aSet collect: answers aSet??

by Andrea BrÃ¼hlmann

Hi Clara, You don't need to worry about the receivers class, but about the result you wish to have... There are 2 possibilities what the result will be: either the same kind as the original collection or something else! If you mind about the result, you need to tell the system what the result should look like :-) In your case, it is important that the result is no Set, so this is why you need to tell the system to collect the grades as an OrderedCollection or whatever. It doesn't matter if the students are a Set or not then! self students collect: #grade as: OrderedCollection Do you have another solution in mind? Maybe you expect Set>collect: to return anOrderedCollection by Default? This would make sense for your students grades and for many more cases, but then, the implementation would break the rule "Collections always return results on an new instance of its own #species". Andrea Clara Allende schrieb: > Ok, but this means I have to worry of the receiver's class before I send > collect:, so as I don't fuck it all up.... and I don't want to think about > that!!! See, if I want the collection of grades of the students, I would > like to do this: > > grades > ^self students collect: [.aStudent | aStudent grades] > > regardless of whatever is the class of students... This does the trick for > all the collections, except for Set. And I donÂ´t know if students is an > instance of Set, and I really don't want to think if it is or not. If I > don't want repeated students and I create my collection as an instance of > Set, an i.e.; I want to calculate the average, then I'm screwed because the > collection I get from the collect: wasn't the want that I wanted. > So, I have to know previously that my collection is an instance of Set, or > if it isn't, so as to know if I have to convert it first.... > > And if I use collect: as:, as you suggest, this means the collections are no > longer polymorphic for me :( > Sorry, maybe I'm really stupid, but I don't know how that message solves > best the problem than redefining collect: for Set. For the particular case I > don't want the repeated objects (which AFAIK is not so common) I could send > asSet. > > On 27 October 2011 11:05, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> On 27.10.2011 15:40, Clara Allende wrote: >> >>> I know, but our students don't :) So they ran into problems because the >>> message send didn't answer what they were specting.... because it makes >>> sense that if I want to transform the objects in my collection, I might get >>> repeated objects... Maybe I'm not thinking in terms of consistency, I'm just >>> putting myself on student's shoes :P >>> >> The consistency rule to remember for #collect:/#select:/#reject: is that >> they will return a collection of the receiver's species. >> #collect:as: was added as a general answer to the situation your students >> ran into :) >> >> set := Set withAll: #(1 2 3 4 5 6 7 8). >> result := set collect: #even as: Bag. >> >> Cheers, >> Henry >> >> >> >> > > -- AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH

Oct. 27, 2011