- Pharo-dev - lists.pharo.org

[Pharo-project] One-Click now uses latest build VMS

by Marcus Denker

The one click at: https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo2… now uses the -latest zips from http://pharo.gforge.inria.fr/ci/vm/pharo/ Marcus

Feb. 28, 2013

[Pharo-project] Issue 7618: Script Download Job is broken

by Marcus Denker

http://code.google.com/p/pharo/issues/detail?id=7618 ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway hudson.plugins.git.GitException: Command "git fetch -t origin +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: The remote end hung up unexpectedly

Feb. 28, 2013

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

by stephane ducasse

I have the impression that there are several problems together. May be removing the cleanUpforRelease and see if it fixes the problems with dateandtime delays is a good move. Stef On Feb 27, 2013, at 1:57 PM, 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. > > 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. 28, 2013

[Pharo-project] [update 2.0] #20574

by Marcus Denker

20574 ----- Issue 7614: do not do #cleanUpForRelease after every update http://code.google.com/p/pharo/issues/detail?id=7614 Issue 7613: Rename tabs in config browser http://code.google.com/p/pharo/issues/detail?id=7613 Issue 7612: EUCTextConverter>>nextFromStream: returns the wrong characters http://code.google.com/p/pharo/issues/detail?id=7612 Diff information: http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Core-MarcusDenker.12.diff http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1055.diff http://ss3.gemstone.com/ss/Pharo20/Multilingual-TextConversion-MarcusDenker… http://ss3.gemstone.com/ss/Pharo20/Multilingual-Tests-MarcusDenker.25.diff

Feb. 28, 2013

Re: [Pharo-project] iOS VM - Sure not right for iDevices...

by phil＠highoctane.be

Some more progress. It all compiles after going through some hoops. There is a duplication of code for the interp C code for isFree during generation (but it is the same code, I don't know why this happens but it wasn't there in the past). Also, the socket plugin needed to be removed as it was included for some reason. It even links. Now, the project doesn't want to let me run it on the iPad for some change being done somewhere in CMake when I do a cmake -G Xcode. Digging that now. Phil

Feb. 28, 2013

Re: [Pharo-project] VM unstable

by Marcus Denker

On Feb 28, 2013, at 9:29 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Feb 28, 2013, at 8:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Feb 27, 2013, at 10:38 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> >>> Marcus we were looking at delay and dateAndTime with igor and I wonder if there is not a relationship >>> between all the date and time delays and the fact that you put the cleanForRelease systematically for each build. >>> >> >> yes, that could be. We can turn it off again.. and move that to 3.0 >> >> But we really need to have a process of building the image that does not require *anything* to be done >> before the relase. Because anything, be it even the most trivial thing, will break if you do it only once >> every year. > > I think that it may just solve the dateAndTime delay problems > Now it shows that there is something wrong in the logic of the cleanup and probably on the delay > Ok, I added a removal for the cleanup. > In adition there is probabbly a bug that crash the vm http://code.google.com/p/pharo/issues/detail?id=7614 Marcus

Feb. 28, 2013

Re: [Pharo-project] VM unstable

by stephane ducasse

On Feb 28, 2013, at 8:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 27, 2013, at 10:38 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> Marcus we were looking at delay and dateAndTime with igor and I wonder if there is not a relationship >> between all the date and time delays and the fact that you put the cleanForRelease systematically for each build. >> > > yes, that could be. We can turn it off again.. and move that to 3.0 > > But we really need to have a process of building the image that does not require *anything* to be done > before the relase. Because anything, be it even the most trivial thing, will break if you do it only once > every year. I think that it may just solve the dateAndTime delay problems Now it shows that there is something wrong in the logic of the cleanup and probably on the delay In adition there is probabbly a bug that crash the vm > >> We may have found a bug in/related startTimerEventLoop >> >> when you look at the code you should get really concentrated and fresh â¦ :( >> >> Stef > >

Feb. 28, 2013

Re: [Pharo-project] VM unstable

by Marcus Denker

On Feb 27, 2013, at 10:38 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > Marcus we were looking at delay and dateAndTime with igor and I wonder if there is not a relationship > between all the date and time delays and the fact that you put the cleanForRelease systematically for each build. > yes, that could be. We can turn it off again.. and move that to 3.0 But we really need to have a process of building the image that does not require *anything* to be done before the relase. Because anything, be it even the most trivial thing, will break if you do it only once every year. > We may have found a bug in/related startTimerEventLoop > > when you look at the code you should get really concentrated and fresh â¦ :( > > Stef

Feb. 28, 2013

Re: [Pharo-project] iOS VM - Sure not right for iDevices...

by phil＠highoctane.be

Sure. I just feels like I am back to 1993 when I was doing ASM, C, and C++ all day long. Anwyay, there has been progress: 83% builds fine. Now, I am on the main application. So, there is something wrong with OpenGL which gets loaded where it should not. Maybe just a framework thing to sort out. More tomorrow. Looks like I am gonna get the build working again. But I wonder how I'll get the result on my iPad... Xcode Cmake target ... Then I'll be able to put my changes for the bluetooth keyboard.... [ 83%] Building CXX object CMakeFiles/iStackVM.dir/Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/iPhone/Classes/SqueakNoOGLIPhoneAppDelegate.m.o In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/AudioToolbox.framework/Headers/AudioToolbox.h:25, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/plugins/SoundPlugin/sqSqueakSoundCoreAudio.h:41, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/Common/Classes/sqSqueakMainApplication.h:47, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/Common/Classes/sqSqueakAppDelegate.h:43, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/iPhone/Classes/SqueakNoOGLIPhoneAppDelegate.h:43, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/iPhone/Classes/SqueakNoOGLIPhoneAppDelegate.m:41: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/AudioToolbox.framework/Headers/AudioQueue.h:332: warning: âweak_importâ attribute does not apply to types In file included from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/iPhone/Classes/SqueakUIViewOpenGL.h:42, from /Users/philippeback/Documents/Smalltalk/2-MyWorkspaces/workspaceVMiOSFromBook/blessed/platforms/iOS/vm/iPhone/Classes/SqueakNoOGLIPhoneAppDelegate.m:46: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:45: error: redefinition of typedef âGLenumâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:55: error: previous declaration of âGLenumâ was here /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:46: error: redefinition of typedef âGLbooleanâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:56: error: previous declaration of âGLbooleanâ was here /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:47: error: redefinition of typedef âGLbitfieldâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:57: error: previous declaration of âGLbitfieldâ was here /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:48: error: redefinition of typedef âGLbyteâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:58: error: previous declaration of âGLbyteâ was here /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:49: error: redefinition of typedef âGLshortâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:59: error: previous declaration of âGLshortâ was here /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES1/gl.h:50: error: redefinition of typedef âGLintâ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/ES2/gl.h:60: error: previous declaration of âGLintâ was here 2013/2/27 Igor Stasenko <siguctua(a)gmail.com>: > On 27 February 2013 22:58, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> I am getting closer! >> >> But it is not going to be so trivial because some things are in >> CogFamilyCocoaIOSConfig and get used for StackIOSConfig, which is not >> very clean. >> >> Anyway, once things compile here, I'll ship you my full folder so that >> it will be easier to integrate the results. >> >> >> Phil, knowing a tad more about Cmake and the source generation process >> that he would like to know in the first place... >> > > Sounds like you prefer having knowledge about m4 syntax and autoconfig > process instead :) > Sorry about that.. but who said that compiling C code and/or porting C > to another platform is easy task? > > Lately, i found that many smalltalkers taking portability for > granted.. because it costs no effort for them to just get VM for their > OS and run stuff there.. forgetting that to get it compiled & working > there costs a lot of sweat & brain cells to someone . > > Portable C code is a myth.. but sure when you back it with enormous > workforce of numerous C hackers, and countless hours of trial and > fail, it becomes reality. > > > >> 2013/2/27 Igor Stasenko <siguctua(a)gmail.com>: >>> On 27 February 2013 18:43, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>> Yeah but it is not. >>>> >>>> StackIPhoneConfig new >>>> "addExternalPlugins: #( FT2Plugin );" >>>> "generateDebug;" >>>> generateSources; >>>> generate. >>>> >>>> and I had to comment out the FT2Plugin for some other reason. Maybe >>>> I'll be able to put it back later. >>>> >>>> There is no PharoVMBuilder support for the iOS things at the moment. >>>> >>> >>> Yes. But it would be trivial to add. >>> But making things compile & work will be non-trivial, and require >>> people like Esteban who knows >>> iOS quirks and pitfalls .. because i am not the right person :) >>> >>>> Phil >>>> >>>> 2013/2/27 Igor Stasenko <siguctua(a)gmail.com>: >>>>> 2013/2/27 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>>> CocoaIOSConfig>>commonCompilerFlags >>>>>> "Common compiler flags" >>>>>> ^#('-arch i386' '-mmacosx-version-min=10.5' '-DHAVE_UUID_GENERATE') >>>>>> >>>>> >>>>> it should be overridden in subclass, no? >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 27, 2013

Re: [Pharo-project] Is this possible with XMLWriter?

by GastÃ³n Dall' Oglio

And in case anyone is not aware, this video shows how to manipulate xml: http://www.pharocasts.com/2010/08/see-how-to-get-data-from-url-parse-xml.ht… 2013/2/27 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 27 Feb 2013, at 22:17, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: > > > +1 > > > > Mariano I'm about to migrate the XMLParser to SmalltalkHub and I know > that you have a DOMTree and a saxAPI > > So with the DOMTree I do not see why we could not manipulate the tree. > > > > Stef > > Here are two approaches that seem to work fine: > > | dom | > dom := (XMLDOMParser parse: '<foo><bar>text</bar><baz>100</baz></foo>'). > dom firstElement addNode: ((XMLElement named: 'mariano') addContent: 'Hi > there !' ). > dom prettyPrinted. > > | xmlWriter dom | > xmlWriter := XMLWriter new writeWith: [ :writer | > writer > enablePrettyPrinting; > xml; > comment: 'Generated from Pharo.'. > writer tag: 'root' with: [ > writer tag: 'parent1' with: [ > writer tag: 'child1' with: 'grrr'. > writer tag: 'child2' with: 'grrr' ]. > writer tag: 'parent2' with: [ > writer tag: 'child3' with: 'buhhhr' ] ] ]. > dom := (XMLDOMParser parse: xmlWriter contents). > dom firstElement addNode: ((XMLElement named: 'mariano') addContent: 'Hi > there !' ). > dom prettyPrinted. > > I guess it would also be possible to completely construct the DOM tree > manually. > > Regards, > > Sven > > >> On 27 Feb 2013, at 21:18, "Esteban A. Maringolo" <emaringolo(a)gmail.com> > wrote: > >> > >>> To do what he wants he should have an XML DOM and manipulate the DOM > >>> nodes directly. I don't know if we have such thing in Pharo. > >> > >> I would be very surprised if that were not possible: create a DOM tree, > either manually or by parsing some XML, then add some nodes and finally > render it again. > >> > >> I never did this, but I'll have a look if I have some time. > >> > >> Sven > >> > >> > >> -- > >> Sven Van Caekenberghe > >> http://stfx.eu > >> Smalltalk is the Red Pill > >> > > > > >

Feb. 27, 2013