Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Richard O'Keefe]

Handlingas: Dictionary
is really quite straightforward.
Add a one-line method to Bag:

Bag>>
associationsDo: aBlock
contents associationsDo: aBlock.

This is a good idea anyway, because currently there is a bug where
aBag associationsDo: aBlock
fails to pass Associations to aBlock.  Once you have done that,
'abracadabra' asBag as: Dictionary
just works.  This one simple addition
 - makes aBag associationsDo: aBlock work when it didn't before
 - makes aBag asDictionary work
 - makes aBag as: Dictionary work
 - makes Dictionary newFrom: aBag work




On Thu, 7 Mar 2019 at 07:35, Sven Van Caekenberghe  wrote:

> I am still not convinced.
>
> > On 6 Mar 2019, at 19:24, Tim Mackinnon  wrote:
> >
> > I still am tempted to make asDictionary work - because the the moment
> you get a #key , DNU error - which is definitely not right.
>
> The error might not be super clear, but it is not wrong, the elements of
> your collection do not respond to #key, a necessity to create a dictionary
> from a collection of associations/pairs.
>
> Also, if you modify #asDictionary like that, then
>
>as: #Dictionary
>
> will still fail.
>
> This is all not so simple as it seems.
>
> > So should Bag asDictionary give you a reasonable dictionary, or should
> it throw a proper exception - something like:
> >
> > DomainError signal: ‘#asDictionary not supported, use #valueAndCounts’
> >
> > Is that better - or do we accept that it inherits it from Collection and
> so can do something useful?
> >
> > Tim
> >
> >> On 6 Mar 2019, at 18:11, p...@highoctane.be wrote:
> >>
> >> And when asking the object:
> >>
> >> #(1 2 4 5 6 7 2 1 4 3) asBag  isDictionary
> >>
> >> we get false. So, not, not a dictionary.
> >>
> >> I still have been using #valuesAndCounts to get the dictionary out of a
> bag on several occasions.
> >>
> >> And is useful indeed.
> >>
> >> #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2
> >>
> >> and
> >>
> >> #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2
> >>
> >> seem pretty much the same.
> >>
> >> But in this age of streams/reactive streams and lazy evaluations, what
> do we have in Pharo on that front?
> >>
> >> Phil
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe 
> wrote:
> >> I was just explaining how it is now, what I think the rationale is
> behind it.
> >>
> >> I understand #asDictionary as working on a collection of
> pairs/associations (because it basically goes to #withAll:).
> >>
> >> A bag is just a collection that is optimised for many duplicates, the
> fact that you have values and counts is more an implementation detail than
> an intrinsic property.
> >>
> >> The conversion that you want, and that already exists in
> #valuesAndCounts is one interpretation of what a bag is, not the only one.
> A bag is foremost a collection of things.
> >>
> >> I am not immediately convinced that #valuesAndCounts should be the
> default #asDictionary interpretation.
> >>
> >> What about the inverse for example ?
> >>
> >>   { #foo->2. #bar->3 } asDictionary asBag.
> >>
> >> But this is certainly an interesting discussion.
> >>
> >> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
> >> >
> >> > As Richard said - as a bag is relationship between keys and
> frequencies, I would expect it to be able to convert to a dictionary.
> >> >
> >> > It displays in an inspector just like a Dictionary - which is why I
> figured I could convert to pass it back to the exercise that was written
> with Dictionaries in mind.
> >> >
> >> > 
> >> >
> >> >
> >> > The code to fix it is quite simple, but on these kinds of things - I
> thought it worth checking before submitting a PR.
> >> >
> >> > Tim
> >> >
> >> >
> >> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
> >> >>
> >> >> Why would that work ? What would you expect the output to be ?
> >> >>
> >> >> Try:
> >> >>
> >> >>  #(1 2 3) asDictionary
> >> >>
> >> >> it fails in exactly the same way. You need key/value pairs
> (Associations).
> >> >>
> >> >> These do work
> >> >>
> >> >>  Bag new add: #foo->100; asDictionary.
> >> >>
> >> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
> >> >>
> >> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> >> >>>
> >> >>> I was surprised to find that a Bag can’t convert to a dictionary -
> e.g.
> >> >>>
> >> >>> Bag new
> >> >>> addAll: 'aacddd’;
> >> >>> asDictionary
> >> >>>
> >> >>> Gives an error - Dnu #key
> >> >>>
> >> >>>
> >> >>> It looks to me like Bag is inheriting a bad version of
> #associationsDo:  and instead could simply forward it to #doWithOccurences:
> instead?
> >> >>>
> >> >>> I know Bag is not used that much - but it comes up a lot in
> programming exercises.
> >> >>>
> >> >>> Tim
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >
>
>
>

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Richard O'Keefe]

To me, a bag is first and foremost a multiset.
Yes, it's a collection, but it's not *just* a collection.
It's a very specific kind of collection with a very
salient "characteristic function".

In my own Smalltalk library, #asDictionary isn't even *defined*
on things that are not dictionaries or some kind of mapping,
because let's face it, a dictionary *isn't* a collection of
Associations, and trying to make it look like one made
Smalltalk-80 rather inconsistent.  For example, if a dictionary
were a collection of associations, you would expect
(Dictionary with: #a -> 1 with: #b -> 2) includes: #a -> 1
to be true. No, it's false.  You would expect
(Dictionary with: #a -> 1 with: #b -> 2) asArray
to be (a->1 b->2).  No, it's (1 2).  In order to avoid major
confusion, I had to learn never to think of Associations in
connection with Dictionaries.  So I expect #asDictionary to
have something to do with #keysAndValuesDo:.
or something like that.

For {1->2. 3->4} asDictionary I would have to write
Dictionary withAllAssociations: {1->2. 3->4}
except that I never actually found a use for it.

#valuesAndCounts is a method that violates good OO practice,
because it exposes (what you'd expect to be) private state.
For example,
  b := 'abracadabra' asBag.
  b valuesAndCounts at: $a put: 'BOOM!'.
  b
select, Print It, BOOM!.  It should *copy* the dictionary.



On Thu, 7 Mar 2019 at 04:50, Sven Van Caekenberghe  wrote:

> I was just explaining how it is now, what I think the rationale is behind
> it.
>
> I understand #asDictionary as working on a collection of
> pairs/associations (because it basically goes to #withAll:).
>
> A bag is just a collection that is optimised for many duplicates, the fact
> that you have values and counts is more an implementation detail than an
> intrinsic property.
>
> The conversion that you want, and that already exists in #valuesAndCounts
> is one interpretation of what a bag is, not the only one. A bag is foremost
> a collection of things.
>
> I am not immediately convinced that #valuesAndCounts should be the default
> #asDictionary interpretation.
>
> What about the inverse for example ?
>
>   { #foo->2. #bar->3 } asDictionary asBag.
>
> But this is certainly an interesting discussion.
>
> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
> >
> > As Richard said - as a bag is relationship between keys and frequencies,
> I would expect it to be able to convert to a dictionary.
> >
> > It displays in an inspector just like a Dictionary - which is why I
> figured I could convert to pass it back to the exercise that was written
> with Dictionaries in mind.
> >
> > 
> >
> >
> > The code to fix it is quite simple, but on these kinds of things - I
> thought it worth checking before submitting a PR.
> >
> > Tim
> >
> >
> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
> >>
> >> Why would that work ? What would you expect the output to be ?
> >>
> >> Try:
> >>
> >>  #(1 2 3) asDictionary
> >>
> >> it fails in exactly the same way. You need key/value pairs
> (Associations).
> >>
> >> These do work
> >>
> >>  Bag new add: #foo->100; asDictionary.
> >>
> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
> >>
> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> >>>
> >>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
> >>>
> >>> Bag new
> >>> addAll: 'aacddd’;
> >>> asDictionary
> >>>
> >>> Gives an error - Dnu #key
> >>>
> >>>
> >>> It looks to me like Bag is inheriting a bad version of
> #associationsDo:  and instead could simply forward it to #doWithOccurences:
> instead?
> >>>
> >>> I know Bag is not used that much - but it comes up a lot in
> programming exercises.
> >>>
> >>> Tim
> >>
> >>
> >
>
>
>

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Ben Coman]

On Thu, 7 Mar 2019 at 02:16, Esteban Maringolo  wrote:

> I couldn't find a "simple enough" solution to deal with that, so I
> moved to emulated Linux [1].
>
> I don't know if the long file path is a limitation of Windows itself or
> libgit2.
>

Its a combination, but for our purposes the limitation lies with libgit2.
Issue open since April 2015... "Support `core.longpaths` on Windows "
https://github.com/libgit2/libgit2/issues/3053#issuecomment-324363336

cheers -ben

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Dale Henrichs]

On 3/6/19 8:18 AM, Sean P. DeNigris wrote:

Tim Mackinnon wrote

how is this shared repository supposed to work?

While I initially liked the space efficiency of the shared approach, I
eventually gave up because it created too many (often obscure) problems. It
just doesn't seem to be a good match for git, although you can get away with
it in the simplest cases (read-only, no branch switching).


The use case that I have used for years (tODE and GemStone) is that I am 
sharing 60+ git repositories amongst 60+ images and I want all of the 
images to be sharing the same versions of all of the git projects. When 
I want to do private work I create a clone that is local to the image 
that I'm working in and do my work on a topic branch ... when I'm done 
with the private work, I merge the topic branch back into my commonly 
shared branch and then update the shared git repository so that when I 
do activate one of the images.


I can quickly tell (via tools) that i have not loaded the latest shared 
code into my image ... if I care (like preparing to do development), I 
update to the latest shared code, so that my changes can be shared... if 
I don't care, then I remember not to make any code changes that I want 
to keep:)


The images that I am using are a mix different versions of GemStone, so 
I _do_ make it a practice to ensure that projects I work with are all 
loadable in the different versions of GemStone that I care about via 
baseline changes (I use packages for version-specific code and avoid 
putting version-specific code on different branches or tags) ...


So, when you say it's not "a good match for git", I don't think that it 
is "git" that is the problem, but the use cases themselves are the 
culprit... different tool features are very likely needed to support 
different use cases ...


Dale

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Richard Sargent]

On Wed, Mar 6, 2019 at 10:25 AM Tim Mackinnon  wrote:

> I still am tempted to make asDictionary work - because the the moment you
> get a #key , DNU error - which is definitely not right.
>

This argument gives me the willies. Sorry.

I can see an argument that a sequenceable collection can implement a
meaningful #asDictionary, using #keysAndValuesDo:. The key is the index of
each element, so it makes sense.

But, #asDictionary for a non-sequenceable collection doesn't make sense
(other than for Dictionary and its variants, obviously). What would the
keys be from a Set, for example?

Bag>>#asDictionary makes sense if (and in my opinion, only if) you define
it to rely on the internal implementation. #valuesAndCounts make sense
because it doesn't rely on internal implementation details to define it,
although it typically is implemented to use those internal implementation
details. I think expressing it as a conversion is a poor choice. Asking it
for a different representation is good.

[And as an aside, given that the API expresses #occurrencesOf:,
#valuesAndCounts might have been better named #valuesAndOccurrences (and
perhaps "With" rather than "And").]


> So should Bag asDictionary give you a reasonable dictionary, or should it
> throw a proper exception - something like:
>
> DomainError signal: ‘#asDictionary not supported, use #valueAndCounts’
>
> Is that better - or do we accept that it inherits it from Collection and
> so can do something useful?
>
> Tim
>
> On 6 Mar 2019, at 18:11, p...@highoctane.be wrote:
>
> And when asking the object:
>
> #(1 2 4 5 6 7 2 1 4 3) asBag  isDictionary
>
> we get false. So, not, not a dictionary.
>
> I still have been using #valuesAndCounts to get the dictionary out of a
> bag on several occasions.
>
> And is useful indeed.
>
> #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2
>
> and
>
> #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2
>
> seem pretty much the same.
>
> But in this age of streams/reactive streams and lazy evaluations, what do
> we have in Pharo on that front?
>
> Phil
>
>
>
>
>
> On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe  wrote:
>
>> I was just explaining how it is now, what I think the rationale is behind
>> it.
>>
>> I understand #asDictionary as working on a collection of
>> pairs/associations (because it basically goes to #withAll:).
>>
>> A bag is just a collection that is optimised for many duplicates, the
>> fact that you have values and counts is more an implementation detail than
>> an intrinsic property.
>>
>> The conversion that you want, and that already exists in #valuesAndCounts
>> is one interpretation of what a bag is, not the only one. A bag is foremost
>> a collection of things.
>>
>> I am not immediately convinced that #valuesAndCounts should be the
>> default #asDictionary interpretation.
>>
>> What about the inverse for example ?
>>
>>   { #foo->2. #bar->3 } asDictionary asBag.
>>
>> But this is certainly an interesting discussion.
>>
>> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
>> >
>> > As Richard said - as a bag is relationship between keys and
>> frequencies, I would expect it to be able to convert to a dictionary.
>> >
>> > It displays in an inspector just like a Dictionary - which is why I
>> figured I could convert to pass it back to the exercise that was written
>> with Dictionaries in mind.
>> >
>> > 
>> >
>> >
>> > The code to fix it is quite simple, but on these kinds of things - I
>> thought it worth checking before submitting a PR.
>> >
>> > Tim
>> >
>> >
>> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
>> >>
>> >> Why would that work ? What would you expect the output to be ?
>> >>
>> >> Try:
>> >>
>> >>  #(1 2 3) asDictionary
>> >>
>> >> it fails in exactly the same way. You need key/value pairs
>> (Associations).
>> >>
>> >> These do work
>> >>
>> >>  Bag new add: #foo->100; asDictionary.
>> >>
>> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
>> >>
>> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
>> >>>
>> >>> I was surprised to find that a Bag can’t convert to a dictionary -
>> e.g.
>> >>>
>> >>> Bag new
>> >>> addAll: 'aacddd’;
>> >>> asDictionary
>> >>>
>> >>> Gives an error - Dnu #key
>> >>>
>> >>>
>> >>> It looks to me like Bag is inheriting a bad version of
>> #associationsDo:  and instead could simply forward it to #doWithOccurences:
>> instead?
>> >>>
>> >>> I know Bag is not used that much - but it comes up a lot in
>> programming exercises.
>> >>>
>> >>> Tim
>> >>
>> >>
>> >
>>
>>
>>
>>
>

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Sven Van Caekenberghe]

I am still not convinced.

> On 6 Mar 2019, at 19:24, Tim Mackinnon  wrote:
> 
> I still am tempted to make asDictionary work - because the the moment you get 
> a #key , DNU error - which is definitely not right.

The error might not be super clear, but it is not wrong, the elements of your 
collection do not respond to #key, a necessity to create a dictionary from a 
collection of associations/pairs.

Also, if you modify #asDictionary like that, then

   as: #Dictionary 

will still fail.

This is all not so simple as it seems.

> So should Bag asDictionary give you a reasonable dictionary, or should it 
> throw a proper exception - something like:
> 
> DomainError signal: ‘#asDictionary not supported, use #valueAndCounts’
> 
> Is that better - or do we accept that it inherits it from Collection and so 
> can do something useful?
> 
> Tim
> 
>> On 6 Mar 2019, at 18:11, p...@highoctane.be wrote:
>> 
>> And when asking the object:
>> 
>> #(1 2 4 5 6 7 2 1 4 3) asBag  isDictionary
>> 
>> we get false. So, not, not a dictionary.
>> 
>> I still have been using #valuesAndCounts to get the dictionary out of a bag 
>> on several occasions.
>> 
>> And is useful indeed.
>> 
>> #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2
>> 
>> and 
>> 
>> #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 
>> 
>> seem pretty much the same.
>> 
>> But in this age of streams/reactive streams and lazy evaluations, what do we 
>> have in Pharo on that front?
>> 
>> Phil
>> 
>> 
>> 
>> 
>> 
>> On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe  wrote:
>> I was just explaining how it is now, what I think the rationale is behind it.
>> 
>> I understand #asDictionary as working on a collection of pairs/associations 
>> (because it basically goes to #withAll:).
>> 
>> A bag is just a collection that is optimised for many duplicates, the fact 
>> that you have values and counts is more an implementation detail than an 
>> intrinsic property.
>> 
>> The conversion that you want, and that already exists in #valuesAndCounts is 
>> one interpretation of what a bag is, not the only one. A bag is foremost a 
>> collection of things.
>> 
>> I am not immediately convinced that #valuesAndCounts should be the default 
>> #asDictionary interpretation.
>> 
>> What about the inverse for example ?
>> 
>>   { #foo->2. #bar->3 } asDictionary asBag.
>> 
>> But this is certainly an interesting discussion.
>> 
>> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
>> > 
>> > As Richard said - as a bag is relationship between keys and frequencies, I 
>> > would expect it to be able to convert to a dictionary.
>> > 
>> > It displays in an inspector just like a Dictionary - which is why I 
>> > figured I could convert to pass it back to the exercise that was written 
>> > with Dictionaries in mind.
>> > 
>> > 
>> > 
>> > 
>> > The code to fix it is quite simple, but on these kinds of things - I 
>> > thought it worth checking before submitting a PR.
>> > 
>> > Tim
>> > 
>> > 
>> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
>> >> 
>> >> Why would that work ? What would you expect the output to be ?
>> >> 
>> >> Try:
>> >> 
>> >>  #(1 2 3) asDictionary 
>> >> 
>> >> it fails in exactly the same way. You need key/value pairs (Associations).
>> >> 
>> >> These do work
>> >> 
>> >>  Bag new add: #foo->100; asDictionary.
>> >> 
>> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
>> >> 
>> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
>> >>> 
>> >>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
>> >>> 
>> >>> Bag new 
>> >>> addAll: 'aacddd’; 
>> >>> asDictionary 
>> >>> 
>> >>> Gives an error - Dnu #key
>> >>> 
>> >>> 
>> >>> It looks to me like Bag is inheriting a bad version of #associationsDo:  
>> >>> and instead could simply forward it to #doWithOccurences: instead?
>> >>> 
>> >>> I know Bag is not used that much - but it comes up a lot in programming 
>> >>> exercises.
>> >>> 
>> >>> Tim
>> >> 
>> >> 
>> > 
>> 
>> 
>> 
> 

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Tim Mackinnon]

I still am tempted to make asDictionary work - because the the moment you get a 
#key , DNU error - which is definitely not right.

So should Bag asDictionary give you a reasonable dictionary, or should it throw 
a proper exception - something like:

DomainError signal: ‘#asDictionary not supported, use #valueAndCounts’

Is that better - or do we accept that it inherits it from Collection and so can 
do something useful?

Tim

> On 6 Mar 2019, at 18:11, p...@highoctane.be wrote:
> 
> And when asking the object:
> 
> #(1 2 4 5 6 7 2 1 4 3) asBag  isDictionary
> 
> we get false. So, not, not a dictionary.
> 
> I still have been using #valuesAndCounts to get the dictionary out of a bag 
> on several occasions.
> 
> And is useful indeed.
> 
> #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2
> 
> and 
> 
> #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 
> 
> seem pretty much the same.
> 
> But in this age of streams/reactive streams and lazy evaluations, what do we 
> have in Pharo on that front?
> 
> Phil
> 
> 
> 
> 
> 
> On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe  > wrote:
> I was just explaining how it is now, what I think the rationale is behind it.
> 
> I understand #asDictionary as working on a collection of pairs/associations 
> (because it basically goes to #withAll:).
> 
> A bag is just a collection that is optimised for many duplicates, the fact 
> that you have values and counts is more an implementation detail than an 
> intrinsic property.
> 
> The conversion that you want, and that already exists in #valuesAndCounts is 
> one interpretation of what a bag is, not the only one. A bag is foremost a 
> collection of things.
> 
> I am not immediately convinced that #valuesAndCounts should be the default 
> #asDictionary interpretation.
> 
> What about the inverse for example ?
> 
>   { #foo->2. #bar->3 } asDictionary asBag.
> 
> But this is certainly an interesting discussion.
> 
> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
> > 
> > As Richard said - as a bag is relationship between keys and frequencies, I 
> > would expect it to be able to convert to a dictionary.
> > 
> > It displays in an inspector just like a Dictionary - which is why I figured 
> > I could convert to pass it back to the exercise that was written with 
> > Dictionaries in mind.
> > 
> > 
> > 
> > 
> > The code to fix it is quite simple, but on these kinds of things - I 
> > thought it worth checking before submitting a PR.
> > 
> > Tim
> > 
> > 
> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  >> > wrote:
> >> 
> >> Why would that work ? What would you expect the output to be ?
> >> 
> >> Try:
> >> 
> >>  #(1 2 3) asDictionary 
> >> 
> >> it fails in exactly the same way. You need key/value pairs (Associations).
> >> 
> >> These do work
> >> 
> >>  Bag new add: #foo->100; asDictionary.
> >> 
> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
> >> 
> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> >>> 
> >>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
> >>> 
> >>> Bag new 
> >>> addAll: 'aacddd’; 
> >>> asDictionary 
> >>> 
> >>> Gives an error - Dnu #key
> >>> 
> >>> 
> >>> It looks to me like Bag is inheriting a bad version of #associationsDo:  
> >>> and instead could simply forward it to #doWithOccurences: instead?
> >>> 
> >>> I know Bag is not used that much - but it comes up a lot in programming 
> >>> exercises.
> >>> 
> >>> Tim
> >> 
> >> 
> > 
> 
> 
> 

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Esteban Maringolo]

I couldn't find a "simple enough" solution to deal with that, so I
moved to emulated Linux [1].

I don't know if the long file path is a limitation of Windows itself or libgit2.

Because if it's the former, then I'll try this setting in Windows 10
and let you know if it works:
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

Regards!

Esteban A. Maringolo

El mié., 6 mar. 2019 a las 13:19, Sean P. DeNigris
() escribió:
>
> Tim Mackinnon wrote
> > how is this shared repository supposed to work?
>
> While I initially liked the space efficiency of the shared approach, I
> eventually gave up because it created too many (often obscure) problems. It
> just doesn't seem to be a good match for git, although you can get away with
> it in the simplest cases (read-only, no branch switching). It sounds like
> you may not have the luxury of avoiding it so hopefully someone can provide
> more constructive help.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[p...@highoctane.be]

And then the Pharo launcher folder suddenly appears as a 20GB folder...

Same league as a Maven .m2, albeit with a messier structure, full of copies
all over the place.

Is Cargo going to help us there?

Phil



On Wed, Mar 6, 2019 at 5:18 PM Sean P. DeNigris 
wrote:

> Tim Mackinnon wrote
> > how is this shared repository supposed to work?
>
> While I initially liked the space efficiency of the shared approach, I
> eventually gave up because it created too many (often obscure) problems. It
> just doesn't seem to be a good match for git, although you can get away
> with
> it in the simplest cases (read-only, no branch switching). It sounds like
> you may not have the luxury of avoiding it so hopefully someone can provide
> more constructive help.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>
>

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[p...@highoctane.be]

And when asking the object:

#(1 2 4 5 6 7 2 1 4 3) asBag  isDictionary

we get false. So, not, not a dictionary.

I still have been using #valuesAndCounts to get the dictionary out of a bag
on several occasions.

And is useful indeed.

#(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2

and

#(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2

seem pretty much the same.

But in this age of streams/reactive streams and lazy evaluations, what do
we have in Pharo on that front?

Phil





On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe  wrote:

> I was just explaining how it is now, what I think the rationale is behind
> it.
>
> I understand #asDictionary as working on a collection of
> pairs/associations (because it basically goes to #withAll:).
>
> A bag is just a collection that is optimised for many duplicates, the fact
> that you have values and counts is more an implementation detail than an
> intrinsic property.
>
> The conversion that you want, and that already exists in #valuesAndCounts
> is one interpretation of what a bag is, not the only one. A bag is foremost
> a collection of things.
>
> I am not immediately convinced that #valuesAndCounts should be the default
> #asDictionary interpretation.
>
> What about the inverse for example ?
>
>   { #foo->2. #bar->3 } asDictionary asBag.
>
> But this is certainly an interesting discussion.
>
> > On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
> >
> > As Richard said - as a bag is relationship between keys and frequencies,
> I would expect it to be able to convert to a dictionary.
> >
> > It displays in an inspector just like a Dictionary - which is why I
> figured I could convert to pass it back to the exercise that was written
> with Dictionaries in mind.
> >
> > 
> >
> >
> > The code to fix it is quite simple, but on these kinds of things - I
> thought it worth checking before submitting a PR.
> >
> > Tim
> >
> >
> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
> >>
> >> Why would that work ? What would you expect the output to be ?
> >>
> >> Try:
> >>
> >>  #(1 2 3) asDictionary
> >>
> >> it fails in exactly the same way. You need key/value pairs
> (Associations).
> >>
> >> These do work
> >>
> >>  Bag new add: #foo->100; asDictionary.
> >>
> >>  Bag new addAll: 'ABABAB'; valuesAndCounts.
> >>
> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> >>>
> >>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
> >>>
> >>> Bag new
> >>> addAll: 'aacddd’;
> >>> asDictionary
> >>>
> >>> Gives an error - Dnu #key
> >>>
> >>>
> >>> It looks to me like Bag is inheriting a bad version of
> #associationsDo:  and instead could simply forward it to #doWithOccurences:
> instead?
> >>>
> >>> I know Bag is not used that much - but it comes up a lot in
> programming exercises.
> >>>
> >>> Tim
> >>
> >>
> >
>
>
>
>

Re: [Pharo-users] IMAP in Pharo

[Tim Mackinnon]

> On 6 Mar 2019, at 16:08, Sean P. DeNigris  wrote:
> 
> cedreek wrote
>> Still havent get my head around this FORK/PR cycle but I will for sure one
>> day :)
> 
> It took me quite a while to grok. Fork = 'personal remote clone' and: [ PR =
> 'UI support for discussing, testing, and accepting commits' ]

It took me even longer to realise that when you load your master branch - you 
still need to pull changes from the original unforked repository (into your 
local repository) and then push them back up to your fork, AND then branch to 
make a change. For ages I was was getting unrelated diff changes even though I 
thought I had started on “master”.

I’m hoping there will be a talk about all of this at Pharo Days. When you get 
it right its awesome - but when you take a mis-step its quite confusing until 
you realise what the pieces mean. (And I’m sure I still have the model wrong, 
but its fun learning more each day)

Tim

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Sean P. DeNigris]

Tim Mackinnon wrote
> how is this shared repository supposed to work?

While I initially liked the space efficiency of the shared approach, I
eventually gave up because it created too many (often obscure) problems. It
just doesn't seem to be a good match for git, although you can get away with
it in the simplest cases (read-only, no branch switching). It sounds like
you may not have the luxury of avoiding it so hopefully someone can provide
more constructive help.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Serializing classes with Fuel

[Konrad Hinsen]

Hi Mariano,

> Yes, that's the "default" behavior. To fully serialize classes you need
> FuelMetalevel packages. This brings a new visitors and mappers to allow you
> to fully serialize methods, classes, contexts, etc.

Thanks for the pointer - I will explore FuelMetalevel.

Konrad.

Re: [Pharo-users] IMAP in Pharo

[Sean P. DeNigris]

cedreek wrote
> Still havent get my head around this FORK/PR cycle but I will for sure one
> day :)

It took me quite a while to grok. Fork = 'personal remote clone' and: [ PR =
'UI support for discussing, testing, and accepting commits' ]



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Sven Van Caekenberghe]

I was just explaining how it is now, what I think the rationale is behind it.

I understand #asDictionary as working on a collection of pairs/associations 
(because it basically goes to #withAll:).

A bag is just a collection that is optimised for many duplicates, the fact that 
you have values and counts is more an implementation detail than an intrinsic 
property.

The conversion that you want, and that already exists in #valuesAndCounts is 
one interpretation of what a bag is, not the only one. A bag is foremost a 
collection of things.

I am not immediately convinced that #valuesAndCounts should be the default 
#asDictionary interpretation.

What about the inverse for example ?

  { #foo->2. #bar->3 } asDictionary asBag.

But this is certainly an interesting discussion.

> On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
> 
> As Richard said - as a bag is relationship between keys and frequencies, I 
> would expect it to be able to convert to a dictionary.
> 
> It displays in an inspector just like a Dictionary - which is why I figured I 
> could convert to pass it back to the exercise that was written with 
> Dictionaries in mind.
> 
> 
> 
> 
> The code to fix it is quite simple, but on these kinds of things - I thought 
> it worth checking before submitting a PR.
> 
> Tim
> 
> 
>> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
>> 
>> Why would that work ? What would you expect the output to be ?
>> 
>> Try:
>> 
>>  #(1 2 3) asDictionary 
>> 
>> it fails in exactly the same way. You need key/value pairs (Associations).
>> 
>> These do work
>> 
>>  Bag new add: #foo->100; asDictionary.
>> 
>>  Bag new addAll: 'ABABAB'; valuesAndCounts.
>> 
>>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
>>> 
>>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
>>> 
>>> Bag new 
>>> addAll: 'aacddd’; 
>>> asDictionary 
>>> 
>>> Gives an error - Dnu #key
>>> 
>>> 
>>> It looks to me like Bag is inheriting a bad version of #associationsDo:  
>>> and instead could simply forward it to #doWithOccurences: instead?
>>> 
>>> I know Bag is not used that much - but it comes up a lot in programming 
>>> exercises.
>>> 
>>> Tim
>> 
>> 
> 

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Tim Mackinnon]

While, I’m still interested in how share repositories works (and debunk some of 
my myths about it ) - digging into this users issue (isn’t Fuel wonderful) - it 
would seem that this image wasn’t created with share repositories on.

It looking down a very complicated stack (Metacello is very complicated) - it 
seems like a “localGopher” object has an IceMetacelloRepositoryAdaptor in it 
that has this non-existent path?

It seems like it gets this path from reading packages - but heck if I know how 
it ended up with something that wasn’t on the users file system (although they 
did have an image like that at some point previous). 

Anyway - if it jumps out at someone - I’d be interested, but otherwise will let 
it go for now.

Tim

> On 6 Mar 2019, at 09:26, Tim Mackinnon  wrote:
> 
> Hi - as many windows users have struggled with the long file path problem 
> (some of which can be caused by orphaned files not even referenced in your 
> baseline - but that were checked in) - many users have started using the 
> "share repositories between images” and point it to a nice short file path 
> (at least we have a workaround).
> 
> This got us running on Exercism - and unblocked our testers.
> 
> However - I was suprised when I asked one of our users to update his image to 
> pull in some new code that fixed an issue for him (It’s the first time I've 
> encountered a conflict and had to use onConflict - and I’m not sure why there 
> is a conflict - but thats a side point).
> 
> Metacello new 
>  baseline: 'Exercism'; 
>  repository: 'github://exercism/pharo-smalltalk:master/dev/src 
> ';
>  onConflict: [ :ex | ex allow ]; 
>  load.
> 
> 
> So doing the above on OSX loads the update into my older image, and 
> everything was fine. However on Windows - one of my testers tried the same 
> thing and got a strange error:
>  “NotFound: failed to resolve path ‘C:\pharo\images\Exercism 
> test\pharo-local….” (See photo below).
> 
> The weird bit is that we aren’t sure where the “Exercism test” bit comes from 
> because his image isn’t "Exercism test” - however I suspect that this is one 
> of the other images he created when we were testing 64 bit and he was loading 
> into that.
> 
> So my question is - how is this shared repository supposed to work? It seems 
> to me that different images are storing non-sharable information in the 
> repository such that sharing can’t possibly work? As my baseline and setup 
> are really simple - I’m suprised by this - there is literally 4 packages and 
> one external dependency on OSProcess (which is an mcz I think). So why does 
> this fail? I’ve always avoided the shared repository as when I initially 
> tried it, I recall all kinds of weird behaviour - but as the windows folks 
> can’t seem to avoid it - can someone explain what it does and what we need to 
> look out for?
> 
> Tim
> 

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Tim Mackinnon]

As Richard said - as a bag is relationship between keys and frequencies, I 
would expect it to be able to convert to a dictionary.

It displays in an inspector just like a Dictionary - which is why I figured I 
could convert to pass it back to the exercise that was written with 
Dictionaries in mind.




The code to fix it is quite simple, but on these kinds of things - I thought it 
worth checking before submitting a PR.

Tim


> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
> 
> Why would that work ? What would you expect the output to be ?
> 
> Try:
> 
>  #(1 2 3) asDictionary 
> 
> it fails in exactly the same way. You need key/value pairs (Associations).
> 
> These do work
> 
>  Bag new add: #foo->100; asDictionary.
> 
>  Bag new addAll: 'ABABAB'; valuesAndCounts.
> 
>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
>> 
>> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
>> 
>> Bag new 
>>  addAll: 'aacddd’; 
>>  asDictionary 
>> 
>> Gives an error - Dnu #key
>> 
>> 
>> It looks to me like Bag is inheriting a bad version of #associationsDo:  and 
>> instead could simply forward it to #doWithOccurences: instead?
>> 
>> I know Bag is not used that much - but it comes up a lot in programming 
>> exercises.
>> 
>> Tim
> 
> 

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Richard O'Keefe]

Doubtless the original poster expected aBag asDictionary
to answer a dictionary mapping the (distinct) elements of
the bag to their counts.  Mathematically, a bag can
usefully be seen as a partial function from a set U to
the positive integers, and a dictionary with U keys and
positive integer values is precisely that.

It's really not unreasonable to expect that,
considering that there *is* a method that does just
what the OP wanted: #valuesAndCounts.  It's rather
dangerous to expose private state like that, but it
is not a private method.  I would expect

asDictionary
  ^contents copy




On Thu, 7 Mar 2019 at 02:54, Sven Van Caekenberghe  wrote:

> Why would that work ? What would you expect the output to be ?
>
> Try:
>
>   #(1 2 3) asDictionary
>
> it fails in exactly the same way. You need key/value pairs (Associations).
>
> These do work
>
>   Bag new add: #foo->100; asDictionary.
>
>   Bag new addAll: 'ABABAB'; valuesAndCounts.
>
> > On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> >
> > I was surprised to find that a Bag can’t convert to a dictionary - e.g.
> >
> > Bag new
> >   addAll: 'aacddd’;
> >   asDictionary
> >
> > Gives an error - Dnu #key
> >
> >
> > It looks to me like Bag is inheriting a bad version of #associationsDo:
> and instead could simply forward it to #doWithOccurences: instead?
> >
> > I know Bag is not used that much - but it comes up a lot in programming
> exercises.
> >
> > Tim
>
>
>

Re: [Pharo-users] Noob Question - slicing

[K K Subbu]

On Wed, 6 Mar 2019 at 12:00, Craig Johnson > wrote:



What is the simplest way to copy characters between positions 4 and
8 from a string in Pharo?


'1234567890' copyFrom: 5 to: 8 "5678"

Page 207 in Updated Pharo by Example book explains more on substrings.

HTH .. Subbu

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

[Sven Van Caekenberghe]

> On 6 Mar 2019, at 15:15, Richard O'Keefe  wrote:
> 
> Surely a Symbol should never be #= to anything that is not
> a Symbol?  At least in VW, GST, Dolphin, and VAST,
> #a = 'a'
> 'a' = #a
> both answer false, and I'd be rather upset if a symbol
> ever compared equal to a string.  The ANSI Smalltalk standard
> says in several places that "Symbol objects are identity
> objects", which is defined as "An object defined such that
> a=b implies a==b".
> 
> So the definition I am expecting to see is
> 
> Symbol>>
> = other
>   ^self == other
> 
> Anything else is inconsistent with the standard and common
> practice.  Symbol hash and = are supposed to be fast all the
> or what's the point?

Because it is very convenient. It has also been like this in Pharo (and Squeak) 
for a long time. With the correct implementation, #= and #~= are just as fast 
when both arguments are Symbols. (We need a little fix there, as recently 
uncovered).

We do not feel bound to the ANSI standard (we won't break it just for fun, it 
is a guide, but it can't stop us evolving).

There are many points of view in the world, yours might be different than mine.

> On Sat, 2 Mar 2019 at 09:02, Sven Van Caekenberghe  wrote:
> Ah, it is an optimisation: if the first #== fails, but the argument is also a 
> Symbol, then that means the are different for sure, so false is returned 
> early, instead of failing in super's #= after that.
> 
> And with ByteSymbol and WideSymbol, although they are exclusive (can never be 
> equal), they can be different and if they are both Symbols, then you can 
> return early (not just when their classes differ).
> 
> > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe  wrote:
> > 
> > Why ? Please explain ...
> > 
> >> On 1 Mar 2019, at 18:02, David T. Lewis  wrote:
> >> 
> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote:
> >>> 
> >>> 
>  On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users 
>   wrote:
>  
>  
>  From: Petr Fischer 
>  Subject: Symbol equality method #= - weird condition in the Pharo 
>  sourcecode
>  Date: 1 March 2019 at 17:08:03 GMT+1
>  To: pharo-users@lists.pharo.org
>  
>  
>  Hello, this is Symbol equality method in Pharo:
>  
>  1: = aSymbol
>  2: "Compare the receiver and aSymbol." 
>  3: self == aSymbol ifTrue: [^ true].
>  4: self class == aSymbol class ifTrue: [^ false].
>  5: "Use String comparison otherwise"
>  6: ^ super = aSymbol
>  
>  Look at line 4 - what does it mean? That's wrong, isn't it?
>  
>  Typically, every symbol comparisons end up in line 3, but if you do some 
>  work with forward proxies for example, condition on line 3 is "false" 
>  and then weird things on line 4 happens.
>  
>  If line 4 and further are correct, can someone explain a little?
>  
>  Thanks! pf
> >>> 
> >>> Yes, that looks weird. Line 4 should probably be removed, unless I am 
> >>> missing something.
> >> 
> >> It is wrong in a Spur image, because we now have subclasses of Symbol.
> >> But removing line 4 is not the right solution. See Nicolas' implementation
> >> in Squeak:
> >> 
> >> Symbol>>= aSymbol
> >>  "Compare the receiver and aSymbol." 
> >>  self == aSymbol ifTrue: [^ true].
> >>  aSymbol isSymbol ifTrue: [^ false].
> >>  "Use String comparison otherwise"
> >>  ^ super = aSymbol
> >> 
> >> Dave
> >> 
> >>> 
> >>> Symbols are by definition always #== so in that sense, #= should not even 
> >>> be implemented (as #= on Object is defined as #==), but since its direct 
> >>> super class String already overwrote #=, it has to follow.
> >>> 
> >>> The super call in line 6 is what allows Symbols and String to be compared.
> >>> 
> >>> I would say line 4 is a kind of sanity check, but probably not needed.
> > 
> 
> 

Re: [Pharo-users] offers (deb and rpm packages included)

[Michael Zeder]

cool
@Offray, I added pacman format now, but I have no means to verify, if 
it installs correctly on Arch/Manjaro/other distros which use the 
pacman package management. If somebody can verify..?
And, I yet have to come up with a way to ensure, that package updates 
dont break compatibility (vm is in /usr/share, while every user has her 
own image in home folder).


Does by chance anybody here has contact to a linux distro maintainer?
With Stef's okay, I will write to all major linux distro teams, if they 
like to include PharoLauncher into their repos (if they can't include 
it in the main repo, I will try to get it into Linux "App Stores" via 
flatpak/snap/etc, though the "real" distro repos would be better).


Michael


Am Mi, 6. Mär, 2019 um 10:02 VORMITTAGS schrieb Esteban Lorenzano 
:

Nice, thank you!
(We are working on some packaging for linux, but somehow we are not 
yet there :( )


Esteban

On 3 Mar 2019, at 17:52, Michael Zeder  
wrote:


Hi!
I would like to make two offers:
First, I know, deciding to be provocative can hurt. I did it int the 
hope that the released energy will be transformed in something good 
by the community, so apology for having been loud and insistent.


Second, I felt oblidged to give at least a little thing back (since 
I use Pharo mostly in spare time). So, hey Linuxers! Whenever I set 
up a new system, I integrate Pharo Launcher into the desktop 
environment. I thought, I just built Debian .deb and RPM packages, 
for convient installation, on multiuser desktops.

https://gitlab.com/mjz/pharo-linux-packages
Maybe you like it. What does it do? installs shell shortcut ( $ 
pharo ) and application menu item (Gnome, KDE etc), which when 
called, copy Launcher image and resources into hidden user dir ( 
/home/USER/.pharolauncher ), if needed, and start Pharo Launcher. 
Packaged as DEB and RPM for i386 and x86_64. Please always verify 
binary integrity.


M

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

[Richard O'Keefe]

Surely a Symbol should never be #= to anything that is not
a Symbol?  At least in VW, GST, Dolphin, and VAST,
#a = 'a'
'a' = #a
both answer false, and I'd be rather upset if a symbol
ever compared equal to a string.  The ANSI Smalltalk standard
says in several places that "Symbol objects are identity
objects", which is defined as "An object defined such that
a=b implies a==b".

So the definition I am expecting to see is

Symbol>>
= other
  ^self == other

Anything else is inconsistent with the standard and common
practice.  Symbol hash and = are supposed to be fast all the
or what's the point?

On Sat, 2 Mar 2019 at 09:02, Sven Van Caekenberghe  wrote:

> Ah, it is an optimisation: if the first #== fails, but the argument is
> also a Symbol, then that means the are different for sure, so false is
> returned early, instead of failing in super's #= after that.
>
> And with ByteSymbol and WideSymbol, although they are exclusive (can never
> be equal), they can be different and if they are both Symbols, then you can
> return early (not just when their classes differ).
>
> > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe  wrote:
> >
> > Why ? Please explain ...
> >
> >> On 1 Mar 2019, at 18:02, David T. Lewis  wrote:
> >>
> >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote:
> >>>
> >>>
>  On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
> 
> 
>  From: Petr Fischer 
>  Subject: Symbol equality method #= - weird condition in the Pharo
> sourcecode
>  Date: 1 March 2019 at 17:08:03 GMT+1
>  To: pharo-users@lists.pharo.org
> 
> 
>  Hello, this is Symbol equality method in Pharo:
> 
>  1: = aSymbol
>  2: "Compare the receiver and aSymbol."
>  3: self == aSymbol ifTrue: [^ true].
>  4: self class == aSymbol class ifTrue: [^ false].
>  5: "Use String comparison otherwise"
>  6: ^ super = aSymbol
> 
>  Look at line 4 - what does it mean? That's wrong, isn't it?
> 
>  Typically, every symbol comparisons end up in line 3, but if you do
> some work with forward proxies for example, condition on line 3 is "false"
> and then weird things on line 4 happens.
> 
>  If line 4 and further are correct, can someone explain a little?
> 
>  Thanks! pf
> >>>
> >>> Yes, that looks weird. Line 4 should probably be removed, unless I am
> missing something.
> >>
> >> It is wrong in a Spur image, because we now have subclasses of Symbol.
> >> But removing line 4 is not the right solution. See Nicolas'
> implementation
> >> in Squeak:
> >>
> >> Symbol>>= aSymbol
> >>  "Compare the receiver and aSymbol."
> >>  self == aSymbol ifTrue: [^ true].
> >>  aSymbol isSymbol ifTrue: [^ false].
> >>  "Use String comparison otherwise"
> >>  ^ super = aSymbol
> >>
> >> Dave
> >>
> >>>
> >>> Symbols are by definition always #== so in that sense, #= should not
> even be implemented (as #= on Object is defined as #==), but since its
> direct super class String already overwrote #=, it has to follow.
> >>>
> >>> The super call in line 6 is what allows Symbols and String to be
> compared.
> >>>
> >>> I would say line 4 is a kind of sanity check, but probably not needed.
> >
>
>
>

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Sven Van Caekenberghe]

Why would that work ? What would you expect the output to be ?

Try:

  #(1 2 3) asDictionary 

it fails in exactly the same way. You need key/value pairs (Associations).

These do work

  Bag new add: #foo->100; asDictionary.

  Bag new addAll: 'ABABAB'; valuesAndCounts.

> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
> 
> I was surprised to find that a Bag can’t convert to a dictionary - e.g.
> 
> Bag new 
>   addAll: 'aacddd’; 
>   asDictionary 
> 
> Gives an error - Dnu #key
> 
> 
> It looks to me like Bag is inheriting a bad version of #associationsDo:  and 
> instead could simply forward it to #doWithOccurences: instead?
> 
> I know Bag is not used that much - but it comes up a lot in programming 
> exercises.
> 
> Tim

Re: [Pharo-users] Noob Question - slicing

[Sven Van Caekenberghe]

In Calypso, select the checkbox next to the virtual category 'instance side', 
which will show all inherited methods (below Object) in the same browser, 
scroll to copy.

#drop:take: sounds totally obscure to me, way worse than #copyFrom:to: first: 
or last:

And what is your point with the Unicode rant ?

What you are pointing at is called Normalization. It is not part of the 
standard image because the necessary databases and fonts are big. But is can be 
done in Pharo just fine.

https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43

What is it with people complaining that they did not find something where they 
expected it ? Every language/environment/library/framework has a learning curve.

The current class/method categorisations are what they are (historically and by 
design), there is more to life than string processing, many operations do make 
sense in other contexts too, that is a powerful thing.

> On 6 Mar 2019, at 13:48, Richard O'Keefe  wrote:
> 
> As someone else already pointed out, the standard way to copy
> part of any array-like sequence is
>aSequence copyFrom: firstIncludedIndex to: lastIncludedIndex
> 
> How could you have found this by yourself?
> 
> From the background, either
>   Click-select Tools-select Playground
> or hold Ctrl down while typing OW (for Open Workspace).
> In the new Playground/workspace, type
>   String
> then Ctrl-B.  You now have a five-pane browser open on
> String.
> 
> About half way down the third panel on the top you will see
>   converting
>   copying
>   displaying
> Click on copying.
> 
> Guess what?  You WON'T see anything that looks relevant!
> Maybe it's in an ancestral class.  So look at the buttons
> under the top row of panes:
>  All packages  Scoped view | Flat Hier | Inst side Class side | ...
> Hier looks promising.  Click it.
> 
> Now in the second pane you will see
> ProtoObject
>   Object
> Collection
>   SequenceableCollection
> ArrayedCollection
>   String
> ...
> Select the parent class, ArrayedCollection.
> Nope, nothing promising there either!
> Select the grandparent class, SequenceableCollection.
> And now the 'copying' method category has quite a few
> potentially interesting methods, including #copyFrom:to:.
> 
> There are four other related methods that I would argue
> are in the wrong category:
>   allButFirst
>   allButFirst: count
>   allButLast
>   allButLast: count
> are in the 'accessing' category.
> 
> If you want something a bit more flexible,
> you could add
> drop: d take: t
>   "Discard the first |d| elements of the receiver if d >= 0.
>Discard the last  |d| elements of the receiver if d <= 0.
>Return  the first |t| elements of the result   if t >= 0.
>Return  the last  |t| elements of the result   if t <= 0.
>The result is the same kind of collection as the receiver."
>   |lb ub n|
>   n := self size.
>   d abs >= n ifTrue: [^self copyEmpty].
>   d < 0
> ifTrue:  [lb := 1.   ub := n + d]
> ifFalse: [lb := d+1. ub := n].
>   ub - lb + 1 <= t abs ifFalse: [
> t < 0
>   ifTrue:  [lb := ub + t + 1]
>   ifFalse: [ub := lb + t - 1]].
>   ^self copyFrom: lb to: ub
> 
> Now I would like to suggest that you not use anything like this
> *directly*.  Go back to the Playground, and evaluate
> 
>   String with: (Character codePoint: 256) 
> 
> The answer is 'Ā'. Pharo supports Unicode.  Now try
> 
>   String with: $A with: (Character codePoint: 16r0304)
> 
> In Pharo, the result looks like A followed by a separate
> macron, but when it's pasted into HTML it displays
> correctly as 'Ā'.  Pharo doesn't *quite* support Unicode.
> If it did, the two strings with different lengths and no
> codepoint in common would display exactly the same.
> 
> The Unicode standard finds it necessary to distinguish
> between characters, glyphs, graphemes, grapheme clusters,
> codepoints, and a couple of other things.  A Smalltalk
> String is a sequence of *codepoints*, not a sequence of
> "characters".  There is no upper bound on the number of
> codepoints that may be needed to encode one "character"
> as the end user sees it, and from there on it gets
> *complicated*.
> 
> For over 20 years, it hasn't really made sense to think
> of a string as a simply indexed sequence of characters.
> Integer indices are a useful implementation-level detail
> for remembering bounds from some "higher level" matching
> technique, but are much less useful than you might expect.
> 
> 
> 
> 
> 
> 
> 
> On Wed, 6 Mar 2019 at 12:00, Craig Johnson  wrote:
> Hi All,
> 
>  
> 
> I was trying to figure an elegant way to slice strings (Python style), and 
> came up empty.
> 
>  
> 
> What is the simplest way to copy characters between positions 4 and 8 from a 
> string in Pharo?
> 
>  
> 
> Craig
> 

Re: [Pharo-users] Noob Question - slicing

[Tim Mackinnon]

Nice reply Richard - do you ever post any of these in a blog - the one below 
would be a great one to point to from Exercism...

> On 6 Mar 2019, at 12:48, Richard O'Keefe  wrote:
> 
> As someone else already pointed out, the standard way to copy
> part of any array-like sequence is
>aSequence copyFrom: firstIncludedIndex to: lastIncludedIndex
> 
> How could you have found this by yourself?
> 
> From the background, either
>   Click-select Tools-select Playground
> or hold Ctrl down while typing OW (for Open Workspace).
> In the new Playground/workspace, type
>   String
> then Ctrl-B.  You now have a five-pane browser open on
> String.
> 
> About half way down the third panel on the top you will see
>   converting
>   copying
>   displaying
> Click on copying.
> 
> Guess what?  You WON'T see anything that looks relevant!
> Maybe it's in an ancestral class.  So look at the buttons
> under the top row of panes:
>  All packages  Scoped view | Flat Hier | Inst side Class side | ...
> Hier looks promising.  Click it.
> 
> Now in the second pane you will see
> ProtoObject
>   Object
> Collection
>   SequenceableCollection
> ArrayedCollection
>   String
> ...
> Select the parent class, ArrayedCollection.
> Nope, nothing promising there either!
> Select the grandparent class, SequenceableCollection.
> And now the 'copying' method category has quite a few
> potentially interesting methods, including #copyFrom:to:.
> 
> There are four other related methods that I would argue
> are in the wrong category:
>   allButFirst
>   allButFirst: count
>   allButLast
>   allButLast: count
> are in the 'accessing' category.
> 
> If you want something a bit more flexible,
> you could add
> drop: d take: t
>   "Discard the first |d| elements of the receiver if d >= 0.
>Discard the last  |d| elements of the receiver if d <= 0.
>Return  the first |t| elements of the result   if t >= 0.
>Return  the last  |t| elements of the result   if t <= 0.
>The result is the same kind of collection as the receiver."
>   |lb ub n|
>   n := self size.
>   d abs >= n ifTrue: [^self copyEmpty].
>   d < 0
> ifTrue:  [lb := 1.   ub := n + d]
> ifFalse: [lb := d+1. ub := n].
>   ub - lb + 1 <= t abs ifFalse: [
> t < 0
>   ifTrue:  [lb := ub + t + 1]
>   ifFalse: [ub := lb + t - 1]].
>   ^self copyFrom: lb to: ub
> 
> Now I would like to suggest that you not use anything like this
> *directly*.  Go back to the Playground, and evaluate
> 
>   String with: (Character codePoint: 256) 
> 
> The answer is 'Ā'. Pharo supports Unicode.  Now try
> 
>   String with: $A with: (Character codePoint: 16r0304)
> 
> In Pharo, the result looks like A followed by a separate
> macron, but when it's pasted into HTML it displays
> correctly as 'Ā'.  Pharo doesn't *quite* support Unicode.
> If it did, the two strings with different lengths and no
> codepoint in common would display exactly the same.
> 
> The Unicode standard finds it necessary to distinguish
> between characters, glyphs, graphemes, grapheme clusters,
> codepoints, and a couple of other things.  A Smalltalk
> String is a sequence of *codepoints*, not a sequence of
> "characters".  There is no upper bound on the number of
> codepoints that may be needed to encode one "character"
> as the end user sees it, and from there on it gets
> *complicated*.
> 
> For over 20 years, it hasn't really made sense to think
> of a string as a simply indexed sequence of characters.
> Integer indices are a useful implementation-level detail
> for remembering bounds from some "higher level" matching
> technique, but are much less useful than you might expect.
> 
> 
> 
> 
> 
> 
> 
> On Wed, 6 Mar 2019 at 12:00, Craig Johnson  > wrote:
> Hi All,
> 
>  
> 
> I was trying to figure an elegant way to slice strings (Python style), and 
> came up empty.
> 
>  
> 
> What is the simplest way to copy characters between positions 4 and 8 from a 
> string in Pharo?
> 
>  
> 
> Craig
> 

[Pharo-users] Why can't a Bag answer as a dictionary?

[Tim Mackinnon]

I was surprised to find that a Bag can’t convert to a dictionary - e.g.

Bag new 
addAll: 'aacddd’; 
asDictionary 

Gives an error - Dnu #key


It looks to me like Bag is inheriting a bad version of #associationsDo:  and 
instead could simply forward it to #doWithOccurences: instead?

I know Bag is not used that much - but it comes up a lot in programming 
exercises.

Tim

Re: [Pharo-users] A "with" construct like Pascal - easy to do, but is it terrible?

[Richard O'Keefe]

The Pascal 'with' statement is among the most hated features of
Pascal and was not copied in successor languages like Ada or Modula-2.
It was typically replaced by record constructors, such as
  Book1 := Book[title   : 'C Programming';
author  : 'Nuha Ali ';
subject : 'C Programming Tutorial';
book_id : 6495407];
which happens to be Pascal (ISO10206).

In
  self classes do: [:class |
| metaclass |
metaclass := class metaclass.
metaclass .
mataclass .
  ]
"metaclass" is a a block temporary, not an instance variable,
and
   self classes do: [:each | (each metaclass) ; ].
suffices.

We observe that
  [:x1 ... :xn | ...] value: e1 ... value: en
is nothing other than a LET expression wearing a funny hat
and should be inlined by a compiler -- mine does -- and that
  e1 in: [:x1 | ...]
is just a "flipped" version of [:x1 | ...] value: e1, so
there's no reason why a compiler shouldn't inline that.
We also observe that
  e0 m1; ... ; mn
can -- at least in my experience -- be most simply implemented
as [:t | t m1. ... t mn] value: e0
followed by the usual inlining of that.
So we might expect that some day
  self classes do: [:each | each metaclass in: [:t | t . t ]]
would generate the *same* code as the cascaded version.

Right now, do whichever is clearer.

On Tue, 5 Mar 2019 at 02:07, Tim Mackinnon  wrote:

> I’ve noticed that as we’ve progressed there has been a move to more
> concise and fluid code - e.g. I quite like the new String streaming stuff
>
> e.g.
>
> ^ String
> streamContents: [ :stream |
> stream nextPut: …. ]
>
>
> So I was wondering why we don’t have a construct like Pascals with  to
> avoid Book1.title, Book1.author etc.
>
> (* book 1 specification *)With Book1 dobegin
>title  := 'C Programming';
>author := 'Nuha Ali ';
>subject := 'C Programming Tutorial';
>book_id := 6495407;end;
>
>
> I often find it a bit tedious with code like the following which then
> needs an instvar...
>
> self classes do: [ :class |
> | metaclass |
> metaclass := class metaclass.
> metaclass .
> mataclass .
> ]
>
>
> I’m wondering why we don’t have #with:do:
>
> class with: class metaclass do: [:metaclass |
> metaclass xxx.
> ]
>
>
> But when such things aren’t there - there is usually a good reason and I’m
> curious … this said, there are all kinds of other such tricks (which I
> rarely use that I keep coming across).
>
> Tim
>
>

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.2 released!

[Norbert Hartl]

yeah, bright future we come!

Norbert

> Am 06.03.2019 um 13:01 schrieb Esteban Lorenzano :
> 
> 
> 
>> On 6 Mar 2019, at 12:38, Norbert Hartl > > wrote:
>> 
>> How wonderful is that? How much effort it was compared to the old process?
> 
> zero.
> Bah, I needed to restart the CI because of the freetype random welcome 
> problem.
> 
> Esteban
> 
>> 
>> Norbert
>> 
>> 
>>> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano >> >:
>>> 
>>> Hi, 
>>> 
>>> I just made a bugfix release of Pharo: 
>>> 
>>> v7.0.2 
>>> <513630.jpeg>  estebanlm 
>>>  released this 22 hours ago
>>> 
>>> Bugfix release
>>> 
>>> #2303  Deprecation 
>>> fixes in TEasilyThemed
>>> #2120  Object-centric 
>>> MetaLink integration
>>> #2376  Ensure subMenu is 
>>> opened (backport)
>>> #2428  Add 
>>> scrollSelectionIntoView
>>> #2700  Tonel test is 
>>> failing (backport)
>>> 
>>> Enjoy :)
>>> 
>>> Esteban
>> 
> 

Re: [Pharo-users] Noob Question - slicing

[Richard O'Keefe]

As someone else already pointed out, the standard way to copy
part of any array-like sequence is
   aSequence copyFrom: firstIncludedIndex to: lastIncludedIndex

How could you have found this by yourself?

>From the background, either
  Click-select Tools-select Playground
or hold Ctrl down while typing OW (for Open Workspace).
In the new Playground/workspace, type
  String
then Ctrl-B.  You now have a five-pane browser open on
String.

About half way down the third panel on the top you will see
  converting
  copying
  displaying
Click on copying.

Guess what?  You WON'T see anything that looks relevant!
Maybe it's in an ancestral class.  So look at the buttons
under the top row of panes:
 All packages  Scoped view | Flat Hier | Inst side Class side | ...
Hier looks promising.  Click it.

Now in the second pane you will see
ProtoObject
  Object
Collection
  SequenceableCollection
ArrayedCollection
  String
...
Select the parent class, ArrayedCollection.
Nope, nothing promising there either!
Select the grandparent class, SequenceableCollection.
And now the 'copying' method category has quite a few
potentially interesting methods, including #copyFrom:to:.

There are four other related methods that I would argue
are in the wrong category:
  allButFirst
  allButFirst: count
  allButLast
  allButLast: count
are in the 'accessing' category.

If you want something a bit more flexible,
you could add
drop: d take: t
  "Discard the first |d| elements of the receiver if d >= 0.
   Discard the last  |d| elements of the receiver if d <= 0.
   Return  the first |t| elements of the result   if t >= 0.
   Return  the last  |t| elements of the result   if t <= 0.
   The result is the same kind of collection as the receiver."
  |lb ub n|
  n := self size.
  d abs >= n ifTrue: [^self copyEmpty].
  d < 0
ifTrue:  [lb := 1.   ub := n + d]
ifFalse: [lb := d+1. ub := n].
  ub - lb + 1 <= t abs ifFalse: [
t < 0
  ifTrue:  [lb := ub + t + 1]
  ifFalse: [ub := lb + t - 1]].
  ^self copyFrom: lb to: ub

Now I would like to suggest that you not use anything like this
*directly*.  Go back to the Playground, and evaluate

  String with: (Character codePoint: 256) 

The answer is 'Ā'. Pharo supports Unicode.  Now try

  String with: $A with: (Character codePoint: 16r0304)

In Pharo, the result looks like A followed by a separate
macron, but when it's pasted into HTML it displays
correctly as 'Ā'.  Pharo doesn't *quite* support Unicode.
If it did, the two strings with different lengths and no
codepoint in common would display exactly the same.

The Unicode standard finds it necessary to distinguish
between characters, glyphs, graphemes, grapheme clusters,
codepoints, and a couple of other things.  A Smalltalk
String is a sequence of *codepoints*, not a sequence of
"characters".  There is no upper bound on the number of
codepoints that may be needed to encode one "character"
as the end user sees it, and from there on it gets
*complicated*.

For over 20 years, it hasn't really made sense to think
of a string as a simply indexed sequence of characters.
Integer indices are a useful implementation-level detail
for remembering bounds from some "higher level" matching
technique, but are much less useful than you might expect.







On Wed, 6 Mar 2019 at 12:00, Craig Johnson  wrote:

> Hi All,
>
>
>
> I was trying to figure an elegant way to slice strings (Python style), and
> came up empty.
>
>
>
> What is the simplest way to copy characters between positions 4 and 8 from
> a string in Pharo?
>
>
>
> Craig
>

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.2 released!

[Esteban Lorenzano]

> On 6 Mar 2019, at 12:38, Norbert Hartl  wrote:
> 
> How wonderful is that? How much effort it was compared to the old process?

zero.
Bah, I needed to restart the CI because of the freetype random welcome problem.

Esteban

> 
> Norbert
> 
> 
>> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano > >:
>> 
>> Hi, 
>> 
>> I just made a bugfix release of Pharo: 
>> 
>> v7.0.2 
>> <513630.jpeg>  estebanlm 
>>  released this 22 hours ago
>> 
>> Bugfix release
>> 
>> #2303  Deprecation fixes 
>> in TEasilyThemed
>> #2120  Object-centric 
>> MetaLink integration
>> #2376  Ensure subMenu is 
>> opened (backport)
>> #2428  Add 
>> scrollSelectionIntoView
>> #2700  Tonel test is 
>> failing (backport)
>> 
>> Enjoy :)
>> 
>> Esteban
> 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.2 released!

[Norbert Hartl]

How wonderful is that? How much effort it was compared to the old process?

Norbert


> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano :
> 
> Hi, 
> 
> I just made a bugfix release of Pharo: 
> 
> v7.0.2 
> <513630.jpeg>  estebanlm 
>  released this 22 hours ago
> 
> Bugfix release
> 
> #2303  Deprecation fixes 
> in TEasilyThemed
> #2120  Object-centric 
> MetaLink integration
> #2376  Ensure subMenu is 
> opened (backport)
> #2428  Add 
> scrollSelectionIntoView
> #2700  Tonel test is 
> failing (backport)
> 
> Enjoy :)
> 
> Esteban

[Pharo-users] [ANN] Pharo 7.0.2 released!

[Esteban Lorenzano]

Hi, 

I just made a bugfix release of Pharo: 

v7.0.2 
  estebanlm  
released this 22 hours ago

Bugfix release

#2303  Deprecation fixes in 
TEasilyThemed
#2120  Object-centric 
MetaLink integration
#2376  Ensure subMenu is 
opened (backport)
#2428  Add 
scrollSelectionIntoView
#2700  Tonel test is failing 
(backport)

Enjoy :)

Esteban

Re: [Pharo-users] IMAP in Pharo

[Cédrick Béler]

Hi Veincent ;-),



> Le 6 mars 2019 à 10:44,  
>  a écrit :
> 
> Hi Cedrik,
>  
> I started something to deal with this as side project: 
> https://github.com/VincentBlondeau/IMAPClient 
> 
> It is at a very early development state. I took a SS3 project 
> (http://smalltalkhub.com/#!/~Gotchas/IMAP-Client 
> ) andbegan to improve it.


Nice, I will try.

>  
> Don’t hesitate to fork and add some PRs

Still havent get my head around this FORK/PR cycle but I will for sure one day 
:)

I’ll try it for sure btw.

Thx,

Cédrick




>  
> Cheers,
> Vincent
>  
> From: Pharo-users  > On Behalf Of Cédrick Béler
> Sent: Wednesday, 6 March 2019 10:37
> To: Any question about pharo is welcome  >
> Subject: [Pharo-users] IMAP in Pharo
>  
> Hi all, 
>  
> Do you know if IMAP is possible in Pharo ? I havent found any implementation 
> (quick search).
> I’d like to have it to interact/filter my email. POP3 is not really possible.
>  
> I think it would be a nice addition and maybe a good GSOC project ?
>  
>  
> Cheers,
>  
> Cédrick
>  
> http://forum.world.st/Zodiac-and-IMAP-td4741328.html 
>  
>  
> It exists in GNU-Smalltalk but don’t look at ti, its GPL :-)
> https://github.com/gnu-smalltalk/smalltalk/blob/master/packages/net/IMAP.st 
> 

Re: [Pharo-users] IMAP in Pharo

[vincent.blondeau]

Hi Cedrik,

 

I started something to deal with this as side project: 
https://github.com/VincentBlondeau/IMAPClient

It is at a very early development state. I took a SS3 project 
(http://smalltalkhub.com/#!/~Gotchas/IMAP-Client) andbegan to improve it.

 

Don’t hesitate to fork and add some PRs

 

Cheers,

Vincent

 

From: Pharo-users  On Behalf Of Cédrick 
Béler
Sent: Wednesday, 6 March 2019 10:37
To: Any question about pharo is welcome 
Subject: [Pharo-users] IMAP in Pharo

 

Hi all, 

 

Do you know if IMAP is possible in Pharo ? I havent found any implementation 
(quick search).

I’d like to have it to interact/filter my email. POP3 is not really possible.

 

I think it would be a nice addition and maybe a good GSOC project ?

 

 

Cheers,

 

Cédrick

 

http://forum.world.st/Zodiac-and-IMAP-td4741328.html 

 

It exists in GNU-Smalltalk but don’t look at ti, its GPL :-)

https://github.com/gnu-smalltalk/smalltalk/blob/master/packages/net/IMAP.st 

[Pharo-users] IMAP in Pharo

[Cédrick Béler]

Hi all, 

Do you know if IMAP is possible in Pharo ? I havent found any implementation 
(quick search).
I’d like to have it to interact/filter my email. POP3 is not really possible.

I think it would be a nice addition and maybe a good GSOC project ?


Cheers,

Cédrick

http://forum.world.st/Zodiac-and-IMAP-td4741328.html 
 

It exists in GNU-Smalltalk but don’t look at ti, its GPL :-)
https://github.com/gnu-smalltalk/smalltalk/blob/master/packages/net/IMAP.st 
 

[Pharo-users] Smalltalk CI - anyone have any luck excluding tests?

[Tim Mackinnon]

As part of Exercism we have to show our language track can build and run tests 
- and they use Travis - so, pretty awesome we have that tooling.

So it was pretty straightforward t hook in - and there are enough examples 
around to support the docs for the .yml and .ston file - however I hit an issue 
with the inclusion and exclusion of test files. I put an issue on SmalltalkCI - 
but its sat there for 8days (https://github.com/hpi-swa/smalltalkCI/issues/417) 
so I’m wondering if anyone has experience with this?

Essentially if I include my other packages ‘ExercismDev’ and ‘ExercismTools’  
(see sample below - I’ve removed them from the include list) then some of my 
tests run twice (I believe because the exclude of #AllExercismTests doesn’t 
work). I also have some environmental tests that need improving to run more 
generically (Submit/Download) and again those don’t seem to be excluded.

It’s like “exclude" simply doesn’t work - but I would think this would be 
reported more widely if this was the case. So maybe I don’t understand the 
overlap of include/exclude etc. Anyone have any thoughts?

Tim
SmalltalkCISpec {
  #loading : [
SCIMetacelloLoadSpec {
  #baseline : 'Exercism',
  #directory : 'dev/src',
  #load : [ 'dev' ],

  #platforms : [ #pharo ]
}
  ],

  #testing : {
#include : {
  #packages : [ 'Exercism' ]
},
#exclude : {
  #classes : [ #AllExercismTests, #ExercismTest, #ExercismSubmitTest, 
#ExercismDownloadTest ],
  #packages : [ 'ExercismWIP']
}
  }
}

Re: [Pharo-users] offers (deb and rpm packages included)

[Esteban Lorenzano]

Nice, thank you!
(We are working on some packaging for linux, but somehow we are not yet there 
:( )

Esteban 

> On 3 Mar 2019, at 17:52, Michael Zeder  wrote:
> 
> Hi!
> I would like to make two offers:
> First, I know, deciding to be provocative can hurt. I did it int the hope 
> that the released energy will be transformed in something good by the 
> community, so apology for having been loud and insistent.
> 
> Second, I felt oblidged to give at least a little thing back (since I use 
> Pharo mostly in spare time). So, hey Linuxers! Whenever I set up a new 
> system, I integrate Pharo Launcher into the desktop environment. I thought, I 
> just built Debian .deb and RPM packages, for convient installation, on 
> multiuser desktops.
> https://gitlab.com/mjz/pharo-linux-packages 
> 
> Maybe you like it. What does it do? installs shell shortcut ( $ pharo ) and 
> application menu item (Gnome, KDE etc), which when called, copy Launcher 
> image and resources into hidden user dir ( /home/USER/.pharolauncher ), if 
> needed, and start Pharo Launcher. Packaged as DEB and RPM for i386 and 
> x86_64. Please always verify binary integrity.
> 
> M
> 

[Pharo-users] [ANN] Pharo Consortium New Academic Member: CIRAD

[Marcus Denker]

The Pharo Consortium is very happy to announce that CIRAD has joined the 
Consortium as an Academic Member.

About
- CIRAD, the French Agricultural Research Centre for International Development: 
https://www.cirad.fr/en/home-page
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to 
support the ongoing development and future of Pharo.

Individuals can support Pharo via the Pharo Association:

- http://association.pharo.org