December 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec row height for list of custom widgets

by Ben Coman

On Fri, 27 Dec 2019 at 09:17, Ben Coman <btc(a)openinworld.com> wrote: > I'm trying to adapt this example from the Spec booklet... > > ListPresenter new > displayBlock: [ :x | x buildWithSpec ]; > items: ('Files' asPackage classes > collect: [:cls | ButtonPresenter new icon: cls systemIcon; > label: cls name]); > openWithSpec > > to use my own presenter rather than ButtonPresenter, but it seems to be > only showing the first line of my presenter. How can the height of each > list row be changed. i.e. for the able sample code, how to make the > buttons taller? > I thought #heightToDisplayInList: looked promising, but overriding it to force a particular value like this... ``` ButtonPresenter subclass: MyButtonPresenter ...etc MyButtonPresenter >> heightToDisplayInList: aList ^200 ``` then doing... ``` cls := 'Files' asPackage classes anyOne. mbp := MyButtonPresenter new icon: cls systemIcon; label: cls name. lp := ListPresenter new displayBlock: [ :x | x buildWithSpec ]; items: {mbp. mbp}. lp openWithSpec. ``` didn't change the row height. cheers -ben

Dec. 26, 2019

Spec row height for list of custom widgets

by Ben Coman

I'm trying to adapt this example from the Spec booklet... ListPresenter new displayBlock: [ :x | x buildWithSpec ]; items: ('Files' asPackage classes collect: [:cls | ButtonPresenter new icon: cls systemIcon; label: cls name]); openWithSpec to use my own presenter rather than ButtonPresenter, but it seems to be only showing the first line of my presenter. How can the height of each list row be changed. i.e. for the able sample code, how to make the buttons taller? cheers -ben

Dec. 26, 2019

Unnecessary double checks of infinity

by Serge Stinckwich

Hi all, I'm having a look how floats are printed. Why we check two times if a Float is infinite ? A first time in: Float>>printOn: stream base: base ... self isInfinite ifTrue: [ stream nextPutAll: 'Float infinity'. ^ self sign = -1 ifTrue: [ stream nextPutAll: ' negated' ] ]. ... and a second time in: Float>>absPrintExactlyOn: aStream base: base ... self isInfinite ifTrue: [ aStream nextPutAll: 'Float infinity'. ^ self]. ... the same in Float>>absPrintInexactlyOn: aStream base: base ... self isInfinite ifTrue: [aStream nextPutAll: 'Float infinity'. ^ self]. ... Apparently the last two methods are never called when number is infinite. I remove the second checks and apparently nothing breaks (all number tests are still green). Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroon "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Dec. 22, 2019

[Pharo 8.0] Build #1089: Test for hasLiteralThorough

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1089 was: SUCCESS. The Pull Request #5400 was integrated: "Test for hasLiteralThorough" Pull request url: https://github.com/pharo-project/pharo/pull/5400 Issue Url: https://github.com/pharo-project/pharo/issues/5154 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019

[ANN] Pharo Newsletter December 2019

by Marcus Denker

The December newsletter is now online: https://mailchi.mp/pharo/pharo-newsletter-december-2019 If you have content for the next newsletter -> send me a mail. It starts to get *really* difficult to not forget something. Marcus

Dec. 20, 2019

[Pharo 8.0] Build #1088: 4611-Lint-clean--categorize-in-Beacon-Core-Tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1088 was: SUCCESS. The Pull Request #4612 was integrated: "4611-Lint-clean--categorize-in-Beacon-Core-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/4612 Issue Url: https://github.com/pharo-project/pharo/issues/4611 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019

Re: [Pharo-dev] pharo compiler on scientific notation

by Sven Van Caekenberghe

The tests you refer to would basically test Float infinity = Float infinity. If you change NumberParser>>#readExponent "read the exponent if any (stored in instVar). Answer true if found, answer false if none. If exponent letter is not followed by a digit, this is not considered as an error. Exponent are always read in base 10." | eneg epos | exponent := 0. sourceStream atEnd ifTrue: [ ^ false ]. (self exponentLetters includes: sourceStream peek) ifFalse: [ ^ false ]. sourceStream next. eneg := sourceStream peekFor: $-. epos := eneg not and: [ self allowPlusSignInExponent and: [ sourceStream peekFor: $+ ] ]. (exponent := self nextUnsignedIntegerOrNilBase: 10) ifNil: [ "Oops, there was no digit after the exponent letter.Ungobble the letter" exponent := 0. sourceStream skip: ((eneg or: [ epos ]) ifTrue: [ -2 ] ifFalse: [ -1 ]). ^ false ]. eneg ifTrue: [ exponent := exponent negated ]. ^ true You will get Float infinity for exponents that are too large. The test on the exponent range was bogus anyway. > On 20 Dec 2019, at 10:58, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > actually the problem arose from some old code that I tried to load and > failed to. > > So I guess at some point in the past (pharo4 or prior) it was working : > > --- > PPExpressParserTests>>testReal3 > self parse: '-1.1333e3333' rule: #literal. > self assert: (result value = -1.1333e3333). > self assert: (PPSmalltalkParser parseExpression: '- > 1.1333e3333') = result rbNode > --- > > nicolas > > On Fri, 2019-12-20 at 10:21 +0100, Sven Van Caekenberghe wrote: >> Yes, the difference is not good. >> >> Indeed, >> >> Float fmax. "1.7976931348623157e308" >> >> The reason >> >> Number readFrom: '7.5e333'. >> >> gives infinity is actual not because of the reading, but because of >> >> 75e332 asFloat. >> >> Which is probably correct. >> >> The failure of >> >> Number readFrom: '7.5e3333'. >> >> is because of NumberParser>>#readExponent >> >> However, the test at the end is probably wrong. >> >> Float emax >> >> is a binary number, not a decimal one, IIUC. >> >> Nicolas (nice) ? >> >>> On 19 Dec 2019, at 19:28, tbrunz <wild.ideas(a)gmail.com> wrote: >>> >>> I would expect that both would result in +Inf. >>> >>> A IEEE-754 'double' overflows around 2e308. >>> >>> Surely both cases should behave the same way..?? >>> >>> -t >>> >>> >>> >>> -- >>> Sent from: >>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> >> > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Dec. 20, 2019

[Pharo 8.0] Build #1087: Removed method characterTable. It was not used

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1087 was: SUCCESS. The Pull Request #5399 was integrated: "Removed method characterTable. It was not used " Pull request url: https://github.com/pharo-project/pharo/pull/5399 Issue Url: https://github.com/pharo-project/pharo/issues/5275 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019

Techtalk December recording online

by Marcus Denker

"Working with Spec2 and GTK" Recording: https://www.youtube.com/watch?v=IVY7TH4MCXI There is a playlist for all techtalk recordings here: https://www.youtube.com/playlist?list=PL4actYd6bfnx8l8cqYWhdNB6gJgRvk5sH

Dec. 20, 2019

[Pharo 8.0] Build #1086: Migrating the context menu of Keymap browser to Spec2

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1086 was: SUCCESS. The Pull Request #5396 was integrated: "Migrating the context menu of Keymap browser to Spec2" Pull request url: https://github.com/pharo-project/pharo/pull/5396 Issue Url: https://github.com/pharo-project/pharo/issues/5389 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019