- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] class variable slots?

by Marcus Denker

> On 03 Dec 2014, at 14:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > What do you mean? > Highlight in the source where the reference isâ¦ Textual highlight should be simple (I did that for other tools already). But what we need is one with semantic knowledgeâ¦ which should be easy, too. (using the AST). Marcus > Doru > > On Wed, Dec 3, 2014 at 2:33 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > Marcus Denker wrote: > > > On Wed, Dec 3, 2014 at 1:32 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> <mailto:tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>> wrote: > > Exactly! This is what I was looking for :) > > > This is now in 4.0 #397 > > e.g. use GTInspector on > > Object binding > > Is it feasible to get highlighting of 'Object' as well? > cheers -ben > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Tudor Girba

What do you mean? Doru On Wed, Dec 3, 2014 at 2:33 PM, Ben Coman <btc(a)openinworld.com> wrote: > Marcus Denker wrote: > >> >> >> On Wed, Dec 3, 2014 at 1:32 PM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Exactly! This is what I was looking for :) >> >> >> This is now in 4.0 #397 >> >> e.g. use GTInspector on >> >> Object binding >> > > Is it feasible to get highlighting of 'Object' as well? > cheers -ben > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Ben Coman

Marcus Denker wrote: > > > On Wed, Dec 3, 2014 at 1:32 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Exactly! This is what I was looking for :) > > > This is now in 4.0 #397 > > e.g. use GTInspector on > > Object binding Is it feasible to get highlighting of 'Object' as well? cheers -ben

Dec. 3, 2014

Re: [Pharo-dev] GetOpt

by Ben Coman

Eliot Miranda wrote: > One if these, which Ben Coman's recent changes above my 64-bit > microsecond clock should have fixed is a spin loop of up to a second to > synchronize the second and millisecond clocks. Is this in the image or VM ? I didn't notice this. > I found these either by profiling (clock sync; I can give you a change > set that allows profiling across a snapshot, quit, resume) or using the > VM simulator (GC to check for finalization facilities). That would be interesting to try. cheers -ben

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Marcus Denker

On Wed, Dec 3, 2014 at 1:32 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Exactly! This is what I was looking for :) > > This is now in 4.0 #397 e.g. use GTInspector on Object binding > 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" > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Dec. 3, 2014

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