March 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

March 31, 2016

[pharo-project/pharo-core] 5c862f: 50671

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5c862f4d413a0f451d130861d31966d5593edd80 https://github.com/pharo-project/pharo-core/commit/5c862f4d413a0f451d130861… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-03-31 (Thu, 31 Mar 2016) Changed paths: A Athens-Cairo.package/AthensCairoMatrix.class/instance/copying/copy.st A Athens-Cairo.package/AthensCairoSurface.class/class/library path/ffiLibraryName.st M Athens-Cairo.package/CairoFontMetricsProvider.class/instance/private/applyKerningOn_of_from_to_.st M Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/private/applyKerningOn_of_from_to_.st A Athens-Cairo.package/TCairoLibrary.class/class/library path/nbLibraryNameOrHandle.st M ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/symbolic versions/stable_.st A ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version39_.st M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/development_.st M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/stable_.st R ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/pre2%5F6%5F0_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/pre2%5F7%5F0_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F0_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F1_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F2_.st A QualityAssistant.package/QANautilusPluginMorph.class/class/accessing/wasOpenedBefore.st A QualityAssistant.package/QANautilusPluginMorph.class/class/accessing/wasOpenedBefore_.st A QualityAssistant.package/QANautilusPluginMorph.class/class/cleanup/cleanUp.st M QualityAssistant.package/QANautilusPluginMorph.class/instance/actions/updateList.st M QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/initialize.st M QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/initializeList.st M QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/initializeProgress.st A QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/privacyMorph.st M QualityAssistant.package/QASettings.class/class/settings-accessing/spotterPlugin.st M QualityAssistant.package/QASettings.class/class/settings-accessing/spotterPlugin_.st M QualityAssistant.package/QASettings.class/definition.st A QualityAssistant.package/QASettings.class/instance/accessing/spotterPlugin.st A QualityAssistant.package/QASettings.class/instance/accessing/spotterPlugin_.st M QualityAssistant.package/QASettings.class/instance/initialization/initialize.st M QualityAssistant.package/extension/CompiledMethod/instance/spotterQACriticsFor_.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/Behavior%5FspotterQACriticsFor.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/Behavior%5FspotterQACriticsFor_.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/CompiledMethod%5FspotterQACriticsFor.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/CompiledMethod%5FspotterQACriticsFor_.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/TraitBehavior%5FspotterQACriticsFor.st A QualityAssistant.package/extension/GTSpotterExtensionSettings/class/TraitBehavior%5FspotterQACriticsFor_.st M QualityAssistant.package/extension/TBehavior/instance/spotterQACriticsFor_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50670.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50671.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50670.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50671.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50671 17904 Update athens 3.9 https://pharo.fogbugz.com/f/cases/17904 17912 QualityAssistant v2.6.2 https://pharo.fogbugz.com/f/cases/17912 http://files.pharo.org/image/50/50671.zip

March 31, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Nicolai Hess

2016-03-30 19:54 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Do anyone really use GLM-Morphic-Brick? > We all "use" it, our tools are build with this. (inspector/debugger/playground/spotter). > Because it is there just for spotter and will be deleted ASAP. > Not only for spotter. And if our tools are build with this, people may try to use this for their own tools. This is the core image, and the core tools. What should we say? Please don't use it, but our core tools are built on this? > We know that it is bad. Normal fix requires too many changes... > No excuse. > On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > >> Please don't do this: >> >> updateHeight >> "no need to care about height, when it's logic is not customized" >> self layout isHeightCustom ifFalse: [ ^ self ]. >> [ self bounds: (self brickBounds withHeight: self customHeight) ] >> on: Exception >> do: [ "just skip and do nothing" ] >> >> This makes debugging GLM/Brick ui/layout code with "self haltOnce" >> impossible. >> see >> GLMBrickGeometryTrait>>#updateHeight >> GLMBrickGeometryTrait>>#updateWidth >> >> And if you log out the raised exception, you see some calls to >> not initialized fonts and a ZeroDevide and some more errors. >> The above catch, catches and hides wrong / to late initialized objects. >> >

March 31, 2016

Re: [Pharo-dev] 'Bad argument for external function' with UFFI... no clue

by Esteban Lorenzano

how does your function call looks like? > On 31 Mar 2016, at 04:55, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys, > > Could someone help me understand what could be the exact reason of a 'Bad argument for external function' in an FFI call? Of course, I double checked all the arguments definitions in the #ffiCall: and the real objects I receive as arguments at the moment of the callout. And they all seem correct. > > And even better...how can I get more info about it? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

March 31, 2016

'Bad argument for external function' with UFFI... no clue

by Mariano Martinez Peck

Hi guys, Could someone help me understand what could be the exact reason of a 'Bad argument for external function' in an FFI call? Of course, I double checked all the arguments definitions in the #ffiCall: and the real objects I receive as arguments at the moment of the callout. And they all seem correct. And even better...how can I get more info about it? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

March 31, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Aliaksei Syrel

Do anyone really use GLM-Morphic-Brick? Because it is there just for spotter and will be deleted ASAP. We know that it is bad. Normal fix requires too many changes... On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > Please don't do this: > > updateHeight > "no need to care about height, when it's logic is not customized" > self layout isHeightCustom ifFalse: [ ^ self ]. > [ self bounds: (self brickBounds withHeight: self customHeight) ] > on: Exception > do: [ "just skip and do nothing" ] > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" > impossible. > see > GLMBrickGeometryTrait>>#updateHeight > GLMBrickGeometryTrait>>#updateWidth > > And if you log out the raised exception, you see some calls to > not initialized fonts and a ZeroDevide and some more errors. > The above catch, catches and hides wrong / to late initialized objects. >

March 30, 2016

Re: [Pharo-dev] validation error related to Fuel

by Martin Dias

Hi, Christophe, did you check locally if some system test fails (or there is some loading error)? I debugged something similar a while ago, and discovered that the source of the problem is usually a test that fails (or errors) and the monkey/fuel is unable to serialize/materialize the associated stack trace. I tell you why. The monkey uses Fuel to serialize and materialize the stack trace of the tests failures. The problem is that sometimes Fuel fails to serialize/materialize such stack trace and then the monkey's output is a Fuel error instead of the original error. The default way of Fuel to serialize a method is: store it's class name, the selector, and the bytecode's hash. To materialize such method (in a potentially different image), Fuel uses the class name and selector to fetch the method (which might be different from the method serialized), and checks that bytecodes' hash are equal. The FLMethodChanged is signaled here, since it's important that bytecodes match. Going back to this particular error, I imagine this reason for the Fuel error during monkey's validation: the original test failure has a a context in its stack trace that points to the changed method, which "changed bytecodes". What I find strange is that (AFAIK) the monkey configures Fuel to serialize the changed entities in a special way where the original bytecodes are stored and then FLMethodChanged shouldn't happen. I could take a look on monkey (more precisely, on ImageWorker) if this error is reproducible... Cheers, Martin On Wed, Mar 30, 2016 at 4:41 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > Le 30 mars 2016 Ã 09:31, Max Leske <maxleske(a)gmail.com> a Ã©crit : > > > On 30 Mar 2016, at 09:10, Christophe Demarey <christophe.demarey(a)inria.fr> > wrote: > > Hi, > > With case #17889, I get the following validation error: > Exception: FLMethodChanged: Materialization error. Method > SystemSettingsPersistence class>>#initialize changed its bytecodes. > I have no idea what to do with that. Yes, I changed this method and â¦ > Does anyone have an idea? > > Thanks, > Christophe > > > The validation is materializing the method in the parent image, which > means the byte code of that method is being installed. It is often safe to > ignore that error, so you could override the #defaultAction of > FLMethodChanged in the preload, for instance (e.g. with âself > resumeUnchecked: nil). > > > ok, thanks for the workaround. > > > What I canât tell you by heart is why the method is being serialized in > the fist place. > > > If you remember the reason, please share it. > > Thanks for your quick answer. > Christophe >

March 30, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Richard Sargent

Nicolas Cellier wrote > Isn't catching too wide an anti-pattern? Yes! Just think of all the Exception subclasses which are *not* errors. This kind of thing effectively disables them. > 2016-03-30 13:33 GMT+02:00 Nicolai Hess < > nicolaihess@ > >: > >> Please don't do this: >> >> updateHeight >> "no need to care about height, when it's logic is not customized" >> self layout isHeightCustom ifFalse: [ ^ self ]. >> [ self bounds: (self brickBounds withHeight: self customHeight) ] >> on: Exception >> do: [ "just skip and do nothing" ] >> >> This makes debugging GLM/Brick ui/layout code with "self haltOnce" >> impossible. >> see >> GLMBrickGeometryTrait>>#updateHeight >> GLMBrickGeometryTrait>>#updateWidth >> >> And if you log out the raised exception, you see some calls to >> not initialized fonts and a ZeroDevide and some more errors. >> The above catch, catches and hides wrong / to late initialized objects. >> -- View this message in context: http://forum.world.st/Catching-Exceptions-without-any-notice-tp4887402p4887… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 30, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Nicolas Cellier

Isn't catching too wide an anti-pattern? 2016-03-30 13:33 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Please don't do this: > > updateHeight > "no need to care about height, when it's logic is not customized" > self layout isHeightCustom ifFalse: [ ^ self ]. > [ self bounds: (self brickBounds withHeight: self customHeight) ] > on: Exception > do: [ "just skip and do nothing" ] > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" > impossible. > see > GLMBrickGeometryTrait>>#updateHeight > GLMBrickGeometryTrait>>#updateWidth > > And if you log out the raised exception, you see some calls to > not initialized fonts and a ZeroDevide and some more errors. > The above catch, catches and hides wrong / to late initialized objects. >

March 30, 2016

Catching Exceptions without any notice

by Nicolai Hess

Please don't do this: updateHeight "no need to care about height, when it's logic is not customized" self layout isHeightCustom ifFalse: [ ^ self ]. [ self bounds: (self brickBounds withHeight: self customHeight) ] on: Exception do: [ "just skip and do nothing" ] This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible. see GLMBrickGeometryTrait>>#updateHeight GLMBrickGeometryTrait>>#updateWidth And if you log out the raised exception, you see some calls to not initialized fonts and a ZeroDevide and some more errors. The above catch, catches and hides wrong / to late initialized objects.

March 30, 2016