September 2015 - Pharo-users

Re: [Pharo-users] Observing changes of regular attributes

by Peter UhnÃ¡k

> > I imagine in time tools will be built to have better control of this (for > example now stack trace in debugger looks really magical (suddenly there's > a frame from nowhere)), but all in time. > Yes! One thing I want to add is to visualise links in the debugger (so > that you can explore easily who hooked into what). And provide a âstep > into metaâ. functionality. I'm currently looking into debuggers to at least provide reference in the context... but this may not be achievable without code rewrite... > Now when code is recompiled (loaded), you need to re-install the links in >> those methods, it does not happen >> automatically. >> > > Are there any scenarios when method is recompiled during regular Pharo run > and without user's invocation? > > If nobody else does magic, just loading code or editing code. > That should be fine then... I hope. :) > In other words, if I install the links after the package has been > loaded/updated and I will not be changing the code, will I be safe? > > If you want to be sure, you need to implement a layer above. (I want to > provide a framework for that later to be reused) > > -> Every change to code can be easily tracked by subscribing to the system > notification mechanism > -> If a method changed that you are interested in â> reinstall the links. > I wanted to avoid global subscriptions since I am not sure of the performance penalty... it seems to me like a overkill, but someone would have to benchmark it first. Because 99% of the time you are probably not working with MetaLinks. maybe I should do real AST rewrites and recompile instead... or investigate > if I can somehow annotate Nautilus and debugger to show the links... hmmâ¦ > > > Link visualisation in the code will come, now with the new editor this is > actually possible! But it will be after the whole base is stable and > debugged... > But of course the âhiddenâ nature of the metalink is a tradeoffâ¦ rewriting > code in a more visible way can be better depending on the situation. > Well since I want to play with metalinks some more I created a simple Nautilus plugin that can show MetaLinks associated with a method... â But I don't know how useful it would be for real metalink usage... maybe I can publish it somewhere... Peter

Sept. 10, 2015

Adding custom context to a debugger

by Peter UhnÃ¡k

Hi, is it possible to add custom context to a debugger? â I would like to add a reference to the highlighted area. I am assuming that since SpecDebugger doesn't provide plugin support I would have to modify the source code? Thanks, Peter

Sept. 10, 2015

Re: [Pharo-users] Observing changes of regular attributes

by Marcus Denker

> On 10 Sep 2015, at 19:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > On Wed, Sep 9, 2015 at 10:04 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Hello, > > The idea of Reflectivity is to be just that: a way to âhookâ into code without changing the sourceâ¦ this is a similar use case like > the one described yesterday: > > link := MetaLink new > metaObject: MyNotifyer; > selector: #notifyChangedVaNamed:; > arguments: #(name). > > Ah, this is really cool and powerful, thanks! > > I imagine in time tools will be built to have better control of this (for example now stack trace in debugger looks really magical (suddenly there's a frame from nowhere)), but all in time. > Yes! One thing I want to add is to visualise links in the debugger (so that you can explore easily who hooked into what). And provide a âstep into metaâ. functionality. > Now when code is recompiled (loaded), you need to re-install the links in those methods, it does not happen > automatically. > > Are there any scenarios when method is recompiled during regular Pharo run and without user's invocation? If nobody else does magic, just loading code or editing code. > In other words, if I install the links after the package has been loaded/updated and I will not be changing the code, will I be safe? > If you want to be sure, you need to implement a layer above. (I want to provide a framework for that later to be reused) -> Every change to code can be easily tracked by subscribing to the system notification mechanism -> If a method changed that you are interested in â> reinstall the links. > Also I am little bit scared that without tools I am brewing a recipe for disaster, because this is very powerful and not controlledâ¦ Indeed, > maybe I should do real AST rewrites and recompile instead... or investigate if I can somehow annotate Nautilus and debugger to show the links... hmmâ¦ Link visualisation in the code will come, now with the new editor this is actually possible! But it will be after the whole base is stable and debugged... But of course the âhiddenâ nature of the metalink is a tradeoffâ¦ rewriting code in a more visible way can be better depending on the situation. Marcus

Sept. 10, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Thierry Goubier

Le 10/09/2015 20:29, Alexandre Bergel a Ã©crit : >>>> But, all well considered, relying only on the underlying vcs for >>>> versions, but writing chunk files, could it work? With the >>>> gitfiletree framework, all version / meta information is external >>>> to the source files, so Metacello could use that and have >>>> everything it needs. Would someone be interested by that? > > Are you suggesting to have a different format, which could be .mcs that > is like .mcz but without all the metadata? That would be that. The mcs would be the chunk format that Pharo and all Smalltalks have (i.e. fileouts). > This means that we will need > another UI since Monticello will not work. No, it would simply be another type of repository for Monticello. I have already done the work for GitFileTree (recreate a MC-like API even if the metadata comes from git instead of the mcz), and you would reuse that. It would be totally transparent to you. Metacello, Gofer, Configurations would work. > Can you estimate the amount of work to do? I'd start from GitFileTree, isolate the git commands and the MC API and copy them to the new repository type, add a chunk reader over a zip archive, and add the chunk writer. I'd reuse the GitFileTree repository inspector because it is already designed for that. For someone who knows a bit the internals of a MC repository, it wouldn't take long. Shouldn't forget to have a good chunk of tests cases and sample repositories: filetree would be my reference there. Thierry > Alexandre

Sept. 10, 2015

Re: [Pharo-users] load directive

by stepharo

(ConfigurationOfStore project version: #stable) record loadDirective linear load : linear load : 0.10 [ConfigurationOfStore] linear load : 0.2 [ConfigurationOfGarage] load : ConfigurationOfTalkFFI linear load : 0.2 [ConfigurationOfGarage] load : Store-StephaneDucasse.13

Sept. 10, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

>>> But, all well considered, relying only on the underlying vcs for >>> versions, but writing chunk files, could it work? With the >>> gitfiletree framework, all version / meta information is external >>> to the source files, so Metacello could use that and have >>> everything it needs. Would someone be interested by that? Are you suggesting to have a different format, which could be .mcs that is like .mcz but without all the metadata? This means that we will need another UI since Monticello will not work. Can you estimate the amount of work to do? Alexandre

Sept. 10, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Thierry Goubier

Le 10/09/2015 19:37, Alexandre Bergel a Ã©crit : >> Solving MC conflicts with tools like meld isn't fun. When it is for >> Metacello version files, it's allmost impossible to correct >> properly. > > I do not see why. It works well for other languages, I see no reason > why it would not work in Pharo. That's because other languages have very poor, unstructured formats which predates Smalltalk, i.e. source files. And an horrible mess of unstructured information for building it: Makefiles, configure scripts, maven, cmake, shell scripts, you name it. Anything which tries to store anything more complex under text files in git (json data, xml data, csv data) has the same problem. >>> One question I have: is mcz the most appropriate? Why not simply >>> doing a fileout of the package? And having one .st file per >>> package. >> >> You need the mcz (in fact, Monticello) support for versions to have >> Metacello: configurations, baselines and all the like. I think >> projects like Seaside and Moose would not be doable without that. > > Well, if you have git, then the baseline is rather simple right? Yes. Part of the attractiveness of git is that: version information is moved into the repository url instead of being in the mcz name. >> But, all well considered, relying only on the underlying vcs for >> versions, but writing chunk files, could it work? With the >> gitfiletree framework, all version / meta information is external >> to the source files, so Metacello could use that and have >> everything it needs. Would someone be interested by that? > > What do you mean by that? What you are suggesting, is it really more > than fileout a source from a package? I am probably missing something > obvious here. No, it is just a fileout. Apart from dependencies, but nobody uses them except for SLICES. There are a few queries you can do on a git repository (search for method versions, class definition changes) where you have to use the filetree format and the chunk format won't work. But, honestly, nobody needs that: I am the only user in the Pharo community (i.e. you need AltBrowser + GitFileTree for that feature). Ah, yes, for the filetree format: it's a lot easier to browse the filetree format than the chunk on github:/, bitbucket:/, gitosis, gitlab, etc... It is also reasonably portable among dialects (ST/X, Squeak, Pharo, Gemstone, VW?) But it has a problem with long file names under windows. And it may be slow to write plenty of small files. Thierry > Cheers, Alexandre > > >> >> Thierry >> >>> Alexandre >>> >>> >>> Le 9 sept. 2015 Ã 11:38, Thierry Goubier >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> a >>> Ã©crit : >>> >>>> - A tool to resolve merge conflicts in Pharo. We should reuse >>>> the diff widget we have. >>>> >>>> >>>> Dale proposed some tools: a diff parser/reader? >>>> >>>> A reader for files with conflict markers. >> >> > > >

Sept. 10, 2015

Re: [Pharo-users] Observing changes of regular attributes

by Peter UhnÃ¡k

On Wed, Sep 9, 2015 at 10:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > The idea of Reflectivity is to be just that: a way to âhookâ into code > without changing the sourceâ¦ this is a similar use case like > the one described yesterday: > > link := MetaLink new > metaObject: MyNotifyer; > selector: #notifyChangedVaNamed:; > arguments: #(name). > Ah, this is really cool and powerful, thanks! I imagine in time tools will be built to have better control of this (for example now stack trace in debugger looks really magical (suddenly there's a frame from nowhere)), but all in time. Now when code is recompiled (loaded), you need to re-install the links in > those methods, it does not happen > automatically. > Are there any scenarios when method is recompiled during regular Pharo run and without user's invocation? In other words, if I install the links after the package has been loaded/updated and I will not be changing the code, will I be safe? Also I am little bit scared that without tools I am brewing a recipe for disaster, because this is very powerful and not controlled... maybe I should do real AST rewrites and recompile instead... or investigate if I can somehow annotate Nautilus and debugger to show the links... hmm... Peter

Sept. 10, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Alexandre Bergel

> Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly. I do not see why. It works well for other languages, I see no reason why it would not work in Pharo. > >> One question I have: is mcz the most appropriate? Why not simply doing a >> fileout of the package? And having one .st file per package. > > You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that. Well, if you have git, then the baseline is rather simple right? > But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that? What do you mean by that? What you are suggesting, is it really more than fileout a source from a package? I am probably missing something obvious here. Cheers, Alexandre > > Thierry > >> Alexandre >> >> >> Le 9 sept. 2015 Ã 11:38, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> a Ã©crit : >> >>> - A tool to resolve merge conflicts in Pharo. We should reuse >>> the diff >>> widget we have. >>> >>> >>> Dale proposed some tools: a diff parser/reader? >>> >>> A reader for files with conflict markers. > >

Sept. 10, 2015

Re: [Pharo-users] Having a look at Git+Pharo

by Thierry Goubier

Hi Alexandre, Le 10/09/2015 17:40, Alexandre Bergel a Ã©crit : > Hi! > > I am not sure to understand. There is a fair amount of tools for got to > deal with conflict. Sure, we could imagine compelling scenarios to have > the conflict merger in Pharo. But I do not feel this is that necessary > for now. Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly. > One question I have: is mcz the most appropriate? Why not simply doing a > fileout of the package? And having one .st file per package. You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that. Oh, by the way, for those who would like to try: git does not know how to properly merge two conflicting class definitions in the chunk format, so conflicts would still be present... But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that? Thierry > Alexandre > > > Le 9 sept. 2015 Ã 11:38, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> a Ã©crit : > >> - A tool to resolve merge conflicts in Pharo. We should reuse >> the diff >> widget we have. >> >> >> Dale proposed some tools: a diff parser/reader? >> >> A reader for files with conflict markers.

Sept. 10, 2015