December 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Sensus is consortium member

by StÃ©phane Ducasse

Hi guys we want to thank Sensus the company of stefan eggermont to be a consortium member. The web site is coming. Stef

Dec. 11, 2012

Re: [Pharo-project] Pharo 2

by Marcus Denker

On Dec 11, 2012, at 9:54 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I was wondering if it really worths working with Pharo 2 yet, in terms of stability and new features. > I think soâ¦ there are some bugs left, but not many real showstoppers. > First question is the link in the website the link to the latest Pharo 2 image ? > yes. > Is Athens included in the Pharo 2 image ? > No. NativeBoost is, but Athens not. > How much production ready Pharo 2 image really is ? > To me it looks quite good, but of course only you can decide that as you might use other parts of the system then me. > Should I move to it or is it still a moving target ? > Not at all. We are in Beta, we just allow bug fixes. > What new Pharo 2 image offers ? We should make a listâ¦ Marcus

Dec. 11, 2012

Re: [Pharo-project] NativeBoost and Pharo Kernel

by Marcus Denker

On Dec 11, 2012, at 9:51 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I would like to ask: should NativeBoost be part of the Pharo Kernel? I would say right now, no. > Currently there are some minor issues like that AsmJit-Extension package takes ownership of Integer>>#&, False>>#asBit and so on. > Will NativeBoost be more closely integrated with the kernel in the near future? > In the far future, native boost will provide the basis to move more things out of the VM into the image. When this happens, yes, it has to be part of the kernel. But that is far away for now. > BTW, we need to integrate http://code.google.com/p/pharo/issues/detail?id=7062 before any update that will move methods between packages. > We should continue to regularly integrate fixesâ¦ it would help a lot if someone that is not me would sometimes look at submitted fixes. Marcus

Dec. 11, 2012

[Pharo-project] Pharo 2

by dimitris chloupis

I was wondering if it really worths working with Pharo 2 yet, in terms of stability and new features. First question is the link in the website the link to the latest Pharo 2 image ? Is Athens included in the Pharo 2 image ? How much production ready Pharo 2 image really is ? Should I move to it or is it still a moving target ? What new Pharo 2 image offers ?

Dec. 11, 2012

Re: [Pharo-project] Unable to run pharo on Ubuntu 12.10

by dimitris chloupis

Ok it seems it was just a corupted download, everything seems to work fine now. I have even tried the Nativeboost-Cog build that works too. Thanks everyone for their help and clarifications.

Dec. 11, 2012

[Pharo-project] NativeBoost and Pharo Kernel

by Pavel Krivanek

Hi, I would like to ask: should NativeBoost be part of the Pharo Kernel? Currently there are some minor issues like that AsmJit-Extension package takes ownership of Integer>>#&, False>>#asBit and so on. Will NativeBoost be more closely integrated with the kernel in the near future? BTW, we need to integrate http://code.google.com/p/pharo/issues/detail?id=7062 before any update that will move methods between packages. Cheers, -- Pavel

Dec. 11, 2012

[Pharo-project] About (backwards) Compatibility

by Fernando Olivero

Hi, i wanted to share an "old" quote which i find relevant to our community. Just replace FORTRAN's with loads of stuff we had in the bloated images in the past, most of them useful to get were we are right now. "FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility." Dijkstra, The Humble Programmer, 1972

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Marcus Denker

Hi, Yes, we should improve the debuggerâ¦ There are some nice things happening around the debugger -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. In the current Debugger, Model and View are completely mixed (and the implementation is kind of old style, that is, very low level and complex) Last week He and Ben did an experiment to get a second UI working (Spec). -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating if this can not replace the context step simulator based partsâ¦ -> For later, we would like to integrate the idea of object centric debugging (halt on next ivar change, halt on next messageâ¦) -> â¦ The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it. Marcus On Dec 9, 2012, at 11:07 PM, adrians <nmanole(a)gmail.com> wrote: > Hi, > > I'm a Smalltalk newbie and I would like to help fix some simpler issues. For > example, I've recently logged some issues surrounding smart character use. I > set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded > to debug. > > Now, I understand that for the old-timers stepping through a selector is > straightforward, no matter what help the debugger gives you. For myself, and > likely many other Smalltalk noobs who'd like to help, I need all the help I > can get. One such support is an accurate indication of where the PC is as > you step through a body of code. Currently, in the 2.0 one-click image > (build 20431), things seem quite broken wrt getting accurate visual feedback > of where you are. > > First, as you step over message sends, the highlighted selection is shown in > a totally incorrect spot. Sometimes, just a bit off from where you expect to > be, but sometimes quite a bit off, for example in a block that should not > even be entered. In the selector I mentioned above, the highlighted location > enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" > returns false. > > Second, the PC location highlight is removed when you click somewhere inside > the code. This should never turn off - it's as if you switch the lights off, > for people not familiar with some particular code. I know you can use the > "Where" button to re-establish the highlight, but other than the fact that > you shouldn't have to do this, the highlighted selection is sometimes shown > in the wrong place. > > Third, as you step through code, you would expect that the values of > variables as shown in the bottom right panel of the debugger are accurately > updated as state changes. I've seen cases, relatively frequent, where this > is not so. Current values are shown only after some further advancement > through code. > > There is an old issue tracking debugger selection, > http://code.google.com/p/pharo/issues/detail?id=709 > <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the > problem seems to have stalled. Additionally, I'm not sure that this > particular issue addresses the third point I made about stale variable > values being shown. > > Could I ask that making the debugger work be made a priority? Of course one > can muddle through some code even with visually broken indicators, but it > should not be so, IMO. The old timers can make the case that there are other > more pressing issues to be addressed, but IMO it makes sense to make the > actual tool used to fix problems as helpful as possible for everyone so that > even non-experts can be productive and lend a helping hand. > > > Cheers, > Adrian > > > > -- > View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 11, 2012

Re: [Pharo-project] NB squeaksource comits

by Igor Stasenko

On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > sorry for bothering you again with this issue but again somebody > (squeaksource ;)) removed me from the commiters of the NB project. > added again :) > Now I have two proposals, a very small one: removing the asm int3, and > decrementing the callback counter in > #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on > callback error case. > no, it should not decrement counter in error case, because you are not leaved from callback. you should always return from callback, otherwise its call will be held on stack. > Secondly, I have converged to an implementation of NBExternalEnum (using > SharedPool) which I think it is cool, and I wanted to share it with you. > Maybe you like it... maybe you don't ... ;) > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] Protecting against stack overflow ?

by Eliot Miranda

2012/12/9 Sven Van Caekenberghe <sven(a)stfx.eu> > Hi, > > Would it be possible to build some kind of protection against stack > overflow ? > note that there already is some mechanism. The low space mechanism is supposed to protect against stack overflow but with today's memories and the difficulty of testing it, this mechanism often a) takes way too long to kick in, and b) either leaves the system in a very sluggish state or simply fails to kick in and the system crashes with an out-of-memory error. Part of the problem is in designing a mechanism which is in keeping with the reflective nature of the system. What I mean is that we now have two different VMs, the Interpreter and the STack/Cog VMs. First one wants a check which is cheap. That means a check which isn't run on every send. In the interpreter a natural time to check for recursion would be on e.g. fullGC, checking for repetition in the current process's context chain. The the Stack/Cog VMs the natural time is on evacuating a stack page when the stack zone is full. But these are two different mechanisms, both of which are deep in the VM, neither of which can be conveniently intercepted from Smalltalk, unlike e.g. doesNotUnderstand:. Personally I like the idea of reviving the low space mechanism and maintaining it properly. For example, if the low space mechanism causes the low space semaphore to fire often, because the limit was set only a little way above the current memory size, and not, as it is now, a little below the absolute limit, then when it fires, the low space process could inspect the current process's stack (e.g. via accelerated via a primitive for performance) and see how deep it is, and possibly whether there is recursion (e.g. a bag of context methods would soon reveal high-frequency methods, and then those contexts could be inspected for repetition, but KISS says just have a per-process limit on the maximum depth of stack). > This is actually the most common situation for loop/cycle that either > results in an unusable image or a crash. > Interrupting with CMD-. is not always possible. > A possible solution could be to just limit the stack size and throw an > exception. > > For example, in LispWorks, it goes like this: > > CL-USER 5 > (defun foo () (cons (random 100) (foo))) > FOO > > CL-USER 6 > (foo) > > Stack overflow (stack size 48128). > 1 (continue) Extend stack by 50%. > 2 (abort) Return to level 0. > 3 Return to top loop level 0. > > Type :b for backtrace or :c <option number> to proceed. > Type :bug-form "<subject>" for a bug report template or :? for other > options. > > CL-USER 7 : 1 > :bq > > ERROR <- RUNTIME:BAD-ARGS-OR-STACK <- LENGTH <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- > FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- > CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION > > Obviously, this is possible, the question is, can it be done easily and > without paying an unbearable performance price ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > -- best, Eliot

Dec. 11, 2012