Google Code Shutdown
Locked
12
12
 
|
On Mon, 3 Aug 2015, Thierry Goubier wrote:
> Le 03/08/2015 21:56, David T. Lewis a écrit : >> The OSProcess implementation for Windows is incomplete. I recommend >> Levente's ProcessWrapper (http://www.squeaksource.com/ProcessWrapper/) as >> an alternative for Windows. > > And GitFileTree (the main reason for trying to crash the external process > support on Pharo :) ) uses ProcessWrapper on Windows and OSProcess elsewhere. > All the reports about the unstability of GitFileTree on Windows relate to the > combination GitFileTree + ProcessWrapper. > > Now, if someone knowledgeable with ProcessWrapper wants to check the code > calling it, I'm all for it :) runProcessWrapperGitCommand: aCommandString in: aDirectory | r | (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load ProcessWrapper' ]) ifNotNil: [ :pW | r := pW new useStdout; startWithShellCommand: self gitCommand , ' -C "' , (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , aCommandString; upToEnd ]. ^ r What is the actual problem with the code? Why is the command executed in a shell? Levente > > Thierry > >> >> Dave >> >> >>> Thanks for the links. Unfortunately none of these really explain what the >>> problem with OSProcess is. I see there were attempts to try using >>> ProcessWrapper instead of OSProcess on windows, but there's no feedback >>> on that thread, so there may be a solution out there, but no one is using >>> it. >>> >>> Levente >>> >>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>> >>>> On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <[hidden email]> wrote: >>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>> >>>> >>>>    but the git user experience under Windows has to be >>>> improved if we want to use efficiently the other >>>> functionalities of github (pull requests, commit, >>>> branches,…). >>>> >>>> >>>> Well some of the experience can be mitigated with tools like >>>> GitHub for Windows, but the main problem is that git with >>>> Pharo is incredibly unstable on Windows and crashes >>>> constantly. >>>> That's our experience >>>> with it so my colleague had to switch to pure filetree out >>>> of frustration. >>>> This however is NOT problem of git, it's problem of >>>> OSProcess. But it does render it almost unusable for now. >>>> (At least for us.) >>>> >>>> >>>> What's the problem with OSProcess on windows? >>>> >>>> >>>> http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html >>>> http://forum.world.st/gitfiletree-metadata-td4838970.html >>>> http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-td4806791.html >>>> >>>> >> >> >> >> > > > |
|
|
Hi Levente,
thanks for looking at it :) Le 03/08/2015 23:51, Levente Uzonyi a écrit : > On Mon, 3 Aug 2015, Thierry Goubier wrote: > >> Le 03/08/2015 21:56, David T. Lewis a écrit : >>> The OSProcess implementation for Windows is incomplete. I recommend >>> Levente's ProcessWrapper >>> (http://www.squeaksource.com/ProcessWrapper/) as >>> an alternative for Windows. >> >> And GitFileTree (the main reason for trying to crash the external >> process support on Pharo :) ) uses ProcessWrapper on Windows and >> OSProcess elsewhere. All the reports about the unstability of >> GitFileTree on Windows relate to the combination GitFileTree + >> ProcessWrapper. >> >> Now, if someone knowledgeable with ProcessWrapper wants to check the >> code calling it, I'm all for it :) > > The only code I could find is MCFileTreeGitRepository class's This is the one, yes. > runProcessWrapperGitCommand: aCommandString in: aDirectory > | r | > (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load > ProcessWrapper' ]) > ifNotNil: [ :pW | > r := pW new > useStdout; > startWithShellCommand: > self gitCommand , ' -C "' , > (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , > aCommandString; > upToEnd ]. > ^ r > > What is the actual problem with the code? Instability. Git commands fail, and, since GitFileTree uses a few of them, GitFileTree becomes unusable. > Why is the command executed in a shell? Because the OSProcess version was also executing in a shell (and so, by default, the git command had no path). In the current version, the git command has a path and the OSProcess side doesn't use the shell, so it could be the same. Should it be changed for ProcessWrapper as well? Thierry > Levente > >> >> Thierry >> >>> >>> Dave >>> >>> >>>> Thanks for the links. Unfortunately none of these really explain >>>> what the >>>> problem with OSProcess is. I see there were attempts to try using >>>> ProcessWrapper instead of OSProcess on windows, but there's no feedback >>>> on that thread, so there may be a solution out there, but no one is >>>> using >>>> it. >>>> >>>> Levente >>>> >>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>> >>>>> On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <[hidden email]> wrote: >>>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>>> >>>>> >>>>>    but the git user experience under Windows has >>>>> to be >>>>> improved if we want to use efficiently the other >>>>> functionalities of github (pull requests, commit, >>>>> branches,…). >>>>> >>>>> >>>>> Well some of the experience can be mitigated with >>>>> tools like >>>>> GitHub for Windows, but the main problem is that git with >>>>> Pharo is incredibly unstable on Windows and crashes >>>>> constantly. >>>>> That's our experience >>>>> with it so my colleague had to switch to pure filetree >>>>> out >>>>> of frustration. >>>>> This however is NOT problem of git, it's problem of >>>>> OSProcess. But it does render it almost unusable for now. >>>>> (At least for us.) >>>>> >>>>> >>>>> What's the problem with OSProcess on windows? >>>>> >>>>> >>>>> http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html >>>>> http://forum.world.st/gitfiletree-metadata-td4838970.html >>>>> http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-td4806791.html >>>>> >>>>> >>>>> >>> >>> >>> >>> >> >> >> |
|
|
On Tue, 4 Aug 2015, Thierry Goubier wrote:
> Hi Levente, > > thanks for looking at it :) > > Le 03/08/2015 23:51, Levente Uzonyi a écrit : >> On Mon, 3 Aug 2015, Thierry Goubier wrote: >> >>> Le 03/08/2015 21:56, David T. Lewis a écrit : >>>> The OSProcess implementation for Windows is incomplete. I recommend >>>> Levente's ProcessWrapper >>>> (http://www.squeaksource.com/ProcessWrapper/) as >>>> an alternative for Windows. >>> >>> And GitFileTree (the main reason for trying to crash the external >>> process support on Pharo :) ) uses ProcessWrapper on Windows and >>> OSProcess elsewhere. All the reports about the unstability of >>> GitFileTree on Windows relate to the combination GitFileTree + >>> ProcessWrapper. >>> >>> Now, if someone knowledgeable with ProcessWrapper wants to check the >>> code calling it, I'm all for it :) >> >> The only code I could find is MCFileTreeGitRepository class's > > This is the one, yes. > >> runProcessWrapperGitCommand: aCommandString in: aDirectory >> | r | >> (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load >> ProcessWrapper' ]) >> ifNotNil: [ :pW | >> r := pW new >> useStdout; >> startWithShellCommand: >> self gitCommand , ' -C "' , >> (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , >> aCommandString; >> upToEnd ]. >> ^ r >> >> What is the actual problem with the code? > > Instability. Git commands fail, and, since GitFileTree uses a few of them, > GitFileTree becomes unusable. Do you have a reproducible case? Have you tried enabling logging to see what happens when the error occurs? (You can do it by evaluating [ProcessWrapper logLevelDebug]. This will create a log file named ProcessWrapper.log, and log the activities of the plugin there.) > >> Why is the command executed in a shell? > > Because the OSProcess version was also executing in a shell (and so, by > default, the git command had no path). > > In the current version, the git command has a path and the OSProcess side > doesn't use the shell, so it could be the same. Should it be changed for > ProcessWrapper as well? If git doesn't have to be run from a shell on windows, then it's probably better to not use a shell. Levente > > Thierry > > >> Levente >> >>> >>> Thierry >>> >>>> >>>> Dave >>>> >>>> >>>>> Thanks for the links. Unfortunately none of these really explain >>>>> what the >>>>> problem with OSProcess is. I see there were attempts to try using >>>>> ProcessWrapper instead of OSProcess on windows, but there's no feedback >>>>> on that thread, so there may be a solution out there, but no one is >>>>> using >>>>> it. >>>>> >>>>> Levente >>>>> >>>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>>> >>>>>> On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <[hidden email]> wrote: >>>>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>>>> >>>>>> >>>>>>    but the git user experience under Windows has >>>>>> to be >>>>>> improved if we want to use efficiently the other >>>>>> functionalities of github (pull requests, commit, >>>>>> branches,…). >>>>>> >>>>>> >>>>>> Well some of the experience can be mitigated with >>>>>> tools like >>>>>> GitHub for Windows, but the main problem is that git with >>>>>> Pharo is incredibly unstable on Windows and crashes >>>>>> constantly. >>>>>> That's our experience >>>>>> with it so my colleague had to switch to pure filetree >>>>>> out >>>>>> of frustration. >>>>>> This however is NOT problem of git, it's problem of >>>>>> OSProcess. But it does render it almost unusable for now. >>>>>> (At least for us.) >>>>>> >>>>>> >>>>>> What's the problem with OSProcess on windows? >>>>>> >>>>>> >>>>>> http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html >>>>>> http://forum.world.st/gitfiletree-metadata-td4838970.html >>>>>> http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-td4806791.html >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>> >>> >>> > > > |
|
|
Le 04/08/2015 19:13, Levente Uzonyi a écrit :
> On Tue, 4 Aug 2015, Thierry Goubier wrote: > >> Hi Levente, >> >> thanks for looking at it :) >> >> Le 03/08/2015 23:51, Levente Uzonyi a écrit : >>> On Mon, 3 Aug 2015, Thierry Goubier wrote: >>> >>>> Le 03/08/2015 21:56, David T. Lewis a écrit : >>>>> The OSProcess implementation for Windows is incomplete. I recommend >>>>> Levente's ProcessWrapper >>>>> (http://www.squeaksource.com/ProcessWrapper/) as >>>>> an alternative for Windows. >>>> >>>> And GitFileTree (the main reason for trying to crash the external >>>> process support on Pharo :) ) uses ProcessWrapper on Windows and >>>> OSProcess elsewhere. All the reports about the unstability of >>>> GitFileTree on Windows relate to the combination GitFileTree + >>>> ProcessWrapper. >>>> >>>> Now, if someone knowledgeable with ProcessWrapper wants to check the >>>> code calling it, I'm all for it :) >>> >>> The only code I could find is MCFileTreeGitRepository class's >> >> This is the one, yes. >> >>> runProcessWrapperGitCommand: aCommandString in: aDirectory >>> | r | >>> (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load >>> ProcessWrapper' ]) >>> ifNotNil: [ :pW | >>> r := pW new >>> useStdout; >>> startWithShellCommand: >>> self gitCommand , ' -C "' , >>> (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , >>> aCommandString; >>> upToEnd ]. >>> ^ r >>> >>> What is the actual problem with the code? >> >> Instability. Git commands fail, and, since GitFileTree uses a few of >> them, GitFileTree becomes unusable. > > What does "fail" mean here? > Do you have a reproducible case? I don't have anything there because I don't use Windows. I wrote the windows support the best I could without running it, hoping for a microsoft user to confirm it would work :( > Have you tried enabling logging to see what happens when the error > occurs? (You can do it by evaluating [ProcessWrapper logLevelDebug]. > This will create a log file named ProcessWrapper.log, and log the > activities of the plugin there.) Good to know. >> >>> Why is the command executed in a shell? >> >> Because the OSProcess version was also executing in a shell (and so, >> by default, the git command had no path). >> >> In the current version, the git command has a path and the OSProcess >> side doesn't use the shell, so it could be the same. Should it be >> changed for ProcessWrapper as well? > > If git doesn't have to be run from a shell on windows, then it's > probably better to not use a shell. Ok, I'll change that as soon as I reach a better situation to do some coding. Thierry > Levente > >> >> Thierry >> >> >>> Levente >>> >>>> >>>> Thierry >>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>>> Thanks for the links. Unfortunately none of these really explain >>>>>> what the >>>>>> problem with OSProcess is. I see there were attempts to try using >>>>>> ProcessWrapper instead of OSProcess on windows, but there's no >>>>>> feedback >>>>>> on that thread, so there may be a solution out there, but no one is >>>>>> using >>>>>> it. >>>>>> >>>>>> Levente >>>>>> >>>>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>>>> >>>>>>> On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <[hidden email]> >>>>>>> wrote: >>>>>>> On Mon, 3 Aug 2015, Peter Uhnák wrote: >>>>>>> >>>>>>> >>>>>>>    but the git user experience under Windows has >>>>>>> to be >>>>>>> improved if we want to use efficiently the other >>>>>>> functionalities of github (pull requests, commit, >>>>>>> branches,…). >>>>>>> >>>>>>> >>>>>>> Well some of the experience can be mitigated with >>>>>>> tools like >>>>>>> GitHub for Windows, but the main problem is that git with >>>>>>> Pharo is incredibly unstable on Windows and crashes >>>>>>> constantly. >>>>>>> That's our experience >>>>>>> with it so my colleague had to switch to pure filetree >>>>>>> out >>>>>>> of frustration. >>>>>>> This however is NOT problem of git, it's problem of >>>>>>> OSProcess. But it does render it almost unusable for now. >>>>>>> (At least for us.) >>>>>>> >>>>>>> >>>>>>> What's the problem with OSProcess on windows? >>>>>>> >>>>>>> >>>>>>> http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html >>>>>>> http://forum.world.st/gitfiletree-metadata-td4838970.html >>>>>>> http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-td4806791.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >> |
|
|
In reply to this post by Peter Uhnak
Why would it be a problem to manage just bug entries?
Did I miss something? Stef Le 3/8/15 11:56, Peter Uhnák a écrit :
|
|
|
No, you did not miss anything. I think there was a misunderstanding :). The GitHub repo is for entries only. But, we could try to mirror the SmalltalkHub repo into GitHub. I do not know how to do that, but if someone would like to do it, it would be great. Doru On Tue, Aug 4, 2015 at 9:20 PM, stepharo <[hidden email]> wrote:
|
|
Administrator
|
IIRC it's pretty easy. One can use GitFileTree to copy the packages from the St repo to the GH repo. Maybe someone has a script for this already?...
Cheers,
Sean |
|
|
I use this to keep my VMMaker mirror (as shown in https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/Spur-VMMaker-Tracker/configure): set -e eval `ssh-agent` ssh-add $HOME/.ssh/id_rsa_estebanlm PACKAGES="'VMMaker.oscog'" REPOSITORY=cog # Clone git clone -b spur64 [hidden email]:estebanlm/pharo-vm.git $REPOSITORY cd $REPOSITORY git config --local user.email "[hidden email]" git config --local user.name "Esteban Lorenzano" cd - # Get Pharo (and prepare it) wget -O- get.pharo.org/50+vm | bash ./pharo Pharo.image get OSProcess # Execute sync script ./pharo Pharo.image eval " | origin destination | origin := (MCHttpRepository location: 'http://source.squeak.org/VMMaker') instVarNamed: 'cacheFileNames' put: true; yourself. destination := MCFileTreeRepository new directory: '$REPOSITORY/mc' asFileReference ensureCreateDirectory; instVarNamed: 'cacheFileNames' put: true; yourself. #($PACKAGES) do: [ :eachPackageName | | infoOrigin infoDest versionNumber newer | VTermOutputDriver stdout black: 'Updating ', eachPackageName; lf. infoOrigin := origin versionInfoFromVersionNamed: eachPackageName. infoDest := destination versionInfoFromVersionNamed: eachPackageName. versionNumber := infoDest versionNumber. newer := (({infoOrigin}, (infoOrigin allAncestors)) select: [ :each | each versionNumber > versionNumber or: [ each versionNumber = versionNumber and: [ each id ~= infoDest id ] ] ]) sorted: [ :a :b | a timeStamp < b timeStamp ]. newer do: [ :each | | summary | [ VTermOutputDriver stdout green: ('New version: ', each name); lf. VTermOutputDriver stdout << 'Store ' << each name << ' in ' << destination description; cr. destination storeVersion: (origin versionFromFileNamed: (each name, '.mcz')). VTermOutputDriver stdout << 'Commit ' << each name; cr. summary := each summary copyReplaceTokens: String cr with: String crlf. OSProcess waitForCommand: '(cd $REPOSITORY; git add -A ; git commit -m \"', summary, '\")' ] on: Error do: [ :e | VTermOutputDriver stdout yellow: ('Warning: ', e messageText); lf ] ] ]. VTermOutputDriver stdout << 'OK'; cr. " cd $REPOSITORY git push --force origin spur64 git branch --verbose cd -
|
|
|
Some explanation:
- clone gut version into REPOSITORY - it will iterate list of PACKAGES and for each new version, will flush to disk and commit it with same commit message as monticello commit (so I can query messages without digging in mcz info) - it will do a push at the end I suppose it can be easily adapted to your needs :) Esteban
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |