- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/labe… 1 regressions found. KernelTests.Exception.ExceptionTests.testNoTimeout

Oct. 17, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 17, 2013

[pharo-project/pharo-core] 4d6fe6: 30493

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4d6fe600f69e350d0a75d2710dd896e8e844fc83 https://github.com/pharo-project/pharo-core/commit/4d6fe600f69e350d0a75d271… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-16 (Wed, 16 Oct 2013) Changed paths: M Kernel-Methods.package/CompiledMethod.class/instance/accessing/category.st M Morphic-Base-MorphTreeWidget.package/MorphTreeModel.class/definition.st A Morphic-Base-MorphTreeWidget.package/MorphTreeModel.class/instance/accessing/disable.st A Morphic-Base-MorphTreeWidget.package/MorphTreeModel.class/instance/accessing/enable.st A Morphic-Base-MorphTreeWidget.package/MorphTreeModel.class/instance/accessing/enabled.st A Morphic-Base-MorphTreeWidget.package/MorphTreeModel.class/instance/accessing/enabled_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/definition.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/accessing/disable.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/accessing/enable.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/accessing/enabled.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/accessing/enabled_.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/accessing/fillStyleToUse.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/events-processing/mouseDown_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/events-processing/mouseMove_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/events-processing/mouseUp_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/events-processing/takesKeyboardFocus.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/selection/selectionColorToUse.st A Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/updating/enabledFromModel.st M Morphic-Base-MorphTreeWidget.package/MorphTreeMorph.class/instance/updating/update_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeNodeMorph.class/instance/mouse events/handleMouseUp_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeNodeMorph.class/instance/mouse events/mouseDown_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeTransformMorph.class/instance/drawing/drawRawColorOn_forSubmorph_.st M Morphic-Base-MorphTreeWidget.package/MorphTreeTransformMorph.class/instance/drawing/drawSubmorphsOn_.st R Refactoring-Core-Refactorings.package/RBMoveMethodRefactoring.class/instance/transforming/compileDelagatorMethod.st A Refactoring-Core-Refactorings.package/RBMoveMethodRefactoring.class/instance/transforming/compileDelegatorMethod.st M Refactoring-Core-Refactorings.package/RBMoveMethodRefactoring.class/instance/transforming/transform.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script148.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30493.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SystemDictionary.class/instance/classes and traits/allBehaviors.st A System-Support.package/SystemNavigation.class/instance/query/allBehaviors.st M System-Support.package/SystemNavigation.class/instance/query/allMethods.st R Tests-Release.package/ReleaseTest.class/instance/testing/testKernelExtensions.st R Tools-Browser.package/extension/SystemNavigation/instance/browseAllUnimplementedCalls.st M Tools-FileList.package/FileList.class/class/file reader registration/allRegisteredServices.st Log Message: ----------- 30493 11912 faster #allMethods on SystemNavigation https://pharo.fogbugz.com/f/cases/11912 11894 Tests.Release.ReleaseTest.testKernelExtensions fails https://pharo.fogbugz.com/f/cases/11894 11909 MorphTreeMorph lacks enable/disable https://pharo.fogbugz.com/f/cases/11909 11886 Typo at method name: RBMoveMethodRefactor>>compileDelagatorMethod https://pharo.fogbugz.com/f/cases/11886 http://files.pharo.org/image/30/30493.zip

Oct. 17, 2013

Re: [Pharo-dev] Old Compiler is now unload able!

by Marcus Denker

On Oct 17, 2013, at 7:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now have a look at Opal and help us making better because there are still edge corners and little bugs. > The most important thing to understand is that Opal is not perfectâ¦ it's just a little bit better than the old compiler. The idea is not perfection (because is does not exist), but to just have some infrastructure that allows us to build on top. (e.g. reviving the old Reflectivity stuff, as one example). For bugs, we have - temps defined in ifTrue: are compiled with the wrong offset in some case (I think when there are other blocks defining a temp with the same name) - Christoph saw some case with problems in to:do: but I have not yet been able to even find an example to re-create the problem - when stepping in the debugger, temp vars are sometimes looked up in the wrong scope. I think this has to do with #stepToSendOrReturn when you are entering a block will run until the first send of the new block, which is too far. For improvements: -> IR instruction should store *range* of the bc offset they generate, as they can generate more than one (this would simplify finding an IR instruction for a pc offset when doing bc->text mapping for the debugger) -> IRIntepreter should be an IRVisitor, clean up the dual visiting/interpreting interface -> Semantic analysis: TempVars should not have index (it is left over from pre-closure times and only used for sorting the variables at the end), Sub=case: Decide which implementation of a sorted dictionary to integrate in Pharo3 Big picture (unlikely to happen) --------------- -> move all optimzations to the IR level (Controll Flow Graph) -> same for some of the analysis related to blocks (e.g. detecting escaping writes in loops should much more beautiful of a CFG than the AST). But then, it works even if is a bit convoluted now. After getting rid of old Compiler ------------------------------------------ -> remove #failBlock: -> compiler should not care about #category, it only compiles. -> all users of RBScanner and RBParser should use the OpalCompiler facade or APIs on CompiledMethod (#ast). (this will allow us to replace the RBParser as we like, e.g. to experiment with PetitParser)

Oct. 17, 2013

Re: [Pharo-dev] Old Compiler is now unload able!

by StÃ©phane Ducasse

Now have a look at Opal and help us making better because there are still edge corners and little bugs. Stef On Oct 16, 2013, at 10:21 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > And for the curious my favourite brainfuck was code:type: and its senders. > > Because the first time you read (code: index type: type), you wonder > * why you pass a parameter index (that overrides inst var index, but most caller invoke with index inst. var.) > * with the key code: > * since there is also an inst var named code that's really troubling... > Also because there is a cryptic use of negated type on return > And once you start analyzing senders, and inst var refs, you're puzzled... > > To decipher, code:type: answers an encoded bytecode, made from an index (temp index, inst var index etc..) and a type (load inst var, load temp var, etc...) thus its name code... > Now, I've contemplated this code too much, and it almost sounds familiar, I can hardly remember how impenetrable it was. But make you a pleasure, put a newbie in front of it. > > To me, this a a very clever factorisation of bytecode encoding - much too clever - much too obfuscated - and I bet we can do much much clearer with not much more code. > But I don't have to prove anything, there is Opal already... > > > > 2013/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Too bad :( > > One of the most brilliant anti-pattern onto which I burnt so many brain cells is gone, > > how are we going to teach good coding practices by counter examples. > > ;) > > :) > We should continue to build the new generation it is more exciting and now I can start to invest in reading > the compiler code. > > Stef >

Oct. 17, 2013

Re: [Pharo-dev] [OT] Free pie for Pharo?

by btc＠openinworld.com

Torsten Bergmann wrote: > https://raymii.org/s/static/Free_Raspberry_Pi.html > > > GPL

Oct. 17, 2013

Re: [Pharo-dev] https://pharo.fogbugz.com ??

by Alexandre Bergel

Thanks! I can log in now Cheers, Alexandre On Oct 16, 2013, at 12:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > abergel wrote >> How can I create a login on https://pharo.fogbugz.com ? >> I have created a login on bugs.pharo.org. I am not sure how does this >> differ from the fogbugz... > > The login you created should work for fogbugz. Now that we have a permalink > to the registration page, I've added it to the fogbugz welcome page. HTH > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/https-pharo-fogbugz-com-tp4714366p4715016.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 16, 2013

[OT] Free pie for Pharo?

by Torsten Bergmann

https://raymii.org/s/static/Free_Raspberry_Pi.html

Oct. 16, 2013

Re: [Pharo-dev] Old Compiler is now unload able!

by Nicolas Cellier

And for the curious my favourite brainfuck was code:type: and its senders. Because the first time you read (code: index type: type), you wonder * why you pass a parameter index (that overrides inst var index, but most caller invoke with index inst. var.) * with the key code: * since there is also an inst var named code that's really troubling... Also because there is a cryptic use of negated type on return And once you start analyzing senders, and inst var refs, you're puzzled... To decipher, code:type: answers an encoded bytecode, made from an index (temp index, inst var index etc..) and a type (load inst var, load temp var, etc...) thus its name code... Now, I've contemplated this code too much, and it almost sounds familiar, I can hardly remember how impenetrable it was. But make you a pleasure, put a newbie in front of it. To me, this a a very clever factorisation of bytecode encoding - much too clever - much too obfuscated - and I bet we can do much much clearer with not much more code. But I don't have to prove anything, there is Opal already... 2013/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Too bad :( > > One of the most brilliant anti-pattern onto which I burnt so many brain > cells is gone, > > how are we going to teach good coding practices by counter examples. > > ;) > > :) > We should continue to build the new generation it is more exciting and now > I can start to invest in reading > the compiler code. > > Stef >

Oct. 16, 2013

Re: [Pharo-dev] default monospaced code font

by Norbert Hartl

Am 16.10.2013 um 21:43 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Very good comparison, thanks! > Source code pro is so disgracious to my eyes, I can't stand it. > Source code sans 10 not that bad. > But my old eyes are much more comfortable with dejaVu, even if less code fits. > +1 to every sentence Norbert > > 2013/10/16 <btc(a)openinworld.com> > Goubier Thierry wrote: > > > Le 16/10/2013 11:50, Sven Van Caekenberghe a Ã©crit : > > On 16 Oct 2013, at 10:20, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > Interesting display, Sven. > > My take on that: > > * Aesthetics: the system has two fonts, not one. -1 if I review a document with more than one font. > > In all documents, you have at least two fonts: body and headings, often quotes, examples, listings, etc have an another font to make them stand out. In the new approach, the idea is that monospaced fonts indicate code (in browsers, debuggers, workspaces). It is a useful principle. > > You're right. But nobody would dare write headings in a monospaced font :) unless for an art project. > > * Coherence / uniformity: A class name, a method selector has a different shape in the GUI (proportional) than in the code (monospaced). Are they different objects? Can I recognize my class name in the code without reading it? > > Syntax highlighting should take care of that I guess. > > I don't think so. This is no by making the selector green that it will look more like the proportional version in the pane above. > > Kind of disrupting the uniformity of the underlying model, when I'm pushing for things like smart suggestions where the GUI understands the objects written in the code. > > I think that if the monospaced font is a point size smaller that the main sans font (e.g. 12 and 11) the excessive width problem or visual shock is much more manageable. In any case, I am giving it a try. > > Probably. But then individual characters may become harder to read and distinguish... sort of compromising character readability to make space for the added whitespace inherent to the monospaced font. > > I'd be more impressed if the argument was helping me distinguish between | and l. > > Yes. It is designed to do that. Some common failings of monospaced fonts are noted [1] and dealt with. There comment section is also interesting. > > The attached PDFs are the result of getting the urge to compare a broad coverage of code examples (taken from "Terse Guide to Squeak") against three fonts: > * DejaVu Sans 9 point > * Source Code Pro [1] [2] 9 point > * Source Sans Pro [3] [4] 9 point & 10 point, since the width of 10 was the same as the others at 9. > Also attached is the source excel file. > > cheers -ben > > [1] http://blogs.adobe.com/typblography/2012/09/source-code-pro.html > [2] http://sourceforge.net/projects/sourcecodepro.adobe/files/ > [3] http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html > [4] http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp > > > I'l let you try, then :) > > Thierry > >

Oct. 16, 2013