- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Source code formatting guidelines

by stepharo

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 > > 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 kilon alios

definetly a very productive year, even I have managed although still very fresh to Pharo to make several contributions. The effort that all Pharoers put into this saga is all inspiring and there is still huge potential. Congratulations to all people involved and thank you for sharing your work for free and being commited to a new age of computing where a dialogue between the machine and the user is established. Happy new year to all, I wish health and happiness but most of all passion to keep exploring the wonderful universe we occupy in our brief life spans. On Mon, Dec 29, 2014 at 2:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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

A toast

by Esteban Lorenzano

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] What do you call someone who writes Pharo code?

by Sven Van Caekenberghe

Hilaire, > On 29 Dec 2014, at 12:21, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 28/12/2014 21:04, phil(a)highoctane.be a Ã©crit : >> >> Jokes aside, Pharo is solid for commercial work. >> > > It is crazy how it seems so successful in this particular area. I have a hard time interpreting this remark as positive. Why do you say that is 'crazy' ? Why do you say 'seems' ? Why do you say 'this particular area' ? Sven

Dec. 29, 2014

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

by Marcus Denker

> On 19 Dec 2014, at 14:08, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Issue > 10529 <https://pharo.fogbugz.com/default.asp?10529> > ToolRegistry need to support multiple registrations per tool > > My solution : > A ToolRegistry subclass (PharoCommonTools) that memorized all registered tools. > And, for some common tools, like browser, debugger, inspector, workspace, > it provides settings entry to reset the registration to a prior tool. > > What do you think? > Yes, we should add thatâ¦ this way people can change the tools easily. We can then later improve the implementationâ¦ Marcus

Dec. 29, 2014