- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Support for git in Pharo

by Sven Van Caekenberghe

There is no direct support for git in Pharo, AFAIK. There is Monticello FileTree support, a portable way to write MC packages to any filesystem. This can then and is used to work with classic version control systems, like git. There are very nice add on libraries offering more support and integration. Using git for any language/project will require installation of git, this is certainly not unique for Pharo, nor should we solve that problem. On 06 Mar 2014, at 13:59, Stephan Eggermont <stephan(a)stack.nl> wrote: > How is git support for Pharo going to work? > Because currently it takes extra effort. > I noticed some Pharo users moving their code to > github, making it less accessible. > > I know a few different ways to get git installed on a mac: > (finkproject, brew, macports, xcode, git-osx-installer, git-scm.com) > and they result in git not always being /usr/bin/git. > Then there are the differences between system wide installs > and installs for specific users, and the different OS versions. > > Stephan > > >

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Goubier Thierry

Le 06/03/2014 13:59, Stephan Eggermont a Ã©crit : > How is git support for Pharo going to work? > Because currently it takes extra effort. > I noticed some Pharo users moving their code to > github, making it less accessible. > > I know a few different ways to get git installed on a mac: > (finkproject, brew, macports, xcode, git-osx-installer, git-scm.com) > and they result in git not always being /usr/bin/git. > Then there are the differences between system wide installs > and installs for specific users, and the different OS versions. gitfiletree: does not depend on /usr/bin/git; it requires a git command somewhere on $PATH. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 6, 2014

Support for git in Pharo

by Stephan Eggermont

How is git support for Pharo going to work? Because currently it takes extra effort. I noticed some Pharo users moving their code to github, making it less accessible. I know a few different ways to get git installed on a mac: (finkproject, brew, macports, xcode, git-osx-installer, git-scm.com) and they result in git not always being /usr/bin/git. Then there are the differences between system wide installs and installs for specific users, and the different OS versions. Stephan

March 6, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Goubier Thierry

Ok, I see now. I don't think this can be avoided; it's inherent in the way both github: and gitfiletree: understand repositories. The explanation will go a bit into git and gitfiletree design and FileTree; in the mean time, you may either change a bit the config to clean that (force a load of the last version from gitfiletree, since they are effectively the same) or don't bother, gitfiletree: when saving a new package version will clear that (sort of). The explanation is a bit long. version metadata for FileTree (the format used to write packages for git and others version control systems) is stored in a file under PackageName.package/monticello.meta/versions. This file is often a problem, at least under git: it's a magnet for git merge conflicts. It is also slow to parse[1], especially if you want to know all the versions of the package stored by the git repository (as gitfiletree does), and sometimes is corrupted (git conflicts). So, in the design of gitfiletree:, I decided that I would not read this file, but, instead, recreate its contents from the git log history[2]. This is what you see when you open a gitfiletree: repository. And particularly, versions UUIDs are generated from the git commit ID[3]. Now, when saving a package in a gitfiletree: repository, the versions file will be written, with an UUID generated for it... except that, on rereading, gitfiletree will generate another UUID from the git commitID (which is known, of course, after committing the versions file :() For example, in gitfiletree:, Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 Whereas the file Renraku.package/monticello.meta/versions has Renraku-YuriyTymchuk.4 with id '60141668-a324-4c9d-8938-db82ed2e57de' Older versions are regenerated from the git data, and this is why, in that file, you see Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) [1] Yes, and I tried long and hard to accelerate reading and parsing 200 times the versions file for a moderatly complex project, including the fact that it's easy to find a corrupted versions file in a git repo. Generating ended up a lot cleaner, as well as garanteeing than the history would be browsable. [2] And filtering the git history to keep only the commits significant for the package, and nothing else. [3] Constant mapping: a given git commitID will allways generate the same UUID. Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : > > On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>> wrote: > >> >> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> wrote: >> >>> >>> >>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr >>>>> <mailto:thierry.goubier@cea.fr>> wrote: >>>>> >>>>> >>>>> >>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >>>>>> >>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : >>>>>>>> Hi guys. >>>>>>>> >>>>>>>> My workflow is like this: >>>>>>>> >>>>>>>> I load a configuration on CI with github:// magic in metacello conf. >>>>>>>> Then on local machine I add a local gitfiletree repo to the >>>>>>>> project packages. >>>>>>> >>>>>>>> The thing is that the last version if loaded, but gitfiletree >>>>>>>> repo is showing that second last is loaded. And yes, diffs with >>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and >>>>>>>> diffs with second last (current one by gitfiletree opinion) show >>>>>>>> changes that were mede in last version. >>>>>>> >>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, >>>>>>> .3, and .4 , like that? >>>>>> >>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". >>>>> >>>>> Are changes shown when you click on the .5 version in gitfiletree? >>>>> on the .4 version in gitfiletree as well? >>>> >>>> Version 5 does not have changes with working copy. While version 4 >>>> has. So from my point of view it seams like version 5 is loaded but >>>> gitfiletree thinks that only version 4 is loaded. >>> >>> Understood. Is it a problem if I have a look at the image or at the >>> git repository? >> >> When I look in the monticello browser in the image. > > And with applies to the both packages I have in that repo > >> >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 6, 2014

Re: [Pharo-dev] Vm-dev Digest, Vol 93, Issue 9

by Max Leske

On 06.03.2014, at 13:00, vm-dev-request(a)lists.squeakfoundation.org wrote: > Date: Wed, 5 Mar 2014 19:59:17 -0500 > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: [Vm-dev] Time primitive precision versus accuracy (was: > [Pharo-dev] strange time / delay problems on > pharo-contribution-linux64-4.ci.inria.fr > To: Squeak Virtual Machine Development Discussion > <vm-dev(a)lists.squeakfoundation.org> > Message-ID: <20140306005917.GA6980(a)shell.msen.com> > Content-Type: text/plain; charset=us-ascii > > On Tue, Mar 04, 2014 at 03:13:26PM -0800, Eliot Miranda wrote: >> >> On Tue, Mar 4, 2014 at 2:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> There is a big difference in how DateAndTime class>>#now works in 2.0 vs >>> 3.0. The former uses #millisecondClockValue while the latter uses >>> #microsecondClockValue. Furthermore 2.0 does all kind of crazy stuff with a >>> loop and Delays to try to improve the accuracy, we threw all that out. >>> >>> Yeah, I guess the clock is just being updated slowly, maybe under heavy >>> load. The question is where that happens. I think in the virtualised OS. >>> >> >> That makes sense. In the VM the microsecond clock is updated on every >> heartbeat and the heartbeat should be running at about 500Hz. Can anyone >> with hardware confirm that in 3.0 the time on linux does indeed increase at >> about 500Hz? >> >> Note that even in 2.0 the time is being derived from the same basis. In >> Cog, the effective time basis is the 64-bit microsecond clock maintained by >> the heartbeat and even the secondClock and millisecondClock are derived >> from this. So its still confusing why there should be such a difference >> between 2.0 and 3.0. >> > > The separate thread for timing may be good for profiling, but it is not such > a good idea for the time primitives. When the image asks for "time now" it > means now, not whatever time it was when the other thread last took a sample. > By reporting the sampled time, we get millisecond accuracy (or worse) reported > with microsecond precision. > > If you collect primUTCMicrosecondClock in a loop with the primitive as > implemented in Cog, then plot the result, you get a staircase with long > runs of the same time value, and sudden jumps every one and a half milliseconds > or so. The equivalent plot for the primitive as implemented in the interpreter > VM is a smoothly increasing slope. > > To illustrate, if you run the example below with Cog to collect as many > "time now" data points as possible within a one second time period, you find > a large number of data points at microsecond precision, but only a small number > of distinct time values within that period. > > "Cog VM" > oc := OrderedCollection new. > now := Time primUTCMicrosecondClock. > [(oc add: Time primUTCMicrosecondClock - now) < 1000000] whileTrue. > oc size. ==> 2621442 > oc asSet size. ==> 333 > > In contrast, an interpreter VM with no separate timer thread collects fewer samples > (because it is slower) but the sample values are distinct and increase monotonically > with no stair stepping effect. > > "Interpreter VM" > oc := OrderedCollection new. > now := Time primUTCMicrosecondClock. > [(oc add: Time primUTCMicrosecondClock - now) < 1000000] whileTrue. > oc size. ==> 246579 > oc asSet size. ==> 246579 Wow, I didnât know that. But can that account for a delay not being executed (or prematurely terminated)? In the example I posted, the 10 second delay takes no time at all (second precision unfortunately because of the division by 1000). Max > > Dave

March 6, 2014

What happened with petitmarkdown?

by Stephan Eggermont

Camillo, While fixing some ci builds, I noticed that at least some of your smalltalkhub repositories are empty (petitmarkdown, ast-interpreter). What happened with the code? ast-interpreter I could find back, but petitmarkdown not. Stephan

March 6, 2014

AST-Interpreter on CI is green

by Stephan Eggermont

The build was red, referring to dh83/ast-Interpreter (empty). Changed the config to use Pharo/AST-Interpreter Stephan

March 6, 2014

Re: [Pharo-dev] Where are the Pharo sources?

by Sebastian Sastre

+1 thanks for the feeback sebastian o/ > On 06/03/2014, at 06:05, "Oscar Nierstrasz @ gmail" <oscar.nierstrasz(a)gmail.com> wrote: > > > Thanks everyone. > > I was confused because the Pharo download page sez: "When downloads are completed, uncompress all files and put them into the same directory (this directory should then contain a .image, .changes, and a .sources file)." > > http://www.pharo-project.org/pharo-download > > But the downloads on this page don't contain the sources. > > So, either the downloads should be updated to include the sources, or the page should be updated to indicate where the sources can be downloaded. An explicit link to http://files.pharo.org/sources/ would do the trick. > > Cheers, > Oscar > >> On Mar 5, 2014, at 15:43 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Oscar, >> >> I am not sure what exactly you downloaded, there are so many options, but sources now come with the VM. >> >> Otherwise, you can find them here: >> >> http://files.pharo.org/sources/ >> >> Sven >> >>> On 05 Mar 2014, at 15:38, Oscar Nierstrasz @ gmail <oscar.nierstrasz(a)gmail.com> wrote: >>> >>> >>> Oh, I did find the PharoV20.sources in the latest Moose download, but I guess they should be available from the Pharo project page ... >>> >>> Oscar >>> >>>> On 5 Mar 2014, at 15:36, "Oscar Nierstrasz @ gmail" <oscar.nierstrasz(a)gmail.com> wrote: >>>> >>>> >>>> Just downloaded the latest Pharo image from the project page. I can find the VM, image and changes files, but no sources. >>>> >>>> I tried various older downloads too, but I can't find them anywhere? >>>> >>>> Can anyone fix it? >>>> >>>> Oscar > >

March 6, 2014

Re: [Pharo-dev] TWM and 3.0: icons/themes, UpdatingMenuMorph

by phil＠highoctane.be

And of course, the TWMUI Theme doesn't work at all anymore... Is there some info about how the new theming works in 3.0? TIA Phil On Thu, Mar 6, 2014 at 12:00 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I am trying to get TWM to work in 3.0 > > I use the Metacello config flag "trick" to make it load 2.x things. > > Now, things do load but there is the deprecation warnings about the way > icons are handled. > > e.g. > > deleteSnapshotIcon > ^ dock theme smallDeleteIcon. > > gives a warning. > > I looked into the code and now, we are supposed to do: > > Smalltalk ui smallDeleteIcon. > > Well, I changed the things that needed to be changed and then hit: > > newMenu: aSelector icon: aForm help: aString > ^ MenuItemMorph new > contents: ''; > subMenu: (UpdatingMenuMorph new updater: self updateSelector: aSelector); > icon: aForm; > setBalloonText: aString. > > Where Updating MenuMorph appears to be gone in 3.0 > > What am I supposed to use as a replacement? > > TIA > > Phil > > >

March 6, 2014

TWM and 3.0: icons/themes, UpdatingMenuMorph

by phil＠highoctane.be

I am trying to get TWM to work in 3.0 I use the Metacello config flag "trick" to make it load 2.x things. Now, things do load but there is the deprecation warnings about the way icons are handled. e.g. deleteSnapshotIcon ^ dock theme smallDeleteIcon. gives a warning. I looked into the code and now, we are supposed to do: Smalltalk ui smallDeleteIcon. Well, I changed the things that needed to be changed and then hit: newMenu: aSelector icon: aForm help: aString ^ MenuItemMorph new contents: ''; subMenu: (UpdatingMenuMorph new updater: self updateSelector: aSelector); icon: aForm; setBalloonText: aString. Where Updating MenuMorph appears to be gone in 3.0 What am I supposed to use as a replacement? TIA Phil

March 6, 2014