GRPackage class >> packages

Running Seaside 3.1.2 in Squeak, a couple of places send "GRPackage
packages" but it is not implemented.  There is a #grPackages, and
several senders of that, so, I implemented #packages on GRPackage
class:

   packages
      ^ self grPackages
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 01/10/15 20:17, Chris Muller wrote:
> Running Seaside 3.1.2 in Squeak, a couple of places send "GRPackage
> packages" but it is not implemented.  There is a #grPackages, and
> several senders of that, so, I implemented #packages on GRPackage
> class:
>
>     packages
>        ^ self grPackages
>

Then we probably missed converting some of the senders to grPackages.
I can find the message where I complain about #packages but not the one
where it was resolved.

http://forum.world.st/GRPackage-gt-gt-packages-td4727544.html

implementing GRPackage class>>packages breaks in Pharo.

Stephan

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> Then we probably missed converting some of the senders to grPackages.

WASeasideVersionStatus>>#sortedWorkingCopies
JQAutocompleteFunctionalTest>>#packages
JQAutocompleteFunctionalTest>>#packageNamesFor:

> I can find the message where I complain about #packages but not the one
> where it was resolved.
>
> http://forum.world.st/GRPackage-gt-gt-packages-td4727544.html
>
> implementing GRPackage class>>packages breaks in Pharo.

Okay, then I've just removed by new #packages method and changed the
above 3 methods to refer to #grPackages.
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 02-10-15 00:24, Chris Muller wrote:
> WASeasideVersionStatus>>#sortedWorkingCopies
> JQAutocompleteFunctionalTest>>#packages
> JQAutocompleteFunctionalTest>>#packageNamesFor:

> Okay, then I've just removed by new #packages method and changed the
> above 3 methods to refer to #grPackages.

Thanks.

Stephan

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

True. We also noticed that in 3.2, where they have been corrected.

I think it’s best that you start working with 3.2

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> I think it’s best that you start working with 3.2

Agree.  Please forgive my ignorance with Metacello, but what is the
easiest way to do that?  I added
'http://smalltalkhub.com/mc/Seaside/Seaside32/main' to my Monticello
repositories, and I see about 15 packages with new versions in there,
I could try loading them one-by-one.

But, before I do that, I thought I would check with you first to see
if there's some script I can do which will merge 3.2 (hopefully
without stomping my local changes to existing packages).

Please advise, thanks!
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi all

On 05.10.2015, at 17:18, Chris Muller <[hidden email]> wrote:

Chris, I have not yet answered your private mail to me. That would answer this question
for Squeak ;) I promise to hurry.

Best regards
        -Tobias_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi all, Hi Chris,

On 05.10.2015, at 17:18, Chris Muller <[hidden email]> wrote:


For your reference:


On 18.09.2015, at 18:19, Chris Muller <[hidden email]> wrote:

> [private mail by chris]

> Seaside is a signature application for Squeak.  I sincerely hope we
> will be able to have a cleanly accessible version for new users like
> me.

Here I am, late as ever :(

So, there was a mis-configuration for RefactoringBrowser by me.

Ok, given you have installed the
Current metacello (https://github.com/dalehenrich/metacello-work)
then

Metacello new
        configuration: 'Seaside3';  
        repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; 
        version: #stable;  
        load: 'OneClick'.

Will give you a clean Seaside 3.1.4.2 in Squeak 5.0.
(I just tested that)

This will install OmniBrowser for the SeasideControlPanel.

I have an alternative one written in ToolBuilder for Squeak, so we no longer
depend on OB for just the SCP.

HOWEVER, WebClient-Seaside assumes the SCP to be present.
I have to break that up to make that more modular.

Gimme some time there ;)

I'll test with 3.2 as soon as I get around to do that.

Best regards
        -Tobias



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi Tobias,

Wonderful, thank you.

While I think Seaside is a framework which really benefits by the
power of Metacello (multi-platform, etc.), it seems to continue to
face challenges in meeting all the catalog requirements.

Like, right here, right now, I have my learning-seaside.image, with
Seaside-3.1.2 loaded, and I would like to load (or, preferably, _merge_,
because my studious activities have caused a few dirty packages) the
packages of this 3.1.4.2 release of Seaside.  But, as I tried to do:

Metacello new
        configuration: 'Seaside3';
        repository:
'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
        version: '3.1.4.2';
        load: 'OneClick'.

I get an error:

      'Vversion '3.1.4.2' is not defined in ConfigurationOfSseaside3.
Possible versions include #(#bleedingEdge #development #release3..."

So I guess there can be an advantage to not using symbolic version
names -- because if someone told me, "3.1.4.2 is the new stable version" and
I were to install "#stable," I might erroneously think I
got 3.1.4.2 loaded even though I didn't (!), because I first needed to
load the "latest Metacello" in order to get the latest definitions.

Unfortunately, the upgrade of Metacello doesn't succeed.  The
installation instructions for Metacello at
https://github.com/dalehenrich/metacello-work fails the 2nd time with:

     MetacelloCommonMCSpecLoader DNU: #loadPackageDirective:gofer:.

The simple SqueakMap procedures enjoy a property of idempotence,
something that must be expected of system configuration scripts, and
Metacello must master, if Seaside is to meet all of the catalog
requirements.

Okay, thank you!  I have direct need for JQAjax>>#callback:json: right
now, but is not introduced until 3.2.

Best,
  Chris
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev