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

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > we are on github I don't think that code mirrored by a robot tells us much about the potential impact of using GitHub the way it was designed - discussions directly in commit diffs; integration of issues, commits, users; a real depiction of who contributed what and when... ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p47655… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sean P. DeNigris

EstebanLM wrote > - better visibility +1. I found an online tool that analyzes a person's programming contributions that described me as (paraphrase): "a Javascript expert who dabbles in Smalltalk" or some such nonsense, because it could see my (very) few Amber contributions on GitHub, but was blissfully unaware of my countless MC commits. ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p47655… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Sean P. DeNigris

kilon alios wrote > One of things that very much annoy me with Amber is its installation , if > Pharo is installation heaven because it does not need an install , > installation of Amber is far from ideal especially if you are not familiar > with web dev Have you checked it out lately? The current procedure seems very streamlined... # Install the CLI tools (only needs to be done once per computer) sudo npm install -g amber-cli # Create the project structure mkdir example-project cd example-project/ # Create and initialixe a new Amber project amber init ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-and-Amber-relationship-tp4764889p4765519.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by phil＠highoctane.be

You just got me convinced to go with Thierry's tooling... Phil Le 28 juin 2014 17:13, "Johan Brichau" <johan(a)inceptive.be> a Ã©crit : > Stef, all, > > First, you need to know how to work with git and understand the > vocabulary. Otherwise, you _will_ get confused, and probably get disgusted. > So, beware... git was made for and by linux people, which is all I am > going to say about that... > > In my experience, tools always help and I can recommend sourcetree [1] or > git tower [2]. > Reading the links that Dale mentioned is a very good idea too. > > Next, Dale's 'getting started with github' [3] is a good intro to make > your first git project work and understand the extra steps you need to make > to manage source code. > It does not have to be a github project. > > Let me also comment a bit on why we (at Yesplan) are now trying to switch > from monticello to git for our daily work. I am using git for over a year > now and we are actively switching to use it on a daily basis. > > First of all, in our daily work, we need continuous deployment. When a > feature is ready, it must be shipped into production as soon as possible. > If you are not the only one working on a codebase, continuous deployment > requires that each feature is developed in its own branch and can only be > integrated with the main codebase when it's ready and stable. Monticello > just does not support branching well. In Git, this is natural. You can > easily create feature branches, do partial publishes, merge the changes > from the main codebase back into your feature branch, explore the version > history, etc. I must also add that github's pull request and code > commenting feature is a very productive way of working together on the same > codebase in a structured way. > > About a year ago, I almost only used git tools to merge in the changes > from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a > huge amount of package changes, which is about the worst case scenario to > understand any evolution and merge it in a port (which has code changes > itself). In about an afternoon of work, most of the dust had settled and I > was using the git merge to understand code moves and to prevent > gemstone-specific changes from being overwritten again. The best part there > was probably the sub-method-level merges. Also, the reason I did not need > any Smalltalk browser to do the merges is because filetree exports packages > and classes as directories and methods as files. If you use the column > layout of the Finder on Mac, the Finder becomes the System Browser (at > least for understanding and navigating the structure of the source code, > which is what you need at that level). Sourcetree had such a browser > internally until very recently... so I am disappointed they removed that. > > Besides numerous other projects, we have Seaside hosted in a github > repository too. The advantages are that we can test every feature branch > and every platform automatically with Travis CI. We don't use pull requests > in the community, but if we did, it would be way easier for contributors > and maintainers. Forking and pulling makes it easy for people to patch > something and contribute the code back, while at the same time, it allows > the maintainers to protect the code base from harmful changes. > > Finally, the biggest pain with filetree is that it carries the monticello > metadata. If you work together on the same branch, you _will_ get stupid > merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge > tool [5] is a wonderful tool. Since I started using that, merges of the > metadata are done by git automatically and I just forget about them. Nice > work Thierry! > > Another pain is that publishing and loading code is a two-step process: > files on disk and code in your image. You need to very carefully > synchronize these. You may switch a branch on disk but forget to load it in > the image, or start publishing code from the image to the disk where a > different branch was checked out. This is where better tools for git from > within the image will help. > > those were my 2 cents ;-) > Johan > > [1] http://www.sourcetreeapp.com > [2] http://www.git-tower.com > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… > [4] https://github.com/glassdb/Seaside31 > [5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver > > On 28 Jun 2014, at 10:12, stepharo <stepharo(a)free.fr> wrote: > > > thanks > > > > Now is there a tutorial? Beause > http://forum.world.st/Pharo-git-td4693999.html scared me. > > > > > > On 27/6/14 15:53, Goubier Thierry wrote: > >> > >> > >> Le 26/06/2014 19:11, Yuriy Tymchuk a Ã©crit : > >>> I can only suggest you to read my blogpost about configurations and > versioning: > http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… > >>> > >>> I usually mix filetree and gitfiletree. Last one is better, because > you donât have to remember to commit in git each time you commit in pharo. > >>> (Also I think that gitfiletree is not working with Pharo4) > >> > >> Now it works with Pharo4! > >> > >> Thierry > > > > > > >

June 28, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Johan Brichau

Stef, all, First, you need to know how to work with git and understand the vocabulary. Otherwise, you _will_ get confused, and probably get disgusted. So, beware... git was made for and by linux people, which is all I am going to say about that... In my experience, tools always help and I can recommend sourcetree [1] or git tower [2]. Reading the links that Dale mentioned is a very good idea too. Next, Dale's 'getting started with github' [3] is a good intro to make your first git project work and understand the extra steps you need to make to manage source code. It does not have to be a github project. Let me also comment a bit on why we (at Yesplan) are now trying to switch from monticello to git for our daily work. I am using git for over a year now and we are actively switching to use it on a daily basis. First of all, in our daily work, we need continuous deployment. When a feature is ready, it must be shipped into production as soon as possible. If you are not the only one working on a codebase, continuous deployment requires that each feature is developed in its own branch and can only be integrated with the main codebase when it's ready and stable. Monticello just does not support branching well. In Git, this is natural. You can easily create feature branches, do partial publishes, merge the changes from the main codebase back into your feature branch, explore the version history, etc. I must also add that github's pull request and code commenting feature is a very productive way of working together on the same codebase in a structured way. About a year ago, I almost only used git tools to merge in the changes from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a huge amount of package changes, which is about the worst case scenario to understand any evolution and merge it in a port (which has code changes itself). In about an afternoon of work, most of the dust had settled and I was using the git merge to understand code moves and to prevent gemstone-specific changes from being overwritten again. The best part there was probably the sub-method-level merges. Also, the reason I did not need any Smalltalk browser to do the merges is because filetree exports packages and classes as directories and methods as files. If you use the column layout of the Finder on Mac, the Finder becomes the System Browser (at least for understanding and navigating the structure of the source code, which is what you need at that level). Sourcetree had such a browser internally until very recently... so I am disappointed they removed that. Besides numerous other projects, we have Seaside hosted in a github repository too. The advantages are that we can test every feature branch and every platform automatically with Travis CI. We don't use pull requests in the community, but if we did, it would be way easier for contributors and maintainers. Forking and pulling makes it easy for people to patch something and contribute the code back, while at the same time, it allows the maintainers to protect the code base from harmful changes. Finally, the biggest pain with filetree is that it carries the monticello metadata. If you work together on the same branch, you _will_ get stupid merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge tool [5] is a wonderful tool. Since I started using that, merges of the metadata are done by git automatically and I just forget about them. Nice work Thierry! Another pain is that publishing and loading code is a two-step process: files on disk and code in your image. You need to very carefully synchronize these. You may switch a branch on disk but forget to load it in the image, or start publishing code from the image to the disk where a different branch was checked out. This is where better tools for git from within the image will help. those were my 2 cents ;-) Johan [1] http://www.sourcetreeapp.com [2] http://www.git-tower.com [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… [4] https://github.com/glassdb/Seaside31 [5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver On 28 Jun 2014, at 10:12, stepharo <stepharo(a)free.fr> wrote: > thanks > > Now is there a tutorial? Beause http://forum.world.st/Pharo-git-td4693999.html scared me. > > > On 27/6/14 15:53, Goubier Thierry wrote: >> >> >> Le 26/06/2014 19:11, Yuriy Tymchuk a Ã©crit : >>> I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… >>> >>> I usually mix filetree and gitfiletree. Last one is better, because you donât have to remember to commit in git each time you commit in pharo. >>> (Also I think that gitfiletree is not working with Pharo4) >> >> Now it works with Pharo4! >> >> Thierry > >

June 28, 2014

Re: [Pharo-dev] [Pharo4] Slots: Code Generation and an Example

by Tudor Girba

This is really brilliant! Doru On Sat, Jun 28, 2014 at 9:34 AM, stepharo <stepharo(a)free.fr> wrote: > This is so cool. I remember when we played one afternoon in 2008 to see > if this interplay would work. > > Stef > > > > On 27/6/14 10:19, Marcus Denker wrote: > > Hi, > > So now Opal delegates code generation for read and write to the Slot meta objects. > The methods called are #emitValue: and #emitStore:, the parameter is an IRBuilder. > > With this the implementor of a Slot is free to generate whatever bytecode needed, it will > be inlined at the read or assignment site in the method. > > For the ivar Slot this is e.g. just > > emitStore: methodBuilder > > methodBuilder storeInstVar: index > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > > Now the implementors of Slots should not need to be bothered about bytecode, therefore we have > in the superclass of all Slots defaults emit methods that implement a **reflective** read and write using > the MOP of the Slot itself (slower than code generation, but often enough): > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > emitStore: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #writeToSlot:of: > > > What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. > > Here is a simple Slot: > > Slot subclass: #TestSlot > instanceVariableNames: 'value' > classVariableNames: '' > category: 'Slot-Scopeâ > > > read: anObject > ^ value > > write: aValue to: anObject > value := aValue > > > So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only > one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) > > Now we can create a class (not yet easily as we have not yet enabled a class template, so lets use the ClassBuilder directly): > > PharoClassInstaller make: [ :builder | > builder name: #A; > slots: { TestSlot named: #iv }; > category: #Playground ]. > > > In class A we can implement accessors: > > iv > ^iv > > iv: anObject > iv := anObject > > > They look like normal ivar accesses, but in the background, the compiler delegated to the Slot the code generation, calling emit*, which leads > to the bytecode e.g. for the read: > > 21 <20> pushConstant: iv => TestSlot > 22 <70> self > 23 <E1> send: read: > 24 <7C> returnTop > > you could override the emit* methods to generate faster code, but to get something running it is not needed. > > To test, e.g. you can set the slot from one object and read it from another: > > A new iv: 6 > A new iv > > Then inspect the slot: > > (A slotNamed: #iv) inspect > > (this should all Work in 4.0 048, the example is there as TestSlot for now) > > ...next steps: > > 1) Class Definition template for classes with Slots > 2) How do we save these classes in Monticello? > 3) Virtual Slots (Boolean and PropertySlots) > > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

June 28, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Dale Henrichs

Stef, Git is not perfect. Monticello is not perfect. Metacello is not perfect. GitHub is not perfect. Git and Github brings some things to the table that make Monticello and Metacello and collaborative development in Smalltalk better... Half of Metacello - the bit where you must "manually" record the version number for every .mcz file used - one of the most tedious parts - becomes unnecessary with git. With git a Metacello version references a specific commit, tag or branch. When we release a version of Seaside3 for GemStone, we just tag a repository and record the tag in the configuration of ... no need for "flattening" or meticulously recording of mcz file versions ... this simple fact by itself is almost enough to make the "complexity of git" worthwhile... Here's the complete version specification for Seaside3.1.1 in the ConfigurationOfSeaside3: spec for: #'gs3.x' do: [ spec baseline: 'Seaside3' with: [ spec repository: 'github://glassdb/Seaside31:3.1.1-gs31/repository' ] ]. That's it ... done... 95% of my git interactions are: git add ... git commit ... git push ... git pull ... This isn't that complicated to understand ... there are certainly times when it is necessary to use some of the more arcane commands, but frankly there are complicated operations in the Monticello/Metacello universe. How do you merge two Metacello versions? How do you merge changes to multiple mcz files? How do you fork/branch a large project like Seaside3 and still retain the ability to track changes from the master? I have done all of these things without git and it is not pretty .... not by a long shot...I wish we did have some arcane commands to help:) With git, all three of those operations are just part of eco-system... With github, I can merge a multiple mcz file contribution into my project ... WITH THE PUSH OF A BUTTON! GiHub arranges to run the tests using travis-ci, so before I dare push the button, I can be assured that all of the tests are passing. Before pushing the button, I can easily review all of the proposed changes and critique the proposed changes on a line by line basis and the contributor and I can engage in an online conversion ... on a line by line basis ... The contributor can make changes in her repository and they are reflected in the original pull request and the tests are automatically rerun... When the tests are green and I am satisfied with the review ... I press a button ... and the code is merged into my project and I can go back to work ... _This_ feature by itself is worth the price of admission for git ... It takes a bit of time to become comfortable with git, but if you are feeling any of pain that I have mentioned above, then it is worth taking the time to become comfortable with git ... If you are not feeling that pain, then I envy you:) and by all means ... do not learn git:) Dale On Sat, Jun 28, 2014 at 1:10 AM, stepharo <stepharo(a)free.fr> wrote: > I use git for my books. Now the simple fact that a tool has to help me to > do simple action is a sign > of strange design. This is the same as Java design and eclipse. When you > code without eclipse you will a real pain :) > I found the git API far to low level from my developer perspective and > this is what I would like the pharo abstraction to > protect our users (while getting the benefits from git). > And this is why when esteban is telling that this is what newbies expect I > cannot believe such kind of statements > because there are simply bullshit. :) > > Stef > > Stef, > > You need to cut your teeth for a decent couple hours to get to terms > with Git. > Especially when using a workflow with branches, with merges, and several > contributors. > I knew of quite a couple of SCMs (including Hg) but Git is a special beast. > > I liked Git Recipes: A Problem Solution Approach as it was very > pragmatic. > > HTH > Phil > > > On Thu, Jun 26, 2014 at 7:09 PM, stepharo <stepharo(a)free.fr> wrote: > >> I read >> >> >> http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git… >> and I found >> http://forum.world.st/Pharo-git-td4693999.html >> >> But is there something that works and it simple? >> >> Stef >> >> >> On 26/6/14 18:27, stepharo wrote: >> >>> Hi >>> >>> I do not know the dif between git file tree, file tree.... and I would >>> like to know how to get >>> started with git in Pharo? >>> >>> What should I read? >>> >>> Stef >>> >> >> >> > >

June 28, 2014

Re: [Pharo-dev] [Pharo4] Slots: Code Generation and an Example

by Ben Coman

Marcus Denker wrote: > What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. > This is very cool. Thanks Marcus. I look forward to playing with it. > Here is a simple Slot: > > Slot subclass: #TestSlot > instanceVariableNames: 'value' > classVariableNames: '' > category: 'Slot-Scopeâ > > > read: anObject > ^ value > > write: aValue to: anObject > value := aValue > > > So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only > one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) > Would a real world example for this be an atomic-counter? Such that the first time an instance reads its instance-slot, the slot-class-variable is incremented and stores the result in the instance-slot in an atomic way. (its a bit hard to work out the terminology to use in relation to that example) Just a random thought - should we now describe ':=' assignment operator as the 'slotting' operator, and the result is that the value has been 'slotted' ? /grin -ben

June 28, 2014

Re: [Pharo-dev] Spec TreeModel

by Yuriy Tymchuk

Thatâs really cool. If we can work together it will be nice. Because I have a couple of ideas how to fix the problem Iâve describer, but I donât know what you think about this and how I can contribute. Uko On 28 Jun 2014, at 09:40, stepharo <stepharo(a)free.fr> wrote: > For your info, I'm slowly going all the polymorph widget examples and truning them into single example to identify what are > the widgets that we should > - improve > - remove > > Having 3 versions of the same is killing us. Ben fixed a lot of problems like merging multi/single selection but there is still > a lot of work to do. So I started to reorganize the packages to help us finding our way doing this analysis. > > Stef > > > On 27/6/14 11:28, Yuriy Tymchuk wrote: >> Hi, >> >> Iâd like to improve the TreeModel of Spec, but I need some help. >> >> Fist of all UI breaks when different theme is used: >> <Mail Attachment.png> >> >> When you deselect checkbox and at that moment item is not highlighted. This happens when checkbox is clicked, the item is not highlighted and so itâs original color is not stored, but when you uncheck item it IS unhighlighted for some reason, and as default color is not stored, black one is used. First of all we can replace black color by theme color, and also I think that we should handle checkbox and list clicks in a separate manner. Now the other thing is related. I can turn on checkbox, but can I turn off the list selection? Are the selected items distinguished is any way, or all items with checked checkboxes and highlights merged into one list? >> >> Uko >> >

June 28, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sebastian Sastre

On Jun 28, 2014, at 5:10 AM, stepharo <stepharo(a)free.fr> wrote: > And this is why when esteban is telling that this is what newbies expect I cannot believe such kind of statements > because there are simply bullshit. :) Hey Stef, we can believe that is bullshit all we want and at the end of the day this is what happens: Software Engineers Are In Demand, And GitHub Is How You Find Them http://www.forbes.com/sites/anthonykosner/2012/10/20/software-engineers-are… How to Recruit Using Github, Quora, Dribbble & More http://www.slideshare.net/VivekReddy4/how-to-recruit-using-github-quora-dri… With the current demand, if you werenât pitched yet from your github profile is because youâre forcing yourself to stay out of the game sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

June 28, 2014