December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by kilon alios

yes I am aware of git documentation thus I mention it in my video tutorial On Wed, Dec 3, 2014 at 2:26 PM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > >> I dont disagree but when it comes to me making a tutorial about something >> then foremost I want to know exactly what I am talking about. So its >> pointless for me to talk about merges using filetree and gitfiletree unless >> I understand these specific topic inside out. >> I dont have a problem getting a phd, I am a bookworm by nature anyway and >> I love learning. I am not saying also that tools are not needed to make >> things easier, obviously if tools make life easier then I am all for using >> them. But I need to make sure first that the tools you guys make work well >> in practice to recommend them to my viewers. Thats how serious teaching >> works. So I think for now would be better if I get more experience with >> merges as Thierry said and study more the internals of git. >> > > You may have seen this already... > http://git-scm.com/book/en/v1/Git-Internals > > > So far all I knew that using git for binary files was a no go, doable but >> not recommended. Thus I found strange that filetree uses binary files. >> On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> >> wrote: >> >> >> >> On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> >> >> "The important take-away from this is that when working with git >> and Smalltalk you must track the SHA that has been loaded into >> the image (the latest version of Metacello tracks this >> information in the project registry) and you must have in-image >> tool support for recognizing SHA skew. It's not absolutely >> necessary to provide a tool for `skew save`, but it _is_ tedious >> to "merge your way out of trouble" manually and in-image tools >> make this situation much more tolerable ..." >> >> well I have to confess all this is way out of my league :D >> >> Haha ... and that's the point ... with tool support you don't have >> to be "in that league":) >> >> >> As I said before I have done some merges with git, but nothing >> so complex to require knowing all this stuff. But then I work >> mostly on my own small projects and not in large teams. >> >> FWIW, I was getting myself into this trouble, by working in multiple >> images that were distributed over time ... I would come back to an >> older image and discover that I'd updated one of my shared projects >> and I had modifications to that project that I wanted to save ... >> Tools are supposed to help people who do not have a PHD in git and >> not get in the way of those who do:) >> >> Dale >> >> >> > >

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Ben Coman

Eliot Miranda wrote: > > [and apologies for being deliberately incendiary but I *hate* the > movement away from tools in Squeak/Pharo. It is a movement towards > stasis and death, and personally I'm enjoying life too much]. So what we need is a native Smalltalk git ;) Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully) Javascript https://github.com/creationix/js-git Java http://eclipse.org/jgit/ Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit Python https://www.samba.org/~jelmer/dulwich/ Perl https://metacpan.org/pod/Git::PurePerl

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Tudor Girba

Exactly! This is what I was looking for :) Thanks, Doru On Wed, Dec 3, 2014 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > One we did for Pharo4 is to use the Associations of Globals to model these > variables as meta-objects (in the same spirit as the Slot objects). > > Thos means that > -> there is an Api to get them > -> they have an API to read /write > > This is just âsugarâ on what the associations did already: > > global := SmalltalkImage classVariableNamed: #CompilerClass. > global read. > global class > ==> ClassVariable > > > Having objects for concepts like this allows of course to leverage the > power of > the toolsâ¦ e.g. this adds an inspect pane that shows all users of > variables: > > 14562 add a Users tab to GTInspector for Slots and LiteralVariables > https://pharo.fogbugz.com/f/cases/14562 > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 3, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Ben Coman

kilon alios wrote: > I dont disagree but when it comes to me making a tutorial about > something then foremost I want to know exactly what I am talking about. > So its pointless for me to talk about merges using filetree and > gitfiletree unless I understand these specific topic inside out. > > I dont have a problem getting a phd, I am a bookworm by nature anyway > and I love learning. I am not saying also that tools are not needed to > make things easier, obviously if tools make life easier then I am all > for using them. But I need to make sure first that the tools you guys > make work well in practice to recommend them to my viewers. Thats how > serious teaching works. So I think for now would be better if I get more > experience with merges as Thierry said and study more the internals of > git. You may have seen this already... http://git-scm.com/book/en/v1/Git-Internals > So far all I knew that using git for binary files was a no go, > doable but not recommended. Thus I found strange that filetree uses > binary files. > > On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > > "The important take-away from this is that when working with git > and Smalltalk you must track the SHA that has been loaded into > the image (the latest version of Metacello tracks this > information in the project registry) and you must have in-image > tool support for recognizing SHA skew. It's not absolutely > necessary to provide a tool for `skew save`, but it _is_ tedious > to "merge your way out of trouble" manually and in-image tools > make this situation much more tolerable ..." > > well I have to confess all this is way out of my league :D > > > Haha ... and that's the point ... with tool support you don't have > to be "in that league":) > > > As I said before I have done some merges with git, but nothing > so complex to require knowing all this stuff. But then I work > mostly on my own small projects and not in large teams. > > > FWIW, I was getting myself into this trouble, by working in multiple > images that were distributed over time ... I would come back to an > older image and discover that I'd updated one of my shared projects > and I had modifications to that project that I wanted to save ... > > Tools are supposed to help people who do not have a PHD in git and > not get in the way of those who do:) > > Dale > >

Dec. 3, 2014

Re: [Pharo-dev] for opal compiler developer: issue on calculating the frameSize

by Marcus Denker

I will have a look later this weekâ¦ > On 29 Nov 2014, at 11:14, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I uploaded a cs fix_closure_stack_frame_size_computation for this issue > 13854 <https://pharo.fogbugz.com/default.asp?13854> > frameSize calculated wrongly for #lineSegmentsDo: ! > > It is not meant as a fix but to show and make it easier to understand where > the bug is. I don't like this fix because it looks like > "fixing the right bug at the wrong place" > > About the issue: > It is all about calculating the correct stack frame size for a compiled method > (compiledmethod>>#header) > With opal, the result is sometimes larger than it is needed > or to small (strangly enough, although we have *some* methods with > a too small stack frame, a vm crash only happens for me if I am stepping > through the method with the debugger). > > The needed stack frame size is calculated from the > numTemps (arguments + number of temporaries) + the max stack depth > *and* if the method defines any blocks the methods stack frame size is > the maximum of > - its own needed stack frame size > - all of its blocks needed stack frame sizes. > > (And what makes this calculation a little bit tricky, the methods arguments > and tempvars, although it looks like that, > don't influence the stack frame size for the blocks. Every block context starts > with its own stack) > > nicolai > >

Dec. 3, 2014

Athens and ellipse drawing (again)

by Nicolai Hess

background: forum.world.st/Athens-and-ellipse-drawing-td4754256.html drawing an ellipse by drawing a non-uniform-scaled circle works, but the border is scaled as well. in Roassal2, ellipse shapes always use a small 1px border (https://code.google.com/p/moose-technology/issues/detail?id=1097) As described in the above 2 threads, it is possible to draw an ellipse with uniform border with cairo, and it is possible to do this with athens, although athens does not provide this as a public api. A much easier solution than the one I suggested in https://code.google.com/p/moose-technology/issues/detail?id=1097 is to use athens "paintTransform". We need to add AthensCairoCanvas>>setPaintMatrix (similiar to setPathMatrix) and call this in AthensCairoStrokePaint>>#athensFillPath:on: self prepareForDrawingOn: aCanvas. aCanvas newPath; loadPath: aPath; setPaintMatrix; "< --- new" stroke what do you think? Nicolai

Dec. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 3, 2014

[pharo-project/pharo-core] 4035b4: 40397

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 4035b411d8b30af9d9482d9ccad7532a91afd714 https://github.com/pharo-project/pharo-core/commit/4035b411d8b30af9d9482d9c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-03 (Wed, 03 Dec 2014) Changed paths: M AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st A OpalTools.package/extension/LiteralVariable/instance/gtInspectorUsersIn_.st A OpalTools.package/extension/Slot/instance/gtInspectorUsersIn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script397.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40397.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/GlobalVariable.class/instance/as yet unclassified/definingClass.st A Slot.package/GlobalVariable.class/instance/queries/definingClass.st Log Message: ----------- 40397 14033 Failing test: AJx64AssemblerTests>#testStringOps64Mnemonics https://pharo.fogbugz.com/f/cases/14033 14562 add a Users tab to GTInspector for Slots and LiteralVariables https://pharo.fogbugz.com/f/cases/14562 http://files.pharo.org/image/40/40397.zip

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Esteban Lorenzano

> On 03 Dec 2014, at 04:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do. why is better? I need more than an opinion there, because my own opinion is that is the contrary :) Esteban

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Esteban Lorenzano

> On 03 Dec 2014, at 08:21, stepharo <stepharo(a)free.fr> wrote: > > > Le 2/12/14 21:02, kilon alios a Ã©crit : >> I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest. >> >> What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language. > > Monticello is like that too. > A decentralized version management system yes, but is a decentralised management system in a way that does not scales in team work (not a problem of monticello, all cms of the time had same problem). They are ok with centralised ways of work (even if decentralised systems): all responsibility is in contributor, so you end having to centralise access rights (this is ok for lots of people, but welllâ¦ not in open source models that wants to grow from âjust some contributorsâ). The real advantage of git is the model it allows: you have a repository that everybody can fork and when ready, they can do a pull requestâ¦ then responsible can choose to merge or not, or cherry pick, or whatever. In summary: is a lot more dynamic and allows a lot more people contribution. monticello is cool, but is not good for that. and if we put also in the table that we need to spend a lot of time improving *external tools* (like smalltalkhub) just to have something that is way far from what is âstate of the artâ, then the equation starts to be less and less in our favor. Also, the proposal so far is not to drop what we have, but to adapt it to be able to use what is aroundâ¦ would be the best of two worlds if you want (even if I believe at the end we will converge in just one). Esteban > >> >> Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D > >

Dec. 3, 2014