- Pharo-dev - lists.pharo.org

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

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