Smalltalk › Pharo › Pharo Smalltalk Developers

If all Pharo projects were on GitHub...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

60 messages Options

123

Damien Cassou-2

Re: If all Pharo projects were on GitHub...

[hidden email] <[hidden email]> 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

abergel

Re: If all Pharo projects were on GitHub...

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 <[hidden email]> wrote:
>
>
> [hidden email] <[hidden email]> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Stephan Eggermont-3

Re: If all Pharo projects were on GitHub...

In reply to this post by Ben Coman

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

Ben Coman

Re: If all Pharo projects were on GitHub...

In reply to this post by Thierry Goubier

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
<[hidden email]> 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

Thierry Goubier

Re: If all Pharo projects were on GitHub...

2015-09-28 13:57 GMT+02:00 Ben Coman <[hidden email]>:

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
<[hidden email]> 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

demarey

Re: If all Pharo projects were on GitHub...

In reply to this post by Ben Coman

Le 28 sept. 2015 à 13:57, Ben Coman a écrit :

> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
> <[hidden email]> 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

smime.p7s (5K) Download Attachment

Ben Coman

Re: If all Pharo projects were on GitHub...

In reply to this post by Thierry Goubier

On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier
<[hidden email]> wrote:

>
>
> 2015-09-28 13:57 GMT+02:00 Ben Coman <[hidden email]>:
>>
>> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
>> <[hidden email]> 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

Max Leske

Re: If all Pharo projects were on GitHub...

In reply to this post by Ben Coman

> On 28 Sep 2015, at 13:57, Ben Coman <[hidden email]> wrote:
>
> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
> <[hidden email]> 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
>

Dale Henrichs-3

Re: If all Pharo projects were on GitHub...

In reply to this post by stepharo

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

philippeback

Re: If all Pharo projects were on GitHub...

In reply to this post by Damien Cassou-2

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 <[hidden email]> wrote:

[hidden email] <[hidden email]> 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

Levente Uzonyi-2

Re: If all Pharo projects were on GitHub...

In reply to this post by CyrilFerlicot

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
>> <[hidden email] <mailto:[hidden email]>> 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
>
>

Peter Uhnak

Re: If all Pharo projects were on GitHub...

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

CyrilFerlicot

Re: If all Pharo projects were on GitHub...

In reply to this post by Levente Uzonyi-2

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

signature.asc (836 bytes) Download Attachment

Dale Henrichs-3

Re: If all Pharo projects were on GitHub...

In reply to this post by Peter Uhnak

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

Dale Henrichs-3

Re: If all Pharo projects were on GitHub...

In reply to this post by CyrilFerlicot

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

Levente Uzonyi-2

Re: If all Pharo projects were on GitHub...

In reply to this post by CyrilFerlicot

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

Thierry Goubier

Re: If all Pharo projects were on GitHub...

In reply to this post by Levente Uzonyi-2

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/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st

[2]
https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st

>
> Levente
>

EstebanLM

Re: If all Pharo projects were on GitHub...

In reply to this post by CyrilFerlicot

> On 29 Sep 2015, at 01:13, Ferlicot D. Cyril <[hidden email]> 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

Nicolai Hess

Re: If all Pharo projects were on GitHub...

In reply to this post by Thierry Goubier

2015-09-29 7:05 GMT+02:00 Thierry Goubier <[hidden email]>:

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/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st

[2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st

Levente

Thierry Goubier

Re: If all Pharo projects were on GitHub...

2015-09-29 9:39 GMT+02:00 Nicolai Hess <[hidden email]>:

2015-09-29 7:05 GMT+02:00 Thierry Goubier <[hidden email]>:
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/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st

[2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st

Levente

123