In case anyone hasn't heard, Google Code will shut down entirely on January 25, 2016. I was following these Smalltalk projects there: magritte-metamodel moose-technology seaside marsonpharo nativeboost metacello squeaksource3 phratch - already on GitHub per Jannik The easiest action seems to be to export to GitHub, for which Google Code even provides a button! I just used it for one of my projects and it was pretty painless. - Sean Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte, metacello ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Another project abandoned by Google, what a surprise :D On Tue, Mar 24, 2015 at 3:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
In case anyone hasn't heard, Google Code will shut down entirely on January 25, 2016. I was following these Smalltalk projects there: magritte-metamodel moose-technology seaside marsonpharo nativeboost metacello squeaksource3 phratch - already on GitHub per Jannik
The easiest action seems to be to export to GitHub, for which Google Code even provides a button! I just used it for one of my projects and it was pretty painless.
- Sean
Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte, metacello
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean P. DeNigris wrote
In case anyone hasn't heard, Google Code will shut down entirely on January 25, 2016.
UPDATE: Impending Deadline: "Google Code will be turning read-only on August 25th" Already Moved: magritte-metamodel phratch seaside metacello Unknown: moose-technology marsonpharo nativeboost squeaksource3 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840717.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Sean, Would you like to help us move the moose-technology project? Cheers, Doru On Sun, Aug 2, 2015 at 5:19 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
In case anyone hasn't heard, Google Code will shut down entirely on January 25, 2016.
UPDATE: Impending Deadline: "Google Code will be turning read-only on August 25th"
Already Moved: magritte-metamodel phratch seaside metacello
Unknown: moose-technology marsonpharo nativeboost squeaksource3
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840717.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Github is indeed appealing. Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :)) On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, Sorry but I am using Windows⦠not because I want to but because I have to... So the therapy will not work ;) Actually, the bugtracker of Moose can be on github, 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,â¦). Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Peter Uhnák Envoyé : lundi 3 août 2015 11:56 à : Pharo Development List Objet : Re: [Pharo-dev] Google Code Shutdown As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :)) On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com<mailto:alexandre.bergel@me.com>> wrote: Github is indeed appealing. Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com<mailto:sean@clipperadams.com>> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
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.) Peter
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? Levente
Peter
On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <leves@elte.hu> 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
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 <leves@elte.hu> 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
The OSProcess implementation for Windows is incomplete. I recommend Levente's ProcessWrapper (http://www.squeaksource.com/ProcessWrapper/) as an alternative for Windows. 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 <leves@elte.hu> 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 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 :) 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 <leves@elte.hu> 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 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 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 <leves@elte.hu> 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 <leves@elte.hu> 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.
What does "fail" mean here? 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 <leves@elte.hu> 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 <leves@elte.hu> 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
A workaround if you absolutely want to use gitfiletree is to install linux using a VM like virtual box , Ubuntu for example works very well with pharo https://www.virtualbox.org/ This way you avoid booting to another OS , you can also share your git folder to both windows and linux vm. This way you can use gitfiletree without ditching windows. Of course dual boot can work too if you dont need to use Pharo with windoom. VM option works also if you want to install MacOS on your windows pc. On Mon, Aug 3, 2015 at 1:13 PM Blondeau Vincent < vincent.blondeau@worldline.com> wrote:
Hi,
Sorry but I am using Windows⦠not because I want to but because I have to... So the therapy will not work ;)
Actually, the bugtracker of Moose can be on github, 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,â¦).
Cheers,
Vincent
*De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part de* Peter Uhnák *Envoyé :* lundi 3 août 2015 11:56 *à :* Pharo Development List *Objet :* Re: [Pharo-dev] Google Code Shutdown
As long as nobody on your team is using Windows, git(hub) is quite good. :)
(And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
------------------------------
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Yes but at the moment only the bug tracker will be used I guess. Maybe someone can create a MOOSE org ? Sent from my iPhone
On 3 août 2015, at 11:56, Peter Uhnák <i.uhnak@gmail.com> wrote:
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I just created this organization: https://github.com/orgs/moosetechnology/dashboard What should I do next? Cheers, Doru On Mon, Aug 3, 2015 at 12:55 PM, <serge.stinckwich@gmail.com> wrote:
Yes but at the moment only the bug tracker will be used I guess. Maybe someone can create a MOOSE org ?
Sent from my iPhone
On 3 août 2015, at 11:56, Peter Uhnák <i.uhnak@gmail.com> wrote:
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
Create a repo for moose in order to have a bug tracker, move issues from Google code to this repo :-) Sorry I'm on my phone, I can't help now ;-) Sent from my iPhone
On 3 août 2015, at 13:00, Tudor Girba <tudor@tudorgirba.com> wrote:
I just created this organization: https://github.com/orgs/moosetechnology/dashboard
What should I do next?
Cheers, Doru
On Mon, Aug 3, 2015 at 12:55 PM, <serge.stinckwich@gmail.com> wrote: Yes but at the moment only the bug tracker will be used I guess. Maybe someone can create a MOOSE org ?
Sent from my iPhone
On 3 août 2015, at 11:56, Peter Uhnák <i.uhnak@gmail.com> wrote:
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"Every thing has its own flow"
Import in progress: Started thread on Moose list: http://forum.world.st/Moving-Issues-to-GitHub-tt4840767.html ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840768.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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 :
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
Github is indeed appealing.
Cheers, Alexandre
> On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Tudor Girba-2 wrote >> Would you like to help us move the moose-technology project? > > Sure. What do you have in mind? It seems exporting to GitHub is the easiest > option. There are a few limitations, but I've had good experiences... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <stepharo@free.fr> wrote:
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 :
As long as nobody on your team is using Windows, git(hub) is quite good. :) (And if you have Windows user, then find him a therapy first, or push for libcgit :))
On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Github is indeed appealing.
Cheers, Alexandre
On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
Would you like to help us move the moose-technology project?
Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
Tudor Girba-2 wrote
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.
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 -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4841101.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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/configur... <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/Spur-VMMaker-Tracker/configur...>): set -e eval `ssh-agent` ssh-add $HOME/.ssh/id_rsa_estebanlm PACKAGES="'VMMaker.oscog'" REPOSITORY=cog # Clone git clone -b spur64 git@github.com:estebanlm/pharo-vm.git $REPOSITORY cd $REPOSITORY git config --local user.email "estebanlm@gmail.com" 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 -
On 05 Aug 2015, at 16:54, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
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.
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 -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4841101.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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
On 05 Aug 2015, at 17:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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/configur... <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/Spur-VMMaker-Tracker/configur...>):
set -e
eval `ssh-agent` ssh-add $HOME/.ssh/id_rsa_estebanlm
PACKAGES="'VMMaker.oscog'" REPOSITORY=cog
# Clone git clone -b spur64 git@github.com:estebanlm/pharo-vm.git $REPOSITORY cd $REPOSITORY git config --local user.email "estebanlm@gmail.com <mailto:estebanlm@gmail.com>" git config --local user.name "Esteban Lorenzano" cd -
# Get Pharo (and prepare it) wget -O- get.pharo.org/50+vm <http://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' <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 -
On 05 Aug 2015, at 16:54, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Tudor Girba-2 wrote
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.
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 -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4841101.html <http://forum.world.st/Google-Code-Shutdown-tp4814760p4841101.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
participants (13)
-
Alexandre Bergel -
Blondeau Vincent -
David T. Lewis -
Dimitris Chloupis -
Esteban Lorenzano -
kilon alios
-
Levente Uzonyi -
Peter Uhnák -
Sean P. DeNigris -
serge.stinckwich＠gmail.com -
stepharo -
Thierry Goubier -
Tudor Girba