December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Jun4Pharo so exciting :)

by Sven Van Caekenberghe

> On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr> wrote: > > https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be It certainly looks nice, but what is Jun exactly ?

Dec. 29, 2014

Re: [Pharo-dev] ToolRegistry need to support multiple registrations per tool

by stepharo

Yes less is more ;) Le 29/12/14 12:20, Marcus Denker a Ã©crit : >> On 19 Dec 2014, at 16:21, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> There used to be a class called AppRegistry in Pharo, which was nothing more than a selection in a list, with an API's for adding/removing options and changing the current selection. (only through popups, but that could easily be extended to provide settings entries). The code might've needed a bit of cleanup (making collection of available options weak, for example), but the concept was sound. >> >> IMHO, rather than the delegation through ToolRegistry, it would've been nice to have built upon AppRegistry and have Inspector/Browser/Debugger as subclasses of that. >> Then you'd still maintain indirection of which ToolX are available / currently in use, and code would be nice and understandable like: >> ToolX open instead of >> ToolRegistry openToolX. >> >> When new tools classifications are added, you'd also avoid progressively extending ToolRegistry into a behemoth of #openToolX etc. methods (ref. UIManager). >> >> Sadly, SoundService was the only real App classification in use, and the code seems to have been removed in 4.0. >> > In retrospect, maybe I should have unified towards the AppRegistryâ¦ but on the other hand, the good thing is that we now have *one* mechanism, not 2-and-a-half > mixed like it used to be. This means we can replace/enhance it as neededâ¦ > > Marcus > > >

Dec. 29, 2014

Re: [Pharo-dev] Source code formatting guidelines

by Marcus Denker

> On 29 Dec 2014, at 15:30, stepharo <stepharo(a)free.fr> wrote: > > As far as I remember it was just the stock RB(Configurable?)Formatter with custom settings. Let me dig out my Dolphin Image. > > This is the same in Pharo. Lukas improved it. I think the âtoo many line breaksâ is actually a bug. It adds line breaks where it should not. >> >>>> >>>> Especially as the format hotkey doesn't work reliably on Mac OS X - >>>> still have to chase why. >>> >>> Yes I would like to have. >>> >>>> >>>>> And concretely I would like to format all the code. I'm doing that when >>>>> I change something. >>>> >>>> CU, >>>> >>>> Udo >> >> >> >> >> > >

Dec. 29, 2014

Jun4Pharo so exciting :)

by stepharo

https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be

Dec. 29, 2014

Re: [Pharo-dev] A toast

by stepharo

Thanks! http://pharoweekly.wordpress.com/2014/12/29/a-toast/ Le 29/12/14 13:59, Esteban Lorenzano a Ã©crit : > Hello Pharoers, > > (sorry for the long post) > > I'm on holidays so I've been silent this latests days, but I didn't want to let the opportunity goes to propose a toast :) > This year has been a great year (yeah, but not like those annoying facebook cards), one year where we have worked itensively in the patient consolidation of several lines of work. > This has been possible thanks to the great improvement that we have made in the Pharo process itself, which required (and still requires) a massive amount of effort: Since I arrived here (but not necessarily*because* I arrived here: this is the work of everyone in Pharo community, I'm just pointing to what I've seen and collaborated :P), we have changed a lot of things: > > - we have deployed a solid CI infrastructure that can handle our integration cycle without too much complications. Even if we still find problems time to time, this has been an incredible step forward. > - thanks to this we have been able to change our release cycle from "it happens when we believe is ready" to time-boxed releases, so we have created Pharo 1.4, 2.0 and this year what, for me, is one of the most complete and cool releases (up to now) that we have produced: Pharo 3.0. > - We have increased massively the amount of tests in the system (no sure what is the percentage, but is high), so we have been able to change core parts in the system without causing too much pain to developers (yeah, we know there have been some errors some times, but well... "errare humanum est", and I think we have learned from the process and now we do not make same mistakes... in any case they are new mistakes :P). > - We have made huge steps in the "Pharo modularisation project", thanks to the Pharo-minimal images and work we have started to move all into a repeatable configuration (thanks to metacello and tools developed for this). > - We have also incorporated the VM building to this process and testing cycle, so is a lot easier for everyone to build their own VM (if needed), and for us we can be sure (as sure as possible at least) VM is in good shape. > - We have improved documentation and release new books. People have working a lot in a lot of cool and instructive videos that have moved our "learning curve" several steps ahead. > > And this is just one part of the "invisible, ant work of everyday", in the visible part, I will not bore (more than needed :P) with details about previous releases, so I will just point some of the great things we have made for the upcoming release, Pharo 4: > > - Thanks to GTools, we are slowly going to a better set of tools, with new ways of see/handle old things. This is the most visible change this year (and it has caused the most flamed wars, but well... we are a passionate community). This release we have a new inspector, playground and spotter (god, spotter is sooooo cool!), next release we hope to integrate a new debugger and if planets align, a new Coder. > - We introduced OSWindow as a preview, a tool which will allow us to do a lot of years waited features: start UI from image instead from VM (transmiting to the used the decision of having one or not), multi-windows, a vectorial UI instead the good-but-old bitblt we have now. > - We enhanced Athens and introduced the new TxModel. We still do now achieve our objective of migrate our morphic drawing mechanism to athens, but this is a lot of work and will take some time. > - We have improved a lot the development cycle with the introduction of smart suggestions, the upcoming smart breakpoins and reflectivity. > - And of course, we have worked a lot in the cleaning of the system (an invisible and ungrateful work, believe me) > > And this is just a glimpse, what I wrote this morning before breakfast, wanting to thank all of you to let me be part of this super cool community, and wanting to have a toast with you: > > For a 2015 with more stories, more adventures, more Pharo! > > Esteban >

Dec. 29, 2014

Re: [Pharo-dev] Source code formatting guidelines

by stepharo

As far as I remember it was just the stock RB(Configurable?)Formatter with custom settings. Let me dig out my Dolphin Image. This is the same in Pharo. Lukas improved it. > >>> >>> Especially as the format hotkey doesn't work reliably on Mac OS X - >>> still have to chase why. >> >> Yes I would like to have. >> >>> >>>> And concretely I would like to format all the code. I'm doing that >>>> when >>>> I change something. >>> >>> CU, >>> >>> Udo > > > > >

Dec. 29, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 29, 2014

[pharo-project/pharo-core] e7f06f: 40425

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e7f06ff141a19305077d05c9c31c9dbf1665da66 https://github.com/pharo-project/pharo-core/commit/e7f06ff141a19305077d05c9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-29 (Mon, 29 Dec 2014) Changed paths: M Compiler.package/Decompiler.class/instance/control/doClosureCopyCopiedValues_numArgs_blockSize_.st A Compiler.package/EncoderForSistaV1.class/class/block closure support/numLocalTempsForBlockAt_in_.st R Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/pcOfBlockCreationBytecodeForBlockStartingAt_in_.st R Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/pushClosureBytecodeSize.st M Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/unusedBytecode.st R Compiler.package/EncoderForSistaV1.class/class/compiled method support/createClosureScanBlock.st R Compiler.package/EncoderForSistaV1.class/class/compiled method support/interpretJumpIfCondIn_.st R Compiler.package/EncoderForSistaV1.class/class/compiled method support/interpretJumpIn_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/interpretJumpIfCondIn_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/interpretJumpIn_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isCreateBlockAt_in_.st A Compiler.package/EncoderForV3.class/class/compiled method support/supportsClosures.st A Compiler.package/EncoderForV3PlusClosures.class/class/block closure support/numLocalTempsForBlockAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/bytecode decoding/callPrimitiveCode.st A Compiler.package/EncoderForV3PlusClosures.class/class/bytecode decoding/stackDeltaForPrimitive_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/bytecode decoding/unusedBytecode.st A Compiler.package/EncoderForV3PlusClosures.class/class/compiled method support/bindingReadScanBlockFor_using_.st A Compiler.package/EncoderForV3PlusClosures.class/class/compiled method support/bindingWriteScanBlockFor_using_.st A Compiler.package/EncoderForV3PlusClosures.class/class/compiled method support/instVarReadScanBlockFor_using_.st A Compiler.package/EncoderForV3PlusClosures.class/class/compiled method support/instVarWriteScanBlockFor_using_.st A Compiler.package/EncoderForV3PlusClosures.class/class/compiled method support/supportsClosures.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/bytecodeSize_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/interpretJumpIfCondIn_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/interpretJumpIn_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/interpretNextInstructionFor_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isBlockReturnAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isBranchIfFalseAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isBranchIfTrueAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isCreateBlockAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isJumpAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isJustPopAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isReturnAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isSendAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isStoreAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/isStorePopAt_in_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instruction stream support/selectorToSendOrItselfFor_in_at_.st R Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretJumpIfCondIn_.st R Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretJumpIn_.st R Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretNextInstructionFor_in_.st M Kernel.package/BlockClosure.class/instance/accessing/numLocalTemps.st M Kernel.package/CompiledMethod.class/instance/scanning/readsField_.st M Kernel.package/CompiledMethod.class/instance/scanning/readsRef_.st M Kernel.package/CompiledMethod.class/instance/scanning/writesField_.st M Kernel.package/CompiledMethod.class/instance/scanning/writesRef_.st A Kernel.package/Context.class/instance/instruction decoding/pushActiveProcess.st M Kernel.package/InstructionStream.class/instance/private/nextPc_.st M Kernel.package/InstructionStream.class/instance/scanning/selectorToSendOrSelf.st M Kernel.package/InstructionStream.class/instance/scanning/skipBackBeforeJump.st M Kernel.package/InstructionStream.class/instance/testing/willBlockReturn.st M Kernel.package/InstructionStream.class/instance/testing/willCreateBlock.st M Kernel.package/InstructionStream.class/instance/testing/willJump.st M Kernel.package/InstructionStream.class/instance/testing/willJumpIfFalse.st M Kernel.package/InstructionStream.class/instance/testing/willJumpIfTrue.st M Kernel.package/InstructionStream.class/instance/testing/willJustPop.st M Kernel.package/InstructionStream.class/instance/testing/willReturn.st M Kernel.package/InstructionStream.class/instance/testing/willSend.st M Kernel.package/InstructionStream.class/instance/testing/willStore.st M Kernel.package/InstructionStream.class/instance/testing/willStorePop.st M OpalDecompiler.package/OCDecompiler.class/instance/control/doClosureCopyCopiedValues_numArgs_blockSize_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script425.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40425.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40425 14661 Integrating new bytecode set (part 2) Make CompiledMethod, InstructionStream and Decompiler independent from bytecode set https://pharo.fogbugz.com/f/cases/14661 http://files.pharo.org/image/40/40425.zip

Dec. 29, 2014

Re: [Pharo-dev] Source code formatting guidelines

by Udo Schneider

On 29/12/14 14:32, stepharo wrote: > I'm still missing the RB based formatter in Dolphin. It's comparable to > the Pharo one (layout wise) but created less "line-break-noise" :-) > > ;-) > I think that it should not be that difficult to arrive to a good compromise > >> It should be easy create an RBFormatter with the same settings in >> Dolphin to. But the current format didn't yet annoy me enough to >> transfer it. >> >>> What we could do is to build a sample and go over it. >>> Ideally I would like to have formatting as you type :). >> Even something simple like automatic "format-on-save" (optionally) >> would help IMHO. > > Yes if you send code we will add it because I would like to give a try As far as I remember it was just the stock RB(Configurable?)Formatter with custom settings. Let me dig out my Dolphin Image. >> >> Especially as the format hotkey doesn't work reliably on Mac OS X - >> still have to chase why. > > Yes I would like to have. > >> >>> And concretely I would like to format all the code. I'm doing that when >>> I change something. >> >> CU, >> >> Udo

Dec. 29, 2014

Re: [Pharo-dev] A toast

by phil＠highoctane.be

Le 29 dÃ©c. 2014 13:59, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > Hello Pharoers, > > (sorry for the long post) > > I'm on holidays so I've been silent this latests days, but I didn't want to let the opportunity goes to propose a toast :) > This year has been a great year (yeah, but not like those annoying facebook cards), one year where we have worked itensively in the patient consolidation of several lines of work. > This has been possible thanks to the great improvement that we have made in the Pharo process itself, which required (and still requires) a massive amount of effort: Since I arrived here (but not necessarily *because* I arrived here: this is the work of everyone in Pharo community, I'm just pointing to what I've seen and collaborated :P), we have changed a lot of things: > > - we have deployed a solid CI infrastructure that can handle our integration cycle without too much complications. Even if we still find problems time to time, this has been an incredible step forward. > - thanks to this we have been able to change our release cycle from "it happens when we believe is ready" to time-boxed releases, so we have created Pharo 1.4, 2.0 and this year what, for me, is one of the most complete and cool releases (up to now) that we have produced: Pharo 3.0. > - We have increased massively the amount of tests in the system (no sure what is the percentage, but is high), so we have been able to change core parts in the system without causing too much pain to developers (yeah, we know there have been some errors some times, but well... "errare humanum est", and I think we have learned from the process and now we do not make same mistakes... in any case they are new mistakes :P). > - We have made huge steps in the "Pharo modularisation project", thanks to the Pharo-minimal images and work we have started to move all into a repeatable configuration (thanks to metacello and tools developed for this). > - We have also incorporated the VM building to this process and testing cycle, so is a lot easier for everyone to build their own VM (if needed), and for us we can be sure (as sure as possible at least) VM is in good shape. > - We have improved documentation and release new books. People have working a lot in a lot of cool and instructive videos that have moved our "learning curve" several steps ahead. > > And this is just one part of the "invisible, ant work of everyday", in the visible part, I will not bore (more than needed :P) with details about previous releases, so I will just point some of the great things we have made for the upcoming release, Pharo 4: > > - Thanks to GTools, we are slowly going to a better set of tools, with new ways of see/handle old things. This is the most visible change this year (and it has caused the most flamed wars, but well... we are a passionate community). This release we have a new inspector, playground and spotter (god, spotter is sooooo cool!), next release we hope to integrate a new debugger and if planets align, a new Coder. > - We introduced OSWindow as a preview, a tool which will allow us to do a lot of years waited features: start UI from image instead from VM (transmiting to the used the decision of having one or not), multi-windows, a vectorial UI instead the good-but-old bitblt we have now. > - We enhanced Athens and introduced the new TxModel. We still do now achieve our objective of migrate our morphic drawing mechanism to athens, but this is a lot of work and will take some time. > - We have improved a lot the development cycle with the introduction of smart suggestions, the upcoming smart breakpoins and reflectivity. > - And of course, we have worked a lot in the cleaning of the system (an invisible and ungrateful work, believe me) > > And this is just a glimpse, what I wrote this morning before breakfast, wanting to thank all of you to let me be part of this super cool community, and wanting to have a toast with you: > > For a 2015 with more stories, more adventures, more Pharo! Pharo has made 2014 very interesting for me and I was able to build decent business with it. I hope to make that grow further in 2015. Pharo is powerful and is fun to use. Let's get to the next level! Phil > > Esteban > >

Dec. 29, 2014