On 17 May 2013 09:10, Esteban Lorenzano <[email protected]> wrote: > > On May 16, 2013, at 11:53 PM, Igor Stasenko <[email protected]> wrote: > >> On 15 May 2013 09:37, Esteban Lorenzano <[email protected]> wrote: >>> >>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[email protected]> wrote: >>> >>>> How did you loaded NBOpenGL? >>>> For 2.0/3.0 pharo image use >>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> I added this important piece of information into >>> http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>> It would be a lot better to make >>> >>> ConfigurationOfNBOpenGL load. >>> >> >> unless you put a lot of complex logic behind that "load", >> it will never work. > > Why? > load should be > > ConfigurationOfNBOpenGL class>>#load > ^ self project stableVersion load. > > and nothing else
the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default. > >> That's why i prefer to giving a version numbers. This version of >> config works with 2.0 image, >> and no pain, no surprises. >> Now, when people get used to do "ConfigurationOfNBOpenGL load" >> it is less pain, but just for the next major update of whatever >> infrastructural parts in Pharo. > > again... why? > Because what happens now is that people try to do what is the convention for > metacello. Also, that means that by not following the conventions, NBOpenGL > will never be able to be loaded through configuration browser :( > hmm, why i cannot specify in config browser that for given version of image use this version of library? >> >> And second, for me, as developer , it is much more helpful to deal >> with problem reports like: >> "this version doesn't loads/works with this version of image" >> instead of "i tried and it doesn't works" :) > > he, I'm sorry, I disagree... > If you as a developer promote a version as a release by assigning a #stable > symbolic version to configuration, you know exactly which version the guy is > trying to load. > And you will not have the problem "this version does not loads...", which is > a consequence of not declaring a version as stable for a platform. Looks to > me that the problem you try to avoid is in fact happening because the > configuration is not adapted to the convention, not the opposite :) > As proof... lot's of complex project follow the convention (seaside, for > example), and nobody has the issue you say. Recently they prepared the > configuration for 2.0, and that means that seaside now loads fine in 1.4 and > 2.0.... > Okay, then i will ask you to help making it working for 2.0 an 3.0 (we can ignore 1.4 i think). And here again, how you propose to deal with situation that i wanna discontinue support for 1.4 (so , if you do just #load, in 1.4 image it won't work, because latest #stable version does not supports that version of Pharo anymore).. Now if you specify exact version which still supports 1.4 you can load and use it. So, what is your recipe for this situation? Writing case statements? MyConfig>>stableVersion Smalltalk version = 1.4 ifTrue: [ ^ '0.4' ]. Smalltalk version = 2.0 ifTrue: [ ^ '0.8' ]. Smalltalk version = 3.0 ifTrue: [ ^ '1.8' ]. i can do that, if you insist.. but that IMO, defeats purpose of using Metacello. Because once you start with adding ugly if/case statements, they will tend to grow larger and larger over time.. and we end up with something like linux configure scripts.. > cheers, > Esteban > -- Best regards, Igor Stasenko.
