unsupported projects (was: DynamicBindings in 4.1)
Locked
unsupported projects (was: DynamicBindings in 4.1)
 
|
> That's pretty old. You can find the latest DynamicBindings version here:
> http://squeaksource.com/KomHttpServer.html We're putting in all this effort with documentation to assist newbies, this sort of problem is really working against us. We're not gonna document that, "for the *real* DynamicBindings" project, look in theKomHttpServer project..." I wonder whether the trunk model could be employed to individual SqueakSource projects; where each project has a "Inbox" for public contributions. If the "owner" is still with the community and has the time to keep up and harvest those contributions into the main line, great. If not, then it's a simple matter for the consumer to decide which one they want to load; e.g., the old one or the latest and greatest in the "inbox"... On Sun, May 9, 2010 at 6:06 PM, Levente Uzonyi <[hidden email]> wrote: > On Sun, 9 May 2010, Brent Pinkney wrote: > >> Hi, >> >> Is anyone aware of where (or if) there is a DynamicBindings Monitcello >> that works with the 4.1 image. >> I have used DynamicBindings-gk.1.mcz in 3.9 but it lack the extension >> methods (e.g. #valueWithBinding:) on BlockClosure. > > That's pretty old. You can find the latest DynamicBindings version here: > http://squeaksource.com/KomHttpServer.html > > > Levente > >> >> This causes a DNU in 4.1 as the image has BlockClosures instead of >> BlockContexts. >> >> Also, the Monitcellos in SqueakSource date from 2007. >> >> Any help welcomed. >> >> Brent >> >> > > |
Re: unsupported projects (was: DynamicBindings in 4.1)
|
|
On 5/11/10, Chris Muller <[hidden email]> wrote:
>> That's pretty old. You can find the latest DynamicBindings version here: >> http://squeaksource.com/KomHttpServer.html > > We're putting in all this effort with documentation to assist newbies, > this sort of problem is really working against us. We're not gonna > document that, "for the *real* DynamicBindings" project, look in > theKomHttpServer project..." > > I wonder whether the trunk model could be employed to individual > SqueakSource projects; where each project has a "Inbox" for public > contributions. If the "owner" is still with the community and has the > time to keep up and harvest those contributions into the main line, > great. If not, then it's a simple matter for the consumer to decide > which one they want to load; e.g., the old one or the latest and > greatest in the "inbox"... > > I think this is a good idea. In fact quite a number of squeaksource are open for posting by everyone. And if you login to squeaksource you may edit the wiki. Actually http://www.squeaksource.com/DynamicBindings is open for writing. So nobody holds you back in putting a copy from http://squeaksource.com/KomHttpServer.html there and adding a note on the wiki about this. --Hannes |
Re: unsupported projects (was: DynamicBindings in 4.1)
|
Administrator
|
Added to wiki: "This project has been superseded by KomHttpServer at http://squeaksource.com/KomHttpServer.html"
Cheers,
Sean |
Re: unsupported projects (was: DynamicBindings in 4.1)
|
|
In reply to this post by Chris Muller-3
If we think of Squeak trunk more as a Linux distribution we could have down stream repository for packages.
Some packages need work to work on Squeak trunk and these could recide here. Karl
On Tue, May 11, 2010 at 5:25 AM, Chris Muller <[hidden email]> wrote: > That's pretty old. You can find the latest DynamicBindings version here: |
Re: unsupported projects (was: DynamicBindings in 4.1)
|
|
Karl,
Thank you for bringing up this issue. I understand that you mean that the Squeak 4.1 trunk is something like the Linux kernel and Squeaksource and other Monticello repositories like the Debian package catalogue. Then a 'distribution' is basically a 'build script' which pulls various packages from the Monticello repositories and loads them into the image. The person who builds the distribution does integration tests and releases the image as a 'distribution'. Damien Cassou has done this for developer images in the past for Squeak 3.9 and 3.10 and seems to be still doing it for Pharo http://damiencassou.seasidehosting.st/ (Click on the link 'Smalltalk', then on the link 'quite popular' and you get to http://damiencassou.dabbledb.com/publish/dev-imagesdownloads ) Actually we should encourage people to do this for various types of images for Squeak 4.1. The base image should stay fairly small but that does not mean that people should not produce derived images which include a lot. --Hannes P.S. What we need are actually a collection of 'build scripts' (a kind of series of apt-get commands in Debian language). However in our context the way to go this days is to write a MetaCello configuration class. Then the user just has to load that class and execute ConfigurationOfMyReallyGoodSqueakEnvironment load How to create a MetaCello configuration http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration The MetaCello repository http://www.squeaksource.com/MetacelloRepository is open for global writing On 5/12/10, karl ramberg <[hidden email]> wrote: > If we think of Squeak trunk more as a Linux distribution we could have down > stream repository for packages. > Some packages need work to work on Squeak trunk and these could recide here. > > Karl > > On Tue, May 11, 2010 at 5:25 AM, Chris Muller <[hidden email]> wrote: > >> > That's pretty old. You can find the latest DynamicBindings version here: >> > http://squeaksource.com/KomHttpServer.html >> >> We're putting in all this effort with documentation to assist newbies, >> this sort of problem is really working against us. We're not gonna >> document that, "for the *real* DynamicBindings" project, look in >> theKomHttpServer project..." >> >> I wonder whether the trunk model could be employed to individual >> SqueakSource projects; where each project has a "Inbox" for public >> contributions. If the "owner" is still with the community and has the >> time to keep up and harvest those contributions into the main line, >> great. If not, then it's a simple matter for the consumer to decide >> which one they want to load; e.g., the old one or the latest and >> greatest in the "inbox"... >> >> >> >> On Sun, May 9, 2010 at 6:06 PM, Levente Uzonyi <[hidden email]> wrote: >> > On Sun, 9 May 2010, Brent Pinkney wrote: >> > >> >> Hi, >> >> >> >> Is anyone aware of where (or if) there is a DynamicBindings Monitcello >> >> that works with the 4.1 image. >> >> I have used DynamicBindings-gk.1.mcz in 3.9 but it lack the extension >> >> methods (e.g. #valueWithBinding:) on BlockClosure. >> > >> > That's pretty old. You can find the latest DynamicBindings version here: >> > http://squeaksource.com/KomHttpServer.html >> > >> > >> > Levente >> > >> >> >> >> This causes a DNU in 4.1 as the image has BlockClosures instead of >> >> BlockContexts. >> >> >> >> Also, the Monitcellos in SqueakSource date from 2007. >> >> >> >> Any help welcomed. >> >> >> >> Brent >> >> >> >> >> > >> > >> >> > |
Re: unsupported projects (was: DynamicBindings in 4.1)
|
Administrator
|
Metacello Configurations definitely simplify dependency management. When it works, it's awesome! Where I am hitting the wall is managing compatibility with different flavors of Squeak. Let me recount my latest experience...
> I want to install ExternalWebBrowser. > Oh good, there is a ConfigurationOf... in the SqS MetacelloRepository > Let me make sure it works and then I'll add it to my ImageSetup script > Results > Pharo 1.1 trunk update 11364: ExternalWebBrowserMacOS class>>isApplescriptAvailable references SMSqueakMap, which was removed from Pharo. Ugh, okay, I'll manually install Applescript via Gofer and Monticello, then restart > Pharo 1.0: same problem > Squeak 4.1 trunk update 10145: MetacelloMCProjectSpec's instance variable 'className' is nil; when asSymbol is called on it, DNU asSymbol > Squeak 4.1 official release: same problem So my question is - what platform does this config target? It failed for all the current Squeak and Pharo images! As a user, I would like to either: * have a specific place (depending on my platform) to find the correct config * or, even easier (and I suspect much less duplication, since many configs may work with multiple platforms), a way to mark ConfigurationsOf as working with particular platforms. Then, you could at least issue a warning, like SqMap, that 'the Config was not approved for this platform, do you want to continue.' If this info was built into the Metacello model, one might even be able to query the MetacelloRepository for configs approved for the current platform. The way it is now, I think I spent more time above than manually resolving the dependencies. What are your experiences with this issue, if any? Thanks. Sean
Cheers,
Sean |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |