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

Re: [Pharo-dev] BlockClosure source code

by Tudor Girba

I love these little things. This is a great example of how value should not be confused with cost. Small can be quite big after all :) Doru On Tue, Oct 14, 2014 at 4:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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> > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 14, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Nicolai Hess

2014-10-14 20:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Oct 14, 2014 at 11:15 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Thank you eliot, marcus >> >> Yes I know your blog it is a great source of information. >> I am curious how the squeak compiler/debugger handles this (I'll look >> into it). >> > > There's no scope at run-time, only at compile time. AT compile time the > BlockNodes for optimized blocks get checked for the optimized selectors > (ifTrue: whileTrue and: et al) and have a flag set if they can be optimized > (have the right number of arguments). At run-time there's no evidence of > an optimized block. One is left in the enclosing method/block activation. > > About opal and optimized block scope: >> Yes, I like the way this "special" non-scope is modelled with >> its own scope class. >> But somehow the whileTrue: receiver block is handled different than >> the ifTrue: block argument. >> > > How so? Is it the source extent that is wrong? > 1. sometimes the debugger can not inspect a single tempvar (list of all temps is working) 2. number of temp vars (in method header) is wrong: | 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. method header numtemps 1 | 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 ]. c < 0 ]. ^ a method header numtemps 3 both methods define a block with a nested block. In the first method it is the receiver of #whileTrue: the second method it is the argument to #ifTrue: I think both blocks are optimized, but somehow the block receiving the whileTrue: message makes the computation for the number of tempvars wrong. > > 2014-10-14 17:41 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> 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 >>> >> >> > > > -- > best, > Eliot >

Oct. 14, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

Le 14/10/2014 14:15, David T. Lewis a Ã©crit : > 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. The strange thing is that it runs to completion (i.e. I got no errors; if any data was missing or corrupted on output, my load would fail); but a lot slower than it should be. > Thank you very much for finding this. I will get it fixed as quickly > as I can. Thanks. I'm unable to help you much, I'm afraid :( Thierry

Oct. 14, 2014

Re: [Pharo-dev] [squeak-dev] Re: [Pharo-users] Trouble opening large files

by Nicolai Hess

Ah, good to know. At least for squeak, bug 7522 can be closed :) Nicolai 2014-10-14 20:49 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Tue, Oct 14, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> There is a bug report on mantis for squeaks unix vm. >> I think this applies to pharo too, although I don't know if this >> bug is still valid on recent squeak vm. >> >> http://bugs.squeak.org/view.php?id=7522 >> > > yes, one must compile with -D_FILE_OFFSET_BITS=64. The Cog VMs are also > built with -D_GNU_SOURCE. > > Here's a line from a Squeak file list on the current Cog VM: > > (2014.10.11 07:00:46 7,115,143,880) > Formula1.2014.Round16.Russia.Qualifying.BBCOneHD.1080i.H264.English-wserhkzt.ts > > No 32-bit limit here. > > >> >> 2014-10-14 17:43 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: >> >>> The OS is Arch Linux. >>> >>> I can read the file with less. >>> >>> The problem, insofar as I can trace it, seems to stem from this line in >>> UnixStore: >>> >>> Primitives lookupDirectory: encodedPath filename: encodedBasename >>> >>> When I have my 57G file there this line returns nil. If I move the 57G >>> file and create a small file with the same name, the same command >>> successfully finds the file. I am not sure how large a file must be to >>> cause this issue, but A 1.5G file works fine. >>> >>> On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> 2014-10-14 6:38 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: >>>> >>>>> Hi, thanks for the reply. >>>>> >>>>> The response is the same: "MessageNotUnderstood: >>>>> False>>humanReadableSIByteSize." >>>>> >>>>> This happens both to print-it as well as to do-it-and-go. Running the >>>>> command on the neighboring "wiki.torrent" torrent file yields the correct >>>>> 54kb. >>>>> >>>>> Thanks, >>>>> Evan >>>>> >>>>> On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> If I understand correctly, the failure occurs while navigating in the >>>>>> "Items" presentation. >>>>>> >>>>>> I cannot reproduce this problem because I do not have enough disk >>>>>> space for such a large file :). But, could you do the following and let me >>>>>> know what the outcome is: >>>>>> >>>>>> 'path/to/your/large/file.xml' asFileReference humanReadableSize >>>>>> >>>>>> ? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue <emdonahu(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello, I've run into some odd behavior and wanted to check whether I >>>>>>> might be missing something: >>>>>>> >>>>>>> I have downloaded a copy of the english wikipedia as an xml file and >>>>>>> am hoping to (sax) parse it. However, I can't even seem to get pharo to >>>>>>> recognize that the file exists. >>>>>>> >>>>>>> If I open FileSystem disk root in the playground and naigate, >>>>>>> attempting to enter the folder containing the (57G) xml file fails with >>>>>>> "MessageNotUnderstood: False>>humanReadableSIByteSize." Likewise if I get a >>>>>>> FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self >>>>>>> exists returns false and the parser fails. >>>>>>> >>>>>>> Am I doing something wrong? Should I be able to do this? >>>>>>> >>>>>>> The version number is #40283 >>>>>>> >>>>>>> Thanks, >>>>>>> Evan >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>> >>>> Which OS ? >>>> Can you check with other programs if this file is readable at all? >>>> >>>> >>>> >>>> >>>> Nicolai >>>> >>>> >>>> >>> >> >> >> >> > > > -- > best, > Eliot >

Oct. 14, 2014

Re: [Pharo-dev] [squeak-dev] Anyone have contact info for Ragnar Hojland Espinosa?

by Eliot Miranda

I just got a reply from Ragnar, so no worries. Thanks! On Tue, Oct 14, 2014 at 10:39 AM, Chris Cunnington <brasspen(a)gmail.com> wrote: > I see on LinkedIn that one RHE works as a sysadmin in Dublin at > http://www.dedsert.com since July and might be contacted by > LinkedIn InMail. Of course, that may not be the droid youâre looking for. > > FWIW, > Chris > > On Oct 14, 2014, at 12:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > 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 > > > > > > -- best, Eliot

Oct. 14, 2014

Re: [Pharo-dev] [Pharo-users] Trouble opening large files

by Nicolai Hess

Rebuild pharo vm with D_FILE_OFFSET_BITS=64 option: Reading list directories with (very) large files working now. 2014-10-14 20:26 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > There is a bug report on mantis for squeaks unix vm. > I think this applies to pharo too, although I don't know if this > bug is still valid on recent squeak vm. > > http://bugs.squeak.org/view.php?id=7522 > > 2014-10-14 17:43 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: > >> The OS is Arch Linux. >> >> I can read the file with less. >> >> The problem, insofar as I can trace it, seems to stem from this line in >> UnixStore: >> >> Primitives lookupDirectory: encodedPath filename: encodedBasename >> >> When I have my 57G file there this line returns nil. If I move the 57G >> file and create a small file with the same name, the same command >> successfully finds the file. I am not sure how large a file must be to >> cause this issue, but A 1.5G file works fine. >> >> On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> 2014-10-14 6:38 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: >>> >>>> Hi, thanks for the reply. >>>> >>>> The response is the same: "MessageNotUnderstood: >>>> False>>humanReadableSIByteSize." >>>> >>>> This happens both to print-it as well as to do-it-and-go. Running the >>>> command on the neighboring "wiki.torrent" torrent file yields the correct >>>> 54kb. >>>> >>>> Thanks, >>>> Evan >>>> >>>> On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> If I understand correctly, the failure occurs while navigating in the >>>>> "Items" presentation. >>>>> >>>>> I cannot reproduce this problem because I do not have enough disk >>>>> space for such a large file :). But, could you do the following and let me >>>>> know what the outcome is: >>>>> >>>>> 'path/to/your/large/file.xml' asFileReference humanReadableSize >>>>> >>>>> ? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue <emdonahu(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, I've run into some odd behavior and wanted to check whether I >>>>>> might be missing something: >>>>>> >>>>>> I have downloaded a copy of the english wikipedia as an xml file and >>>>>> am hoping to (sax) parse it. However, I can't even seem to get pharo to >>>>>> recognize that the file exists. >>>>>> >>>>>> If I open FileSystem disk root in the playground and naigate, >>>>>> attempting to enter the folder containing the (57G) xml file fails with >>>>>> "MessageNotUnderstood: False>>humanReadableSIByteSize." Likewise if I get a >>>>>> FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self >>>>>> exists returns false and the parser fails. >>>>>> >>>>>> Am I doing something wrong? Should I be able to do this? >>>>>> >>>>>> The version number is #40283 >>>>>> >>>>>> Thanks, >>>>>> Evan >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> Which OS ? >>> Can you check with other programs if this file is readable at all? >>> >>> >>> >>> >>> Nicolai >>> >>> >>> >> >

Oct. 14, 2014

Re: [Pharo-dev] [squeak-dev] Re: [Pharo-users] Trouble opening large files

by Eliot Miranda

Hi Nicolai, On Tue, Oct 14, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a bug report on mantis for squeaks unix vm. > I think this applies to pharo too, although I don't know if this > bug is still valid on recent squeak vm. > > http://bugs.squeak.org/view.php?id=7522 > yes, one must compile with -D_FILE_OFFSET_BITS=64. The Cog VMs are also built with -D_GNU_SOURCE. Here's a line from a Squeak file list on the current Cog VM: (2014.10.11 07:00:46 7,115,143,880) Formula1.2014.Round16.Russia.Qualifying.BBCOneHD.1080i.H264.English-wserhkzt.ts No 32-bit limit here. > > 2014-10-14 17:43 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: > >> The OS is Arch Linux. >> >> I can read the file with less. >> >> The problem, insofar as I can trace it, seems to stem from this line in >> UnixStore: >> >> Primitives lookupDirectory: encodedPath filename: encodedBasename >> >> When I have my 57G file there this line returns nil. If I move the 57G >> file and create a small file with the same name, the same command >> successfully finds the file. I am not sure how large a file must be to >> cause this issue, but A 1.5G file works fine. >> >> On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> 2014-10-14 6:38 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: >>> >>>> Hi, thanks for the reply. >>>> >>>> The response is the same: "MessageNotUnderstood: >>>> False>>humanReadableSIByteSize." >>>> >>>> This happens both to print-it as well as to do-it-and-go. Running the >>>> command on the neighboring "wiki.torrent" torrent file yields the correct >>>> 54kb. >>>> >>>> Thanks, >>>> Evan >>>> >>>> On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> If I understand correctly, the failure occurs while navigating in the >>>>> "Items" presentation. >>>>> >>>>> I cannot reproduce this problem because I do not have enough disk >>>>> space for such a large file :). But, could you do the following and let me >>>>> know what the outcome is: >>>>> >>>>> 'path/to/your/large/file.xml' asFileReference humanReadableSize >>>>> >>>>> ? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue <emdonahu(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, I've run into some odd behavior and wanted to check whether I >>>>>> might be missing something: >>>>>> >>>>>> I have downloaded a copy of the english wikipedia as an xml file and >>>>>> am hoping to (sax) parse it. However, I can't even seem to get pharo to >>>>>> recognize that the file exists. >>>>>> >>>>>> If I open FileSystem disk root in the playground and naigate, >>>>>> attempting to enter the folder containing the (57G) xml file fails with >>>>>> "MessageNotUnderstood: False>>humanReadableSIByteSize." Likewise if I get a >>>>>> FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self >>>>>> exists returns false and the parser fails. >>>>>> >>>>>> Am I doing something wrong? Should I be able to do this? >>>>>> >>>>>> The version number is #40283 >>>>>> >>>>>> Thanks, >>>>>> Evan >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> Which OS ? >>> Can you check with other programs if this file is readable at all? >>> >>> >>> >>> >>> Nicolai >>> >>> >>> >> > > > > -- best, Eliot

Oct. 14, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Eliot Miranda

On Tue, Oct 14, 2014 at 11:15 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Thank you eliot, marcus > > Yes I know your blog it is a great source of information. > I am curious how the squeak compiler/debugger handles this (I'll look into > it). > There's no scope at run-time, only at compile time. AT compile time the BlockNodes for optimized blocks get checked for the optimized selectors (ifTrue: whileTrue and: et al) and have a flag set if they can be optimized (have the right number of arguments). At run-time there's no evidence of an optimized block. One is left in the enclosing method/block activation. About opal and optimized block scope: > Yes, I like the way this "special" non-scope is modelled with > its own scope class. > But somehow the whileTrue: receiver block is handled different than > the ifTrue: block argument. > How so? Is it the source extent that is wrong? 2014-10-14 17:41 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> 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 >> > > -- best, Eliot

Oct. 14, 2014

Re: [Pharo-dev] [Pharo-users] Trouble opening large files

by Nicolai Hess

There is a bug report on mantis for squeaks unix vm. I think this applies to pharo too, although I don't know if this bug is still valid on recent squeak vm. http://bugs.squeak.org/view.php?id=7522 2014-10-14 17:43 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: > The OS is Arch Linux. > > I can read the file with less. > > The problem, insofar as I can trace it, seems to stem from this line in > UnixStore: > > Primitives lookupDirectory: encodedPath filename: encodedBasename > > When I have my 57G file there this line returns nil. If I move the 57G > file and create a small file with the same name, the same command > successfully finds the file. I am not sure how large a file must be to > cause this issue, but A 1.5G file works fine. > > On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 2014-10-14 6:38 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com>: >> >>> Hi, thanks for the reply. >>> >>> The response is the same: "MessageNotUnderstood: >>> False>>humanReadableSIByteSize." >>> >>> This happens both to print-it as well as to do-it-and-go. Running the >>> command on the neighboring "wiki.torrent" torrent file yields the correct >>> 54kb. >>> >>> Thanks, >>> Evan >>> >>> On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> If I understand correctly, the failure occurs while navigating in the >>>> "Items" presentation. >>>> >>>> I cannot reproduce this problem because I do not have enough disk space >>>> for such a large file :). But, could you do the following and let me know >>>> what the outcome is: >>>> >>>> 'path/to/your/large/file.xml' asFileReference humanReadableSize >>>> >>>> ? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue <emdonahu(a)gmail.com> >>>> wrote: >>>> >>>>> Hello, I've run into some odd behavior and wanted to check whether I >>>>> might be missing something: >>>>> >>>>> I have downloaded a copy of the english wikipedia as an xml file and >>>>> am hoping to (sax) parse it. However, I can't even seem to get pharo to >>>>> recognize that the file exists. >>>>> >>>>> If I open FileSystem disk root in the playground and naigate, >>>>> attempting to enter the folder containing the (57G) xml file fails with >>>>> "MessageNotUnderstood: False>>humanReadableSIByteSize." Likewise if I get a >>>>> FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self >>>>> exists returns false and the parser fails. >>>>> >>>>> Am I doing something wrong? Should I be able to do this? >>>>> >>>>> The version number is #40283 >>>>> >>>>> Thanks, >>>>> Evan >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> Which OS ? >> Can you check with other programs if this file is readable at all? >> >> >> >> >> Nicolai >> >> >> >

Oct. 14, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Nicolai Hess

Thank you eliot, marcus Yes I know your blog it is a great source of information. I am curious how the squeak compiler/debugger handles this (I'll look into it). About opal and optimized block scope: Yes, I like the way this "special" non-scope is modelled with its own scope class. But somehow the whileTrue: receiver block is handled different than the ifTrue: block argument. 2014-10-14 17:41 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > 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