The Trunk: SMLoader-cmm.85.mcz

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

The Trunk: SMLoader-cmm.85.mcz

commits-2
Chris Muller uploaded a new version of SMLoader to project The Trunk:
http://source.squeak.org/trunk/SMLoader-cmm.85.mcz

==================== Summary ====================

Name: SMLoader-cmm.85
Author: cmm
Time: 15 September 2015, 2:58:07.033 pm
UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
Ancestors: SMLoader-dtl.84

Revert dtl.84, because it broke the Catalog filters.

=============== Diff against SMLoader-dtl.84 ===============

Item was changed:
  ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') -----
  packageListCalculated
  "Return a list of the SMPackages that should be visible
  by applying all the filters. Also filter based on the currently
  selected category - if any."
  ^ self packages select: [:p |
+ filters allSatisfy: [:currFilter |
- filters anySatisfy: [:currFilter |
  currFilter isSymbol
  ifTrue: [(self perform: currFilter) value: p]
  ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz

Chris Muller-3
After review and some thought, it has become clear to me that Dave's
change is incorrect.  Please take a look at the SqueakMap filters and
consider them from the context of the use-cases -- what users need to
do with SqueakMap, and NOT from the context of a database that needs
to produce generalized "query results" <---- because it doesn't.

"Published" are the ones which have software to install, while
"Auto-installable" shows only packages that are installable from the
"Install" menu selection within the image.  These two filters are
useful together in a restricting fashion, not an inflating one, so
that newbies can see what's ready to go.

It was then that I also realized that Hannes' combination was not a
use-case either.  The use-cases we have are:  1) user wants to install
software or, 2) user wants to see what they have already installed.
Seeing a cumulative list of both installed and uninstalled satisfies
neither use-case.

Nevertheless you may once again "Clear all filters" (which was broken
by Dave's commit) if you want to see everything.

I still say SqueakMap catalog can and needs improvement, but we need
to really consider our changes because its clear that Göran put a lot
of thought into the usage of SqueakMap and its role in the community;
so I think we can afford to be a bit more skeptical before thinking
something like that was a bug in the first place and for nine years
running..


On Tue, Sep 15, 2015 at 2:58 PM,  <[hidden email]> wrote:

> Chris Muller uploaded a new version of SMLoader to project The Trunk:
> http://source.squeak.org/trunk/SMLoader-cmm.85.mcz
>
> ==================== Summary ====================
>
> Name: SMLoader-cmm.85
> Author: cmm
> Time: 15 September 2015, 2:58:07.033 pm
> UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
> Ancestors: SMLoader-dtl.84
>
> Revert dtl.84, because it broke the Catalog filters.
>
> =============== Diff against SMLoader-dtl.84 ===============
>
> Item was changed:
>   ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') -----
>   packageListCalculated
>         "Return a list of the SMPackages that should be visible
>         by applying all the filters. Also filter based on the currently
>         selected category - if any."
>         ^ self packages select: [:p |
> +               filters allSatisfy: [:currFilter |
> -               filters anySatisfy: [:currFilter |
>                         currFilter isSymbol
>                                 ifTrue: [(self perform: currFilter) value: p]
>                                 ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz

Karl Ramberg
Maybe it would be nice if the filters where off when opening the SqueakMap browser. With filters on it seems to be empty and not functioning. 

There is always warnings about package not being compatible when you try to load them anyway.

Karl

On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller <[hidden email]> wrote:
After review and some thought, it has become clear to me that Dave's
change is incorrect.  Please take a look at the SqueakMap filters and
consider them from the context of the use-cases -- what users need to
do with SqueakMap, and NOT from the context of a database that needs
to produce generalized "query results" <---- because it doesn't.

"Published" are the ones which have software to install, while
"Auto-installable" shows only packages that are installable from the
"Install" menu selection within the image.  These two filters are
useful together in a restricting fashion, not an inflating one, so
that newbies can see what's ready to go.

It was then that I also realized that Hannes' combination was not a
use-case either.  The use-cases we have are:  1) user wants to install
software or, 2) user wants to see what they have already installed.
Seeing a cumulative list of both installed and uninstalled satisfies
neither use-case.

Nevertheless you may once again "Clear all filters" (which was broken
by Dave's commit) if you want to see everything.

I still say SqueakMap catalog can and needs improvement, but we need
to really consider our changes because its clear that Göran put a lot
of thought into the usage of SqueakMap and its role in the community;
so I think we can afford to be a bit more skeptical before thinking
something like that was a bug in the first place and for nine years
running..


On Tue, Sep 15, 2015 at 2:58 PM,  <[hidden email]> wrote:
> Chris Muller uploaded a new version of SMLoader to project The Trunk:
> http://source.squeak.org/trunk/SMLoader-cmm.85.mcz
>
> ==================== Summary ====================
>
> Name: SMLoader-cmm.85
> Author: cmm
> Time: 15 September 2015, 2:58:07.033 pm
> UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
> Ancestors: SMLoader-dtl.84
>
> Revert dtl.84, because it broke the Catalog filters.
>
> =============== Diff against SMLoader-dtl.84 ===============
>
> Item was changed:
>   ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') -----
>   packageListCalculated
>         "Return a list of the SMPackages that should be visible
>         by applying all the filters. Also filter based on the currently
>         selected category - if any."
>         ^ self packages select: [:p |
> +               filters allSatisfy: [:currFilter |
> -               filters anySatisfy: [:currFilter |
>                         currFilter isSymbol
>                                 ifTrue: [(self perform: currFilter) value: p]
>                                 ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]!
>
>




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz

Chris Muller-4
> Maybe it would be nice if the filters where off when opening the SqueakMap
> browser. With filters on it seems to be empty and not functioning.

No.  Just a gentle reminder, the best way to talk about SqueakMap and
figure out how to improve it is to orient ourselves with the
requirements:

    http://wiki.squeak.org/squeak/6183

Presenting everything in the list would violate requirement #4.
Publishers who simply follow these publishing guidelines [1] are able
to meet these requirements, and so what users see in the list is what
WORKS.  If we show "everything" then we're hiding what works, and SM
becomes useless again.

Why do you say its an empty list?  I just checked Squeak 5.0 and there
are at least 20 packages showing up in there..?

IF nothing were to show up in the list when "Safely-available" filter
(and nothing else) is checked, then that's on us as a community.  It
simply means that we didn't care enough to take the 5 minutes
necessary to recertify our packages for the latest Squeak.  It is what
it is, but let's not fake out the "truth".

Thankfully, we DON'T have a blank list in 5.0.  Thanks to those in the
community who have gotten on board with the publishing guidelines we
have packages on SM that actually WORK (if they were done right) and
have single one of those requirements met.  Users are able to consume
those packages with one click instead of being forced to come begging
to the list for "how to load it"..

We will get there!

[1] -- SqueakMap Publishing Guidelines
http://wiki.squeak.org/squeak/6182

[2] -- How to designate existing SqueakMap packages for a new version of Squeak
http://wiki.squeak.org/squeak/6180

> There is always warnings about package not being compatible when you try to
> load them anyway.
>
> Karl
>
> On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller <[hidden email]> wrote:
>>
>> After review and some thought, it has become clear to me that Dave's
>> change is incorrect.  Please take a look at the SqueakMap filters and
>> consider them from the context of the use-cases -- what users need to
>> do with SqueakMap, and NOT from the context of a database that needs
>> to produce generalized "query results" <---- because it doesn't.
>>
>> "Published" are the ones which have software to install, while
>> "Auto-installable" shows only packages that are installable from the
>> "Install" menu selection within the image.  These two filters are
>> useful together in a restricting fashion, not an inflating one, so
>> that newbies can see what's ready to go.
>>
>> It was then that I also realized that Hannes' combination was not a
>> use-case either.  The use-cases we have are:  1) user wants to install
>> software or, 2) user wants to see what they have already installed.
>> Seeing a cumulative list of both installed and uninstalled satisfies
>> neither use-case.
>>
>> Nevertheless you may once again "Clear all filters" (which was broken
>> by Dave's commit) if you want to see everything.
>>
>> I still say SqueakMap catalog can and needs improvement, but we need
>> to really consider our changes because its clear that Göran put a lot
>> of thought into the usage of SqueakMap and its role in the community;
>> so I think we can afford to be a bit more skeptical before thinking
>> something like that was a bug in the first place and for nine years
>> running..
>>
>>
>> On Tue, Sep 15, 2015 at 2:58 PM,  <[hidden email]> wrote:
>> > Chris Muller uploaded a new version of SMLoader to project The Trunk:
>> > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: SMLoader-cmm.85
>> > Author: cmm
>> > Time: 15 September 2015, 2:58:07.033 pm
>> > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
>> > Ancestors: SMLoader-dtl.84
>> >
>> > Revert dtl.84, because it broke the Catalog filters.
>> >
>> > =============== Diff against SMLoader-dtl.84 ===============
>> >
>> > Item was changed:
>> >   ----- Method: SMLoaderPlus>>packageListCalculated (in category
>> > 'lists') -----
>> >   packageListCalculated
>> >         "Return a list of the SMPackages that should be visible
>> >         by applying all the filters. Also filter based on the currently
>> >         selected category - if any."
>> >         ^ self packages select: [:p |
>> > +               filters allSatisfy: [:currFilter |
>> > -               filters anySatisfy: [:currFilter |
>> >                         currFilter isSymbol
>> >                                 ifTrue: [(self perform: currFilter)
>> > value: p]
>> >                                 ifFalse: [self package: p
>> > filteredByCategory: (map object: currFilter)]]]!
>> >
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz

Karl Ramberg
Ok

Karl

On Wed, Sep 16, 2015 at 6:39 PM, Chris Muller <[hidden email]> wrote:
> Maybe it would be nice if the filters where off when opening the SqueakMap
> browser. With filters on it seems to be empty and not functioning.

No.  Just a gentle reminder, the best way to talk about SqueakMap and
figure out how to improve it is to orient ourselves with the
requirements:

    http://wiki.squeak.org/squeak/6183

Presenting everything in the list would violate requirement #4.
Publishers who simply follow these publishing guidelines [1] are able
to meet these requirements, and so what users see in the list is what
WORKS.  If we show "everything" then we're hiding what works, and SM
becomes useless again.

Why do you say its an empty list?  I just checked Squeak 5.0 and there
are at least 20 packages showing up in there..?

IF nothing were to show up in the list when "Safely-available" filter
(and nothing else) is checked, then that's on us as a community.  It
simply means that we didn't care enough to take the 5 minutes
necessary to recertify our packages for the latest Squeak.  It is what
it is, but let's not fake out the "truth".

Thankfully, we DON'T have a blank list in 5.0.  Thanks to those in the
community who have gotten on board with the publishing guidelines we
have packages on SM that actually WORK (if they were done right) and
have single one of those requirements met.  Users are able to consume
those packages with one click instead of being forced to come begging
to the list for "how to load it"..

We will get there!

[1] -- SqueakMap Publishing Guidelines
http://wiki.squeak.org/squeak/6182

[2] -- How to designate existing SqueakMap packages for a new version of Squeak
http://wiki.squeak.org/squeak/6180

> There is always warnings about package not being compatible when you try to
> load them anyway.
>
> Karl
>
> On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller <[hidden email]> wrote:
>>
>> After review and some thought, it has become clear to me that Dave's
>> change is incorrect.  Please take a look at the SqueakMap filters and
>> consider them from the context of the use-cases -- what users need to
>> do with SqueakMap, and NOT from the context of a database that needs
>> to produce generalized "query results" <---- because it doesn't.
>>
>> "Published" are the ones which have software to install, while
>> "Auto-installable" shows only packages that are installable from the
>> "Install" menu selection within the image.  These two filters are
>> useful together in a restricting fashion, not an inflating one, so
>> that newbies can see what's ready to go.
>>
>> It was then that I also realized that Hannes' combination was not a
>> use-case either.  The use-cases we have are:  1) user wants to install
>> software or, 2) user wants to see what they have already installed.
>> Seeing a cumulative list of both installed and uninstalled satisfies
>> neither use-case.
>>
>> Nevertheless you may once again "Clear all filters" (which was broken
>> by Dave's commit) if you want to see everything.
>>
>> I still say SqueakMap catalog can and needs improvement, but we need
>> to really consider our changes because its clear that Göran put a lot
>> of thought into the usage of SqueakMap and its role in the community;
>> so I think we can afford to be a bit more skeptical before thinking
>> something like that was a bug in the first place and for nine years
>> running..
>>
>>
>> On Tue, Sep 15, 2015 at 2:58 PM,  <[hidden email]> wrote:
>> > Chris Muller uploaded a new version of SMLoader to project The Trunk:
>> > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: SMLoader-cmm.85
>> > Author: cmm
>> > Time: 15 September 2015, 2:58:07.033 pm
>> > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
>> > Ancestors: SMLoader-dtl.84
>> >
>> > Revert dtl.84, because it broke the Catalog filters.
>> >
>> > =============== Diff against SMLoader-dtl.84 ===============
>> >
>> > Item was changed:
>> >   ----- Method: SMLoaderPlus>>packageListCalculated (in category
>> > 'lists') -----
>> >   packageListCalculated
>> >         "Return a list of the SMPackages that should be visible
>> >         by applying all the filters. Also filter based on the currently
>> >         selected category - if any."
>> >         ^ self packages select: [:p |
>> > +               filters allSatisfy: [:currFilter |
>> > -               filters anySatisfy: [:currFilter |
>> >                         currFilter isSymbol
>> >                                 ifTrue: [(self perform: currFilter)
>> > value: p]
>> >                                 ifFalse: [self package: p
>> > filteredByCategory: (map object: currFilter)]]]!
>> >
>> >
>>
>