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

Re: [Pharo-dev] Coral (again)

by Stephan Eggermont

I would be strongly interested in using Coral as a replacement for puppet/chef/salt Stephan

March 7, 2014

Re: [Pharo-dev] About inspectors

by Sven Van Caekenberghe

Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use. On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone. > > This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector. > > Uko

March 7, 2014

Re: [Pharo-dev] Status of the VM?

by Eliot Miranda

Hi Jan, On Mar 6, 2014, at 2:29 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 04/03/14 17:37, Eliot Miranda wrote: >> >> >> >> On Sat, Mar 1, 2014 at 4:09 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz >> <mailto:jan.vrany@fit.cvut.cz>> wrote: >> >> Maybe I'm missing something obvious, but from my point of >> view the fundamental difference here is that with JVM's JPDA >> triggering of event actually **does not** affect the monitored >> system. >> >> If these events are handled by the image, it is quite tricky to >> figure out which one is caused by "application" and which one >> is caused by the event handling machinery. For instance, >> if (non-empty) method is called after a GC, this handler >> may trigger another GC, which may... >> >> That brings me to another, if you do in-image profiling (event >> handling), data could be quite different than what would you get >> using out-of-image profiler. >> >> >> <personal experience:> >> I've used (and implemented some :-) both - Smalltalk in-image tools >> and out-of-image tools, namely JPDA and DTRACE/STAP. For serious >> profiling and monitoring, I always use out-of-image approach if >> possible. >> >> >> I disagree. > > Fair enough :-) > > What I use for serious VM profiling is a hybrid approach >> that collects data in the VM but uses the image to display and interact >> with it. The VMProfiler, which is in CogTools in the VMMaker repository >> is IMNAAHO a very nice VM profiler. > > Looks good, indeed. > >> >> In the VM there is a thread that interrupts the main VM thread >> periodically, sampling its pc and storing this in a circular buffer. >> The thread and buffer are manipulated by a couple of primitives. >> Alongside is a platform-specific plugin to reveal the dlls loaded in >> the VM. The JIT reports current machine code methods and PICs through a >> primitive. > > Looks like everybody has a slightly different techniques and its own tools :-) I collect data in VM but the VM reports them to "outside" (via log file or kind of IPC). Then I analyze data post-mortem using various tools, some of them are hand-crafted, some not. I found > KCachegrind quite nice. > > Anyway, the interesting question to me is what are the advantages of > your approach? One is interactivity. The tool supports drilling down to instruction level, which is good for critical code sequences such as method prolog. Another is comprehensibility. Because it can distinguish between generated machine code (specific methods and runtime routines), functions in the VM and other support code (including stuff like Linux on stack system call entry) one sees all activities in the VM presented meaningfully. Another is evolvability. Because it's written in smalltalk I can develop the tool quickly and do so while I'm using it. > Best, Jan Eliot (phone)

March 7, 2014

Re: [Pharo-dev] 12911 Tests-failing-in-fresh-image-MetacelloRepositorySqueakCommonTestCase

by Max Leske

Works on OS X 10.9.2 Max On 07.03.2014, at 18:48, btc(a)openInWorld.com wrote: > Can someone with a Mac review... > https://pharo.fogbugz.com/f/cases/edit/12911/Tests-failing-in-fresh-image-M… > > Its low priority but also simple - just an update for three tests to deal with difference on Windows platform . > cheers -ben >

March 7, 2014

Coral (again)

by phil＠highoctane.be

I would like to know where to look to get a "valid"/"best" version of Coral to use/work on. I am going to need to work in an assignment where there are a number of scripting things to do and I'd like to give Pharo a shot. I'd like to be able to use Coral, as I liked the video about it and how it worked. I saw that Camillo has it on GitHub. TIA for the pointers. Phil

March 7, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

That is precisely what GT offers you. Just use that. Doru On Fri, Mar 7, 2014 at 9:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I would like to have some idea, that object can provide a way to inspect > itself (similar like every object should define how to print itself). And > then all the browsers could use it. Because now I'm developing something > and I'm implementing special inspections for my objects. Would be nice to > give other people a possibility to also inspect my objects in a special way. > > > On 07 Mar 2014, at 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Why do you say that? > > You get two different solutions. GTInspector is around since almost four > years and it was brewed in the more research-oriented Moose environment. At > the moment, the Pharo solution adopted just the multiple presentations > part. I agree that it is not at all as powerful as GTInspector (both > implementation and conceptual wise), but it's already better than it exists > in other environments. > > In the meantime, GTInspector will grow more to show what else is possible, > and hopefully, the community will finally look at it and see that it offers > a completely new way of developing :). > > Doru > > > > > On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: > >> Yes, I know. And this is sad :( >> >> >> On 07 Mar 2014, at 18:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> We cannot do that because they are based on two radically different >> technologies. >> >> Doru >> >> >> On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: >> >>> Hi everyone. >>> >>> This day I've attended Moose dojo and I'm pretty impressed with the >>> possibilities of GTInspector. The one thing that I've noticed is that both >>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>> wandering if we can come up with a common protocol to give an object >>> specific infector view, and not develop a separate thing for each inspector. >>> >>> Uko >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

March 7, 2014

Re: [Pharo-dev] TWM and 3.0: icons/themes, UpdatingMenuMorph

by phil＠highoctane.be

Yes, I started sprinkling but was unhappy as some icons are internal to TWM and others are Smalltalk ui icons... I'll look into how I can make it nice. Phil On Fri, Mar 7, 2014 at 8:03 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > philippeback wrote > > I am trying to get TWM to work in 3.0 > > ... > > Where Updating MenuMorph appears to be gone in 3.0 > > > > What am I supposed to use as a replacement? > > Glad you're working on it. I got stuck in the same place. The icon problem > IIRC occurs in two TWM classes. Might I suggest (which you may already have > done) for the class with the many such references (the bar I think), you > abstract via "#icons ^ Smalltalk ui" instead of sprinkling "Smalltalk ui > xyzIcon" everywhere and having to repeat the work for Pharo #.0. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/TWM-and-3-0-icons-themes-UpdatingMenuMorph-tp4747979p… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 7, 2014

Re: [Pharo-dev] About inspectors

by Yuriy Tymchuk

I would like to have some idea, that object can provide a way to inspect itself (similar like every object should define how to print itself). And then all the browsers could use it. Because now Iâm developing something and Iâm implementing special inspections for my objects. Would be nice to give other people a possibility to also inspect my objects in a special way. On 07 Mar 2014, at 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Why do you say that? > > You get two different solutions. GTInspector is around since almost four years and it was brewed in the more research-oriented Moose environment. At the moment, the Pharo solution adopted just the multiple presentations part. I agree that it is not at all as powerful as GTInspector (both implementation and conceptual wise), but it's already better than it exists in other environments. > > In the meantime, GTInspector will grow more to show what else is possible, and hopefully, the community will finally look at it and see that it offers a completely new way of developing :). > > Doru > > > > > On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Yes, I know. And this is sad :( > > > On 07 Mar 2014, at 18:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> We cannot do that because they are based on two radically different technologies. >> >> Doru >> >> >> On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Hi everyone. >> >> This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector. >> >> Uko >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

March 7, 2014

Re: [Pharo-dev] TWM and 3.0: icons/themes, UpdatingMenuMorph

by Pharo4Stef

> > > As I was getting the class back in my 3.0 image, I noticed that drag and drop of classes to other packages led to a #MNU: > https://pharo.fogbugz.com/default.asp?13049 > > ... and deprecation warnings are nice but not with little windows all over... :-p > > Putting the UpdatingMenuMorph makes TWM works again. As TWM is the only user of this one, I suggest to put the class in TWM with a TWM prefix. Okay? yes! > > Phil > > >> >> TIA >> Phil >> >> >> >> >> On Thu, Mar 6, 2014 at 12:00 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> I am trying to get TWM to work in 3.0 >> >> I use the Metacello config flag "trick" to make it load 2.x things. >> >> Now, things do load but there is the deprecation warnings about the way icons are handled. >> >> e.g. >> >> deleteSnapshotIcon >> ^ dock theme smallDeleteIcon. >> >> gives a warning. >> >> I looked into the code and now, we are supposed to do: >> >> Smalltalk ui smallDeleteIcon. >> >> Well, I changed the things that needed to be changed and then hit: >> >> newMenu: aSelector icon: aForm help: aString >> ^ MenuItemMorph new >> contents: ''; >> subMenu: (UpdatingMenuMorph new updater: self updateSelector: aSelector); >> icon: aForm; >> setBalloonText: aString. >> >> Where Updating MenuMorph appears to be gone in 3.0 >> >> What am I supposed to use as a replacement? >> >> TIA >> >> Phil >> >> >> > > > <07-03-14 10-17-33.png>

March 7, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

Why do you say that? You get two different solutions. GTInspector is around since almost four years and it was brewed in the more research-oriented Moose environment. At the moment, the Pharo solution adopted just the multiple presentations part. I agree that it is not at all as powerful as GTInspector (both implementation and conceptual wise), but it's already better than it exists in other environments. In the meantime, GTInspector will grow more to show what else is possible, and hopefully, the community will finally look at it and see that it offers a completely new way of developing :). Doru On Fri, Mar 7, 2014 at 8:39 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Yes, I know. And this is sad :( > > > On 07 Mar 2014, at 18:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > We cannot do that because they are based on two radically different > technologies. > > Doru > > > On Fri, Mar 7, 2014 at 4:43 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: > >> Hi everyone. >> >> This day I've attended Moose dojo and I'm pretty impressed with the >> possibilities of GTInspector. The one thing that I've noticed is that both >> GTInspactor and EyeInspector support custom inspections for objects. I'm >> wandering if we can come up with a common protocol to give an object >> specific infector view, and not develop a separate thing for each inspector. >> >> Uko >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

March 7, 2014