[ann] spotter processors as settings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[ann] spotter processors as settings

Tudor Girba-2
Hi,

We now have a new little feature in Spotter. Take a look:



Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore.

Please give this a try and let us know what you think.

We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector.

Cheers,
Doru



--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [ann] spotter processors as settings

Uko2
This is nice.

I have not used moose image for a long time, but spotter seams really slow. Can this be because of the settings feature?

One thing interesting for me, is how can we collaborate on a certain setting. Because I have a setting for the spotter extension of QA, and I do it in an ugly way. But I’d still like to be able to provide the setting in the QA group, so people can control all the plugins from the same place.

Can you give me some API to check/disable/enable a certain extension, so I can use it with my setting? I.e. can I rely on “doesNotUnderstand:”? :)

Cheers.
Uko

On 22 Jan 2016, at 09:14, Tudor Girba <[hidden email]> wrote:

Hi,

We now have a new little feature in Spotter. Take a look:

<spotter-settings.png>

Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore.

Please give this a try and let us know what you think.

We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector.

Cheers,
Doru



--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [ann] spotter processors as settings

Tudor Girba-2
Hi,


> On Jan 22, 2016, at 9:28 AM, Yuriy Tymchuk <[hidden email]> wrote:
>
> This is nice.
>
> I have not used moose image for a long time, but spotter seams really slow. Can this be because of the settings feature?

Could you be more specific? When is it slow?

> One thing interesting for me, is how can we collaborate on a certain setting. Because I have a setting for the spotter extension of QA, and I do it in an ugly way. But I’d still like to be able to provide the setting in the QA group, so people can control all the plugins from the same place.
>
> Can you give me some API to check/disable/enable a certain extension, so I can use it with my setting? I.e. can I rely on “doesNotUnderstand:”? :)

In the latest version, I added two methods that allow you to enable/disable processors programmatically:

m := Behavior>>#spotterClassInstanceVariablesFor:.
GTSpotterExtensionSettings disableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
 "true".

GTSpotterExtensionSettings enableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
 “false"

Cheers,
Doru

> Cheers.
> Uko
>
>> On 22 Jan 2016, at 09:14, Tudor Girba <[hidden email]> wrote:
>>
>> Hi,
>>
>> We now have a new little feature in Spotter. Take a look:
>>
>> <spotter-settings.png>
>>
>> Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore.
>>
>> Please give this a try and let us know what you think.
>>
>> We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Quality cannot be an afterthought."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [ann] spotter processors as settings

Uko2

On 22 Jan 2016, at 11:05, Tudor Girba <[hidden email]> wrote:

Hi,


On Jan 22, 2016, at 9:28 AM, Yuriy Tymchuk <[hidden email]> wrote:

This is nice.

I have not used moose image for a long time, but spotter seams really slow. Can this be because of the settings feature?

Could you be more specific? When is it slow?

I don’t know how specific it is, but when you just open the spotter it shows you some information like menu, mc, and so on. Usually it’s almost instant. But in todays Moose image it took like 5-10 sec and my fan started to spin fast (maybe a coincidence).


One thing interesting for me, is how can we collaborate on a certain setting. Because I have a setting for the spotter extension of QA, and I do it in an ugly way. But I’d still like to be able to provide the setting in the QA group, so people can control all the plugins from the same place.

Can you give me some API to check/disable/enable a certain extension, so I can use it with my setting? I.e. can I rely on “doesNotUnderstand:”? :)

In the latest version, I added two methods that allow you to enable/disable processors programmatically:

m := Behavior>>#spotterClassInstanceVariablesFor:.
GTSpotterExtensionSettings disableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
"true".

GTSpotterExtensionSettings enableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
“false”

Thanks I’ll give it a shot.
Cheers.
Uko


Cheers,
Doru

Cheers.
Uko

On 22 Jan 2016, at 09:14, Tudor Girba <[hidden email]> wrote:

Hi,

We now have a new little feature in Spotter. Take a look:

<spotter-settings.png>

Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore.

Please give this a try and let us know what you think.

We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector.

Cheers,
Doru



--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [ann] spotter processors as settings

Uko2
In reply to this post by Tudor Girba-2

On 22 Jan 2016, at 11:05, Tudor Girba <[hidden email]> wrote:

Hi,


On Jan 22, 2016, at 9:28 AM, Yuriy Tymchuk <[hidden email]> wrote:

This is nice.

I have not used moose image for a long time, but spotter seams really slow. Can this be because of the settings feature?

Could you be more specific? When is it slow?

I don’t know how specific it is, but when you just open the spotter it shows you some information like menu, mc, and so on. Usually it’s almost instant. But in todays Moose image it took like 5-10 sec and my fan started to spin fast (maybe a coincidence).


One thing interesting for me, is how can we collaborate on a certain setting. Because I have a setting for the spotter extension of QA, and I do it in an ugly way. But I’d still like to be able to provide the setting in the QA group, so people can control all the plugins from the same place.

Can you give me some API to check/disable/enable a certain extension, so I can use it with my setting? I.e. can I rely on “doesNotUnderstand:”? :)

In the latest version, I added two methods that allow you to enable/disable processors programmatically:

m := Behavior>>#spotterClassInstanceVariablesFor:.
GTSpotterExtensionSettings disableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
"true".

GTSpotterExtensionSettings enableProcessorDefinedInMethod: m.
GTSpotterExtensionSettings shouldSpotterIgnoreProcessorDefinedInMethod: m
“false”

Thanks I’ll give it a shot.
Cheers.
Uko


Cheers,
Doru

Cheers.
Uko

On 22 Jan 2016, at 09:14, Tudor Girba <[hidden email]> wrote:

Hi,

We now have a new little feature in Spotter. Take a look:

<spotter-settings.png>

Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore.

Please give this a try and let us know what you think.

We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector.

Cheers,
Doru



--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev