- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About (backwards) Compatibility

by Sven Van Caekenberghe

On 14 Dec 2012, at 17:55, Chris Muller <asqueaker(a)gmail.com> wrote: > 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. Please, this is so silly: - the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ? BTW: it is a done deal. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by ClÃ©ment Bera

Several months ago I made a prototype of a small game in amber. (To play my prototype, download it, run index.html and click Multiplayer>beta fight. The source is here : https://github.com/clementbera/easnoth:. It uses Jquery.getJSON() so it might not work on some web browsers/computers) I asked several smalltalkers why there was no game in Smalltalk. Most of them answered me it was because Smalltalk is too slow to run video game. It may be because of the GC as Lawson English said. If you want to do a game that requires a lot of performance (for example realtime + 3d), you should care. But if you want to do a small game, as the games we can find on smartphone or on website like armor games it is enough. I don't think that running a Lua script through native Boost is a good idea. It will work, but will be slower than pure Smalltalk. But I'm not a pro :) 2012/12/14 Frank Shearar <frank.shearar(a)gmail.com> > On 14 December 2012 20:26, Lawson English <lenglish5(a)cox.net> wrote: > > On 12/13/12 1:58 AM, Igor Stasenko wrote: > >> > >> On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> > wrote: > >>> > >>> I was ready to disagree , but you do make a valid point. > >>> > >>> Also going down the pharo route you dont offer games only a better > >>> language > >>> but also a development enviroment and that is a double win. I am > suprised > >>> that pharo is not used heavily for games. > >>> > >>> And no I dont believe sandbox is the reason. Afterall python is very > >>> popular > >>> with games too and has no sandbox. > >> > >> indeed, its all about marketing and having 'killer app', and then you > >> wont notice how eagerly new > >> people will jump into bandwagon. > >> > >> > > > > until certain issues with garbage collection are fixed, there will be no > > playable realtime games on any of the OSS Smalltalks. > > Details please! Does the time taken to GC vary too wildly, for example? > > frank > > > L > > > > -- > > Squeak from the very start (introduction to Squeak and Pharo Smalltalk > for > > the (almost) complete and compleate beginner). > > > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > > > "Debugging is twice as hard as writing the code in the first place. > > Therefore, if you write the code as cleverly as possible, you are, by > > definition, not smart enough to debug it." - Brian Kernighan > > > > > >

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Frank Shearar

On 14 December 2012 20:26, Lawson English <lenglish5(a)cox.net> wrote: > On 12/13/12 1:58 AM, Igor Stasenko wrote: >> >> On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> >>> I was ready to disagree , but you do make a valid point. >>> >>> Also going down the pharo route you dont offer games only a better >>> language >>> but also a development enviroment and that is a double win. I am suprised >>> that pharo is not used heavily for games. >>> >>> And no I dont believe sandbox is the reason. Afterall python is very >>> popular >>> with games too and has no sandbox. >> >> indeed, its all about marketing and having 'killer app', and then you >> wont notice how eagerly new >> people will jump into bandwagon. >> >> > > until certain issues with garbage collection are fixed, there will be no > playable realtime games on any of the OSS Smalltalks. Details please! Does the time taken to GC vary too wildly, for example? frank > L > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for > the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it." - Brian Kernighan > >

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Lawson English

On 12/13/12 1:58 AM, Igor Stasenko wrote: > On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> I was ready to disagree , but you do make a valid point. >> >> Also going down the pharo route you dont offer games only a better language >> but also a development enviroment and that is a double win. I am suprised >> that pharo is not used heavily for games. >> >> And no I dont believe sandbox is the reason. Afterall python is very popular >> with games too and has no sandbox. > indeed, its all about marketing and having 'killer app', and then you > wont notice how eagerly new > people will jump into bandwagon. > > until certain issues with garbage collection are fixed, there will be no playable realtime games on any of the OSS Smalltalks. L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Sean P. DeNigris

Chris Muller-3 wrote > I don't know if its just romantic, starry-eyed mountain climbers or > intentional false-propaganda Or both! ;) Chris Muller-3 wrote > This example is bunk Well, you're partly right - the clean version is not due totally to FS. You'd be more right if human beings were rational beings. But we're not, we're driven by emotion. I /feel/ bad when I look at FD, because I find it ugly and confusing. Therefore, I would be reluctant to refactor that code and it probably would still be in the state it is. But I was excited to have well-factored, intuitive FS objects to work with, which boiled into me searching the system for ugly code to clean. That example was a quote from a previous post in my excitement after cleaning and making the system better. Beauty and simplicity reverberates out well beyond the initial objects... that's good enough for me. Sean -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659295.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2012

[Pharo-project] NB Types and C Types

by Jimmie Houchin

Hello, In my app using NB and have a few questions on types. In one function I have an size_t *arg for an argument. Is NBUInt64 proper for this argument? I also have a DATE which uses OLE Automation date format which is described as: IO2GRequestFactory.fillMarketDataSnapshotRequestTime """ An OLE Automation date is implemented as a floating-point number whose integral component is the number of days before or after midnight, 30 December 1899, and whose fractional component represents the time on that day divided by 24. """ Would NBUInt64 be best or is NBUInt32 a better fit? I haven't seen a method for this particular date epoch, but I can easily write the method to handle conversion. Thanks for any wisdom and guidance. Jimmie

Dec. 14, 2012

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