- Pharo-dev - lists.pharo.org

changing default theme to DarkTheme
by Esteban Lorenzano April 21, 2017

April 21, 2017

Hello guys, I wanted to let you know that we talked at the board and we want to make the DarkTheme a default for Pharo 6.0. This is just because we want to have a visual immediate reference of changing things (yeah, marketing ;) ) Those which still do not like it can still execute Pharo3Theme beCurrent. (in their startup actions, if you want) And everything will be as before. Esteban

18 73

In the quest of a new iterator :)
by Stephane Ducasse April 21, 2017

April 21, 2017

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

10 19

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm
by Ben Coman April 21, 2017

April 21, 2017

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

2 2

[pharo-project/pharo-core] 7bde98: 60468
by GitHub April 20, 2017

April 20, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7bde98ed1694390205b9b93c81ebfffc82ed2ff3 https://github.com/pharo-project/pharo-core/commit/7bde98ed1694390205b9b93c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-20 (Thu, 20 Apr 2017) Changed paths: A Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/basic-colors/errorPopperBackgroundColor.st M Glamour-Morphic-Widgets.package/GLMErrorPopper.class/instance/initialization/initializeTextMorph.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors/errorPopperBackgroundColor.st M Polymorph-Widgets.package/Pharo3Theme.class/instance/accessing colors/balloonBackgroundColor.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/basic-colors/errorPopperBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors/errorPopperBackgroundColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60467.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60468.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60467.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60468.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/README.md A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/bookName.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/open.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/pages.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/introduction.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/moreInformation.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step01.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step02.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step03.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step04.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step05.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/definition.st Log Message: ----------- 60468 19956 switching back to pharo3 theme has wrong tooltip color https://pharo.fogbugz.com/f/cases/19956 19937 Help for TravisIntegration https://pharo.fogbugz.com/f/cases/19937 19961 Impossible to read popup error in playground and Dark Theme https://pharo.fogbugz.com/f/cases/19961 http://files.pharo.org/image/60/60468.zip

1 0

[pharo-project/pharo-core]
by GitHub April 20, 2017

April 20, 2017

Branch: refs/tags/60468 Home: https://github.com/pharo-project/pharo-core

1 0

Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?
by Tim Mackinnon April 20, 2017

April 20, 2017

Adding this to the Dev user group - is there really no solution for this? I read a few old messages from 2012 about different fonts but nothing seemed to work from what I could see. Has everyone just been putting up with the fuzziness and got used to it? As a new Retina display user, I love the clarity in other apps and find it quite jarring in Pharo. I was going to do a brown bag session on Smalltalk with the current team Iâm working with, however as they all have retina Macs, I think I may reconsider this as unless you love the language its another thing for people to throw stones at. As Stephan mentions below, were Tobiasâ changes not viable? Is there anything we can do to help get them safely in - or can I try it on an experimental branch? Tim > On 29 Nov 2016, at 21:02, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 29/11/16 00:34, Tim Mackinnon wrote: >> Or is this still the same issue thatâs been hanging around for a long >> time as its hard to easily fix? > > Tobias Pape wrote some vm changes that solved the problem this summer, and they somehow interfered, so were reverted. I posted some pictures > on twitter 10/11-7 of it working with both Pharo & Squeak. > > Stephan > > > >> Hi Guys - its been a while since Iâve had a chance to get back into some coding in Smalltalk, and took the plunge again with a new laptop and Pharo 5, however the screen is really blurry? >> >> Doing a google search, I can see this same question raised back in 2012, but has there been no progress in this intervening years or has a workaround not been documented for google to find? Or has everyone just got used to it, and I need to hand in there... >> >> I have tried using a different font - but not sure what constitutes a true-type font (are these the same as free-type mentioned in the Settings Browser?). Has anyone found a font that makes everything look crisp (I tried Helvetica but its only marginally better). >> >> Or is this still the same issue thatâs been hanging around for a long time as its hard to easily fix? >> >> Tim

8 20

Epicea should ask before recovering
by Peter Uhnak April 20, 2017

April 20, 2017

Hi, can we modify epicea before asking for recovery? Because right now when I close image to intentionally throw away changes (because I managed to break the image or whatever), Epicea will freeze the image on startup for 10-15 seconds for even a mere 6-method change. (I also had it freeze for (couple) minutes on a rather big changeset...) Closing image and reopening is a very convenient way to get back to usable state of the image, so maybe a configuration option that would first prompt me "Epicea has detected lost changes, do you want to review them? <yes> <no>" would be nice. Of course if I am the only person that uses images in such a way then I can just work around it myself. (because having endless lists of config options is also nightmare) Peter

7 9

Spotter feature idea/request - exclusion filter
by Ben Coman April 20, 2017

April 20, 2017

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

1 0

[pharo-project/pharo-core] bf8db7: 60467
by GitHub April 20, 2017

April 20, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: bf8db76012347d23e7b9b78176aebbc6e9be413f https://github.com/pharo-project/pharo-core/commit/bf8db76012347d23e7b9b781… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-20 (Thu, 20 Apr 2017) Changed paths: A Komitter.package/Komitter.class/instance/announcement/unsubscribe.st A Komitter.package/KomitterUI.class/instance/private/windowIsClosing.st M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/accessing colors/borderColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60466.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60467.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60466.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60467.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/private/isMethodDefinition_.st M System-CommandLineHandler.package/PharoCommandLineHandler.class/README.md Log Message: ----------- 60467 19943 Error while browsing a comment un MessageBrowser https://pharo.fogbugz.com/f/cases/19943 19945 PharoCommandLineHandler class comments incorrect https://pharo.fogbugz.com/f/cases/19945 19954 Komitter should explicitly unsubscribe form SystemAnnoucer when window is closed https://pharo.fogbugz.com/f/cases/19954 19941 Dark Theme - overlapped title bars need to be distinctive https://pharo.fogbugz.com/f/cases/19941 http://files.pharo.org/image/60/60467.zip

1 0

[pharo-project/pharo-core]
by GitHub April 20, 2017

April 20, 2017

Branch: refs/tags/60467 Home: https://github.com/pharo-project/pharo-core

1 0