Hi I bumped into a broken setting in FFI (see attached Screenshot). After I exported the settings, every time I open an image a DNU comes to greet me: NBGlxAPI class>>moduleName:
From the implementation, it seems the setting does not make much sense. Or if it does to somebody, it is probably still missing some part.
Cheers Ricky
thatâs not FFI, is NBOpenGL :)
On 07 Apr 2015, at 14:35, Richard Wettel <wettel@gmail.com> wrote:
Hi
I bumped into a broken setting in FFI (see attached Screenshot). After I exported the settings, every time I open an image a DNU comes to greet me:
NBGlxAPI class>>moduleName:
From the implementation, it seems the setting does not make much sense. Or if it does to somebody, it is probably still missing some part.
Cheers Ricky
<ffiSetting.PNG>
This setting should be removed. Does anyone have anything against that? Doru On Tue, Apr 7, 2015 at 2:45 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
thatâs not FFI, is NBOpenGL :)
On 07 Apr 2015, at 14:35, Richard Wettel <wettel@gmail.com> wrote:
Hi
I bumped into a broken setting in FFI (see attached Screenshot). After I exported the settings, every time I open an image a DNU comes to greet me:
NBGlxAPI class>>moduleName:
From the implementation, it seems the setting does not make much sense. Or if it does to somebody, it is probably still missing some part.
Cheers Ricky
<ffiSetting.PNG>
-- www.tudorgirba.com "Every thing has its own flow"
Le 07/04/2015 15:14, Tudor Girba a écrit :
This setting should be removed. Does anyone have anything against that?
Or, could settings be rewritten so that we don't regularly triggers DNUs and MNUs when we reload them? You know, just regular, declarative, boring settings instead of something which execute code on non-existent Classes half of the time... Thierry
Doru
On Tue, Apr 7, 2015 at 2:45 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
thatâs not FFI, is NBOpenGL :)
> On 07 Apr 2015, at 14:35, Richard Wettel <wettel@gmail.com <mailto:wettel@gmail.com>> wrote: > > Hi > > I bumped into a broken setting in FFI (see attached Screenshot). > After I exported the settings, every time I open an image a DNU comes to greet me: > > NBGlxAPI class>>moduleName: > > From the implementation, it seems the setting does not make much sense. Or if it does to somebody, it is probably still missing some part. > > Cheers > Ricky > > <ffiSetting.PNG>
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Le 7/4/15 15:19, Thierry Goubier a écrit :
Le 07/04/2015 15:14, Tudor Girba a écrit :
This setting should be removed. Does anyone have anything against that?
Or, could settings be rewritten so that we don't regularly triggers DNUs and MNUs when we reload them?
You know, just regular, declarative, boring settings instead of something which execute code on non-existent Classes half of the time...
We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check. It is called cocoon on pharoextras Stef
Thierry
Doru
On Tue, Apr 7, 2015 at 2:45 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
thatâs not FFI, is NBOpenGL :)
> On 07 Apr 2015, at 14:35, Richard Wettel <wettel@gmail.com <mailto:wettel@gmail.com>> wrote: > > Hi > > I bumped into a broken setting in FFI (see attached Screenshot). > After I exported the settings, every time I open an image a DNU comes to greet me: > > NBGlxAPI class>>moduleName: > > From the implementation, it seems the setting does not make much sense. Or if it does to somebody, it is probably still missing some part. > > Cheers > Ricky > > <ffiSetting.PNG>
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Le 09/04/2015 16:10, stepharo a écrit :
Le 7/4/15 15:19, Thierry Goubier a écrit :
Le 07/04/2015 15:14, Tudor Girba a écrit :
This setting should be removed. Does anyone have anything against that?
Or, could settings be rewritten so that we don't regularly triggers DNUs and MNUs when we reload them?
You know, just regular, declarative, boring settings instead of something which execute code on non-existent Classes half of the time...
We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check.
It is called cocoon on pharoextras
Seems fine. Just browsing through it. Maybe a tad complex, to have to subclass both a CCConfiguration and a CCSTONConfigurationInterpreter for the thing to work. Flexible and powerfull. Composable. Is missing some of the code needed for settings: a default place to store them, the GUI part (settings browser), and the logic run-once. As the previous one, gives the feeling that settings are not application driven, but system driven (and applications are passive receivers). It's a design choice, and I'm not entirely happy with that choice, because it has a tendency to force decoupling layers in apps so that they can control if and when they take in account external settings or in-image settings changes. Thierry
Le 09/04/2015 16:10, stepharo a écrit :
Le 7/4/15 15:19, Thierry Goubier a écrit :
Le 07/04/2015 15:14, Tudor Girba a écrit :
This setting should be removed. Does anyone have anything against that?
Or, could settings be rewritten so that we don't regularly triggers DNUs and MNUs when we reload them?
You know, just regular, declarative, boring settings instead of something which execute code on non-existent Classes half of the time...
We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check.
It is called cocoon on pharoextras
Small remark on the documentation on Smalltalkhub: it is STON-based, not JSON-based. Will you make this an item (replace settings by Cocoon) on the roadmap for Pharo5? I know I would. Thierry
We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check.
It is called cocoon on pharoextras
Small remark on the documentation on Smalltalkhub: it is STON-based, not JSON-based.
Will you make this an item (replace settings by Cocoon) on the roadmap for Pharo5? I know I would.
you mean saving settings with Cocoon? Not sure because somebody should do it and my plate will quite full
Thierry
Le 09/04/2015 22:40, stepharo a écrit :
We started to extract tge configuration code out of pillar but we do not know if it will work for settings. So far no time to check.
It is called cocoon on pharoextras
Small remark on the documentation on Smalltalkhub: it is STON-based, not JSON-based.
Will you make this an item (replace settings by Cocoon) on the roadmap for Pharo5? I know I would.
you mean saving settings with Cocoon? Not sure because somebody should do it and my plate will quite full
Fair enough. But at least could we integrate it in Pharo5 to allow apps to use it? Thierry
participants (5)
-
Esteban Lorenzano -
Richard Wettel -
stepharo -
Thierry Goubier -
Tudor Girba