Re: [Pharo-dev] Debugging and optimizations
This is an interesting problem. There is currently no simple way of executing a message at compile-time instead of at runtime in Pharo, which is useful to have settings but no runtime overhead. I did a simple extension for opal compiler for this purpose, adding the message Cvalue, which is compiled by Opal either to its receiver's block value or the result of its value depending on the result of #allowPrecompilation sent to its class using AST manipulation before the semantic analysis. Example: MyClass#example ^ [ Smalltalk vm class ] Cvalue if MyClass allowPrecompilation answers true, it is compiled to: ^ VirtualMachine if MyClass allowPrecompilation answers false, it is compiled to: ^ Smalltalk vm class if MyClass does not use the compiler extension, Cvalue is implemented as ^ self value on BlockClosure. In your case it's slightly different, if you write [ Processor outputDebugLine: 'Trace something' ] Cvalue. It would either compile to the body of the block or evaluate the expression at compile-time, and you don't want to evaluate the expression at compile-time but just delete it. I believe something similar to what I did could solve your problem. However, it's difficult to do something easy to read and to use without having to extend too much the Smalltalk language... Here I added a special selector which is an important constraint so I don't think such code should be in the base image. If you're interested, the code is on Smalltalkhub ClementBera/NeoCompiler, you need to recompile the NeoCompiler examples once they're loaded to have them working, then you can look at the bytecode generated in NeoCompilerExample#example and NeoCompilerExample2#example to easily understand what is compiled. If you change NeoCompiler#precompile: to replace the 'aBlock CValue' expression by (RBLiteralNode value: nil) instead of the result of the expression it should do what you want. Now as I said this is not difficult to implement the problem is how to do it without having extensions and constraints in the Smalltalk semantics. 2015-06-13 13:20 GMT+02:00 Marcus Denker marcus.den...@inria.fr: 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
[Pharo-dev] Fwd: [Amber list]: Importing Data from Pharo
IDK enough about STON to answer well. I'm forwarding to Pharo Dev... From http://forum.world.st/Importing-Data-from-Pharo-tt4832187.html : Amber Smalltalk mailing list wrote On Sat, Jun 13, 2015 at 5:38 AM, Sean P. DeNigris lt; sean@ gt; wrote: I have a few Pharo apps that simply offer querying of an unchanging database of objects - think something like a train schedule. I often want to offer these via Amber. Creating the Amber UI is easy enough. The thing that usually slows me down is importing the data. I know I can use Pharo as a backend and keep the data there, but since there is no editing involved, it would greatly simplify things to keep everything in Amber. The typical ways to store objects in Pharo are Fuel or STON. But as far as I know, neither of these are compatible with Amber, are they? What I've done in the past is write a custom serializer that creates class-side constructor methods to re-create the data, but feels like too much extra work. STON is an extension of the JSON notation, if I understood this correctly from a recent thread on the Pharo mailinglist. Is that right? What Amber supports out of the box is JSON (obviously). So far there is no support for Fuel of STON but STON might work if it could be transformed to/queried as plain JSON. Is anyone else running into this complication i.e. wanting to move data from Pharo to Amber? If so, what is the best practice here? Would it be worth it to port something to facilitate... maybe STON? STON is going to be integrated into Pharo 5, right? In that case it might be worth to have a library written in Amber which supports reading/writing STON so an Amber application can easily exchange data with a Pharo server. I think that using the regular JSON parser will not work here (correct me if I am wrong). The question is if writing a new parser (Amber uses PEG.js for parsing) would be required for a STON library or if the Amber internal parser could be reused in this case. Best, Manfred - Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Amber-list-Importing-Data-from-Pharo-tp4832254.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Debugging and optimizations
Le 13/06/2015 14:39, Clément Bera a écrit : This is an interesting problem. There is currently no simple way of executing a message at compile-time instead of at runtime in Pharo, which is useful to have settings but no runtime overhead. This is the discussion I wanted to have about pragmas... It didn't turn out this way ;) Returning to the original problem, would something like aspect-oriented programming [1][2] implemented via RB rewriting or Metalinks a solution for modeling the problem? It is easy in Smalltalk/Pharo to search for specific pragmas or comments to trigger the rewriting on or off, and easy to do the rewriting even without MetaLink or RB support[3]. Regards, Thierry [1] https://en.wikipedia.org/wiki/Aspect-oriented_programming [2] http://www.eclipse.org/aspectj/ [3] https://github.com/ThierryGoubier/Jejak
Re: [Pharo-dev] Spotter search pane does not support choose font by Settings
Hi, Doru and Marcus Thanks for your replies! I sometime create methods with Chinese method name or write my own comment in Chinese, so it is good for me if the font can be changed by Settings. Liang
Re: [Pharo-dev] Debugging and optimizations
Hi Torsten, Hi Ben, On Jun 12, 2015, at 2:49 PM, Torsten Bergmann asta...@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? Ben's reply reminded me of a prototype I did in VW that we never released that could be adapted. I added a ConstantBinding class alongside VariableBinding. The compiler accessed the value of the ConstantBinding directly instead of going through it. But the compiler included the ConstantBinding in the method's literals just as it includes the selectors of optimized messages such as ifTrue:. There was a convention whereby code could be recompiled after the values of ConstantBindings were evaluated during class initialization. It was something like initialize self recompileChangedConstantsAfter: [...] Assigning to a ConstantBinding raised a proceedable exception that was caught by recompileChangedConstantsAfter:, which would allow the assignment to proceed and add the ConstantBinding to a set. After the block had evaluated recompileChangedConstantsAfter: would use the ConstantBindings scopes (they need back pointers to their defining scopes) to find the set of methods that referred to ConstantBindings modified in the block and recompile them. Now if one used this scheme one could also modify the compiler to compile certain idioms specially. For example a ConstantBinding assigned a block, or a ConstantBinding assigned a Boolean flag. The key here is that the ConstantBinding included in the method's literals provides a way to quickly distinguish between a method merely making use of true or false and a method making optimized use of a flag in a ConstantBinding. - Any pointers on how Opal does optimizations? Do we have similar optimizations (removing code that could not be reached) that could be used. Remember that Opal, just like most Smalltalk compilers, optimizes ifTrue:, whileTrue:, and: at al. And just like my closure extension to the Squeak compiler Opal optimizes temp vars accessed in blocks but defined in outer scopes into copied variables if possible. - How do you usually deal with additional tracing code when you do not want to have too much runtime overhead. Thanks T.
[Pharo-dev] [pharo-project/pharo-core] c382a2: 50113
Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c382a23c017465341634981a1cca504ee73e1440 https://github.com/pharo-project/pharo-core/commit/c382a23c017465341634981a1cca504ee73e1440 Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-06-13 (Sat, 13 Jun 2015) Changed paths: A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version133_.st R Polymorph-Widgets.package/Pharo3UIThemeIcons.class/class/icons/radioSelectedForm.st R Polymorph-Widgets.package/Pharo3UIThemeIcons.class/class/icons/radioSelectedFormContents.st R Polymorph-Widgets.package/Pharo3UIThemeIcons.class/class/icons/radioUnselectedForm.st R Polymorph-Widgets.package/Pharo3UIThemeIcons.class/class/icons/radioUnselectedFormContents.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/class/private - icons/radioSelectedForm.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/class/private - icons/radioUnselectedForm.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/instance/forms/radioSelectedForm.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/instance/forms/radioUnselectedForm.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/instance/private - contents/radioSelectedFormContents.st R Polymorph-Widgets.package/PharoUIThemeIcons.class/instance/private - contents/radioUnselectedFormContents.st M Rubric.package/RubFindReplaceDialogWindow.class/README.md M Rubric.package/RubFindReplaceDialogWindow.class/definition.st M Rubric.package/RubFindReplaceDialogWindow.class/instance/user-interface/findTextFieldMorph.st M Rubric.package/RubFindReplaceDialogWindow.class/instance/user-interface/newFindTextEntryMorph.st M Rubric.package/RubFindReplaceService.class/README.md R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50112.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50113.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50112.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50113.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Edition.package/EditorFindReplaceDialogWindow.class/definition.st M Text-Edition.package/EditorFindReplaceDialogWindow.class/instance/user-interface/findTextFieldMorph.st M Text-Edition.package/EditorFindReplaceDialogWindow.class/instance/user-interface/newFindTextEntryMorph.st Log Message: --- 50113 15276 radioUnselectedFormContents and radioSelectedFormContents broken in Pharo3UIThemeIcons https://pharo.fogbugz.com/f/cases/15276 15766 remove explicit isKindOf: PluggableTextFieldMorph in rubric https://pharo.fogbugz.com/f/cases/15766 15767 remove explicit isKindOf: PluggableTextFieldMorph https://pharo.fogbugz.com/f/cases/15767 http://files.pharo.org/image/50/50113.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50113 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Detecting the context/producer of code change announcements
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.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: 2015-06-11 16:49 GMT+02:00 Ben Coman b...@openinworld.com mailto:b...@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.package/AltBrowser.class/class/registerOnSystemAnnouncements.st
Re: [Pharo-dev] EnableHaltOnce shortcut
On 12 Jun 2015, at 16:43, Sven Van Caekenberghe s...@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.warlou...@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
[Pharo-dev] Dead data in smalltalkhub, who has access to the mongodb?
https://pharo.fogbugz.com/default.asp?14968 Dead data in Smalltalkhub: VOMongoError: Lazy reference not found ShTeam: OID(3583374428) Someone with mongo access might want to check all references Stephan
[Pharo-dev] what is the simple way to get an input?
Hi I was reading a book that teaches programming in python and they have input(x) that requests inputs and stores it? What is our equivalent? Stef
Re: [Pharo-dev] [pharo-project/pharo-core] 7b783b: 50112
Le 12/6/15 22:22, Torsten Bergmann a écrit : 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! Martin :) Bye T.
Re: [Pharo-dev] EnableHaltOnce shortcut
Le 13/6/15 10:41, Franck Warlouzet a écrit : 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. which is totally true. So I would sawp and add haltOnce. People do not use it because they are not hacking in UI enough, Stef I will do your tip and duplicate the item now, thank you Ben. Cheers, Franck From: b...@openinworld.com Date: Sat, 13 Jun 2015 09:20:58 +0800 To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] EnableHaltOnce shortcut On Fri, Jun 12, 2015 at 9:40 PM, Franck Warlouzet franck.warlou...@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
Re: [Pharo-dev] what is the simple way to get an input?
Isn't it* userInput := UIManager default request: 'Enter whatever you want'* ? 2015-06-13 19:00 GMT+02:00 stepharo steph...@free.fr: Hi I was reading a book that teaches programming in python and they have input(x) that requests inputs and stores it? What is our equivalent? Stef
Re: [Pharo-dev] EnableHaltOnce shortcut
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: b...@openinworld.com Date: Sat, 13 Jun 2015 09:20:58 +0800 To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] EnableHaltOnce shortcut On Fri, Jun 12, 2015 at 9:40 PM, Franck Warlouzet franck.warlou...@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
Re: [Pharo-dev] Spotter search pane does not support choose font by Settings
Hello, Thanks for the report! We should add this as issues to the issue tracker (I guess one for Nautilus, one for Spotter) Marcus On 13 Jun 2015, at 13:26, lb liangbin...@126.com wrote: Hi, Pharo 5 and 4, Spotter search pane does not support choose font by Settings. Pharo 5 New Comment Pane too. AbstractNautilusUIbuildNewCommentText | scrolledText | scrolledText := self classCommentTextModel newScrolledText beForPlainText; withCommentAnnotation; beWrapped; yourself. . Have a good weekend Liang
Re: [Pharo-dev] Debugging and optimizations
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
[Pharo-dev] Spotter search pane does not support choose font by Settings
Hi, Pharo 5 and 4, Spotter search pane does not support choose font by Settings. Pharo 5 New Comment Pane too. AbstractNautilusUIbuildNewCommentText | scrolledText | scrolledText := self classCommentTextModel newScrolledText beForPlainText; withCommentAnnotation; beWrapped; yourself. . Have a good weekend Liang
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
On Sat, Jun 13, 2015 at 5:47 AM, Sean P. DeNigris s...@clipperadams.com wrote: 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... And/Or you could add Deprecated to the window title text. cheers -ben
Re: [Pharo-dev] Spotter search pane does not support choose font by Settings
Hi Liang, I do not quite understand what the issue is. Could you explain it in more details? Cheers, Doru On Sat, Jun 13, 2015 at 1:26 PM, lb liangbin...@126.com wrote: Hi, Pharo 5 and 4, Spotter search pane does not support choose font by Settings. Pharo 5 New Comment Pane too. AbstractNautilusUIbuildNewCommentText | scrolledText | scrolledText := self classCommentTextModel newScrolledText *beForPlainText;* withCommentAnnotation; beWrapped; yourself. . Have a good weekend Liang -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Debugging and optimizations
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
Re: [Pharo-dev] Magritte3 in Pharo 5.0
On 13/06/15 02:23, Sean P. DeNigris wrote: 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? Stable loads an old version of Grease Stephan
Re: [Pharo-dev] Magritte3 in Pharo 5.0
On 13/06/15 20:38, Stephan Eggermont wrote: On 13/06/15 02:23, Sean P. DeNigris wrote: 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? Stable loads an old version of Grease Do we need Pharo5.x platform everywhere now? Stephan
