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

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

Re: [Pharo-dev] What do you call someone who writes Pharo code?

by Hilaire

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. -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 29, 2014

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

by Marcus Denker

> 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

[pharo-project/pharo-core]

by GitHub

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

Dec. 29, 2014

[pharo-project/pharo-core] 7d7819: 40424

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 7d781953a1b256775b2c900a6fd280ba84923c1f https://github.com/pharo-project/pharo-core/commit/7d781953a1b256775b2c900a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-29 (Mon, 29 Dec 2014) Changed paths: A Compiler.package/BytecodeEncoder.class/class/bytecode decoding/stackDeltaForPrimitive_in_.st A Compiler.package/BytecodeEncoder.class/instance/opcode sizing/sizeTrapIfNotInstanceOf_.st A Compiler.package/Decompiler.class/instance/instruction decoding/blockReturnConstant_.st R Compiler.package/Decompiler.class/instance/private/interpretNextInstructionFor_.st A Compiler.package/EncoderForSistaV1.class/README.md A Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/callPrimitiveCode.st A Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/pcOfBlockCreationBytecodeForBlockStartingAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/pushClosureBytecodeSize.st A Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/stackDeltaForPrimitive_in_.st A Compiler.package/EncoderForSistaV1.class/class/bytecode decoding/unusedBytecode.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/bindingReadScanBlockFor_using_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/bindingWriteScanBlockFor_using_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/createClosureScanBlock.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/extensionsAt_in_into_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/instVarReadScanBlockFor_using_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/instVarWriteScanBlockFor_using_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/interpretJumpIfCondIn_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/interpretJumpIn_.st A Compiler.package/EncoderForSistaV1.class/class/compiled method support/supportsClosures.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/bytecodeSize_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/interpretNextInstructionFor_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isBlockReturnAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isBranchIfFalseAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isBranchIfTrueAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isExtension_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isJumpAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isJustPopAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isRealSendAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isReturnAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isReturnTopFromMethodAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isSendAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isStoreAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/isStorePopAt_in_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/selectorToSendOrItselfFor_in_at_.st A Compiler.package/EncoderForSistaV1.class/class/instruction stream support/superSendScanBlockUsing_.st A Compiler.package/EncoderForSistaV1.class/class/scanning/method_refersInBytecodeToLiteral_specialSelectorIndex_.st A Compiler.package/EncoderForSistaV1.class/definition.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genBranchPopFalseLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genBranchPopFalse_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genBranchPopTrueLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genBranchPopTrue_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genCallInlinePrimitive_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genCallPrimitive_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genDup.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genJumpLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genJump_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genNop.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPop.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushCharacter_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushClosureCopyNumCopiedValues_numArgs_jumpSize_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushConsArray_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushInstVarLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushInstVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushInteger_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushLiteralVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushLiteral_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushNewArray_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushReceiver.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushRemoteTemp_inVectorAt_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushSpecialLiteral_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushTemp_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genPushThisContext.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genReturnReceiver.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genReturnSpecialLiteral_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genReturnTop.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genReturnTopToCaller.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genSendSpecial_numArgs_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genSendSuper_numArgs_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genSend_numArgs_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genSignedSingleExtendB_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStoreInstVarLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStoreInstVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStoreLiteralVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStorePopInstVarLong_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStorePopInstVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStorePopLiteralVar_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStorePopRemoteTemp_inVectorAt_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStorePopTemp_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStoreRemoteTemp_inVectorAt_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genStoreTemp_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genTrapIfNotInstanceOf_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genUnsignedMultipleExtendA_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genUnsignedSingleExtendA_.st A Compiler.package/EncoderForSistaV1.class/instance/bytecode generation/genUnsignedSingleExtendB_.st A Compiler.package/EncoderForSistaV1.class/instance/in-line primitive generation/genInlineSmallIntegerAdd.st A Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretJumpIfCondIn_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretJumpIn_.st A Compiler.package/EncoderForV3PlusClosures.class/class/instructionStream support/interpretNextInstructionFor_in_.st A Kernel.package/BlockLocalTempCounter.class/instance/instruction decoding/blockReturnConstant_.st M Kernel.package/CompiledMethod.class/instance/accessing/defaultSelector.st A Kernel.package/CompiledMethod.class/instance/accessing/encoderClass.st A Kernel.package/CompiledMethod.class/instance/accessing/signFlag.st A Kernel.package/Context.class/instance/instruction decoding/blockReturnConstant_.st A Kernel.package/Context.class/instance/instruction decoding/pushClosureTemps_.st A Kernel.package/InstructionClient.class/instance/instruction decoding/blockReturnConstant_.st A Kernel.package/InstructionClient.class/instance/instruction decoding/pushActiveProcess.st A Kernel.package/InstructionClient.class/instance/instruction decoding/pushClosureTemps_.st A Kernel.package/InstructionClient.class/instance/instruction decoding/trap.st A Kernel.package/InstructionClient.class/instance/instruction decoding/trapIfNotInstanceOf_.st M Kernel.package/InstructionStream.class/instance/decoding/interpretJump.st M Kernel.package/InstructionStream.class/instance/decoding/interpretJumpIfCond.st A Kernel.package/InstructionStream.class/instance/decoding/interpretNext2ByteSistaV1Instruction_for_extA_extB_startPC_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretNext3ByteSistaV1Instruction_for_extA_extB_startPC_.st M Kernel.package/InstructionStream.class/instance/decoding/interpretNextInstructionFor_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretNextSistaV1InstructionFor_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretNextV3PlusClosureInstructionFor_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretSistaV1ExtendedPush_for_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretSistaV1Jump.st A Kernel.package/InstructionStream.class/instance/decoding/interpretSistaV1JumpIfCond.st A Kernel.package/InstructionStream.class/instance/decoding/interpretV3PlusClosureExtension_in_for_.st A Kernel.package/InstructionStream.class/instance/decoding/interpretV3PlusClosureJump.st A Kernel.package/InstructionStream.class/instance/decoding/interpretV3PlusClosureJumpIfCond.st R Kernel.package/InstructionStream.class/instance/private/interpretExtension_in_for_.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/blockReturnConstant_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushActiveContext.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushActiveProcess.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushClosureTemps_.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/trap.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/trapIfNotInstanceOf_.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/tests - instructions/testPushThisContext.st A OpalDecompiler.package/OCDecompiler.class/instance/instruction decoding/blockReturnConstant_.st R OpalDecompiler.package/OCDecompiler.class/instance/private/interpretNextInstructionFor_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script424.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40424.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40424 14659 Integrating new bytecode set (part 1) https://pharo.fogbugz.com/f/cases/14659 14660 one test failing after integrating 14659 https://pharo.fogbugz.com/f/cases/14660 http://files.pharo.org/image/40/40424.zip

Dec. 29, 2014

Re: [Pharo-dev] Source code formatting guidelines

by Udo Schneider

On 29/12/14 08:54, stepharo wrote: > > Le 19/11/14 15:19, Nicolai Hess a Ã©crit : >> 2014-11-19 14:55 GMT+01:00 Marcus Denker >> <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>>: >> >> >>> On 19 Nov 2014, at 14:47, Peter UhnÃ¡k >>> <i.uhnak(a)gmail.com >>> <mailto:i.uhnak@gmail.com>> wrote: >>> >>> how Pharo source code is formatted >>> >>> One could argue that this is equivalent to the default settings >>> of Pharo formatter. >> >> Which is not goodâ¦ e.g. it always adds too many line breaksâ¦ >> >> Marcus >> >> >> If we can agree on source code guidelines, we should change the >> default settings of the Pharo formatter accordingly. > Yes I would love that. I nearly like the default formatter except that > sometimes it creates too > many line breaks. 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" :-) 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. Especially as the format hotkey doesn't work reliably on Mac OS X - still have to chase why. > And concretely I would like to format all the code. I'm doing that when > I change something. CU, Udo

Dec. 29, 2014