September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Nicolai Hess

2015-09-29 10:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-09-29 9:39 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-09-29 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Levente, >>> >>> Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : >>> >>>> On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote: >>>> >>>> An other point is that git file tree will not work on Windows if we do >>>>> not fix the problem of the stdio. And a lot of people out of the >>>>> community use Windows, so this is not a issue we should forget. Most of >>>>> the people I know in company use Windows, so if we want to attract >>>>> people this problem need to be corrected. >>>>> >>>> >>>> If there are so many windows users, then how can it be that none of them >>>> managed to explain what the actual problem with stdio handling is. I had >>>> asked about the problem a while ago, but I still haven't got an answer: >>>> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >>>> >>> >>> Well, I changed the code using ProcessWrapper with your suggestions >>> following that exchange, but my code stay fairly naive [1] (and would need >>> to run under debug), and I didn't have someone testing on Windows. >>> >> >> Can you give me an example on how to test this >> > > Yes! Thanks! > > Can you run a makefile under Windows? I can prepare one which calls and > loads everything to run the tests for gitfiletree. > > Or just trying to load something like SmaCC from github... > > Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main'; > configurationOf: 'GitFileTree'; loadDevelopment > > Metacello new baseline: 'SmaCC'; repository: 'gitfiletree:// > github.com/ThierryGoubier/SmaCC?protocol=https'; load > > If you manage to get through the SmaCC loading without a crash or a > lockup, then it means it nearly certainly works. > No, it does not work, in MCFileTreeGitRepository class>>#runProcessWrapperGitCommand:in: ... (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load ProcessWrapper' ]) ifNotNil: [ :pW | | command | command := pW new useStdout; useStderr; startWithCommand: self gitCommand , ' -C "' , (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , aCommandString. r := command upToEnd. "<<<<<<<<<<<<------------------- MNU False>>upToEnd" ... somehow, the command is a boolean false, instead of a ProcessWrapper. > > Thierry > > >> >> >>> >>> Am I writing that code correctly? If you see the equivalent code using >>> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on >>> the external commands framework, I am prepared to work very closely with >>> that layer including inside the vm plugin code (and David T Lewis helped me >>> a lot to fix random lockups we had). >>> >>> Thierry >>> >>> (*) Running the gitfiletree integration tests launches probably over a >>> hundred external commands in quick succession. >>> >>> [1] >>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… >>> >>> [2] >>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… >>> >>> >>>> Levente >>>> >>>> >>> >>> >> >

Sept. 29, 2015

Filtering methods

by Alexandre Bergel

Hi! I can now type in the method list pane. This is fantastic beginning. However it does not work properly. Can someone finish it? For example, once I started to filtering, I cannot use the keys to select a method. Frustrating. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2015

Re: [Pharo-dev] Hi from VISSOFT'15 / ICSME'15

by Serge Stinckwich

Great ! Please continue the buzz ;-) On Tue, Sep 29, 2015 at 1:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I am now attending (very) academic conferences: http://vissoft.info and http://www.icsme.uni-bremen.de . It is fantastic to see and hear a lot about Pharo. > > Thanks to all the researchers around here... > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 29, 2015

Hi from VISSOFT'15 / ICSME'15

by Alexandre Bergel

Hi! I am now attending (very) academic conferences: http://vissoft.info and http://www.icsme.uni-bremen.de . It is fantastic to see and hear a lot about Pharo. Thanks to all the researchers around here... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-29 10:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 29 Sep 2015, at 1:48 , Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > The big issue for git and windows (in general) is that there is a 255 > character limit on the paths for files .... I recently pruned some file > names for Metacello (on a win-hack branch) just to get Metacello to work > with filetree .. > > Working with Github Desktop[1] for Windows makes the experience of using > git from the command line tolerable on Windows - you get a retty nice bash > shell to work with so as a non-windows user I can work in a pretty familiar > environment ... > > At the moment I'm working with Pharo3.0 on Windows, so I don't have any > useful feedback right now (assuming things have changed a bit on Windows > with Pharo4.0 and Pharo5.0) ... > > Dale > > > IIRC, there is some flag you can set to make (some?) the actual git client > (but not bundled tools) support long filenames on Windows: > git config core.longpaths true > For instance, cloning the PharoVM repo choked (or rather, failed > semi-silently) on some really long selector in an obscure plugin somewhere > until I found that... > Interesting. This could allow gitfiletree(*) to load from a repository where filetree would fail to load... but both would fail upon writing :( (*) gitfiletree loads packages via a call to git archive and may so avoid some of the long paths. Thierry > > Cheers, > Henry >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Henrik Johansen

> On 29 Sep 2015, at 1:48 , Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > The big issue for git and windows (in general) is that there is a 255 character limit on the paths for files .... I recently pruned some file names for Metacello (on a win-hack branch) just to get Metacello to work with filetree .. > > Working with Github Desktop[1] for Windows makes the experience of using git from the command line tolerable on Windows - you get a retty nice bash shell to work with so as a non-windows user I can work in a pretty familiar environment ... > > At the moment I'm working with Pharo3.0 on Windows, so I don't have any useful feedback right now (assuming things have changed a bit on Windows with Pharo4.0 and Pharo5.0) ... > > Dale IIRC, there is some flag you can set to make (some?) the actual git client (but not bundled tools) support long filenames on Windows: git config core.longpaths true For instance, cloning the PharoVM repo choked (or rather, failed semi-silently) on some really long selector in an obscure plugin somewhere until I found that... Cheers, Henry

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-29 9:39 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-29 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Levente, >> >> Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : >> >>> On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote: >>> >>> An other point is that git file tree will not work on Windows if we do >>>> not fix the problem of the stdio. And a lot of people out of the >>>> community use Windows, so this is not a issue we should forget. Most of >>>> the people I know in company use Windows, so if we want to attract >>>> people this problem need to be corrected. >>>> >>> >>> If there are so many windows users, then how can it be that none of them >>> managed to explain what the actual problem with stdio handling is. I had >>> asked about the problem a while ago, but I still haven't got an answer: >>> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >>> >> >> Well, I changed the code using ProcessWrapper with your suggestions >> following that exchange, but my code stay fairly naive [1] (and would need >> to run under debug), and I didn't have someone testing on Windows. >> > > Can you give me an example on how to test this > Yes! Thanks! Can you run a makefile under Windows? I can prepare one which calls and loads everything to run the tests for gitfiletree. Or just trying to load something like SmaCC from github... Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main'; configurationOf: 'GitFileTree'; loadDevelopment Metacello new baseline: 'SmaCC'; repository: 'gitfiletree:// github.com/ThierryGoubier/SmaCC?protocol=https'; load If you manage to get through the SmaCC loading without a crash or a lockup, then it means it nearly certainly works. Thierry > > >> >> Am I writing that code correctly? If you see the equivalent code using >> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on >> the external commands framework, I am prepared to work very closely with >> that layer including inside the vm plugin code (and David T Lewis helped me >> a lot to fix random lockups we had). >> >> Thierry >> >> (*) Running the gitfiletree integration tests launches probably over a >> hundred external commands in quick succession. >> >> [1] >> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… >> >> [2] >> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… >> >> >>> Levente >>> >>> >> >> >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Nicolai Hess

2015-09-29 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Levente, > > Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : > >> On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote: >> >> An other point is that git file tree will not work on Windows if we do >>> not fix the problem of the stdio. And a lot of people out of the >>> community use Windows, so this is not a issue we should forget. Most of >>> the people I know in company use Windows, so if we want to attract >>> people this problem need to be corrected. >>> >> >> If there are so many windows users, then how can it be that none of them >> managed to explain what the actual problem with stdio handling is. I had >> asked about the problem a while ago, but I still haven't got an answer: >> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >> > > Well, I changed the code using ProcessWrapper with your suggestions > following that exchange, but my code stay fairly naive [1] (and would need > to run under debug), and I didn't have someone testing on Windows. > Can you give me an example on how to test this > > Am I writing that code correctly? If you see the equivalent code using > OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on > the external commands framework, I am prepared to work very closely with > that layer including inside the vm plugin code (and David T Lewis helped me > a lot to fix random lockups we had). > > Thierry > > (*) Running the gitfiletree integration tests launches probably over a > hundred external commands in quick succession. > > [1] > https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… > > [2] > https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… > > >> Levente >> >> > >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Esteban Lorenzano

> On 29 Sep 2015, at 01:13, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : >> >> If there are so many windows users, then how can it be that none of them >> managed to explain what the actual problem with stdio handling is. I had >> asked about the problem a while ago, but I still haven't got an answer: >> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >> >> Levente >> > > The problem is that gitfiletree use OSProcess and OSProcess use Stdio to > get the state or the exit value of a command for example. > But in Windows Stdio is just an ugly hack. It doesn't use the stdio but > create 3 files (stdin, stderr' stdout) in the working directory and > write/read this files. But as Windows doesn't use that we can't > communicate with the system. ah yes, I remember when I made that :) it was for been able to run CI on windowsâ¦ and I remember I told Christophe âletâs do this crap until we find a real solutionâ. That was like 4yrs ago :P So, I still does not have a real solution because GetStdHandle funtion in windows does not work for non console apps. Maybe we could solve this redirecting the outputs (SetStdHandle)? Iâm not a windows user and I donât really know deeply this stuff, but Iâd gladly accept any contribution to fix this issue (or at least to fix OSProcess). Esteban > > I tried to have some look at it but I don't even know if it is a vm or > an image problem. Some says that the dll for that is wrong, some says > that this is an image problem. I don't have the knowledge and the time > to go deeper on that problem. > > So in order to fix a lot of problem on windows we need to fix the Stdio > but we need someone who have the time and the knowledge and we do not > have a lot of developers that can manage stdio on windows even if we > have users. > > -- > Cheers > Cyril >

Sept. 29, 2015

Re: [Pharo-dev] PharoTouch Demo Video

by stepharo

Le 28/9/15 16:55, Stephan Eggermont a Ã©crit : > On 28-09-15 16:22, Marcus Denker wrote: >> Pharo touch demo with the new OSWindows architecture, touch events, >> vector graphics using Athens and libsdl2. >> >> Thanks the people involved (specifically for the touch project >> Christopher Coat, Mervan Ougdane, Jan-Baptiste Arnaud, >> Eric Lepors and Mathieu Lacaton) and to Thales for sponsoring this >> project. >> >> https://www.youtube.com/watch?v=ksyoGItedVg >> <https://www.youtube.com/watch?v=ksyoGItedVg> > > Nice. What kind of hardware do you need for this? Is it just a > capacitive multi touch screen monitor that supports windows 8/10? yes I think so. > > Stephan > > > >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

Hi Levente, Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : > On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote: > >> An other point is that git file tree will not work on Windows if we do >> not fix the problem of the stdio. And a lot of people out of the >> community use Windows, so this is not a issue we should forget. Most of >> the people I know in company use Windows, so if we want to attract >> people this problem need to be corrected. > > If there are so many windows users, then how can it be that none of them > managed to explain what the actual problem with stdio handling is. I had > asked about the problem a while ago, but I still haven't got an answer: > http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . Well, I changed the code using ProcessWrapper with your suggestions following that exchange, but my code stay fairly naive [1] (and would need to run under debug), and I didn't have someone testing on Windows. Am I writing that code correctly? If you see the equivalent code using OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on the external commands framework, I am prepared to work very closely with that layer including inside the vm plugin code (and David T Lewis helped me a lot to fix random lockups we had). Thierry (*) Running the gitfiletree integration tests launches probably over a hundred external commands in quick succession. [1] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… [2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/Monticello… > > Levente >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Levente Uzonyi

On Tue, 29 Sep 2015, Ferlicot D. Cyril wrote: > Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : >> >> If there are so many windows users, then how can it be that none of them >> managed to explain what the actual problem with stdio handling is. I had >> asked about the problem a while ago, but I still haven't got an answer: >> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >> >> Levente >> > > The problem is that gitfiletree use OSProcess and OSProcess use Stdio to > get the state or the exit value of a command for example. If you check the message I linked, it says GitFileTree uses ProcessWrapper instead of OSProcess on Windows. > But in Windows Stdio is just an ugly hack. It doesn't use the stdio but > create 3 files (stdin, stderr' stdout) in the working directory and > write/read this files. But as Windows doesn't use that we can't > communicate with the system. ProcessWrapper allows you to access the three streams from the image without creating files. Levente > > I tried to have some look at it but I don't even know if it is a vm or > an image problem. Some says that the dll for that is wrong, some says > that this is an image problem. I don't have the knowledge and the time > to go deeper on that problem. > > So in order to fix a lot of problem on windows we need to fix the Stdio > but we need someone who have the time and the knowledge and we do not > have a lot of developers that can manage stdio on windows even if we > have users. > > -- > Cheers > Cyril > >

Sept. 29, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Dale Henrichs

On 09/28/2015 04:13 PM, Ferlicot D. Cyril wrote: > Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : >> If there are so many windows users, then how can it be that none of them >> managed to explain what the actual problem with stdio handling is. I had >> asked about the problem a while ago, but I still haven't got an answer: >> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . >> >> Levente >> > The problem is that gitfiletree use OSProcess and OSProcess use Stdio to > get the state or the exit value of a command for example. > But in Windows Stdio is just an ugly hack. It doesn't use the stdio but > create 3 files (stdin, stderr' stdout) in the working directory and > write/read this files. But as Windows doesn't use that we can't > communicate with the system. > > I tried to have some look at it but I don't even know if it is a vm or > an image problem. Some says that the dll for that is wrong, some says > that this is an image problem. I don't have the knowledge and the time > to go deeper on that problem. > > So in order to fix a lot of problem on windows we need to fix the Stdio > but we need someone who have the time and the knowledge and we do not > have a lot of developers that can manage stdio on windows even if we > have users. +1 ... yeah the stderr is not fun ... I did add some bash error traps (see my other message about using Git Bash on windows as part of GitHub Desktop for Windows) so that I could at least arrange to have stderr dumped to stdout on an error ... Dale

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Dale Henrichs

The big issue for git and windows (in general) is that there is a 255 character limit on the paths for files .... I recently pruned some file names for Metacello (on a win-hack branch) just to get Metacello to work with filetree .. Working with Github Desktop[1] for Windows makes the experience of using git from the command line tolerable on Windows - you get a retty nice bash shell to work with so as a non-windows user I can work in a pretty familiar environment ... At the moment I'm working with Pharo3.0 on Windows, so I don't have any useful feedback right now (assuming things have changed a bit on Windows with Pharo4.0 and Pharo5.0) ... Dale [1] https://desktop.github.com/ On 09/28/2015 03:39 PM, Peter UhnÃ¡k wrote: > > If there are so many windows users > > > There are many windows users, > there are NOT many windows + git users. > Probably because everyone gives up on gitfiletree after ten minutes > and switch to regular filetree. > > I think that none of the developers of Git in Pharo / gitfiletree use > Windows, so some new who knows both Git and Windows well would need to > come around at look into it. Or someone new who is interested in it > enough that is willing to spend his time understanding it and then > fixing it. > > Peter

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ferlicot D. Cyril

Le 28/09/2015 23:54, Levente Uzonyi a Ã©crit : > > If there are so many windows users, then how can it be that none of them > managed to explain what the actual problem with stdio handling is. I had > asked about the problem a while ago, but I still haven't got an answer: > http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . > > Levente > The problem is that gitfiletree use OSProcess and OSProcess use Stdio to get the state or the exit value of a command for example. But in Windows Stdio is just an ugly hack. It doesn't use the stdio but create 3 files (stdin, stderr' stdout) in the working directory and write/read this files. But as Windows doesn't use that we can't communicate with the system. I tried to have some look at it but I don't even know if it is a vm or an image problem. Some says that the dll for that is wrong, some says that this is an image problem. I don't have the knowledge and the time to go deeper on that problem. So in order to fix a lot of problem on windows we need to fix the Stdio but we need someone who have the time and the knowledge and we do not have a lot of developers that can manage stdio on windows even if we have users. -- Cheers Cyril

Sept. 28, 2015

TestAsserter>>assertCollection:hasSameElements:

by Peter UhnÃ¡k

How practical it is to do set-based comparison in TestAsserter>>assertCollection:hasSameElements: ? For example #(1 1 2) has same elements as #(1 2) which may make sense for sets, but not for bags. The main reason I was using it is that in tests the expected collection may be created by hand, which means it is very often an array #(...), { ... }, while models very often return OrderedCollections (at least in my case). So my question is --- how to compare collections irrespective of type, and possibly of order? A) always convert the actual collection toanArray B) change difference: behavior for non-sets (ton of work with catastrophic consequences) C) extend TAssertable with new methods like #assertElementsOf: actualCollection equals: expectedCollection #assertUnorderedElementsOf: actualCollection equals: expectedCollection C.a) directly in Pharo/SUnit C.b) in independend SUnit-Extensions repository/project C.c) just in my project D) stop discussing non-problems Thanks, Peter

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Peter UhnÃ¡k

> > If there are so many windows users There are many windows users, there are NOT many windows + git users. Probably because everyone gives up on gitfiletree after ten minutes and switch to regular filetree. I think that none of the developers of Git in Pharo / gitfiletree use Windows, so some new who knows both Git and Windows well would need to come around at look into it. Or someone new who is interested in it enough that is willing to spend his time understanding it and then fixing it. Peter

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Levente Uzonyi

On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote: > Le 27/09/2015 12:11, Dimitris Chloupis a Ã©crit : >> we have more than a nice Git integration. I have been using Github for >> my pharo project for over a year now without any issue, the last few >> months I have been using gitfiltree which is making it even easier. >> Definitely beats the alternatives . >> > > Hi! > > Did you try to use git on a big project with a team? Did you try to > merge .st files ? > I heard it's really annoying to merge files with meta informations on git. > > An other point is that git file tree will not work on Windows if we do > not fix the problem of the stdio. And a lot of people out of the > community use Windows, so this is not a issue we should forget. Most of > the people I know in company use Windows, so if we want to attract > people this problem need to be corrected. If there are so many windows users, then how can it be that none of them managed to explain what the actual problem with stdio handling is. I had asked about the problem a while ago, but I still haven't got an answer: http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 . Levente > >> On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel >> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> â¦ Pharo may be within the 30 most popular languages on Earth. >> The 30th languages has 3,253 repository. There are 2,635 on >> SmalltalkHub. >> >> I wish we had a nice Git integration. >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- > Cheers > Cyril > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by phil＠highoctane.be

Well, there is some kind of but I was tired and the stream broke as my internet connection went bust. (and I should have done the full setup). Ah these things pile up. Still, one can see the trainwreck over here: https://www.livecoding.tv/philippeback/videos/ Pick the things with "git" in the tile. Phil On Mon, Sep 28, 2015 at 10:59 AM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > philippe.back(a)highoctane.be <philippe.back(a)gmail.com> writes: > > > It isn't. It is actually very easy to use git. > > > > Time for a video :-) > > > > Expect that for tomorrow. > > tomorrow is today :-). We expect it! > > Thanks Philippe > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Dale Henrichs

On 9/27/15 11:53 PM, stepharo wrote: > > > Le 27/9/15 15:33, Peter UhnÃ¡k a Ã©crit : >> >> Because to me git is **really** complex. I do not talk about add >> push commit but rebase remote.... >> >> >> Git allows you to do complex things if you need them. >> But you can easily use git without ever needing rebase, filter-branch >> or whatnot. >> >> Everything that Monticello can do can be done with git easily >> (commit, push, pull, merge). >> It just gives you much more powerful tools. > > sure except that suddenly you do not know why you have to know the > arcanes part. > I think that git is not layered so you get exposed to a lot of details > even when you avoid. > May be having a set of git macros would help. Stef, I have been working on this problem for several years now with tODE and in tODE I've been able to build a project tool that handles the mundane everyday, commit/checkout/branch/push/pull operations using menu items ... this approach means that folks can choose to use a git workflow that matches their whims/needs --- without having to become intimately familiar with the more arcane bits of git. I did find that it is absolutely necessary to have a Smalltalk gui based git merge tool ... there are non-smalltalk merge tools out there, but I prefer to do my merges in the comfort of my Smalltalk development environment:) ... Another tool that is important is what I call `skew diff` and `skew merge` ... `skew` happens when a git repository on disk is checked out to a commit that differs from the commit when the packages were loaded into an image (think of an image that has been sitting unused for a couple of months). Metacello has features for making it possible to record the SHA of the commit present when a project is loaded from a git repository and my project tool compares this SHA with the current SHA of the git repository and notices when SHA skew occurs ... `skew diff` and `skew merge` were invented to help a developer understand the implications and repair (if necessary) - more often than not a simple load (or ignoring the skew) sufficient, but it is imperative that a developer be notified that this skew is present ... Sooooo, I think that Pharo-based tools can be built so that developers can go about there daily work without ever having to drop down to the git command-line (macros or no macros)... Dale

Sept. 28, 2015

Re: [Pharo-dev] PharoTouch Demo Video

by Stephan Eggermont

On 28-09-15 16:22, Marcus Denker wrote: > Pharo touch demo with the new OSWindows architecture, touch events, vector graphics using Athens and libsdl2. > > Thanks the people involved (specifically for the touch project Christopher Coat, Mervan Ougdane, Jan-Baptiste Arnaud, > Eric Lepors and Mathieu Lacaton) and to Thales for sponsoring this project. > > https://www.youtube.com/watch?v=ksyoGItedVg <https://www.youtube.com/watch?v=ksyoGItedVg> Nice. What kind of hardware do you need for this? Is it just a capacitive multi touch screen monitor that supports windows 8/10? Stephan

Sept. 28, 2015

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by Marcus Denker

> On 20 Sep 2015, at 16:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 19 Sep 2015, at 01:10, stepharo <stepharo(a)free.fr> wrote: >> >> Marcus I have a API design question >> >> when you offer >> >> options: #(optionOneShot); >> >> versus >> >> optionOneShot >> >> Do you do a perform of the arrays selectors? >> What is the benefit of options: > > I needed a mechanism for flags (stored not each in an ivar, as they normally > not active). As we have this mechanism in Opal already, I decided to use the > same pattern. > As in Opal, for all the pre-defined options we should not rely on perform: but > have explicit #optionOneShot getter/setter methods. I will add those later.. > DONE: https://pharo.fogbugz.com/f/cases/16654/test-for-optionOneShot-and-accessor… <https://pharo.fogbugz.com/f/cases/16654/test-for-optionOneShot-and-accessor…> Marcus

Sept. 28, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50345 Home: https://github.com/pharo-project/pharo-core

Sept. 28, 2015

[pharo-project/pharo-core] 306d76: 50345

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 306d7616cbcc0f10b4931ae71c3dc296869a8d35 https://github.com/pharo-project/pharo-core/commit/306d7616cbcc0f10b4931ae7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-28 (Mon, 28 Sep 2015) Changed paths: M Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuColor.st A Refactoring-Critics.package/PharoCriticRules.class/README.md A Refactoring-Critics.package/PharoCriticRules.class/class/accessing/pharoIntegrationLintRule.st A Refactoring-Critics.package/PharoCriticRules.class/class/default rules/pharoHardLintRules.st A Refactoring-Critics.package/PharoCriticRules.class/class/default rules/pharoSoftLintRules.st A Refactoring-Critics.package/PharoCriticRules.class/definition.st R Refactoring-Critics.package/RBCompositeLintRule.class/class/default rules/pharoHardLintRules.st R Refactoring-Critics.package/RBCompositeLintRule.class/class/default rules/pharoSoftLintRules.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50344.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50345.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50344.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50345.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/class/instance creation/openWithEnvironment_removeTestCase_.st R Tool-CriticBrowser.package/SelectRuleBrowser.class/class/instance creation/pharoIntegrationRules.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/definition.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/accessing/items_.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/addAllItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/addItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/nextAction.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/removeAllItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/removeItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/initialization/initialize.st A Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/private/isSelected_.st Log Message: ----------- 50345 16652 Menues now have a very strange reddish color https://pharo.fogbugz.com/f/cases/16652 16631 Move integration rules to a PharoCriticRules class https://pharo.fogbugz.com/f/cases/16631 http://files.pharo.org/image/50/50345.zip

Sept. 28, 2015

PharoTouch Demo Video

by Marcus Denker

Pharo touch demo with the new OSWindows architecture, touch events, vector graphics using Athens and libsdl2. Thanks the people involved (specifically for the touch project Christopher Coat, Mervan Ougdane, Jan-Baptiste Arnaud, Eric Lepors and Mathieu Lacaton) and to Thales for sponsoring this project. https://www.youtube.com/watch?v=ksyoGItedVg <https://www.youtube.com/watch?v=ksyoGItedVg>

Sept. 28, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

by Marcus Denker

Yes, debug code left. I fixed it alreadyâ¦ I should have seen it when going through the diff... > On 28 Sep 2015, at 15:57, Henrik Nergaard <henrin10(a)student.uia.no> wrote: > > Yeah, that might be my mistake. > Looking into it now -> loading 16648 changes the color. > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Marcus Denker > Sent: Monday, September 28, 2015 3:44 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344 > > There is some strange side effect that now the menus have a very odd reddish color. > > I guess this is caused somehow by 16648 or maybe even 16647? > > I added a new issue tracker entry for that: > > https://pharo.fogbugz.com/f/cases/16652/Menues-now-have-a-very-strange-redd… > > >> Log Message: >> ----------- >> 50344 >> 16647 Nautilus Variable Menu Improvement >> https://pharo.fogbugz.com/f/cases/16647 >> >> 16648 ThemeSettings protocol cleanup >> https://pharo.fogbugz.com/f/cases/16648 >> >> 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals >> https://pharo.fogbugz.com/f/cases/16649 >> >> http://files.pharo.org/image/50/50344.zip >> >> > > >

Sept. 28, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

by Henrik Nergaard

Yeah, that might be my mistake. Looking into it now -> loading 16648 changes the color. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Marcus Denker Sent: Monday, September 28, 2015 3:44 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344 There is some strange side effect that now the menus have a very odd reddish color. I guess this is caused somehow by 16648 or maybe even 16647? I added a new issue tracker entry for that: https://pharo.fogbugz.com/f/cases/16652/Menues-now-have-a-very-strange-redd… > Log Message: > ----------- > 50344 > 16647 Nautilus Variable Menu Improvement > https://pharo.fogbugz.com/f/cases/16647 > > 16648 ThemeSettings protocol cleanup > https://pharo.fogbugz.com/f/cases/16648 > > 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals > https://pharo.fogbugz.com/f/cases/16649 > > http://files.pharo.org/image/50/50344.zip > >

Sept. 28, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

by Marcus Denker

There is some strange side effect that now the menus have a very odd reddish color. I guess this is caused somehow by 16648 or maybe even 16647? I added a new issue tracker entry for that: https://pharo.fogbugz.com/f/cases/16652/Menues-now-have-a-very-strange-redd… > Log Message: > ----------- > 50344 > 16647 Nautilus Variable Menu Improvement > https://pharo.fogbugz.com/f/cases/16647 > > 16648 ThemeSettings protocol cleanup > https://pharo.fogbugz.com/f/cases/16648 > > 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals > https://pharo.fogbugz.com/f/cases/16649 > > http://files.pharo.org/image/50/50344.zip > >

Sept. 28, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50344 Home: https://github.com/pharo-project/pharo-core

Sept. 28, 2015

[pharo-project/pharo-core] 07c9a0: 50344

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 07c9a04969c9a4afbe64c1eeeeca0dabfe5a1bee https://github.com/pharo-project/pharo-core/commit/07c9a04969c9a4afbe64c1ee… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-28 (Mon, 28 Sep 2015) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariableReferences.st A Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/buildVariableReferencesMenuFrom_withIcon_contentBy_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/autoMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/autoMenuColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpDelayTime.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpDelayTime_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpEnabled.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpEnabled_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/buttonColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/buttonColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/defaultButtonColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/derivedMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/fallbackMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/flatMenu.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/flatMenu_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/maxBalloonHelpLineLength.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/maxBalloonHelpLineLength_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuBorderColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuBorderWidth.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuKeyboardControl.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuKeyboardFocusColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionTextColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionTextColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuShadowColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleBorderColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarProgressColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarProgressColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/applySettingsFrom_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/fromConfiguration_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/toConfiguration_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpDelayTime.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpDelayTime_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpEnabled.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpEnabled_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/maxBalloonHelpLineLength.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/maxBalloonHelpLineLength_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/buttonColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/buttonColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/defaultButtonColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/autoMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/autoMenuColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/derivedMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/fallbackMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/flatMenu.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/flatMenu_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuBorderColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuBorderWidth.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuKeyboardControl.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuKeyboardFocusColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionTextColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionTextColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuShadowColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleBorderColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarProgressColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarProgressColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/applySettingsFrom_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/fromConfiguration_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/toConfiguration_.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableClass.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableContext.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableLink.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableName.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableObject.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableValue.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableVariable.st R Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalVariableName.st M Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalVariableValue.st M Reflectivity.package/RFClassReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFClassReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFLinkReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFLinkReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFNameReification.class/class/plugin interface/nodes.st M Reflectivity.package/RFObjectReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFObjectReification.class/instance/generate/genForLiteralVariable.st A Reflectivity.package/RFReification.class/instance/as yet unclassified/genForGlobalVariable.st M Reflectivity.package/RFThisContextReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFThisContextReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFValueReification.class/class/plugin interface/nodes.st M Reflectivity.package/RFVariableReification.class/class/plugin interface/nodes.st R Reflectivity.package/RFVariableReification.class/instance/generate/genForGlobal.st A Reflectivity.package/RFVariableReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFVariableReification.class/instance/generate/genForRBVariableNode.st R Reflectivity.package/RFVariableReification.class/instance/generate/genForSlot.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50343.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50344.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50343.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50344.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50344 16647 Nautilus Variable Menu Improvement https://pharo.fogbugz.com/f/cases/16647 16648 ThemeSettings protocol cleanup https://pharo.fogbugz.com/f/cases/16648 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals https://pharo.fogbugz.com/f/cases/16649 http://files.pharo.org/image/50/50344.zip

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Max Leske

> On 28 Sep 2015, at 13:57, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? Yes it could. Iâve been thinking about that too. There are some nice properties, e.g. 1 commit <-> one note (where a note can be tree). That way you donât get merge conflicts on changing metadata. However, youâd need to find an equivalent mechanism for each new SCM. Also, using such a mechanism is a bit obscure. But the idea definitely deserves some attention. Cheers, Max > > [1] http://git-scm.com/docs/git-notes > > cheers -ben >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> >> >> >> I have a vague recollection that the problem was a particular file >> >> where data changed each commit and having the idea that this might be >> >> solved by: each commit writing metadata to a different file e.g. >> >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> >> metadata. >> > >> > >> > Hum, I thought that as well, but in fact write the merge driver turned >> > out >> > as far better and simpler. Moreover, all type of data oriented files >> > (ston, json, version) do not merge properly in git. So even Esteban >> > saying >> > he will use STON does not seems to solve the merge issue, unless he is >> > planning something else. I do take in account we will have more metadata >> > in >> > the future, thanks to EPICEA, so we need a way to handle it. >> > >> > Merging is easy, you just need to hook into it. >> > >> > I believed also that we could do the merge ourselves and force git to >> > commit >> > the result, but discovered this was a bad idea. Imagine having to fire >> > Pharo >> > to merge a 250k OCaml project with 2k of st code in it :( >> >> btw, would "notes" [1] be useful for attaching metadata? >> "A typical use of notes is to supplement a commit message without >> changing the commit itself." >> Or is the metadata better inside the commit? > > > I don't know. What happens to notes when you merge? Do you need to fetch > down all the ancestors (some of them without notes, because it was a merge > of whatever external stuff was in the repository, so you need to recurse[2]) > and merge them yourself everytime? What happens if a guy do a by hand edit > of a st file and commits outside of Pharo? Can it work outside git (Fossil, > Mercury, bazaar)? Does it scale to a lot of metadata? > > Thierry > > [2] gitfiletree has that code, and it gives unintuitive, but correct, > results at time. > > >> >> [1] http://git-scm.com/docs/git-notes >> All good questions I don't have answers for. Its something I only came across last week and I'm still understanding its general usage pattern. cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Christophe Demarey

Le 28 sept. 2015 Ã 13:57, Ben Coman a Ã©crit : > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > > [1] http://git-scm.com/docs/git-notes I would not use that to store data useful to Pharo. Packages meta-data should be versioned at the same place that the code itself. Git is the trendy SCM but there are others. I prefer to not rely on a specific feature of a SCM to let door opened to others

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > Le 28/09/2015 04:27, Ben Coman a Ã©crit : > >> > >> > >> I have a vague recollection that the problem was a particular file > >> where data changed each commit and having the idea that this might be > >> solved by: each commit writing metadata to a different file e.g. > >> NNNN.metadata, and Monticello knows to pick up the highest numbered > >> metadata. > > > > > > Hum, I thought that as well, but in fact write the merge driver turned > out > > as far better and simpler. Moreover, all type of data oriented files > > (ston, json, version) do not merge properly in git. So even Esteban > saying > > he will use STON does not seems to solve the merge issue, unless he is > > planning something else. I do take in account we will have more metadata > in > > the future, thanks to EPICEA, so we need a way to handle it. > > > > Merging is easy, you just need to hook into it. > > > > I believed also that we could do the merge ourselves and force git to > commit > > the result, but discovered this was a bad idea. Imagine having to fire > Pharo > > to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > I don't know. What happens to notes when you merge? Do you need to fetch down all the ancestors (some of them without notes, because it was a merge of whatever external stuff was in the repository, so you need to recurse[2]) and merge them yourself everytime? What happens if a guy do a by hand edit of a st file and commits outside of Pharo? Can it work outside git (Fossil, Mercury, bazaar)? Does it scale to a lot of metadata? Thierry [2] gitfiletree has that code, and it gives unintuitive, but correct, results at time. > [1] http://git-scm.com/docs/git-notes > > cheers -ben > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> I have a vague recollection that the problem was a particular file >> where data changed each commit and having the idea that this might be >> solved by: each commit writing metadata to a different file e.g. >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> metadata. > > > Hum, I thought that as well, but in fact write the merge driver turned out > as far better and simpler. Moreover, all type of data oriented files > (ston, json, version) do not merge properly in git. So even Esteban saying > he will use STON does not seems to solve the merge issue, unless he is > planning something else. I do take in account we will have more metadata in > the future, thanks to EPICEA, so we need a way to handle it. > > Merging is easy, you just need to hook into it. > > I believed also that we could do the merge ourselves and force git to commit > the result, but discovered this was a bad idea. Imagine having to fire Pharo > to merge a 250k OCaml project with 2k of st code in it :( btw, would "notes" [1] be useful for attaching metadata? "A typical use of notes is to supplement a commit message without changing the commit itself." Or is the metadata better inside the commit? [1] http://git-scm.com/docs/git-notes cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] [Pharo-users] Changing method icons priorities in nautilus

by Damien Cassou

Peter UhnÃ¡k <i.uhnak(a)gmail.com> writes: > So would it make sense to swap the priority? I agree with you. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Changing method icons priorities in nautilus

by Peter UhnÃ¡k

Hi, is it a good idea to have the test icon have higher priority than overrides (is overriding parent method/the method is overriden by a child) â Because the state of the test is also available from: 1) the test class itself 2) TestRunner (and one of the two I will have open regardless) And often a method affects more than one test so the icon is not representative of the state anyway. On the other hand if I want to reach the overriden method it's much harder because I have to open new browser, click on the class, find the method. So would it make sense to swap the priority? There's long standing issue in the tracker with having multiple icons per method, but resolving that from UI perspective is perhaps not as easy... (The remaining priorities seem ok... higher number = more important) â Peter

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Stephan Eggermont

On 28-09-15 04:27, Ben Coman wrote: > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. There is no such thing as one workflow. That is to say, the one workflow is simply very complicated, as different people need to solve different problems with design data management. The problems of the core pharo team are not those of the community. To do this well it would be good to work with personas, like in http://gsoc2013.esug.org/projects/distributed-issue-tracker Adoption will come only when a sufficiently large, consistent and complete part of the stakeholders needs is covered. Personas are also very useful to drive the documentation. Stephan

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Alexandre Bergel

Video are good. But please, do not show trivial things. Show us an example with several users and conflict resolution. Alexandre > On Sep 28, 2015, at 10:59 AM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > philippe.back(a)highoctane.be <philippe.back(a)gmail.com> writes: > >> It isn't. It is actually very easy to use git. >> >> Time for a video :-) >> >> Expect that for tomorrow. > > tomorrow is today :-). We expect it! > > Thanks Philippe > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Damien Cassou

philippe.back(a)highoctane.be <philippe.back(a)gmail.com> writes: > It isn't. It is actually very easy to use git. > > Time for a video :-) > > Expect that for tomorrow. tomorrow is today :-). We expect it! Thanks Philippe -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Damien Cassou

Alexandre Bergel <alexandre.bergel(a)me.com> writes: > I have tried several times to use Git for my project. But I do not > want to spend time on configuring .gitattribute and other > configuration file. This does not go in the right direction I believe. > Why is it easier to use git with Java than it is with Pharo? I disagree, I think configuring .gitattribute (for the merge driver) is an important step forward. It means that Pharo can control the merge. Currently, it's only useful for metadata. But later, it might be useful to facilitate code merges: e.g., a method is renamed in a branch and improved in another. This should not generate a conflict. With Epicea, we might be able to avoid this conflict in the future and drive the merge successfully. Another example: two branches each adds an instance variable to the same class. This should not generate a conflict. The merge driver could detect that and merge successfully. Final example: the merge driver could run the unit tests while merging to tell the developer when a merge is correct and when it is not. The merge driver means we can merge ASTs, not lines of source code. For me, the merge driver is the future, not the past. Thanks Thierry. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Peter UhnÃ¡k

> > sure except that suddenly you do not know why you have to know the arcanes >> part. >> I think that git is not layered so you get exposed to a lot of details >> even when you avoid. >> > Hmm, I don't see that, but I've been using git for many years so I am not in position to judge it how complex it is. > > >> May be having a set of git macros would help. >> > > Maybe not because macros are fragile and your average set of git commands > is rather limited. Making git simpler through Pharo could be nice... > Maybe providing a way to streamline common patterns. For example in git community there's a well known workflow model http://nvie.com/posts/a-successful-git-branching-model/ There's even git extension (but you can still use git directly) on top of that pattern https://github.com/nvie/gitflow (better visualized here https://danielkummer.github.io/git-flow-cheatsheet/ ) And while most don't follow the pattern strictly, most people are at least inspired by it and adapt parts of it. Peter

Sept. 28, 2015

Re: [Pharo-dev] World.st has a new admin

by Henrik Johansen

> On 24 Sep 2015, at 4:27 , Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > The admin duties have now been handed over to Sean DeNigris who kindly > volunteered to look after the www.world.st web presence as well as the > Nabble archived mailing list forums on forum.world.st. > > As mentioned in a previous post, I did establish The World of Smalltalk some > years ago I have now unfortunately too many other things on my plate. So I > feel a person who is closer to the Smalltalk action will be better suited to > take over the reins and I wish Sean all the best to continue! > > > > -- > View this message in context: http://forum.world.st/World-st-has-a-new-admin-tp4851811.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > Thanks for all the work, I've really appreciated using the forums! They have been, and continue to be, a pleasure to both browse and search compared to other mailing list web interfaces. Not to mention it's really nice to have one place to go to for all the Smalltalk lists. Cheers, Henry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-28 8:53 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 27/9/15 15:33, Peter UhnÃ¡k a Ã©crit : > > Because to me git is **really** complex. I do not talk about add push >> commit but rebase remote.... >> > > Git allows you to do complex things if you need them. > But you can easily use git without ever needing rebase, filter-branch or > whatnot. > > Everything that Monticello can do can be done with git easily (commit, > push, pull, merge). > It just gives you much more powerful tools. > > > sure except that suddenly you do not know why you have to know the arcanes > part. > I think that git is not layered so you get exposed to a lot of details > even when you avoid. > You probably nailed it when it comes to why git seems more complex that needs to be. > May be having a set of git macros would help. > Maybe not because macros are fragile and your average set of git commands is rather limited. Making git simpler through Pharo could be nice... Thierry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by stepharo

Le 27/9/15 15:33, Peter UhnÃ¡k a Ã©crit : > > Because to me git is **really** complex. I do not talk about add > push commit but rebase remote.... > > > Git allows you to do complex things if you need them. > But you can easily use git without ever needing rebase, filter-branch > or whatnot. > > Everything that Monticello can do can be done with git easily (commit, > push, pull, merge). > It just gives you much more powerful tools. sure except that suddenly you do not know why you have to know the arcanes part. I think that git is not layered so you get exposed to a lot of details even when you avoid. May be having a set of git macros would help. Stef

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

Le 28/09/2015 04:27, Ben Coman a Ã©crit : > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. Hum, I thought that as well, but in fact write the merge driver turned out as far better and simpler. Moreover, all type of data oriented files (ston, json, version) do not merge properly in git. So even Esteban saying he will use STON does not seems to solve the merge issue, unless he is planning something else. I do take in account we will have more metadata in the future, thanks to EPICEA, so we need a way to handle it. Merging is easy, you just need to hook into it. I believed also that we could do the merge ourselves and force git to commit the result, but discovered this was a bad idea. Imagine having to fire Pharo to merge a 250k OCaml project with 2k of st code in it :( > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. Unless you have some experience of Monticello, Metacello, the Pharo workflow, some of the workflow outside Pharo, and git, then defining this workflow is shooting in the dark. So, first attempts are either: - be flexible, so that you fit into a pre-existing workflow, and explore options, - be dictatorial in your shot in the dark, and pray you got it right. Now, we've solved all the hard points (apart from the Windows support), so we can imagine a future. Thierry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Max Leske

> On 28 Sep 2015, at 04:27, Ben Coman <btc(a)openInWorld.com> wrote: > > On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. >> Now, what I do believe is that we need to improve a couple of things: >> >> 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. >> 2) double commit is annoying. >> >> We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. >> Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). > > Would moving to libgit2 bypass the problem with stdio? Yes. We call out to libgit2 through NativeBoost. > >> Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. >> I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. > > >> After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) >> >> So I would do a âcall for pushingâ and ask community to spend some time making it work properly. >> >> cheers, >> Esteban >> >> >>> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: >>> >>> Alex do you know git? >>> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. > > cheers -ben > > >>> Did you try to use sourcetree (the UI for git) to understand what I mean? >>> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >>> >>> Now you can systematicall save your code with monticello and automatically publish it to git. >>> Esteban has a script for doing that. >>> >>> Stef >>> >>>> â¦ Pharo may be within the 30 most popular languages on Earth. >>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>>> >>>> I wish we had a nice Git integration. >>>> >>>> Alexandre >>> >>> >> >> >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by philippe.back＠highoctane.be

Le 28 sept. 2015 04:29, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > > On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > > > Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. > > Now, what I do believe is that we need to improve a couple of things: > > > > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. > > 2) double commit is annoying. > > > > We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. > > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). > > Would moving to libgit2 bypass the problem with stdio? > > > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. > > I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. > > > > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) > > > > So I would do a âcall for pushingâ and ask community to spend some time making it work properly. > > > > cheers, > > Esteban > > > > > >> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: > >> > >> Alex do you know git? > >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. Currently working in a distributed team with multiple companies. We use git and also Phabricator for reviews which is really great. I cant think of *not* using a DVCS and features like git rebase in such an environment. Phil > > cheers -ben > > > >> Did you try to use sourcetree (the UI for git) to understand what I mean? > >> So we cannot use git simply we have to propose a much nicer model on top of this assembly. > >> > >> Now you can systematicall save your code with monticello and automatically publish it to git. > >> Esteban has a script for doing that. > >> > >> Stef > >> > >>> â¦ Pharo may be within the 30 most popular languages on Earth. > >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. > >>> > >>> I wish we had a nice Git integration. > >>> > >>> Alexandre > >> > >> > > > > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. > Now, what I do believe is that we need to improve a couple of things: > > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. > 2) double commit is annoying. > > We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). Would moving to libgit2 bypass the problem with stdio? > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. > I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. I have a vague recollection that the problem was a particular file where data changed each commit and having the idea that this might be solved by: each commit writing metadata to a different file e.g. NNNN.metadata, and Monticello knows to pick up the highest numbered metadata. > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) > > So I would do a âcall for pushingâ and ask community to spend some time making it work properly. > > cheers, > Esteban > > >> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: >> >> Alex do you know git? >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... Git is very flexible which implies complexity for newcomers to it. What is required on top of git is a "well defined" workflow. I see sometimes on this mail-list that people design their tools for flexibility since they don't want to *impose* a workflow on people, which is a commendable philosophy, but slows adoption by newcomers. It may be useful to define "this is *the* way its done here" , with the standard proviso that there may be missteps that need to be tuned. cheers -ben >> Did you try to use sourcetree (the UI for git) to understand what I mean? >> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >> >> Now you can systematicall save your code with monticello and automatically publish it to git. >> Esteban has a script for doing that. >> >> Stef >> >>> â¦ Pharo may be within the 30 most popular languages on Earth. >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>> >>> I wish we had a nice Git integration. >>> >>> Alexandre >> >> > >

Sept. 28, 2015

[pharo-project/pharo-core] 6a2134: 50343

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6a21341a640e1e49f2b391d17f92f3731c08744f https://github.com/pharo-project/pharo-core/commit/6a21341a640e1e49f2b391d1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-27 (Sun, 27 Sep 2015) Changed paths: R AST-Core.package/RBParser.class/instance/private-parsing/parseNegatedNumber.st M AST-Core.package/RBParser.class/instance/private-parsing/parsePrimitiveObject.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testNegativeNumberError.st A Reflectivity-Tests.package/MetaLinkTest.class/instance/tests - misc/testAvailableReifications.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterMethodWithTemps.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitPrepareLinkAfter_.st A Reflectivity.package/extension/LiteralVariable/instance/availableReifications.st A Reflectivity.package/extension/RBProgramNode/instance/availableReifications.st A Reflectivity.package/extension/Slot/instance/availableReifications.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50342.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50343.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50342.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50343.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50343 16646 test + fix: #after mit access to temp in method https://pharo.fogbugz.com/f/cases/16646 16642 availableReifications: return the list of supported reifications for an entity https://pharo.fogbugz.com/f/cases/16642 16632 RBParser should reject - space literal https://pharo.fogbugz.com/f/cases/16632 http://files.pharo.org/image/50/50343.zip

Sept. 27, 2015