- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Stephan Eggermont

On 10-11-15 08:00, stepharo wrote: > Thanks I assume you want it working in Pharo5? There was no #'pharo5.x' Name: ConfigurationOfSPort2-StephanEggermont.16 Author: StephanEggermont Time: 10 November 2015, 10:01:56.039515 am UUID: 0c712020-3d22-405b-9842-3106b6b9721f Ancestors: ConfigurationOfSPort2-StephanEggermont.15 In-place pharo5 version added

Nov. 10, 2015

Re: [Pharo-dev] Is RBRefactoryChange alive, and what do I use for recategorization

by Max Leske

Martin has been working on change reification to manage history. Iâm not sure however, if thatâs been integrated. CCâd to Martin. > On 06 Nov 2015, at 15:25, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi everyone. > > in my critic projects I need a concept of a âchangeâ the can be previewed, executed or combined with other changes. I.e. if a critic can propose an automated solution, it has to be _something_. At the moment Iâve started to use RBRefactoryChange, but I want to know whether it is the thing to use, or maybe someone is preparing a replacement. Because classes have no comments. no real diff support and so onâ¦ > > If it is the thing to use, which change should I use for a recategorization (change protocol) of a method? > > Thanks. > Uko

Nov. 10, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by stepharo

Thanks Le 10/11/15 01:43, Stephan Eggermont a Ã©crit : > http://smalltalkhub.com/#!/~Sport/Sport > > Stephan > > >

Nov. 10, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Stephan Eggermont

http://smalltalkhub.com/#!/~Sport/Sport Stephan

Nov. 10, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Esteban A. Maringolo

If Swazoo is available, I guess Sport will be too because it depends on it. Regards! Esteban A. Maringolo

Nov. 9, 2015

Does anybody know if Sport is available in Pharo?

by stepharo

Nov. 9, 2015

Re: [Pharo-dev] Ubuntu fullscreen problems

by J.F. Rick

Works like a charm: both toggling modes and using the Unity pager to switch workspaces. Thanks! Jeff On Sun, Nov 8, 2015 at 6:40 PM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 2015-10-28 20:14 GMT+01:00 J.F. Rick <self(a)je77.com>: > >> Cool. I guess if there is a bug report on squeak then there is no reason >> to create one on pharo. If you need someone to test a solution on Ubuntu >> 15.10, let me know. >> > > Hi Jeff, > > can you check this version, it works for me on > > DISTRIB_ID="elementary OS" > DISTRIB_RELEASE=0.3.1 > DISTRIB_CODENAME=freya > DISTRIB_DESCRIPTION="elementary OS Freya" > > > https://drive.google.com/file/d/0B8yEahnuIem2VGJlejJpUjZfZHc/view?usp=shari… > > it should work on Ubuntu, but I don|t have Ubuntu 15 installed. > > > > >> >> On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> 2015-10-28 15:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>>> I think there must be some incompatibility between Pharo and the host >>>> window manager/desktop environment. >>>> >>>> On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but not (2). >>>> >>>> There is however interesting behavior... if I try to switch desktop >>>> while in fullscreen it doesn't switch, however once I switch back to >>>> non-fullscreen, suddenly I jump to the other desktop, as if the keyboard >>>> shortcut for the switch got buffered somewhere... >>>> >>>> Opening a issue in FogzBugz is a good idea so it doesn't get forgotten. >>>> >>>> Peter >>>> >>>> On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick <self(a)je77.com> wrote: >>>> >>>>> Hi everybody, >>>>> >>>>> I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I >>>>> want Pharo to use the full screen (i.e., above the menu bar and launcher). >>>>> Inside Pharo, I can choose "Toggle full screen mode". This works to some >>>>> extent but has some problems: >>>>> >>>>> (1) I can no longer switch applications or desktops (i.e., pager). So >>>>> it stops me doing work where I move between Pharo and a browser. This may >>>>> be expected functionality. >>>>> >>>>> (2) More problematically, when I try to switch out of full screen mode >>>>> by choosing "Toggle full screen mode", the Pharo interface completely >>>>> disappears (just a giant gray area) and no mouse or keyboard events seem to >>>>> register. I have to use command line to kill it. In good news, I can use >>>>> "save and quit" instead and relaunching it just has it in maximum mode >>>>> (full screen but launcher and menu bar are visible). I can then toggle full >>>>> screen mode twice to get back to full screen. >>>>> >>>>> I searched for this on FogBugz but found nothing. Is there a >>>>> workaround? This seems like a VM issue. Is there a newer VM that fixes >>>>> this? I just used the most recent one on the Pharo 4.0 download page. >>>>> >>>>> If nobody has a fix, I'll open a case on FogBugz. This isn't a large >>>>> problem but it would be nice to have this >>>>> >>>> >>> It is a know problem (with possible fixes) >>> (http://bugs.squeak.org/view.php?id=7812) >>> You can not switch back from fullscreen on a linux 64-bit system ( >>> http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit issue, >>> but just the more recent windowmanager) >>> >>> >>> >>>> >>>>> Cheers, >>>>> >>>>> Jeff >>>>> >>>> >>>> >>>

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

Submitted a FileTree bug[1] for this ... I think this is more a function of FileTree than Metacello ... but I have to uncover the "cypress fix" and then think about the best place to make the fix .... Dale [1] https://github.com/dalehenrich/filetree/issues/166 On 11/9/15 5:27 PM, Dale Henrichs wrote: > > > On 11/9/15 5:08 PM, Thierry Goubier wrote: >> Hi Dale, >> >> I'm back at that again. >> >> And I think that Metacello is already failing with repositories that >> have true branches (git + filetree). Metacello delegates to >> Monticello which rely on full ordering to establish upgrades or >> loading preferences. And on repositories with branches, each branch >> has its own ordering, making upgrades a possible problem (such as >> switching to a new branch with a new version and discover there that >> the top of that branch has a lower version number than the previous >> version == no load). > Hmmm ... I can see that this could happen ... >> >> Granted, this is less probable, but could surprise... > I don't like surprises:) >> >> Now, if Metacello could use the semantic versionning present in the >> Configurations and Baselines... > Semantic versioning is only used in ConfigurationOf subclasses ... the > notion with git is that the branch should be loaded whether or not it > is an "Monticello package upgrade" or not... I'll have to think on > this one a bit .... I'm in Buenos Aires for Smalltalks this week ... > but I consider this to be somewhat of a major bug, given that folks > are moving more and more to git .... it may be as "simple" as turning > on the "cypress url" for all FileTree repos .... but I want to think > through this one a bit more ... > > Dale >

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

On 11/9/15 5:08 PM, Thierry Goubier wrote: > Hi Dale, > > I'm back at that again. > > And I think that Metacello is already failing with repositories that > have true branches (git + filetree). Metacello delegates to Monticello > which rely on full ordering to establish upgrades or loading > preferences. And on repositories with branches, each branch has its > own ordering, making upgrades a possible problem (such as switching to > a new branch with a new version and discover there that the top of > that branch has a lower version number than the previous version == no > load). Hmmm ... I can see that this could happen ... > > Granted, this is less probable, but could surprise... I don't like surprises:) > > Now, if Metacello could use the semantic versionning present in the > Configurations and Baselines... Semantic versioning is only used in ConfigurationOf subclasses ... the notion with git is that the branch should be loaded whether or not it is an "Monticello package upgrade" or not... I'll have to think on this one a bit .... I'm in Buenos Aires for Smalltalks this week ... but I consider this to be somewhat of a major bug, given that folks are moving more and more to git .... it may be as "simple" as turning on the "cypress url" for all FileTree repos .... but I want to think through this one a bit more ... Dale

Nov. 9, 2015

Re: [Pharo-dev] [ANN] No-Metadata mode for GitFileTree

by Dale Henrichs

On 11/8/15 2:04 PM, Thierry Goubier wrote: > Le 08/11/2015 17:41, Dale Henrichs a Ã©crit : >> >> >> On 11/7/15 10:00 AM, Thierry Goubier wrote: >>> Oh yes, >>> >>> I can announce that from now on, the development version of >>> GitFileTree for Pharo 5 handles FileTree repositories without most of >>> the metadata (precisely version and methodProperties). >>> >>> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, >>> all...) by cutting the noise on diffs and conflicts on merge and >>> cherry picking. >>> >>> Note: it only apply to brand new repositories; nothing is changed for >>> pre-existing ones. >>> >>> Note2: reading those Metadata-less repositories with FileTree does >>> give you packages without metadata: no version history, no author, no >>> author nor timestamp on methods. >>> >>> Note3: it is possible to hack a repo from metadata to non-metadata >>> mode, but I won't explain it. >>> >>> Enjoy and tell me how it works for you. I'm especially interested by >>> heavy branchers/mergers reports :) >>> >>> Thierry >>> >> Thierry, >> >> You want to double check that Metacello works correctly with these >> metadata-less packages ... if you are continuing to increment the >> "package version" there shouldn't be a problem, but when I did a similar >> experiment a year or so ago, I found that I had to teach Metacello to >> ignore the "package version" and load the package anyway ... the normal >> procedure for Monticello packages and Metacello is not load a package if >> the "package version" is less than or equal to the package already >> loaded .... I did make an extension to Metacello to make this work .... >> I can hunt it up if needed and make it part of the standard release (I >> may have kept it as part of tODE) ... > > Hi Dale, > > GitFileTree without metadata on disk does not mean no metadata for > Monticello/Metacello to work with; as long as you reach the git log > info, then it will work exactly as usual (incrementing version > numbers, etc...), with the usual caveats (i.e., if you limit depth > when cloning with git, version numbers do change). > > However, when accessing via FileTree (for example github:// urls), > then, yes, version numbers become 1. > > It will only matter when updating an already loaded project via a > github:// or bitbucket:// url. And there, simply allowing Metacello to > load if repository version is >= to existing version should take care > of it. This is the sticky wicket ... what I did to "solve the problem" was to define a Cypress url (I think) that would arrange for the proper loading to take place (ignore monticello meta data and load unconditionally) .... this sounds bad, but Monticello is smart enough to only load the changed definitions, so loading the same package over and over will not load anything ... you do get the overhead of ccreating definitions from disk ... but that might not be as big a deal these days ... > > I have an idea of possible solutions. We'll see how it goes and solve > that when we'll have a serious push around git ;) Agreed ... I just wanted to point out this potentially surprising tidbit:) Dale

Nov. 9, 2015