If all Pharo projects were on GitHub...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Henrik Sperre Johansen

On 29 Sep 2015, at 1:48 , Dale Henrichs <[hidden email]> 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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thierry Goubier


2015-09-29 10:50 GMT+02:00 Henrik Johansen <[hidden email]>:

On 29 Sep 2015, at 1:48 , Dale Henrichs <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Nicolai Hess
In reply to this post by Thierry Goubier


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


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.


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






Reply | Threaded
Open this post in threaded view
|

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

Nicolai Hess


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


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

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.


1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(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)
                 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)

 

 

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







Reply | Threaded
Open this post in threaded view
|

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

Thierry Goubier


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


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


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

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.


1. git has to be on the path
2. windows does not understand /usr/bin/git

Ok, can you give me an example path for git on a windows system?
 
3. changing the above to

(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)
                 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

What is the crash like? Inside Pharo or vm crash?

Thierry
 

(with latest vm, I 'll try again with stable vm)

 

 

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








Reply | Threaded
Open this post in threaded view
|

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

Nicolai Hess
In reply to this post by Nicolai Hess


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


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


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

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.


1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(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)
                 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)

 

still crashes, happens on calling #exitCode

 

 

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








Reply | Threaded
Open this post in threaded view
|

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

Thierry Goubier

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


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


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


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

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.


1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(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)
                 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)

 

still crashes, happens on calling #exitCode

It's a crash instead of a DNU, on the line ?

command exitCode > 0
ifTrue:

Thierry
Reply | Threaded
Open this post in threaded view
|

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

Nicolai Hess


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

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


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


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


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

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.


1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(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)
                 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)

 

still crashes, happens on calling #exitCode

It's a crash instead of a DNU, on the line ?

command exitCode > 0
ifTrue:

Thierry

Yes, a crash.
I am not sure, I tried to remove the call to #exitCode
but it still crashes
I tried to debug the vm, but now it does not crash.

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi-2
In reply to this post by Nicolai Hess
On Tue, 29 Sep 2015, Nicolai Hess wrote:

>
>
> 2015-09-29 14:27 GMT+02:00 Nicolai Hess <[hidden email]>:
>
>
>       2015-09-29 14:02 GMT+02:00 Nicolai Hess <[hidden email]>:
>
>
>             2015-09-29 10:14 GMT+02:00 Thierry Goubier <[hidden email]>:
>
> 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.
>
>
> 1. git has to be on the path
> 2. windows does not understand /usr/bin/git
> 3. changing the above to
>
> (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)
There's a semicolon missing from the end of the line.

>                  yourself.
>             r := command upToEnd.
>
> makes it loading the git repository, but crashes afterwards.
>
> (with latest vm, I 'll try again with stable vm)
>
>  
>
>
> still crashes, happens on calling #exitCode
Does #isRunning return true when #exitCode is called? If so, the crash is
to be expected - aka it's a known issue. This is because one must not
request for the exit code, by sending #exitCode, before the process has
terminated.

If it keeps crashing, then you should consider enabling the plugin's log
to see what's happening.

Levente

>
>  
>
>  
>
> 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/runProcessWra
>       pperGitCommand.in..st
>
>       [2]https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessG
>       itCommand.in..st
>
>
>             Levente
>
>
>
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs-3
In reply to this post by Henrik Sperre Johansen


On 09/29/2015 01:50 AM, Henrik Johansen wrote:

On 29 Sep 2015, at 1:48 , Dale Henrichs <[hidden email]> 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...


Thanks Henry, I have done the `git config core.longpaths true` and I believe that that (supposedly) addresses manipulating long file paths problem for git, it does not help an application like pharo read the files with long paths ... without additional work ... and even then it's not clear that it truly fixes the problem ... because the fundamental limit is embedded in the OS ... for example from the git bash shell, I cannot `rm` the directories that have long paths (I have to use the explorer to delete them) and when I write out a package with long paths from Pharo3.0 the long path files are silently deleted ...

If it worked for you, that's good ... my experience was not quite as nice:)

Dale
Reply | Threaded
Open this post in threaded view
|

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

philippeback
Yes, about the git config core.longpaths true: works here as well.

It requires git for windows > 1.9 to work. My 1.8.x choked, had to upgrade.

I have checked out the VM code where there was the GeniePlugin problem and the issue was gone with that setup.

cp -r or rm -rf indeed give trouble.

If we used the Windows subst command to map a drive to some depth in the path and work from there, it would solve the issue. That's how I've done that for Java never ending directories in the past.

Operations are also very slow compared to Unix.

Phil




On Wed, Sep 30, 2015 at 6:47 PM, Dale Henrichs <[hidden email]> wrote:


On 09/29/2015 01:50 AM, Henrik Johansen wrote:

On 29 Sep 2015, at 1:48 , Dale Henrichs <[hidden email][hidden email]> 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...


Thanks Henry, I have done the `git config core.longpaths true` and I believe that that (supposedly) addresses manipulating long file paths problem for git, it does not help an application like pharo read the files with long paths ... without additional work ... and even then it's not clear that it truly fixes the problem ... because the fundamental limit is embedded in the OS ... for example from the git bash shell, I cannot `rm` the directories that have long paths (I have to use the explorer to delete them) and when I write out a package with long paths from Pharo3.0 the long path files are silently deleted ...

If it worked for you, that's good ... my experience was not quite as nice:)

Dale

Reply | Threaded
Open this post in threaded view
|

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

abergel
In reply to this post by Dale Henrichs-3
Why not having just one  folder level? As we would have in any other language? One folder per package, and inside a .st file per class. 

Alexandre 

Le 30 sept. 2015 à 18:47, Dale Henrichs <[hidden email]> a écrit :



On 09/29/2015 01:50 AM, Henrik Johansen wrote:

On 29 Sep 2015, at 1:48 , Dale Henrichs <[hidden email][hidden email]> 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...


Thanks Henry, I have done the `git config core.longpaths true` and I believe that that (supposedly) addresses manipulating long file paths problem for git, it does not help an application like pharo read the files with long paths ... without additional work ... and even then it's not clear that it truly fixes the problem ... because the fundamental limit is embedded in the OS ... for example from the git bash shell, I cannot `rm` the directories that have long paths (I have to use the explorer to delete them) and when I write out a package with long paths from Pharo3.0 the long path files are silently deleted ...

If it worked for you, that's good ... my experience was not quite as nice:)

Dale
Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs-3
1. the original code from Otto put each method in a file
2. I liked the idea of using git to manage method versions - and it is a really cool
    feature as git is able to maintain the history of a method (file) as the method is
    moved from class to class
3. Using directory structure actually enhanced the ability to create a cross-platform
    scheme, since directory structure parsing is easier than coming to an agreement
    on a common "fileout" format

With that said, assuming that a common fileout format can be agreed upon ...
there's no reason that a file per package or file per class format could be
invented ... If you or anyone else has the time to create such a beast then I say go for it ...

Given that we have a functional disk representation in hand, I don't think that searching for a new format (that will have it's own flaws) is a top priority ... regardless of what the disk format looks like there is a real void when it comes to the tool set ....

Finally the smalltalk community is not the only group that has trouble using git on windows because of the file path limitation ... so these guys that do file per package still run into trouble when using git on windows:)

Dale

On 9/30/15 11:57 AM, Alexandre Bergel wrote:
Why not having just one  folder level? As we would have in any other language? One folder per package, and inside a .st file per class. 

Alexandre 

Le 30 sept. 2015 à 18:47, Dale Henrichs <[hidden email]> a écrit :

Reply | Threaded
Open this post in threaded view
|

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

Jan Vrany
In reply to this post by Dale Henrichs-3
On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs 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 ..

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit
using special UNC pathnames like
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.

The "only" issue is that not all tools in the chain are using
this hack...

Jan


Reply | Threaded
Open this post in threaded view
|

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

Jigyasa Grover
In reply to this post by abergel
Agreed.

On Sun, Sep 27, 2015 at 3:27 PM, Alexandre Bergel <[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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





Reply | Threaded
Open this post in threaded view
|

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

Nicolai Hess
In reply to this post by Jan Vrany


2015-10-01 6:33 GMT+02:00 Jan Vrany <[hidden email]>:
On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs 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 ..

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit
using special UNC pathnames like
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.

This hack is now implemented in the latest squeak and pharo vm.
 

The "only" issue is that not all tools in the chain are using
this hack...

Jan



Reply | Threaded
Open this post in threaded view
|

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

Damien Cassou-2
In reply to this post by abergel

Alexandre Bergel <[hidden email]> writes:

> Why not having just one folder level? As we would have in any other
> language?

that's not true. In java, a Java path typically looks like:

project/src/main/java/org/apache/project/base/model/MyModel.java

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Reply | Threaded
Open this post in threaded view
|

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

philippe.back@highoctane.be


Le 1 oct. 2015 13:21, "Damien Cassou" <[hidden email]> a écrit :
>
>
> Alexandre Bergel <[hidden email]> writes:
>
> > Why not having just one folder level? As we would have in any other
> > language?
>
> that's not true. In java, a Java path typically looks like:
>
> project/src/main/java/org/apache/project/base/model/MyModel.java

Same boat for PHP when using frameworks like ZendFramework2.

Namespaces are in, along with composer modules etc. So looong pathes.

Phil
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

Reply | Threaded
Open this post in threaded view
|

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

abergel
In reply to this post by Damien Cassou-2
>> Why not having just one folder level? As we would have in any other
>> language?
>
> that's not true. In java, a Java path typically looks like:
>
> project/src/main/java/org/apache/project/base/model/MyModel.java

I sincerely wish we had a good git integration. The train is passing by.

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs-3
In reply to this post by Nicolai Hess
Excellent!

On 09/30/2015 11:36 PM, Nicolai Hess wrote:


2015-10-01 6:33 GMT+02:00 Jan Vrany <[hidden email]>:
On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs 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 ..

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit
using special UNC pathnames like
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.

This hack is now implemented in the latest squeak and pharo vm.
 

The "only" issue is that not all tools in the chain are using
this hack...

Jan




123