March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Thanks for Pharo
by Scott Gibson March 30, 2011

March 30, 2011

I just wanted to say thanks to everyone for all of the hard work that has been done for Pharo. Pharo 1.2 has come a long way and has been very enjoyable to use. Recently I had been given the opportunity to develop an application for a potential customer. I chose to use Pharo and Seaside and have been very happy with how well using Pharo 1.2 has been, with Cog even. I am very new to Smalltalk but I have been looking to help in any way (financially, documentation, etc.) that I can in order to help the progress of an open source Smalltalk, Pharo specifically. I am so new to Smalltalk that I feel I would be more of a hinderance than anything so I have not quite figured out how I could best help though I do hope to contribute in some way soon. Thanks again! Scott Gibson

2 2

[Pharo-project] [COTDC] 38 - PathShape
by laurent laffont March 30, 2011

March 30, 2011

Let's comment Polymorph for several days. Today: PathShape Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

2 3

Re: [Pharo-project] Which methods are really not executed?
by Marcus Denker March 30, 2011

March 30, 2011

On Mar 28, 2011, at 11:28 AM, Mariano Martinez Peck wrote: > Hi folks. I would like to know which are the messages that are not really executed, thus not being intercepted by proxies. > So far, I know: > > 1) > those are inlined by the compiler... > yes. > 2) Special shorcut bytecodes that are in "Smalltalk specialSelectors" / "ParseNode classVarNamed: 'StdSelectors'" / "Smalltalk specialObjectsArray at: 24" > > Here I have a question...if I understand correctly, in this list of selectors there are 3 cases: > > 2.1) methods may or may not be executed depending on the receiver/arguments. For example > 1 + 2 will never send the message #+ to 1. > but 1 + 'mariano' will do. > yes. > 2.2) methods that are NEVER sent, like #class and #== > yes > 2.3) methods that are ALWAYS sent, like #new, #next, #nextPut:, #size, etc. > > So...did I understand correclty this part? > I think so, yes. > > are there more cases where a message may not be really executed? You could see the block creation bytecode as a problematic case. It's not a message, so you can't trap it. But then when we are on that level, the same is with iVar access. Or temp access. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Issue 2911 in pharo: senders of ifNil:ifNotNil: only find literals but not senders
by pharo＠googlecode.com March 30, 2011

March 30, 2011

Comment #2 on issue 2911 by nicolas....(a)gmail.com: senders of ifNil:ifNotNil: only find literals but not senders http://code.google.com/p/pharo/issues/detail?id=2911 Related to issue2559

1 1

Re: [Pharo-project] Random crashes?
by AxiNat March 30, 2011

March 30, 2011

I was using the Cog VM shipped with the OneClick image, I'll update it right away. Thanks :) Bernat. 2011/3/30 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Mar 30, 2011, at 5:01 06PM, AxiNat wrote: > > > Hi Henrik and list, I was just asking how can I do the research by myself > to find out where the bug comes from. > > > > Anyway, here's my config: > > > > Debian GNU/Linux wheezy/sid (testing) - Kernel version 2.6.32-5-686 > > > > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz > > > > Smalltalk version 'Pharo1.2' > > Smalltalk vmVersion 'Croquet Closure Cog VM [CoInterpreter > VMMaker-oscog.35]' > > > > > Then I'd say there's probably a bug in code generation of the Cog JIT'er, > seeing as how it doesn't crash right away. > Use of SSE2 instructions would be my first bet, but it looks like your > processor supports those. > > First I'd try upgrading to a recent VM, .35 is really old, and there have > been plenty of crash fixes since then. > > If that doesn't help, try to identify which piece of code gets JIT'ed right > before the crash (using logs/a debug-built VM/gdb etc.), and try to create a > reproducible test-case of the code that generates invalid instructions when > JIT'ed. > > Then, submit testcase/details you just provided here to the Cog issue > tracker, cross your fingers, and hope for the best :) > > Cheers, > Henry >

4 9

[Pharo-project] Fwd: Random crashes?
by Henrik Johansen March 30, 2011

March 30, 2011

Meh, bitten by default reply receiver... Sending it here as well in case it's of interest for others. Begin forwarded message: > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: March 30, 2011 5:10:01 PM GMT+02:00 > To: AxiNat <tibabenfortlapalanca(a)gmail.com> > Subject: Re: [Pharo-project] Random crashes? > > > On Mar 30, 2011, at 5:01 06PM, AxiNat wrote: > >> Hi Henrik and list, I was just asking how can I do the research by myself to find out where the bug comes from. >> >> Anyway, here's my config: >> >> Debian GNU/Linux wheezy/sid (testing) - Kernel version 2.6.32-5-686 >> >> CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz >> >> Smalltalk version 'Pharo1.2' >> Smalltalk vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35]' >> >> > Then I'd say there's probably a bug in code generation of the Cog JIT'er, seeing as how it doesn't crash right away. > Use of SSE2 instructions would be my first bet, but it looks like your processor supports those. > > First I'd try upgrading to a recent VM, .35 is really old, and there have been plenty of crash fixes since then. > > If that doesn't help, try to identify which piece of code gets JIT'ed right before the crash (using logs/a debug-built VM/gdb etc.), and try to create a reproducible test-case of the code that generates invalid instructions when JIT'ed. > > Then, submit testcase/details you just provided here to the Cog issue tracker, cross your fingers, and hope for the best :) > > Cheers, > Henry

1 0

[Pharo-project] Random crashes?
by AxiNat March 30, 2011

March 30, 2011

Hi list, I was getting some random crashes in 1.1, so I switched to 1.2 some weeks ago. It's been kind of stable until just today, when it started randomly crashing again. At least the image isn't corrupted like it used to happen to me in 1.1, but I'm wasting a lot of time recovering lost changes. The terminal just outputs "illegal hardware instruction", how could I find out the bug's nature to fill in a bug report? Thanks! Bernat Romagosa.

2 2

[Pharo-project] XSD Encoding/Decoding
by Udo Schneider March 30, 2011

March 30, 2011

All, I'm a bit stuck on decoding/encoding data based on existing XSDs. I assumed this should be possible with SoapOpera ... but I don't really know where to start. Does anybody have a small example of encoding/decoding Smalltalk Objects based on exiting XSDs? Thanks, Udo

1 0

[Pharo-project] Issue 3767 in pharo: We should add References to Pool Variable
by pharo＠googlecode.com March 30, 2011

March 30, 2011

Status: Accepted Owner: stephane...(a)gmail.com New issue 3767 by stephane...(a)gmail.com: We should add References to Pool Variable http://code.google.com/p/pharo/issues/detail?id=3767 It is possible to identify the reference to a PoolVariable. would be good to have that in the browser

1 1

Re: [Pharo-project] Migration morph objects from 1.1 to 1.2
by Marcus Denker March 30, 2011

March 30, 2011

On Mar 29, 2011, at 10:30 PM, Denis Kudriashov wrote: > Thanks for reply. > > I should search mails first. > We should have added that fix to 1.2, not just 1.3.... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1