seaside-dev February 2010

seaside-dev@lists.squeakfoundation.org

10 participants
15 discussions

Re: [Seaside Commits] Seaside 3.0: Grease-Core-obi.29.mcz
by Lukas Renggli 24 Feb '10

24 Feb '10

Is there a particular reason that you added this method? As you can see in the method comment of #url: the variable can also contain a string, so your method does not necessarily return what it says. Also consider adding a method comment and tests for any public method. Lukas On 21 February 2010 18:41, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Gerhard Obermann uploaded a new version of Grease-Core to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Grease-Core-obi.29.mcz > > ==================== Summary ==================== > > Name: Grease-Core-obi.29 > Author: obi > Time: 21 February 2010, 6:43:17 pm > UUID: 79473ec4-083e-a144-aa40-4d100d2ab1e3 > Ancestors: Grease-Core-lr.28 > > - add direct accessing method for url > > =============== Diff against Grease-Core-lr.28 =============== > > Item was added: > + ----- Method: GRPackage>>urlSelector (in category 'accessing') ----- > + urlSelector > + ^ url! > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits > -- Lukas Renggli http://www.lukas-renggli.ch

5 10

Re: [Seaside-dev] Seaside-Swazoo moved (again)?
by Dale Henrichs 22 Feb '10

22 Feb '10

1 1

Re: [Seaside-dev] Seaside-Swazoo moved (again)?
by Dale Henrichs 22 Feb '10

22 Feb '10

Lukas, It is easy enough to edit the configuration when things change out from under users. Metacello isn't the only thing that breaks when packages are deleted from repositories. Seaside28 is stable so there isn't a need to copy packages from there, unless you plan to destroy the repository:) Seaside3.0 is under active development and dealing with moving packages is just one of the many things developers and users have to cope with:) Seaside 3.0 hasn't hit beta yet, so things are expected to change ... I was just surprised to see Seaside-Swazoo move again and half expected that it might be moved one more time:) Dale ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | Generally I suggest that anything referenced from a Metacello | configuration should be copied to a safe immutable location. This is | also what we do for our releases, see | <http://builder.seaside.st/distributions/>. Repositories are going to | diappear, packages are going to be deleted or moved. Nobody listened | when I suggested that in the Pharo list a few months back ... so here | you go :-) | | Lukas | | | | On 22 February 2010 18:52, Lukas Renggli <renggli(a)gmail.com> wrote: | > Its location never changed. The problem was more that it was | committed | > to the wrong place and that people continued from there without | > noticing. The problem should be solved now as each package declares | > its default location and the scripts to commit have been updated to | > take advantage of that information. | > | > Lukas | > | > On 22 February 2010 18:35, Dale Henrichs | <dale.henrichs(a)gemstone.com> wrote: | >> Is Seaside-Swazoo going to stay in its present repository or will | it be moved again? | >> | >> Dale | >> _______________________________________________ | >> seaside-dev mailing list | >> seaside-dev(a)lists.squeakfoundation.org | >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | >> | > | > | > | > -- | > Lukas Renggli | > http://www.lukas-renggli.ch | > | | | | -- | Lukas Renggli | http://www.lukas-renggli.ch | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

3 4

Re: [Seaside-dev] Seaside-Swazoo moved (again)?
by Dale Henrichs 22 Feb '10

22 Feb '10

Lukas, I don't think it was accidental, I recall that there was an email exchange about Seaside-Swazoo saying that the Seaside-Swazoo package itself wasn't licensed under the LGPL, so it shouldn't be in the LGPL repository ... shortly after that mail the package was moved. Dale ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | Its location never changed. The problem was more that it was | committed | to the wrong place and that people continued from there without | noticing. The problem should be solved now as each package declares | its default location and the scripts to commit have been updated to | take advantage of that information. | | Lukas | | On 22 February 2010 18:35, Dale Henrichs <dale.henrichs(a)gemstone.com> | wrote: | > Is Seaside-Swazoo going to stay in its present repository or will it | be moved again? | > | > Dale | > _______________________________________________ | > seaside-dev mailing list | > seaside-dev(a)lists.squeakfoundation.org | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | | | | -- | Lukas Renggli | http://www.lukas-renggli.ch | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2 1

Seaside-Swazoo moved (again)?
by Dale Henrichs 22 Feb '10

22 Feb '10

Is Seaside-Swazoo going to stay in its present repository or will it be moved again? Dale

2 2

[Seaside] [Seaside-dev] MbContainerPlus
by Maximiliano Taborda 22 Feb '10

22 Feb '10

Hi. Anybody know if exists a port for this component (or someone like) --> http://pupunzi.open-lab.com/2009/02/01/mbcontainersplus/ Thanks. Maxi.

1 0

Re: [Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Grease-Core-obi.29.mcz
by Dale Henrichs 22 Feb '10

22 Feb '10

1 0

GRTestsFunctionalPlatformTest>>#testGarbageCollect
by James Foster 17 Feb '10

17 Feb '10

All, I've updated the SeasideLoadOrderTests and found a problem with GRTestsFunctionalPlatformTest>>#testGarbageCollect. This test exists early and fails until Seaside-Tests-Pharo-Functional is loaded. This indicates some load order dependency. What is in Functional that should be in Core? Or should the test be moved to Functional? Otherwise, things seem to be quite clean! James Loaded Grease-Core-dkh.8.mcz Loaded Grease-Pharo-Core-dkh.4.mcz Loaded Grease-Tests-Core-jf.7.mcz Loaded Grease-Tests-Pharo-Core-dkh.2.mcz 217 run, 214 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Core-dkh.590.mcz Loaded Seaside-Tests-Core-jf.167.mcz Loaded Seaside-Tests-UTF8-pmm.7.mcz Loaded Seaside-Pharo-Core-jf.3.mcz Loaded Seaside-Tests-Pharo-Core-dkh.6.mcz 595 run, 592 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Canvas-pmm.74.mcz Loaded Seaside-Pharo-Canvas-jf.2.mcz Loaded Seaside-Tests-Canvas-jf.40.mcz 673 run, 670 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Session-dkh.125.mcz Loaded Seaside-Tests-Session-jf.33.mcz 721 run, 718 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Component-lr.79.mcz Loaded Seaside-Tests-Component-lr.26.mcz 734 run, 731 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-RenderLoop-jf.68.mcz Loaded Seaside-Tests-RenderLoop-jf.9.mcz 734 run, 731 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Tools-Core-jf.12.mcz 734 run, 731 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Widgets-dkh.7.mcz 734 run, 731 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Environment-lr.65.mcz Loaded Seaside-Pharo-Environment-jf.4.mcz Loaded Seaside-Tests-Environment-jf.19.mcz 739 run, 736 passes, 2 expected failures, 1 failures, 0 errors, 0 unexpected passes GRTestsFunctionalPlatformTest>>#testGarbageCollect Loaded Seaside-Tests-Functional-pmm.95.mcz Loaded Seaside-Tests-Pharo-Functional-dkh.7.mcz 741 run, 739 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Pharo-Continuation-lr.4.mcz Loaded Seaside-Tests-Pharo-Continuation-lr.4.mcz 757 run, 755 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Flow-dkh.18.mcz Loaded Seaside-Pharo-Flow-jf.3.mcz Loaded Seaside-Tests-Flow-jf.20.mcz 758 run, 756 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Tools-Web-lr.65.mcz Loaded Seaside-Pharo-Tools-Web-jf.6.mcz Loaded Seaside-Tests-Tools-Web-jf.11.mcz 761 run, 759 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Development-dkh.122.mcz Loaded Seaside-Pharo-Development-lr.26.mcz Loaded Seaside-Tests-Development-jf.32.mcz Loaded Seaside-Tests-Pharo-Development-jf.3.mcz 765 run, 763 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Examples-jf.15.mcz Loaded Seaside-Tests-Examples-jf.6.mcz 767 run, 765 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Tools-OmniBrowser-jf.11.mcz Loaded Seaside-Pharo-Tools-OmniBrowser-jf.3.mcz 767 run, 765 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded RSS-Core-jf.56.mcz Loaded RSS-Tests-Core-jf.21.mcz Loaded RSS-Examples-dkh.20.mcz 776 run, 774 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Javascript-Core-dkh.69.mcz Loaded Javascript-Pharo-Core-jf.2.mcz Loaded Javascript-Tests-Core-jf.45.mcz 878 run, 876 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded JQuery-Core-lr.90.mcz Loaded JQuery-Tests-Core-lr.94.mcz Loaded JQuery-UI-lr.42.mcz Loaded JQuery-Tests-UI-lr.56.mcz 1060 run, 1058 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Prototype-Core-jf.12.mcz Loaded Prototype-Tests-Core-jf.5.mcz 1094 run, 1092 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Scriptaculous-Core-jf.93.mcz Loaded Scriptaculous-Tests-Core-dkh.39.mcz Loaded Scriptaculous-Components-dkh.92.mcz Loaded Scriptaculous-Tests-Components-dkh.27.mcz 1105 run, 1103 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-HTML5-jf.7.mcz Loaded Seaside-Tests-HTML5-jf.14.mcz 1105 run, 1103 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-InternetExplorer-jf.5.mcz Loaded Seaside-Tests-InternetExplorer-jf.8.mcz 1111 run, 1109 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Seaside-Email-dkh.14.mcz Loaded Seaside-Tests-Email-jf.6.mcz Loaded Seaside-Pharo-Email-dkh.5.mcz 1115 run, 1113 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded DynamicBindings-damiencassou.9.mcz Loaded KomServices-gc.19.mcz Loaded KomHttpServer-damiencassou.47.mcz Loaded Seaside-Adaptors-Comanche-pmm.51.mcz Loaded Seaside-Tests-Adaptors-Comanche-jf.11.mcz 1123 run, 1121 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Comet-Core-jf.42.mcz Loaded Comet-Pharo-Core-jf.3.mcz Loaded Comet-Tests-Core-jf.7.mcz Loaded Comet-Examples-lr.15.mcz 1126 run, 1124 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes

4 7

Re: [Seaside-dev] beta?
by Dale Henrichs 17 Feb '10

17 Feb '10

Keep in mind that the only reason for being sticky on the version is to be able to sort the versions. If sorting wasn't an issue, then any old string would work... If you want to sort, then you must have a scheme otherwise '1.10' sorts earlier that '1.9' and that is not good. In this particular instance it is only necessary to have a parsing rule for distinguishing alphabetic components from numeric components and I know that I can parse 1.0a6 correctly ... it's just a little more programming. Haha, the scheme that I had in mind appears to match what Mozilla has done...just break the components at string and numeric boundaries where '.' is the numeric separator...There version comparison algorithm is slightly different, but I'd rather follow Mozilla than almost follow Mozilla... If you want to use 1.0a6 style versions just say the word and I'll make it so ... as I said, I think I will be following the Mozilla scheme going forward after discussion on mailing list which will make parsing a non-issue, but in the Mozilla scheme 1.0a6 still sorts less then 1.0alpha5. Dale ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | On Tue, Feb 16, 2010 at 1:11 PM, Dale Henrichs | <dale.henrichs(a)gemstone.com> wrote: | > Metacello has first-class versions as well, but parsing strings is | part of the game. Humans will be writing and reading the strings: | > | > Loader load: 'ConfigurationOfSeaside' version: '2.8.4' | > | > So Metacello has parsing rules for versions to convert back and | forth between versions and strings. | | Seems like that's always going to depend on people following a | particular convention. So either you force everyone to use the same | convention for their projects (not likely) or accept that the | Metacello version number may not match the project's own numbering | character-by-character... no? | | I suppose the alternative is to track ancestry of versions somehow, | but that's a whole other story. | | > I know that with Monticello, there never was a concrete (read | enforced) definition for the file name. Gofer has imposed a parsing | scheme on Monticello file names that works pretty well for calculating | the latest file, but falls down when the creators of a Monticello | filename use a convention that is at odds with Gofer's scheme ... | > | > I want to avoid that problem with Metacello, so this early in the | game I'm willing to change my parsing scheme. | | Sure, but is that really going to solve the problem universally (i.e. | for projects other than Seaside)? | | > GRVersion can certainly be converted to MetacelloVersionNumber, but | I am worried about the print string format (call me anal). | > | > If you are going to write a message that says load 1.0a6 of Grease, | then I would hope that Metacello would load '1.0a6' of Grease and that | the sort order of versions will work (there is a load latest option in | Metacello)....Since I've already gone and created a version called | 1.0alpha51 I can't imagine a parser/sorter that would sort 1.0a6 later | than 1.0alpha5.1. If you can think of one I am interested. | | Well, I can't personally imagine ever writing alpha6 in an email | unless I was really forcing myself to. I can imagine being told to | load a6, asking for a list of versions, and realizing that alpha6 is | the same thing, though... | | As for parsing/sorting, Mozilla's scheme sounds like it might allow | what you want ( | https://developer.mozilla.org/en/Toolkit_version_format ) but it may | be a bit overkill. | | > I'm already pretty well convinced that I was overly optimistic that | something like 1.0-a6 would fly as a version naming scheme. But I am | willing to change and from what I can tell, you'd like to use the name | 1.0a6 instead of 1.0alpha6, so I think I will be changing the | ConfigurationOfGrease configs ... better now, than later. | | Well, I note that GRVersion's #greaseString is currently outputting | 'alpha6' :) but that's just because I was using symbols for the | #alpha, #beta, and it was easier to just output the whole thing. I | dunno - mostly I'd just rather there was a way we didn't have to be | so | sticky about strings. :) | | Julian

2 2

Re: [Seaside-dev] beta?
by Dale Henrichs 17 Feb '10

17 Feb '10

Metacello has first-class versions as well, but parsing strings is part of the game. Humans will be writing and reading the strings: Loader load: 'ConfigurationOfSeaside' version: '2.8.4' So Metacello has parsing rules for versions to convert back and forth between versions and strings. I know that with Monticello, there never was a concrete (read enforced) definition for the file name. Gofer has imposed a parsing scheme on Monticello file names that works pretty well for calculating the latest file, but falls down when the creators of a Monticello filename use a convention that is at odds with Gofer's scheme ... I want to avoid that problem with Metacello, so this early in the game I'm willing to change my parsing scheme. GRVersion can certainly be converted to MetacelloVersionNumber, but I am worried about the print string format (call me anal). If you are going to write a message that says load 1.0a6 of Grease, then I would hope that Metacello would load '1.0a6' of Grease and that the sort order of versions will work (there is a load latest option in Metacello)....Since I've already gone and created a version called 1.0alpha51 I can't imagine a parser/sorter that would sort 1.0a6 later than 1.0alpha5.1. If you can think of one I am interested. I'm already pretty well convinced that I was overly optimistic that something like 1.0-a6 would fly as a version naming scheme. But I am willing to change and from what I can tell, you'd like to use the name 1.0a6 instead of 1.0alpha6, so I think I will be changing the ConfigurationOfGrease configs ... better now, than later. I'll also be bringing up the version scheme on the Metacello mailing list to get more feedback ... Dale ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | Well, to be honest I was trying to avoid all of this string sorting | by | having a first-class Version. :) | | Actually, now that I say that, I realize I hadn't mentioned that so | you may not have noticed. Can you just convert the GRVersion to | whatever string you want? | | Julian | | On Mon, Feb 15, 2010 at 4:30 PM, Dale Henrichs | <dale.henrichs(a)gemstone.com> wrote: | > Mmmmm, ('1.0-a6' asMetacelloVersionNumber) sorts less than | ('1.0-alpha5'asMetacelloVersionNumber). since 'a6' sorts less than | 'alpha5'. | > | > I could tweak the sorting algorithm for version numbers, but I was | hoping that the string components in the version number would just | sort as strings. | > | > If you are set on using 'a' instead of 'alpha' I'd almost rather | bite the bullet now and change the existing references... | > | > BTW, the '-' is significantly part of the metacello version numbers. | I haven't had any push back, yet, but I'm willing to wiggle aroun in | the version component parsing space. Currently: | > | > 1.0a6 parses into { 1.'0a6'. } | > 1.0-a6 parses into { 1. 0. 'a6' } | > 1.0-a.6 parses into {1. 0. 'a'. 6. } | > 1.0-a.6 parses into {1. 0. 'a'. 6. } | > 1.0-6 parses into { 1. 0. '6'. } | > | > an alternate scheme could go with (A): | > | > 1.0a6 parses into { 1. 0. 'a6'. } | > 1.0-a6 parses into { 1. 0. 'a6'. } | > 1.0-a.6 parses into {1. 0. 'a'. 6. } | > 1.0-6 parses into { 1. 0. '6'. } | > | > or even (B): | > | > 1.0a6 parses into { 1. 0. 'a'. 6. } | > 1.0-a6 parses into { 1. 0. 'a'. 6. } | > 1.0-a.6 parses into {1. 0. 'a'. 6. } | > 1.0-6 parses into { 1. 0. 6. } | > | > This doesn't help with 'alpha' part, but if you are strongly opposed | to 1.0-a.6 then now would be the time to speak up, because I'm pretty | sure that I can get away with supporting either of A or B ... | > | > Now that it comes up, I'm probably in favor of B... | > | > Dale | > | > | > ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | > | > | Mm... I think there's no point changing everything. Since luckily | you | > | went with 1.0 anyway, why don't we just call this 1.0a6 then? | Does | > | that solve things? | > | | > | Julian | > | | > | On Mon, Feb 15, 2010 at 1:52 PM, Dale Henrichs | > | <dale.henrichs(a)gemstone.com> wrote: | > | > Julian, | > | > | > | > When I created the Metacello configuration for Grease, I took | the | > | liberty of using '1.0-alpha1' as the original version number. | Grease | > | is up to '1.0-alpha5.1' in Metacello. It appears that you are | using a | > | different naming scheme than that used by Seaside. | > | > | > | > Seaside 3.0 has made it to '3.0.0-alpha5.8' and Seaside 2.8 s up | to | > | '2.8.4.4', but I don't see any danger in version naming collisions | for | > | Seaside. | > | > | > | > The Metacello version numbers should coincide with the actual | > | product versions, so pardon me for going ahead and using up some | of | > | the valuable version namespace for Grease. | > | > | > | > At this juncture it wouldn't cause too much disturbance to | change | > | the Grease version numbers to match your vision (technically | published | > | versions aren't supposed to change), but I'd need to know the | names | > | that you'd like to use for the already released versions of | Grease, so | > | I can change the Grease configuration and all of the other | > | configuration that reference Grease. | > | > | > | > Dale | > | > | > | > ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | > | > | > | > | Just a heads up that we're thinking of rolling a beta real | soon. | > | At | > | > | some level I'd like a little more polish on it, but | realistically | > | > | development has seriously slowed down, very few bugs are | being | > | > | reported, and people seem to be adopting and beginning to | deploy | > | and | > | > | distribute the alpha. I'm just going to try to get our query | and | > | post | > | > | fields sorted out and then that's it for my list. | > | > | | > | > | I'm going to number Grease as 1.0a at the same time as we go | beta | > | on | > | > | Seaside in order to have a named version that we can refer | to. | > | > | Removing stuff from Grease will be problematic once it's out | of | > | > | alpha, | > | > | so I don't want to rush it along too quickly. | > | > | | > | > | Last chance to shout if there are any platform issues or | anything | > | > | that | > | > | need resolving before beta (ideally with a commitment to fix | it | > | ASAP | > | > | :) ). | > | > | | > | > | Julian | > | > | _______________________________________________ | > | > | seaside-dev mailing list | > | > | seaside-dev(a)lists.squeakfoundation.org | > | > | | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | > _______________________________________________ | > | > seaside-dev mailing list | > | > seaside-dev(a)lists.squeakfoundation.org | > | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | > | >

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev February 2010