November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MorphTreeMorph

by Alain Plantec

Le 29/11/2010 11:24, Benjamin a Ã©crit : > Hi guys, > > I had a little problem about MorphTreeMorph>>#setSelectedNodeItemList: > > setSelectedNodeItemList: aNodeItemCollection > | keptSelectedMorphList | > self selectedMorphList removeAll. > "Don't work directly with selectedMorphList because for very long > list, #drawOn: is time consuming" > keptSelectedMorphList := selectedMorphList. > selectedMorphList := #(). > keptSelectedMorphList addAll: (self nodeMorphsWithAllNodeItems: > aNodeItemCollection). > ------- > I break here > ------- > selectedMorphList := keptSelectedMorphList. > lastClickedMorph ifNil: [lastClickedMorph := selectedMorphList > ifEmpty: [nil] ifNotEmpty: [selectedMorphList last]]. > self selectionChanged. > > > Due to the break, selectedMorphList is an empty array, and when I try > to resend the message, removeAll from the start is not understood ... > > Is there a reason why selectedMorphList is set as an empty array ? I don't think so. This assignment should be removed. Cheers Alain > Cheers, > > Ben > >

Nov. 29, 2010

Re: [Pharo-project] Issue 3353 in pharo: CommentReference

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3353 by Benjamin.VanRyseghem.Pharo: CommentReference http://code.google.com/p/pharo/issues/detail?id=3353 (No comment was entered for this change.) Attachments: CommentReference.BenjaminVanRyseghem.1.cs 451 bytes

Nov. 29, 2010

[Pharo-project] Issue 3353 in pharo: CommentReference

by pharo＠googlecode.com

Status: Accepted Owner: Benjamin.VanRyseghem.Pharo New issue 3353 by Benjamin.VanRyseghem.Pharo: CommentReference http://code.google.com/p/pharo/issues/detail?id=3353 Maybe CommentReference should have a method #selector to be polymorphic.

Nov. 29, 2010

[Pharo-project] MorphTreeMorph

by Benjamin

Hi guys, I had a little problem about MorphTreeMorph>>#setSelectedNodeItemList: setSelectedNodeItemList: aNodeItemCollection | keptSelectedMorphList | self selectedMorphList removeAll. "Don't work directly with selectedMorphList because for very long list, #drawOn: is time consuming" keptSelectedMorphList := selectedMorphList. selectedMorphList := #(). keptSelectedMorphList addAll: (self nodeMorphsWithAllNodeItems: aNodeItemCollection). ------- I break here ------- selectedMorphList := keptSelectedMorphList. lastClickedMorph ifNil: [lastClickedMorph := selectedMorphList ifEmpty: [nil] ifNotEmpty: [selectedMorphList last]]. self selectionChanged. Due to the break, selectedMorphList is an empty array, and when I try to resend the message, removeAll from the start is not understood ... Is there a reason why selectedMorphList is set as an empty array ? Cheers, Ben

Nov. 29, 2010

Re: [Pharo-project] Issue 3291 in pharo: Missing text field with completion

by pharo＠googlecode.com

Updates: Labels: Milestone-1.2 Comment #3 on issue 3291 by aplantec: Missing text field with completion http://code.google.com/p/pharo/issues/detail?id=3291 yes. In PharoTaskForces: last version of SLICE-Issue-3291-Missing-text-field-with-completion. Reasonably tested and documented. The FindReplaceDialogWindow is using it to popup previously entered tokens in the find and in the replace fields. This greatly improve its useability.

Nov. 29, 2010

Re: [Pharo-project] Issue 3254 in pharo: [Repackage] "Regular expressions" should be well structured

by pharo＠googlecode.com

Comment #12 on issue 3254 by Torsten....(a)astares.de: [Repackage] "Regular expressions" should be well structured http://code.google.com/p/pharo/issues/detail?id=3254 I would call this extortion ... (I was able to connect to the server and now have to find the time to start first steps with integration)

Nov. 29, 2010

[Pharo-project] CompiledMethod copy

by Gabriel HernÃ¡n Barbuto

Hi I've been trying to duplicate a CompiledMethod and finally I've been able to do it. I've thought about integrating the copy code back into the image. But the comment in CompiledMethod's veryDeepCopyWith: made me thought if the change would be correct. veryDeepCopyWith: deepCopier "Return self. I am always shared. Do not record me. Only use this for blocks. Normally methodDictionaries should not be copied this way." On the other hand. CompiledMethod uses Object's copy which makes a shallow copy of the receiver followed by a postCopy. CompiledMethod doesn't define any of these methods. So I am not sure if they are always shared or not as the comment says. I wonder if it's correct to put this way of copying a CompiledMethod in copy. What do you think about it? Bests Gabriel

Nov. 29, 2010

Re: [Pharo-project] Issue 3352 in pharo: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage

by pharo＠googlecode.com

Updates: Labels: Type-RequestForEnhancement Comment #7 on issue 3352 by adrian.lienhard: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage http://code.google.com/p/pharo/issues/detail?id=3352 Hi Tony, Thanks for the contribution. Improvements like this are very much appreciated. We have a (somewhat complicated) description of the contribution process at http://code.google.com/p/pharo/wiki/HowToContribute. The most important thing is if you could sign the agreement (linked from the above mentioned page). Changesets are OK, but you could also submit your code with Monticello. Adrian

Nov. 29, 2010

Re: [Pharo-project] Issue 3270 in pharo: fix xor: to work with blocks and booleans

by Peter Hugosson-Miller

+1 -- Cheers, Peter On Mon, Nov 29, 2010 at 10:49 AM, Peter van Rooijen <peter(a)vanrooijen.com>wrote: > Hi, > > I don't get why it should work with blocks, since evaluation > of the exclusive OR operation cannot be short-circuited. > Therefore there is no reason to ever use a block as an argument. > > #and: and #or: take a block as an argument precisely because > for 50% of the receivers (i.e., false and true, respectively) > it is known in advance that the value of the expression in the > argument block is irrelevant, so it would be at least wasteful > to evaluate it. > > But this reasoning does not apply to #xor:. > > I think it is simply a user mistake when a block is provided > as argument, where a boolean is required. > > It's an understandable mistake (that I've made myself ;) since xor: > has such similarities to or: that you automatically want to start > a block unless you're really thinking about what you're doing. > > So, I don't see the bug. Thus, I don't see the fix. I do see > obscure code (aBoolean value)and wasted time because of the > extra message send. > > Apologies if this is a late response, I unly just saw the issue mentioned. > > Cheers, Peter > > > > On Thu, 18 Nov 2010 18:55:41 +0100, <pharo(a)googlecode.com> wrote: > > Status: Fixed >> Owner: marcus.denker >> Labels: Milestone-1.2 >> >> New issue 3270 by marcus.denker: fix xor: to work with blocks and booleans >> http://code.google.com/p/pharo/issues/detail?id=3270 >> >> ... so that it works like or: (calling #value on the argument. This means >> it will continue to work with booleans, too). >> >> >> >> Attachments: >> XOr.1.cs 903 bytes >> >>

Nov. 29, 2010

Re: [Pharo-project] XOR: don't recieve a block

by Peter van Rooijen

Levente is of course right, apologies for not reading up more before making the same point belatedly (and with many more words). So I'll keep on reading now and keep quiet :-). Cheers, peter On Thu, 18 Nov 2010 18:57:58 +0100, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 18 Nov 2010, Marcus Denker wrote: > >> >> On Nov 18, 2010, at 6:34 PM, StÃ©phane Ducasse wrote: >> >>> & | don't >>> Do not cnfuse lazy and the others. >> >> >> true xor: [false] >> >> --> walkback. >> >> false xor: [false] >> >> --> [false] >> >> There is a call to #value missing (which will keep it working with >> booleans, too, as they understand >> #value, too (returning self)). > > That's a possible solution, but xor can't be lazy, so the block is just > pointless. > > > Levente > >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> -- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048

Nov. 29, 2010