- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Source code formatting guidelines

by stepharo

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. What we could do is to build a sample and go over it. Ideally I would like to have formatting as you type :). And concretely I would like to format all the code. I'm doing that when I change something.

Dec. 29, 2014

Re: [Pharo-dev] The Smalltalk Renaissance Program

by stepharo

Guys you make me laugh. We built pharo to reinvent smalltalk (Since day one) and many people shout and cry because we do not want to say that this is a smalltalk and because it is not compatible. Now suddenly you show up (we pushed ESUG since 15 years BTW) telling us that we should all aggregate under the renaissance program (without really knowing what we are deeply doing) and now you criticize that nobody on Smalltalk is doing innovation. So let me tell you this: - adhesion and trust is based on actions in open-source world (So the ball is in your camp). - if I would have got the money that alan got for his projects, Pharo would not be like it is now but way better. There is a pharo roadmap (you may find it interesting) and we are steadily addressing it. We should write the new version of the Pharo vision. - Pharo is not Smalltalk and we are doing it our way. We want to make sure that people can get a living building applications with Pharo. - We are not just creating a language. We are creating an ecosystem with companies and universities. Here my piece of advices: - doing takes a lot more energy than talking, so think in terms of milestones: "what should I do if I do not get the energy to push it during years?" - there are plenty of ways to help but you have to decide. What you want to do. -- reading books -- writing tutorials -- blogging (but I agree I always pay attention about what I blog/twit) -- develop libraries Stef Le 29/12/14 01:36, horrido a Ã©crit : > Bret Victor's talk is certainly interesting. This got me thinking... > > What we need is a modern-day PARC with a /next generation/ of visionaries to > advance Smalltalk. They would carry on the work that was begun four decades > ago. > > Here's the thing: The Smalltalk environment has not fundamentally changed > or improved since the Xerox PARC days. We've been tweaking the design here > and there, but nothing groundbreaking has happened. > > Is the current Smalltalk environment the /final word/ on the nature of > dynamic programming and humane representation of thought? I seriously doubt > it. > > Who are the visionaries that will shake things up? How do we find them? > > Let's face it: We've all become rather complacent. (With the exception of > Newspeak, which frankly doesn't impress me much. *We don't need a new > language!*) > > This is something Smalltalk Renaissance should think about. > > > > -- > View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797243.h… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 29, 2014

Re: [Pharo-dev] Artefact green on CI

by stepharo

Thanks Stephan. We missed the last bits stupidly. Le 29/12/14 02:03, stephan(a)stack.nl a Ã©crit : > Name: ConfigurationOfArtefact-StephanEggermont.15 > Author: StephanEggermont > Time: 29 December 2014, 12:21:30.768 am > UUID: f55adfa3-0a60-4695-be30-9dd2320cd944 > Ancestors: ConfigurationOfArtefact-OlivierAuverlot.14 > > Promoted new version 1.4 to stable as current stable is broken, adding > a Pharo20 compatibility package > > Name: Artefact-Pharo20-StephanEggermont.1 > Author: StephanEggermont > Time: 29 December 2014, 12:10:05.696 am > UUID: e8475459-0316-4eca-a707-a1c5982ed650 > Ancestors: > > convenience methods max: flattened, flattenOn: to make build green > >

Dec. 29, 2014

Re: [Pharo-dev] The Smalltalk Renaissance Program

by S Krish

Inlined notes I agree nothing earth shaking is happening in Smalltalk in just the 6 months, but over the last 4 yrs it is a quite a shift in Pharo. Hats off to all active contributers. I quite disagree... on the fact nothing is happening. While all intellectually inclined love the idea of creating anew something ground breaking, it is in current decade more important to ensure we create relevant technology not just for the sake of claiming high ground. Wolfram , Google, FB may be creating their islands of tech bubbles and that may take the world too, but they have the billions I guess to afford. On Mon, Dec 29, 2014 at 6:06 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > Bret Victor's talk is certainly interesting. This got me thinking... > > What we need is a modern-day PARC with a /next generation/ of visionaries > to > advance Smalltalk. They would carry on the work that was begun four decades > ago. > > Here's the thing: The Smalltalk environment has not fundamentally changed > or improved since the Xerox PARC days. We've been tweaking the design here > and there, but nothing groundbreaking has happened. > > Is the current Smalltalk environment the /final word/ on the nature of > dynamic programming and humane representation of thought? I seriously doubt > it. > > Who are the visionaries that will shake things up? How do we find them? > Stephane Ducasse and team are visionaries in as much as Pharo is shaking things up on Smalltalk world . Lots of new things have already been charted out, of course the tough grind of actually cleaning and providing a meaningful free Smalltalk environment for the enterprise world is a gargantuan task and I see it as being reached gradually in Pharo. That will itself be etched in history 10 yrs later as a great achievement. > > Let's face it: We've all become rather complacent. (With the exception of > Newspeak, which frankly doesn't impress me much. *We don't need a new > language!*) > > For four years I have seen the kind of energy/ enthusiasm unmatched in the last decade or more in Pharo resurgence. Free Enterprise Smalltalk, is about arriving in the IT industry.. just some honchos need to weave it in. > This is something Smalltalk Renaissance should think about. > > Much said and done in Pharo, there is nothing stopping any group in > creating something more powerful / relevant and leave the footprints in the > sands of time more firmly etched. I agree again there is lot of scope > provided that group does it.. > > -- > View this message in context: > http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797243.h… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 29, 2014

Re: [Pharo-dev] The Smalltalk Renaissance Program

by Sebastian Sastre

Completely agree Richard. In this talk Alan Kay address that point: The Future Doesn't Have to Be Incremental https://www.youtube.com/watch?v=gTAghAJcO1o <https://www.youtube.com/watch?v=gTAghAJcO1o> Even if we have the visionaries, as in that talk is explained, you need funding to get them working on the vision. I donât know if our community has enough millionaires to make that happen, so far doesnât look like it. Or.. we didnât explore that path well enough > On Dec 28, 2014, at 10:36 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > > Bret Victor's talk is certainly interesting. This got me thinking... > > What we need is a modern-day PARC with a /next generation/ of visionaries to > advance Smalltalk. They would carry on the work that was begun four decades > ago. > > Here's the thing: The Smalltalk environment has not fundamentally changed > or improved since the Xerox PARC days. We've been tweaking the design here > and there, but nothing groundbreaking has happened. > > Is the current Smalltalk environment the /final word/ on the nature of > dynamic programming and humane representation of thought? I seriously doubt > it. > > Who are the visionaries that will shake things up? How do we find them? > > Let's face it: We've all become rather complacent. (With the exception of > Newspeak, which frankly doesn't impress me much. *We don't need a new > language!*) > > This is something Smalltalk Renaissance should think about. > > > > -- > View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797243.h… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 29, 2014