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

Re: [Pharo-dev] Question about closure compilation

by Norbert Hartl

Am 29.06.2013 um 11:12 schrieb Marcus Denker <marcus.denker(a)inria.fr>: >> >> OK, that seems OK. >> >> The reason I was asking was because I wanted to know if this JavaScript bug would hit us as well: >> >> http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.… >> >> It is slightly more complicated than the basic question of closing over an unreferenced variable though. >> >> I just can't figure out a way to quickly test it in Pharo. I think it is worth looking into. > > Yes, we have exactly the same problem. > > imagine a method like this: > > test > | bigObject smallObject | > > [bigObject := Array new: 1000000] value. > ^[smallObject := 1]. > > > both big and small are escaping variables that are written. This means they are allocated > in an Array on the heap (Cog is calling this a TempVector). > > There is just one tempVector created per scope, so we will have a tempVector with both > smallObject and bigObject inside created for the method. This then is passed to the blocks, which > access the temps via the vector. > > The bytecode looks like this: > > 21 <8A 02> push: (Array new: 2) > 23 <68> popIntoTemp: 0 > 24 <10> pushTemp: 0 > 25 <8F 10 00 07> closureNumCopied: 1 numArgs: 0 bytes 29 to 35 > 29 <40> pushLit: Array > 30 <21> pushConstant: 1000000 > 31 <CD> send: new: > 32 <8D 00 00> storeIntoTemp: 0 inVectorAt: 0 > 35 <7D> blockReturn > 36 <C9> send: value > 37 <87> pop > 38 <10> pushTemp: 0 > 39 <8F 10 00 05> closureNumCopied: 1 numArgs: 0 bytes 43 to 47 > 43 <76> pushConstant: 1 > 44 <8D 01 00> storeIntoTemp: 1 inVectorAt: 0 > 47 <7D> blockReturn > 48 <7C> returnTop > > The closure [smallObject := 1] now, even though not referencing the largeObject, references > the tempVector. This tempVector holds on the to large object --> memory is wasted that is not needed. > > Back when implementing the SemChecker, I was thinking about this and wonderingâ¦ for sure > this can be optimized by allocating multiple arrays per scope, depending on how they are used later. > But even then I am sure you can construct strange cases (multiple nested blocks). > > And of course allocating 2 Arrays (or more) wastes memory, too. > > So this is not a simple problemâ¦ the question is how much it matters in practice, though. Thanks. So please let us separate problems. In the example from Sven there are two problems: - increase of memory per function invocation. That problem we don't have - easily keeping a reference to memory preventing it from being garbage collected. That is what you are talking about. And to me there is nothing wrong with it Norbert

June 29, 2013

Re: [Pharo-dev] Question about closure compilation

by Norbert Hartl

Am 28.06.2013 um 23:09 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 28 Jun 2013, at 22:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Jun 28, 2013, at 9:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Hi, >>> >>> Does the closure returned from >>> >>> | foo | >>> foo := #( data 1 2 3 ). >>> [ :x | x + 1 ] >>> >>> close over foo ? >> No. >> >>> Since foo is not used, it should not, right ? >> right. if we get the AST of your method >> >> >> ast := (TT>>#tt) ast. >> (ast scope lookupVar: 'foo') isEscaping >> >> --> false. > > OK, that seems OK. > > The reason I was asking was because I wanted to know if this JavaScript bug would hit us as well: > > http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.… > > It is slightly more complicated than the basic question of closing over an unreferenced variable though. > > I just can't figure out a way to quickly test it in Pharo. I think it is worth looking into. I don't think it is easy to do in pharo. The problem in the article only works because a string primitive is directly referenced. Primitives are copied as a whole when assigned. An object holding that huge string wouldn't be a problem because the enclosed activation record would just hold a reference to that object. As we don't have primitive types in smalltalk the problem doesn't apply IMHO. So his example is the combination that on every function invocation an activation record is created and the primitive string is copied into. The chain of the calling activation records _is_ the lexical scope IIRC. So tweaking the enclosed environment would need to copy and alter the activation records. And to be honest I fail to see why having foo in the scope is wrong. I mean why is it an error if it is there? In my opinion it is normal that foo is there but it can be an optimization to get rid of it, no? And I'm not sure it is easy in most cases to determine the liveliness of a variable. Norbert > >> Now the question is what the inspector of the context should show? >> >> e.g. >> >> tt >> | foo | >> foo := #( data 1 2 3 ). >> ^[ :x | x + 1. thisContext inspect ] >> >> >> if we now execute: >> >> TT new tt value: 2 >> >> the inspector pops up and shows both x and foo. >> >> The reason is that we need to decide what to show >> >> 1) the variable that is stored in the context >> 2) all *possible* variables that I can write in the block and recompile and it works. >> >> 1) is this: >> ast statements last value scope localTempNames >> >> 2) is this: >> >> ast statements last value scope allTemps >> >> Opal implements is like this because the old Compiler (DebuggerMethodMap) did it like this. >> At first I thought this is wrong and I wanted to change it. >> But then I thought that it is not that wrong: in the debugger the inspector of the context shows >> not just the vars that are in the context, but all that *could* be there. All where I can lookup and >> get a result, e.g. >> >> ast statements last value scope lookupVar: 'foo' >> >> Thus all those that I *could* write in the code inside the block. >> >> I am not sure, thoughâ¦ maybe we should change it. >> >> Marcus >> >> >>> But it seems that the outer context of the block closure knows about foo, although the value seems nil. >>> >>> And if it closes over foo, foo's value/binding won't be GC-ed so long as there is a reference to the block closure, even though foo is not practically accessible. >>> >>> Sven > >

June 29, 2013

Re: [Pharo-dev] VM ppa question

by GOUBIER Thierry

Hi Sven, I believe Damien said a while ago to switch to an "official' pharo ppa instead of his: deb http://ppa.launchpad.net/pharo/stable/ubuntu raring main (I still have both in my /etc/apt/sources.list.d/ :)) Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Sven Van Caekenberghe [sven(a)stfx.eu] Date d'envoi : samedi 29 juin 2013 11:31 Ã : Pharo Development List Objet : [Pharo-dev] VM ppa question Hi, On a machine where I once installed the VM via the ppa method, I now get apt some errors: t3@coolerslave:smalltalk$ sudo apt-get update [sudo] password for t3: Get:1 http://security.ubuntu.com quantal-security Release.gpg [933 B] Hit http://be.archive.ubuntu.com quantal Release.gpg Ign http://ppa.launchpad.net quantal Release.gpg Get:2 http://security.ubuntu.com quantal-security Release [49.6 kB] Get:3 http://be.archive.ubuntu.com quantal-updates Release.gpg [933 B] Hit http://ppa.launchpad.net quantal Release.gpg Hit http://be.archive.ubuntu.com quantal-backports Release.gpg Hit http://ppa.launchpad.net quantal Release.gpg Ign http://ppa.launchpad.net quantal Release Hit http://be.archive.ubuntu.com quantal Release Get:4 http://be.archive.ubuntu.com quantal-updates Release [49.6 kB] Hit http://ppa.launchpad.net quantal Release Hit http://ppa.launchpad.net quantal Release Ign http://ppa.launchpad.net quantal/main Sources/DiffIndex Hit http://be.archive.ubuntu.com quantal-backports Release Get:5 http://security.ubuntu.com quantal-security/main Sources [51.9 kB] Ign http://ppa.launchpad.net quantal/main amd64 Packages/DiffIndex Hit http://be.archive.ubuntu.com quantal/main Sources Hit http://be.archive.ubuntu.com quantal/restricted Sources Hit http://be.archive.ubuntu.com quantal/universe Sources Hit http://be.archive.ubuntu.com quantal/multiverse Sources Ign http://ppa.launchpad.net quantal/main i386 Packages/DiffIndex Hit http://be.archive.ubuntu.com quantal/main amd64 Packages Get:6 http://security.ubuntu.com quantal-security/restricted Sources [1,833 B] Hit http://be.archive.ubuntu.com quantal/restricted amd64 Packages Get:7 http://security.ubuntu.com quantal-security/universe Sources [19.2 kB] Hit http://be.archive.ubuntu.com quantal/universe amd64 Packages Get:8 http://security.ubuntu.com quantal-security/multiverse Sources [696 B] Hit http://ppa.launchpad.net quantal/main Sources Hit http://be.archive.ubuntu.com quantal/multiverse amd64 Packages Get:9 http://security.ubuntu.com quantal-security/main amd64 Packages [146 kB] Hit http://ppa.launchpad.net quantal/main amd64 Packages Hit http://be.archive.ubuntu.com quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/restricted i386 Packages Hit http://ppa.launchpad.net quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/universe i386 Packages Get:10 http://security.ubuntu.com quantal-security/restricted amd64 Packages [3,469 B] Hit http://be.archive.ubuntu.com quantal/multiverse i386 Packages Get:11 http://security.ubuntu.com quantal-security/universe amd64 Packages [54.7 kB] Hit http://ppa.launchpad.net quantal/main Sources Get:12 http://security.ubuntu.com quantal-security/multiverse amd64 Packages [1,152 B] Hit http://be.archive.ubuntu.com quantal/main Translation-en Get:13 http://security.ubuntu.com quantal-security/main i386 Packages [144 kB] Hit http://ppa.launchpad.net quantal/main amd64 Packages Hit http://be.archive.ubuntu.com quantal/multiverse Translation-en Hit http://ppa.launchpad.net quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/restricted Translation-en Get:14 http://security.ubuntu.com quantal-security/restricted i386 Packages [3,531 B] Get:15 http://security.ubuntu.com quantal-security/universe i386 Packages [55.2 kB] Hit http://be.archive.ubuntu.com quantal/universe Translation-en Get:16 http://be.archive.ubuntu.com quantal-updates/main Sources [106 kB] Get:17 http://security.ubuntu.com quantal-security/multiverse i386 Packages [1,396 B] Hit http://security.ubuntu.com quantal-security/main Translation-en Get:18 http://be.archive.ubuntu.com quantal-updates/restricted Sources [2,564 B] Get:19 http://be.archive.ubuntu.com quantal-updates/universe Sources [88.8 kB] Hit http://security.ubuntu.com quantal-security/multiverse Translation-en Hit http://security.ubuntu.com quantal-security/restricted Translation-en Hit http://security.ubuntu.com quantal-security/universe Translation-en Get:20 http://be.archive.ubuntu.com quantal-updates/multiverse Sources [3,998 B] Get:21 http://be.archive.ubuntu.com quantal-updates/main amd64 Packages [273 kB] Ign http://security.ubuntu.com quantal-security/main Translation-en_US Get:22 http://be.archive.ubuntu.com quantal-updates/restricted amd64 Packages [4,804 B] Ign http://security.ubuntu.com quantal-security/multiverse Translation-en_US Get:23 http://be.archive.ubuntu.com quantal-updates/universe amd64 Packages [195 kB] Ign http://security.ubuntu.com quantal-security/restricted Translation-en_US Ign http://security.ubuntu.com quantal-security/universe Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en_US Get:24 http://be.archive.ubuntu.com quantal-updates/multiverse amd64 Packages [10.8 kB] Ign http://ppa.launchpad.net quantal/main Translation-en Get:25 http://be.archive.ubuntu.com quantal-updates/main i386 Packages [272 kB] Err http://ppa.launchpad.net quantal/main Sources 404 Not Found Err http://ppa.launchpad.net quantal/main amd64 Packages 404 Not Found Ign http://ppa.launchpad.net quantal/main Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en Ign http://ppa.launchpad.net quantal/main Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en Get:26 http://be.archive.ubuntu.com quantal-updates/restricted i386 Packages [4,841 B] Err http://ppa.launchpad.net quantal/main i386 Packages 404 Not Found Get:27 http://be.archive.ubuntu.com quantal-updates/universe i386 Packages [195 kB] Get:28 http://be.archive.ubuntu.com quantal-updates/multiverse i386 Packages [10.9 kB] Hit http://be.archive.ubuntu.com quantal-updates/main Translation-en Hit http://be.archive.ubuntu.com quantal-updates/multiverse Translation-en Hit http://be.archive.ubuntu.com quantal-updates/restricted Translation-en Hit http://be.archive.ubuntu.com quantal-updates/universe Translation-en Hit http://be.archive.ubuntu.com quantal-backports/main Sources Hit http://be.archive.ubuntu.com quantal-backports/restricted Sources Hit http://be.archive.ubuntu.com quantal-backports/universe Sources Hit http://be.archive.ubuntu.com quantal-backports/multiverse Sources Hit http://be.archive.ubuntu.com quantal-backports/main amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/restricted amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/universe amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/multiverse amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/main i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/restricted i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/universe i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/multiverse i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/main Translation-en Hit http://be.archive.ubuntu.com quantal-backports/multiverse Translation-en Hit http://be.archive.ubuntu.com quantal-backports/restricted Translation-en Hit http://be.archive.ubuntu.com quantal-backports/universe Translation-en Ign http://be.archive.ubuntu.com quantal/main Translation-en_US Ign http://be.archive.ubuntu.com quantal/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal/universe Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/main Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/universe Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/main Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/universe Translation-en_US Fetched 1,752 kB in 3s (439 kB/s) W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/source/Sour… 404 Not Found W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/binary-amd6… 404 Not Found W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/binary-i386… 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. apt has always been a bit of mystery to me. Maybe the problem is that the ppa moved ? Is there a way to fix this ? Maybe uninstall some stuff ? Thx, Sven

June 29, 2013

VM ppa question

by Sven Van Caekenberghe

Hi, On a machine where I once installed the VM via the ppa method, I now get apt some errors: t3@coolerslave:smalltalk$ sudo apt-get update [sudo] password for t3: Get:1 http://security.ubuntu.com quantal-security Release.gpg [933 B] Hit http://be.archive.ubuntu.com quantal Release.gpg Ign http://ppa.launchpad.net quantal Release.gpg Get:2 http://security.ubuntu.com quantal-security Release [49.6 kB] Get:3 http://be.archive.ubuntu.com quantal-updates Release.gpg [933 B] Hit http://ppa.launchpad.net quantal Release.gpg Hit http://be.archive.ubuntu.com quantal-backports Release.gpg Hit http://ppa.launchpad.net quantal Release.gpg Ign http://ppa.launchpad.net quantal Release Hit http://be.archive.ubuntu.com quantal Release Get:4 http://be.archive.ubuntu.com quantal-updates Release [49.6 kB] Hit http://ppa.launchpad.net quantal Release Hit http://ppa.launchpad.net quantal Release Ign http://ppa.launchpad.net quantal/main Sources/DiffIndex Hit http://be.archive.ubuntu.com quantal-backports Release Get:5 http://security.ubuntu.com quantal-security/main Sources [51.9 kB] Ign http://ppa.launchpad.net quantal/main amd64 Packages/DiffIndex Hit http://be.archive.ubuntu.com quantal/main Sources Hit http://be.archive.ubuntu.com quantal/restricted Sources Hit http://be.archive.ubuntu.com quantal/universe Sources Hit http://be.archive.ubuntu.com quantal/multiverse Sources Ign http://ppa.launchpad.net quantal/main i386 Packages/DiffIndex Hit http://be.archive.ubuntu.com quantal/main amd64 Packages Get:6 http://security.ubuntu.com quantal-security/restricted Sources [1,833 B] Hit http://be.archive.ubuntu.com quantal/restricted amd64 Packages Get:7 http://security.ubuntu.com quantal-security/universe Sources [19.2 kB] Hit http://be.archive.ubuntu.com quantal/universe amd64 Packages Get:8 http://security.ubuntu.com quantal-security/multiverse Sources [696 B] Hit http://ppa.launchpad.net quantal/main Sources Hit http://be.archive.ubuntu.com quantal/multiverse amd64 Packages Get:9 http://security.ubuntu.com quantal-security/main amd64 Packages [146 kB] Hit http://ppa.launchpad.net quantal/main amd64 Packages Hit http://be.archive.ubuntu.com quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/restricted i386 Packages Hit http://ppa.launchpad.net quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/universe i386 Packages Get:10 http://security.ubuntu.com quantal-security/restricted amd64 Packages [3,469 B] Hit http://be.archive.ubuntu.com quantal/multiverse i386 Packages Get:11 http://security.ubuntu.com quantal-security/universe amd64 Packages [54.7 kB] Hit http://ppa.launchpad.net quantal/main Sources Get:12 http://security.ubuntu.com quantal-security/multiverse amd64 Packages [1,152 B] Hit http://be.archive.ubuntu.com quantal/main Translation-en Get:13 http://security.ubuntu.com quantal-security/main i386 Packages [144 kB] Hit http://ppa.launchpad.net quantal/main amd64 Packages Hit http://be.archive.ubuntu.com quantal/multiverse Translation-en Hit http://ppa.launchpad.net quantal/main i386 Packages Hit http://be.archive.ubuntu.com quantal/restricted Translation-en Get:14 http://security.ubuntu.com quantal-security/restricted i386 Packages [3,531 B] Get:15 http://security.ubuntu.com quantal-security/universe i386 Packages [55.2 kB] Hit http://be.archive.ubuntu.com quantal/universe Translation-en Get:16 http://be.archive.ubuntu.com quantal-updates/main Sources [106 kB] Get:17 http://security.ubuntu.com quantal-security/multiverse i386 Packages [1,396 B] Hit http://security.ubuntu.com quantal-security/main Translation-en Get:18 http://be.archive.ubuntu.com quantal-updates/restricted Sources [2,564 B] Get:19 http://be.archive.ubuntu.com quantal-updates/universe Sources [88.8 kB] Hit http://security.ubuntu.com quantal-security/multiverse Translation-en Hit http://security.ubuntu.com quantal-security/restricted Translation-en Hit http://security.ubuntu.com quantal-security/universe Translation-en Get:20 http://be.archive.ubuntu.com quantal-updates/multiverse Sources [3,998 B] Get:21 http://be.archive.ubuntu.com quantal-updates/main amd64 Packages [273 kB] Ign http://security.ubuntu.com quantal-security/main Translation-en_US Get:22 http://be.archive.ubuntu.com quantal-updates/restricted amd64 Packages [4,804 B] Ign http://security.ubuntu.com quantal-security/multiverse Translation-en_US Get:23 http://be.archive.ubuntu.com quantal-updates/universe amd64 Packages [195 kB] Ign http://security.ubuntu.com quantal-security/restricted Translation-en_US Ign http://security.ubuntu.com quantal-security/universe Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en_US Get:24 http://be.archive.ubuntu.com quantal-updates/multiverse amd64 Packages [10.8 kB] Ign http://ppa.launchpad.net quantal/main Translation-en Get:25 http://be.archive.ubuntu.com quantal-updates/main i386 Packages [272 kB] Err http://ppa.launchpad.net quantal/main Sources 404 Not Found Err http://ppa.launchpad.net quantal/main amd64 Packages 404 Not Found Ign http://ppa.launchpad.net quantal/main Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en Ign http://ppa.launchpad.net quantal/main Translation-en_US Ign http://ppa.launchpad.net quantal/main Translation-en Get:26 http://be.archive.ubuntu.com quantal-updates/restricted i386 Packages [4,841 B] Err http://ppa.launchpad.net quantal/main i386 Packages 404 Not Found Get:27 http://be.archive.ubuntu.com quantal-updates/universe i386 Packages [195 kB] Get:28 http://be.archive.ubuntu.com quantal-updates/multiverse i386 Packages [10.9 kB] Hit http://be.archive.ubuntu.com quantal-updates/main Translation-en Hit http://be.archive.ubuntu.com quantal-updates/multiverse Translation-en Hit http://be.archive.ubuntu.com quantal-updates/restricted Translation-en Hit http://be.archive.ubuntu.com quantal-updates/universe Translation-en Hit http://be.archive.ubuntu.com quantal-backports/main Sources Hit http://be.archive.ubuntu.com quantal-backports/restricted Sources Hit http://be.archive.ubuntu.com quantal-backports/universe Sources Hit http://be.archive.ubuntu.com quantal-backports/multiverse Sources Hit http://be.archive.ubuntu.com quantal-backports/main amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/restricted amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/universe amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/multiverse amd64 Packages Hit http://be.archive.ubuntu.com quantal-backports/main i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/restricted i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/universe i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/multiverse i386 Packages Hit http://be.archive.ubuntu.com quantal-backports/main Translation-en Hit http://be.archive.ubuntu.com quantal-backports/multiverse Translation-en Hit http://be.archive.ubuntu.com quantal-backports/restricted Translation-en Hit http://be.archive.ubuntu.com quantal-backports/universe Translation-en Ign http://be.archive.ubuntu.com quantal/main Translation-en_US Ign http://be.archive.ubuntu.com quantal/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal/universe Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/main Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal-updates/universe Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/main Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/multiverse Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/restricted Translation-en_US Ign http://be.archive.ubuntu.com quantal-backports/universe Translation-en_US Fetched 1,752 kB in 3s (439 kB/s) W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/source/Sour… 404 Not Found W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/binary-amd6… 404 Not Found W: Failed to fetch http://ppa.launchpad.net/cassou/pharo/ubuntu/dists/quantal/main/binary-i386… 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. apt has always been a bit of mystery to me. Maybe the problem is that the ppa moved ? Is there a way to fix this ? Maybe uninstall some stuff ? Thx, Sven

June 29, 2013

Re: [Pharo-dev] Question about closure compilation

by Sven Van Caekenberghe

Hi Marcus, On 29 Jun 2013, at 11:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >> >> OK, that seems OK. >> >> The reason I was asking was because I wanted to know if this JavaScript bug would hit us as well: >> >> http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.… >> >> It is slightly more complicated than the basic question of closing over an unreferenced variable though. >> >> I just can't figure out a way to quickly test it in Pharo. I think it is worth looking into. > > Yes, we have exactly the same problem. > > imagine a method like this: > > test > | bigObject smallObject | > > [bigObject := Array new: 1000000] value. > ^[smallObject := 1]. > > > both big and small are escaping variables that are written. This means they are allocated > in an Array on the heap (Cog is calling this a TempVector). > > There is just one tempVector created per scope, so we will have a tempVector with both > smallObject and bigObject inside created for the method. This then is passed to the blocks, which > access the temps via the vector. > > The bytecode looks like this: > > 21 <8A 02> push: (Array new: 2) > 23 <68> popIntoTemp: 0 > 24 <10> pushTemp: 0 > 25 <8F 10 00 07> closureNumCopied: 1 numArgs: 0 bytes 29 to 35 > 29 <40> pushLit: Array > 30 <21> pushConstant: 1000000 > 31 <CD> send: new: > 32 <8D 00 00> storeIntoTemp: 0 inVectorAt: 0 > 35 <7D> blockReturn > 36 <C9> send: value > 37 <87> pop > 38 <10> pushTemp: 0 > 39 <8F 10 00 05> closureNumCopied: 1 numArgs: 0 bytes 43 to 47 > 43 <76> pushConstant: 1 > 44 <8D 01 00> storeIntoTemp: 1 inVectorAt: 0 > 47 <7D> blockReturn > 48 <7C> returnTop > > The closure [smallObject := 1] now, even though not referencing the largeObject, references > the tempVector. This tempVector holds on the to large object --> memory is wasted that is not needed. > > Back when implementing the SemChecker, I was thinking about this and wonderingâ¦ for sure > this can be optimized by allocating multiple arrays per scope, depending on how they are used later. > But even then I am sure you can construct strange cases (multiple nested blocks). > > And of course allocating 2 Arrays (or more) wastes memory, too. > > So this is not a simple problemâ¦ the question is how much it matters in practice, though. > > Marcus Thanks for the explanation. I am also not sure if this would be a real problem in practice. I guess most code can be rewritten to avoid it. But it is probably a good idea to document this, maybe in a unit test. And who knows, maybe one day we'll have to revisit this. Sven

June 29, 2013

Re: [Pharo-dev] Question about closure compilation

by Marcus Denker

>> > > OK, that seems OK. > > The reason I was asking was because I wanted to know if this JavaScript bug would hit us as well: > > http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.… > > It is slightly more complicated than the basic question of closing over an unreferenced variable though. > > I just can't figure out a way to quickly test it in Pharo. I think it is worth looking into. Yes, we have exactly the same problem. imagine a method like this: test | bigObject smallObject | [bigObject := Array new: 1000000] value. ^[smallObject := 1]. both big and small are escaping variables that are written. This means they are allocated in an Array on the heap (Cog is calling this a TempVector). There is just one tempVector created per scope, so we will have a tempVector with both smallObject and bigObject inside created for the method. This then is passed to the blocks, which access the temps via the vector. The bytecode looks like this: 21 <8A 02> push: (Array new: 2) 23 <68> popIntoTemp: 0 24 <10> pushTemp: 0 25 <8F 10 00 07> closureNumCopied: 1 numArgs: 0 bytes 29 to 35 29 <40> pushLit: Array 30 <21> pushConstant: 1000000 31 <CD> send: new: 32 <8D 00 00> storeIntoTemp: 0 inVectorAt: 0 35 <7D> blockReturn 36 <C9> send: value 37 <87> pop 38 <10> pushTemp: 0 39 <8F 10 00 05> closureNumCopied: 1 numArgs: 0 bytes 43 to 47 43 <76> pushConstant: 1 44 <8D 01 00> storeIntoTemp: 1 inVectorAt: 0 47 <7D> blockReturn 48 <7C> returnTop The closure [smallObject := 1] now, even though not referencing the largeObject, references the tempVector. This tempVector holds on the to large object --> memory is wasted that is not needed. Back when implementing the SemChecker, I was thinking about this and wonderingâ¦ for sure this can be optimized by allocating multiple arrays per scope, depending on how they are used later. But even then I am sure you can construct strange cases (multiple nested blocks). And of course allocating 2 Arrays (or more) wastes memory, too. So this is not a simple problemâ¦ the question is how much it matters in practice, though. Marcus

June 29, 2013

Re: [Pharo-dev] brief explanation of the new class organizer

by Esteban Lorenzano

On Jun 29, 2013, at 9:29 AM, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > I love objects but we should consider that they had memory constraints and soon we will have them too > because we are starting to have them for Moose ;) then we need a better vm/object space/whatever... not to strip down the objects :) Esteban > > Stef > >>> >> What strikes me is why such simple concept, which you can express with >> couple words: "methods in class can have categories", ends up into >> insanely complex mess of code over multiple layers in system. >> Anything which puts more order and logic, simplifies these things is welcome. >> And of course, we cannot see the forest beyond the wall of fallen >> trees. So we must clean it up first. > > oh yes! >> >> >>> cheers, >>> Esteban >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

June 29, 2013

Re: [Pharo-dev] [ANN] SS3 the canary site

by StÃ©phane Ducasse

Thanks tobias. To me your version of SS3 looks even more Squeak centric and this is ok but my plate is full and I'm sorry but I focus on Pharo because we must deliver and continue. Now don't you think that joining effort on SmalltalkHub (did you see the name is not PharoHub) would make more sense? Also because the stack behind is sexy and can be reused/improved for business. And you guess what? I want and push daily business in Pharo. I want smart guys like you, camillo, guilermo, ben, nicolas, igor, esteban and many more to be able to decide if they want to get a cool job with Pharo. Stef On Jun 28, 2013, at 11:55 PM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Dear fellow Smalltalkers > > For me to test new features of SqueakSource3 and for you to have a look on > new features and fixed bugs, I have created > > http://canary.netshed.de/ > > which is the most recent, say alpha, deployment of SqueakSource3. > It contains features that are not yet deployed at other ss3 sites, > including the gemstone one. I cannot make any guaranty that code commited > to the canary will survive forever; > it is a play toy, so go play with it :) > > Attached a teaser image. > > Best > -Tobias > > <BrowsingSS3Canary.PNG>

June 29, 2013

Re: [Pharo-dev] brief explanation of the new class organizer

by stephane ducasse

I love objects but we should consider that they had memory constraints and soon we will have them too because we are starting to have them for Moose ;) Stef >> > What strikes me is why such simple concept, which you can express with > couple words: "methods in class can have categories", ends up into > insanely complex mess of code over multiple layers in system. > Anything which puts more order and logic, simplifies these things is welcome. > And of course, we cannot see the forest beyond the wall of fallen > trees. So we must clean it up first. oh yes! > > >> cheers, >> Esteban > > > > -- > Best regards, > Igor Stasenko. >

June 29, 2013

Re: [Pharo-dev] brief explanation of the new class organizer

by Igor Stasenko

On 29 June 2013 00:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > So... this is what I made las days (as a conclusion of many days before): > > The old class organizer was a mess. Basically, it considered all protocols as strings, and for worst it was arranging them into a flat array. > While the array stuff is just an internal problem (objects outside doesn't know how are they managed, and that's good), having protocols-as-strings is essentially bad (no need for explanations about that). > > The new class organizer just do what is more or less obvious: > > 1) replaces string protocols for first class instances (now instances of Protocol). > 2) internally, manages protocols and methods in protocols in a much better and fashion way. > > (btw, the implementation was made by Ben, thanks!) > > the real important part is the point 1. Now we can start to assign real behavior to Protocol, For instance, I will create an ExtensionProcol which will contain a direct pointer to it's real package. That means that we do not need weird computations to get a method extension package (and when the tools allows us, we could get rid off the *Blah). I would like also to be able to have "composite" protocols (like "private"+"accesing"), etc. > It will allow a refactor of current RPackage implementation, allowing us to simplify the SystemAnnounce mechanism (and speeding up monticello, if my calculous are fine). > > And like this, there are still a huge room for improvement, I hope many that I do not even thought about :) > What strikes me is why such simple concept, which you can express with couple words: "methods in class can have categories", ends up into insanely complex mess of code over multiple layers in system. Anything which puts more order and logic, simplifies these things is welcome. And of course, we cannot see the forest beyond the wall of fallen trees. So we must clean it up first. > cheers, > Esteban -- Best regards, Igor Stasenko.

June 29, 2013