- Pharo-dev - lists.pharo.org

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

by Max Leske

On 06.03.2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote: >> I donât quite follow. What do you mean by methods? > > When mapping methods to files, there is the problem that on disk files take a minimum amount of space, > often 4KB. This slows writing a package to disk down a lot. I see. There are two things to consider: 1. the format we use to store source 2. the fact that Git will create one blob per file Obviously, by choosing a source storage format that avoids this problem, we donât have to deal with the second issue. If you go with something like FileTree, which uses a single file per method, this changes. By combining multiple files (e.g. by zipping) we could avoid the problem of tiny blobs but we would loose the ability to look at the repository from the outside. This is something I donât want to do. It creates a dependency to Pharo (and to the particular implementation of how those files are stored) and unneeded complexity (especially with regard to maintenance). In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. So yes, potentially we could do something about fragmentation but I wonât promise you anything. Does that answer your question? Cheers, Max > > Stephan > > >

March 6, 2014

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

by Stephan Eggermont

Max wrote: >I donât quite follow. What do you mean by methods? When mapping methods to files, there is the problem that on disk files take a minimum amount of space, often 4KB. This slows writing a package to disk down a lot. Stephan

March 6, 2014

Re: [Pharo-dev] AST-Interpreter on CI is green

by ClÃ©ment Bera

Thanks for fixing it. Tthe tests are green but last time I tried the regression tests (package AST-Interpreter-PharoTest) were failing. 2014-03-06 13:18 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > 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] Support for git in Pharo

by Max Leske

On 06.03.2014, at 15:04, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote: >> Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a >Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where >we can start doing something with it. > > That sounds good. I happen to have older git versions which no longer work after upgrading to Mavericksâ¦ > > Will that allow us to avoid the filesystem bottleneck for large packages where minimum disk block size for methods is much larger than the actual method size? I donât quite follow. What do you mean by methods? > > Stephan

March 6, 2014

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

by Stephan Eggermont

Max wrote: >Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a >Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where >we can start doing something with it. That sounds good. I happen to have older git versions which no longer work after upgrading to Mavericksâ¦ Will that allow us to avoid the filesystem bottleneck for large packages where minimum disk block size for methods is much larger than the actual method size? Stephan

March 6, 2014

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

by Goubier Thierry

Le 06/03/2014 14:15, Max Leske a Ã©crit : > Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where we can start doing something with it. Yes, this is interesting. I've also considered bundling a static version of the git command line. > For people interested, there is a Smalltalk-Git mailing list on google groups: https://groups.google.com/forum/?hl=de#!forum/smalltalk-git Thanks, I registered :) 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

Re: [Pharo-dev] [Vm-dev] Time primitive precision versus accuracy (was: strange time / delay problems on pharo-contribution-linux64-4.ci.inria.fr

by David T. Lewis

On Thu, Mar 06, 2014 at 01:39:24PM +0100, Max Leske wrote: > > > 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). > No, this is probably not related to the problem that you reported with delay processing in Pharo 3.0. The time values reported by primUTCMicrosecondClock are perfectly valid. I am just discussing how the accuracy of those values might be improved, particularly in light of the implied precision. The image needs to behave reasonably with the time values reported by the primitive, regardless of their accuracy or precision. Dave

March 6, 2014

Re: [Pharo-dev] About inspectors

by btc＠openinworld.com

Pharo4Stef wrote: > Ok we should think about that for 40. > > Stef > A low impact option (that may even be reasonable to slip into Pharo 3.0) would be to make the first 'c' capital so that the distinction is observed at the start of the line rather than the end. For example evaluating: #(1 2 3) inspect... self: (# 12 3) class: Array > Class: Array class > superclass: MenuItemMorph Another option, rather than a green (C) icon, how about an (M) icon of another colour - for "meta" cheers -ben may be to make the > On 06 Mar 2014, at 04:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > >> Pharo4Stef wrote >> >>> I found that confusing to get mixed self/class/allinstvars and the >>> instVar. >>> >> Yes, I still haven't gotten used to this. Also, that the selected node is >> not the receiver anymore - forces me to pop up extra inspectors :/ >> >> >> >> ----- >> Cheers, >> Sean >> -- >> >>

March 6, 2014

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

by Max Leske

Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where we can start doing something with it. For people interested, there is a Smalltalk-Git mailing list on google groups: https://groups.google.com/forum/?hl=de#!forum/smalltalk-git Cheers, Max On 06.03.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] About inspectors

by Pharo4Stef

Ok we should think about that for 40. Stef On 06 Mar 2014, at 04:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Pharo4Stef wrote >> I found that confusing to get mixed self/class/allinstvars and the >> instVar. > > Yes, I still haven't gotten used to this. Also, that the selected node is > not the receiver anymore - forces me to pop up extra inspectors :/ > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/About-inspectors-tp4747815p4747957.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 6, 2014