October 2014 - Pharo-dev - lists.pharo.org

Anyone have contact info for Ragnar Hojland Espinosa?

by Eliot Miranda

re http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/057750.html does anyone have contact info for Ragnar Hojland Espinosa? I have Ragnar Hojland Espinosa <ragnar(a)ragnar-hojland.com> but it bounces. -- best, Eliot

Oct. 14, 2014

Trouble opening large files

by Torsten Bergmann

Hi, just debug it. I guess some primitive returns false instead of the basic filesize. There is AbstractFileReference>>humanReadableSize looking like this: humanReadableSize ^self size humanReadableSIByteSize So if size returns "false" then you will get this error. If you trace further you may end up in DiskStore>>basicSize: anEntry which gives the 5th entry. Just check where it is coming from (somewhere in FilePluginPrims I guess). Maybe the size is so large that it fit's Smalltalk but not C. But I just guess, try to debug. Bye T.

Oct. 14, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Eliot Miranda

Hi Marcus, On Tue, Oct 14, 2014 at 4:09 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 12 Oct 2014, at 11:49, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > I tried to solve issues > > "13260 inspecting variables in the debugger fails in some cases" and > > "14058 Inconsistent information in debugger" > > and found some oddities in the way opal (compiler and the debuggermap) > > handles tempory variables. > > I am not sure if these are bugs. > > > > 1. order of temporaries: > > Evaluating this method > > |a b c| > > a:=1. > > b:=2. > > c:=3. > > thisContext tempNames logCr. > > ["in a block ! " thisContext tempNames logCr . a+b+c ] value. > > > > prints in the transcript > > #(#a #b #c) > > #(#a #b #c) > > > > - ok, both contexts, the method and block context, use the same > > ordering for the tempories > > > > writing on one variable in the block context require an indirection > vector for > > the variable > > > > |a b c| > > a:=1. > > b:=2. > > c:=3. > > thisContext tempNames logCr. > > [b:=1. thisContext tempNames logCr. a+b+c ] value. > > > > here the variable b is written within the block context. This method > prints > > #(#b #a #c) > > #(#a #c #b) > > > > - strange the variable order has changed and is not the same in both > contexts. > > > > Yes, but behind the scenes a lot is going onâ¦ when you assign a variable > in a block, this > variable can not be allocated like a normal temp. There is instead an > array (temp vector) allocated where this > variable lives. Then *this array* has a âtempâ and is accessed in the > block like the variables > in the case of no assignment. > Niolai, you're probably aware of it but there's an extensive write up of the design on my blog: http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compil… (especially section "The Closure Analysis") This means that there can not be an order: some variables live in arrays, > others in the context. > The only thing that you have is a scope that nows how a name maps to a > specific offset or two > (offset of temp of the âtemp vector + offset inside this temp vector). > I disagree slightly. The Squeak compiler maintains order, both in temps and in indirect temps. But whether a temp is direct or indirect depends on a simple analysis of a single method. I still think it is part of the Smalltalk culture to KISS and e.g. maintain the order of temps. One could beautify it a bit by sorting the names according to the original > definition order, though. > (we should look onto that). > The current exception system needs to access temps, e.g. ensure:'s and ifCurtailed:'s complete and on:do:'s handlerActive. Isn't it really important to maintain ordering? It certainly makes introspection easier. One can go through a name-based interface but that is likely to be much much slower in what is a perfrmance-critical part of the system. > > But even if we do, this does not mean that b has offset 2 in the example, > as it lives in an array... > Right. > > > > 2. OCOptimizedBlockScope > > > > Consider a whileTrue: call > > ["A-Block"] whileTrue:["B-Block"] > > or an ifTrue: > > ("some boolean value") ifTrue:["C-Block"] > > stepping into the blocks with the debugger and reading the > > values for a tempoariy variable shows that every block has > > an OCOpotimizedBlockScope as its scope. > > Are all 3 blocks the same kind of "optimized blocks"? because -> > > > Yes, we tried two ideas > The first move only real existing scopes, that means, instead of an > optimised scope > point to the scope that all these optimized blocks are flattened into. > But that was not nice and we could not get it to work. > Instead, we opted into modelling the concept of the optimised scope: on > the AST > level, the block has a scope (like all blocks), but when you add an entry > (or query), > it will forward to the ârealâ existing scope. > > I still like it, it makes things very explicit. > > > 3. Blocks within optimized blocks > > This method prints the number of tempories on the Transcript > > (the on:do: call is just a dummy for an "block within a block" > > but the important part is the usage of the three variables > > in the do-block) > > > > |a b c| > > a:=1. > > b:=2. > > c:=3. > > (c>0) ifTrue:[ > > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. > > ]. > > thisContext method numTemps logCr. > > a > > > > The output on the transcript is "3" > > - ok > > > > This method is like the one above, but the nested block > > is in the receiver of the whileTrue:[] call (again, an optimized block, > right?) > > > > |a b c| > > a:=1. > > b:=2. > > c:=3. > > > > [ > > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. > > c <0 ] whileTrue:[]. > > thisContext method numTemps logCr. > > a > > > > The output on the Transcript is "1" > > And it depends on the number of used variables in the do-Block > > The same method but with the do-Block > > do:[:ex | a value:a value:b] > > would print 2 as number of temporaries. > > > > > Hmmâ¦ I need to think about this one. It looks strange, yes. > > Marcus > > > > > -- best, Eliot

Oct. 14, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40304 Home: https://github.com/pharo-project/pharo-core

Oct. 14, 2014

[pharo-project/pharo-core] 3512dd: 40304

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3512dd8cc3b01799689e6fbe98c980fcb66e94f8 https://github.com/pharo-project/pharo-core/commit/3512dd8cc3b01799689e6fbe… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-14 (Tue, 14 Oct 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script304.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40304.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40304 14218 Opal should be able to compile methods for SqueakV3PlusClosure and Spur https://pharo.fogbugz.com/f/cases/14218 http://files.pharo.org/image/40/40304.zip

Oct. 14, 2014

Re: [Pharo-dev] BlockClosure source code

by Sven Van Caekenberghe

Very nice !! On 14 Oct 2014, at 16:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 10 Oct 2014, at 12:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 10 Oct 2014, at 10:57, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: >>> >>> Hi All, >>> >>> Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? >>> >> I will try to fix it next week... >> >>> Or can you suggest me some other way/workaround, how to get/generate the source code of a block? >>> >> >> The old compiler used a hack to decompile blocks for getting a textual representationâ¦ one could port >> the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of >> using the byte code-offset-to-AST mapping more). >> > > step one: A nice toolâ¦ GTInspector view of the byte codes that highlights what is thinks is the corresponding code in the source. > (This living Bytecode view replaces what before just printed out the #longPrintString of the CompiledMethod): > > > > <Playground.jpeg>

Oct. 14, 2014

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 10 Oct 2014, at 12:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 10 Oct 2014, at 10:57, Jan KurÅ¡ <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch>> wrote: >> >> Hi All, >> >> Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? >> > I will try to fix it next week... > >> Or can you suggest me some other way/workaround, how to get/generate the source code of a block? >> > > The old compiler used a hack to decompile blocks for getting a textual representationâ¦ one could port > the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of > using the byte code-offset-to-AST mapping more). > step one: A nice toolâ¦ GTInspector view of the byte codes that highlights what is thinks is the corresponding code in the source. (This living Bytecode view replaces what before just printed out the #longPrintString of the CompiledMethod):

Oct. 14, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40303 Home: https://github.com/pharo-project/pharo-core

Oct. 14, 2014

[pharo-project/pharo-core] e6023c: 40303

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e6023ca6f707a9c2b2dead79a9af5e4629171a3c https://github.com/pharo-project/pharo-core/commit/e6023ca6f707a9c2b2dead79… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-14 (Tue, 14 Oct 2014) Changed paths: M Kernel.package/CompiledMethod.class/instance/printing/longPrintOn_.st R Kernel.package/CompiledMethod.class/instance/printing/longPrintOn_indent_.st M Kernel.package/CompiledMethod.class/instance/printing/symbolic.st R Kernel.package/InstructionPrinter.class/README.md R Kernel.package/InstructionPrinter.class/class/printing/on_.st R Kernel.package/InstructionPrinter.class/class/printing/printClass_.st R Kernel.package/InstructionPrinter.class/definition.st R Kernel.package/InstructionPrinter.class/instance/accessing/indent.st R Kernel.package/InstructionPrinter.class/instance/accessing/indent_.st R Kernel.package/InstructionPrinter.class/instance/accessing/method.st R Kernel.package/InstructionPrinter.class/instance/accessing/method_.st R Kernel.package/InstructionPrinter.class/instance/accessing/printPC_.st R Kernel.package/InstructionPrinter.class/instance/initialize-release/printInstructionsOn_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/blockReturnTop.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/doDup.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/doPop.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/jump_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/jump_if_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/methodReturnConstant_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/methodReturnReceiver.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/methodReturnTop.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/popIntoLiteralVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/popIntoReceiverVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/popIntoRemoteTemp_inVectorAt_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/popIntoTemporaryVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushActiveContext.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushClosureCopyNumCopiedValues_numArgs_blockSize_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushConsArrayWithElements_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushConstant_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushLiteralVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushNewArrayOfSize_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushReceiver.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushReceiverVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushRemoteTemp_inVectorAt_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/pushTemporaryVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/send_super_numArgs_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/storeIntoLiteralVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/storeIntoReceiverVariable_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/storeIntoRemoteTemp_inVectorAt_.st R Kernel.package/InstructionPrinter.class/instance/instruction decoding/storeIntoTemporaryVariable_.st R Kernel.package/InstructionPrinter.class/instance/printing/print_.st R KernelTests.package/InstructionPrinterTest.class/README.md R KernelTests.package/InstructionPrinterTest.class/definition.st R KernelTests.package/InstructionPrinterTest.class/instance/tests/testInstructions.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/currentDisplayChoice.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/currentDisplayChoice_.st R Nautilus.package/AbstractNautilusUI.class/instance/build ui buttons/buildSwitchToByteCodeButton.st R Nautilus.package/AbstractNautilusUI.class/instance/build ui buttons/buildSwitchToSourceCodeButton.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui lists/buildTextAreaButtonsColumn_.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/switchToByteCodeButton.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/switchToSourceCodeButton.st R Nautilus.package/AbstractNautilusUI.class/instance/private/byteCodeSymbol.st R Nautilus.package/AbstractNautilusUI.class/instance/private/showByteCode.st R Nautilus.package/AbstractNautilusUI.class/instance/private/showSource.st R Nautilus.package/AbstractNautilusUI.class/instance/private/sourceCodeSymbol.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/selectedMethodSource.st R Nautilus.package/extension/ThemeIcons/instance/byteCodePressedIcon.st R Nautilus.package/extension/ThemeIcons/instance/byteCodePressedIconContents.st R Nautilus.package/extension/ThemeIcons/instance/byteCodeSelectedIcon.st R Nautilus.package/extension/ThemeIcons/instance/byteCodeSelectedIconContents.st R Nautilus.package/extension/ThemeIcons/instance/byteCodeUnselectedIcon.st R Nautilus.package/extension/ThemeIcons/instance/byteCodeUnselectedIconContents.st R Nautilus.package/extension/ThemeIcons/instance/sourcePressedIcon.st R Nautilus.package/extension/ThemeIcons/instance/sourcePressedIconContents.st R Nautilus.package/extension/ThemeIcons/instance/sourceSelectedIcon.st R Nautilus.package/extension/ThemeIcons/instance/sourceSelectedIconContents.st R Nautilus.package/extension/ThemeIcons/instance/sourceUnselectedIcon.st R Nautilus.package/extension/ThemeIcons/instance/sourceUnselectedIconContents.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testBlockReturnTop.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testGoTo.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testGoToIf.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testIfGoTo.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testIfGoToOtherWise.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testLabel.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPopTop.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushClosureCopyNumCopiedValuesNumArgsTo.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushConsArray.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushDup.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushInstVar.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushLiteral.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushLiteralVariable.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushNewArray.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushReceiver.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushRemoteTempInVectorAt.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushTemp.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushThisContext.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testReturnTop.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testSend.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testSendToSuperOf.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStoreInstVar.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStoreIntoLiteralVariable.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStoreLiteralVariable.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStorePopInstVar.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStorePopIntoLiteralVariable.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStorePopRemoteTempInVectorAt.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStorePopTemp.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStoreRemoteTempInVectorAt.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testStoreTemp.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/other-tests/testDifferentBlocksWithSameArgumentName.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/test - block returning/testBlockReturning.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testBlockTemp.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testMethodArgument.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testReturnBlockInMethod.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testSteamContentsLimitedToSequenceableCollectionClass.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoArgumentNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoInsideTempNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testToDoOutsideTempNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileModificationAfterNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileModificationBeforeNotInlined.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/tests/testWhileWithTempNotInlined.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script303.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40303.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/initialization/initializeDropList.st R Tool-Base.package/ByteCodeMethodConverter.class/README.md R Tool-Base.package/ByteCodeMethodConverter.class/definition.st R Tool-Base.package/ByteCodeMethodConverter.class/instance/private/internalGetText.st Log Message: ----------- 40303 14232 remove ByteCodeMethodConverter https://pharo.fogbugz.com/f/cases/14232 14225 implement #symbolic by printing the SymbolicBytecode.... https://pharo.fogbugz.com/f/cases/14225 13318 no (strong) visual feedback for bytecode view while looking at a class definition https://pharo.fogbugz.com/f/cases/13318 http://files.pharo.org/image/40/40303.zip

Oct. 14, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote: > Hi Dave, > > took me a while to do some testing. It seems there is an issue, but I > couldn't find out where. First, the data: > > Loading a package from a local gitfiletree repository (get from the > command a zipped git archive containing the package) : > > 4.5.11, 4.6.8: 2132 msec. > 4.5.12, 4.6.9: 50847 msec. > > I tried to rewrite the main command, remove the closePipes, etc... No > change in the runtime, so your right. > > Profiling doesn't help much: execution time is mostly idle time (but > with a significant increase on PipeableOSProcess commands: goes from > invisible to 2700 ms. A user break in the middle shows it delay waiting > on output of the external process). > > Only hint I could see is that it seems to be linked with the size of the > output of the command. Thierry, Aha! I am quite sure that you have located the problem. There must be something preventing the OS process from running to completion with a larger amount of output data. It definitely sounds like a bug in my latest update to Pipeable OSProcess. Thank you very much for finding this. I will get it fixed as quickly as I can. Dave > > Le 11/10/2014 15:34, David T. Lewis a ?crit : > >On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote: > >>>Le 10/10/2014 17:52, David T. Lewis a ?crit : > >>>>>2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > >>>>> > >>>>>> > >>>>>>Right. But please do test it in your applications to be sure, I really > >>>>>>only > >>>>>>did simple testing and I am sure there may still chances for problems > >>>>>>in > >>>>>>this area. > >>>>>> > >>>>> > >>>>>Hi Dave, > >>>>> > >>>>>Would it has a chance of slowing down things a lot? > >>>>> > >>>>>There is apparently something going very very slow compared to > >>>>>OSProcess > >>>>>4.5.11 when used from GitFileTree. So slow that I killed the image > >>>>>building > >>>>>script before it was over. Reverting GitFileTree to 4.5.11 solved it. > >>>>> > >>>> > >>>>I don't this so, but I am not certain. The update for PipeableOSProcess > >>>>affects only the methods in PipeableOSProcess class>>command: and > >>>>closely > >>>>related methods. If GitFileTree is using that idiom, then it is > >>>>certainly > >>>>possible that I have introduced a bug that does not show up in my unit > >>>>tests. > >>> > >>>Typical code in GitFileTree is this: > >>> > >>>[ > >>>c := PipeableOSProcess command: ''. > >>>output := c output. > >>>... > >>>] ensure: [c closePipes] > >>> > >>>Maybe it's triggering something. > >>> > >>>Thierry > >>> > >> > >>Hmmm... I wonder if the #closePipes is causing a problem now. I don't know > >>if I ever tested to see if sending closePipes works after the pipes are > >>already closed, and my recent change closes the pipes after #output is > >>evaluated. I'll check it when I get home. > >> > > > >I tried this in both Squeak trunk and Pharo 3.0: > > > > (1 to: 100) collect: [:e | | c output | > > [c := PipeableOSProcess command: 'ls -lt'. > > output := c output. > > ] ensure: [c closePipes]. > > output ]. > > > >I get the expected results, and no open file handles left over. > > > >The #closePipes is no longer needed, so this can now be simplified as > >follows, > >which also leaves no open file handles: > > > > (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') > > output]. > > > >I am not sure what the issue is when used with GitFileTree, but it does not > >look like the change to PipeableOSProcess class>> command: is directly > >involved. > >But ... I'm probably missing something. > > > >If you are fairly sure the that problem is related to the the > >PipeableOSProcess > >change, then the only other thing I can think of right now is that there > >may > >be some other places in GitFileTree where PipeableOSProcess is being used > >in > >a different way, and maybe I caused a problem there due the the change in > >the > >#command: methods. But this a a complete guess, I really do not know. > > > >Dave > > > > > > >

Oct. 14, 2014