- Pharo-dev - lists.pharo.org

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