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

[Pharo-project] Issue 3357 in pharo: Enable silent / verbose updates again...

by pharo＠googlecode.com

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3357 by marcus.denker: Enable silent / verbose updates again... http://code.google.com/p/pharo/issues/detail?id=3357 ... for hudson. -> updates are loaded verbose by default -> beSilent can be used (e.g. by hudson) Attachments: UpdateStreamer.1.cs 1.9 KB

Nov. 29, 2010

Re: [Pharo-project] Block semantics ....

by James Ladd

Hi Eliot, I was suspecting you might respond, you really know your stuff. I think I'm more confused now that before but in a good way. I have more information thank to you. My need to fully understand blocks is to implement them in Redline. Maybe it will be sufficient to 'limit' the use of a block with a return to the method in which is was defined? ie: Method A can define the block and send it as an argument, but once method A has been exited, the block is no longer valid, at least not the return part. Does this appear most 'like' how blocks are handled in Pharo? Rgs, James.

Nov. 29, 2010

[Pharo-project] NewInspector does not work well with delegated collections

by jaayer

Enclosed is a fileout of a sample collection named DelegatedSet that works by delegating to an instance of Set stored in an instance variable. It implements the basic protocol Collection requires, including #add:, #remove:ifAbsent: and #do: as well as some additional messages, all through delegation. Create an instance of it and then inspect that instance with NewInsepctor, and you will notice the "Elements" item does not work. Nothing happens when you click it. To inspect the elements, you need to click "set," the instance variable containing the Set, and then inspect that object further. Apparently, unless you override one or more messages under the extension category *Newinspector, NewInspector will not know how to inspect your collection properly. Worse, as soon as you do implement those methods, unless you change their category, they will now be considered part of the *Newinspector package rather than the package your collection belongs to and will not be saved along with the collection. I think at a minimum, any collection understanding #do: and #size should be inspectable by NewInspector.

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: Status: Closed Comment #9 on issue 3352 by stephane.ducasse: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage http://code.google.com/p/pharo/issues/detail?id=3352 no stress :) we can simply close it!

Nov. 29, 2010

Re: [Pharo-project] How to update Pharo

by StÃ©phane Ducasse

tony you should take the latest unstable image (1.2) you can find it at http://pharo-project.org/pharo-download or https://gforge.inria.fr/frs/?group_id=1299 stef On Nov 29, 2010, at 8:21 PM, Tony Fleig wrote: > In the document at: http://code.google.com/p/pharo/wiki/HowToContribute, I find > > â¢ Download the latest Pharo image from http://code.google.com/p/pharo/wiki/Downloads?tm=2. > â¢ Launch the fresh image and load the latest updates by using the option in the menu. > > The Pharo-1.1 One-Click image has no "update" option in the menu. Should I be using a different image? > > How would I go about updating the One-Click image "manually"? > > Regards, > TF >

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

Comment #8 on issue 3352 by tony.fleig: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage http://code.google.com/p/pharo/issues/detail?id=3352 After reading the HowToContribute document, I think maybe I should just start over with submitting this. I have signed the agreement and will fax it tomorrow. Then I will follow the HowToContribute instructions and submit the Pharo changes via PharoInBox and deal with the Seaside changes separately. Is there a way to retract this issue at this point so I can do it properly?

Nov. 29, 2010

[Pharo-project] How to update Pharo

by Tony Fleig

In the document at: http://code.google.com/p/pharo/wiki/HowToContribute, I find - Download the latest Pharo image from http://code.google.com/p/pharo/wiki/Downloads?tm=2. - Launch the fresh image and load the latest updates by using the option in the menu. The Pharo-1.1 One-Click image has no "update" option in the menu. Should I be using a different image? How would I go about updating the One-Click image "manually"? Regards, TF

Nov. 29, 2010

Re: [Pharo-project] TextConverter handling of binary streams

by StÃ©phane Ducasse

sven I'm terribly and more than that busy until mid or more dec. Now did you check if the behavior is the same in squeak? S. On Nov 29, 2010, at 3:23 PM, Sven Van Caekenberghe wrote: > Hi, > > TextConverter and its subclasses seem to break the contract of #nextFromStream: and #nextPut:toStream: when the stream #isBinary. Consider the following two examples: > > ByteArray streamContents: [ :stream | | encoder | > encoder := UTF8TextConverter new. > 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]. > > #[233 108 232 118 101 32 101 110 32 102 114 97 110 231 97 105 115] > > (String streamContents: [ :stream | | encoder | > encoder := UTF8TextConverter new. > 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]) asByteArray. > > #[195 169 108 195 168 118 101 32 101 110 32 102 114 97 110 195 167 97 105 115] > > The first answer is incorrect, the second is correct (as far as I understand it). > > This is apparently on purpose, from the implementation of, for example, UTF8TextConverter>>#nextPut:toStream: > > nextPut: aCharacter toStream: aStream > | leadingChar nBytes mask shift ucs2code | > aStream isBinary ifTrue: [^aCharacter storeBinaryOn: aStream]. > leadingChar := aCharacter leadingChar. > (leadingChar = 0 and: [aCharacter asciiValue < 128]) ifTrue: [ > aStream basicNextPut: aCharacter. > ^ aStream. > ]. > > "leadingChar > 3 ifTrue: [^ aStream]." > > ucs2code := aCharacter asUnicode. > ucs2code ifNil: [^ aStream]. > > nBytes := ucs2code highBit + 3 // 5. > mask := #(128 192 224 240 248 252 254 255) at: nBytes. > shift := nBytes - 1 * -6. > aStream basicNextPut: (Character value: (ucs2code bitShift: shift) + mask). > 2 to: nBytes do: [:i | > shift := shift + 6. > aStream basicNextPut: (Character value: ((ucs2code bitShift: shift) bitAnd: 63) + 128). > ]. > > ^ aStream. > > I would say that the contract of #nextPut:toStream: is to take a Character object and write a binary representation using a specific encoding to a stream. However, when given a #isBinary stream, it does no longer do any encoding at all ! > > The same is true for the other converters as well as for #nextFromStream:. > > Does anyone know why that is the case ? > > And if it is by design, how should one do UTF8 encoding on a binary stream ?? > > Thx, > > Sven > > PS: If others also think this is strange, I could make an issue, I am just not sure this is a bug. > > >

Nov. 29, 2010

Re: [Pharo-project] SimpleTraits - How can we have Traits/Mixins quickly?

by Johan Brichau

On 29 Nov 2010, at 16:38, Peter van Rooijen wrote: > Now it seems that Traits have somehow not "made it" into > Pharo and I believe with you that it is a shame not to have it. there's no need to despair: traits *are* in Pharo ;-)

Nov. 29, 2010

[Pharo-project] [OT] Smalltalk commitment

by Torsten Bergmann

Interesting read, especially on commitment that Smalltalk requires: http://blog.lostlake.org/index.php?/archives/14-Smalltalk-Language-of-the-g… -- GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Nov. 29, 2010