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

Spec enhancements
by Stephane Ducasse Oct. 5, 2017

Oct. 5, 2017

Hi rob I like you extensions to label and text. I harvested them with the tests and I will slowly generalise that to other widgets. I published my current code experiments to MCSmalltalkhubRepository owner: 'Pharo' project: 'Spec' user: '' password: '' Stef

2 2

Non-deterministic ombu errors
by Gabriel Cotelli Oct. 5, 2017

Oct. 5, 2017

Hi, I'm having some non-deterministic errors in the Travis builds, the error is always something like: *OmFileStoreReadingError: Reading entry from File @ pharo-local/ombu-sessions/Pharo.4p8buz6mww48y1noxrolgwkl1.ombu@17432579: Invalid utf8 input detected* If I retried the build it works without any change. I think it happens during the code loading phase. Is anyone experiencing this issue? Here's an extract of the travis log: *OmFileStoreReadingError: Reading entry from File @ pharo-local/ombu-sessions/Pharo.4p8buz6mww48y1noxrolgwkl1.ombu@17432579: Invalid utf8 input detected* [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: UTF8InvalidText(Exception)>>signal UTF8InvalidText(Exception)>>signal: UTF8TextConverter>>errorMalformedInput UTF8TextConverter>>nextFromStream: MultiByteFileStream>>next MultiByteFileStream(PositionableStream)>>match: MultiByteFileStream(PositionableStream)>>upToAll: OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: OmBlockFileStore>>refreshNewBlocksFrom: [ :readStream | self refreshNewBlocksFrom: readStream ] in OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: in Block: [ :readStream | self refreshNewBlocksFrom: readStr...etc... [ ^ aBlockClosure value: readStream ascii ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure value: readStream ascii ] BlockClosure>>on:do: [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ... [ aBlock value: stream ] in FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock value: stream ] BlockClosure>>ensure: FileReference(AbstractFileReference)>>readStreamDo: OmBlockFileStore(OmFileStore)>>readEntriesWith: OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: [ | initialPosition initialLocalName | self entryBuffer isEmpty ifTrue: [ ^ self ]. fileReference writeStreamDo: [ :fileStream | fileStream setToEnd. initialPosition := fileStream position. initialLocalName := self entryBuffer first value. ZnBufferedWriteStream on: fileStream do: [ :aWriteStream | | anEntryWriter | anEntryWriter := self newEntryWriter. [ self entryBuffer isEmpty ] whileFalse: [ | next entry | next := self entryBuffer removeFirst. entry := next key. "Write entry to file" anEntryWriter on: aWriteStream nextEntryPut: entry ] ]. "In Linux it was necessary to explicitely flush the file stream" fileStream flush. lastStreamPosition := fileStream size ]. self refreshEntryPositionsByLocalNameStartingAt: initialPosition since: initialLocalName ] in OmBlockFileStore(OmFileStore)>>flushEntryBuffer in Block: [ | initialPosition initialLocalName |... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: OmBlockFileStore(OmFileStore)>>critical: OmBlockFileStore(OmFileStore)>>flushEntryBuffer OmDeferrer>>sendMessage [ self sendMessage ] in OmDeferrer>>flush in Block: [ self sendMessage ]

5 13

SystemVersion cleanup (or the return of the explicit build number) in latest Pharo 7
by Torsten Bergmann Oct. 5, 2017

Oct. 5, 2017

Hi, as you all know Pharo 7 is built using sources from github and a new bootstrap process. The first Pharo 7 images [1] unfortunately were hard to distinguish - the initial problem was described in [2] Guille tried to address this by adding a build number again [3] but unfortunately he mixed it into the existing suffix of the class SystemVersion. There was also some other trouble afterwards: - the highestUpdate was still not set by the bootstrap process, which made some code unloadable (like Artefact who's config is checking if it is above a certain update number) - with Guilles fix the build number had to be parsed from the suffix string - one was still not able to distinguish 32/64 bit images - the SystemVersion class and the according tests were still ugly So I reviewed all this more deeply and cleaned SystemVersion as well as the tests while trying to stay as compatible as possible. Thanks a lot to Pavel and Esteban who helped me sorting things out, especially in git and the bootstrap process. How does it look now ==================== 1. Our system type is still called "Pharo" ;) SystemVersion current type -> 'Pharo' 2. we still continue with major and minor versioning (leaving out patch versions), so currently work is done for Pharo 7.0 SystemVersion current major -> 7 SystemVersion current minor -> 0 SystemVersion current majorMinorVersion -> 'Pharo7.0' 3. the identification string now has a "+" sign inside to separate the build meta informations following the given rule 10 from http://semver.org So the full image version now looks like this: SystemVersion current imageVersionString -> 'Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit)' 4. the suffix is currently "alpha" and may be changed depending on release status SystemVersion current suffix -> 'alpha' 5. the build number is stored as an explicit ivar in SystemVersion now SystemVersion current build -> 168 Note that the build number is explicitly set during the bootstrap process from the outside and increased over time with each new build. It represents the CI build number of #development branch now, see [4] on CI server 6. the github SHA commit hash is accessible too: SystemVersion current commitHash -> '30fc9bbe79922877706ecd842f8aef6822cdcdd9' which corresponds in this case to the last commit in #development branch https://github.com/pharo-project/pharo/commit/30fc9bbe79922877706ecd842f8ae… 7. the version includes now also the 32/64 bit distinction: Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit) or Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (64 Bit) Additionally ============ - the version is displayed in SystemReporter and the AboutBox (Screenshot attached), please use this to identify the image easily - the #highestUpdate is calculated dynamically with code in the image (but it is there only for compatibility reasons). SystemVersion current highestUpdate -> "70168" We might easily catch the 999 build mark now and then run into 71000 which might still be Pharo 7.0 instead of 7.1. (which means first two digits of update number will then NOT correspond to major/minor version anymore). So better avoid #highestUpdate as a meaningful number for loading code or other. - also note if you contribute with an own PR (in your own fork on github) the build number is the build number of you PR specific CI build. Once your PR is reviewed and merged it is the regular Pharo image build number again. - you can reuse SystemVersion for you own apps built on top of Pharo: "MyKillerApp-1.0+beta (64 Bit)" can be easily created with: (SystemVersion major: 1 minor: 0 suffix: 'beta') type: 'MyKillerApp'; yourself - if you report a bug on bugs.pharo.org it would be good to note down the full version of the image you used as found in the About box. This allows to better reproduce wrong behavior that only happens in a specific image Thanks T. [1] http://files.pharo.org/image/70/ [2] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1309… [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1310… [4] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #168: 20464 Cleanup SystemVersion and SystemVersionTest (but stay compatible)
by ci-pharo-ci-jenkins2＠inria.fr Oct. 5, 2017

Oct. 5, 2017

There is a new Pharo build available! The status of the build #168 was: SUCCESS. The Pull Request #309 was integrated: "20464 Cleanup SystemVersion and SystemVersionTest (but stay compatible)" Pull request url: https://github.com/pharo-project/pharo/pull/309 Issue Url: https://pharo.fogbugz.com/f/cases/20464 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

removing deprecation of #pin methods
by Esteban Lorenzano Oct. 5, 2017

Oct. 5, 2017

Hi, I will remove deprecation of pin methods. Why? - because that change is causing a lot of incompatibilities with running 6.1 code. - because that change is causing some errors on current Pharo 7.0 development. So instead deprecate, it will be âmarked for deprecationâ, then deprecation will happen in Pharo 8.0. And just as a side note: next time I say âis is not a good ideaâ, believe me, it is not. Esteban

1 0

Call for spec user
by Stephane Ducasse Oct. 5, 2017

Oct. 5, 2017

Hi I did some changes and I would like to know if you could load the following issues and report potential problems. https://pharo.fogbugz.com/f/cases/20490/NewValueHolder-substituable-for-Val… Stef

1 0

pharo --help returning non-zero exit status
by Peter UhnÃ¡k Oct. 5, 2017

Oct. 5, 2017

Hi, why does executing `pharo --help` return exit status 1? The operation succeeded, so I don't see a reason for a failure return state. Thanks, Peter

5 6

About Pragma comment and Pragma description
by Stephane Ducasse Oct. 4, 2017

Oct. 4, 2017

Hi, That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? Cheers, Doru Doru where can I find the code?

1 0

String Interpolation
by Sven Van Caekenberghe Oct. 4, 2017

Oct. 4, 2017

Hi, I got into a little office discussion about string interpolation as it is done in different programming languages. In Pharo we have String>>#format: which is pretty nice. It works as follows: | x y | x := 123. y := #foo. 'x={1} and y={2}' format: { x. y }. It is also possible to use a dictionary with keys, like this: | x y | x := 123. y := #foo. 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings. Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work: | x y | x := 123. y := #foo. 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate. => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793' Here is the implementation I came up with: String>>#interpolate "Format the receiver by interpolating the evaluation of expressions in between curly brackets in the context of the sender as in the following 3 oneline examples. 'Today is {Date today}' interpolate. | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." | senderContext | senderContext := thisContext sender. ^ self class new: self size streamContents: [ :out | | stream | stream := self readStream. [ stream atEnd ] whileFalse: [ | currentChar | (currentChar := stream next) == ${ ifTrue: [ | expression result | expression := stream upTo: $}. result := Compiler new evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false. out nextPutAll: result asString ] ifFalse: [ currentChar == $\ ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ] ifFalse: [ out nextPut: currentChar ] ] ] ] It is a hack that could certainly be improved. And there is of course an obvious security problem. Thoughts ? Sven

14 39

Deprecating ValueHolder (call for Spec user)
by Stephane Ducasse Oct. 4, 2017

Oct. 4, 2017

Hi we have ValueHolder and NewValueHolder so I wanted to remove the 6 last user of ValueHolder. Now I see that we have ValueHolder >> contents: newContents contents := newContents. self changed: #contents NewValueHolder >> value: anObject self handleCircularReferencesWhile: [ | oldValue | oldValue := value. value := anObject. self valueChanged: oldValue ]. ^ value So dialog newSliderFor: (ValueHolder new contents: 0.5) getValue: #contents setValue: #contents: help: 'This is a slider'). => (dialog newSliderFor: (NewValueHolder new value: 0.5; yourself) getValue: #value setValue: #value: help: 'This is a slider'). and I find that boring to have to be forced to use yourself. as an experiment I changed the definition of value: to NewValueHolder >> value: anObject self handleCircularReferencesWhile: [ | oldValue | oldValue := value. value := anObject. self valueChanged: oldValue ]. Now I'm looking for spec users to tell me if I break something. Stef

1 0