[Seaside-dev] WAPackage dependencies

Julian Fitzell jfitzell at gmail.com
Thu Dec 18 16:23:57 UTC 2008


Sound right, yup.

On Thu, Dec 18, 2008 at 4:43 PM, John O'Keefe
<wembley.instantiations at gmail.com> wrote:
> Julian -
>
> OK, I think I understand.  You are saying that WAPackage *should* reflect
> all the *legitimate* dependencies *within* Seaside (I added this last caveat
> based on our earlier discussions).  When WAPackage does not accurately
> reflect these dependencies, it can be either an error in the WAPackage
> dependency description *or* an error in the actual interrelationship of the
> code.  Right?
>
> I don't think I need Lukas' static analysis output since VA Smalltalk will
> alert me (sometimes quite forcefully!) if the dependencies are wrong.  Since
> I already have a mechanism to add dependencies that are not reflected in
> WAPackage, I will use this mechanism to work-around any existing mismatches
> in the WAPackage dependencies.
>
> John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
>
>
> On Thu, Dec 18, 2008 at 10:09 AM, Julian Fitzell <jfitzell at gmail.com> wrote:
>>
>> Hey John,
>>
>> So, let me try again.
>>
>> The goal of WAPackage is to document the dependencies between packages
>> as a human would understand them (ie. by the design).
>>
>> Lukas also has a tool that looks for code dependencies (subclassing,
>> referencing a class, etc).
>>
>> There *should* not be any code dependencies that go beyond the
>> dependencies of WAPackage, and if there are then it is probably a bug.
>> In each case, though, we need to look at it and see whether the bug is
>> that we failed to document a legitimate logical dependency in
>> WAPackage or whether an inadvertent code dependency has been
>> introduced.
>>
>> This allows us to look for "red flags" by taking the set of detected
>> code dependencies and subtracting the set of WAPackage dependencies.
>>
>> It also allows us to build a possible load order (even in presence of
>> incorrect code dependencies) where one exists by taking the union of
>> the two dependency sets. This is what you would need to do to build a
>> load order (at least during development). Lukas has a tool working
>> that does this but I'm not sure exactly what you need to do with the
>> data. I imagine it can be adapted.
>>
>> So yes, we are saying that WAPackage dependencies should not be simply
>> updated to reflect existing dependencies unless they are by-design
>> dependencies that just happened to get missed on WAPackage.
>>
>> Is that clearer?
>>
>> Julian
>>
>> On Thu, Dec 18, 2008 at 2:20 PM, John O'Keefe
>> <wembley.instantiations at gmail.com> wrote:
>> > Julian and Lukas -
>> >
>> > VA Smalltalk is quite strict about dependencies and complains when they
>> > are
>> > not met -- the comment on my package update is an exact copy of this
>> > particular complaint.  Because VA Smalltalk packages for runtime based
>> > on
>> > dependencies, it is critical for us to have them right in any package
>> > destined for a runtime application.  For a development time package
>> > (such as
>> > a testcase package), these complaint can be (but not neccessarily are)
>> > less
>> > important.
>> >
>> > Before the advent of WAPackage, I had an equivalent to its dependencies
>> > in
>> > the VAPackageExporter (Lukas, you've seen this) which was used to
>> > generate
>> > the dependencies when exporting Seaside packages from Squeak to VA
>> > Smalltalk.  With the advent of WAPackage, these dependency definitions
>> > have
>> > been reduced to only those that go outside Seaside (such as SUnit and
>> > Refactoring Browser) which I merge with the dependencies from WAPackage
>> > when
>> > exporting.
>> >
>> > So, I'm not quite sure how to interpret your post.  Did you mean to say
>> > that
>> > I should not have modified the dependencies for JQuery-Tests-Core?  If
>> > so, I
>> > guess I am still not clear on exactly what the intent of the WAPackage
>> > dependencies is.  I certainly have no intent of subverting the desired
>> > use
>> > of WAPackage dependencies, so perhaps I need to change my approach to
>> > generating prerequisites for Seaside packages in VA Smalltalk.  I am
>> > open to
>> > suggestions.
>> >
>> > John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
>> >
>> >
>> > On Thu, Dec 18, 2008 at 5:14 AM, Julian Fitzell <jfitzell at gmail.com>
>> > wrote:
>> >>
>> >> JQuery-Tests-Core-jok.46.mcz
>> >> from Seaside 2.9 by John O'Keefe <john_okeefe at instantiations.com>
>> >> - update dependencies: Seaside-Development is required due to
>> >> referenced class WAPrettyPrintedDocument from
>> >> JQAllTests>>#renderJavascriptOn:
>> >>
>> >> John, the goal is, I think to have the WAPackage dependencies reflect
>> >> functional (or "desired") dependencies and that that information
>> >> combined with static dependency analysis will allow us to (a) create a
>> >> workable load order if possible and by considering the union of the
>> >> two dependency sets (b) spot problems where there are static
>> >> dependencies that should not exist by looking at the difference of the
>> >> one set from the other.
>> >>
>> >> This concept has got a bit muddied though: I was just talking about it
>> >> again with Lukas the other day and he had forgotten we were talking
>> >> about doing that and so was not combining the static dependency info
>> >> into the load order. But I think he was going to try doing that now...
>> >>
>> >> Julian
>> >> _______________________________________________
>> >> seaside-dev mailing list
>> >> seaside-dev at lists.squeakfoundation.org
>> >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>> >
>> >
>> > _______________________________________________
>> > seaside-dev mailing list
>> > seaside-dev at lists.squeakfoundation.org
>> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>> >
>> >
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>


More information about the seaside-dev mailing list