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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30534 Home: https://github.com/pharo-project/pharo-core

Nov. 1, 2013

[pharo-project/pharo-core] f091ea: 30534

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: f091ea34309d163ad6a6f4ba8342bad3117fc2d1 https://github.com/pharo-project/pharo-core/commit/f091ea34309d163ad6a6f4ba… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-01 (Fri, 01 Nov 2013) Changed paths: R Compiler.package/Compiler.class/class/decompiling/decompileMethod_.st R Compiler.package/Compiler.class/class/decompiling/decompile_in_.st R Compiler.package/Compiler.class/class/decompiling/decompile_in_method_.st A Compiler.package/Compiler.class/class/utilities/decompileMethod_.st A Deprecated30.package/extension/CompiledMethod/instance/methodClassAssociation.st A Deprecated30.package/extension/CompiledMethod/instance/methodClassAssociation_.st A Deprecated30.package/extension/CompiledMethod/instance/who.st A Deprecated30.package/extension/Compiler/class/decompile_in_.st A Deprecated30.package/extension/Compiler/class/decompile_in_method_.st M FreeType.package/FT2Face.class/instance/testing/isFixedWidth.st M FreeType.package/FreeTypeFont.class/instance/displaying/displayStrikeoutOn_from_to_.st M FreeType.package/FreeTypeFontProvider.class/instance/file paths/getWindowsFontFolderPath.st M FreeType.package/FreeTypeNameParser.class/instance/initialization/initialize.st M FreeType.package/FreeTypeNameParser.class/instance/parsing/tokenize_.st R Kernel.package/CompiledMethod.class/instance/accessing/methodClassAssociation.st R Kernel.package/CompiledMethod.class/instance/accessing/methodClassAssociation_.st R Kernel.package/CompiledMethod.class/instance/printing/who.st M Kernel.package/ProtoObject.class/instance/pointing to/pointsTo_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script189.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30534.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tools.package/MetacelloConfigurationBrowserPane.class/instance/actions/refreshRepository.st M Tools.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st Log Message: ----------- 30534 12044 Move more more deprecated methods to Deprecated30 https://pharo.fogbugz.com/f/cases/12044 12045 Some underscores zealously replaced by assignment in FreeType https://pharo.fogbugz.com/f/cases/12045 12047 Config browser Refresh does only refresh the list - but not refresh from repository https://pharo.fogbugz.com/f/cases/12047 12036 pointsTo: should not filter compact classes https://pharo.fogbugz.com/f/cases/12036 http://files.pharo.org/image/30/30534.zip

Nov. 1, 2013

Re: [Pharo-dev] Debugging Morphs (was Re: Questions about Athens)

by Camillo Bruni

On 2013-11-01, at 16:44, btc(a)openinworld.com wrote: > kilon alios wrote: >> About the problem to recreate it all it takes is a demo := AthensDemoMorph >> new openInWorld . It opens the morph with the Athens grey box, I save the >> image , close pharo, open pharo which reloads the image automagically and >> BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph >> since I cant find documentation to do things differently. >> >> So lets get to the questions >> >> 6) Also why there is a Red Box of Doom in the first place ? >> > > See #drawErrorOn: call from... > > Morph>>fullDrawOn: > self visible ifFalse: [^ self]. > (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ > "calls to each Morph's drawing stuff" > ] on: Error do: > [:err | > "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: err freeze. > ^ self drawErrorOn: aCanvas ] > --------------- > In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. > From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables' > > Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this... > > Morph>>fullDrawOn: > self visible ifFalse: [^ self]. > (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ > "calls to each Morph's drawing stuff" > ] on: Error do: > [:err | > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". > ^ self drawErrorOn: aCanvas ] > "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be." You have in the halo menu an entry "debug drawing error" which does what you want. As you can see there is already the line: > > self setProperty: #drawError toValue: err freeze. which serializes the whole error (no need to use fuel as long as you stay in the image...).

Nov. 1, 2013

Debugging Morphs (was Re: Questions about Athens)

by btc＠openinworld.com

kilon alios wrote: > About the problem to recreate it all it takes is a demo := AthensDemoMorph > new openInWorld . It opens the morph with the Athens grey box, I save the > image , close pharo, open pharo which reloads the image automagically and > BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph > since I cant find documentation to do things differently. > > So lets get to the questions > > 6) Also why there is a Red Box of Doom in the first place ? > See #drawErrorOn: call from... Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: err freeze. ^ self drawErrorOn: aCanvas ] --------------- In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables' Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this... Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". ^ self drawErrorOn: aCanvas ] "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be." > 7) Why the debugger is not triggered as it should be ? > Because Morph>>fullDrawOn: is called many times a second. You would end up with dozens of debuggers coming up faster than you can respond. > 8) Is that critical a failure of Morphic ? > Its an error in the drawing code of that particular morph. cheers -ben

Nov. 1, 2013

Re: [Pharo-dev] Add HTTPRequest plugin to CI

by Camillo Bruni

On 2013-11-01, at 15:48, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi Camillo, > > thanks for following up. Yes I thought to use the URLTrigger to monitor the > Monticello repos. > > > The reason to use the HTTPRequest plugin instead of just a bash oneliner > with curl or something is that for the POST that triggers the Travis build > to succeed you need to include github authentication information. The > HTTPRequest plugin has a method to specify and store the login info in one > place, and hide the password, rather than putting it in each Jenkins job > config. > > > So to build on multiple versions of Pharo, Squeak, and Gemstone (etc) you'd: > 1. make a Github repo that tells Travis how to build the project and on what > platforms > 2. tell Travis about the Github repo > 3. make a Jenkins job that monitors the Monticello repos the smalltalk devs > currently use > 4. when the Jenkins job notices a change, it sends a POST to Github > triggering the build on Travis > 5. (no idea how to do this yet, but probably not too bad) get the build > results from Travis back to Jenkins to update the build status for each > platform/version Sorry for being sceptical, but why do you want to trigger the travis build on github from jenkins and then get the result back? Wouldn't it make more sense to just push the changes from the MC repositories to github and thus trigger the travis job that way? In any case, I added the HTTPRequest plugin so you can start trying out your travis trigger...

Nov. 1, 2013

Re: [Pharo-dev] Add HTTPRequest plugin to CI

by Paul DeBruicker

Hi Camillo, thanks for following up. Yes I thought to use the URLTrigger to monitor the Monticello repos. The reason to use the HTTPRequest plugin instead of just a bash oneliner with curl or something is that for the POST that triggers the Travis build to succeed you need to include github authentication information. The HTTPRequest plugin has a method to specify and store the login info in one place, and hide the password, rather than putting it in each Jenkins job config. So to build on multiple versions of Pharo, Squeak, and Gemstone (etc) you'd: 1. make a Github repo that tells Travis how to build the project and on what platforms 2. tell Travis about the Github repo 3. make a Jenkins job that monitors the Monticello repos the smalltalk devs currently use 4. when the Jenkins job notices a change, it sends a POST to Github triggering the build on Travis 5. (no idea how to do this yet, but probably not too bad) get the build results from Travis back to Jenkins to update the build status for each platform/version I suggest that we make a smalltalk-community group account on github that can store these multi-platform build jobs and keep that github account's authorization info in the HTTPRequest module on Inria's CI. thanks again, Paul Camillo Bruni-3 wrote > On 2013-10-31, at 19:55, Paul DeBruicker < > pdebruic@ > > wrote: >> Is it OK/possible to add this plugin to Jenkins: >> >> https://wiki.jenkins-ci.org/display/JENKINS/HTTP+Request+Plugin > > From what I get this plugin is used to make http request from jenkins. You > can easily do that with pharo ;) or bash scripts. I always prefer to not > use any jenkins specific stuff, since you cannot just copy the script and > run it locally. > > Please see below, if this is not what you need, I can install the plugin.. > >> With it a person could, if they wanted, set the Inria Jenkins to monitor >> some smalltalk mc repo urls and then trigger a github hook which would >> start travis-ci building a Configuration across several platforms. > > Maybe I misunderstood, but you want to monitor an external resource from > jenkins, we use the [URLTrigger] plugin for that, see > https://ci.inria.fr/pharo-contribution/job/AsmJit/configure > >> If you look at this repo: >> >> https://github.com/pdebruic/ConfigurationOfSeaside3 >> >> It contains the minimum needed to have Travis-CI build Seaside on Squeak, >> Pharo (1.4 & 2) , and Gemstone. To trigger the build you can either push >> a git commit to github or send a POST github as described here: >> >> http://developer.github.com/v3/repos/hooks/#test-a-push-hook >> >> I'd prefer to send a POST because it seems easier than coordinating a git >> push from the Inria CI. >> >> If its not possible to add that then I can just get a VPS for $1/month >> and run my own jenkins on it. But this technique may be generally >> useful. > > You can just setup a repository polling see > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/configure > > > signature.asc (457 bytes) > <http://forum.world.st/attachment/4718258/0/signature.asc> -- View this message in context: http://forum.world.st/Add-HTTPRequest-plugin-to-CI-tp4718203p4718345.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 1, 2013

Re: [Pharo-dev] Strange primitive failure

by Alexandre Bergel

Nothing surprising here for me. The reason is that an array is really simple (e.g., fixed size, easy to access element, which does not require to send message from the VM), while an ordered collection is more complex and the VM does not support direct operations on it. The VM knows how to deal with Array, but it does not know how an ordered collection works. Alexandre On Nov 1, 2013, at 11:01 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Hello guys, > > is it expected that > > 1 perform: #gcd: withArguments: {2} > works > > while > > 1 perform: #gcd: withArguments: {2} asOrderedCollection > fails ? > > > Ben > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 1, 2013

Strange primitive failure

by Benjamin

Hello guys, is it expected that 1 perform: #gcd: withArguments: {2} works while 1 perform: #gcd: withArguments: {2} asOrderedCollection fails ? Ben

Nov. 1, 2013

Re: [Pharo-dev] Using Gutenberg

by phil＠highoctane.be

philippeback --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Fri, Nov 1, 2013 at 2:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > sure what is your git account. > > Stef > > On Nov 1, 2013, at 2:01 PM, phil(a)highoctane.be wrote: > > Can you give me write access to the repo? > > Phil > > > On Fri, Nov 1, 2013 at 4:42 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> the pdf that I sent and that you can find on git hub >> >> >> https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english >> >> down down down at the bottom >> >> >> On Oct 31, 2013, at 7:17 PM, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> >> > >> > On 2013-10-31, at 18:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> > >> >> read the latex we documented everything. >> > >> > which latex file? >> >> >> > >

Nov. 1, 2013

Re: [Pharo-dev] Losing instance variable addition

by StÃ©phane Ducasse

> > This is not the same :) > > What is not the same? :) By "override" I meant the problem induced by two packages that define the same method, and that are being loaded at the same time. ah that yes but it will probably never happen in reality :) I thought more about method extensions Stef

Nov. 1, 2013