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

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

by Pavel Krivanek

On Fri, Dec 14, 2012 at 7:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 December 2012 19:33, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > > On Fri, Dec 14, 2012 at 7:17 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> > >> wrote: > >> > > >> > > >> > On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> > >> > wrote: > >> >> > >> >> 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 > :) > >> > > >> > > >> > You are right, when I add sources file next to NBCog, it works. Has > >> > anyone > >> > changed the scripts? > >> > > >> > >> yes, guys added this nice feature lately.. but forgot to make it fault > >> tolerant, i.e. > >> > >> downloadSources > >> > >> [ > >> ......... > >> > >> ] on: ??Exception?? do: [ .. ok we failed.. continue without ] > >> > >> because without it, image will fail to work once you don't have > >> network connection or simply cannot connect to urls.. for any other > >> reason. > > > > > > Yes, I know that function very well because it makes ugly dependency of > the > > kernel on Zinc ;-). But I was talking about scripts: > > http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh > > http://pharo.gforge.inria.fr/ci/ciNBCog.sh > > http://pharo.gforge.inria.fr/ci/ciPharo20.sh > > > > but script works fine. image starts .. and then downloads .source file > forever.. > at least this is what happen on my ubuntu machine > hmm, you are right, I looked at an older directory created this way some time ago and the sources file has slightly newer time of creation. I supposed that the file is dowloaded by bash. -- Pavel > > > -- Pavel > > > >> > -- Pavel > >> > > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Dec. 14, 2012

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

by Igor Stasenko

On 14 December 2012 19:33, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > On Fri, Dec 14, 2012 at 7:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > >> > On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> 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 :) >> > >> > >> > You are right, when I add sources file next to NBCog, it works. Has >> > anyone >> > changed the scripts? >> > >> >> yes, guys added this nice feature lately.. but forgot to make it fault >> tolerant, i.e. >> >> downloadSources >> >> [ >> ......... >> >> ] on: ??Exception?? do: [ .. ok we failed.. continue without ] >> >> because without it, image will fail to work once you don't have >> network connection or simply cannot connect to urls.. for any other >> reason. > > > Yes, I know that function very well because it makes ugly dependency of the > kernel on Zinc ;-). But I was talking about scripts: > http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh > http://pharo.gforge.inria.fr/ci/ciNBCog.sh > http://pharo.gforge.inria.fr/ci/ciPharo20.sh > but script works fine. image starts .. and then downloads .source file forever.. at least this is what happen on my ubuntu machine > -- Pavel > >> > -- Pavel >> > >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Dec. 14, 2012

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

by Pavel Krivanek

On Fri, Dec 14, 2012 at 7:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > > > On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> 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 :) > > > > > > You are right, when I add sources file next to NBCog, it works. Has > anyone > > changed the scripts? > > > > yes, guys added this nice feature lately.. but forgot to make it fault > tolerant, i.e. > > downloadSources > > [ > ......... > > ] on: ??Exception?? do: [ .. ok we failed.. continue without ] > > because without it, image will fail to work once you don't have > network connection or simply cannot connect to urls.. for any other reason. Yes, I know that function very well because it makes ugly dependency of the kernel on Zinc ;-). But I was talking about scripts: http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh http://pharo.gforge.inria.fr/ci/ciNBCog.sh http://pharo.gforge.inria.fr/ci/ciPharo20.sh -- Pavel > -- Pavel > > > > -- > Best regards, > Igor Stasenko. > >

Dec. 14, 2012

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

by Igor Stasenko

http://code.google.com/p/pharo/issues/detail?id=7129 Sven, can you please give an advice, how to properly handle Zinc errors, when requested url is not available for one or another reason.. and especially timeouts (at this point a timeout should be == failure), we don't want users to see black screen for more than 2 seconds during startup. -- Best regards, Igor Stasenko.

Dec. 14, 2012

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

by Igor Stasenko

On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 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 :) > > > You are right, when I add sources file next to NBCog, it works. Has anyone > changed the scripts? > yes, guys added this nice feature lately.. but forgot to make it fault tolerant, i.e. downloadSources [ ......... ] on: ??Exception?? do: [ .. ok we failed.. continue without ] because without it, image will fail to work once you don't have network connection or simply cannot connect to urls.. for any other reason. > -- Pavel > -- Best regards, Igor Stasenko.

Dec. 14, 2012

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

by Nicolas Cellier

SqNumberParser is for Smalltalk syntax, so it must not be localized, but ExtendedNumberParser could eventually be. I would suggest creating a LocalizedNumberParser. Otherwise, I have http://ss3.gemstone.com/ss/NumberPrinter to print decimal float and fractions with some support for variations like alternate fraction separator. Nicolas 2012/12/14 Dario Trussardi <dario.trussardi(a)tiscali.it>: > > >> 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 Locale decimalPoint is a method port from Gemstone for compatibility : > > decimalPoint > " by DTR for compatibility with OODB Locale" > > ^self current primDecimalSymbol > > The other considerations don't change. > > > Dario > >> 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 Pavel Krivanek

On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 :) > You are right, when I add sources file next to NBCog, it works. Has anyone changed the scripts? -- Pavel > > > -- > Best regards, > Igor Stasenko. > >

Dec. 14, 2012

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

by Pavel Krivanek

And are we allowed to remove features? ;-) On the other hand, we may look at it as fix of an umimplemented call. But we can let it there because I doubt we will be able to remove all unimplemented calls in 2.0 - even in the Pharo Kernel. -- Pavel On Fri, Dec 14, 2012 at 1:47 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > 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] 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 Locale decimalPoint is a method port from Gemstone for compatibility : decimalPoint " by DTR for compatibility with OODB Locale" ^self current primDecimalSymbol The other considerations don't change. Dario > 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] About (backwards) Compatibility

by Chris Muller

I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk. Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is: "FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime. "FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime. Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!) On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Chris Muller-4 wrote >> While someone in the Pharo >> community said FileSystem over FileDirectory is "huge", I see it as an >> incremental API change > > Can you still say that after reading > http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! > > FileSystem has hugely decremented the number of times I've wanted to throw > my computer at a wall ;) FileDirectory occurred to me like graffiti painted > on a great work of art. > > Multiply the above by every dark corner of the system and you have the > barrier to the next stage of evolution. For myself, every time I've embarked > on a bold new idea for our IDE, after getting bogged down in a mess of > objects - like FileDirectory et al, or Paragraph and friends, or Morphic > layout objects, and on and on - I reached a point where I was not willing to > put in the tremendous effort required to understand the system (if even > possible). And because few of the design decisions are documented, I didn't > know how to clean things without breaking them. So, I gave up and just went > back to the standard tools. > > I hate to keep repeating myself, but the Pharo manifesto is very clear, and > makes these types of arguments moot: > - Better for the better > - Beauty to learn from > - Not backward compatible > - Clean, lean and fast > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 14, 2012