- Pharo-dev - lists.pharo.org

[Pharo-project] XMLParser green bar on ci.inria.fr/pharo-contribution

by StÃ©phane Ducasse

Hi guys so we have a first version of XMLParser migrated to SmalltalkHub and with tests running on our cool integration server. http://ci.inria.fr/pharo-contribution I will continue with OPAX/Pastell and migrate SOUP to use this new version of XMLParser. Stef

March 3, 2013

Re: [Pharo-project] about run tests from nautilus

by Benjamin

Because some one decided that methods starting with "should" are also tests Ben On Mar 3, 2013, at 10:38 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi ben > > I do not know if you saw this behavior but when I press the button on the class of a test methods that are not tests > are also executed and reported as failures. > For example I got > > XMLNodeTest>>should: aBlock enumerate: aCollection > | enumerated | > > enumerated := OrderedCollection new. > aBlock value: [:each | enumerated add: each]. > self assert: enumerated = aCollection asOrderedCollection. > > executed while it is an helper. > With the testrunner I get a class with 100% green tests now. > but not with nautilus. > > Stef

March 3, 2013

[Pharo-project] About development on symbolic versions

by StÃ©phane Ducasse

Hi dale for pharo 3.0 alpha I want the following setup. I want to monitor all the pharo-contribution using jenkins. So is there a pattern to make sure that at the same time I can load the stable version of the project on 2.0 but the development baseline for the 3.0 (which may match the 20 if no change are made)? for example for XMLParser I have stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.1'. now what should I write for development? development: spec <symbolicVersion: #'development'> spec for: #'common' version: ???? Thanks

March 3, 2013

[Pharo-project] About XMLParser

by StÃ©phane Ducasse

Hi I saw that some change in the XML parser were commited on the gemstone repository. Does it means that this is only for gemstone? Should I take take of them in the new ConfigurationOfXMLParser I'm building? I cannot test gemstone so I'm dealing with it right now. still I was wondering if some of the changes should be push in the main branch or not. Stef

March 3, 2013

Re: [Pharo-project] Spreadsheet widget

by stephane ducasse

Hi ben I added you as contributor. >> >> >> > Thanks Stef. I've just signed up to Smalltalkhub. How do I contribute to the project? > The following has been added to the attached mcz. > * Pharo 1.4 does not have LayoutFrame>>identity. We should use 2.0 > * Allow external control of spreadsheet using SpreadsheetGridMorph>>cellStringAt:put: & cellStringAt: and added associated test. > * Fixed error with SpreadsheetCell>>printOn: missing Integer>>printAsColumnRefOn: and added associated test. > * To assist tracing/learning the code, added a few commented halt points. Worked around 'editedCell' instance variable losing its value while in debugger, which probably needs further review. cool :) > > cheers -ben > > <Spreadsheet-BenComan.3.mcz>

March 3, 2013

[Pharo-project] about run tests from nautilus

by StÃ©phane Ducasse

Hi ben I do not know if you saw this behavior but when I press the button on the class of a test methods that are not tests are also executed and reported as failures. For example I got XMLNodeTest>>should: aBlock enumerate: aCollection | enumerated | enumerated := OrderedCollection new. aBlock value: [:each | enumerated add: each]. self assert: enumerated = aCollection asOrderedCollection. executed while it is an helper. With the testrunner I get a class with 100% green tests now. but not with nautilus. Stef

March 3, 2013

Re: [Pharo-project] about OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1

by stephane ducasse

On Mar 3, 2013, at 10:23 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 03 Mar 2013, at 10:20, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Hi sven >> >> yes I imagine now we should improve in trakcing such changes. >> In addition I do not understand why >> >> XMLOrderedList new: 10 >> >> breaks the inspectorâ¦. > > Yes, I once saw that as well, very strange, I guess that is what happens when you start making your own collection classesâ¦ Yes they said that the inspector class is OrderedCollectionInspector but it does not work so I changed it to get the system debuggable right now. Stef > >> This is why all the important libraries should be covered by a jenkins job and tests. >> So that right on the spot we can identify problems. >> >> Stef >> >> >>> These important changes were made intentionally, so we need to find the rationale of the change. >>> Like is the new behavior covered by new tests ? >>> >>> On 03 Mar 2013, at 09:45, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> >>>> >>>> On Mar 3, 2013, at 9:42 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>> >>>>> I could overwrite XMLOrderedList >>>>> >>>>> replaceFrom: aStartingIndex to: anEndingIndex with: aCollection startingAt: aReplacementStart >>>>> >>>>> >>>>> collection >>>>> replaceFrom: aStartingIndex >>>>> to: anEndingIndex >>>>> with: aCollection >>>>> startingAt: aReplacementStart >>>>> >>>>> to make it grow? But I do not really know the impact on the XML library >>>>> >>>>>> self makeRoomFor: (anEndingIndex- self capacity). >>>>> >>>>> any idea? >>>> >>>> >>>> In fact it will not work since makeRoomFor: and others have been removed and I do not have the time to dive in >>>> OrderedCollection growing logic. >>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 3, 2013, at 9:34 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> in 1.2.1 >>>>>> >>>>>> OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 >>>>>> gave >>>>>> an OrderedCollection(6 7 8 9 10) >>>>>> >>>>>> >>>>>> while in 1.4 and 2.0 >>>>>> OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 >>>>>> raised an error >>>>>> >>>>>> Do you have an idea how I can handle that? Because XMLObservableList and XMLOrderedList implements >>>>>> replaceFrom: to: with: startingAt: >>>>>> >>>>>> because there is no self makeRoomFor: (stop - self capacity) invocation. >>>>>> >>>>>> >>>>>> in 1.4>> >>>>>> replaceFrom: start to: stop with: replacement startingAt: repStart >>>>>> "This destructively replaces elements from start to stop in the receiver >>>>>> starting at index, repStart, in the sequenceable collection, >>>>>> replacementCollection. Answer the receiver. No range checks are >>>>>> performed." >>>>>> >>>>>> | index repOff | >>>>>> repOff := repStart - start. >>>>>> index := start - 1. >>>>>> [(index := index + 1) <= stop] >>>>>> whileTrue: [self at: index put: (replacement at: repOff + index)] >>>>>> >>>>>> at: anInteger put: anObject >>>>>> "Put anObject at element index anInteger. at:put: cannot be used to >>>>>> append, front or back, to an ordered collection; it is used by a >>>>>> knowledgeable client to replace an element." >>>>>> self ensureBoundsFrom: anInteger to: anInteger. >>>>>> ^array at: anInteger + firstIndex - 1 put: anObject >>>>>> >>>>>> >>>>>> in 1.2.1 >>>>>> >>>>>> replaceFrom: start to: stop with: replacement startingAt: repStart >>>>>> "An ordered collection is growable, so a call to this can make the collection grow." >>>>>> self makeRoomFor: (stop - self capacity). >>>>>> array >>>>>> replaceFrom: start + firstIndex - 1 >>>>>> to: stop + firstIndex - 1 >>>>>> with: replacement >>>>>> startingAt: repStart. >>>>>> lastIndex := lastIndex max: stop + firstIndex - 1. >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

March 3, 2013

Re: [Pharo-project] about OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1

by stephane ducasse

> while in 1.4 and 2.0 > OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 > raised an error The problem I have is in fact that (OrderedCollection new: 10) replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 So even if the collection has enough space only a collection with enough elements can get them replaced. So I fixed the tests of the XMLOrderedList to work but I'm a bit unsatisfied. Stef > Do you have an idea how I can handle that? Because XMLObservableList and XMLOrderedList implements > replaceFrom: to: with: startingAt: > > because there is no self makeRoomFor: (stop - self capacity) invocation. > > > in 1.4>> > replaceFrom: start to: stop with: replacement startingAt: repStart > "This destructively replaces elements from start to stop in the receiver > starting at index, repStart, in the sequenceable collection, > replacementCollection. Answer the receiver. No range checks are > performed." > > | index repOff | > repOff := repStart - start. > index := start - 1. > [(index := index + 1) <= stop] > whileTrue: [self at: index put: (replacement at: repOff + index)] > > at: anInteger put: anObject > "Put anObject at element index anInteger. at:put: cannot be used to > append, front or back, to an ordered collection; it is used by a > knowledgeable client to replace an element." > self ensureBoundsFrom: anInteger to: anInteger. > ^array at: anInteger + firstIndex - 1 put: anObject > > > in 1.2.1 > > replaceFrom: start to: stop with: replacement startingAt: repStart > "An ordered collection is growable, so a call to this can make the collection grow." > self makeRoomFor: (stop - self capacity). > array > replaceFrom: start + firstIndex - 1 > to: stop + firstIndex - 1 > with: replacement > startingAt: repStart. > lastIndex := lastIndex max: stop + firstIndex - 1.

March 3, 2013

[Pharo-project] why cmd-M on a class is not equal to cmd-B

by StÃ©phane Ducasse

Hi guys this is at least two times that I reimplement this behavior why cmd-b on a symbol is not equal to cmd-m why cmd-m on a class name is not equal to cmd-b so boringâ¦. this idea that there is a difference between implementor and browse is plain bad. Stef

March 3, 2013

Re: [Pharo-project] about OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1

by Sven Van Caekenberghe

On 03 Mar 2013, at 10:20, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi sven > > yes I imagine now we should improve in trakcing such changes. > In addition I do not understand why > > XMLOrderedList new: 10 > > breaks the inspectorâ¦. Yes, I once saw that as well, very strange, I guess that is what happens when you start making your own collection classes... > This is why all the important libraries should be covered by a jenkins job and tests. > So that right on the spot we can identify problems. > > Stef > > >> These important changes were made intentionally, so we need to find the rationale of the change. >> Like is the new behavior covered by new tests ? >> >> On 03 Mar 2013, at 09:45, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> >>> On Mar 3, 2013, at 9:42 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> >>>> I could overwrite XMLOrderedList >>>> >>>> replaceFrom: aStartingIndex to: anEndingIndex with: aCollection startingAt: aReplacementStart >>>> >>>> >>>> collection >>>> replaceFrom: aStartingIndex >>>> to: anEndingIndex >>>> with: aCollection >>>> startingAt: aReplacementStart >>>> >>>> to make it grow? But I do not really know the impact on the XML library >>>> >>>>> self makeRoomFor: (anEndingIndex- self capacity). >>>> >>>> any idea? >>> >>> >>> In fact it will not work since makeRoomFor: and others have been removed and I do not have the time to dive in >>> OrderedCollection growing logic. >>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> On Mar 3, 2013, at 9:34 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >>>> >>>>> Hi guys >>>>> >>>>> in 1.2.1 >>>>> >>>>> OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 >>>>> gave >>>>> an OrderedCollection(6 7 8 9 10) >>>>> >>>>> >>>>> while in 1.4 and 2.0 >>>>> OrderedCollection new replaceFrom: 1 to: 5 with: #(6 7 8 9 10) startingAt: 1 >>>>> raised an error >>>>> >>>>> Do you have an idea how I can handle that? Because XMLObservableList and XMLOrderedList implements >>>>> replaceFrom: to: with: startingAt: >>>>> >>>>> because there is no self makeRoomFor: (stop - self capacity) invocation. >>>>> >>>>> >>>>> in 1.4>> >>>>> replaceFrom: start to: stop with: replacement startingAt: repStart >>>>> "This destructively replaces elements from start to stop in the receiver >>>>> starting at index, repStart, in the sequenceable collection, >>>>> replacementCollection. Answer the receiver. No range checks are >>>>> performed." >>>>> >>>>> | index repOff | >>>>> repOff := repStart - start. >>>>> index := start - 1. >>>>> [(index := index + 1) <= stop] >>>>> whileTrue: [self at: index put: (replacement at: repOff + index)] >>>>> >>>>> at: anInteger put: anObject >>>>> "Put anObject at element index anInteger. at:put: cannot be used to >>>>> append, front or back, to an ordered collection; it is used by a >>>>> knowledgeable client to replace an element." >>>>> self ensureBoundsFrom: anInteger to: anInteger. >>>>> ^array at: anInteger + firstIndex - 1 put: anObject >>>>> >>>>> >>>>> in 1.2.1 >>>>> >>>>> replaceFrom: start to: stop with: replacement startingAt: repStart >>>>> "An ordered collection is growable, so a call to this can make the collection grow." >>>>> self makeRoomFor: (stop - self capacity). >>>>> array >>>>> replaceFrom: start + firstIndex - 1 >>>>> to: stop + firstIndex - 1 >>>>> with: replacement >>>>> startingAt: repStart. >>>>> lastIndex := lastIndex max: stop + firstIndex - 1. >>>> >>>> >>> >>> >> >> > >

March 3, 2013