[squeak-dev] Re: [Pkg] FreeTypePlus
Locked
 
|
Welcome to packages!
Rob Rothwell wrote: > It seems that FreeTypePlus has disappeared from PackagesSqueak39? I had a check through the history of PackagesSqueak39, and I can't see FreeTypePlus in the history. > If I try to load it into a level playing field-ed > sq3.9.1-7075dev08.05.2.image: > > (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st > <http://installer.pbwiki.com/f/LPF.st>') readStream fileIn. > Installer install: 'Packages'. > Installer sake addPackage: 'FreeTypePlus'; install. That's the right loading code... so we need to see where Andrew did put the package definition. To see all definitions in all versions load: Installer install: 'PackagesAllVersions'. We find that it is available in PackagesSqueak310U as the universes definition, but Andrew put an improved specific version into PackagesSqueak310. So... we copy the definition to PackagesSqueak39, with its dependents, FFI, and "FreeType Plusplugins". Then we can check to see if Andrew has any more recent versions... in www.squeaksource.com/FreeTypePlus and we copy the definition of 'FreeType Plus' to PackagesSqueak39beta, and PackagesSqueak310beta but we change the load script to load whatever is the latest from squeaksource, rather than the package on SqueakMap. Here is one of those finer points I mentioned. Packages beta load: 'FreeType Plus'. Runs this non-specific "load the latest" script, but any dependencies which are not defined in PackagesSqueak39beta, are supplied by falling back to using 'Packages current'. > ...it is nowhere to be found... > > Is this the right place to point this out? > > Also, I am moderately interested in the call to assist maintaining > sake packages, but I am concerned that I am just Moderately interested is good! > not that good of a Squeaker! On the other hand, I spend an awful lot > of time being frustrated that you can't just There is not a lot of coding needed, its just copy and paste and some testing (hopefully we will get some of the testing automated in the long run) > start from a published image and install the packages you need and > have them work... One of the things I am aiming to facilitate to move squeak forward is the ability to harness even the smallest contributions to the greater good. so welcome aboard! cheers Keith > Thanks, > > Rob Rothwell |
[squeak-dev] Re: [Pkg] FreeTypePlus
|
|
"Keith Hodges" <[hidden email]> wrote in message news:[hidden email]... > Welcome to packages! > > Rob Rothwell wrote: >> It seems that FreeTypePlus has disappeared from PackagesSqueak39? > I had a check through the history of PackagesSqueak39, and I can't see > FreeTypePlus in the history. >> If I try to load it into a level playing field-ed >> sq3.9.1-7075dev08.05.2.image: >> >> (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st >> <http://installer.pbwiki.com/f/LPF.st>') readStream fileIn. >> Installer install: 'Packages'. >> Installer sake addPackage: 'FreeTypePlus'; install. > That's the right loading code... so we need to see where Andrew did put > the package definition. > > To see all definitions in all versions load: > > Installer install: 'PackagesAllVersions'. > > We find that it is available in PackagesSqueak310U as the universes > definition, but Andrew put an improved specific version into > PackagesSqueak310. No I didn't. I put it into a new class, PackagesSqueak310dev0804 Because it is NOT for 3.10 , it is ONLY for developer Squeak sq3.10-7159dev08.04.1 It might work with other images, but it might not. It might work with future releases of developer Squeak, but it might not. It solves the specific problem of - "FreeType Plus won't load into sq3.10-7159dev08.04.1 because MC1.5 doesn't run postscripts, initializes classes in a different order, and fails to load FFI" . I anticipate that that problem will be solved with future versions of MC1.5 and/or FFI and/or FreeType Plus, at which point my script will only be of historical interest. I think something is missing here. How can the appropriate installer be found for a specific version, of a particular fork/distribution, that is itself based upon some core Squeak image? e.g. sq3.10-7159dev08.04.1 is based upon sq3.10-7159 . There are multiple version identifiers here... distributionName=DeveloperSqueak distributionVersion=08.04.01 coreImageName=Squeak coreImageVersion=3.10 coreImageBuild=7159 coreImageReleaseStatus=beta In the future, as the core image shrinks, I can imagine someone creating a distribution based on another distribution based on some fork and so on. So there would be a chain of version identifiers, e.g. ... MyApplication.2.0.1alpha <- SpecialFork.1.0beta <- DeveloperSqueak08.04.01 <- sq3.10-7159 If this version chain was embedded in each image, could Installer use it to find the most appropriate install script for each package? > > So... we copy the definition to PackagesSqueak39, with its dependents, > FFI, and "FreeType Plusplugins". > > Then we can check to see if Andrew has any more recent versions... in > www.squeaksource.com/FreeTypePlus > > and we copy the definition of 'FreeType Plus' to PackagesSqueak39beta, and > PackagesSqueak310beta but we change the load script to load whatever is > the latest from squeaksource, rather than the package on SqueakMap. That's a bit dangerous. The latest on SqueakSource will almost certainly be full of bugs, and might contain experimental code that does outrageous things. Like deleting all the font files from your disk, and installing a new set from DodgyFreeFonts.org . It doesn't, but you get my point :) Cheers, Andy |
Re: [squeak-dev] Re: [Pkg] FreeTypePlus
|
|
El 5/18/08 5:23 AM, "Andrew Tween" <[hidden email]> escribió: > > "Keith Hodges" <[hidden email]> wrote in message > news:[hidden email]... >> Welcome to packages! >> >> Rob Rothwell wrote: >>> It seems that FreeTypePlus has disappeared from PackagesSqueak39? >> I had a check through the history of PackagesSqueak39, and I can't see >> FreeTypePlus in the history. >>> If I try to load it into a level playing field-ed >>> sq3.9.1-7075dev08.05.2.image: >>> >>> (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st >>> <http://installer.pbwiki.com/f/LPF.st>') readStream fileIn. >>> Installer install: 'Packages'. >>> Installer sake addPackage: 'FreeTypePlus'; install. >> That's the right loading code... so we need to see where Andrew did put >> the package definition. >> >> To see all definitions in all versions load: >> >> Installer install: 'PackagesAllVersions'. >> >> We find that it is available in PackagesSqueak310U as the universes >> definition, but Andrew put an improved specific version into >> PackagesSqueak310. > > No I didn't. > I put it into a new class, PackagesSqueak310dev0804 > Because it is NOT for 3.10 , it is ONLY for developer Squeak > sq3.10-7159dev08.04.1 > > It might work with other images, but it might not. > It might work with future releases of developer Squeak, but it might not. > > It solves the specific problem of - "FreeType Plus won't load into > sq3.10-7159dev08.04.1 > because MC1.5 doesn't run postscripts, initializes classes in a different > order, and fails to load FFI" . > > I anticipate that that problem will be solved with future versions of MC1.5 > and/or FFI and/or FreeType Plus, at which point my script will only be of > historical interest. > > I think something is missing here. > How can the appropriate installer be found for a specific version, of a > particular fork/distribution, that is itself based upon some core Squeak > image? > e.g. sq3.10-7159dev08.04.1 is based upon sq3.10-7159 . > There are multiple version identifiers here... > distributionName=DeveloperSqueak > distributionVersion=08.04.01 > coreImageName=Squeak > coreImageVersion=3.10 > coreImageBuild=7159 > coreImageReleaseStatus=beta > > In the future, as the core image shrinks, I can imagine someone creating a > distribution based on another distribution based on some fork and so on. > So there would be a chain of version identifiers, e.g. ... > > MyApplication.2.0.1alpha <- SpecialFork.1.0beta <- > DeveloperSqueak08.04.01 <- sq3.10-7159 > > If this version chain was embedded in each image, could Installer use it to > find the most appropriate install script for each package? > >> >> So... we copy the definition to PackagesSqueak39, with its dependents, >> FFI, and "FreeType Plusplugins". >> >> Then we can check to see if Andrew has any more recent versions... in >> www.squeaksource.com/FreeTypePlus >> >> and we copy the definition of 'FreeType Plus' to PackagesSqueak39beta, and >> PackagesSqueak310beta but we change the load script to load whatever is >> the latest from squeaksource, rather than the package on SqueakMap. > > That's a bit dangerous. > The latest on SqueakSource will almost certainly be full of bugs, and might > contain experimental code that does outrageous things. > Like deleting all the font files from your disk, and installing a new set > from DodgyFreeFonts.org . > It doesn't, but you get my point :) > > Cheers, > Andy And is why I against Installer and other scripting things which IMHO is like GOTO or modern Pandora box. Some was scared for me trying to show we could have four branches of images SqueakFoo - basic . Meaning bussiness as usual. SqueakFooWT Meaning image witout traits SqueakFooMC2 Meaning image developed with MC2 (My personal pick) SqueakFooDS Meaning image developed with DS Andrew here show we could have a Big Bang effect of countless variations and only few experts could know how to survive in this scenario. The way to the heaven is hard and full of troubles. The way to the hell is always the easier one. Edgar |
|
|
In reply to this post by Andrew Tween
Hi Andrew,
Some good points... > It might work with other images, but it might not. > It might work with future releases of developer Squeak, but it might not. > > It solves the specific problem of - "FreeType Plus won't load into > sq3.10-7159dev08.04.1 > because MC1.5 doesn't run postscripts, initializes classes in a > different order, and fails to load FFI" . > MC1.5 does now run postscripts (it should have always run postscripts) > I anticipate that that problem will be solved with future versions of > MC1.5 and/or FFI and/or FreeType Plus, at which point my script will > only be of historical interest. agreed. > I think something is missing here. > How can the appropriate installer be found for a specific version, of > a particular fork/distribution, that is itself based upon some core > Squeak image? > e.g. sq3.10-7159dev08.04.1 is based upon sq3.10-7159 . > There are multiple version identifiers here... > distributionName=DeveloperSqueak > distributionVersion=08.04.01 > coreImageName=Squeak > coreImageVersion=3.10 > coreImageBuild=7159 > coreImageReleaseStatus=beta Which means to me that this is getting impossible, so we need to switch tactics. Perhaps it is time to start thinking about image "capabilities". Plan A. Let's note, if sq3.10-7159dev08.04.1 is based upon sq3.10-7159, and is an assembly of packages, then it is simply a collection of packages with dependencies, and our package simply keeps up the tradition. If it doesn't have what it needs the dependency system takes care of that. Plan B - Basic Capabilities Each package nominates a "provides list". Normally a package provides "itself", however it can provide any "capability". So for example "Magma server" and "Magma client" both provide "Magma", an abstract capability. Packages that need "Magma" capability put "Magma" in their dependsOn: list and will not load unless "Magma" is provided. Which provider of "Magma" is left to the installers choice. Plan C - Detailed Capabilities We are using Sake as a basis for this whole system so we are not just limited to depending upon Sake/Packages tasks. We can specify dependencies upon the existence of a particular Class, Package, File or Method. task dependsOn: { (SakeTask class: 'UUniverse') exists }. > In the future, as the core image shrinks, I can imagine someone > creating a distribution based on another distribution based on some > fork and so on. > So there would be a chain of version identifiers, e.g. ... > > MyApplication.2.0.1alpha <- SpecialFork.1.0beta <- > DeveloperSqueak08.04.01 <- sq3.10-7159 > > If this version chain was embedded in each image, could Installer use > it to find the most appropriate install script for each package? set to.... 1. installer.pbwiki.com/ Page - Smalltalk version - author initials 2. installer.pbwiki.com/ Page - Smalltalk version 3. installer.pbwiki.com/ Page - SystemVersion current majorMinorVersion Sake/Packages The code "Packages current", is currently set to major-minor version. However I have changed it to try the following options: 'Packages' , SystemVersion current version asLegalSelector capitalized 'Packages' , SystemVersion current majorMinorVersion asLegalSelector capitalized >> and we copy the definition of 'FreeType Plus' to >> PackagesSqueak39beta, and PackagesSqueak310beta but we change the >> load script to load whatever is the latest from squeaksource, rather >> than the package on SqueakMap. > > That's a bit dangerous. > The latest on SqueakSource will almost certainly be full of bugs, and > might contain experimental code that does outrageous things. > Like deleting all the font files from your disk, and installing a new > set from DodgyFreeFonts.org . > It doesn't, but you get my point :) Packages beta load: 'FreeTypePlus'. Is specifically requesting the most recent and hence most dangerous version whatever it may be, (because I cant be bothered to go and look for it myself). This provides package authors the easiest way of getting others on board with testing where they are at. The package author can say "Try the beta and see if it fixes your problem." The author is saved from having to update the "working" definitions until he his ready. cheers Keith > Cheers, > Andy > > > |
|
|
In reply to this post by Edgar J. De Cleene
Edgar wrote:
> And is why I against Installer and other scripting things which IMHO is like > GOTO or modern Pandora box. > Sake/Packages which is what is being described here is not modelled upon GOTO it is modelled upon "make" and "rake", both of which can model complex dependencies and relationships. In many cases those complexities are more than the human mind can handle without getting a headache, that is why "make" was invented. > Some was scared for me trying to show we could have four branches of images > > SqueakFoo - basic . Meaning bussiness as usual. > SqueakFooWT Meaning image witout traits > SqueakFooMC2 Meaning image developed with MC2 (My personal pick) > SqueakFooDS Meaning image developed with DS > Having a set of images to choose from IS conceptually just like a GOTO. Furthermore you have no idea what capabilities any of those images does contain, the only clue being the title, WT = With Traits or Without Traits or With Teeth? So building the future of squeak upon different images like this almost guarantees an explosion of different images and forks. This is not the way we want to go. Instead the trend towards kernel "common ancestor" images allows us to build up a detailed model of an image's capabilities and components (packages). This will hopefully lead to more interoperability than less. > Andrew here show we could have a Big Bang effect of countless variations > and only few experts could know how to survive in this scenario. > > The way to the heaven is hard and full of troubles. > The way to the hell is always the easier one. > The path of willful ignorance leads to hell, I have other plans. cheers Keith |
[squeak-dev] Re: [Pkg] FreeTypePlus
|
|
In reply to this post by keith1y
Sorry for the late reply; I have been away from a computer for a few days...!
Thanks...although I don't quite understand why you can't do something like: Installer sake: #PackagesSqueak310U to use the other packages, instead of copying the methods, but I'll play around with this and try to figure it out. I'm sure I'll have more questions, though... Rob On Sat, May 17, 2008 at 10:50 PM, Keith Hodges <[hidden email]> wrote: Welcome to packages! |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |