- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] changing default theme to DarkTheme

by Dimitris Chloupis

Resistance is futile You know what amazes me about this discussion ? The one thing that I find amazing is that we have like 58 messages already , many of them complain about the dark theme and not one even bothered posting a single screenshot demonstration all these "problems" , just one . How hard it is to trigger a shortcut to capture an image so we who love the dark theme can see why some people find it hard to use. And this is why I feel lucky that the deed is done and this is no democracy.... very happy indeed :) On Thu, Apr 20, 2017 at 8:48 PM Ben Coman <btc(a)openinworld.com> wrote: > I see in 60467 that the deed is done. Okay, so moving forward... be > prepared ;) for a surge of feedback as a bunch of us > dark-theme-newbies start using it in earnest. I understand those that > been using it a while already are obviously happy with how its tuned, > and probably not many things can be accommodated, but there is one > thing... > > Maybe its that its 1AM, or its my astigmatism, but my first impression > was a shock at the high contrast pure-white-on-black text - for the > World Menu and System Browser - to the degree that my eyes felt > crosseyed. Particularly the title-bar-text was jarring. Dimming it > slightly made it *much* easier to focus. Could > dark-theme-connoisseurs try this out... > > Pharo3DarkTheme>>textColor > ^ Color veryLightGray lighter > > > And wow! That very bright green in TestRunner hurts. > > > Other than that, so far it looks cool. > > cheers -ben > > > On Thu, Apr 20, 2017 at 3:19 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > For the mooc we have normally an image: it is called Pharo 50. > > > > S. > > > > On Mon, Apr 17, 2017 at 3:34 PM, Mark Bestley <news{(a)bestley.co.uk> > wrote: > >> > >> Dimitris Chloupis <kilon.alios(a)gmail.com> > >> wrote: > >> > >> > --001a113a8620c74f7a054d5aba55 > >> > Content-Type: text/plain; charset=UTF-8 > >> > > >> > Not before IMMEDIATELY realizing that all screenshots containing the > >> > white > >> > theme are outdated and will IMMEDIATELY prefer the dark ones that will > >> > have > >> > an updated view of the Pharo GUI compared to a screenshot that has the > >> > white theme and it's outdated by two or more years. > >> > > >> > >> No they will think it is for a different environment and waste time > >> looking for a match. > >> > >> A beginner won't see that just that they cannot get the same answer as > >> the mooc or documentation. > >> > >> They will look for a language where the documentation matches what they > >> get as they don't know if the documentation or their code is wrong. (and > >> probably cast aspersions on the quality of what they are using) > >> > >> > Updating the screenshots for PBE5 was a big pain and I am sure there > are > >> > ones that are left that are still outdated showing 1.4 , which is at > >> > least > >> > 6 years old. > >> > > >> > >> -- > >> Mark > >> > >> > > > >

April 21, 2017

Re: [Pharo-dev] #renameTo: and #moveTo:

by Alistair Grant

On Thu, Apr 20, 2017 at 09:21:01PM +0200, Nicolas Cellier wrote: > 2017-04-20 9:53 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > > What? Google this: man stat The first field of stat structure is > > a device ID, so deciding if two files are on same file system or > > not is doable by checking this field for the source file and > > destination file (if it exists) or directory - modulo the fact > > that you'd have to care of symbolic links with lstat. > > I meant from within the image. Also, while this is fine for > Linux, and probably for MacOS, what about Windows? > > Ah, so it's more a Squeak/Pharo VM problem than a unix problem ;) You > are right, there is a call to stat() in unix file plugin > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… > > but the device info is not passed back to the image... Too bad! But it should be a straightforward extension. I think I'll ask on vm-dev if anyone objects to me adding this extension. Thanks for pointing this out! Cheers, Alistair > As for windows, it's not a problem, there is a rename function that > would move files across devices (but not directories!) See rename() on > msdn https://msdn.microsoft.com/en-us/library/zw5t957f.aspx

April 21, 2017

Re: [Pharo-dev] [Vm-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

by Nicolai Hess

John Brant discovered this bug recenlty: (see bottom of his post) http://forum.world.st/collection-flatCollect-something-VS-collection-collec… 2017-04-21 1:56 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Thu, Apr 20, 2017 at 4:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi All, >> >> just stumbled across a bytecode compiler bug that's in both the >> Squeak compiler and the Opal compiler. I'm told by ClÃ©ment that Opal >> mimics the bug to avoid crashing legacy code. So there may be places that >> depend on this bug. It would be good to eliminate the dependencies and the >> bug. >> >> For illustration look at the to:do: loop in the ifNil: arm in >> Context>>privRefresh: >> >> Context>>privRefresh >> "Reinitialize the receiver so that it is in the state it was at its >> creation." >> closureOrNil >> ifNotNil: >> [pc := closureOrNil startpc. >> self stackp: closureOrNil numArgs + closureOrNil numCopiedValues. >> 1 to: closureOrNil numCopiedValues do: >> [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]] >> ifNil: >> [pc := method initialPC. >> self stackp: method numTemps. >> method numArgs+1 to: method numTemps do: >> [:i | self tempAt: i put: nil]] >> >> >> This should evaluate method numArgs + 1 then method numTemps. If it were >> written as a non-in-lined (method numArgs+1 to: method numTemps) do: [:i| >> self tempAt: i put: nil] then the [self tempAt: i put: nil] block would be >> created next. But the bytecode for the inlined version is >> >> self stackp: method numTemps. >> 63 <70> self >> 64 <84 40 03> pushRcvr: 3 >> 67 <D6> send: numTemps >> 68 <E1> send: stackp: >> 69 <87> pop >> >> iLimit := method numTemps >> 70 <84 40 03> pushRcvr: 3 >> 73 <D6> send: numTemps >> 74 <69> popIntoTemp: 1 >> >> i := method numArgs + 1 >> 75 <84 40 03> pushRcvr: 3 >> 78 <D2> send: numArgs >> 79 <76> pushConstant: 1 >> 80 <B0> send: + >> 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo) >> 83 <10> pushTemp: 0 >> 84 <11> pushTemp: 1 >> 85 <B4> send: <= >> 86 <AC 0B> jumpFalse: 99 >> >> There is a second bug in the Squeak bytecode; storeIntoTemp: is used to >> load i whereas it should be popIntoTemp:. It was this second bug that >> alerted me to the order-of-evaluation bug. >> > > The second bug (Squeak's use of storeIntoTemp:) is actually only a poor > implementation of the value/effect distinction through the inlined > ifNil:ifNotNil:. Because ifNil:ifNotNil: has a value (albeit one that is > discarded) the Squeak compiler generates a storeIntoTemp: to p[reserve the > value of the to:do: lop, which is the initial index. So the bug is not > within the generation of the to:do: (the only bug there being the > order-of-evaluation one). The bug is actually outside; the loop should be > being generated for effect but is being evaluated for value. > > On the order of evaluation bug, does anyone have any memory of which > methods depended on this bug? > > _,,,^..^,,,_ >> best, Eliot >> > > > > -- > _,,,^..^,,,_ > best, Eliot > >

April 21, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Alistair Grant

On Fri, Apr 21, 2017 at 09:05:15AM +0800, Ben Coman wrote: > On Fri, Apr 21, 2017 at 12:31 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > On the other hand, we have #keysAndValuesDo: which competes with > > #withIndexDo: and is a bit more portable across dialects > > (it's just that it turns the bloc parameters the other way around, [:index > > :element | ]) > > > > So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect: > > > > Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a > > SequenceableCollection) the keys are indices. Or the other way around, a > > Dictionary is indexed by arbitrary keys (not just positive integers). > > Sounds like something I should know, but I'm not quite getting it. > Could you provide an example? Is this what you meant? | results | results := OrderedCollection new. #('a' 'b' 'c' 'd') keysAndValuesDo: [ :k :v | results add: { k. v. } ]. results Cheers, Alistair

April 21, 2017

Re: [Pharo-dev] do we "how to use Announcements" somewhere

by Ben Coman

On Fri, Apr 21, 2017 at 10:12 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Apr 21, 2017 at 5:47 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> I was just explaining how Announcer/Announcements work to somebody because I couldn't find any online resource, but I thought I saw it somewhere. >> >> Do we have it explained in some book? >> >> Peter >> > > I remember finding this tutorial very instructive. Its quite old so > I'm not sure how current it is, but I don't think much has changed > with the Announcements API. > http://pharo.dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial > > Also... > http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/ > and... > https://pharoweekly.wordpress.com/2016/09/03/building-an-announcement-spy-i… > > cheers -ben Oh, and... https://github.com/SquareBracketAssociates/PharoLimbo/blob/master/Announcem… cheers -ben

April 21, 2017

Re: [Pharo-dev] do we "how to use Announcements" somewhere

by Ben Coman

On Fri, Apr 21, 2017 at 5:47 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > I was just explaining how Announcer/Announcements work to somebody because I couldn't find any online resource, but I thought I saw it somewhere. > > Do we have it explained in some book? > > Peter > I remember finding this tutorial very instructive. Its quite old so I'm not sure how current it is, but I don't think much has changed with the Announcements API. http://pharo.dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial Also... http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/ and... https://pharoweekly.wordpress.com/2016/09/03/building-an-announcement-spy-i… cheers -ben

April 21, 2017

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

by Ben Coman

On Fri, Apr 21, 2017 at 3:11 AM, Luke Gorrie <luke(a)snabb.co> wrote: > Hi Ben, > > Thanks for explaining the process for maintaining the stable vs development > versions and illustrating it with data. > > I need to understand the Pharo Launcher better. Could indeed be the best > strategy is to focus on supporting that well. That's basically the approach > that Damien has taken with the current nix packages. > > Hopefully we can work out the optimal way to package Pharo once 6.0 has > shipped and people have more bandwidth. Just now I have a hard time > understanding what VM+image combinations are considered to be "supported" In times past, the VM from the previous release has usually remained stable for the most of the next development cycle. Except last year there was a big change from pre-Spur to Spur, and this year a big change from 32-bit to 64-bit, as you can see from the rate of change... https://github.com/OpenSmalltalk/opensmalltalk-vm/graphs/contributors These two very positive events obviously came with more churn in updating the VM. > vs which ones are likely to have obscure plugin problems, etc. I've not seen many plugin problems reported. Now unless you join the consortium or otherwise pay for support, I would guess you'll get the "best" support on the tip of development, with the risk of being the first to categorise a new bug. What might be good is to periodically define some recommended in-development VM-Image combinations, so we get more people working with a particular combination - to more quickly hit bugs in a particular combo, and provide confidence for the more cautious to move their applications forward. That is, not the effort of a full release, (@Esteban?) Very broadly, I'd stick with the Pharo 6 release for the first 3 - 6 months while any high impact stuff that has been waiting in the wings during the Pharo 6 feature freeze are integrated. Then as Pharo-6 bugs fixed in Pharo-7-dev accumulate, consider moving your personal development to Pharo-7-dev, keeping release on Pharo-6. It probably a good idea port your app to Pharo-7-dev at least three months prior to its release - so any bugs you hit get fixed *in* Pharo 7, otherwise (unless they are critical, or you pay) you may end up waiting until Pharo 8 release. Probably its good to have CI running for both Pharo 6 Release and Pharo-7-dev-tip so your tests pick up any new bugs. https://ci.inria.fr/pharo-contribution/ @Damien might advise how compatible this is with nix. (Disclaimer: Pharo is currently just a (significant) hobby for me, so in practice YMMV.) cheers -ben

April 21, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Ben Coman

On Fri, Apr 21, 2017 at 12:31 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-04-20 17:06 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> >> >> On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> >>> why? >>> Iterators are powerful and avoid that we all reinvent the wheel in our >>> own corners. >>> >>> About keySelect: I do not see the point to convert a large collection >>> into a dictionary then do yet another pass. >>> To me it looks like a hack. >>> >>> I implemented >>> selectEvery: >>> (selectFirst selectSecond) as helpers. >>> >>> and also unzip all in one pass. >>> Now I have no problem to keep them for me but to me this is the wrong >>> attitude. >>> >>> Stef >>> >>> >>> testSelectEveryFirst >>> self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' >>> #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) >>> asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') >> >> >> >> selectEveryFirst seems a strange name, not indicating the skip amount. >> The first of every three? or four? As it stand, technically I'd think its >> result would >> be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' >> #classVariableNames: '' #package: 'Kernel-BasicObjects') >> >> +1 to Peter's suggested #withIndexSelect: >> >> cheers -ben > > > On the other hand, we have #keysAndValuesDo: which competes with > #withIndexDo: and is a bit more portable across dialects > (it's just that it turns the bloc parameters the other way around, [:index > :element | ]) > > So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect: > > Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a > SequenceableCollection) the keys are indices. Or the other way around, a > Dictionary is indexed by arbitrary keys (not just positive integers). Sounds like something I should know, but I'm not quite getting it. Could you provide an example? cheers -ben

April 21, 2017

Re: [Pharo-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

by Eliot Miranda

On Thu, Apr 20, 2017 at 4:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > just stumbled across a bytecode compiler bug that's in both the Squeak > compiler and the Opal compiler. I'm told by ClÃ©ment that Opal mimics the > bug to avoid crashing legacy code. So there may be places that depend on > this bug. It would be good to eliminate the dependencies and the bug. > > For illustration look at the to:do: loop in the ifNil: arm in > Context>>privRefresh: > > Context>>privRefresh > "Reinitialize the receiver so that it is in the state it was at its > creation." > closureOrNil > ifNotNil: > [pc := closureOrNil startpc. > self stackp: closureOrNil numArgs + closureOrNil numCopiedValues. > 1 to: closureOrNil numCopiedValues do: > [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]] > ifNil: > [pc := method initialPC. > self stackp: method numTemps. > method numArgs+1 to: method numTemps do: > [:i | self tempAt: i put: nil]] > > > This should evaluate method numArgs + 1 then method numTemps. If it were > written as a non-in-lined (method numArgs+1 to: method numTemps) do: [:i| > self tempAt: i put: nil] then the [self tempAt: i put: nil] block would be > created next. But the bytecode for the inlined version is > > self stackp: method numTemps. > 63 <70> self > 64 <84 40 03> pushRcvr: 3 > 67 <D6> send: numTemps > 68 <E1> send: stackp: > 69 <87> pop > > iLimit := method numTemps > 70 <84 40 03> pushRcvr: 3 > 73 <D6> send: numTemps > 74 <69> popIntoTemp: 1 > > i := method numArgs + 1 > 75 <84 40 03> pushRcvr: 3 > 78 <D2> send: numArgs > 79 <76> pushConstant: 1 > 80 <B0> send: + > 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo) > 83 <10> pushTemp: 0 > 84 <11> pushTemp: 1 > 85 <B4> send: <= > 86 <AC 0B> jumpFalse: 99 > > There is a second bug in the Squeak bytecode; storeIntoTemp: is used to > load i whereas it should be popIntoTemp:. It was this second bug that > alerted me to the order-of-evaluation bug. > The second bug (Squeak's use of storeIntoTemp:) is actually only a poor implementation of the value/effect distinction through the inlined ifNil:ifNotNil:. Because ifNil:ifNotNil: has a value (albeit one that is discarded) the Squeak compiler generates a storeIntoTemp: to p[reserve the value of the to:do: lop, which is the initial index. So the bug is not within the generation of the to:do: (the only bug there being the order-of-evaluation one). The bug is actually outside; the loop should be being generated for effect but is being evaluated for value. On the order of evaluation bug, does anyone have any memory of which methods depended on this bug? _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

April 20, 2017

Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

by Eliot Miranda

Hi All, just stumbled across a bytecode compiler bug that's in both the Squeak compiler and the Opal compiler. I'm told by ClÃ©ment that Opal mimics the bug to avoid crashing legacy code. So there may be places that depend on this bug. It would be good to eliminate the dependencies and the bug. For illustration look at the to:do: loop in the ifNil: arm in Context>>privRefresh: Context>>privRefresh "Reinitialize the receiver so that it is in the state it was at its creation." closureOrNil ifNotNil: [pc := closureOrNil startpc. self stackp: closureOrNil numArgs + closureOrNil numCopiedValues. 1 to: closureOrNil numCopiedValues do: [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]] ifNil: [pc := method initialPC. self stackp: method numTemps. method numArgs+1 to: method numTemps do: [:i | self tempAt: i put: nil]] This should evaluate method numArgs + 1 then method numTemps. If it were written as a non-in-lined (method numArgs+1 to: method numTemps) do: [:i| self tempAt: i put: nil] then the [self tempAt: i put: nil] block would be created next. But the bytecode for the inlined version is self stackp: method numTemps. 63 <70> self 64 <84 40 03> pushRcvr: 3 67 <D6> send: numTemps 68 <E1> send: stackp: 69 <87> pop iLimit := method numTemps 70 <84 40 03> pushRcvr: 3 73 <D6> send: numTemps 74 <69> popIntoTemp: 1 i := method numArgs + 1 75 <84 40 03> pushRcvr: 3 78 <D2> send: numArgs 79 <76> pushConstant: 1 80 <B0> send: + 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo) 83 <10> pushTemp: 0 84 <11> pushTemp: 1 85 <B4> send: <= 86 <AC 0B> jumpFalse: 99 There is a second bug in the Squeak bytecode; storeIntoTemp: is used to load i whereas it should be popIntoTemp:. It was this second bug that alerted me to the order-of-evaluation bug. _,,,^..^,,,_ best, Eliot

April 20, 2017