- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Hudson build server for Pharo
by Marcus Denker Nov. 30, 2010

Nov. 30, 2010

Hi, So we finally have a Hudson: http://pharo-ic.lille.inria.fr/ - one Linux Builder Slave machine - Builds and runs tests of Core 1.1 - loads updates and runs tests Core 1.2 For now, it builds once per day. Starting tomorrow, 1.2 will be build automatically after an update. More to come... (e.g. builds of the full release, One-Click... Mac Slave...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

5 4

Re: [Pharo-project] ConfigurationOfMocketry + Help
by laurent laffont Nov. 30, 2010

Nov. 30, 2010

Hi Denis, I've commited Mocketry-Help and ConfigurationOfMocketry is in MetacelloRepository. I removed SMock-SUnit from the Configuration but SMock is still here for Mocketry-Tests (it may be good enough for a first release). I have 3 tests failing from SMock: SMProxyTest>>#testDefaultInspectString SMProxyTest>>#testDefaultDebugString SMProxyTest>>#testDefaultPrintString Cheers, Laurent. On Tue, Nov 30, 2010 at 9:15 AM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > > > 2010/11/30 laurent laffont <laurent.laffont(a)gmail.com> > > >> On Mon, Nov 29, 2010 at 10:20 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: >> >>> Hello, I am very glad to your work. >>> >>> I try configuration in pharo1.1. Loaded without problem. And Mocketry >>> tests green. >>> >>> Why you add SMock to Core group? >>> >> >> Because I'm ignorant :) What is SMock exactly ? >> >> > SMock is primitive mocks framework that I use for Mocketry development. > Only MocketryTests depends on SMock. > > > >> Indeed I've never used Mocketry but I want to package existing mocking >> frameworks for Pharo. >> >> >>> SMock only needed for MocketryTests. And if you need mocks just use >>> Mocketry. >>> I think SMock should has separate configuration >>> >> >> You mean ConfigurationOfSMock ? >> >> > > Yes. > > >

1 0

[Pharo-project] Issue 3360 in pharo: TextConverter handling of binary streams is wrong
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: New Owner: ---- New issue 3360 by sven.van.caekenberghe: TextConverter handling of binary streams is wrong http://code.google.com/p/pharo/issues/detail?id=3360 It seems that the way binary (#isBinary true) streams are handled by TextConverter and its subclasses is wrong. When given a binary stream, the core text converter methods (#nextPut:toStream and #nextFromStream:) simply do no longer encode or decode at all. Moreover, the unit test UTF8TextConverter>>#testPutSingleCharacter seems plain wrong. The actual encoded bytes should be #[97 226 130 172]. However, this behavior seems to be added by design, so it is hard to estimate the impact of changing this. It is currently very ugly to get a binary UTF-8 encoding, one has to write to a character stream and then turn those characters into bytes. I wrote an alternative UTF-8 encoder as a support class to the Zinc HTTP Components (http://www.squeaksource.com/ZincHTTPComponents.html) together with the following unit test: testUTF8Encoder "The examples are taken from http://en.wikipedia.org/wiki/UTF-8#Description" | encoder inputBytes outputBytes inputString outputString | encoder := ZnUTF8Encoder new. inputString := String with: $$ with: (Unicode value: 16r00A2) with: (Unicode value: 16r20AC) with: (Unicode value: 16r024B62). inputBytes := #[16r24 16rC2 16rA2 16rE2 16r82 16rAC 16rF0 16rA4 16rAD 16rA2]. outputBytes := self encodeString: inputString with: encoder. self assert: outputBytes = inputBytes. outputString := self decodeBytes: inputBytes with: encoder. self assert: outputString = inputString based on the helper methods: encodeString: string with: encoder ^ ByteArray streamContents: [ :stream | string do: [ :each | encoder nextPut: each toStream: stream ] ] decodeBytes: bytes with: encoder | input | input := bytes readStream. ^ String streamContents: [ :stream | [ input atEnd ] whileFalse: [ stream nextPut: (encoder nextFromStream: input) ] ] The new encoder code is simpler, but might not handle everything that is needed (leading chars, language codes), but is all that still needed ? Sven

1 1

[Pharo-project] Issue 3362 in pharo: Another fix for MethodReference
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3362 by Benjamin.VanRyseghem.Pharo: Another fix for MethodReference http://code.google.com/p/pharo/issues/detail?id=3362 RecentMessageList need an accessor to classSymbol to be able to change the reference when a class is renamed Attachments: AnotherMethodReferenceFix.1.cs 912 bytes

1 2

[Pharo-project] [update 1.2] #12266
by Marcus Denker Nov. 30, 2010

Nov. 30, 2010

12266 ----- Issue 3191: SparseLargeArray Issue 3363: #isSafeVM calls deprecated method Issue 3362: Another fix for MethodReference -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3363 in pharo: #isSafeVM calls deprecated method
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3363 by marcus.denker: #isSafeVM calls deprecated method http://code.google.com/p/pharo/issues/detail?id=3363 fix attached Attachments: AllocationTest-isSafeVM.st 572 bytes

1 1

Re: [Pharo-project] Issue 3191 in pharo: SparseLargeArray
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Updates: Status: Fixed Comment #2 on issue 3191 by jbaptiste.arnaud: SparseLargeArray http://code.google.com/p/pharo/issues/detail?id=3191 Inbox at Issue 3191: SparseLargeArray-JB.1

1 1

[Pharo-project] [update 1.2] #12265
by Marcus Denker Nov. 30, 2010

Nov. 30, 2010

12265 ----- Issue 3354: Clean of RecentMessageList Issue 3338: could not parse a <historical> time stamp Issue 3291: Missing text field with completion Issue 3356: AllocationTest>>#isSafeVM -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3356 in pharo: AllocationTest>>#isSafeVM
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3356 by Benjamin.VanRyseghem.Pharo: AllocationTest>>#isSafeVM http://code.google.com/p/pharo/issues/detail?id=3356 This code isSafeVM "False if the VM is a Unix VM that has not been updated to version 4. Earlier versions may be subject to a bug that can crash the VM when running AllocationTest." self flag: #toRemove. "April 2010 dtl - remove this about one year from now" ^ Smalltalk isUnix not or: [((Smalltalk vmFullPath findTokens: FileDirectory slash) select: [:e | e beginsWith: '4.']) isEmpty not] Should be changed by : isSafeVM "False if the VM is a Unix VM that has not been updated to version 4. Earlier versions may be subject to a bug that can crash the VM when running AllocationTest." self flag: #toRemove. "April 2010 dtl - remove this about one year from now" ^ Smalltalk isUnix not or: [((Smalltalk vmFullPath findTokens: FileDirectory slash) anySatisfy: [:e | e beginsWith: '4.'])]

1 3

Nov. 30, 2010

what we learned in the story is that the newinspector is too intrusive and that we should make sure that we limit the api to be used when building introspective tools. This is also why we will remove it from the next pharo-dev Stef On Nov 29, 2010, at 9:38 PM, jaayer wrote: > 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.<DelegatedSet.st>

2 1