February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] iOS VM - More Info 2

by phil＠highoctane.be

Guess the CMake that is generated is plain wrong. /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX6.1.sdk ... WRONG I guess... set(CMAKE_C_COMPILER /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc) set(CMAKE_CXX_COMPILER /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++) set(CMAKE_OSX_ARCHITECTURES armv7) set(CMAKE_OSX_SYSROOT /) # This is automatically generated file using StackIPhoneConfig on 27 February 2013 4:17:00.984 pm cmake_minimum_required(VERSION 2.6.2) include(CMakeDetermineSystem) project("iStackVM") set(CMAKE_OSX_DEPLOYMENT_TARGET 10.5) set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX6.1.sdk) include(directories.cmake) set(externalModulesDir "${outputDir}/iStackVM.app/Contents/MacOS/Plugins") message("${CMAKE_MODULE_PATH}") set(CMAKE_CONFIGURATION_TYPES Release) include_directories(${buildDir}/) include_directories(${platformsDir}/iOS/vm/iPhone) include_directories(${crossDir}/vm ${srcVMDir} ${targetPlatform}/vm ${buildDir}) include_directories(${srcDir}/vm) include_directories(${platformsDir}/iOS/vm/iPhone) include_directories(${platformsDir}/iOS/vm/iPhone/Classes) include_directories(${platformsDir}/iOS/vm/OSX) include_directories(${platformsDir}/unix/vm) include_directories(${platformsDir}/iOS/vm/Common/Classes) include_directories(${platformsDir}/iOS/plugins/SoundPlugin) include_directories(${platformsDir}/iOS/vm/OSX/plugins/SoundP

Feb. 27, 2013

[Pharo-project] iOS VM : more info

by phil＠highoctane.be

Got a look inside the UIDevice.h and there is typedef NS_ENUM(NSInteger, UIUserInterfaceIdiom) { #if __IPHONE_3_2 <= __IPHONE_OS_VERSION_MAX_ALLOWED UIUserInterfaceIdiomPhone, // iPhone and iPod touch style UI UIUserInterfaceIdiomPad, // iPad style UI #endif } Do we have any special defined thing related to that? Phil

Feb. 27, 2013

Re: [Pharo-project] Crash seemingly related to becomeForward: on linux

by Igor Stasenko

On 27 February 2013 13:57, Camillo Bruni <camillobruni(a)gmail.com> wrote: > To rule out side-effects, I suggest deactivating ALL NB tests and see if we > still have such unpredictable behavior. Since last november we basically didn't > manage to get the system back into stable mode. > why not. won't hurt to try. > And there are currently three things (maybe unrelated) that worry me a lot: > - delay processes > - unloading of plugins at some point > - unstable "becomeForward:" > > we should really come up with a battle plan... which brings me to the next question > > when are you on holidays igor? > 27.02. - 06.03 (so yes, today is my official holiday, yet i am in the office :) > > On 2013-02-27, at 13:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> yes, i seen that dump, Marcus. >> >> It is of course easy to blame become, but it can be worse: >> something corrupts heap, and the corruption stays dormant, until >> become operation, because >> it scans heap and then stumbling upon invalid pointer, which leads to crash. >> >> On 27 February 2013 13:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> I will setup a second Pharo-2.0-Test running on the StackVM so we can compare them bit. >>> >>> >>> On 2013-02-27, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> Hmmâ¦ >>>> >>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/label=linux/187/consoleFull >>>> >>>> >>>> Smalltalk stack dump: >>>> 0xbfb19878 M WideString(Object)>becomeForward: 0x795d44e4: a(n) WideString >>>> 0xbfb19894 M WideString>? 0x795d44e4: a(n) WideString >>>> 0xbfb198b4 M WriteStream>nextPut: 0x795c5f8c: a(n) WriteStream >>>> 0xbfb198dc M [] in ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >>>> 0xbfb107d8 M String class(SequenceableCollection class)>new:streamContents: 0x777cde88: a(n) String class >>>> 0xbfb10808 M ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >>>> 0xbfb10824 M ZnStringEntity>readFrom: 0x795c1500: a(n) ZnStringEntity >>>> 0xbfb10844 M ZnEntity class>readFrom:usingType:andLength: 0x777e8c30: a(n) ZnEntity class >>>> 0xbfb10870 M ZnEntityReader>readFrom:usingType:andLength: 0x795bb9d0: a(n) ZnEntityReader >>>> 0xbfb108a4 M ZnEntityReader>readEntityFromStream 0x795bb9d0: a(n) ZnEntityReader >>>> 0xbfb108c0 M ZnEntityReader>readEntity 0x795bb9d0: a(n) ZnEntityReader >>>> 0xbfb108dc M ZnResponse(ZnMessage)>readEntityFrom: 0x795b3240: a(n) ZnResponse >>>> 0xbfafd750 M ZnResponse>readEntityFrom: 0x795b3240: a(n) ZnResponse >>>> 0xbfafd76c M ZnResponse(ZnMessage)>readFrom: 0x795b3240: a(n) ZnResponse >>>> 0xbfafd78c M ZnResponse class(ZnMessage class)>readFrom: 0x777e9004: a(n) ZnResponse class >>>> 0xbfafd7a8 M ZnClient>executeRequestResponse 0x79580ff0: a(n) ZnClient >>>> 0xbfafd7c0 M [] in ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >>>> 0xbfafd7e0 M BlockClosure>ensure: 0x795b1fec: a(n) BlockClosure >>>> 0xbfafd7fc M ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >>>> 0xbfafd814 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >>>> 0xbfafd830 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >>>> 0xbfafd84c M [] in ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >>>> 0xbfafd868 M BlockClosure>on:do: 0x79583bd8: a(n) BlockClosure >>>> 0xbfafd888 M ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >>>> 0xbfafd8a4 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>>> 0xbfafd8c0 M BlockClosure>on:do: 0x795839cc: a(n) BlockClosure >>>> 0xbfafd8e0 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a718 M [] in ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a73c M [] in ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >>>> 0xbfb1a75c M BlockClosure>ensure: 0x7958393c: a(n) BlockClosure >>>> 0xbfb1a780 M ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >>>> 0xbfb1a7a0 M ZnConnectionTimeout class(DynamicVariable class)>value:during: 0x777ea304: a(n) ZnConnectionTimeout class >>>> 0xbfb1a7c0 M ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a7dc M ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a7f8 M [] in ZnClient>execute 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a814 M [] in ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a838 M [] in ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >>>> 0xbfb1a858 M BlockClosure>ensure: 0x79583764: a(n) BlockClosure >>>> 0xbfb1a87c M ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >>>> 0xbfb1a89c M ZnSignalProgress class(DynamicVariable class)>value:during: 0x7799005c: a(n) ZnSignalProgress class >>>> 0xbfb1a8bc M ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >>>> 0xbfb1a8e0 M ZnClient>execute 0x79580ff0: a(n) ZnClient >>>> 0xbfaad7a8 M ZnClient>get 0x79580ff0: a(n) ZnClient >>>> 0xbfaad7d0 M ZnClientTests>testRedirect 0x794a76bc: a(n) ZnClientTests >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Feb. 27, 2013

[Pharo-project] iOS VM build... oops, not working

by phil＠highoctane.be

Hello, Looks like there is no Xcode project anymore in the last version of the build. Right, it looks like the same as the OSX one. First, I had to remove the FT2Plugin since it failed badly. Also there is no support for the PharoVMBuilder in there. And no iPhone.image anymore. Which has been renamed iOS.image and required fetching from the CI. (Also, having the bad URL since the move). Anyway, got that done. Now, I am facing this (and I removed all of Xcode 4.2, cleaned the box, reinstalled Xcode 4.3 And also set SDK to the right one and the platform to armv7 before generating the sources. Now, I get: Scanning dependencies of target IOSPlugin [ 0%] Building C object IOSPlugin/CMakeFiles/IOSPlugin.dir/Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c.o In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIApplication.h:13, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIViewController.h:10, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIActivityViewController.h:9, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:14, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/build/iStackVM_Prefix.pch:7, from <command-line>:0: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:33: error: expected identifier before â}â token /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c: In function âprimitiveShowKeyboardâ: /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c:124: warning: implicit declaration of function âsqShowKeyboardâ make[2]: *** [IOSPlugin/CMakeFiles/IOSPlugin.dir/Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c.o] Error 1 make[1]: *** [IOSPlugin/CMakeFiles/IOSPlugin.dir/all] Error 2 make: *** [all] Error 2 [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/build philippeback$] gvim /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/build/iStackVM_Prefix.pch [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/build philippeback$] sudo make [ 0%] Building C object IOSPlugin/CMakeFiles/IOSPlugin.dir/Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c.o In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIApplication.h:13, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIViewController.h:10, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIActivityViewController.h:9, from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:14, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/build/iStackVM_Prefix.pch:3, from <command-line>:0: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:33: error: expected identifier before â}â token /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c: In function âprimitiveShowKeyboardâ: /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c:124: warning: implicit declaration of function âsqShowKeyboardâ make[2]: *** [IOSPlugin/CMakeFiles/IOSPlugin.dir/Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/src/plugins/IOSPlugin/IOSPlugin.c.o] Error 1 make[1]: *** [IOSPlugin/CMakeFiles/IOSPlugin.dir/all] Error 2 make: *** [all] Error 2 For some reason the pch contains ^M characters all over. Removed them but nothing better came out. Looks like I am in for another round of "try to get this thing to compile...." Phil

Feb. 27, 2013

Re: [Pharo-project] Crash seemingly related to becomeForward: on linux

by Camillo Bruni

To rule out side-effects, I suggest deactivating ALL NB tests and see if we still have such unpredictable behavior. Since last november we basically didn't manage to get the system back into stable mode. And there are currently three things (maybe unrelated) that worry me a lot: - delay processes - unloading of plugins at some point - unstable "becomeForward:" we should really come up with a battle plan... which brings me to the next question when are you on holidays igor? On 2013-02-27, at 13:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > yes, i seen that dump, Marcus. > > It is of course easy to blame become, but it can be worse: > something corrupts heap, and the corruption stays dormant, until > become operation, because > it scans heap and then stumbling upon invalid pointer, which leads to crash. > > On 27 February 2013 13:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I will setup a second Pharo-2.0-Test running on the StackVM so we can compare them bit. >> >> >> On 2013-02-27, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Hmmâ¦ >>> >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/label=linux/187/consoleFull >>> >>> >>> Smalltalk stack dump: >>> 0xbfb19878 M WideString(Object)>becomeForward: 0x795d44e4: a(n) WideString >>> 0xbfb19894 M WideString>? 0x795d44e4: a(n) WideString >>> 0xbfb198b4 M WriteStream>nextPut: 0x795c5f8c: a(n) WriteStream >>> 0xbfb198dc M [] in ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >>> 0xbfb107d8 M String class(SequenceableCollection class)>new:streamContents: 0x777cde88: a(n) String class >>> 0xbfb10808 M ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >>> 0xbfb10824 M ZnStringEntity>readFrom: 0x795c1500: a(n) ZnStringEntity >>> 0xbfb10844 M ZnEntity class>readFrom:usingType:andLength: 0x777e8c30: a(n) ZnEntity class >>> 0xbfb10870 M ZnEntityReader>readFrom:usingType:andLength: 0x795bb9d0: a(n) ZnEntityReader >>> 0xbfb108a4 M ZnEntityReader>readEntityFromStream 0x795bb9d0: a(n) ZnEntityReader >>> 0xbfb108c0 M ZnEntityReader>readEntity 0x795bb9d0: a(n) ZnEntityReader >>> 0xbfb108dc M ZnResponse(ZnMessage)>readEntityFrom: 0x795b3240: a(n) ZnResponse >>> 0xbfafd750 M ZnResponse>readEntityFrom: 0x795b3240: a(n) ZnResponse >>> 0xbfafd76c M ZnResponse(ZnMessage)>readFrom: 0x795b3240: a(n) ZnResponse >>> 0xbfafd78c M ZnResponse class(ZnMessage class)>readFrom: 0x777e9004: a(n) ZnResponse class >>> 0xbfafd7a8 M ZnClient>executeRequestResponse 0x79580ff0: a(n) ZnClient >>> 0xbfafd7c0 M [] in ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >>> 0xbfafd7e0 M BlockClosure>ensure: 0x795b1fec: a(n) BlockClosure >>> 0xbfafd7fc M ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >>> 0xbfafd814 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >>> 0xbfafd830 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >>> 0xbfafd84c M [] in ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >>> 0xbfafd868 M BlockClosure>on:do: 0x79583bd8: a(n) BlockClosure >>> 0xbfafd888 M ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >>> 0xbfafd8a4 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>> 0xbfafd8c0 M BlockClosure>on:do: 0x795839cc: a(n) BlockClosure >>> 0xbfafd8e0 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>> 0xbfb1a718 M [] in ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >>> 0xbfb1a73c M [] in ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >>> 0xbfb1a75c M BlockClosure>ensure: 0x7958393c: a(n) BlockClosure >>> 0xbfb1a780 M ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >>> 0xbfb1a7a0 M ZnConnectionTimeout class(DynamicVariable class)>value:during: 0x777ea304: a(n) ZnConnectionTimeout class >>> 0xbfb1a7c0 M ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >>> 0xbfb1a7dc M ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >>> 0xbfb1a7f8 M [] in ZnClient>execute 0x79580ff0: a(n) ZnClient >>> 0xbfb1a814 M [] in ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >>> 0xbfb1a838 M [] in ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >>> 0xbfb1a858 M BlockClosure>ensure: 0x79583764: a(n) BlockClosure >>> 0xbfb1a87c M ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >>> 0xbfb1a89c M ZnSignalProgress class(DynamicVariable class)>value:during: 0x7799005c: a(n) ZnSignalProgress class >>> 0xbfb1a8bc M ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >>> 0xbfb1a8e0 M ZnClient>execute 0x79580ff0: a(n) ZnClient >>> 0xbfaad7a8 M ZnClient>get 0x79580ff0: a(n) ZnClient >>> 0xbfaad7d0 M ZnClientTests>testRedirect 0x794a76bc: a(n) ZnClientTests >> >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 27, 2013

Re: [Pharo-project] Crash seemingly related to becomeForward: on linux

by Igor Stasenko

yes, i seen that dump, Marcus. It is of course easy to blame become, but it can be worse: something corrupts heap, and the corruption stays dormant, until become operation, because it scans heap and then stumbling upon invalid pointer, which leads to crash. On 27 February 2013 13:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I will setup a second Pharo-2.0-Test running on the StackVM so we can compare them bit. > > > On 2013-02-27, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hmmâ¦ >> >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/label=linux/187/consoleFull >> >> >> Smalltalk stack dump: >> 0xbfb19878 M WideString(Object)>becomeForward: 0x795d44e4: a(n) WideString >> 0xbfb19894 M WideString>? 0x795d44e4: a(n) WideString >> 0xbfb198b4 M WriteStream>nextPut: 0x795c5f8c: a(n) WriteStream >> 0xbfb198dc M [] in ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >> 0xbfb107d8 M String class(SequenceableCollection class)>new:streamContents: 0x777cde88: a(n) String class >> 0xbfb10808 M ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity >> 0xbfb10824 M ZnStringEntity>readFrom: 0x795c1500: a(n) ZnStringEntity >> 0xbfb10844 M ZnEntity class>readFrom:usingType:andLength: 0x777e8c30: a(n) ZnEntity class >> 0xbfb10870 M ZnEntityReader>readFrom:usingType:andLength: 0x795bb9d0: a(n) ZnEntityReader >> 0xbfb108a4 M ZnEntityReader>readEntityFromStream 0x795bb9d0: a(n) ZnEntityReader >> 0xbfb108c0 M ZnEntityReader>readEntity 0x795bb9d0: a(n) ZnEntityReader >> 0xbfb108dc M ZnResponse(ZnMessage)>readEntityFrom: 0x795b3240: a(n) ZnResponse >> 0xbfafd750 M ZnResponse>readEntityFrom: 0x795b3240: a(n) ZnResponse >> 0xbfafd76c M ZnResponse(ZnMessage)>readFrom: 0x795b3240: a(n) ZnResponse >> 0xbfafd78c M ZnResponse class(ZnMessage class)>readFrom: 0x777e9004: a(n) ZnResponse class >> 0xbfafd7a8 M ZnClient>executeRequestResponse 0x79580ff0: a(n) ZnClient >> 0xbfafd7c0 M [] in ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >> 0xbfafd7e0 M BlockClosure>ensure: 0x795b1fec: a(n) BlockClosure >> 0xbfafd7fc M ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient >> 0xbfafd814 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >> 0xbfafd830 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient >> 0xbfafd84c M [] in ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >> 0xbfafd868 M BlockClosure>on:do: 0x79583bd8: a(n) BlockClosure >> 0xbfafd888 M ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient >> 0xbfafd8a4 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >> 0xbfafd8c0 M BlockClosure>on:do: 0x795839cc: a(n) BlockClosure >> 0xbfafd8e0 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >> 0xbfb1a718 M [] in ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >> 0xbfb1a73c M [] in ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >> 0xbfb1a75c M BlockClosure>ensure: 0x7958393c: a(n) BlockClosure >> 0xbfb1a780 M ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout >> 0xbfb1a7a0 M ZnConnectionTimeout class(DynamicVariable class)>value:during: 0x777ea304: a(n) ZnConnectionTimeout class >> 0xbfb1a7c0 M ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient >> 0xbfb1a7dc M ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient >> 0xbfb1a7f8 M [] in ZnClient>execute 0x79580ff0: a(n) ZnClient >> 0xbfb1a814 M [] in ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >> 0xbfb1a838 M [] in ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >> 0xbfb1a858 M BlockClosure>ensure: 0x79583764: a(n) BlockClosure >> 0xbfb1a87c M ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress >> 0xbfb1a89c M ZnSignalProgress class(DynamicVariable class)>value:during: 0x7799005c: a(n) ZnSignalProgress class >> 0xbfb1a8bc M ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient >> 0xbfb1a8e0 M ZnClient>execute 0x79580ff0: a(n) ZnClient >> 0xbfaad7a8 M ZnClient>get 0x79580ff0: a(n) ZnClient >> 0xbfaad7d0 M ZnClientTests>testRedirect 0x794a76bc: a(n) ZnClientTests > > -- Best regards, Igor Stasenko.

Feb. 27, 2013

Re: [Pharo-project] Stressing SmalltalkHub :)

by Hilaire Fernandes

Thanks. Will be nice to link it somewhere on SmalltalkHub because this question will be asked zillion of times? Hilaire Le 27/02/2013 12:35, Damien Cassou a Ã©crit : > Hi Hilaire, > > On Wed, Feb 27, 2013 at 12:11 PM, Hilaire Fernandes > <hilaire.fernandes(a)gmail.com> wrote: >> I will like to import drgeo package history in SmalltalkHub. Is it >> already possible? I remember Steph mentionned this feature a couple of >> days ago. > > ================================ > fetch script > > | go | > go := Gofer new squeaksource: 'XXX'. > go allResolved > do: [:each | > self crLog: each packageName. > go package: each packageName. > Transcript show: each printString ; cr. > go fetch.]. > > ================================== > push script > > |go repo| > repo := MCSmalltalkhubRepository > owner: 'XXX' > project: 'XXX' > user: 'XXX' > password: 'XXX'. > > > go := Gofer new. > go repository: repo. > go package: 'XXX'; push. > > ======================================= > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Feb. 27, 2013

Re: [Pharo-project] Crash seemingly related to becomeForward: on linux

by Camillo Bruni

I will setup a second Pharo-2.0-Test running on the StackVM so we can compare them bit. On 2013-02-27, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hmmâ¦ > > https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/label=linux/187/consoleFull > > > Smalltalk stack dump: > 0xbfb19878 M WideString(Object)>becomeForward: 0x795d44e4: a(n) WideString > 0xbfb19894 M WideString>? 0x795d44e4: a(n) WideString > 0xbfb198b4 M WriteStream>nextPut: 0x795c5f8c: a(n) WriteStream > 0xbfb198dc M [] in ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity > 0xbfb107d8 M String class(SequenceableCollection class)>new:streamContents: 0x777cde88: a(n) String class > 0xbfb10808 M ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity > 0xbfb10824 M ZnStringEntity>readFrom: 0x795c1500: a(n) ZnStringEntity > 0xbfb10844 M ZnEntity class>readFrom:usingType:andLength: 0x777e8c30: a(n) ZnEntity class > 0xbfb10870 M ZnEntityReader>readFrom:usingType:andLength: 0x795bb9d0: a(n) ZnEntityReader > 0xbfb108a4 M ZnEntityReader>readEntityFromStream 0x795bb9d0: a(n) ZnEntityReader > 0xbfb108c0 M ZnEntityReader>readEntity 0x795bb9d0: a(n) ZnEntityReader > 0xbfb108dc M ZnResponse(ZnMessage)>readEntityFrom: 0x795b3240: a(n) ZnResponse > 0xbfafd750 M ZnResponse>readEntityFrom: 0x795b3240: a(n) ZnResponse > 0xbfafd76c M ZnResponse(ZnMessage)>readFrom: 0x795b3240: a(n) ZnResponse > 0xbfafd78c M ZnResponse class(ZnMessage class)>readFrom: 0x777e9004: a(n) ZnResponse class > 0xbfafd7a8 M ZnClient>executeRequestResponse 0x79580ff0: a(n) ZnClient > 0xbfafd7c0 M [] in ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient > 0xbfafd7e0 M BlockClosure>ensure: 0x795b1fec: a(n) BlockClosure > 0xbfafd7fc M ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient > 0xbfafd814 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient > 0xbfafd830 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient > 0xbfafd84c M [] in ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient > 0xbfafd868 M BlockClosure>on:do: 0x79583bd8: a(n) BlockClosure > 0xbfafd888 M ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient > 0xbfafd8a4 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient > 0xbfafd8c0 M BlockClosure>on:do: 0x795839cc: a(n) BlockClosure > 0xbfafd8e0 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient > 0xbfb1a718 M [] in ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient > 0xbfb1a73c M [] in ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout > 0xbfb1a75c M BlockClosure>ensure: 0x7958393c: a(n) BlockClosure > 0xbfb1a780 M ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout > 0xbfb1a7a0 M ZnConnectionTimeout class(DynamicVariable class)>value:during: 0x777ea304: a(n) ZnConnectionTimeout class > 0xbfb1a7c0 M ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient > 0xbfb1a7dc M ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient > 0xbfb1a7f8 M [] in ZnClient>execute 0x79580ff0: a(n) ZnClient > 0xbfb1a814 M [] in ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient > 0xbfb1a838 M [] in ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress > 0xbfb1a858 M BlockClosure>ensure: 0x79583764: a(n) BlockClosure > 0xbfb1a87c M ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress > 0xbfb1a89c M ZnSignalProgress class(DynamicVariable class)>value:during: 0x7799005c: a(n) ZnSignalProgress class > 0xbfb1a8bc M ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient > 0xbfb1a8e0 M ZnClient>execute 0x79580ff0: a(n) ZnClient > 0xbfaad7a8 M ZnClient>get 0x79580ff0: a(n) ZnClient > 0xbfaad7d0 M ZnClientTests>testRedirect 0x794a76bc: a(n) ZnClientTests

Feb. 27, 2013

[Pharo-project] Crash seemingly related to becomeForward: on linux

by Marcus Denker

Hmmâ¦ https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/label=linux/187/consoleFull Smalltalk stack dump: 0xbfb19878 M WideString(Object)>becomeForward: 0x795d44e4: a(n) WideString 0xbfb19894 M WideString>? 0x795d44e4: a(n) WideString 0xbfb198b4 M WriteStream>nextPut: 0x795c5f8c: a(n) WriteStream 0xbfb198dc M [] in ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity 0xbfb107d8 M String class(SequenceableCollection class)>new:streamContents: 0x777cde88: a(n) String class 0xbfb10808 M ZnStringEntity>readLimitedFrom: 0x795c1500: a(n) ZnStringEntity 0xbfb10824 M ZnStringEntity>readFrom: 0x795c1500: a(n) ZnStringEntity 0xbfb10844 M ZnEntity class>readFrom:usingType:andLength: 0x777e8c30: a(n) ZnEntity class 0xbfb10870 M ZnEntityReader>readFrom:usingType:andLength: 0x795bb9d0: a(n) ZnEntityReader 0xbfb108a4 M ZnEntityReader>readEntityFromStream 0x795bb9d0: a(n) ZnEntityReader 0xbfb108c0 M ZnEntityReader>readEntity 0x795bb9d0: a(n) ZnEntityReader 0xbfb108dc M ZnResponse(ZnMessage)>readEntityFrom: 0x795b3240: a(n) ZnResponse 0xbfafd750 M ZnResponse>readEntityFrom: 0x795b3240: a(n) ZnResponse 0xbfafd76c M ZnResponse(ZnMessage)>readFrom: 0x795b3240: a(n) ZnResponse 0xbfafd78c M ZnResponse class(ZnMessage class)>readFrom: 0x777e9004: a(n) ZnResponse class 0xbfafd7a8 M ZnClient>executeRequestResponse 0x79580ff0: a(n) ZnClient 0xbfafd7c0 M [] in ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient 0xbfafd7e0 M BlockClosure>ensure: 0x795b1fec: a(n) BlockClosure 0xbfafd7fc M ZnClient>getConnectionAndExecute 0x79580ff0: a(n) ZnClient 0xbfafd814 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient 0xbfafd830 M ZnClient>executeWithRedirectsRemaining: 0x79580ff0: a(n) ZnClient 0xbfafd84c M [] in ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient 0xbfafd868 M BlockClosure>on:do: 0x79583bd8: a(n) BlockClosure 0xbfafd888 M ZnClient>executeWithRetriesRemaining: 0x79580ff0: a(n) ZnClient 0xbfafd8a4 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient 0xbfafd8c0 M BlockClosure>on:do: 0x795839cc: a(n) BlockClosure 0xbfafd8e0 M [] in ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient 0xbfb1a718 M [] in ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient 0xbfb1a73c M [] in ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout 0xbfb1a75c M BlockClosure>ensure: 0x7958393c: a(n) BlockClosure 0xbfb1a780 M ZnConnectionTimeout(DynamicVariable)>value:during: 0x777949f0: a(n) ZnConnectionTimeout 0xbfb1a7a0 M ZnConnectionTimeout class(DynamicVariable class)>value:during: 0x777ea304: a(n) ZnConnectionTimeout class 0xbfb1a7c0 M ZnClient>withTimeoutDo: 0x79580ff0: a(n) ZnClient 0xbfb1a7dc M ZnClient>executeWithTimeout 0x79580ff0: a(n) ZnClient 0xbfb1a7f8 M [] in ZnClient>execute 0x79580ff0: a(n) ZnClient 0xbfb1a814 M [] in ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient 0xbfb1a838 M [] in ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress 0xbfb1a858 M BlockClosure>ensure: 0x79583764: a(n) BlockClosure 0xbfb1a87c M ZnSignalProgress(DynamicVariable)>value:during: 0x7799034c: a(n) ZnSignalProgress 0xbfb1a89c M ZnSignalProgress class(DynamicVariable class)>value:during: 0x7799005c: a(n) ZnSignalProgress class 0xbfb1a8bc M ZnClient>withProgressDo: 0x79580ff0: a(n) ZnClient 0xbfb1a8e0 M ZnClient>execute 0x79580ff0: a(n) ZnClient 0xbfaad7a8 M ZnClient>get 0x79580ff0: a(n) ZnClient 0xbfaad7d0 M ZnClientTests>testRedirect 0x794a76bc: a(n) ZnClientTests

Feb. 27, 2013

Re: [Pharo-project] Progress Indication seems way off

by Camillo Bruni

On 2013-02-27, at 12:16, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 27, 2013, at 11:35 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Did anybody else notice this ? >> >> For me, in #20572, progress indication seems to be off, like when I run unit tests, there is simply no progress bar, it jumps from 0 to 369 just like that. >> >> I am also missing some but not all progress bars while doing a system update. >> > > Yes, I saw that and was wonderingâ¦ very strange. I can confirm.

Feb. 27, 2013