- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FogBugz status change

by Marcus Denker

On 29 Dec 2013, at 23:34, btc(a)openinworld.com wrote: > Esteban Lorenzano wrote: >> >> thatâs usually done by the integrators, but nothing prevents you to do it :) >> > I thought wider community involvement was encouraged for anyone to provide the peer review to move items to status Resolved Fix To Include > with the integrators then moving it to status Resolved Fix Included (and then usually straight to Closed status) > Yes, but for a real working system we would need a voting schemeâ¦ right now it matters not much as everything is manual, but of it would be automatic, it would be nice to have something like âtwo people who are commuters say itâs goo then it is good to be integrated automaticallyâ.] Right now the idea is that people can set the âfix to includeâ if they are 150% sure that is is a good change. Itâs better to just add a note to the âfix review neededâ so then someone else will say âhe thinks itâs good, I double checked, so itâs goodâ. So, in short: we need a better system, but for now it kind of works. Marcus

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Marcus Denker

On 30 Dec 2013, at 09:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Dec 2013, at 08:29, Johan Brichau <johan(a)inceptive.be> wrote: > >> On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ >> >> imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. > > Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. We need to get rid of it. The mental overhead it produces is costing far more then the memory it saves (and now we soon have 2014, so if it was âtoo much memoryâ for Pharo3, it will by definition not be for Pharo4 thanks to time passingâ¦) Marcus

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Marcus Denker

On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ > but I do not remember the result of that discussion and this could be a consequence of that. Marcus will know better for sure (letâs wait he is back from his holidays :) ) > I am back and going through lots of mailsâ¦. So: I thought this was fixed. Seemingly there was a regressionâ¦ There is another issue that we need to have a look at related (not the same): https://pharo.fogbugz.com/f/cases/11908/Need-to-show-warning-when-no-change…

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Esteban Lorenzano

On 30 Dec 2013, at 09:54, Johan Brichau <johan(a)inceptive.be> wrote: > > On 30 Dec 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. >> >> Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. > > I guess it does not hurt to look at both places. > In 10 years from now, you might no longer have the V10.sources anymore with your vm but you might want to dive into a 2011 image of Zinc on Pharo1.4 for good âol times sake ;-) in 10 months from now (not years), if everything goes fine, sources will come inside image (also changes)â¦ in an unique super-file :) but well, we are not still in that pointâ¦ and 10 months is just a desire than a fact :) Esteban > > cheers > Johan

Dec. 30, 2013

Re: [Pharo-dev] Thank you for Pharo

by Marcus Denker

On 27 Dec 2013, at 11:17, Volkert Barr <volkert(a)nivoba.de> wrote: > Thank you for Pharo â¦. > > I am following the development of Pharo since its fork from Squeak, and i am really impressed what you crazy guys all have archived the last years. It all evolved to really nice language, a fantastic nice looking live programming environment, cool packages and a growing ecosystems. I have so much fun using Pharo. Thank you. > > 2011 i gave me a push to learn Pharo and last year i decided to do a small research prototype with it. The goal is a tool to analyze and visualize application landscapes. I have implemented a small repository model for the different architecture levels, some data analytic rules on top the model, and some model visualizations. For visualization i use Roassal/Mondrian. For Data-In/-Export i use simply NeoCSV. Next year i plan to add more data analytic rules, to add model transformation operations to "simulate" landscape transformations (projects), and to use 3D visualizations with Roassal3D (City Metaphor). If all works fine, we see what 2015 brings ... > > Pharo is really a productivity boost for me. If you are able to play around with the objects in an interactive environment life is getting so much easier. Thanks a lot for this mail :-) Marcus

Dec. 30, 2013

Re: [Pharo-dev] Are #explorerContents and #hasContentsInExplorer obsolete ?

by Marcus Denker

On 28 Dec 2013, at 13:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks for raising this :). > > I now added a simple implementation in the GTInspector to have Pointers available for all objects. Perhaps it is overdoing it to have it by default on all objects, but it was cheap to implement in a crude way. I still do not eliminate all inspector related objects that point to the current object, but it's a start (see attached the pointers to Smalltalk). > If the inspector that is in Pharo gets a solution for pointers, then we can directly clean up a lot of old code. With this being done for tools that are just loadable optionally â> we still have to keep the old code of the Explorer around. Marcus

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Johan Brichau

On 30 Dec 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. > > Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. I guess it does not hurt to look at both places. In 10 years from now, you might no longer have the V10.sources anymore with your vm but you might want to dive into a 2011 image of Zinc on Pharo1.4 for good âol times sake ;-) cheers Johan

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Sven Van Caekenberghe

On 30 Dec 2013, at 08:29, Johan Brichau <johan(a)inceptive.be> wrote: > On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ > > imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. > I made a bug report for it. But what you saw was a bug indeed. > cheers, > Johan

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Johan Brichau

On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. I made a bug report for it. cheers, Johan

Dec. 30, 2013

towards moose in the pharo ide (gtinspector / gtdebugger)

by Tudor Girba

Hi, Some of you asked how the GTInspector and GTDebugger are different from the existing infrastructure. They are quite different from the norm in that: they are tiny, and they are highly extensible. Here are some posts that describe what makes them different: http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructe… http://www.humane-assessment.com/blog/dissecting-the-gtinspector/ http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspec… http://www.humane-assessment.com/blog/moldable-gtdebugger These tools are already the default development tools in the Moose image. As you can see, Moose is reshaping the Pharo IDE. I think this is exciting. This should be just the beginning. To make it better, we need your energy: - Apply and extend these tools for your context (this is what makes them unique). - Tell us what works and what does not work. - Ideally, start working with us on this topic. In particular, I am looking for people that would like to spend some time working on Morphic widgets. It's your turn now. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Dec. 30, 2013