unsupported projects (was: DynamicBindings in 4.1)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

unsupported projects (was: DynamicBindings in 4.1)

Chris Muller-3
> 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
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: unsupported projects (was: DynamicBindings in 4.1)

Hannes Hirzel
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

Reply | Threaded
Open this post in threaded view
|

Re: unsupported projects (was: DynamicBindings in 4.1)

Sean P. DeNigris
Administrator
Hannes Hirzel-2 wrote
Actually http://www.squeaksource.com/DynamicBindings is open for
writing. So nobody holds you back in... adding a note on
the wiki about this.
Added to wiki: "This project has been superseded by KomHttpServer at http://squeaksource.com/KomHttpServer.html"
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: unsupported projects (was: DynamicBindings in 4.1)

Karl Ramberg
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:
> 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
>>
>>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: unsupported projects (was: DynamicBindings in 4.1)

Hannes Hirzel
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
>> >>
>> >>
>> >
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: unsupported projects (was: DynamicBindings in 4.1)

Sean P. DeNigris
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