- Pharo-dev - lists.pharo.org

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

[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