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

Fwd: [Amber list]: Importing Data from Pharo

by Sean P. DeNigris

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 < > sean@ > > > 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.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 13, 2015

Re: [Pharo-dev] Spotter search pane does not support choose font by Settings

by lb

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

June 13, 2015

[pharo-project/pharo-core]

by GitHub

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

June 13, 2015

[pharo-project/pharo-core] c382a2: 50113

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c382a23c017465341634981a1cca504ee73e1440 https://github.com/pharo-project/pharo-core/commit/c382a23c017465341634981a… Author: Jenkins Build Server <board(a)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

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Eliot Miranda

Hi Torsten, Hi Ben, 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? 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. >

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by Thierry Goubier

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

June 13, 2015

Re: [Pharo-dev] Debugging and optimizations

by ClÃ©ment Bera

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.denker(a)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 >

June 13, 2015

Re: [Pharo-dev] Spotter search pane does not support choose font by Settings

by Marcus Denker

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 <liangbing64(a)126.com> wrote: > > 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] Spotter search pane does not support choose font by Settings

by Tudor Girba

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 <liangbing64(a)126.com> wrote: > 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 > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 13, 2015

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

by Ben Coman

On Sat, Jun 13, 2015 at 5:47 AM, Sean P. DeNigris <sean(a)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

June 13, 2015