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

Latest Xcode to Compile VM

by Sean P. DeNigris

What's the latest Xcode version successfully used to compile the Pharo VM? I don't want to upgrade past the maintainers... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Latest-Xcode-to-Compile-VM-tp4719249.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 5, 2013

Re: [Pharo-dev] Feature request poll

by Yuriy Tymchuk

Sounds like I should get back to work :) On 04 Nov 2013, at 23:19, kilon alios <kilon.alios(a)gmail.com> wrote: > I think now Pharo as Pharo. It stands on its own get inspired by the past, inventing the future ;) > > how that sounds ? > > > On Mon, Nov 4, 2013 at 11:21 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 04 Nov 2013, at 22:13, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> >> 2013/11/4 Alexandre Bergel <alexandre.bergel(a)me.com> >> Why do you mention Smalltalk at all actually? In my classes, I simply say that Pharo is inspired by Smalltalk, if I ever mention it >> It is easier to be convinced by the future than by the past. >> >> >> To me trying to dissociate Smalltalk from Pharo is like trying to dissociate Smalltalk from VisualWorks (aka "Cincom Smalltalk"). >> Or worst... ANSI C from C++. >> >> I still mention Smalltalk, and I promote Pharo as "an active Smalltalk dialect". >> >> Maybe it will be better to promote it plainly as Pharoâ¦ > I just say that Pharo is what had to happen with Smalltalk in last 30 years. We can think about Pharo in Smalltalk like Scala in Java. But Java had versions, and Smalltalk is treated just as only 80th year frozen snapshot. Iâd say that Pharo is a Smalltalk of 2013 year. Oh, yes, but in public itâs better to say that Pharo is completely different ;) > > >> >> >> >> >> >> Esteban A. Maringolo > >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by GOUBIER Thierry

Doing git pull and git push... As it stands, git push would be easy: my idea would be to add a button to the repository browser to do a push... Or add a setting(*) to do a push after each commit, or both. git pull, however... a git pull can create conflicts, and it would be a bit messy to try a pull, fail with conflicts (a pull does a merge) and let the Pharo user drop to the command line to try to clean up the mess :( git fetch is a bit safer, but may require some command line work to merge the fetched changes to the current branch. Git is complex. The git clone could also be done in Pharo. Thierry (*) Settings don't play well with absent classes on first load :( ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de kilon alios [kilon.alios(a)gmail.com] Date d'envoi : lundi 4 novembre 2013 23:19 Ã : Pharo Development List Objet : Re: [Pharo-dev] Github and Pharo It does work indeed, commit wise. But can I git pull and git push with it ? 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 >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by kilon alios

It does work indeed, commit wise. But can I git pull and git push with it ? On Mon, Nov 4, 2013 at 10:50 PM, GOUBIER Thierry <thierry.goubier(a)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] de la part de > Alexandre Bergel [alexandre.bergel(a)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> 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>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] de la part de Max >> Leske [maxleske(a)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> 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 >> > >> >> >> >> >

Nov. 4, 2013

Re: [Pharo-dev] Feature request poll

by kilon alios

I think now Pharo as Pharo. It stands on its own get inspired by the past, inventing the future ;) how that sounds ? On Mon, Nov 4, 2013 at 11:21 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 04 Nov 2013, at 22:13, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 2013/11/4 Alexandre Bergel <alexandre.bergel(a)me.com> > >> Why do you mention Smalltalk at all actually? In my classes, I simply say >> that Pharo is inspired by Smalltalk, if I ever mention it >> It is easier to be convinced by the future than by the past. >> >> > To me trying to dissociate Smalltalk from Pharo is like trying to > dissociate Smalltalk from VisualWorks (aka "Cincom Smalltalk"). > Or worst... ANSI C from C++. > > I still mention Smalltalk, and I promote Pharo as "an active Smalltalk > dialect". > > Maybe it will be better to promote it plainly as Pharoâ¦ > > I just say that Pharo is what had to happen with Smalltalk in last 30 > years. We can think about Pharo in Smalltalk like Scala in Java. But Java > had versions, and Smalltalk is treated just as only 80th year frozen > snapshot. Iâd say that Pharo is a Smalltalk of 2013 year. Oh, yes, but in > public itâs better to say that Pharo is completely different ;) > > > > > > > > Esteban A. Maringolo > > >

Nov. 4, 2013

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

by Benjamin

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. 4, 2013

Re: [Pharo-dev] Peek

by Henrik Sperre Johansen

That's great! Remembering that commit message was part of the reason for benching, was sort of disappointed there was no significant difference between Zn in 2.0 and latest 3.0... I guess with the amount of hacks accumulating, it is indeed turning into a worthy successor of MultiByteFileStream ;) Cheers, Henry P.S: If you want another delightful one in the same vein (both from WTFy-ness and perf improvement POV), take a gander at UTF16TextConverter >> nextPutByteString:toStream: On Mon, Nov 4, 2013 at 5:12 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Henrik, > > Great writeup, thanks ! > > (more inline) > > On 04 Nov 2013, at 11:58, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 04 Nov 2013, at 9:57 , Diego Lont <diego.lont(a)delware.nl> wrote: > > > >> Working on Petit Delphi we found a strange implementation for > asPetitStream: > >> Stream>asPetitStream > >> ^ self contents asPetitStream > >> > >> Further investigation showed that the basic peek was not fast enough > for Petit Parser, as it is used a lot. So it implemented a "improved > unchecked peek": > >> PPStream>peek > >> "An improved version of peek, that is slightly faster than the > built in version." > >> ^ self atEnd ifFalse: [ collection at: position + 1 ] > >> > >> PPStream>uncheckedPeek > >> "An unchecked version of peek that throws an error if we try to > peek over the end of the stream, even faster than #peek." > >> ^ collection at: position + 1 > >> > >> But in my knowledge a basic peek should be fast. The real problem is > the peek in the underlying peek: > >> PositionableStream>peek > >> "Answer what would be returned if the message next were sent to the > >> receiver. If the receiver is at the end, answer nil." > >> > >> | nextObject | > >> self atEnd ifTrue: [^nil]. > >> nextObject := self next. > >> position := position - 1. > >> ^nextObject > >> > >> That actually uses "self next". The least thing one should do is to > cache the next object. But isn't there a primitive for peek in a file > stream? Because al overriding peeks of PositionableStream have basically > the same implementation: reading the next and restoring the state to before > the peek (that is slow). So we would like to be able to remove PPStream > without causing performance issues, as the only added method is the > "improved peek". > >> > >> Stephan and Diego > > > > If you are reading from file, ZnCharacterStream should be a valid > alternative. > > If not, ZnBufferedReadStream on an internal collection stream also does > peek caching. > > > > Beware with files though; itâs better to bench the overall operation for > different alternatives. > > F.ex, ZnCharacterStream is much faster than the standard Filestream for > peek: > > > > cr := ZnCharacterReadStream on: 'PharoDebug.log' asFileReference > readStream binary. > > [cr peek] bench. '49,400,000 per second.' > > cr close. > > > > FileStream fileNamed: 'PharoDebug.log' do: [:fs | [fs peek] bench] > '535,000 per second.â > > > > but has different bulk reads characteristics (faster for small bulks, > slower for large bulks, crossover-point at around 1k chars at once); > > (The actual values are of course also dependent on encoder/file > contents, those given here obtained with UTF-8 and a mostly/all ascii text > file) > > > > [cr := ZnCharacterReadStream on: ('PharoDebug.log' asFileReference > readStream binary ) readStream. > > cr next: 65536; close] bench '105 per second.' '106 per second.â > > Well, I just realised that ZnCharacterReadStream and > ZnCharacterWriteStream did not yet make use of the optimisations that I did > for ZnCharacterEncoding some time ago. More specifically, they were not yet > using #next:putAll:startingAt:toStream: and > #readInto:startingAt:count:fromStream: which are overwritten for > ZnUTF8Encoder with (super hacked) versions that assume most of the input > will be ASCII (a reasonable assumption). > > I am still chasing a bug, but right now: > > [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream > binary)) > next: 65536; close ] bench. > > "135 per second.â BEFORE > "3,310 per second.â AFTER > > But of course the input file is ASCII, so YMMV. > > Iâll let you know when I commit this code. > > Sven > > > [FileStream fileNamed: 'PharoDebug.log' do: [:fs | fs next: 65536] > > ] bench '176 per second.â > > > > If you use a StandardFilestream set to binary ( which has less overhead > for binary nextâs compared to the MultiByteFileStream returned by > asFileReference readStream)as the base stream instead, , the same general > profile holds true, but with a crossover around 2k characters. > > > > TL;DR: Benchmark the alternatives. The best replacement option depends > on your results. Appropriately (according to source and actual use) set up > Zn-streams are probably your best bet. > > > > Cheers, > > Henry > > >

Nov. 4, 2013

Re: [Pharo-dev] Feature request poll

by Yuriy Tymchuk

On 04 Nov 2013, at 22:13, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2013/11/4 Alexandre Bergel <alexandre.bergel(a)me.com> > Why do you mention Smalltalk at all actually? In my classes, I simply say that Pharo is inspired by Smalltalk, if I ever mention it > It is easier to be convinced by the future than by the past. > > > To me trying to dissociate Smalltalk from Pharo is like trying to dissociate Smalltalk from VisualWorks (aka "Cincom Smalltalk"). > Or worst... ANSI C from C++. > > I still mention Smalltalk, and I promote Pharo as "an active Smalltalk dialect". > > Maybe it will be better to promote it plainly as Pharoâ¦ I just say that Pharo is what had to happen with Smalltalk in last 30 years. We can think about Pharo in Smalltalk like Scala in Java. But Java had versions, and Smalltalk is treated just as only 80th year frozen snapshot. Iâd say that Pharo is a Smalltalk of 2013 year. Oh, yes, but in public itâs better to say that Pharo is completely different ;) > > > > > > Esteban A. Maringolo

Nov. 4, 2013

Re: [Pharo-dev] Feature request poll

by Esteban A. Maringolo

2013/11/4 Alexandre Bergel <alexandre.bergel(a)me.com> > Why do you mention Smalltalk at all actually? In my classes, I simply say > that Pharo is inspired by Smalltalk, if I ever mention it > It is easier to be convinced by the future than by the past. > > To me trying to dissociate Smalltalk from Pharo is like trying to dissociate Smalltalk from VisualWorks (aka "Cincom Smalltalk"). Or worst... ANSI C from C++. I still mention Smalltalk, and I promote Pharo as "an active Smalltalk dialect". Maybe it will be better to promote it plainly as Pharo... Esteban A. Maringolo

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by GOUBIER Thierry

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] de la part de Alexandre Bergel [alexandre.bergel(a)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 >

Nov. 4, 2013