- Pharo-dev - lists.pharo.org

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

by kilon alios

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. 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> wrote: > > > On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)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 > >

Nov. 30, 2014

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

by Dale Henrichs

On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios(a)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

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban Lorenzano

> On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > btwâ¦ historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects" > > And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it? Smalltalkhub was already there. Question was if we put it online or not, not if we develop it or not. ss3 was there but Dale always said (at the time) that was a proof of concept and that having time for work on it was complicated (and search was severely broken, and it was slow and we were having *real* problems when doing massive downloads). both situations are probably fixed now, but at the time having a 3rd solution for the community looked like a good idea. and I believe it was. Even if you plan, in the future, to provide something else that you believe is better, when you are developing something like Pharo you have certain responsibilities with your community, you cannot drop something without having already a good replacement. We needed a solution soon, we had sthub, so it was a good match. and look nowâ¦ I still believe the future is using Git as our central source management system, but we are still not there, tools are still not good enough and then, we still need to have tools like sthub. Esteban > >

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Denis Kudriashov

2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btwâ¦ historic reference: sthub was never intended to be there for stay. I > remember talking about it with Nico and Stef, more than two years ago, > before sthub came online, and our conclusion at the time was: âyes, the > future it will be git, but until we get there, letâs put sthub online > because sqsource cannot handle more projects" And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?

Nov. 30, 2014

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

by kilon alios

"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 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.

Nov. 30, 2014

Books

by Luc Fabresse

Hi Guys, Regarding the books, I think that all Zinc chapters and the STON one should be moved from the EnterprisePharo to the PharoWeb book. What do you think? #Luc

Nov. 30, 2014

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

by Thierry Goubier

Le 30/11/2014 12:01, Max Leske a Ã©crit : > >> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>> The code would look like this: >>> >>> [ | file | >>> file := StandardFileStream forceNewFileNamed: âfooâ. >>> file nextPutAll: âbarâ ] >>> ensure: [ file close ]. >>> >>> Why that is considered bad practice however, I canât tell. >> >> This one would fail because file is a temp to the block (and not visible to the ensure block). > > If it werenât visible, wouldnât the compiler raise an exception? In your example, yes. But the rule matched: | file | [ file := StandardFileStream forceNewFileNamed: âfooâ. file nextPutAll: âbarâ ] ensure: [ file close ]. (Hum: wouldn't the compiler complain of file might be nil in the ensure block?) >> Another problem is that, if you have a failure in forceNewFileNamed:, file is nil and the ensure: fail as well. > > True, but thatâs a problem this rule doesnât really cover I guess. That oneâs up to the developer. I would expect that rule to flag bad coding practices, and I think it does ;) Thierry

Nov. 30, 2014

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

by Max Leske

> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 30/11/2014 11:06, Max Leske a Ã©crit : >> The code would look like this: >> >> [ | file | >> file := StandardFileStream forceNewFileNamed: âfooâ. >> file nextPutAll: âbarâ ] >> ensure: [ file close ]. >> >> Why that is considered bad practice however, I canât tell. > > This one would fail because file is a temp to the block (and not visible to the ensure block). If it werenât visible, wouldnât the compiler raise an exception? > > Another problem is that, if you have a failure in forceNewFileNamed:, file is nil and the ensure: fail as well. True, but thatâs a problem this rule doesnât really cover I guess. That oneâs up to the developer. > > This is how I interpret that rule. > > Thierry > >

Nov. 30, 2014

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

by Sven Van Caekenberghe

This is how it should be done: readStreamDo: aBlock | stream | stream := self readStream. ^ [ aBlock value: stream ] ensure: [ stream close ] Errors while opening or closing are still signalled, which is good IMO. > On 30 Nov 2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 30/11/2014 11:06, Max Leske a Ã©crit : >> The code would look like this: >> >> [ | file | >> file := StandardFileStream forceNewFileNamed: âfooâ. >> file nextPutAll: âbarâ ] >> ensure: [ file close ]. >> >> Why that is considered bad practice however, I canât tell. > > This one would fail because file is a temp to the block (and not visible to the ensure block). > > Another problem is that, if you have a failure in forceNewFileNamed:, file is nil and the ensure: fail as well. > > This is how I interpret that rule. > > Thierry > >

Nov. 30, 2014

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

by Thierry Goubier

Le 30/11/2014 11:06, Max Leske a Ã©crit : > The code would look like this: > > [ | file | > file := StandardFileStream forceNewFileNamed: âfooâ. > file nextPutAll: âbarâ ] > ensure: [ file close ]. > > Why that is considered bad practice however, I canât tell. This one would fail because file is a temp to the block (and not visible to the ensure block). Another problem is that, if you have a failure in forceNewFileNamed:, file is nil and the ensure: fail as well. This is how I interpret that rule. Thierry

Nov. 30, 2014