- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] The Garage database driver API

by Sean P. DeNigris

Guillermo Polito wrote > Can you open an issue so I do not forget? https://github.com/guillep/DBXTalk/issues/6 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-The-Garage-database-driver-API-tp4825006p4825069.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 7, 2015

Re: [Pharo-dev] Selected context specific debugger action

by Eliot Miranda

Hi Tudor, could you describe the client-side API and give some examples? I'm in squeak most if the time so GT is not easily accessible but perhaps the facility could be back ported. I'd love to have this facility for making the CM simulator easier to step through. Eliot (phone) On May 7, 2015, at 7:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > You should be able to do that in the GTDebugger (it was made exactly for that). > > Doru > > On Thu, May 7, 2015 at 4:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Hi, >> >> is it possible to have a debugger action specific for selected context? I.e. define label, icon, whether the action is visible depending on the selected context? >> >> Uko > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

May 7, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

Independent of package comments, the ManifestClasses are a good idea I think. I also think they have not yet found their final design. Let me summarize my impressions so far (perhaps this need to go to a different thread). a) All package manifests are subclasses of "PackageManifest" - good idea. b) The principle of storing the manifest properties as literals in methods is surprising, but has its advantages. However, no general functionality for storing those values seems to be in place. c) The class "TheManifestBuilder" seems to be a key class, and has a lot of functionality for the quality assistant (I presume that is what they are used for - I have not looked in that corner of the system yet). I think the manifest builder need to be split into a family of builders, a general builder which has the functionality to create and query manifest classes, and a set of builders for each (set of) properties of manifest classes. The QualityAssistant would then have its own subclass, and package comments would have its subclass. For now, I believe I will experiment with merely having a package comment category on TheManifestBuilder. -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4825058.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 7, 2015

Re: [Pharo-dev] Selected context specific debugger action

by Andrei Chis

Where do you want these actions to be placed? In the menu of the stack or next to the stepInto/Over etc buttons? Cheers, Andrei On Thu, May 7, 2015 at 4:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > is it possible to have a debugger action specific for selected context? > I.e. define label, icon, whether the action is visible depending on the > selected context? > > Uko >

May 7, 2015

Re: [Pharo-dev] Selected context specific debugger action

by Yuriy Tymchuk

This is cool, but the sad thing is that by default it is not a default tool that Pharoers use. Uko > On 07 May 2015, at 16:39, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > You should be able to do that in the GTDebugger (it was made exactly for that). > > Doru > > On Thu, May 7, 2015 at 4:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi, > > is it possible to have a debugger action specific for selected context? I.e. define label, icon, whether the action is visible depending on the selected context? > > Uko > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

May 7, 2015

Re: [Pharo-dev] Selected context specific debugger action

by Tudor Girba

You should be able to do that in the GTDebugger (it was made exactly for that). Doru On Thu, May 7, 2015 at 4:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > is it possible to have a debugger action specific for selected context? > I.e. define label, icon, whether the action is visible depending on the > selected context? > > Uko > -- www.tudorgirba.com "Every thing has its own flow"

May 7, 2015

Selected context specific debugger action

by Yuriy Tymchuk

Hi, is it possible to have a debugger action specific for selected context? I.e. define label, icon, whether the action is visible depending on the selected context? Uko

May 7, 2015

Re: [Pharo-dev] Package comments

by Yuriy Tymchuk

Hi, as you know Iâm working on QualityAssistant, and at the moment the current structure of false positives in Manifest in not good enough for me. So I plant to reimplement it. Should I follow some guidelines? Because you are introducing this new package manifest, and I think that it could make sense if Iâll give you a feedback whether I works well for my needs. Uko > On 06 May 2015, at 13:56, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 6 mai 2015 Ã 13:21, Kasper Osterbye a Ã©crit : > >> demarey wrote >>> If you want to allow package comments in Nautilus, I would display the >>> content of the description method of the package manifest if available. >> >> It would be great to leverage on something already taking place. >> Are you talking about class PackageManifest? >> I can see that RPackage has a method which will give me a PackageManifest >> (or create a new one). I have not been able to spot "the description method >> of the package manifest" (as mentioned by Marcus). Mostly those Manifest >> classes seems to be used for other purposes than documentation. > > Manifest classes were introduced to manage code critics false positives. > >> I'll try out a few things to see how it can work, my reading of the >> "TheManifestBuilder>>createManifestNamed:" shows that manifests would be >> very suited for this documentation purpose, as it actually create a >> ManifestClass in the package. I believe this class is stored in Monticello >> like any other class. > > right > >> For the time being I found no instances of PackageManifest, so it is a bit >> unclear to me how these Manifest classes store any data? > > > Indeed. > There are PackageManifest classes only for projects managing code critics false positives. > I created the PackageManifest class to start the decoupling between the manifest and critics, but there is not yet a lot of other tools / project using it (but it will come). > > Data is stored in raw strings in methods (instance side) of the Manifest. > ex: > ManifestKernel>>#description > ^ 'I am the description of the Pharo Kernel package.'

May 7, 2015

Re: [Pharo-dev] external package handling ... a concrete case

by Andrei Chis

In the meantime can you let us know when you integrate a slice for a project managed through configurations. I cannot guess when this happens. On Wed, May 6, 2015 at 11:24 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 6/5/15 22:37, Esteban Lorenzano a Ã©crit : > >> but that happens because GTools guys made a mistake: >> >> spotterActDefault >> ^ Smalltalk tools browser openOnPackage: self >> >> thatâs the correct implementation of that method. >> > > Ok but I do not care. This is just an example of the problem. > I will **not** publish the GTSpotter code nor update the configuration > because I do know the internal of GT. > If I would be maintaining an external pharo tool I would hate that > somebody publish random code to it. > The configuration of spotter and of any other project from gt is nothing special nor complicated. Feel free to update it or push changes directly to the repo at any time. You'll get no complaints from us :) Cheers, Andrei > > When we publish a change in Pharo for external tools this is like a pull > request! > > Stef > > >> Esteban >> >> On 06 May 2015, at 22:14, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi guys >>> >>> I'm cleaning nautilus model and Spotter is extended. >>> Now I will not publish the fix in Spotter, I will not update a >>> configuration of a tool I do not know. >>> So what should I do, stop working? No this is not possible. So I will >>> push this changes in the inbox and >>> integrate it and GT people should merge the fix in their baseline when >>> they want. >>> Or I will really stop doing anything for Pharo 50 alpha. >>> >>> Stef >>> >>> spotterActDefault >>> ^ Nautilus openOnPackage: self >>> >>> >> >> > >

May 7, 2015

Re: [Pharo-dev] Debugger hangs vm on step into

by Alain Rastoul

Le 05/05/2015 14:35, Ben Coman a Ã©crit : > Not sure if this is related, but if you put a haltOnce at the top of > SpecDebugger>>updateReceiverInspectorFromContext: > then step down until the 'receiver' temporary variable is set, > then inspect 'receiver', the system hangs. > cheers -ben > > After digging into it, the cause of the hang is now obvious, but the simplest solution makes me perplex and does not cover other cases (ProcessLocalVariables, see below). The problem comes from the display of the object in the lower pane of the debugger that locks itself because the monitor is owned by the debugged process. (the inspector ends up in a call to xxx>>printOn: aStream to display the object and SharedQueue>>printOn: aStream starts with a critical block on the monitor). So we could be hanged in various ways : clicking on the debugger stack on the Sharedqueue context, opening an inspector on the Sharedqueue etc). A simple solution is to evaluate the printOn: in the context of the owner process in SharedQueue (tested and works), but it is specific to SharedQueue. When an inspector ask an object to print itself, it does not take into account the "effective/owner process " part of the object. For example for ProcessLocalVariable (and descendants) it does not work: | process variable | process := [ variable := ProcessLocalVariable value: 'hello world' ] forkAt: Processor userInterruptPriority . variable value => evaluates to nil this makes it difficult (impossible ?) to inspect/debug - a workaround would be to track the effective process near the host in the inspector (in AbstractEyeElement?) but it could be tricky and I do not know implications here. Any comment/idea/advice is welcome I can submit the workaround specific to SharedQueue in the meantime. TIA -- Regards, Alain

May 7, 2015