- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ifError: implementation is bad

by Tudor Girba

Hi, Denis says that right now, to use ifError: you do: [...] ifError: [:msg :rcv | â¦ ] and he would like to write this: [...] ifError: [:error | â¦ ] I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly. Does it make more sense now? Or did I get it wrong? Cheers, Doru > On Jan 8, 2016, at 10:05 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi denis > I do not understand the problem and I'm convinced that you are right > so can anybody explain to me the point made by denis? > > Stef > > Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : >> Hi >> >> I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. >> But what is this arguments? It is not error instance but specific properties from it. >> >> BlockClosure>>ifError: errorHandlerBlock >> >> ^ self on: Error do: [:ex | >> errorHandlerBlock cull: ex description cull: ex receiver] >> >> Why people doing that? >> Many users of it just pass given error like >> >> [...] ifError: [:msg :rcv | ... >> rcv error: msg]. >> >> Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. >> >> I propose change ifError: to cull error instance. >> >> What you think? Can be put it in Pharo 5? Such change can touch some packages > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Jan. 8, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

In general I do not like cull: and I'm really suspicious about its use. It often reveals a lack of coherence and/or design. Why this is not simply BlockClosure>>ifError: errorHandlerBlock ^ self on: Error do: errorHandlerBlock ?? > Hi > > I look at implementation of BlockClosure>>ifError: . I did't know that > it culls arguments to errorBlock. > But what is this arguments? It is not error instance but specific > properties from it. > > BlockClosure>>ifError: errorHandlerBlock > > ^ self on: Error do: [:ex | > errorHandlerBlock cull: ex description cull: ex receiver] > > > Why people doing that? > Many users of it just pass given error like > > [...] ifError: [:msg :rcv | ... > > rcv error: msg]. > > > Especially it is commonly used scenario by senders of > #critical:ifError:. But it is different question. > I propose change ifError: to cull error instance. > > What you think? Can be put it in Pharo 5? Such change can touch some > packages

Jan. 8, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis? Stef Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : > Hi > > I look at implementation of BlockClosure>>ifError: . I did't know that > it culls arguments to errorBlock. > But what is this arguments? It is not error instance but specific > properties from it. > > BlockClosure>>ifError: errorHandlerBlock > > ^ self on: Error do: [:ex | > errorHandlerBlock cull: ex description cull: ex receiver] > > > Why people doing that? > Many users of it just pass given error like > > [...] ifError: [:msg :rcv | ... > > rcv error: msg]. > > > Especially it is commonly used scenario by senders of > #critical:ifError:. But it is different question. > I propose change ifError: to cull error instance. > > What you think? Can be put it in Pharo 5? Such change can touch some > packages

Jan. 8, 2016

problem with become:?

by Tudor Girba

Hi, If I execute the following code in the latest Pharo image: Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA'. Object subclass: #B instanceVariableNames: '' classVariableNames: '' package: 'AA'. a := A new. b := B new. a become: b. a class ==> âA". In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a change I am not aware of? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Ben Coman

On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > I wonder if someone could give me a hand to find out why a FFI calling I am > doing is crashing. In OSX it works correct but I am testing in CentOS and it > fails. I wonder if it also crashes in other Linuxes too. I only had enough time to run it a few time so you know it also crashes in Debian Jessie 32-bit. There were no debug logs. I got these sorts of messages... *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size (fast): 0x08841a70 *** pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed. *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory corruption: 0x0984c1e0 *** Searching github for "posix_spawn_file_actions_init " (https://git.io/vuSPL) I see a lot a function definitions of the form... int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) { fa->__actions = 0; return 0; } ...so it seems you need to first allocate the space for the struct and then pass the address of that. { int __allocated; int __used; struct __spawn_action *__actions; int __pad[16]; } posix_spawn_file_actions_t; // http://linux.die.net/include/spawn.h cheers -ben > > I am using latest Pharo 5.0 with Spur. To reproduce: > > 1) Get latest Pharo 5.0 and Spur via: > wget -O- get.pharo.org/alpha+vm | bash > > 2) Inside Pharo, load my prototype tool: > > Gofer it > package: 'OSSubprocess'; > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; > load. > > 3) This is the code I am executing and it's crashing: > > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress > allocate: 4. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: > posixSpawnFileActionsT. posixSpawnFileActionsT free. > 4) The primitive is as simple as: > > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* > aPosixSpawnFileActionsT) ) module: LibC > > I have no idea what I am doing wrong. And again, this works on OSX. The > function I am calling is: int > posix_spawn_file_actions_init(posix_spawn_file_actions_t *file_actions); as > you can read in [1] > > Below is the stacktrace I get the Linux terminal. > > Any hint is greatly appreciated. > > Thanks, > > > [1] > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_…

Jan. 8, 2016

Re: [Pharo-dev] Question about attribution under the MIT License

by monty

This line form the text of the license suggests we should really be bundling the full license text with our code, not just stating "this code is MIT" on the STH project page: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." Because of this, I've started adding #catalogLicense methods to STH Configs I manage that return the entire MIT license text with a copyright statement. I think everyone should do the same. > Sent: Friday, January 08, 2016 at 11:08 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] Question about attribution under the MIT License > > Hi, > > I have a been wondering recently about attribution under the MIT License. > > Code in Pharo and code contributed to Pharo is and should be licensed under the MIT License. > > https://en.wikipedia.org/wiki/MIT_License > > Contributors sign an extra agreement. > > http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf > > Here, contributors give a license so Pharo can include their code. > > As I read the MIT license the original author keeps the copyright and about the only requirement is that that copyright shall be included when the code is used. The extra agreement does not transfer copyright. > > So, all authors should be mentioned in the general Pharo MIT license. > > The reason I was thinking about this is that many people on the list seems to be under the impression that MIT licensed code means that you can freely copy it, like most recently in the discussions about Dophin Smalltalk. I think copying MIT licensed code requires proper attribution. > > If people copy (my, someone else's) code from Pharo to somewhere else, I want them to at least acknowledge that fact, preferably include a general Pharo (contributors) copyright, but ideally (my, their) copyright. > > But that would also mean that Pharo has to do the same. I think we should list and update the official contributor list, including the historical list of original authors going back. > > Am I right or wrong ? > > How do other people feel about this ? > > Sven > > >

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Max Leske

> On 08 Jan 2016, at 19:35, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Jan 8, 2016 at 3:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > Hi guys, > > I wonder if someone could give me a hand to find out why a FFI calling I am doing is crashing. In OSX it works correct but I am testing in CentOS and it fails. I wonder if it also crashes in other Linuxes too. > > I am using latest Pharo 5.0 with Spur. To reproduce: > > 1) Get latest Pharo 5.0 and Spur via: > wget -O- get.pharo.org/alpha+vm <http://get.pharo.org/alpha+vm> | bash > > 2) Inside Pharo, load my prototype tool: > > Gofer it > package: 'OSSubprocess'; > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main <http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main>'; > load. > > 3) This is the code I am executing and it's crashing: > > | posixSpawnFileActionsT | > posixSpawnFileActionsT := ExternalAddress allocate: 4. > > > If I change above line with this: > > posixSpawnFileActionsT := ByteArray new: 4. Wil this not allocate more the four bytes because of the object header? So how about allocating 8 bytes for the pointer (just for fun)? ExternalAddress allocate: 8 > > Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy(). > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

On Fri, Jan 8, 2016 at 3:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi guys, > > I wonder if someone could give me a hand to find out why a FFI calling I > am doing is crashing. In OSX it works correct but I am testing in CentOS > and it fails. I wonder if it also crashes in other Linuxes too. > > I am using latest Pharo 5.0 with Spur. To reproduce: > > 1) Get latest Pharo 5.0 and Spur via: > wget -O- get.pharo.org/alpha+vm | bash > > 2) Inside Pharo, load my prototype tool: > > Gofer it > package: 'OSSubprocess'; > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; > load. > > 3) This is the code I am executing and it's crashing: > > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress > allocate: 4. > If I change above line with this: posixSpawnFileActionsT := ByteArray new: 4. Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy(). -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2016

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Johan Fabry

I second Torstenâs comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > On Jan 8, 2016, at 14:28, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. > > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) > > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. > > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com[http://www.tudorgirba.com] > www.feenk.com[http://www.feenk.com] > > "Beauty is where we see it." ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 8, 2016

Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

Hi guys, I wonder if someone could give me a hand to find out why a FFI calling I am doing is crashing. In OSX it works correct but I am testing in CentOS and it fails. I wonder if it also crashes in other Linuxes too. I am using latest Pharo 5.0 with Spur. To reproduce: 1) Get latest Pharo 5.0 and Spur via: wget -O- get.pharo.org/alpha+vm | bash 2) Inside Pharo, load my prototype tool: Gofer it package: 'OSSubprocess'; url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; load. 3) This is the code I am executing and it's crashing: | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress allocate: 4. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: posixSpawnFileActionsT. posixSpawnFileActionsT free. 4) The primitive is as simple as: primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT ^ self ffiCall: #( int posix_spawn_file_actions_init(void* aPosixSpawnFileActionsT) ) module: LibC I have no idea what I am doing wrong. And again, this works on OSX. The function I am calling is: int posix_spawn_file_actions_init(posix_spawn_file_actions_t *file_actions); as you can read in [1] Below is the stacktrace I get the Linux terminal. Any hint is greatly appreciated. Thanks, [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… **** Error in `/home/centos/pharo-vm/pharo': malloc(): memory corruption (fast): 0x09544268 **** ======= Backtrace: ========= /lib/libc.so.6(+0x7428c)[0xf758e28c] /lib/libc.so.6(+0x76d98)[0xf7590d98] /lib/libc.so.6(__libc_calloc+0xa7)[0xf7592df7] /home/centos/pharo-vm/pharo[0x80b8f44] /home/centos/pharo-vm/pharo[0x80b909c] /home/centos/pharo-vm/pharo(ioLoadExternalFunctionOfLengthFromModuleOfLengthAccessorDepthInto+0xc2)[0x80b9402] /home/centos/pharo-vm/pharo[0x808de6f] /home/centos/pharo-vm/pharo[0x80a0810] /home/centos/pharo-vm/pharo(ceSendsupertonumArgs+0x1da)[0x80a1f4a] [0x960004c] [0x9600b00] [0xaec2e9b] [0xaec3481] [0x9604ff0] [0x964ed43] [0x9604f5c] [0x960424c] [0x9602e47] [0x9602be7] [0x960320c] [0x9602277] [0x960bec2] [0x9600b00] [0x9600ad8] ======= Memory map: ======== 08048000-08151000 r-xp 00000000 fd:01 202178584 /home/centos/pharo-vm/pharo 08151000-08152000 r--p 00108000 fd:01 202178584 /home/centos/pharo-vm/pharo 08152000-0815c000 rw-p 00109000 fd:01 202178584 /home/centos/pharo-vm/pharo 0815c000-08193000 rw-p 00000000 00:00 0 09505000-095a5000 rw-p 00000000 00:00 0 [heap] 09600000-09701000 rwxp 00000000 00:00 0 09701000-0dbc0000 rw-p 00000000 00:00 0 f6de5000-f6dfe000 r-xp 00000000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dfe000-f6dff000 r--p 00018000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dff000-f6e00000 rw-p 00019000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6e00000-f6e21000 rw-p 00000000 00:00 0 f6e21000-f6f00000 ---p 00000000 00:00 0 f6f25000-f6f26000 rw-p 00000000 00:00 0 f6f26000-f6f2e000 r-xp 00000000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2e000-f6f2f000 r--p 00007000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2f000-f6f30000 rw-p 00008000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f30000-f6f32000 r-xp 00000000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f32000-f6f33000 r--p 00001000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f33000-f6f34000 rw-p 00002000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f34000-f6f5b000 r-xp 00000000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5b000-f6f5d000 r--p 00026000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5d000-f6f5e000 rw-p 00028000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5e000-f6fc0000 r-xp 00000000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc0000-f6fc2000 r--p 00061000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc2000-f6fc3000 rw-p 00063000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc3000-f6fcf000 r-xp 00000000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fcf000-f6fd0000 r--p 0000b000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd0000-f6fd1000 rw-p 0000c000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd1000-f6fd5000 r-xp 00000000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd5000-f6fd6000 r--p 00004000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd6000-f6fd7000 rw-p 00005000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd7000-f6fd8000 r-xp 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd8000-f6fd9000 r--p 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd9000-f6fda000 rw-p 00001000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fda000-f6ffd000 r-xp 00000000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffd000-f6ffe000 r--p 00022000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffe000-f6fff000 rw-p 00023000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6fff000-f7004000 r-xp 00000000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7004000-f7005000 r--p 00005000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7005000-f7006000 rw-p 00006000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7006000-f7009000 r-xp 00000000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f7009000-f700a000 r--p 00002000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700a000-f700b000 rw-p 00003000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700b000-f7014000 r-xp 00000000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7014000-f7015000 r--p 00008000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7015000-f7016000 rw-p 00009000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7016000-f701d000 r-xp 00000000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701d000-f701e000 r--p 00006000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701e000-f701f000 rw-p 00007000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701f000-f702c000 r-xp 00000000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702c000-f702d000 r--p 0000d000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702d000-f702e000 rw-p 0000e000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702e000-f7030000 r-xp 00000000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7030000-f7031000 r--p 00001000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7031000-f7032000 rw-p 00002000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7032000-f7034000 r-xp 00000000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7034000-f7035000 r--p 00001000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7035000-f7036000 rw-p 00002000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7036000-f703a000 r-xp 00000000 fd:01 203140421 /usr/lib/libxcb-dri2.so.0.0.0./pharo-ui: line 11: 4019 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2016