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

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

by Stephane Ducasse

Yes this is probably what I was also looking for. On Wed, Apr 19, 2017 at 11:07 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > We already have > > * #withIndexCollect: > * #withIndexDo: > > > So why not #withIndexSelect: ? > > #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ > :each :i | i \\ 2 = 0 ] > > Peter > > p.s. for every second you could also do > aCollection pairsCollect: [ :first :second | second ] > > > On Wed, Apr 19, 2017 at 04:35:07PM -0300, Esteban A. Maringolo wrote: > > 2017-04-19 16:17 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > > 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. > > > > keySelect: would do a select based on the key (index in the case of > > SequenceableCollection) of the element, no need to create a > > Dictionary. > > > > keySelect: aBlock > > | result | > > result := self species new. > > self keysAndValuesDo: [:key :value | > > (aBlock value: key) ifTrue: [result add: value] > > ]. > > ^result > > > > > > You could implement #selectEverySecond or #selectEveryFirst in terms > > of the above. The name sounds weird though, but I'm not a native > > English speaker. > > > > Regarding #unzip it's a different story, I wouldn't use 'zip' in a > > selector for non Zip (compression) related methods. > > > > But do as you please, Pharo is yours as well ;) > > > > Regards! > > > > > > > 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') > > > testSelectEverySecond self assert: (#(#Object #subclass: #Point > > > #instanceVariableNames: 'x y' #classVariableNames: '' #package: > > > 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: > > > #instanceVariableNames: #classVariableNames: #package:) > > > testUnzip > > > | uz | > > > uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' > > > #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. > > > self assert: uz first asArray equals: #(#Object #Point 'x y' '' > > > 'Kernel-BasicObjects'). > > > self assert: uz second asArray equals: #(#subclass: > #instanceVariableNames: > > > #classVariableNames: #package:) > > > > > > Esteban A. Maringolo > > > >

April 20, 2017

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

by Stephane Ducasse

This is what I was looking for. On Wed, Apr 19, 2017 at 10:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There are already #pairsDo: and #pairsCollect: that could be used: > > #(a b c d e f g h) pairsCollect: [ :x :y | y ] > > => #(#b #d #f #h) > > > On 19 Apr 2017, at 22:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > I like this one. > > > > Doru > > > > > >> On Apr 19, 2017, at 8:43 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> Hi > >> > >> I have > >> > >> #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like > to select on the second elements. > >> > >> I was thinking that > >> > >> #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i > | i \\ 2 = 0 ] > >> could be a nice iterator. > >> > >> What do you think? > >> > >> > >> Stef > >> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Innovation comes in the least expected form. > > That is, if it is expected, it already happened." > > > > > > >

April 20, 2017

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

by Ben Coman

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 20, 2017

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

by Nicolas Cellier

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).

April 20, 2017

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

by Ben Coman

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

April 20, 2017

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

by Ben Coman

On Thu, Apr 20, 2017 at 10:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > Moved thread back to pharo-dev for image-side nix packaging discussion. Whoops. Try again, back to pharo-dev. > > On Thu, Apr 20, 2017 at 3:59 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> >> On 20 April 2017 at 06:03, Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Thu, Apr 20, 2017 at 12:21 AM, Luke Gorrie <luke(a)snabb.co> wrote: >>>> >>>> Then you can start one of those images with these shell commands: >>>> >>>> pharo-6.0 >>>> pharo64-6.0 >>>> pharo-5.0 >>>> moose-6.1 >>>> pharo-launcher-2017.02.28 >>> >>> Since Pharo 6 is not yet released, what are the implications of naming those >>> pharo-6.dev & pharo64-6.dev [minor edit] >> >> On reflection I will split up my packaging work into "vm" and "image" components. I will send the vm upstream ASAP. I will leave the images on a development branch, perhaps indefinitely, because I am not sure that I am on the right track there at all. > > That sounds like a good approach. > >> So, here are more thoughts on image packaging, but with the disclaimer that I will probably not actively pursue this topic further at the moment: >> >> I assert that Pharo 5 and Pharo 6 are both released, > > The "release" event will create the PharoV60.sources file, > null out the .changes file (it gets incorporated into PharoV60.sources) > and Pharo 7 development on will commence. > None of those things has happened yet. > Last I read, this was due in May, similar timeframe to Pharo 5 release > last year. > >> and are both fast-moving targets. > > The attached chart shows the dev-image build rate. > There is a clear change in Pharo 5 build rate after it was released on 12-May. > What happens is that during Pharo-6-development, a critical bug was > fixed and deemed worthy to backport to Pharo 5. That doesn't put > released-Pharo-5 and in-development-Pharo-6 on equal footing. > > Perhaps for packaging for distributions we need a modified process > for post-release-updates, such that the released image remains > constant and upon startup notifies that there are updates available to > install. > >> >> On http://pharo.org/download there is a prominent link to Pharo 6 as the "development version" ready for download. Anecdotally the Pharo community that I interact with (mailing list, twitter, slack chat, etc) seem more focused on Pharo 6 than on Pharo 5. > > The greater focus on Pharo 6 is because it is "in development" > and you are talking to pharo-developers. > > >> Occasionally people express surprise when I tell them I am "still" using Pharo 5. > > On the one hand, that might be considered overzealous recommending > alpha/beta software for your primary platform. On the other hand, > in practice many find the bleeding edge consistently very stable. > (opinion depends on the exact critical nature the application) > > The thing is, if you hit a bug in the in-development version, it can > get fixed quite quickly. More Pharo-developers work on the HEAD, > so its self interest to get things working smoothly. Policy is that *all* > fixes must *first* be done in the in-development-version. Only critical > fixes get backported to the released-version. So if you hit a bug in > a released-version, you might not see the fix before the next release. > > So there is a lot of benefit following the tip of development. > >> >> On http://files.pharo.org/image/50/ there is a new release of Pharo 5 every few weeks. This means that each time I have downloaded "Pharo 5" in the past I have probably gotten a different image and a different VM. So from my end-user perspective I have no idea what software I am installing regardless of whether I choose Pharo 5 or Pharo 6. > > I consider this moving target for a released version (i.e. Pharo 5) a > problem. Personally I'd like to see post-release versionning like > 5.0.x, > but other seem to disagree, or maybe its just resourcing. > > Pharo 6 is "in-development" so different rules apply. > Personally I never use the "latest" download. > I manually choose the latest build using PharoLauncher (couldn't live > without it) > > >> >> So as a nix user it would make sense for me to be able to download both Pharo 5 and Pharo 6 and for the nix package definitions to determine exactly which software I am running (as opposed to getting an invisible update from Pharo upstream every few days/weeks potentially leading to "but it worked fine on my other machine..." sorts of problems that are exactly what can nix protect me from.) >> > > I agree with you wrt to a released-Pharo-5, but not in-development-Pharo-6. > > >>> Packing the other images is maybe also wrong. How would you deal with user state being stored in the image when a new build download in available? >> >> >> The ad-hoc idea that I ran with is this: >> >> Running a script like pharo-5.0 (or moose-6.1, etc) will make a temporary copy of the image in the current directory. The changes file will be read-write (requirement) but the image file will be read-only. The model is "you saved it, you own it" i.e. if you want the image to survive after exit you need to "Save image as..." and once you do that then you are responsible for it. > > I hardly ever use "Save image as...", just "Save" and I think that might > confuse existing users if they *need* to do it. Probably workable would be > having the "Save image as..." dialog appear the first that "Save" is chosen. > >> >> Code: script to run an image[1] and script to start the right vm[2]. >> > [1] https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/images… > [2] https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/wrappe… > > >> I am not sure why "Save image as..." is misbehaving for me. I have tested every combination of read/write permissions on the working directory, the image, the changes file, etc, but it was always the same. I am sure that I can work this out via the Smalltalk debugger -- but at the moment it seems to make more sense to focus on the VM than on the images. (I want to wrap this up.) >> >> The downside to skipping the images is that I don't maintain feature parity with Damien's original nix packaging. He packaged the launcher image and then that was the gateway to everything else. This solution doesn't feel very solid to me, since now in 2017 I don't think the launcher is accounting for all the different VM requirements properly, but I am not willing to pick up maintenance of that image so that is life. > > Skipping Images is different to skipping Launcher. The Launcher > provides a *static* vm+image that is used to manage Images to solve > "movign target" problem you are hitting. Launcher could perhaps do > with some further extension to distinguish 64-bit Images, since that > requirement has only arisen in the past year, and also perhaps be able > to manage multiple VMs, instead of just the pre-Spur & Spur VMs > configured in its settings. But otherwise Launcher works fairly well. > > If feasible, I'd suggest that you separately package the VMs, and then > have a package for PharoLauncher that depends on that package. > > cheers -ben > >> >> Cheers, >> -Luke >> >> >> On Thu, Apr 20, 2017 at 6:43 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > On 20 April 2017 at 09:59, Luke Gorrie <luke(a)snabb.co> wrote: >> >> On reflection I will split up my packaging work into "vm" and "image" components. I will send the vm upstream ASAP. I will leave the images on a development branch, perhaps indefinitely, because I am not sure that I am on the right track there at all. > > > On further reflection it is possible that I am on the wrong track with the VM packaging too. > > Pharo upstream are distributing releases as binary vm+image pairs with some third party libraries included. The most faithful way to package this for nix would be to take these binaries and make them work (using patchelf to fix up the shared library paths.) This is how people package other binary software for nix e.g. Skype. > > The advantage of this approach would be to faithfully reproduce the software as it is released from the Pharo project. This way nix users would expect the software to work equally well as on Ubuntu or Fedora, say. This would also ease support because Pharo upstream would never be bothered by users having problems due to my packaging e.g. using the latest VM with an older image release if that is not supposed to be supported. This is the advantage of using PharoLauncher, and I wonder if nix is what inspired Damien to develop PharoLauncher. It pairs a static VM and a static image for *itself*, with settings to determine which VM is used. Your packaging should not enter the picture for which VMs and Images users combine together. Although you might > > The disadvantage is that this does not suit my own use case. I want to develop a Pharo application, deploy it with nix, and support it myself. The binary releases are too opaque for my taste and I don't want to work with them. In this context I see a net benefit to building everything from sources and tracking all the dependencies explicitly on the nix level. So I would continue to use this source-based packaging myself, and I would not be interested in spending the time to package up the binaries for other people. Perhaps you can achieve what you want by packaging PharoLauncher separately from the VMs. Then IIUC, the VM-package-version for your application could move on while the VM-package-version for PharoLauncher could remain pinned?? You may find PharoLauncher useful while developing your application. It excels when you want a new clean image from which to test a bug, or generate a submit a bug report or fix, or install a slice of a fix to review. > > So - I need to rethink whether I am the right person to maintain the generic pharo packages for nix. (Could be that I should instead treat this as an opensmalltalk-vm packaging that is "use at own risk" with pharo images.) Hopefully you see some value in keeping PharoLauncher. Perhaps I'll join you on nix after a while. It looks really interesting. But I can understand not wanting to overcommit. cheers -ben

April 20, 2017

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

by Ron Teitelbaum

The first thing I thought of was: | anArray | anArray := #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects'). (1 to: anArray size by: 2) collect: [:i | anArray at: i] All the best, Ron Teitelbaum On Thu, Apr 20, 2017 at 2:04 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Thu, Apr 20, 2017 at 12:17:35AM +0300, Yuriy Tymchuk wrote: > > I second the Peter???s idea. I don???t think that we need a dedicated > index-based select when we already have withIndex*. Also one year after > adding withIndexSelect: we can mine public repos and see how many projects > use the method and the selection block does not read the first (each) > parameter. > > > > Uko > > > > > On 20 Apr 2017, at 00:07, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > > > We already have > > > > > > * #withIndexCollect: > > > * #withIndexDo: > > > > > > > > > So why not #withIndexSelect: ? > > > > > > #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: > [ :each :i | i \\ 2 = 0 ] > > > > > > Peter > > +1 > > > >

April 20, 2017

Pharo 5 and retina displays in 2017?

by Tim Mackinnon

I mentioned this last year - and Iâm wondering if there is any news or developments on making Pharo look better on higher end hardware like Macbookâs and Dellâs? I keep dipping into Pharo but every time I see the blurry screen, it just takes away the shine for me (which is a bit sad)? Is Bloc getting much traction? Tim > On 23 Dec 2016, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks for the update - that is exciting and gives me some hope. > > What do we need to do to help bloc advance at pace? > > Tim > > Sent from my iPhone > > On 23 Dec 2016, at 01:22, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > >> Hi Tim, >> >> itâs coming, but it needs some time: https://twitter.com/aliakseisyrel/status/812065956856025088 <https://twitter.com/aliakseisyrel/status/812065956856025088> >>> On 1 Dec 2016, at 14:44, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> >>> To give people a better view of this - here is the Pharo image next to the mail client (Iâm not sure if the screen captures really do it justice as when you scale them down in a picture everything looks fine - however if I zoom into that bottom corner in a second image it might make it more obvious). >>> >>> I think this has been a problem brewing for a while, but if most contributors donât have retina screens (although they are getting much more common now) then I guess it goes unnoticed. I suspect in the next few years, as people start replacing machines - it will gain more visibility. >>> >>> I find it quite distracting when switching from mail or other apps to Pharo and then you notice the fuzziness. Maybe if you spend a few hours in the code you might adjust. >>> >>> Tim >>> >>> >>> >>> The following is the bottom corner zoom in to show what I mean by fuzzy: >>> >>> >>> <PastedGraphic-2.png> >>>> On 30 Nov 2016, at 23:53, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>>> >>>> On 30/11/16 20:32, Sven Van Caekenberghe wrote: >>>>> Maybe, but the thing is, you are looking at it half size, in some >>>>> sense, when it is on a Retina display. Anyway, to me, it is OK, but >>>>> my eyes are no longer what they used to be. I can imagine young >>>>> people being more sensitive to it. >>>> >>>> Nah, it just is blurry. I've played a bit with krono's vm, and it is >>>> a very noticable difference. Much better readable and less tiring. >>>> And you mostly only notice when trying to go back from HiDPI to low. >>>> >>>> Stephan >>>> >>>> >>> >>

April 20, 2017

Re: [Pharo-dev] Epicea should ask before recovering

by Denis Kudriashov

I as trying to write little tips. But I realized new issue 19957 <https://pharo.fogbugz.com/f/cases/19957/Sometime-Epicea-do-not-see-lost-cha…> 2017-04-20 3:34 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Wed, Apr 19, 2017 at 9:42 PM, Rajula Vineet <Vineet.Reddy(a)iiitb.org> > wrote: > >> Hi, >> >> I am interested in this issue. Maybe I will try adding this feature of a >> pop >> up when an image crashes, which asks 'do you want to recover your lost >> changes?' >> >> Rajula >> >> > Give it a go. > http://pharo.org/contribute-propose-fix > https://pharo.fogbugz.com/f/cases/19955/Epicea-should-ask- > before-recovering > > For approach, use "World menu > Tools > Finder > Source" > searching for the window title "Lost Changes Detected". > Drop a "self halt" at the top of that method. > Save the Image, then change any random method and Quit the image. > Next startup a debugger should open in the appropriate spot. > > ------- > > However a side question is, when someone goes "World menu > Quit" > should that be taken to mean they are throwing away outstanding changes? > > ------- > > Something else, I went to test previous behaviour of Lost Changes in Pharo > 5.0 > and I'm confounded by this behaviour. > > Preparation... > 1. Downloaded and uznipped http://files.pharo.org/ > platform/Pharo5.0-linux.zip > 2. From the command line, ran ./pharo > 3. Opened System Browser on random method EllipseMorph>>closestPointTo: > 4. Appended "aPoint + 0@0" and saved method. > 5. Save&Quit Image, then re-opened Image > > Test... > 6. Changed 0@0 to 1@1. > 7. At the command line, hit <CTRL-C> to crash-stop the image > 8. Re-open image > ==> Expect "Lost Changes" dialog but there is none. > Do I misremember the expected behaviour? > > This is the same with... > http://files.pharo.org/platform/Pharo2.0-linux.zip > > cheers -ben >

April 20, 2017

Spotter feature idea/request - exclusion filter

by Ben Coman

I had a poke at this but couldn't find my way into how Spotter filters work, so I'll just pass on the idea. Wanting to look at implementers of #withIndex* several tests are mixed in the result that it would be nice to eliminate by typing "subtract test" like this... " -test " much like I'd do in google search. cheers -ben

April 20, 2017