Pharo 2.0 scriptaculous does not work

Paul DeBruicker <[hidden email]> wrote:
> You mean why do I ask?  Because I've been using/maintaining it and am
> curious about whether anyone ever uses it but me.

I looked at it and I have seen that Money is a subclass of Magnitude.
Shouldn't it be a subclass of ScaledDecimal?

10.2s2 asMoney: #EUR prints EUR 10..20.20

Kind regards,
  Markus

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

I think I need the metacello doctor to work out what I had in mind.
Dale? you there? :-)

In the meantime, I bumped a new version that references the correct Zinc-Seaside package version, such that it works correctly for now.

The problem I have is that Metacello does not support the #requires: condition for project references. Before loading Zinc (with Zinc-Seaside), the Seaside-Core package needs to be loaded.
I was under the false impression that such a statement was possible in Metacello, but alas... I am wrong.

So now I need to figure out how we can:
- let the Zinc-Seaside package version be controlled by the Zinc project (it makes more sense)
- have the Seaside config reference the Zinc project but only load it after having loaded Seaside-Core.

I tried several things yesterday including referencing Seaside from Zinc as well, but that went into an infinite loop (metacello does not detect loops?).
Guess I was a bit too bold yesterday, but maybe Dale can shed some light on how to accomplish the above two items?

Johan

On 07 Jun 2013, at 16:43, Johan Brichau <[hidden email]> wrote:

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

On 06/07/2013 05:23 PM, Markus Fritsche wrote:
> 10.2s2 asMoney: #EUR prints EUR 10..20.20


Thats weird.  On Pharo 1.4 & 2 it prints:

 EUR 10.20

Which image and which version of the package is loaded in your image?

As to whether it should be a subclass of scaled decimal or not, I don't
know enough about the trade-offs to make a decision.  Its an old library
and I don't know the users but I'd expect itd be fine to change it.  If
you look at the #normalizeAmount: method it converts everything into a
Fraction internally.


I usually just use the ConvertableMoney/InexactMoney classes because I'm
just estimating across currencies anyways.

regardless, thanks for taking a look.


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

Paul DeBruicker <[hidden email]> wrote:
> On 06/07/2013 05:23 PM, Markus Fritsche wrote:
>> 10.2s2 asMoney: #EUR prints EUR 10..20.20

> Thats weird.  On Pharo 1.4 & 2 it prints:

> EUR 10.20

> Which image and which version of the package is loaded in your image?
Pharo2.0
Latest update: #20606

Name: Money-PaulDeBruicker.64
Author: PaulDeBruicker
Time: 17 April 2013, 7:03:07 pm

But if you can't reproduce this, then never mind - I have loaded Seaside +
Pier3 into that image, and that seems to have a bit of an impact.

Kind regards,
  Markus

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

Johan,

Let me try to understand what you want.

You want to move Zinc-Seaside to Zinc, and thus build Zinc depend on Seaside instead of the other way around.
So you want to add a group to Zinc, called 'Seaside', that loads Zinc-Seaside that requires Seaside30, so it loads after Seaside30 config is loaded with Seaside-Core.
Both projects have load type linear, so it should work …. but my guess is that you than have to remove Zinc from Seaside altogether.

So I think my question would be: why should Seaside still depend on Zinc, when you move Zinc-Seaside to Zinc?

Diego

On Jun 8, 2013, at 10:11 AM, Johan Brichau wrote:

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

On 10 Jun 2013, at 09:23, Diego Lont <[hidden email]> wrote:

It is more complicated than that, IMHO:

- there is more than one Seaside (3.0.8 & 3.1), Zinc does not want (or has to) choose
- loading the Zinc-Seaside adaptor does not necessarily mean you have to update Zinc itself
- conceptually, Seaside needs HTTP support, not the other way around
- but you cannot load an adaptor without the Seaside framework classes being loaded

My current proposed solution is very simple: a group 'Seaside' that loads only Zinc-Seaside without dependencies. The advantage is that I can control the version and update it if needed.

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

Diego,

Indeed, the most "natural" way of things from a project-dependencies point-of-view is that the Seaside project includes the Zinc-Seaside package, which is the way things work right now. However, the internal implementation of the adaptor is dependent on the version of the Zinc project. If Seaside references a particular version of the Zinc package _and_ references the #stable version of the Zinc project, it happens that Seaside can load incompatible versions of Zinc and the Zinc-Seaside package. Therefore, it would be more natural for the Zinc project to specify the version of the Zinc-Seaside package, instead of the Seaside project doing that.

Obviously, this is also not correct because the Zinc-Seaside package depends on Seaside as well. I guess that using current Metacello, we can only achieve this by creating a separate project-spec for Zinc-Seaside. It probably is the most correct way to do it, because the package sits between two projects.

Nevertheless, if Metacello would allow to specify a "requires" clause on project references, we could enforce the loading of Seaside-Core to precede the loading of Zinc (including its Zinc-Seaside adaptor package). Another solution (a bit more low-level) would be that Seaside config determines that version to load for the 'Zinc-Seaside' package is the one referenced in the #stable version of Zinc.

In summary, the main point is that Seaside should not reference an explicit Zinc-Seaside package version _and_ reference the symbolic #stable version of Zinc, because that breaks, has broken and will break again. Now, what is the most lenient solution to solve this?

Johan

On 10 Jun 2013, at 09:39, Sven Van Caekenberghe <[hidden email]> wrote:

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

btw, disregard my use of "natural" in my previous response. I apply the adjective too to many different situations, hence confusing you ;-)

On 10 Jun 2013, at 10:50, Johan Brichau <[hidden email]> wrote:

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

Paul DeBruicker wrote:
>On 06/07/2013 05:23 PM, Markus Fritsche wrote:
>> 10.2s2 asMoney: #EUR prints EUR 10..20.20
>
>
>Thats weird.  On Pharo 1.4 & 2 it prints:
>
> EUR 10.20

It's not weird, it just depends on locales in the implementation and is broken for locales like german
that use $, as a money separator (EUR 10,20)


If you look at:

 printSeparated: aNumber on: aStream
        | s n n1 sz |
        s := aNumber printShowingDecimalPlaces: 2.
        n := s copyUpTo: self decimal.
        ...

you will see that it copies up to the return value of "self decimal".
This is implemented as following:

  decimal
   ^Locale current primDecimalSymbol first

and returns either $. or $, (on german locales).

If you use

 printSeparated: aNumber on: aStream
        | s n n1 sz |
        s := aNumber printShowingDecimalPlaces: 2.
        n := s copyUpTo: $..
        ...

it will always work and format locale independent as "EUR 10.20"

Will you move the project to STHub for adopting for Pharo >= 2.0 and for others to contribute?

Thx
T.




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

Johan,

Sorry I've been completely absorbed by STIC this week, so the doctor has not been in, but he is now:)


If I understand the flow of the conversation you are trying to include the Zinc-Seaside package in the Zinc project without specifying a proper dependency (because doing so would instroduce a circularity between Seaside and Zinc).

You are taking this approach because you ran into problems when Zven made a certain set of changes to Zinc that broke the adaptor...

First I'd like to back up and say the Zinc-Seaside package _should_ be included in Seaside30 project with a dependency upon the Zinc project. The Zinc-Seaside _is_ in support of the Seaside project - the code is wrapping Zinc functionality with a Seaside-specific (common) API for web servers.

It's not correct to expect Sven to be responsible for ensuring that Zinc-Seaside passes all of it's tests whenever he releases a new version of Zinc, so he should not be responsible for the Zinc-Seaside package.

AFAICT, the issues came up when Sven released a new #stable version of Zinc that,to quote Sven:

  "Some recent changes to Zinc apparently resulted in some
   compatibility problems with Seaside. We fixed already at
   least one of them..."

Either the "recent changes" were changes to the basic API (case #1) or the Zinc-Seaside code itself was reaching into Zinc and using a private API (case #2) or the Zinc-Seaside code was written to work around/rely on a bug in Zinc (case #3).

Let's skip case #1 for now.

If the root cause is case #2, then the Seaside folks should work with Zinc to define a public API that can be safely cause across all future bugfixes ...

If the root cause is case #3 then the Seaside folks can take out there workaround and move forward.

In both of the above cases the root cause is an anomaly that is not expected to occur _every time Zinc is updated_.

If the root cause is case #1, then we have a more difficult situation because in reality an API change results in the creation of two #stable versions ... One #stable version is Zinc with the old API the other #stable vesion is Zinc with new API.

If one expects to use a project in production applications, it is reasonable to expect that the API itself remains consistent across bug fixes ... I do not want to have to change my application in order to safely pick up a bugfix from a project ... On the other hand if I want to take advantage of the new api, I am be willing to rewrite my application to take advantage of the new capabilities... If we are indeed entering this area then we need to adpopt the Sematic Versioning Spec[1] for version naming so that API transitions can be recognized at the version-level which then makes it possible specify project dependencies in tools such as Metacello.

There is a fourth case (case #4) that occurs to me and that is that the Zinc API is not complete and Seaside is dependent upon a project with an API that is still under development. If this is the case, it behooves Sven to pre-announce his plan to change the Zinc API in an upcoming release and give projects and production apps that depend Zinc a chance to evaluate the implications and adjust their applications/dependencies in anticipation of the change...

I am not "picking on Zinc." Sven is providing a very good product free of charge to the community.

I _do_ want to make sure that we have characterized the problem completely before taking action in the form of adding features to Metacello:)

Dale

[1] http://semver.org/

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| Sent: Saturday, June 8, 2013 1:11:52 AM
| Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
|
| I think I need the metacello doctor to work out what I had in mind.
| Dale? you there? :-)
|
| In the meantime, I bumped a new version that references the correct
| Zinc-Seaside package version, such that it works correctly for now.
|
| The problem I have is that Metacello does not support the #requires:
| condition for project references. Before loading Zinc (with
| Zinc-Seaside), the Seaside-Core package needs to be loaded.
| I was under the false impression that such a statement was possible
| in Metacello, but alas... I am wrong.
|
| So now I need to figure out how we can:
| - let the Zinc-Seaside package version be controlled by the Zinc
| project (it makes more sense)
| - have the Seaside config reference the Zinc project but only load it
| after having loaded Seaside-Core.
|
| I tried several things yesterday including referencing Seaside from
| Zinc as well, but that went into an infinite loop (metacello does
| not detect loops?).
| Guess I was a bit too bold yesterday, but maybe Dale can shed some
| light on how to accomplish the above two items?
|
| Johan
|
| On 07 Jun 2013, at 16:43, Johan Brichau <[hidden email]> wrote:
|
| > Thanks Sven.
| >
| > I'm adapting the Seaside config to include that group instead of
| > the Zinc-Seaside package.
| >
| > On 07 Jun 2013, at 14:17, Sven Van Caekenberghe <[hidden email]>
| > wrote:
| >
| >> Johan,
| >>
| >> On 07 Jun 2013, at 10:11, Johan Brichau <[hidden email]>
| >> wrote:
| >>
| >>> On 07 Jun 2013, at 10:03, Sven Van Caekenberghe <[hidden email]>
| >>> wrote:
| >>>
| >>>> I am willing to do that (it sounds logical), but can that be
| >>>> done without depending on Seaside itself ? Because that does
| >>>> not sound practical, maybe reducing a circular dependency or at
| >>>> least an interference with the specific Seaside versions and
| >>>> groups that you initially want to load.
| >>>
| >>> If I am correct, that should not be a problem.
| >>>
| >>> The Seaside30 config can specify to load the 'Zinc-Seaside'
| >>> version as specified by the Zinc config.
| >>> All you have to do is list the Zinc-Seaside package in your
| >>> version methods and make sure that it does not get loaded when
| >>> not explicitly asking for it.
| >>> I believe that can be done by not putting it in the #default load
| >>> group.
| >>
| >> I just created
| >> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.49 which
| >> now has a 'Seaside' group that loads the 'Zinc-Seaside' adaptor
| >> package with a specific version. It is of course not loaded by
| >> default.
| >>
| >>> If you want your config to be complete, you can list a dependency
| >>> on the Seaside project for the Zinc-Seaside package. This would
| >>> only be loaded if somebody explicitly load the Zinc-Seaside
| >>> package.
| >>
| >> For now I skipped the dependency on Seaside, we'll see how it
| >> goes.
| >>
| >> Sven
| >>
| >>> If that does not work, we need to ask the Metacello doctor ;-)
| >>>
| >>> Johan_______________________________________________
| >>> seaside mailing list
| >>> [hidden email]
| >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| >>
| >> --
| >> Sven Van Caekenberghe
| >> Proudly supporting Pharo
| >> http://pharo.org
| >> http://association.pharo.org
| >> http://consortium.pharo.org
| >>
| >>
| >>
| >>
| >> _______________________________________________
| >> seaside mailing list
| >> [hidden email]
| >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| >
| > _______________________________________________
| > seaside mailing list
| > [hidden email]
| > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dale,

I guess the case was #1.
Zinc produced a new #stable version but the Seaside project referenced an older (incompatible) Zinc-Seaside package. In contrast, the Zinc project was offering a correct version of Zinc-Seaside in its #stable version, but Seaside references Zinc-Seaside using an explicit package version.

So, my reasoning was that if Zinc was actually offering a matching Zinc-Seaside package version, it should be possible for Seaside to pick it up....

I fully agree that, given the dependencies, the Zinc-Seaside version to use should be specified by the Seaside version. But, since Seaside references Zinc using #stable, then it should also reference Zinc-Seaside using #stable. Or Seaside should reference Zinc using an explicit version.

In my mind, Zinc-Seaside is more of a shared package between Seaside and Zinc. Changes to both Seaside and Zinc might require it to be changed.
In essence, if Zinc-Seaside would really have been owned by the Seaside project, then we would have needed to adapt it to work with the new Zinc.

Perhaps the most reasonable solution is to move Zinc-Seaside in its own configuration. Especially since Zinc is moving way faster than Seaside, we might want to deal with changing versions in a separate configuration and reference that one from Seaside using #stable.

Johan

On 15 Jun 2013, at 20:49, "Dale K. Henrichs" <[hidden email]> wrote:

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

Johan,

A third  project for Zinc Seaside support isn't a bad alternative ... then the #stable is only incremented when support for Zinc has been successfully vetted against both projects ...

Another alternative is to add a #stableSeaside symbolic version to the Zinc project that is "owned" by the Seaside project and changed whenever a new release has been vetted by the Seaside guys ...

Presumably the Seaside API is changing a lot less frequently than Zinc, so this approach will decouple Seaside from Zinc a bit without having to manage a completely separate package...

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| Sent: Saturday, June 15, 2013 12:38:16 PM
| Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
|
| Dale,
|
| I guess the case was #1.
| Zinc produced a new #stable version but the Seaside project
| referenced an older (incompatible) Zinc-Seaside package. In
| contrast, the Zinc project was offering a correct version of
| Zinc-Seaside in its #stable version, but Seaside references
| Zinc-Seaside using an explicit package version.
|
| So, my reasoning was that if Zinc was actually offering a matching
| Zinc-Seaside package version, it should be possible for Seaside to
| pick it up....
|
| I fully agree that, given the dependencies, the Zinc-Seaside version
| to use should be specified by the Seaside version. But, since
| Seaside references Zinc using #stable, then it should also reference
| Zinc-Seaside using #stable. Or Seaside should reference Zinc using
| an explicit version.
|
| In my mind, Zinc-Seaside is more of a shared package between Seaside
| and Zinc. Changes to both Seaside and Zinc might require it to be
| changed.
| In essence, if Zinc-Seaside would really have been owned by the
| Seaside project, then we would have needed to adapt it to work with
| the new Zinc.
|
| Perhaps the most reasonable solution is to move Zinc-Seaside in its
| own configuration. Especially since Zinc is moving way faster than
| Seaside, we might want to deal with changing versions in a separate
| configuration and reference that one from Seaside using #stable.
|
| Johan
|
| On 15 Jun 2013, at 20:49, "Dale K. Henrichs"
| <[hidden email]> wrote:
|
| > Johan,
| >
| > Sorry I've been completely absorbed by STIC this week, so the
| > doctor has not been in, but he is now:)
| >
| >
| > If I understand the flow of the conversation you are trying to
| > include the Zinc-Seaside package in the Zinc project without
| > specifying a proper dependency (because doing so would instroduce
| > a circularity between Seaside and Zinc).
| >
| > You are taking this approach because you ran into problems when
| > Zven made a certain set of changes to Zinc that broke the
| > adaptor...
| >
| > First I'd like to back up and say the Zinc-Seaside package _should_
| > be included in Seaside30 project with a dependency upon the Zinc
| > project. The Zinc-Seaside _is_ in support of the Seaside project -
| > the code is wrapping Zinc functionality with a Seaside-specific
| > (common) API for web servers.
| >
| > It's not correct to expect Sven to be responsible for ensuring that
| > Zinc-Seaside passes all of it's tests whenever he releases a new
| > version of Zinc, so he should not be responsible for the
| > Zinc-Seaside package.
| >
| > AFAICT, the issues came up when Sven released a new #stable version
| > of Zinc that,to quote Sven:
| >
| >  "Some recent changes to Zinc apparently resulted in some
| >   compatibility problems with Seaside. We fixed already at
| >   least one of them..."
| >
| > Either the "recent changes" were changes to the basic API (case #1)
| > or the Zinc-Seaside code itself was reaching into Zinc and using a
| > private API (case #2) or the Zinc-Seaside code was written to work
| > around/rely on a bug in Zinc (case #3).
| >
| > Let's skip case #1 for now.
| >
| > If the root cause is case #2, then the Seaside folks should work
| > with Zinc to define a public API that can be safely cause across
| > all future bugfixes ...
| >
| > If the root cause is case #3 then the Seaside folks can take out
| > there workaround and move forward.
| >
| > In both of the above cases the root cause is an anomaly that is not
| > expected to occur _every time Zinc is updated_.
| >
| > If the root cause is case #1, then we have a more difficult
| > situation because in reality an API change results in the creation
| > of two #stable versions ... One #stable version is Zinc with the
| > old API the other #stable vesion is Zinc with new API.
| >
| > If one expects to use a project in production applications, it is
| > reasonable to expect that the API itself remains consistent across
| > bug fixes ... I do not want to have to change my application in
| > order to safely pick up a bugfix from a project ... On the other
| > hand if I want to take advantage of the new api, I am be willing
| > to rewrite my application to take advantage of the new
| > capabilities... If we are indeed entering this area then we need
| > to adpopt the Sematic Versioning Spec[1] for version naming so
| > that API transitions can be recognized at the version-level which
| > then makes it possible specify project dependencies in tools such
| > as Metacello.
| >
| > There is a fourth case (case #4) that occurs to me and that is that
| > the Zinc API is not complete and Seaside is dependent upon a
| > project with an API that is still under development. If this is
| > the case, it behooves Sven to pre-announce his plan to change the
| > Zinc API in an upcoming release and give projects and production
| > apps that depend Zinc a chance to evaluate the implications and
| > adjust their applications/dependencies in anticipation of the
| > change...
| >
| > I am not "picking on Zinc." Sven is providing a very good product
| > free of charge to the community.
| >
| > I _do_ want to make sure that we have characterized the problem
| > completely before taking action in the form of adding features to
| > Metacello:)
| >
| > Dale
| >
| > [1] http://semver.org/
| >
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "Seaside - general discussion"
| > | <[hidden email]>
| > | Sent: Saturday, June 8, 2013 1:11:52 AM
| > | Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
| > |
| > | I think I need the metacello doctor to work out what I had in
| > | mind.
| > | Dale? you there? :-)
| > |
| > | In the meantime, I bumped a new version that references the
| > | correct
| > | Zinc-Seaside package version, such that it works correctly for
| > | now.
| > |
| > | The problem I have is that Metacello does not support the
| > | #requires:
| > | condition for project references. Before loading Zinc (with
| > | Zinc-Seaside), the Seaside-Core package needs to be loaded.
| > | I was under the false impression that such a statement was
| > | possible
| > | in Metacello, but alas... I am wrong.
| > |
| > | So now I need to figure out how we can:
| > | - let the Zinc-Seaside package version be controlled by the Zinc
| > | project (it makes more sense)
| > | - have the Seaside config reference the Zinc project but only
| > | load it
| > | after having loaded Seaside-Core.
| > |
| > | I tried several things yesterday including referencing Seaside
| > | from
| > | Zinc as well, but that went into an infinite loop (metacello does
| > | not detect loops?).
| > | Guess I was a bit too bold yesterday, but maybe Dale can shed
| > | some
| > | light on how to accomplish the above two items?
| > |
| > | Johan
| > |
| > | On 07 Jun 2013, at 16:43, Johan Brichau <[hidden email]>
| > | wrote:
| > |
| > | > Thanks Sven.
| > | >
| > | > I'm adapting the Seaside config to include that group instead
| > | > of
| > | > the Zinc-Seaside package.
| > | >
| > | > On 07 Jun 2013, at 14:17, Sven Van Caekenberghe <[hidden email]>
| > | > wrote:
| > | >
| > | >> Johan,
| > | >>
| > | >> On 07 Jun 2013, at 10:11, Johan Brichau <[hidden email]>
| > | >> wrote:
| > | >>
| > | >>> On 07 Jun 2013, at 10:03, Sven Van Caekenberghe
| > | >>> <[hidden email]>
| > | >>> wrote:
| > | >>>
| > | >>>> I am willing to do that (it sounds logical), but can that be
| > | >>>> done without depending on Seaside itself ? Because that does
| > | >>>> not sound practical, maybe reducing a circular dependency or
| > | >>>> at
| > | >>>> least an interference with the specific Seaside versions and
| > | >>>> groups that you initially want to load.
| > | >>>
| > | >>> If I am correct, that should not be a problem.
| > | >>>
| > | >>> The Seaside30 config can specify to load the 'Zinc-Seaside'
| > | >>> version as specified by the Zinc config.
| > | >>> All you have to do is list the Zinc-Seaside package in your
| > | >>> version methods and make sure that it does not get loaded
| > | >>> when
| > | >>> not explicitly asking for it.
| > | >>> I believe that can be done by not putting it in the #default
| > | >>> load
| > | >>> group.
| > | >>
| > | >> I just created
| > | >> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.49 which
| > | >> now has a 'Seaside' group that loads the 'Zinc-Seaside'
| > | >> adaptor
| > | >> package with a specific version. It is of course not loaded by
| > | >> default.
| > | >>
| > | >>> If you want your config to be complete, you can list a
| > | >>> dependency
| > | >>> on the Seaside project for the Zinc-Seaside package. This
| > | >>> would
| > | >>> only be loaded if somebody explicitly load the Zinc-Seaside
| > | >>> package.
| > | >>
| > | >> For now I skipped the dependency on Seaside, we'll see how it
| > | >> goes.
| > | >>
| > | >> Sven
| > | >>
| > | >>> If that does not work, we need to ask the Metacello doctor
| > | >>> ;-)
| > | >>>
| > | >>> Johan_______________________________________________
| > | >>> seaside mailing list
| > | >>> [hidden email]
| > | >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | >>
| > | >> --
| > | >> Sven Van Caekenberghe
| > | >> Proudly supporting Pharo
| > | >> http://pharo.org
| > | >> http://association.pharo.org
| > | >> http://consortium.pharo.org
| > | >>
| > | >>
| > | >>
| > | >>
| > | >> _______________________________________________
| > | >> seaside mailing list
| > | >> [hidden email]
| > | >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | >
| > | > _______________________________________________
| > | > seaside mailing list
| > | > [hidden email]
| > | > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > |
| > | _______________________________________________
| > | seaside mailing list
| > | [hidden email]
| > | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > |
| > _______________________________________________
| > seaside mailing list
| > [hidden email]
| > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside