June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] the importance of your story

by phil＠highoctane.be

Yes, thx. Your words are inspiring. At a time I needed that lift :-) Phil Le 25 juin 2015 13:54, "Max Leske" <maxleske(a)gmail.com> a Ã©crit : > > Thanks Doru! > >> On 25 Jun 2015, at 13:39, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> I gave last week a talk at NDC Oslo on "Don't demo facts. Demo stories!". While the talk is less technical, I did exemplified the message by demoing Spotter in comparison with the search support from Eclipse. >> >> There are several things I would like to emphasize. >> >> I compared our solution with an "industry standard" one. We often think our system as being niche and perhaps not mature enough. We need to change that perception about our work. We build state of the art. >> >> One thing that I did not mention explicitly in the talk is the size of the implementation. The Spotter implementation is 3500 lines of code -- and that it is so large because it currently comes with its own widgets. Furthermore, the extensions average 8 lines per custom processor (including the method header and the pragma). This is orders of magnitude smaller than what is typically out there, and it is precisely the reason why we can compete even if we are fewer. >> >> But, to get out there and compete we have to set that high goal for ourselves. For example, with GT we do not want to compete. We want to outcompete. So can you. >> >> While details are important, high goals require us to get away from those details. Only polishing details will tend to limit you to incremental improvements. We need to jump from time to time. But, these jumps are hard. On the one hand, it is hard to find the right jump and convince people to jump with you. On the other hand, they are hard to predict. For example, Spotter would have not been predictable one year ago. >> >> Yet, dry goals are not enough to keep us going. We need stories that make us dream. And the beauty is that Pharo breaths such a story. We should not limit ourselves to that story only. For example, with GT we want to reinvent the developer experience by making the developer be able to mold visual tools to her context because that is the only effective way to build sustainable systems. This little point of view will turn the IDE upside down, and this is only possible in a system like Pharo. >> >> Choose your high goal and tell its story through the system that you build. And remember that Pharo already offers a beautiful story to start from. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > >

June 25, 2015

[pharo-project/pharo-core] 875d5b: 50135

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 875d5b3e6c92aa75b40ab710e64af05d823575e4 https://github.com/pharo-project/pharo-core/commit/875d5b3e6c92aa75b40ab710… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-25 (Thu, 25 Jun 2015) Changed paths: M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitNode_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitReturnNode_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitVariableNode_.st R OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitVariableWrite_.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyGlobalVariable.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitNode_.st A Reflectivity.package/RFVariableReification.class/instance/generate/genForGlobal.st M Reflectivity.package/RFVariableReification.class/instance/generate/genForRBVariableNode.st A Reflectivity.package/RFVariableReification.class/instance/generate/genForSlot.st R Reflectivity.package/extension/OCASTTranslator/instance/emitMetaLinkAfter_.st R Reflectivity.package/extension/OCASTTranslator/instance/emitMetaLinkBefore_.st R Reflectivity.package/extension/OCASTTranslator/instance/visitStoreIntoTempNode_.st R Reflectivity.package/extension/OCASTTranslator/instance/visitStorePopIntoTempNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50134.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50135.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50134.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50135.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50135 15838 Reflectivity: allow to reify #variable for Globals https://pharo.fogbugz.com/f/cases/15838 15837 Move all RF code from Opal to Opal Plugin https://pharo.fogbugz.com/f/cases/15837 http://files.pharo.org/image/50/50135.zip

June 25, 2015

[pharo-project/pharo-core]

by GitHub

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

June 25, 2015

Re: [Pharo-dev] the importance of your story

by Max Leske

Thanks Doru! > On 25 Jun 2015, at 13:39, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I gave last week a talk at NDC Oslo on "Don't demo facts. Demo stories!". While the talk is less technical, I did exemplified the message by demoing Spotter in comparison with the search support from Eclipse. > > There are several things I would like to emphasize. > > I compared our solution with an "industry standard" one. We often think our system as being niche and perhaps not mature enough. We need to change that perception about our work. We build state of the art. > > One thing that I did not mention explicitly in the talk is the size of the implementation. The Spotter implementation is 3500 lines of code -- and that it is so large because it currently comes with its own widgets. Furthermore, the extensions average 8 lines per custom processor (including the method header and the pragma). This is orders of magnitude smaller than what is typically out there, and it is precisely the reason why we can compete even if we are fewer. > > But, to get out there and compete we have to set that high goal for ourselves. For example, with GT we do not want to compete. We want to outcompete. So can you. > > While details are important, high goals require us to get away from those details. Only polishing details will tend to limit you to incremental improvements. We need to jump from time to time. But, these jumps are hard. On the one hand, it is hard to find the right jump and convince people to jump with you. On the other hand, they are hard to predict. For example, Spotter would have not been predictable one year ago. > > Yet, dry goals are not enough to keep us going. We need stories that make us dream. And the beauty is that Pharo breaths such a story. We should not limit ourselves to that story only. For example, with GT we want to reinvent the developer experience by making the developer be able to mold visual tools to her context because that is the only effective way to build sustainable systems. This little point of view will turn the IDE upside down, and this is only possible in a system like Pharo. > > Choose your high goal and tell its story through the system that you build. And remember that Pharo already offers a beautiful story to start from. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

June 25, 2015

Re: [Pharo-dev] the importance of your story

by Tudor Girba

And here is the video: https://vimeo.com/131632605 On Thu, Jun 25, 2015 at 1:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I gave last week a talk at NDC Oslo on "Don't demo facts. Demo stories!". > While the talk is less technical, I did exemplified the message by demoing > Spotter in comparison with the search support from Eclipse. > > There are several things I would like to emphasize. > > I compared our solution with an "industry standard" one. We often think > our system as being niche and perhaps not mature enough. We need to change > that perception about our work. We build state of the art. > > One thing that I did not mention explicitly in the talk is the size of the > implementation. The Spotter implementation is 3500 lines of code -- and > that it is so large because it currently comes with its own widgets. > Furthermore, the extensions average 8 lines per custom processor (including > the method header and the pragma). This is orders of magnitude smaller than > what is typically out there, and it is precisely the reason why we can > compete even if we are fewer. > > But, to get out there and compete we have to set that high goal for > ourselves. For example, with GT we do not want to compete. We want to > outcompete. So can you. > > While details are important, high goals require us to get away from those > details. Only polishing details will tend to limit you to incremental > improvements. We need to jump from time to time. But, these jumps are hard. > On the one hand, it is hard to find the right jump and convince people to > jump with you. On the other hand, they are hard to predict. For example, > Spotter would have not been predictable one year ago. > > Yet, dry goals are not enough to keep us going. We need stories that make > us dream. And the beauty is that Pharo breaths such a story. We should not > limit ourselves to that story only. For example, with GT we want to > reinvent the developer experience by making the developer be able to mold > visual tools to her context because that is the only effective way to build > sustainable systems. This little point of view will turn the IDE upside > down, and this is only possible in a system like Pharo. > > Choose your high goal and tell its story through the system that you > build. And remember that Pharo already offers a beautiful story to start > from. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

June 25, 2015

the importance of your story

by Tudor Girba

Hi, I gave last week a talk at NDC Oslo on "Don't demo facts. Demo stories!". While the talk is less technical, I did exemplified the message by demoing Spotter in comparison with the search support from Eclipse. There are several things I would like to emphasize. I compared our solution with an "industry standard" one. We often think our system as being niche and perhaps not mature enough. We need to change that perception about our work. We build state of the art. One thing that I did not mention explicitly in the talk is the size of the implementation. The Spotter implementation is 3500 lines of code -- and that it is so large because it currently comes with its own widgets. Furthermore, the extensions average 8 lines per custom processor (including the method header and the pragma). This is orders of magnitude smaller than what is typically out there, and it is precisely the reason why we can compete even if we are fewer. But, to get out there and compete we have to set that high goal for ourselves. For example, with GT we do not want to compete. We want to outcompete. So can you. While details are important, high goals require us to get away from those details. Only polishing details will tend to limit you to incremental improvements. We need to jump from time to time. But, these jumps are hard. On the one hand, it is hard to find the right jump and convince people to jump with you. On the other hand, they are hard to predict. For example, Spotter would have not been predictable one year ago. Yet, dry goals are not enough to keep us going. We need stories that make us dream. And the beauty is that Pharo breaths such a story. We should not limit ourselves to that story only. For example, with GT we want to reinvent the developer experience by making the developer be able to mold visual tools to her context because that is the only effective way to build sustainable systems. This little point of view will turn the IDE upside down, and this is only possible in a system like Pharo. Choose your high goal and tell its story through the system that you build. And remember that Pharo already offers a beautiful story to start from. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

June 25, 2015

OSWindow and event managing

by Matthieu Lacaton

Hello everyone, I would like to talk a bit about the way OSWindow makes events available for the user. Currently, a dedicated process with a priority of 60 gets SDL events, converts them into OSWindow events and then makes them available to the user via the OSWindowEventVisitor. Now my concern is that, by default, it is this same process that executes actions specified by the user. (Actually every event is forked to be executed in its own thread but with the same priority of 60 so as Pharo scheduler is not pre emptive it does not change the execution order) So basically, all the operations made in the main thread will be interrupted by the operations made in the event thread since the event thread has a higher priority. I get that it makes the window more responsive since its events are treated almost immediately but if you are not aware of what you are doing you can have some weird behaviors as in every multi-threaded program. It means that if I am a simple user and I want to use OSWindow simply, by default I need to deal with 2 processes and to handle some kind of concurrency even if my application is very simple. I find it a bit harsh. Shouldn't we provide the user with something simple and "unbreakable" by default but let him the possibility to do whatever he wants with extra work instead of providing him with something a bit more advanced by default but that needs extra work to make simple ? Maybe we could provide something a bit like SDL does. Put OSWindow events in a queue and then create mechanisms arround to manage this queue and let the user easily get events he wants. By default any application would be mono-processed but nothing would prevent the user to create a new process dedicated to event handling. What are your thoughts about all that ? Thanks, Matthieu

June 25, 2015

Re: [Pharo-dev] Pharo 4.0 crash

by Sabine Manaa

Hi Steph, dev: Mac-iOS, here is the crashed image. prod: windows, not yet this problem Regards Sabine 2015-06-24 21:07 GMT+02:00 stepharo [via Smalltalk] < ml-node+s1294792n4833940h35(a)n4.nabble.com>: > Hi sabina > > on which OS are you? > > Stef > > Le 19/6/15 09:31, Sabine Manaa a Ã©crit : > > > Hi, > > > > I have crashes from time to time. Are they useful for you? > > If yes, where is the vm-dev list? > > > > Regards > > Sabine > > > > > > > > -- > > View this message in context: > http://forum.world.st/Pharo-4-0-crash-tp4832475p4833169.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Pharo-4-0-crash-tp4832475p4833940.html > To unsubscribe from Pharo 4.0 crash, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Pharo-4-0-crash-tp4832475p4834009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 25, 2015

[pharo-project/pharo-core]

by GitHub

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

June 25, 2015

[pharo-project/pharo-core] f1e4b4: 50134

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f1e4b4275da241f32f438cfc486d0be90d477551 https://github.com/pharo-project/pharo-core/commit/f1e4b4275da241f32f438cfc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-25 (Thu, 25 Jun 2015) Changed paths: M NautilusRefactoring.package/NautilusRefactoring.class/instance/class/buildRenameRefactoringEngineFor_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/emitMessageNode_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitAssignmentNode_.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkAfter_.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkBefore_.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/visitStoreIntoTempNode_.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/visitStorePopIntoTempNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/emitMessageNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitAssignmentNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitReturnNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitVariableNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitVariableWrite_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/emitMessageNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitArrayNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitBlockNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitLiteralArrayNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitLiteralNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitParseErrorNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitSequenceNode_.st A Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitVariableNode_.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/recompileAST.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50133.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50134.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50133.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50134.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50134 15830 enable compiler subclass for Reflectivity, start to move hooks from superclass https://pharo.fogbugz.com/f/cases/15830 15836 Abort Rename class refactoring https://pharo.fogbugz.com/f/cases/15836 http://files.pharo.org/image/50/50134.zip

June 25, 2015