If all Pharo projects were on GitHub...
Locked
123
123
Re: If all Pharo projects were on GitHub...
 
|
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)
Re: If all Pharo projects were on GitHub...
|
|
2015-09-29 10:50 GMT+02:00 Henrik Johansen <[hidden email]>:
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
|
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by Thierry Goubier
2015-09-29 10:14 GMT+02:00 Thierry Goubier <[hidden email]>:
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.
|
Re: If all Pharo projects were on GitHub...
|
|
2015-09-29 14:02 GMT+02:00 Nicolai Hess <[hidden email]>:
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)
|
Re: If all Pharo projects were on GitHub...
|
|
2015-09-29 14:27 GMT+02:00 Nicolai Hess <[hidden email]>:
Ok, can you give me an example path for git on a windows system?
What is the crash like? Inside Pharo or vm crash? Thierry
|
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by Nicolai Hess
2015-09-29 14:27 GMT+02:00 Nicolai Hess <[hidden email]>:
still crashes, happens on calling #exitCode
|
Re: If all Pharo projects were on GitHub...
|
|
2015-09-29 14:34 GMT+02:00 Nicolai Hess <[hidden email]>:
It's a crash instead of a DNU, on the line ? command exitCode > 0 ifTrue: Thierry |
Re: If all Pharo projects were on GitHub...
|
|
2015-09-29 14:38 GMT+02:00 Thierry Goubier <[hidden email]>:
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. |
Re: If all Pharo projects were on GitHub...
|
|
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) > 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 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 > > > > > > > > > > |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by Henrik Sperre Johansen
On 09/29/2015 01:50 AM, Henrik Johansen
wrote:
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 |
Re: If all Pharo projects were on GitHub...
|
|
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:
|
|
|
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
|
Re: If all Pharo projects were on GitHub...
|
|
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:
|
|
|
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 |
Re: If all Pharo projects were on GitHub...
|
|
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. |
Re: If all Pharo projects were on GitHub...
|
|
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: This hack is now implemented in the latest squeak and pharo vm.
|
Re: If all Pharo projects were on GitHub...
|
|
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 |
Re: If all Pharo projects were on GitHub...
|
|
Same boat for PHP when using frameworks like ZendFramework2. Namespaces are in, along with composer modules etc. So looong pathes. Phil |
|
|
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by Nicolai Hess
Excellent!
On 09/30/2015 11:36 PM, Nicolai Hess
wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |