November 2013 - Pharo-dev - lists.pharo.org

Pb team in Smalltalk hub?

by Alexandre Bergel

Hi! Apparently I cannot add any new team member in the team of ObjectProfile. Am I the only one to experience this? When I click on add, the member is not added. I've tried refreshing... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 5, 2013

Re: [Pharo-dev] Writing jpeg files to disk

by Usman Bhatti

On Tue, Nov 5, 2013 at 2:36 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I added you to the PharoInbox, could you commit again? > Thanx and done. > > On 2013-11-05, at 11:54, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > Here is a slice the corrects the bug. > > I cannot commit to pharo inbox. > > > > Usman > > > > > > On Tue, Nov 5, 2013 at 11:49 AM, Usman Bhatti <usman.bhatti(a)gmail.com> > wrote: > > https://pharo.fogbugz.com/f/cases/12073/Writing-jpeg-files-to-disk > > > > > > On Tue, Nov 5, 2013 at 11:34 AM, Usman Bhatti <usman.bhatti(a)gmail.com> > wrote: > > Hello, > > > > Due to the changes in Pharo 3.0, I cannot write jpeg files on the disk. > This happens because when writing a jpeg file, we delete any precedent > version of the file to be exported. However, now DiskStore>>delete: throws > an exception when the file to be deleted is not present > > > > delete: path > > | pathString encodedPathString | > > > > (self exists: path) > > ifFalse: [ ^ FileDoesNotExist signalWith: path ]. > > > > ... > > > > Hence, we need to fix PluginBasedJPEGReadWriter>>putForm: quality: > progressiveJPEG: onFileNamed: to not delete files not present. > > > > To reproduce the problem: > > Display writeJPEGfileNamed: 'display.jpeg' progressive: true > > > > If confirmed, I'll open a bug report and propose a slice because > correction is quite simple ;) > > > > > > > > > > > > regards, > > Usman > > > > > > > <Graphics-Files-usmanbhatti.48.mcz><SLICE-Issue-12073-Writing-jpeg-files-to-disk-usmanbhatti.1.mcz> > >

Nov. 5, 2013

Re: [Pharo-dev] Writing jpeg files to disk

by Camillo Bruni

I added you to the PharoInbox, could you commit again? On 2013-11-05, at 11:54, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Here is a slice the corrects the bug. > I cannot commit to pharo inbox. > > Usman > > > On Tue, Nov 5, 2013 at 11:49 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/12073/Writing-jpeg-files-to-disk > > > On Tue, Nov 5, 2013 at 11:34 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hello, > > Due to the changes in Pharo 3.0, I cannot write jpeg files on the disk. This happens because when writing a jpeg file, we delete any precedent version of the file to be exported. However, now DiskStore>>delete: throws an exception when the file to be deleted is not present > > delete: path > | pathString encodedPathString | > > (self exists: path) > ifFalse: [ ^ FileDoesNotExist signalWith: path ]. > > ... > > Hence, we need to fix PluginBasedJPEGReadWriter>>putForm: quality: progressiveJPEG: onFileNamed: to not delete files not present. > > To reproduce the problem: > Display writeJPEGfileNamed: 'display.jpeg' progressive: true > > If confirmed, I'll open a bug report and propose a slice because correction is quite simple ;) > > > > > > regards, > Usman > > > <Graphics-Files-usmanbhatti.48.mcz><SLICE-Issue-12073-Writing-jpeg-files-to-disk-usmanbhatti.1.mcz>

Nov. 5, 2013

Re: [Pharo-dev] 11920 NewValueHolder should use value instead of contents

by Benjamin

On 05 Nov 2013, at 14:13, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-11-05, at 14:09, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On 05 Nov 2013, at 13:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> it shouldn't be an MC issue. >>> the integrator is configured in "merge accepting upcoming changes". >>> So if you integrate and accept without you picking the right version, when the automatic process run it blindly overrides the previous change. >> >> Then this is clearly a problem. >> >> It works in case fixes are made linearly one after the other. Which is far from being the case > > but we even proposed, several times, a remerged SLICE which would for instance produce again a merge conflict. > So there is a strange problem around, which has something to do with MC. This is for sure another issue :) But I guess the value holder fix got lost because I - produce the slice A for value holder - produce the slice B for something else spec related - A got integrated - B got integrated. And of course in this scenario, if conflicts are not resolved, of if merge is not done properly, it tools back A Ben

Nov. 5, 2013

Re: [Pharo-dev] 11920 NewValueHolder should use value instead of contents

by Camillo Bruni

On 2013-11-05, at 14:09, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 05 Nov 2013, at 13:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> it shouldn't be an MC issue. >> the integrator is configured in "merge accepting upcoming changes". >> So if you integrate and accept without you picking the right version, when the automatic process run it blindly overrides the previous change. > > Then this is clearly a problem. > > It works in case fixes are made linearly one after the other. Which is far from being the case but we even proposed, several times, a remerged SLICE which would for instance produce again a merge conflict. So there is a strange problem around, which has something to do with MC.

Nov. 5, 2013

Re: [Pharo-dev] 11920 NewValueHolder should use value instead of contents

by Benjamin

On 05 Nov 2013, at 13:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > it shouldn't be an MC issue. > the integrator is configured in "merge accepting upcoming changes". > So if you integrate and accept without you picking the right version, when the automatic process run it blindly overrides the previous change. Then this is clearly a problem. It works in case fixes are made linearly one after the other. Which is far from being the case Ben > > So I would call it "a human mistake", before an MC one. > > unless, of course, there is no mistake and MC failed to see the change, who would be too serious to notice it just right now, don't you think? > > Esteban > > > On Tue, Nov 5, 2013 at 8:38 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > That was my impression too. > But the interaction with RPackage Annoucement etc.. makes it hard to isolate. > I suspect these layers, because I use MC everyday in Squeak where it's much more robust. > That means that tests are not currently sufficient and we should focus on this (MC used to have a fairly good coverage). > > > 2013/11/5 Camillo Bruni <camillobruni(a)gmail.com> > So there must be some serious MC issue. > > On 2013-11-05, at 11:15, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > Indeed, it seems to not be in the system. > > > > Most probably because afterward another spec related issue has been integrated, > > and that the diff were not properly detected. > > (Already happened) > > > > Ben > > > > On 04 Nov 2013, at 23:06, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > > >> I will tomorrow :) > >> > >> Ben > >> > >> On 04 Nov 2013, at 13:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > >>> Ben > >>> > >>> this is strange when I look at these changes I do not really see that value is used instead of contents. > >>> Can you check to see if your changes got really integrated? > >>> > >>> Stef > >>> On Nov 3, 2013, at 8:17 PM, GitHub <noreply(a)github.com> wrote: > >>> > >>>> Branch: refs/heads/3.0 > >>>> Home: https://github.com/pharo-project/pharo-core > >>>> Commit: a5bce43720062026ab415167af4db194d3958d62 > >>>> https://github.com/pharo-project/pharo-core/commit/a5bce43720062026ab415167… > >>>> Author: Jenkins Build Server <board(a)pharo-project.org> > >>>> Date: 2013-11-03 (Sun, 03 Nov 2013) > >>>> > >>>> Changed paths: > >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script199.st > >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30544.st > >>>> M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > >>>> M Spec-Core.package/TextModel.class/definition.st > >>>> M Spec-Core.package/TextModel.class/instance/initialization/initialize.st > >>>> A Spec-Core.package/TextModel.class/instance/protocol-events/whenMenuHolderChanged_.st > >>>> M Spec-Core.package/TextModel.class/instance/protocol/codePaneMenu_shifted_.st > >>>> A Spec-Core.package/TextModel.class/instance/protocol/menuHolder.st > >>>> A Spec-Core.package/TextModel.class/instance/protocol/menuHolder_.st > >>>> A StartupPreferences.package/extension/SettingBrowser/instance/exportAllSettings_by_withBasename_.st > >>>> M StartupPreferences.package/extension/SettingBrowser/instance/exportSettings.st > >>>> A StartupPreferences.package/extension/SettingBrowser/instance/exportSettings_toFileNamed_.st > >>>> > >>>> Log Message: > >>>> ----------- > >>>> 30544 > >>>> 12061 SettingBrowser>>exportSettings need refactoring > >>>> https://pharo.fogbugz.com/f/cases/12061 > >>>> > >>>> 11920 NewValueHolder should use value instead of contents > >>>> https://pharo.fogbugz.com/f/cases/11920 > >>>> > >>>> 11819 TextModel>>#codePaneMenu:shifted: should work with a value holder > >>>> https://pharo.fogbugz.com/f/cases/11819 > >>>> > >>>> http://files.pharo.org/image/30/30544.zip > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > >

Nov. 5, 2013

Re: [Pharo-dev] 11920 NewValueHolder should use value instead of contents

by Esteban Lorenzano

and btw... the whole RPackage + Announcements stuff should not prevent an MC code to be installed, just to be properly categorized, so I wouldn't check in that direction either, in case of an error. On Tue, Nov 5, 2013 at 9:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > it shouldn't be an MC issue. > the integrator is configured in "merge accepting upcoming changes". > So if you integrate and accept without you picking the right version, when > the automatic process run it blindly overrides the previous change. > > So I would call it "a human mistake", before an MC one. > > unless, of course, there is no mistake and MC failed to see the change, > who would be too serious to notice it just right now, don't you think? > > Esteban > > > On Tue, Nov 5, 2013 at 8:38 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> That was my impression too. >> But the interaction with RPackage Annoucement etc.. makes it hard to >> isolate. >> I suspect these layers, because I use MC everyday in Squeak where it's >> much more robust. >> That means that tests are not currently sufficient and we should focus on >> this (MC used to have a fairly good coverage). >> >> >> 2013/11/5 Camillo Bruni <camillobruni(a)gmail.com> >> >>> So there must be some serious MC issue. >>> >>> On 2013-11-05, at 11:15, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >>> wrote: >>> > Indeed, it seems to not be in the system. >>> > >>> > Most probably because afterward another spec related issue has been >>> integrated, >>> > and that the diff were not properly detected. >>> > (Already happened) >>> > >>> > Ben >>> > >>> > On 04 Nov 2013, at 23:06, Benjamin < >>> benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> > >>> >> I will tomorrow :) >>> >> >>> >> Ben >>> >> >>> >> On 04 Nov 2013, at 13:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >> >>> >>> Ben >>> >>> >>> >>> this is strange when I look at these changes I do not really see >>> that value is used instead of contents. >>> >>> Can you check to see if your changes got really integrated? >>> >>> >>> >>> Stef >>> >>> On Nov 3, 2013, at 8:17 PM, GitHub <noreply(a)github.com> wrote: >>> >>> >>> >>>> Branch: refs/heads/3.0 >>> >>>> Home: https://github.com/pharo-project/pharo-core >>> >>>> Commit: a5bce43720062026ab415167af4db194d3958d62 >>> >>>> >>> https://github.com/pharo-project/pharo-core/commit/a5bce43720062026ab415167… >>> >>>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> >>>> Date: 2013-11-03 (Sun, 03 Nov 2013) >>> >>>> >>> >>>> Changed paths: >>> >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - >>> scripts/script199.st >>> >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - >>> updates/update30544.st >>> >>>> M >>> ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> >>>> M Spec-Core.package/TextModel.class/definition.st >>> >>>> M Spec-Core.package/TextModel.class/instance/initialization/ >>> initialize.st >>> >>>> A >>> Spec-Core.package/TextModel.class/instance/protocol-events/whenMenuHolderChanged_.st >>> >>>> M >>> Spec-Core.package/TextModel.class/instance/protocol/codePaneMenu_shifted_.st >>> >>>> A >>> Spec-Core.package/TextModel.class/instance/protocol/menuHolder.st >>> >>>> A >>> Spec-Core.package/TextModel.class/instance/protocol/menuHolder_.st >>> >>>> A >>> StartupPreferences.package/extension/SettingBrowser/instance/exportAllSettings_by_withBasename_.st >>> >>>> M >>> StartupPreferences.package/extension/SettingBrowser/instance/exportSettings.st >>> >>>> A >>> StartupPreferences.package/extension/SettingBrowser/instance/exportSettings_toFileNamed_.st >>> >>>> >>> >>>> Log Message: >>> >>>> ----------- >>> >>>> 30544 >>> >>>> 12061 SettingBrowser>>exportSettings need refactoring >>> >>>> https://pharo.fogbugz.com/f/cases/12061 >>> >>>> >>> >>>> 11920 NewValueHolder should use value instead of contents >>> >>>> https://pharo.fogbugz.com/f/cases/11920 >>> >>>> >>> >>>> 11819 TextModel>>#codePaneMenu:shifted: should work with a value >>> holder >>> >>>> https://pharo.fogbugz.com/f/cases/11819 >>> >>>> >>> >>>> http://files.pharo.org/image/30/30544.zip >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> > >>> >>> >> >

Nov. 5, 2013

Re: [Pharo-dev] 11920 NewValueHolder should use value instead of contents

by Esteban Lorenzano

it shouldn't be an MC issue. the integrator is configured in "merge accepting upcoming changes". So if you integrate and accept without you picking the right version, when the automatic process run it blindly overrides the previous change. So I would call it "a human mistake", before an MC one. unless, of course, there is no mistake and MC failed to see the change, who would be too serious to notice it just right now, don't you think? Esteban On Tue, Nov 5, 2013 at 8:38 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > That was my impression too. > But the interaction with RPackage Annoucement etc.. makes it hard to > isolate. > I suspect these layers, because I use MC everyday in Squeak where it's > much more robust. > That means that tests are not currently sufficient and we should focus on > this (MC used to have a fairly good coverage). > > > 2013/11/5 Camillo Bruni <camillobruni(a)gmail.com> > >> So there must be some serious MC issue. >> >> On 2013-11-05, at 11:15, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> > Indeed, it seems to not be in the system. >> > >> > Most probably because afterward another spec related issue has been >> integrated, >> > and that the diff were not properly detected. >> > (Already happened) >> > >> > Ben >> > >> > On 04 Nov 2013, at 23:06, Benjamin < >> benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> > >> >> I will tomorrow :) >> >> >> >> Ben >> >> >> >> On 04 Nov 2013, at 13:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> >> >>> Ben >> >>> >> >>> this is strange when I look at these changes I do not really see that >> value is used instead of contents. >> >>> Can you check to see if your changes got really integrated? >> >>> >> >>> Stef >> >>> On Nov 3, 2013, at 8:17 PM, GitHub <noreply(a)github.com> wrote: >> >>> >> >>>> Branch: refs/heads/3.0 >> >>>> Home: https://github.com/pharo-project/pharo-core >> >>>> Commit: a5bce43720062026ab415167af4db194d3958d62 >> >>>> >> https://github.com/pharo-project/pharo-core/commit/a5bce43720062026ab415167… >> >>>> Author: Jenkins Build Server <board(a)pharo-project.org> >> >>>> Date: 2013-11-03 (Sun, 03 Nov 2013) >> >>>> >> >>>> Changed paths: >> >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - >> scripts/script199.st >> >>>> A ScriptLoader30.package/ScriptLoader.class/instance/pharo - >> updates/update30544.st >> >>>> M >> ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >>>> M Spec-Core.package/TextModel.class/definition.st >> >>>> M Spec-Core.package/TextModel.class/instance/initialization/ >> initialize.st >> >>>> A >> Spec-Core.package/TextModel.class/instance/protocol-events/whenMenuHolderChanged_.st >> >>>> M >> Spec-Core.package/TextModel.class/instance/protocol/codePaneMenu_shifted_.st >> >>>> A Spec-Core.package/TextModel.class/instance/protocol/menuHolder.st >> >>>> A >> Spec-Core.package/TextModel.class/instance/protocol/menuHolder_.st >> >>>> A >> StartupPreferences.package/extension/SettingBrowser/instance/exportAllSettings_by_withBasename_.st >> >>>> M >> StartupPreferences.package/extension/SettingBrowser/instance/exportSettings.st >> >>>> A >> StartupPreferences.package/extension/SettingBrowser/instance/exportSettings_toFileNamed_.st >> >>>> >> >>>> Log Message: >> >>>> ----------- >> >>>> 30544 >> >>>> 12061 SettingBrowser>>exportSettings need refactoring >> >>>> https://pharo.fogbugz.com/f/cases/12061 >> >>>> >> >>>> 11920 NewValueHolder should use value instead of contents >> >>>> https://pharo.fogbugz.com/f/cases/11920 >> >>>> >> >>>> 11819 TextModel>>#codePaneMenu:shifted: should work with a value >> holder >> >>>> https://pharo.fogbugz.com/f/cases/11819 >> >>>> >> >>>> http://files.pharo.org/image/30/30544.zip >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> > >> >> >

Nov. 5, 2013

Re: [Pharo-dev] Latest Xcode to Compile VM

by Esteban Lorenzano

I still didn't tried with the latest xcode, but I tried the immediate previous and there is no problem at all. I don't see why it shouldn't work with mavericks :) I will do it as soon as I'm back from holidays (because if I do it now, they wouldn't be holidays ;) Esteban On Tue, Nov 5, 2013 at 4:29 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > On 2013-11-05, at 05:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > What's the latest Xcode version successfully used to compile the Pharo > VM? I > > don't want to upgrade past the maintainers... > > I think everybody upgraded to 10.9 but did not have time yet to compile > the VM :P. > The Mac slave is using a rather old OS and an even older Xcode... >

Nov. 5, 2013

Re: [Pharo-dev] Github and Pharo

by Goubier Thierry

Le 04/11/2013 23:19, kilon alios a Ã©crit : > It does work indeed, commit wise. But can I git pull and git push with it ? Something like that? Thierry > > On Mon, Nov 4, 2013 at 10:50 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > Alexandre, > > using Git with Pharo (2 and 3) works today on Mac and Linux with > MonticelloFileTree and MonticelloFileTree-Git. > > FileSystem-Git will be a better way to do it (and more portable) :) > > Thierry > > ------------------------------------------------------------------------ > *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org > <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Alexandre > Bergel [alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>] > *Date d'envoi :* lundi 4 novembre 2013 21:34 > *Ã :* Pharo Development List > *Cc:* Pharo Development List > > *Objet :* Re: [Pharo-dev] Github and Pharo > > +1 > Everybody is waiting for using Git with Pharo. There is a real > possibility to impact 100s of users... > Go go go! > > Alexandre > > Alexandre > > Le 04-11-2013 Ã 15:35, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> a Ã©crit : > >> Yeah I agree, this is an awesome project and thank you for your >> hard work :) >> >> >> On Mon, Nov 4, 2013 at 8:12 PM, GOUBIER Thierry >> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: >> >> Hi Max, >> >> I saw you were on it :) It's a huge effort you're undertaking. >> I learned a bit about git internal storage stepping through >> the code. >> >> Thierry >> >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org >> <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Max >> Leske [maxleske(a)gmail.com <mailto:maxleske@gmail.com>] >> Date d'envoi : lundi 4 novembre 2013 17:44 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Github and Pharo >> >> FileSystem-Git is basically in alpha at the momentâ¦ Iâm >> rewriting it. >> >> >> On 04.11.2013, at 17:04, Goubier Thierry >> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: >> >> > Ok, I tried a bit with FileSystem-Git, but it seems there is >> still a bit of work to do... >> > >> > I tried on one of my work repository, and: >> > - it failed trying to uft8convert a packed data file. >> > So I corrected the error (get the stream as binary!) and >> > - It failed looking for one of the commit IDs >> > I found the ref in a pack file; apparently, it's not looking >> in there... >> > I'm forcing a read of the pack files in there >> > - Yet another utf8convert error on binary data >> > Corrected, I got the pack files, but the index isn't telling >> me much. >> > I tried to list the objects in it... Unknown compression >> method error. >> > >> > There's a huge amount of code in there, it's a bit >> frightening. I think I'll stay with OSProcess a bit longer ;) >> > >> > Thierry >> > >> > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : >> >> >> >> >> >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : >> >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry >> wrote: >> >>>> >> >>>> >> >>>> Le 04/11/2013 12:11, kilon alios a ?crit : >> >>>>> yeap filetree did the trick here. However it does not >> allow to browse >> >>>>> through the git commits as gitfiletree does, the only >> commit available >> >>>>> is the last commit. >> >>>>> >> >>>>> I took a look at CommandShell and friends and they all >> look pretty much >> >>>>> very broken. For example in workspace I executed >> >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" >> it creates an >> >>>>> error because it add C path inside pharo subdirectories. >> Dont know if >> >>>>> this is normal behavior. >> >>> >> >>> Use "CommandShell open" rather than >> "CommandShellTranscript open". >> >>> >> >>> >> >>>> >> >>>> I hope someone with more knowledge than me of OSProcess >> under windows >> >>>> will have a look :) >> >>>> >> >>> OSProcess support for Windows is incomplete, so this will >> probably not >> >>> do what you need. If the OSProcess is included in the >> Windows VM, it will >> >>> let you run a Windows program, but it will not do most of >> the other >> >>> things >> >>> that you expect from OSProcess. >> >>> >> >>> Check http://www.squeaksource.com/ProcessWrapper.html for >> a possible >> >>> alternative. >> >> >> >> Thanks Dave; no easy solution on that, it seems. I'll have >> a look then >> >> with FileSystem-Git, this one may be a more portable solution. >> >> >> >> Windows is still a world apart from the rest :( >> >> >> >> Thierry >> > >> > -- >> > Thierry Goubier >> > CEA list >> > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> > 91191 Gif sur Yvette Cedex >> > France >> > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >> >> >> >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 5, 2013