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

[Pharo-project] Favorite New Features

by Sean P. DeNigris

Hey guys, what are your favorite features added in 2.0? Please answer at http://code.google.com/p/pharo/wiki/ActionsInPharo20 There are so many improvements, I've definitely lost track. I remember there were some really useful shortcuts cami or ben showed me, something like cmd-click to browse class... Cheers, Sean -- View this message in context: http://forum.world.st/Favorite-New-Features-tp4659272.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2012

[Pharo-project] Kernel-Numbers don't reference Locale decimalPoint

by Dario Trussardi

Ciao, i'm working for manage some write - read data ( MANumberDescription / MAScaledDecimalDescription / SIXX interchange data ) about Number and is subclass. I see some codes into Kernel-Numbers and i found it don't reference the Locale decimalPoint. The codes directly define the $. when reference the decimal. Now if i have setup the Locale decimalPoint to $, the SIXX write data with $. After if i read this sixx data into another environment ( for example Gemstone ) where i setup Locale decimalPoint to $, the system can't generate right Numbers. Another problem is relative to the Number readFrom: stringOrStream "Answer a decimal number as described on stringOrStream. The number may not include a leading radix specification, as in 16rFADE, nor an exponent like 1.0e-3 It might have a scale specification at end or not like 10.3s2 If not, number of digits after decimal point will be used as scale" ^(SqNumberParser on: stringOrStream) next........... because also the SqNumberParser don't reference the Locale decimalPoint. In this case if in my application i need to use the $, as decimalPoint ( and i use it in the Seaside TextInput ) follow stringOrStream is based on $, ( for example '123,89' ) as result SqNumberParser can't generate right numbers. Before begin to do some change i'm interested to know some other think about this problematic and if someone working around it. Thanks for any consideration, Dario

Dec. 14, 2012

Re: [Pharo-project] NBCog broken on 64bit Linux?

by Igor Stasenko

i killled the VM with SIGUSR signal and here the stack: Process 0x77ccf2cc priority 40 0xbff5517c I [] in Delay>wait 2035889428: a(n) Delay 0xbff551a4 I BlockClosure>ifCurtailed: 2035890000: a(n) BlockClosure 0xbff551c8 I Delay>wait 2035889428: a(n) Delay 0xbff551e8 I TimeStamp class(DateAndTime class)>waitForOffsets 2007868504: a(n) TimeStamp class 0xbff55210 I TimeStamp class(DateAndTime class)>milliSecondsSinceMidnight 2007868504: a(n) TimeStamp class 0xbff55238 I TimeStamp class(DateAndTime class)>now 2007868504: a(n) TimeStamp class 0xbff55260 I TimeStamp class>current 2007868504: a(n) TimeStamp class 0xbff55280 I TimeStamp class>now 2007868504: a(n) TimeStamp class 0xbff552a0 I ZnClient>handleResponse 2035558752: a(n) ZnClient 0xbff552c0 I ZnClient>executeWithRedirectsRemaining: 2035558752: a(n) ZnClient 0xbff552e4 I [] in ZnClient>executeWithRetriesRemaining: 2035558752: a(n) ZnClient 0xbff55300 M BlockClosure>on:do: 2035590416: a(n) BlockClosure 0xbff55328 I ZnClient>executeWithRetriesRemaining: 2035558752: a(n) ZnClient 0xbff55344 M [] in ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff55360 M BlockClosure>on:do: 2035590092: a(n) BlockClosure 0xbff55388 I [] in ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff553ac I [] in ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient 0xbff553d8 I [] in ZnConnectionTimeout(DynamicVariable)>value:during: 2007631496: a(n) ZnConnectionTimeout 0xbff553f8 M BlockClosure>ensure: 2035589948: a(n) BlockClosure 0xbff55424 I ZnConnectionTimeout(DynamicVariable)>value:during: 2007631496: a(n) ZnConnectionTimeout 0xbff5544c I ZnConnectionTimeout class(DynamicVariable class)>value:during: 2007997132: a(n) ZnConnectionTimeout class 0xbff55474 I ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient 0xbff55498 I ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff554bc I [] in ZnClient>execute 2035558752: a(n) ZnClient 0xbff554e0 I [] in ZnClient>withProgressDo: 2035558752: a(n) ZnClient 0xbff5550c I [] in ZnSignalProgress(DynamicVariable)>value:during: 2009919884: a(n) ZnSignalProgress 0xbff5552c M BlockClosure>ensure: 2035589476: a(n) BlockClosure 0xbff55558 I ZnSignalProgress(DynamicVariable)>value:during: 2009919884: a(n) ZnSignalProgress 0xbff55580 I ZnSignalProgress class(DynamicVariable class)>value:during: 2009919012: a(n) ZnSignalProgress class 0xbff555a8 I ZnClient>withProgressDo: 2035558752: a(n) ZnClient 0xbff555d4 I ZnClient>execute 2035558752: a(n) ZnClient 0xbff555f4 I ZnClient>get 2035558752: a(n) ZnClient 0xbff55614 I ZnClient>downloadTo: 2035558752: a(n) ZnClient 0xbff55640 I SmalltalkImage>downloadSources 2020677412: a(n) SmalltalkImage 0xbff55670 I SmalltalkImage>checkAndOpenSourcesAndChanges 2020677412: a(n) SmalltalkImage 0xbff55690 I SmalltalkImage>openSourceFiles 2020677412: a(n) SmalltalkImage 0xbff556a8 M SmalltalkImage class>startUp: 2020650272: a(n) SmalltalkImage class 0xbff556d0 M [] in SmalltalkImage>send:toClassesNamedIn:with: 2020677412: a(n) SmalltalkImage 0xbff556ec M BlockClosure>on:do: 2035540616: a(n) BlockClosure 0xbff5570c M SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 2020677412: a(n) SmalltalkImage so, it looks that we should not blame VM for 'black screen of death', but a startup code which stuck forever trying to download .sources file :) -- Best regards, Igor Stasenko.

Dec. 14, 2012

Re: [Pharo-project] NBCog broken on 64bit Linux?

by Igor Stasenko

On 14 December 2012 12:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > but the build is broken. > Unless you forced the load (two times) for build, you are not using my merge yet :) > ah.. ok then this discrepancy introduced even before > On Dec 14, 2012, at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 14 December 2012 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> If I download the latest VM and image the same way as our CI jobs on Linux: >>> wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash >>> then the VM is broken (it opens only black or white widnow). The image works >>> well with different VM version but with the VM downloaded by this scipt not. >>> It breaks some CI jobs and when I tried to find why the main Pharo 2.0 job >>> is working and others not when they use the same script, I found out that >>> they had build limited to "linux64". My local linux system is 64bit too. >>> >>> So I tried to restict "Pharo Kernel 2.0 support" job to "linux" but it look >>> broken even in this configuraton. So please can you check the VM on a 32-bit >>> system? >>> >> >> same story here.. >> it opens blank black window and period. Looks like a merge done by >> Esteban didn't vent well :( >> >> sig@sig-VirtualBox:~/vm$ uname -a >> Linux sig-VirtualBox 2.6.38-10-generic #46-Ubuntu >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Dec. 14, 2012

[Pharo-project] Thanks BetaNine and Mads for their Pharo consortium participation

by StÃ©phane Ducasse

Hi guys I want to thank BetaNine and Mad-Environment for their support to the Pharo Consortium Thanks for your trust. Stef

Dec. 14, 2012

Re: [Pharo-project] who is "dfgs"?

by Camillo Bruni

I know I will use it (though I am not allowed to add more features in 2.0 ;)) so it will be 3.0. Anyways I will add a fully-fledged command-line REPL. so it's up to you, I can add it again anyway On 2012-12-14, at 05:07, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > So what about to remove VTermInputDriver from the image? And add it in > future with working handler. > > -- Pavel > > On Thu, Dec 13, 2012 at 5:24 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> haha, so these are commits from the pre-full-name aera. >> Anyway, dfgs was a student in bern ;), but since I put the code in the >> system I should be the owner ;). >> >> VTerm*Driver abstract over the terminal, and yes they are crucial for any >> decent terminal support. >> - provide colors for terminal >> - provide cursor navigation >> - provide terminal capability access >> >> due to lack of NativeBoost in the main image, >> so far I could not use tcap, but that will change. >> >> So far I did not port the input handler (but there is a fully fledged >> smalltalk-based readline implementation ready). >> Once that is in the image there should be no more undefined calls. >> >> And using #perform: is a very bad habit in my opinion. >> It breaks all tools, since you make everything implicit (and quite slow as >> well).. >> >> On 2012-12-11, at 09:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> ... and please, please, please, use real names, not initials when >> committing packages! >>> >>> Esteban >>> >>> On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >>> >>>> Hi, >>>> >>>> I would like to ask who has the initials "dfgs". And I have a question >> for him/her. The VTermInputDriver initialization methods generate a lot of >> unimplemented calls because they expect a handler object with protocol that >> is not defined in the image. Do we need the VTerm classes at all? Can you >> provide an abstract handler class? Or what about to switch this calls to >> perform:/perform:with: form. >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >> >> >>

Dec. 14, 2012

Re: [Pharo-project] How to load Phoseydon and Neptuno?

by StÃ©phane Ducasse

meta layer on top of openBDX and magritte Stef On Dec 14, 2012, at 7:47 AM, Alexandre Bergel wrote: > What are Phoseydon and Neptuno? New kind of browsers? > > Alexandre > > > On Dec 13, 2012, at 10:49 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> Hi! >> >> which Pharo version are you using? I was able to download Phoseydon in Pharo 1.4 by doing >> >> Gofer it >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfDBXTools'; >> load. >> >> (((Smalltalk at: #ConfigurationOfDBXTools) >> perform: #project) >> perform: #version: with: #stable) >> load: 'Phoseydon' >> >> as it is in the webpage... >> What problem did you find? >> >> BTW, I would move this thread to dbxtalk(a)googlegroups.com or the pharo-users mailing lists. >> >> Cheers, >> Guille >> >> On Wed, Dec 12, 2012 at 11:07 PM, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: >> Hi all, is there a working snippet to load these two? I've tried combinations >> from previous threads without success so far. >> Thanks, ...Stan >> >> >> >> -- >> View this message in context: http://forum.world.st/How-to-load-Phoseydon-and-Neptuno-tp4659102.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 14, 2012

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

by StÃ©phane Ducasse

Hi mike last week andrei sat with ben and they got a first sketch of a debugger using spec and the model extracted from the debugger. Then just after jorge visited us and ported/fixed Bifrost in 1.4 and 2.0 so we will also have an object-centric debugger. Stef On Dec 14, 2012, at 12:48 AM, Michael Roberts wrote: > Indeed we spent some time in Edinburgh looking at it :-) that was too long ago :-( > > The problem i see with the original debugger inherited from Squeak, in the Pharo context, is that it is very sensitive to a lot of the core code in the image. What this means is that the accelerated changes in Pharo code base had unintended side effects on original debugger machinery as it diverged from its ancestry. It goes all the way back to pushing Eliot's closure implementation in 1.0 which we were desperate and excited for. > > Since we relied on taking core compiler/closure/debugger code from Squeak it became more and > more important to track the difference between squeak and Pharo. Anyone who has tried looking at the diffs will know how hard that is. I forget which class it was but we found this obscure bug in one of the collection classes IIRC that threw one tiny but annoying aspect of debugger highlighting off. I only found that by single stepping both images through known code snippets with this debugger 'oscilloscope' I had hacked up for the purpose. What that experience showed was it was really involved how the instruction machinery hangs together. As squeak trunk is where most fixes get pushed in this area it requires huge resources and diligence to track every change to see if Pharo needs it. For ages Stef would post every interesting looking trunk change to the pharo bug tracker but there were not many folks looking at them all. And also it is not nice work. We didn't have the tools or modularity to cherry pick changes in this area. > > So the new debugger model in Glamorous showed an interesting direction to go in and this comment from Marcus is also interesting on seemingly building a new debugger architecture which we have discussed before. I was trying to do was to figure out a way you could regression test the debugger by recording and replaying examples of it's operation and checking each release it hadn't been broken unexpectedly. I think there is still mileage in that area if it has not been done already. > > Also, historically, I am not convinced it was ever properly working in the sapphire build or even in 3.9. The bugs and effects were so subtle that you just got used to working around them. I.e. I have 20 mins to do some coding do I add a bit more to my cool seaside app or do I struggle with fixing the debugger? Last I looked at squeak trunk it was looking pretty good. But the code base is hard to track. > > What I was last thinking about in this area was trying to live 'trace' in some way all the code required by the debugger into a filed out and renamed set of classes like :SqDebugger SqArray SqCompiler SqInstructionStream and so on and then load them into Pharo. The idea being you would have an identical implementation that you would use to operate on all the Pharo code but entirely independent from it and maintained in squeak trunk. It is an unrealistic idea but the example i was thinking about from the electronic world is using one oscilloscope to test or observe the internals of another. You could do that image to image over the network of course but I am not sure if you just vary the complexity in a different direction. > > Anyway just my 2p, I care a lot I about the tooling and look forward to seeing what comes out! > > Cheers, > Mike > > (a bit absent, but still enjoying the progress) > > On 13 Dec 2012, at 09:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Now adrian I imagine that you saw that people worked on this bug and this is a rather complex one. >>> So I would suggest to you to avoid to draw conclusions too fast. >>> >> yes, if i remember, we tried to approach it at least once.. >> but unfortunately it requires a lot deeper knowledge about bytecode >> and (de)optimizations to fix highlight. >> >>> Stef >>> >>> On Dec 12, 2012, at 11:28 PM, adrians wrote: >>> >>>> >>>> Well, it just seems that I'm whining here instead of contributing, but if >>>> the debugger is indeed a very (if not the most) useful tool which is used in >>>> pretty much every bit of fix-up work, fixing it if it is broken would have >>>> to come before all else, no? Otherwise, any work that needs to be done until >>>> it is looked at is just compounded. >>>> >>>> Maybe it would make sense to correct (in the current code) to a small degree >>>> just one of the things that is currently broken. No frills, but just getting >>>> a more accurate indication of where the PC is - at least have it on the >>>> correct line of code if it can't be pinpointed more accurately without too >>>> much hassle. I'm curious what derails the location highlighting as half of >>>> the time it is close, if not correct. Is it blocks that give it a hard time? >>>> It wouldn't be too bad if other things were going to take a while if you >>>> could at least keep track of where you were. >>>> >>>> If the idea is to wait until a whole big refactoring can be done on this, I >>>> fear a fully debugger might be another year away. >>>> >>>> -- 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. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Dec. 14, 2012

Re: [Pharo-project] NBCog broken on 64bit Linux?

by Esteban Lorenzano

but the build is broken. Unless you forced the load (two times) for build, you are not using my merge yet :) On Dec 14, 2012, at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 December 2012 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> If I download the latest VM and image the same way as our CI jobs on Linux: >> wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash >> then the VM is broken (it opens only black or white widnow). The image works >> well with different VM version but with the VM downloaded by this scipt not. >> It breaks some CI jobs and when I tried to find why the main Pharo 2.0 job >> is working and others not when they use the same script, I found out that >> they had build limited to "linux64". My local linux system is 64bit too. >> >> So I tried to restict "Pharo Kernel 2.0 support" job to "linux" but it look >> broken even in this configuraton. So please can you check the VM on a 32-bit >> system? >> > > same story here.. > it opens blank black window and period. Looks like a merge done by > Esteban didn't vent well :( > > sig@sig-VirtualBox:~/vm$ uname -a > Linux sig-VirtualBox 2.6.38-10-generic #46-Ubuntu > > -- > Best regards, > Igor Stasenko. >

Dec. 14, 2012

Re: [Pharo-project] NBCog broken on 64bit Linux?

by Igor Stasenko

On 14 December 2012 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > If I download the latest VM and image the same way as our CI jobs on Linux: > wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash > then the VM is broken (it opens only black or white widnow). The image works > well with different VM version but with the VM downloaded by this scipt not. > It breaks some CI jobs and when I tried to find why the main Pharo 2.0 job > is working and others not when they use the same script, I found out that > they had build limited to "linux64". My local linux system is 64bit too. > > So I tried to restict "Pharo Kernel 2.0 support" job to "linux" but it look > broken even in this configuraton. So please can you check the VM on a 32-bit > system? > same story here.. it opens blank black window and period. Looks like a merge done by Esteban didn't vent well :( sig@sig-VirtualBox:~/vm$ uname -a Linux sig-VirtualBox 2.6.38-10-generic #46-Ubuntu -- Best regards, Igor Stasenko.

Dec. 14, 2012