May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] does recent changes broke playground with dark theme?

by Marcus Denker

> On 28 May 2015, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm having some forced black fonts there. > Can you confirm it? > I donât see itâ¦ if it is in the code highlighting, it could be related to the highlighter. In the settings you can turn AST based highlighting off to check if that is the source of the problem. Marcus

May 29, 2015

Re: [Pharo-dev] OSWindow and OSWindowDriver

by Matthieu Lacaton

Arf, I failed when I wrote this mail cause I accidently sent it before it was finished :s Could we all use the second one for the discussion please ? I'm sorry :( 2015-05-29 6:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > Thanks matthieu. > This is a good description of our discussion and I did not get the time to > talk with esteban yet. So thanks! > > > Le 29/5/15 00:05, Matthieu Lacaton a Ã©crit : > > Hello everyone, >> >> I'm writing here because I would like some insight about the >> OSWindowDriver. >> >> As you may know, the OSWindowDriver (via OSSDL2Driver) is responsible for >> many things in OSWindow such as setting up the event loop, creating the SDL >> window, etc. >> >> My first question is : How are you supposed to access the driver ? >> >> Currently you can do a "OSWindowDriver current" and it should return you >> the "most suited driver". It is the way the driver is picked if you don't >> specify a preferable driver in the OSWindow attributes. >> I see two problems with this : >> - If you don't have the SDL plugin it returns you an OSWindowNullDriver >> and you cannot do anything with it even if you have the SDL library. >> - Let's say that SDL does not meet my requirements and I create another >> binding to another library. I now have the possibility to use OSWindow with >> two different back-ends. How does the OSWindowDriver discriminates between >> the twos ? >> >> Now if I want to specify a driver I can do it by setting >> "preferableDriver" in the OSWindowAttributes. >> But if I want an OSSDL2Driver, the only way I see for the moment is to >> call "OSSDL2Driver new". >> But by doing so I am creating an instance of the driver per window >> created whereas with "OSWindowDriver current" I am only using one instance >> of the driver for all windows. I think something is not coherent here. >> So should all specific drivers be singletons ? Should they all implement >> their own version of the "current" method returning the only instance of >> them ? >> >> I have another remark too : >> >> The driver needs to keep a map of all active windows to be able to >> dispatch events to the correct one. But when a window is destroyed, it >> needs to be removed from the map so there is no mess in the events and so >> the garbage collector can free it. >> Currently the window map is a class variable of OSSDL2Driver. But I think >> the map should be common to all drivers because they would probably all >> need one. So I'd like to move the WindowMap class variable to the >> "OSWindowDriver" class directly >> > > >

May 29, 2015

Re: [Pharo-dev] OSWindow and OSWindowDriver questions

by Matthieu

Oh, after some reflexion, I don't think it is a good idea anymore to have one window map for all kinds of drivers because if we want to use more than one back-end, the different windows will probably share some IDs so we cannot put them all in the same basket :s It is probably better then to keep a window map per kind of driver but we still need to be able to update it when a window is destroyed. How can we know which map is the correct one and how can we access the correct driver ? -- View this message in context: http://forum.world.st/OSWindow-and-OSWindowDriver-questions-tp4829193p48292… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 29, 2015

Re: [Pharo-dev] OSWindow and OSWindowDriver

by stepharo

Thanks matthieu. This is a good description of our discussion and I did not get the time to talk with esteban yet. So thanks! Le 29/5/15 00:05, Matthieu Lacaton a Ã©crit : > Hello everyone, > > I'm writing here because I would like some insight about the > OSWindowDriver. > > As you may know, the OSWindowDriver (via OSSDL2Driver) is responsible > for many things in OSWindow such as setting up the event loop, > creating the SDL window, etc. > > My first question is : How are you supposed to access the driver ? > > Currently you can do a "OSWindowDriver current" and it should return > you the "most suited driver". It is the way the driver is picked if > you don't specify a preferable driver in the OSWindow attributes. > I see two problems with this : > - If you don't have the SDL plugin it returns you an > OSWindowNullDriver and you cannot do anything with it even if you have > the SDL library. > - Let's say that SDL does not meet my requirements and I create > another binding to another library. I now have the possibility to use > OSWindow with two different back-ends. How does the OSWindowDriver > discriminates between the twos ? > > Now if I want to specify a driver I can do it by setting > "preferableDriver" in the OSWindowAttributes. > But if I want an OSSDL2Driver, the only way I see for the moment is to > call "OSSDL2Driver new". > But by doing so I am creating an instance of the driver per window > created whereas with "OSWindowDriver current" I am only using one > instance of the driver for all windows. I think something is not > coherent here. > So should all specific drivers be singletons ? Should they all > implement their own version of the "current" method returning the only > instance of them ? > > I have another remark too : > > The driver needs to keep a map of all active windows to be able to > dispatch events to the correct one. But when a window is destroyed, it > needs to be removed from the map so there is no mess in the events and > so the garbage collector can free it. > Currently the window map is a class variable of OSSDL2Driver. But I > think the map should be common to all drivers because they would > probably all need one. So I'd like to move the WindowMap class > variable to the "OSWindowDriver" class directly

May 29, 2015

Re: [Pharo-dev] Metacello and #stable

by Dale Henrichs

Ben, Hmmm, I could make the use of #stable a Critical Warning: "MetacelloValidationCriticalWarning indicates that there is a logical inconsistency that may not be intentional and that could cause incorrect loads". I've submitted a Metacello issue #350[1] for this. If I thought that folks regularly used configuration validation, I wouldn't have to do much else:) Of course there are ancient configurations where #stable still must be used. There are validation pragmas that allow one to filter out "know exceptions" for the validator so that only new configs would generate the "critical warning" ... I'm reluctant to go much further than this ... of course tools could be more aggressive in stamping out the use of #stable... Dale [1] https://github.com/dalehenrich/metacello-work/issues/350 On 5/28/15 4:57 PM, Ben Coman wrote: > On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> Andrei, >> >> 1) The old configuration load api is non-deterministic, especially when used >> with large configurations, Metacello will not downgrade a package, so if >> (using the old api) Metacello decides that a newer version of a >> configuration is present, then it will use the newer (and possibly incorrect >> version). Keep in mind that pre-loaded packages in Pharo can influence this >> non-deterministic calculation. >> >> I don't know for certain that using the old API is the culprit. The only way >> for me to understand where the issue might lie is for me to look at the >> Transcript output of a load. >> >> 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not >> actively tested then they are likely to quit working over time and I'd guess >> this is the case for Pharo3.0 and Moose. >> >> 3) using #stable is a very inaccurate way of specifying a symbolic version. >> The Seaside folks have started using version-based symbolic versions like: >> #'release3', #'release3.1', #'release3.2' a while ago and I think this is a >> very good way to leverage symbolic versions ... #stable can be changed and >> in the mind of the developer #stable is now version 4.0.0, while a number of >> older configurations will consider #stable to be version 3.0.0 ... it >> doesn't take long the #stable version universe to be completely confused ... > For a Configuration newbie it may seem intuitive for a Configuration > to dependend on other Configuration's #stable without realising the > hole they are digging. You could say its easy to shoot yourself in > the foot with #stable? So maybe #stable only makes sense as a > *convenience* for interactive users at the "command line." It might > be reasonable for the system to block use of #stable within a > Configuration (with a deprecation warning and bypass method like > #allowNestedStable) > cheers -ben > >> While I suspect that the current #stable version of Moose does not run on >> Pharo3.0, if version-based symbolic versions had been used back then the >> configurations would likely still be usable ... >> >> Again, I am just guessing ... analysis of the Transcript output would give >> me better clues ... >> >> Using the new Metacello scripting API: >> >> Metacello new >> configuration: 'Moose'; >> version: #stable; >> repository: '???'; >> load >> >> does a load without without calculating the #currentVersion and should be >> deterministic with respect to loaded versions ... this only addresses the >> first point above. If points 2 or 3 are involved, then it may be more >> difficult to solve the problem ... >> >> BTW, sorry for taking so long to get back to you ... in the last month I've >> taken a long overdue vacation (and did not even open my laptop:) and have >> been working exclusively on GemStone 3.3 ... I'm nearly finished with my >> main commitments for GemStone 3.3 and as I come up for air, I'm working off >> my email backlog:) >> >> Dale >> >> On 5/18/15 5:56 AM, Andrei Chis wrote: >>> Hi, >>> >>> If I specify a stable version for a platform (spec for: #'pharo3.x' >>> version: '3.0.6'.), shouldn't Metacello load that version? >>> >>> Concrete use-case: loading ConfigurationOfMoose in Pharo 3 >>> - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 >>> - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable >>> - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 >>> (spec for: #'pharo3.x' version: '3.0.6') >>> >>> Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for >>> ConfigurationOfGlamour. >>> Updating Monticello leads to the same result. >>> >>> Did I misunderstood something about how monticello works? >>> Any idea how to debug this? >>> >>> Cheers, >>> Andrei >>> >>> [1] (ConfigurationOfMoose project version: #'stable') record loadDirective >>> >>

May 29, 2015

Re: [Pharo-dev] Metacello and #stable

by Ben Coman

On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Andrei, > > 1) The old configuration load api is non-deterministic, especially when used > with large configurations, Metacello will not downgrade a package, so if > (using the old api) Metacello decides that a newer version of a > configuration is present, then it will use the newer (and possibly incorrect > version). Keep in mind that pre-loaded packages in Pharo can influence this > non-deterministic calculation. > > I don't know for certain that using the old API is the culprit. The only way > for me to understand where the issue might lie is for me to look at the > Transcript output of a load. > > 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not > actively tested then they are likely to quit working over time and I'd guess > this is the case for Pharo3.0 and Moose. > > 3) using #stable is a very inaccurate way of specifying a symbolic version. > The Seaside folks have started using version-based symbolic versions like: > #'release3', #'release3.1', #'release3.2' a while ago and I think this is a > very good way to leverage symbolic versions ... #stable can be changed and > in the mind of the developer #stable is now version 4.0.0, while a number of > older configurations will consider #stable to be version 3.0.0 ... it > doesn't take long the #stable version universe to be completely confused ... For a Configuration newbie it may seem intuitive for a Configuration to dependend on other Configuration's #stable without realising the hole they are digging. You could say its easy to shoot yourself in the foot with #stable? So maybe #stable only makes sense as a *convenience* for interactive users at the "command line." It might be reasonable for the system to block use of #stable within a Configuration (with a deprecation warning and bypass method like #allowNestedStable) cheers -ben > > While I suspect that the current #stable version of Moose does not run on > Pharo3.0, if version-based symbolic versions had been used back then the > configurations would likely still be usable ... > > Again, I am just guessing ... analysis of the Transcript output would give > me better clues ... > > Using the new Metacello scripting API: > > Metacello new > configuration: 'Moose'; > version: #stable; > repository: '???'; > load > > does a load without without calculating the #currentVersion and should be > deterministic with respect to loaded versions ... this only addresses the > first point above. If points 2 or 3 are involved, then it may be more > difficult to solve the problem ... > > BTW, sorry for taking so long to get back to you ... in the last month I've > taken a long overdue vacation (and did not even open my laptop:) and have > been working exclusively on GemStone 3.3 ... I'm nearly finished with my > main commitments for GemStone 3.3 and as I come up for air, I'm working off > my email backlog:) > > Dale > > On 5/18/15 5:56 AM, Andrei Chis wrote: >> >> Hi, >> >> If I specify a stable version for a platform (spec for: #'pharo3.x' >> version: '3.0.6'.), shouldn't Metacello load that version? >> >> Concrete use-case: loading ConfigurationOfMoose in Pharo 3 >> - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 >> - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable >> - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 >> (spec for: #'pharo3.x' version: '3.0.6') >> >> Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for >> ConfigurationOfGlamour. >> Updating Monticello leads to the same result. >> >> Did I misunderstood something about how monticello works? >> Any idea how to debug this? >> >> Cheers, >> Andrei >> >> [1] (ConfigurationOfMoose project version: #'stable') record loadDirective >> > >

May 28, 2015

Re: [Pharo-dev] Metacello and #stable

by Dale Henrichs

Andrei, 1) The old configuration load api is non-deterministic, especially when used with large configurations, Metacello will not downgrade a package, so if (using the old api) Metacello decides that a newer version of a configuration is present, then it will use the newer (and possibly incorrect version). Keep in mind that pre-loaded packages in Pharo can influence this non-deterministic calculation. I don't know for certain that using the old API is the culprit. The only way for me to understand where the issue might lie is for me to look at the Transcript output of a load. 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not actively tested then they are likely to quit working over time and I'd guess this is the case for Pharo3.0 and Moose. 3) using #stable is a very inaccurate way of specifying a symbolic version. The Seaside folks have started using version-based symbolic versions like: #'release3', #'release3.1', #'release3.2' a while ago and I think this is a very good way to leverage symbolic versions ... #stable can be changed and in the mind of the developer #stable is now version 4.0.0, while a number of older configurations will consider #stable to be version 3.0.0 ... it doesn't take long the #stable version universe to be completely confused ... While I suspect that the current #stable version of Moose does not run on Pharo3.0, if version-based symbolic versions had been used back then the configurations would likely still be usable ... Again, I am just guessing ... analysis of the Transcript output would give me better clues ... Using the new Metacello scripting API: Metacello new configuration: 'Moose'; version: #stable; repository: '???'; load does a load without without calculating the #currentVersion and should be deterministic with respect to loaded versions ... this only addresses the first point above. If points 2 or 3 are involved, then it may be more difficult to solve the problem ... BTW, sorry for taking so long to get back to you ... in the last month I've taken a long overdue vacation (and did not even open my laptop:) and have been working exclusively on GemStone 3.3 ... I'm nearly finished with my main commitments for GemStone 3.3 and as I come up for air, I'm working off my email backlog:) Dale On 5/18/15 5:56 AM, Andrei Chis wrote: > Hi, > > If I specify a stable version for a platform (spec for: #'pharo3.x' > version: '3.0.6'.), shouldn't Metacello load that version? > > Concrete use-case: loading ConfigurationOfMoose in Pharo 3 > - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 > - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable > - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 > (spec for: #'pharo3.x' version: '3.0.6') > > Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 > for ConfigurationOfGlamour. > Updating Monticello leads to the same result. > > Did I misunderstood something about how monticello works? > Any idea how to debug this? > > Cheers, > Andrei > > [1] (ConfigurationOfMoose project version: #'stable') record loadDirective >

May 28, 2015

OSWindow and OSWindowDriver questions

by Matthieu Lacaton

Hello everyone, I'm writing here because I would like some insight about the OSWindowDriver. As you may know, the OSWindowDriver (via OSSDL2Driver) is responsible for many things in OSWindow such as setting up the event loop, creating the SDL window, etc. My first question is : How are you supposed to access the driver ? Currently you can do a "OSWindowDriver current" and it should return you the "most suited driver". It is the way the driver is picked if you don't specify a preferable driver in the OSWindow attributes. I see two problems with this : - If you don't have the SDL plugin it returns you an OSWindowNullDriver and you cannot do anything with it even if you have the SDL library. - Let's say that SDL does not meet my requirements and I create another binding to another library. I now have the possibility to use OSWindow with two different back-ends. How does the OSWindowDriver discriminates between the twos ? Now if I want to specify a driver I can do it by setting "preferableDriver" in the OSWindowAttributes. But if I want an OSSDL2Driver, the only way I see for the moment is to call "OSSDL2Driver new". But by doing so I am creating an instance of the driver per window created whereas with "OSWindowDriver current" I am only using one instance of the driver for all windows. I think something is not coherent here. So should all specific drivers be singletons ? Should they all implement their own version of the "current" method returning the only instance of them ? I have another remark too : The driver needs to keep a map of all active windows to be able to dispatch events to the correct one. But when a window is destroyed, it needs to be removed from the map so there is no mess in the events and so the garbage collector can free it. Currently the window map is a class variable of OSSDL2Driver. But I think the map should be common to all drivers because they would probably all need one. So I'd like to move the WindowMap class variable to the "OSWindowDriver" class directly with a class method to remove the selected window from it. That way when a window is destroyed, we just have to call this class method and it is easy. What do you think about it ? I hope I was clear enough for you to understand. I would just like to know the best way to "fix" these things. And If I am totally wrong and there is a precise way to deal with this, please let me know :) Thanks a lot, Matthieu

May 28, 2015

OSWindow and OSWindowDriver

by Matthieu Lacaton

Hello everyone, I'm writing here because I would like some insight about the OSWindowDriver. As you may know, the OSWindowDriver (via OSSDL2Driver) is responsible for many things in OSWindow such as setting up the event loop, creating the SDL window, etc. My first question is : How are you supposed to access the driver ? Currently you can do a "OSWindowDriver current" and it should return you the "most suited driver". It is the way the driver is picked if you don't specify a preferable driver in the OSWindow attributes. I see two problems with this : - If you don't have the SDL plugin it returns you an OSWindowNullDriver and you cannot do anything with it even if you have the SDL library. - Let's say that SDL does not meet my requirements and I create another binding to another library. I now have the possibility to use OSWindow with two different back-ends. How does the OSWindowDriver discriminates between the twos ? Now if I want to specify a driver I can do it by setting "preferableDriver" in the OSWindowAttributes. But if I want an OSSDL2Driver, the only way I see for the moment is to call "OSSDL2Driver new". But by doing so I am creating an instance of the driver per window created whereas with "OSWindowDriver current" I am only using one instance of the driver for all windows. I think something is not coherent here. So should all specific drivers be singletons ? Should they all implement their own version of the "current" method returning the only instance of them ? I have another remark too : The driver needs to keep a map of all active windows to be able to dispatch events to the correct one. But when a window is destroyed, it needs to be removed from the map so there is no mess in the events and so the garbage collector can free it. Currently the window map is a class variable of OSSDL2Driver. But I think the map should be common to all drivers because they would probably all need one. So I'd like to move the WindowMap class variable to the "OSWindowDriver" class directly

May 28, 2015

Re: [Pharo-dev] Beyond RPackages: RPackageTag and DynamicGroup

by Sergio Fedi

On Thu, May 28, 2015 at 9:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, May 28, 2015 at 5:48 PM, Sergio Fedi <sergio.fedi(a)gmail.com> > wrote: > > (Personally I have no idea of Work criteria to list classes, and have no > > idea of the details of the other two) > > Neither do I. Never used them. Now I wonder if when you define a new > group, you might also define a filter and the existing groups use that > facility, such that you could inspect and existing group to see its > definition. > This is why we need comments on DynamicGroups

May 28, 2015