June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Torsten Bergmann

> EstebanLM wrote > > Which other functionality you think we should add? > > Browse configuration class from context menu when present > > ----- > Cheers, > Sean I just added this in "Tool-Catalog-TorstenBergmann.14" ("allow to browse the config class when loaded similar to what Config browser had"). Will be integrated with the next release version. Thanks T.

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Eliot Miranda

Hi Torsten, On Jun 12, 2015, at 2:49 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > Hi, > > for tracing and logging one could easily write: > > foo > ... > Log enabled ifTrue: [ "do some tracing here" ]. > ... > > but this always requires some message sends/checks if the debug mode is active. > This is OK while debugging/tracing to find errors - but for runtime one whishes to have the > best performance without any effect of tracing/debug code. > > Smalltalk/MT had a nice optimization feature that allowed to mix in debug code without > additional overhead when in non-debug mode. If I remember correctly the basic idea was the > following: there is a pool constant _DEBUG_INTERNAL that you compare to another pool constant > TRUE (representing the value 1). > > So with an expresion like _DEBUG_INTERNAL == TRUE this ends up in 1 == 1 comparision > which is always true if the pool constants/values have the same value of 1. > A followup message send of #ifTrue: will always be executed - therefore means for the compiler > to included the (debug) code: > > foo > ... > _DEBUG_INTERNAL == TRUE ifTrue: [ > Processor outputDebugLine: 'Trace something' > ]. > ... > > So in this case (always true) this was optimized by the compiler to > > foo > ... > Processor outputDebugLine: 'Trace something' > ... > > When _DEBUG_INTERNAL was set to FALSE (represented by value 0 as in C/C++) this > ends up in 0 == 1 which is always false and will never be true. So a followup message > send of #ifTrue: was optimized (removed as it was dead code and never reached). > > foo > ... > ... > > So depending on pool flag _DEBUG_INTERNAL and recompilation of (all) methods one > could add debug/trace/logging code without runtime overhead. Yes this is very C language > like to have conditional compilation - but very effective in keeping debug/tracing > code influence low. > > I know we usually have the debugger in front of us - but sometimes a trace or log is > required to see where code crashes. Think of a headless situation in a webserver or > a small device like the pi where you want to reduce the performance overhead. > > This leads to several questions: > - Is something like this feasible/already possible in Pharo? > - Any pointers on how Opal does optimizations? Do we have similar optimizations (removing > code that could not be reached) that could be used. > - How do you usually deal with additional tracing code when you do not want to > have too much runtime overhead. One way is to hold the logger in an inst var and have two loggers, one null and one not. Then the overhead in the null case is marshaling arguments and a frameless send. If there are no expensive arguments to Marshall (such as a block or an expression) then I expect thus will be quite cheap. The analogue of this approach that I use in the VM are the many many assertions which compile Tia macro invocation that in production code compiles to null. > > Thanks > T. >

June 13, 2015

Magritte3 in Pharo 5.0

by Sean P. DeNigris

Loading via catalog browser gives: "'This package depends on the following classes: GRDelegatingStream You must resolve these dependencies before..." Any idea what we should do? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Magritte3-in-Pharo-5-0-tp4832177.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 13, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Sean P. DeNigris

Torsten Bergmann wrote > I just added this in "Tool-Catalog-TorstenBergmann.14" Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Tool-Catalog-Browser-in-Pharo-5-0-tp4831575p48321… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 13, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Sean P. DeNigris

EstebanLM wrote > Which other functionality you think we should add? Browse configuration class from context menu when present ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Tool-Catalog-Browser-in-Pharo-5-0-tp4831575p48321… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2015

Debugging and optimizations

by Torsten Bergmann

Hi, for tracing and logging one could easily write: foo ... Log enabled ifTrue: [ "do some tracing here" ]. ... but this always requires some message sends/checks if the debug mode is active. This is OK while debugging/tracing to find errors - but for runtime one whishes to have the best performance without any effect of tracing/debug code. Smalltalk/MT had a nice optimization feature that allowed to mix in debug code without additional overhead when in non-debug mode. If I remember correctly the basic idea was the following: there is a pool constant _DEBUG_INTERNAL that you compare to another pool constant TRUE (representing the value 1). So with an expresion like _DEBUG_INTERNAL == TRUE this ends up in 1 == 1 comparision which is always true if the pool constants/values have the same value of 1. A followup message send of #ifTrue: will always be executed - therefore means for the compiler to included the (debug) code: foo ... _DEBUG_INTERNAL == TRUE ifTrue: [ Processor outputDebugLine: 'Trace something' ]. ... So in this case (always true) this was optimized by the compiler to foo ... Processor outputDebugLine: 'Trace something' ... When _DEBUG_INTERNAL was set to FALSE (represented by value 0 as in C/C++) this ends up in 0 == 1 which is always false and will never be true. So a followup message send of #ifTrue: was optimized (removed as it was dead code and never reached). foo ... ... So depending on pool flag _DEBUG_INTERNAL and recompilation of (all) methods one could add debug/trace/logging code without runtime overhead. Yes this is very C language like to have conditional compilation - but very effective in keeping debug/tracing code influence low. I know we usually have the debugger in front of us - but sometimes a trace or log is required to see where code crashes. Think of a headless situation in a webserver or a small device like the pi where you want to reduce the performance overhead. This leads to several questions: - Is something like this feasible/already possible in Pharo? - Any pointers on how Opal does optimizations? Do we have similar optimizations (removing code that could not be reached) that could be used. - How do you usually deal with additional tracing code when you do not want to have too much runtime overhead. Thanks T.

June 12, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Sean P. DeNigris

EstebanLM wrote > In any case this is Pharo 5 super-alphaâ¦ so there is no need to keep > things going until we replace them :) IMHO it's not too much to ask to keep the old tool *at least* until the release when we've have time to adapt and have these discussions. If we removed it because we want to encourage use of the new tools, maybe the old one could be buried a bit more in the menus e.g. World->Tools->Deprecated. This seems eerily familiar to the discussions around GT... EstebanLM wrote > In case of add own repositories, Iâm not sure anyone used itâ¦ I was :) It's very useful for e.g. private projects, forked configs w. different stable/default groups, etc. I guess I've gotten used to our lightning-quick development pace because, when my startup script which adds the repos got an error, I assumed another cool tool had been introduced, and found the Catalog Browser. But now I'll have to go back to 4.0 for some tasks for a while... [OT]: now that the tool is getting more comprehensive, can we add the ability to load #development, or #bleedingEdge? I understand we may want to bury them a bit not to confuse new users, but IMHO the lack makes the tool much less useful for non-newbies (me at least!)... ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Tool-Catalog-Browser-in-Pharo-5-0-tp4831575p48321… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 7b783b: 50112

by Torsten Bergmann

>12986 Increase speed of accessing sourceCode >https://pharo.fogbugz.com/f/cases/12986 Wow! Searching through sources using Finder in latest Pharo 5 is now super fast ... a good candidate for a backport to Pharo 4 (if possible). Thanks Camillo! Bye T.

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Dale Henrichs

On 06/12/2015 01:24 AM, Esteban Lorenzano wrote: > it was just an example of why using #stable in project dependences is a bad idea :) > you made #releaseN.N to fix precisely my point. > but since this is a convention of Seaside and not a regular practiceâ¦ who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â) > > btwâ¦ IMO other frequent misunderstanding is the use of metacello as description for nightly builds. > metacello (and any dependency manager) should be use *just* for releases. > think other dependecy managers around: maven, npm or whateverâ¦ they are used to describe and publish projects people actually can download and use. > Any version: > > 3.0 > 3.0.1 > 3.1 > â¦ > etc. > > is a loadable and usable version. > the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. > > we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. > In my opinion development cycle should be: > > we release version 1.0 > then we develop in bleeding edge lets say for doing a version 1.1 > we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 > we continue in #bleedingEdge until we are ready to: > 1.1-alpha > 1.1-beta > 1.1-rc1 > 1.1 > we repeat the cycle for next version > etc. > > Iâm sorry for being obvious here, I know this is knownâ¦ problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. > Esteban, this point is exactly the reason that I am a proponent of using git. Branches are first class objects in git and provide exactly the type of functionality that is needed for doing development where problems are being solved on multiple fronts. I've added features to the Metacello Scripting API over the last couple of years to make it possible to switch between github-based repos and local git clones which is critical for development and So I don't think that "Metacello shouldn't be used for nightly builds", but that "ConfigurationOf shouldn't be used for nightly builds":) I've recently posted an article on the Metacello news group[1] where I talk in more detail about using Metacello and git for development. Dale [1] http://forum.world.st/GitHub-Configs-tp4830432p4830673.html

June 12, 2015

[pharo-project/pharo-core]

by GitHub

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

June 12, 2015