- Pharo-dev - lists.pharo.org

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