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

merge conflict (issue validator)

by Nicolai Hess

I don't understand this merge conflict in hte issue validation for case 14288 <https://pharo.fogbugz.com/default.asp?14288> I can manually load the slice and it does not show any conflicts. Any ideas?

Nov. 29, 2014

Re: [Pharo-dev] ensure: and assignments RB Rule

by Yuriy Tymchuk

As the class of this rule is named RBFileBlocksRule, I guess it comes from some practice used when working with files. Iâm not a file guru, but maybe others can tell more. Stef, as you are working on rules, can we merge category and group of the rule? I understand that one was added later by Manifest, but it is in the Pharo core anywayâ¦ Uko > On 29 Nov 2014, at 21:41, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > I'm revisiting all the RB rule and I'm puzzled by this one. > > > Checks assignment to a variable that is the first statement inside the value block that is also used in the unwind block. > > > [| `@temps | > `var := `@object. > `@.statements] > ensure: > [`var `@messages: `@args] > > Does anybody have an idea? > > Stef >

Nov. 29, 2014

ensure: and assignments RB Rule

by stepharo

Hi guys I'm revisiting all the RB rule and I'm puzzled by this one. Checks assignment to a variable that is the first statement inside the value block that is also used in the unwind block. [| `@temps | `var := `@object. `@.statements] ensure: [`var `@messages: `@args] Does anybody have an idea? Stef

Nov. 29, 2014

MVC/ MVP / DCI Patterns..

by S Krish

In the context of spec / UI / enterprise solutions, I have been mulling over this for some time especially when I play with FXML. To put it in context, I find FXML intriguing and nice. XML metadata that stays completely outside the code and makes it uber flexible to weave in UI to a enterprise solution post facto. The thought trail I have is: Typical Pattern: Model links to Controller that links to a: Customer View ( singleton ? ) Controller links to: Validators / Delegates.. et als.. Model links to in Memory Cache registry { that links to: Persistence Module.. I do not bother about this for now..} In FXML I see nice convention over configuration approach: * XML format.. understood by people/ more importantly editors at large.. * Controller is injectable * all method calls onAction/ events are simple viz #handleSubmitButtonAction or the ilk.. that will thereby call the controller instance methods.. * fxml can also invoke simple ( or complex) javascript action viz: jsSubmitAction( event) Would Spec see that kind of approach.. feasible for extensibility Food for thought more as rethink on fundamental patterns: a) Should view have knowledge explicitly of its Controller.. Or Controller while creating the view injects its instance.. only.. b) Should we push Controller to be a Presenter.. as the case tends to be. And then let Controller be the gateway to all other parts.. as listed above.. c) View actions & callbacks & validators are separated and dealt with a view "controller" , but the gateway to all other parts is handled by a real "observer controller" ... There has to be reliable: * bidirectional update from view -> model ( in cache ) * proper modular segregation of all parts of a standard enterprise app. to enable common and known functions of each part, flexible, scalable but importantly easily maintainable.. in future by developer other than the author.. * Scriptability is one of the desired capabilities with the shrink wrapped app to be extended

Nov. 29, 2014

Re: [Pharo-dev] Athens Repository (NativeBoost)

by Nicolai Hess

2014-11-27 10:02 GMT+01:00 stepharo <stepharo(a)free.fr>: > > > >> The fact that Athens are part of Pharo distribution don't means, that >> its repository should be abandoned and all updates should come directly to >> Pharo. That would be a huge mistake. >> > > That's how I've done it recently. > > I'll merge the changes from pharo -> athens repository. > > > Thanks for doing that! > Hm, actually I don't know how to do that :) Whats the common way for merging this changes back? Do I just open Monticello Browser, select the Athens packages (Athens-Balloon/Athens-Cairo/Athens-Core ..) and just save them in the 'http://smalltalkhub.com/mc/Pharo/Athens/main' - repository ? > > > > >> Doing everything in a monolithic image is a planning mess, and works >> fine only for bug fixing or small refactorings. >> >> Anything which requires sizable planning and designing, should have own >> line of development and maintenance, >> like that there's a clear separation of the responsibility for >> maintaining the project in healthy state and less bottlenecks. >> >> >> no ideaâ¦ I guess is the same case, but I have no control over that >>> area. >>> Igor will know better :) >>> >>> Esteban >>> >>> >>> >> >> -- >> Best regards, >> Igor Stasenko. >> > > >

Nov. 29, 2014

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

by Dale Henrichs

Kilon, As Thierry points out I think that it is important to have project orientation where: project == baseline == git repo In the attached screenshot (tode_project_list) you see a project browser from tode, where each project loaded in the image is managed. There are git-based/baseline projects (filetree and github repos) and mcz/configuration based repos (http repos). For git repos, it is important to know the SHA of the commit that is loaded into your image and the name of the branch that you have checked out (the middle column). The main menu represents the "standard" operations that can be performed for a project. With the exception of the `push` command, all of the operations can be performed against a git or mcz repository. For example the `log` command for a git repo shows the commit log while the log for an mcz repo shows the commit history of the configuration project. The `changes` command compares all packages for a project against the disk version of the packages. The `save` command saves all of the dirty packages to the repo and for git repos does a git commit ... and so on. The Git menu has get-specific commands for doing fairly common git operations. tODE has it's own command line application (from within the image) and the full range of git commands can be run in the "tODE shell" (callable from Smalltalk) so that uncommon operations can be run from within the image ... tODE also allows you to write your scripts (in Smalltalk) so it is easy to write your own custom operations that mix and match git operations and Metacello (for example)... The importance of tracking the loaded commit SHA is illustrated by the second screen shot (tode_project_list_conflicts). The projects highlighted in red, indicate that the SHA of the git repo on disk is different than the SHA of the commit loaded into the image (a very common occurrence when working with multiple images that share git repos). On the main menu you see that the two menu items: `skew diff` and `skew save` are enabled. `skew diff` gives you a view of the differences between the two commits (git diffs can include non-smalltalk diffs) so that you can determine what has changed .... `skew save` is important if you have image-level changes that need to be merged with into the new git SHA ... `skew save` walks you through the steps of: 1. checkout out original SHA 2. create a new branch 3. save changes to the new branch 4. merge the new branch into the original branch 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 ... Dale On Sat, Nov 29, 2014 at 4:15 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > "For a true 'doing something with it', you have to look into what Dale > Henrichs has done with tODE. He is, as far as I could read, a long way up > front us." > > no idea what tODE is doing, I have seen some demos but I have not > understand it. > > "Filetree metadata is a pain in the ass when merging and Thierry's tool > solves that." > > yeah I have seen that he mention that json is binary file .... this is > weird choice why choose a binary file for version controlling . I thought > json file are text files. > > "Also realize that SourceTree is not available in Linux. " > > have you watched my video tutorial ? I already provide a very good > solution for that too :) > > anyway I am new to all this but not new to git , though I have to confess > I have done like one pull request and very few merges, so I will postpone > the tutorials for now for when I feel more comfortable with using the tools > . > > >

Nov. 29, 2014

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

by kilon alios

> > >> I recently did a merge between the pharo3.0 and the pharo4.0 branches of > AltBrowser; if you are interested, you can have a look and try to reproduce > it (by doing a checkout of the pharo4.0 branch to the commit id just before > the merge and merging with pharo3.0 again. Doing it with and without the > merge driver could be interesting). > > Keeping in sync your clone of AltBrowser with the fixes I push could be a > nice example as well. > > Thierry > > yeah more the reason to practice my merge skills. I had not the time to play with your browser yet, but I will and I am sure I will deal with these merge issues. Obviously if the merge driver is so needed makes sense to add it to a video tutorial but I will still like to streamline its installation to something easier, maybe I could help there if you dont beat me to the task first. In any case I am very interested into contributing to improving the workflow between Pharo and Git.

Nov. 29, 2014

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

by Thierry Goubier

Le 29/11/2014 13:15, kilon alios a Ã©crit : > > "For a true 'doing something with it', you have to look into what Dale > Henrichs has done with tODE. He is, as far as I could read, a long way > up front us." > > no idea what tODE is doing, I have seen some demos but I have not > understand it. What I know is that Dale has brought together everything git and smalltalk need: - The merge driver, - a Meld equivalent, - a Project idea (saving multiple packages as a single commit) - Filetree and git. I haven't checked how he has done that in the detail; we just know this was what was needed (and if there is an effort in that direction, I'll know where to get the pieces). > "Filetree metadata is a pain in the ass when merging and Thierry's tool > solves that." > > yeah I have seen that he mention that json is binary file .... this is > weird choice why choose a binary file for version controlling . I > thought json file are text files. You have both: you have a text file containing the version information (and ancestry), and you have properties in Json files (class definitions, method timestamps). This is usual and listed in the git documentation (or any VCS). Git decides whether a file is text-based or binary and uses different diff and merge strategies accordingly. Text based git strategies only work if changes in the files can be resumed by adding or removing lines. a) If your text file is a single line -> doesn't work -> conflict b) If your changes occur over a single line -> probable conflict when merging c) If your text file contains a complex tree structure -> adding/removing lines doesn't work. Version metadata is a), b) and c). Json is a) and b) in FileTree case. > "Also realize that SourceTree is not available in Linux. " > > have you watched my video tutorial ? I already provide a very good > solution for that too :) > > anyway I am new to all this but not new to git , though I have to > confess I have done like one pull request and very few merges, so I will > postpone the tutorials for now for when I feel more comfortable with > using the tools . I recently did a merge between the pharo3.0 and the pharo4.0 branches of AltBrowser; if you are interested, you can have a look and try to reproduce it (by doing a checkout of the pharo4.0 branch to the commit id just before the merge and merging with pharo3.0 again. Doing it with and without the merge driver could be interesting). Keeping in sync your clone of AltBrowser with the fixes I push could be a nice example as well. Thierry

Nov. 29, 2014

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

by stepharo

Thanks Nicolai. I imagine that clement/marcus will have a look. I have been recently running too much. Stef Le 29/11/14 11:14, Nicolai Hess a Ã©crit : > 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 > >

Nov. 29, 2014

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

by kilon alios

"For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us." no idea what tODE is doing, I have seen some demos but I have not understand it. "Filetree metadata is a pain in the ass when merging and Thierry's tool solves that." yeah I have seen that he mention that json is binary file .... this is weird choice why choose a binary file for version controlling . I thought json file are text files. "Also realize that SourceTree is not available in Linux. " have you watched my video tutorial ? I already provide a very good solution for that too :) anyway I am new to all this but not new to git , though I have to confess I have done like one pull request and very few merges, so I will postpone the tutorials for now for when I feel more comfortable with using the tools .

Nov. 29, 2014