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

Spotter search pane does not support choose font by Settings

by lb

Hi, Pharo 5 and 4, Spotter search pane does not support choose font by Settings. Pharo 5 New Comment Pane too. AbstractNautilusUI>>buildNewCommentText | scrolledText | scrolledText := self classCommentTextModel newScrolledText beForPlainText; withCommentAnnotation; beWrapped; yourself. ............. Have a good weekend Liang

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Marcus Denker

> > 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. The only optimisation we do is that we do not compile a push pop for variables (and even blocks) that are compiled for âeffectâ as there is no effectâ¦ One could of course add support for a special case like that. But what I donât really like is that all this would require explicit recompilationâ¦ and it would be always globalâ¦ Marcus

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Marcus Denker

>> >> 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. > > Does Pharo have pool *constants* or only pool *variables* ? I don't > think a variable can/should affect compilation. > They are the same as Globals: there is an association in the literal frame whose value is pushed to read or stored into for write. > I like Eliot's approach of a variable holding a NullLogger, but if you > have expensive arguments to marshall and you need absolute > performance, perhaps an alternative proposal would be to consider > expanding the semantic that pragmas affect compilation, such that you > can use angle bracket blocks throughout the method that look up a > variable during compilation > <compileThis: [Log this: 'error'] when: DebugFlag> > > Another alternative may be to use MetaLinks to install & remove the > debugging code, plus something like the pragma syntax so these can be > written inline like this... > myMethod > x := y + 1. > < metalink: #debugging installWhenActive: [Log this: y] > > z := x + y. > Then you can enable debugging with... MetaLink activate: #debugging. I am a bit sceptical to have meta links show up as syntaxâ¦ I see two possibilities one could experiment with: 1) just add a Global + put a link. someMethod ... LogHere â¦ Opal does not compile the pushLititeralVariable/pop, it only put the association in the literal frame. Then you could put a link on this global. LogHere link: myLink. after which all methods that have LogHere would be recompiled with the code if the link compiled in. The link could reify everything needed. 2) we could add the concept of a #delete link and just annotate all sends to the Logger with that. Marcus

June 13, 2015

Re: [Pharo-dev] EnableHaltOnce shortcut

by Franck Warlouzet

Ok thanks, I already checked the shortcuts with cmd + e and they are related to add methods or classes in Group in Nautilus. I was thinking that devs used more often haltOnce than Groups. I will do your tip and duplicate the item now, thank you Ben. Cheers, Franck > From: btc(a)openinworld.com > Date: Sat, 13 Jun 2015 09:20:58 +0800 > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] EnableHaltOnce shortcut > > On Fri, Jun 12, 2015 at 9:40 PM, Franck Warlouzet > <franck.warlouzet(a)hotmail.fr> wrote: > > Hello, > > > > I really would like to have a shortcut to "Halt enableHaltOnce". What could > > be a good combinaison ? I thought about cmd e, h (for Enable Halt) but I do > > not know if it is already taken. > > > > What do you think about it ? > > You can check with "World > System > Keymap Browser" and type "+ e". > What I often do is use the halos on the "World > System > Enable > halt/inspect once" menu item to duplicate it onto the background, > which acts like a button. > cheers -ben >

June 13, 2015

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

by Esteban Lorenzano

â¦ and of course I agree 100% with you :) the real problem is how do we get there, and Iâm thinking not just the tools, but the âcultural changeâ. Esteban > On 12 Jun 2015, at 19:41, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > 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 <http://forum.world.st/GitHub-Configs-tp4830432p4830673.html>

June 13, 2015

Re: [Pharo-dev] EnableHaltOnce shortcut

by Esteban Lorenzano

> On 12 Jun 2015, at 16:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think that use case it too specific to add that for everybody. +1 > > But it would be nice if this was a one liner that you could add to your personal settings (I mean, binding a global shortcut to a block doing what you want). > > My 2c > >> On 12 Jun 2015, at 15:40, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: >> >> Hello, >> >> I really would like to have a shortcut to "Halt enableHaltOnce". What could be a good combinaison ? I thought about cmd e, h (for Enable Halt) but I do not know if it is already taken. >> >> What do you think about it ? >> >> Cheers, >> Franck > >

June 13, 2015

Re: [Pharo-dev] Detecting the context/producer of code change announcements

by Thierry Goubier

Hi Eliot, Le 13/06/2015 06:54, Eliot Miranda a Ã©crit : > Hi Thierry, > > On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > >> >> >> 2015-06-11 16:49 GMT+02:00 Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>>: >> >> >> Just a *very* divergent thought that I'm not sure is a good idea... >> maybe the parent announcement could hold the announcer of its >> children. >> >> >> The problem is then that all tools which are not interested in the >> parent announcement because they only deal with the low level stuff >> (system browser, RPackageOrganizer and friends: MessageList, Spotter, >> Critics browser, Finder, Versionner, Inspector, anything which listen >> to a code change basically) have to still listen to the parent and, on >> reception, subscribe to the low-level announcement, and then >> unsubscribe on the parent end announcement. > > It seems to me that with Ben's suggestion there need only be the > low-level announcement, and that subscribers interested in the > higher-level context could fetch it by asking the announcement for its > context. I reacted to the fact Ben said announcer, not announcement... Reregistering announcers in code-aware tools is not something you do often [1] One aspect I forgot is the performance issues linked with announcements. On package loads, a huge number of announcements is generated, and just simple things like tracking those to refresh the display of a system browser needs to be optimised to avoid degrading performance significantly. Thierry [1] https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.packag…

June 13, 2015

Re: [Pharo-dev] Detecting the context/producer of code change announcements

by Eliot Miranda

Hi Thierry, On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-06-11 16:49 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> Just a *very* divergent thought that I'm not sure is a good idea... >> maybe the parent announcement could hold the announcer of its >> children. > > The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement. It seems to me that with Ben's suggestion there need only be the low-level announcement, and that subscribers interested in the higher-level context could fetch it by asking the announcement for its context. > Another issue is, when introducing a new class of activity such as SprintInRMOD, you then need to rewrite all the listeners to add the relevant: > ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ] > > Kind of messy. > > For me, what Martin is trying to do is currently handled in a way by MC and RB: write all your code operations as abstract operations on a model of the code, group them into a composite (RBCompositeChange or something like that), and apply them all in one go. But all this structure is flattened in the change set, and may be interleaved with other changes happening at the same time. > > I'd take Martin's job idea :) plus specific announcements for the start and end. > > Thierry > >> cheers -ben >> >> > >> > I hope you can make some use of my ramblings (last exam tomorrow, just >> > taking a break here :) ) >> > >> > Cheers, >> > Max >> > >> > >> > >> > Kind regards, >> > MartÃn >> > >> > >

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Ben Coman

On Sat, Jun 13, 2015 at 5:49 AM, 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. Does Pharo have pool *constants* or only pool *variables* ? I don't think a variable can/should affect compilation. I like Eliot's approach of a variable holding a NullLogger, but if you have expensive arguments to marshall and you need absolute performance, perhaps an alternative proposal would be to consider expanding the semantic that pragmas affect compilation, such that you can use angle bracket blocks throughout the method that look up a variable during compilation <compileThis: [Log this: 'error'] when: DebugFlag> Another alternative may be to use MetaLinks to install & remove the debugging code, plus something like the pragma syntax so these can be written inline like this... myMethod x := y + 1. < metalink: #debugging installWhenActive: [Log this: y] > z := x + y. Then you can enable debugging with... MetaLink activate: #debugging. cheers -ben

June 13, 2015

Re: [Pharo-dev] EnableHaltOnce shortcut

by Ben Coman

On Fri, Jun 12, 2015 at 9:40 PM, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > Hello, > > I really would like to have a shortcut to "Halt enableHaltOnce". What could > be a good combinaison ? I thought about cmd e, h (for Enable Halt) but I do > not know if it is already taken. > > What do you think about it ? You can check with "World > System > Keymap Browser" and type "+ e". What I often do is use the halos on the "World > System > Enable halt/inspect once" menu item to duplicate it onto the background, which acts like a button. cheers -ben

June 13, 2015