- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

Tudor I think you doing a great job and you are correct that Pharo is there concerning the goal you describing. But my goal is not the goal you are describing. My goal is the next step, its the product of your goal. What happens when you have a mouldable IDE. I am talking about the specific tools themselves not tools that help create those tools. Its the same with 3d graphics apps, no artist want to use graphic engines to create 3d graphics, they want to use tools that already provide the means to achieve the result they want. This is why opengl is not enough , or a graphic engine, or even visual coding environment. For example lets say that I want a tool to visualise structure of objects and how they depend on each other. I know that I can do that with roassal but I am not aware if such tool exist already for Pharo. I would also like another tool that visualizes sockets connection and communication. Data that comes in Pharo and goes out. I would also like a drag and drop GUI designer. I would also like a tool, that would allow me to quickly browse through class comments and edit them and even share them online, like an online database. I would also like code completion that also displays small info about the code to be completed. I would also like visual integration of git. Git alone is a huge collection of tools. and so on .... On Tue, Aug 12, 2014 at 3:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Kilon, > > Excellent observation! > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is > simple: make it dead cheap for the developer to mold the IDE to his/her > contextual needs. > > Until now, we have announced an inspector and a debugger that do just > that. The inspector makes it possible to mold the tool for every little > object if you desire. For example, I alone have built literally hundreds of > extensions for various objects. Actually, the inspector goes as far as to > allow you to mold the flow to the context in which you are. The debugger > lets you define custom debuggers that you can switch to while debugging. > All these extensions are incredibly small (an object inspector extension > has an average of 8 lines, and the debuggers we implemented consist of a > couple of hundred loc), they are independent of each other, and they are > put together through a small frame. Add to that the potential of using > multiple rendering engines and we get a brand new philosophy that I believe > holds the potential to change software development significantly. > > This is not a far goal. It's a reality now. At ESUG, we will show how > these tools work now in practice. > > What Roberto is doing is complementary to our efforts. Data mining will > certainly play a significant role in this picture, precisely when we will > start to have thousands of these little contextual tools. At this time, > DFlow is experimental, but eventually a tool like this should become part > of the IDE as we need to understand how developers work in their context > and what they need in their context. That is why his effort should be > supported by our community. Please install it and give feedback. > > Cheers, > Doru > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> I think the future are tools tailor made for specific kind of tasks . The >> age of IDEs and Languages has come to an end. Neither programming languages >> and IDEs can maintain the complexity of modern software. They are too >> generic.I think that what we need is a UNIX system but with GUIs , a >> collection of tools that can talk to each other but at the same time have >> an extremely limited scope as tools. Smalltalk definitely moves towards >> that direction but even Smalltalk is far from that goal. >> >> I see that paradigm a lot in 3d art, it raises the amount of knowledge >> required because you end up with learning hundreds of tools contained in a >> single application but if you want professional results and you are dead >> serious about efficiency and productivity then its the way to go. >> >> I will install DFlow and help you in your saga, but bare in mind that >> DFlow will tell you what I use and I how , but it wont answer you the most >> important question "what I want to use and how I want to use it" . >> >> >> On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch >> > wrote: >> >>> Hi guys, >>> >>> I uploaded a web page to explain Self-Adaptive IDEs, the vision I will >>> develop for my Ph.D >>> http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. >>> >>> Please take a minute to look at it and tell me your opinion! >>> >>> At the moment we are conducting an experiment with my interaction >>> profiler (DFlow). It would be >>> great if you could participate! This will cost you little effort but >>> help me to gather an understanding >>> of development practices and interactions. This is the ground for >>> improving our Pharo IDE! >>> >>> Cheers and thanks in advance, >>> Roberto >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 12, 2014

Re: [Pharo-dev] About STON

by Sven Van Caekenberghe

Stef, On 12 Aug 2014, at 07:55, stepharo <stepharo(a)free.fr> wrote: > sven > > I was wondering if we could get the following in STON > > > STON acceptNonPresentClasses. > > STON readFrom: 'Blblbl {#foo : 3} > > would create a dictionary with class name -> #Blblbl > > Now if the class is loaded we would get a Blblbl object Good idea: === Name: STON-Core-SvenVanCaekenberghe.51 Author: SvenVanCaekenberghe Time: 12 August 2014, 3:40:21.574545 pm UUID: 6559f648-b74a-4901-b249-e72808fdea0d Ancestors: STON-Core-SvenVanCaekenberghe.49 Add STONReader>#acceptUnknownClasses: option When true (default is false) an unknown object class will result in a map with an added property #className (thx StÃ©phane Ducasse for the suggetion) Added STON class>>#classNameKey Moved #stonName from Class to Object class Added STONReaderTests>>#testUnknownClasses === Name: STON-Tests-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 12 August 2014, 3:40:43.256364 pm UUID: e48a3d7c-6d8a-4899-943f-829ee4e8715d Ancestors: STON-Tests-SvenVanCaekenberghe.44 Add STONReader>#acceptUnknownClasses: option When true (default is false) an unknown object class will result in a map with an added property #className (thx StÃ©phane Ducasse for the suggetion) Added STON class>>#classNameKey Moved #stonName from Class to Object class Added STONReaderTests>>#testUnknownClasses === > Christophe has some other ideas such > > STON nilOutEmptyCollections. > to avoid to save #() and other I think this can better be done with a custom serialisation, assuming #roles is a lazy initialised collection, like: #stonOn: stonWriter stonWriter writeObject: self streamMap: [ :stream | stream at: #username put: username; at: #password put: password. (roles isNil or: [ roles isEmpty ]) ifFalse: [ stream at: #roles put: roles ] ] BTW, not writing nil is already an option, see #stonShouldWriteNilInstVars > Stef Thanks for the feedback, Sven

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

I have enabled your DFlow tool, but it looks like it severely slows down Pharo. Browsing through methods was instantaneous but with DFlow I see at least a one second lag which make its use quite an obstacle to my workflow. I am on macos 10.9 maverics with a 2011 macbook air. On Tue, Aug 12, 2014 at 4:31 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > I agree with you Kilon, thanks for your observation (and future help). > > My interaction profiler is only a means to the end. As Doru is saying, my > goal is to use the data captured by > DFlow to understand how developers work and what they need in their > context. > > In the short term I want to analyze how developers work, but then I will > do my best to bridge the gap between > what our IDEs offer and what we need. > > P.s. Thanks Doru for your support! > > Cheers, > Roby > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Kilon, > > > > Excellent observation! > > > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is > simple: make it dead cheap for the developer to mold the IDE to his/her > contextual needs. > > > > Until now, we have announced an inspector and a debugger that do just > that. The inspector makes it possible to mold the tool for every little > object if you desire. For example, I alone have built literally hundreds of > extensions for various objects. Actually, the inspector goes as far as to > allow you to mold the flow to the context in which you are. The debugger > lets you define custom debuggers that you can switch to while debugging. > All these extensions are incredibly small (an object inspector extension > has an average of 8 lines, and the debuggers we implemented consist of a > couple of hundred loc), they are independent of each other, and they are > put together through a small frame. Add to that the potential of using > multiple rendering engines and we get a brand new philosophy that I believe > holds the potential to change software development significantly. > > > > This is not a far goal. It's a reality now. At ESUG, we will show how > these tools work now in practice. > > > > What Roberto is doing is complementary to our efforts. Data mining will > certainly play a significant role in this picture, precisely when we will > start to have thousands of these little contextual tools. At this time, > DFlow is experimental, but eventually a tool like this should become part > of the IDE as we need to understand how developers work in their context > and what they need in their context. That is why his effort should be > supported by our community. Please install it and give feedback. > > > > Cheers, > > Doru > > > > > > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > I think the future are tools tailor made for specific kind of tasks . > The age of IDEs and Languages has come to an end. Neither programming > languages and IDEs can maintain the complexity of modern software. They are > too generic.I think that what we need is a UNIX system but with GUIs , a > collection of tools that can talk to each other but at the same time have > an extremely limited scope as tools. Smalltalk definitely moves towards > that direction but even Smalltalk is far from that goal. > > > > I see that paradigm a lot in 3d art, it raises the amount of knowledge > required because you end up with learning hundreds of tools contained in a > single application but if you want professional results and you are dead > serious about efficiency and productivity then its the way to go. > > > > I will install DFlow and help you in your saga, but bare in mind that > DFlow will tell you what I use and I how , but it wont answer you the most > important question "what I want to use and how I want to use it" . > > > > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli < > roberto.minelli(a)usi.ch> wrote: > > Hi guys, > > > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will > develop for my Ph.D > > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > > > Please take a minute to look at it and tell me your opinion! > > > > At the moment we are conducting an experiment with my interaction > profiler (DFlow). It would be > > great if you could participate! This will cost you little effort but > help me to gather an understanding > > of development practices and interactions. This is the ground for > improving our Pharo IDE! > > > > Cheers and thanks in advance, > > Roberto > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > >

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Roberto Minelli

Hi, I agree with you Kilon, thanks for your observation (and future help). My interaction profiler is only a means to the end. As Doru is saying, my goal is to use the data captured by DFlow to understand how developers work and what they need in their context. In the short term I want to analyze how developers work, but then I will do my best to bridge the gap between what our IDEs offer and what we need. P.s. Thanks Doru for your support! Cheers, Roby On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Kilon, > > Excellent observation! > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. > > Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. > > This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. > > What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. > > Cheers, > Doru > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. > > I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. > > I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will develop for my Ph.D > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > Please take a minute to look at it and tell me your opinion! > > At the moment we are conducting an experiment with my interaction profiler (DFlow). It would be > great if you could participate! This will cost you little effort but help me to gather an understanding > of development practices and interactions. This is the ground for improving our Pharo IDE! > > Cheers and thanks in advance, > Roberto > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 12, 2014

Re: [Pharo-dev] Adding menu to ListModel

by Yuriy Tymchuk

So Ben answered my question: http://stackoverflow.com/a/25242253/982238 but with his approach I get MenuMorph(Object)>>doesNotUnderstand: #addGroup:. Any ideas why? Uko On 11 Aug 2014, at 12:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys. > > I need a little help with adding a menu to the ListModel (in Spec). Can you take a look please: http://stackoverflow.com/questions/25240931/add-menu-to-listmodel > > Cheers. > Uko

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Tudor Girba

Hi Kilon, Excellent observation! The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. Cheers, Doru On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I think the future are tools tailor made for specific kind of tasks . The > age of IDEs and Languages has come to an end. Neither programming languages > and IDEs can maintain the complexity of modern software. They are too > generic.I think that what we need is a UNIX system but with GUIs , a > collection of tools that can talk to each other but at the same time have > an extremely limited scope as tools. Smalltalk definitely moves towards > that direction but even Smalltalk is far from that goal. > > I see that paradigm a lot in 3d art, it raises the amount of knowledge > required because you end up with learning hundreds of tools contained in a > single application but if you want professional results and you are dead > serious about efficiency and productivity then its the way to go. > > I will install DFlow and help you in your saga, but bare in mind that > DFlow will tell you what I use and I how , but it wont answer you the most > important question "what I want to use and how I want to use it" . > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> > wrote: > >> Hi guys, >> >> I uploaded a web page to explain Self-Adaptive IDEs, the vision I will >> develop for my Ph.D >> http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. >> >> Please take a minute to look at it and tell me your opinion! >> >> At the moment we are conducting an experiment with my interaction >> profiler (DFlow). It would be >> great if you could participate! This will cost you little effort but help >> me to gather an understanding >> of development practices and interactions. This is the ground for >> improving our Pharo IDE! >> >> Cheers and thanks in advance, >> Roberto >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 12, 2014

Faster ThreadSafeTranscript Re: [pharo-project/pharo-core] 06d05b: 40165

by Ben Coman

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will > develop for my Ph.D > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > Please take a minute to look at it and tell me your opinion! > > At the moment we are conducting an experiment with my interaction profiler > (DFlow). It would be > great if you could participate! This will cost you little effort but help > me to gather an understanding > of development practices and interactions. This is the ground for > improving our Pharo IDE! > > Cheers and thanks in advance, > Roberto > > >

Aug. 12, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by Esteban Lorenzano

On 11 Aug 2014, at 18:28, Tim Mackinnon <tim(a)testit.works> wrote: > Bump? The text on http://pharo.org/contribute-propose-fix is still wrong - can someone include the text I fixed up below? fixed Esteban > > Also - do we want to make pharo.org the primary place for docs (and hence change the first paragraph to: > > #How to propose a bug fix or enhancement > First check if your change has already been entered into Fogbugz, and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below. > > If we want to move away from the Fogbugz wiki, I will also simplify some of the text and point it back to pharo.org. > > Tim > > On 8 Aug 2014, at 08:40, Tim Mackinnon <tim(a)testit.works> wrote: > >> Ok - Iâve fixed my faux-pas and propose the following text (a slight rework of what is published now). Taking a hint from Martin there is a notehub link here (http://notehub.org/2014/8/8/how-to-propose-a-bug-fix-or-enhancement) - although Iâve noticed notehub handles sub-bullets a bit strangely. We might also want to do another slight change if we agree that Fogbugz should be secondary content (if so - adjust the first paragraph to something like: Check if your change has already been entered into Fogbugz, and consider watching the overview video of the steps documented below.) >> >> ââ > > >> #How to propose a bug fix or enhancement >> First check you meet the submission requirements and are familiar with the more detailed [contribution steps](https://pharo.fogbugz.com/default.asp?W68) (watch the [tutorial video](https://pharo.fogbugz.com/default.asp?pg=pgDownload&pgType=pgWikiAtt…, it's great!) >> >> ##Prerequisites >> In order to propose a bug fix or enhancement for Pharo you need: >> >> - An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com) >> - An account on [SmalltalkHub](http://smalltalkhub.com) with rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) >> _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.o… >> >> ##Procedure >> To commit a change, you will follow these steps: >> >> - Take the latest [stable or development system](http://pharo.org/download), ideally using the latest virtual machine for your OS >> - Ensure you have created [details of the issue in the Fogbugz issue tracker] (https://pharo.fogbugz.com) >> - Create a code fix (ideally with a [unit test](http://pharo.gforge.inria.fr/PBE1/PBE1ch8.html) exercising the working code) >> - Create a Monticello Slice (group of packages) for your changes: >> - Open the Monticello Browser >> - Open the Slice Maker by clicking the "Slice" button >> - In Slice Maker enter the Fogbugz issue number and "grab" the issue summary >> - Select all dirty packages affected by your fix >> - Verify your changes (click the Changes button) >> - Select the Pharo40 repository >> - Select your Slice >> - Press changes in the Monticello Browser and verify that your changes are correct >> - Publish the Slice to the inbox: >> - Select the whole Slice (not it's individual packages). >> - Select the SmalltalkHub Pharo Inbox repository. >> - Commit the Slice. >> - Verify that your fix loads: >> - Take a fresh image and load the Slice you just published >> - Update the bug entry to mention that you submitted a Slice in the inbox >> - Now sit back and feel good! You've helped influence a brighter future... >> >> You can also contribute to Pharo by proposing enhancements on the mailing list and/or by submitting a Fogbugz issue. Note that all code submitted to the [Pharo repositories](http://smalltalkhub.com/#!/~Pharo) is licensed under the [MIT license]http://opensource.org/licenses/MIT) Do not forget to sign the [license agreement](http://files.pharo.org/media/PharoSoftwareDistributionAgreement.…. >> >> >> On 8 Aug 2014, at 07:16, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Stef - I've confused you with my suggestion. Where I wrote "use link" after the text in [] - I meant put that hyperlink for the [text]. >>> >>> Sorry, I was writing my reply in a text editor and was doing a sort of pseudo markdown syntax. >>> >>> Looking at where this is going - maybe we should instead make the Pharo.org site the main source of info and not Fogbugz? We have a duplication problem - and when things change we end up with conflicting instructions as we forget to update the other copies. Essentially we need to refactor the docs. >>> >>> Is Pharo.org easily editable by others (is this the Pillar bit?). If it was then I would say let's edit the Fogbugz pages - simplify them and point them back to the more detailed Pharo.org pages. >>> >>> For now, I will find a laptop and send some cleaned up text. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 7 Aug 2014, at 10:45 pm, "stepharo [via Smalltalk]" <[hidden email]> wrote: >>> >>>> in fact I just did a merge with the version of Tim and it is looking great. >>>> On 7/8/14 22:32, stepharo wrote: >>>> >>>> > Thanks martin I will have a look tomorrow. >>>> > >>>> > Stef >>>> > >>>> > On 7/8/14 22:11, MartinW wrote: >>>> >> Could you extend http://pharo.org/contribute-propose-fix a bit? And >>>> >> add a >>>> >> screenshot of Slice Maker (I attach one). The following text would have >>>> >> helped me (I paste the markdown. I also posted it on NoteHub for a >>>> >> better >>>> >> reading experience >>>> >> http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix) >>>> >> >>>> >> #How to propose a bug fix: >>>> >> ##Prerequesites: >>>> >> In order to propose a bug fix or enhancement for Pharo you need: >>>> >> >>>> >> - an account at the [Pharo Issue Tracker on >>>> >> Fogbugz](https://pharo.fogbugz.com), >>>> >> - a [SmalltalkHub](http://smalltalkhub.com) account and >>>> >> - the commit right for the [Pharo Inbox on >>>> >> SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on >>>> >> the >>>> >> [Pharo Developers >>>> >> mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.… >>>> >> >>>> >> for the commit right). >>>> >> >>>> >> ##Procedure: >>>> >> - Take the latest stable or latest development system, ideally using the >>>> >> latest virtual machine. >>>> >> - Do a fix for a given bug, or a new bug you entered to the issue >>>> >> tracker. >>>> >> - Create a slice (group of packages): >>>> >> - Open the Monticello Browser. >>>> >> - Open the Slice Maker by clicking the **+Slice** button. >>>> >> - In Slice Maker enter the Fogbugz issue number and **grab** the >>>> >> issue >>>> >> summary. >>>> >> - Select all dirty packages affected by your bug fix. >>>> >> - Publish the slice to the inbox: >>>> >> - Select the whole slice (not it's individual packages). >>>> >> - Select the SmalltalkHub Pharo Inbox repository. >>>> >> - Commit your slice. >>>> >> - Verify that your fix loads: take a fresh image and load the slice you >>>> >> published. >>>> >> - Update the bug entry to mention that you submitted a slice in the >>>> >> inbox. >>>> >> >>>> >> You can also contribute to Pharo by proposing enhancements following the >>>> >> same process. Note that all code submitted to the Pharo repositories is >>>> >> licensed under the MIT license. Do not forget to sign the license >>>> >> agreement. >>>> >> >>>> >> <http://forum.world.st/file/n4772388/SliceMaker.png> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> View this message in context: >>>> >> http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… >>>> >> 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/About-your-contributions-Improve-Pharo-right-now-righ… >>>> To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. >>>> NAML >>> >>> View this message in context: Re: About your contributions: Improve Pharo right now, right there. >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Aug. 12, 2014

Re: [Pharo-dev] Draw PolygonMorph with athens

by stepharo

> for issue 13791 I uploaded a slice to make the PolygonMorph drawing > work on an AthensCanvas. Thanks. > The results look great, although there is a small difference between > athens > and morphics curve polygon drawing. The difference is more visible for > open curved polygons. > I don't know why, > I don't think we really need this :) :) I think that indeed we should not aim for equality. We will build slowly. > and I would like to move on to work on some more important > Morphs :) Yes :) > > > nicolai

Aug. 12, 2014