Stream >> <<

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
109 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Stream >> <<

Herby Vojčík
Hello!

In Pharo 7.0.4,

   Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]

   >>> #($1 $0 $1 $0 10 '10')

Bug or feature?

Herby

Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Noury Bouraqadi-2
Herby,

It's a feature. ;-)

<< sends putOn: message to the non-collection args.
Integer>>#putOn: aStream
        aStream isBinary
                ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ]
                ifFalse: [ self asString putOn: aStream ]

String>>#putOn: aStream
        aStream nextPutAll: self

> On 10 Sep 2019, at 11:27, Herby Vojčík <[hidden email]> wrote:
>
> Hello!
>
> In Pharo 7.0.4,
>
>  Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
>
>  >>> #($1 $0 $1 $0 10 '10')
>
> Bug or feature?
>
> Herby
>


Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Richard O'Keefe
In reply to this post by Herby Vojčík
I think it's fair to say that #<< *is* a bug.
There does not seem to be any coherent description of what it means.
It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
something else, in some confusing ways.
CommandLineHandler           #nextPutAll: (sent somewhere else)
Integer                      left shift (someone has been smoking too much C++)
NonInteractiveTranscript     #show: = locked #print:
SocketStream                 #putOn: (which may itself act like
                             #nextPut:, #nextPutAll:, #print,
                             put elements sans separators, or
                             something else)
Stream                       #putOn: (see above)
WriteStream                  either #nextPutAll: or #putOn:
Transcript                   #show: = locked #print:
ThreadSafeTranscript         #show: = locked #print:
VTermOutputDriver            #putOn:
VTermOutputDriver2           #asString then #nextPutAll:
ZnEncodedWriteStream         #nextPutAll:
ZnHtmlOutputStream           #asString then #nextPutAll:
SequenceableCollection class #streamContents:

As was once said about PL/I, #<< fills a much-needed gap.
When I see #print:, or #nextPut:, or #nextPutAll:, I know
what to expect.  When I see #putOn:, I have in general no
idea what will happen.  And when I see << it is worse.

One point of << is to imitate C++'s composition of outputs.
That might work, too, if only there were some agreement
about what #nextPutAll: returns.  There is not.  It might
return the receiver.  It might return some other stream
related to the receiver.  It might even return the collection
argument.  So when you see
 a << b << c
in general you not only do not have a clue what (a) is going
to do with (b) but you have no idea what object the message
<< c will be sent to.

Now let's see if we can puzzle out what
Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
does.
The output will be going to a WriteStream.
aWriteStream << anInteger
is not, but is like, aWriteStream print: anInteger.
So we add $1 and $0.
aWriteStream << aString
reduces to aWriteStream nextPutAll: aString.
So we add $1 and $0.
aWriteStream on anArray << anotherArray
reduces to aWriteStream nextPutAll: anotherArray.
So we add 10 and '10'.
Thus the result we get is
#($1 $0 $1 $0 10 '10').
What result we should *expect* from this muddle I cannot say.

If, on the other hand, you wrote explicitly
Array streamContents: [:stream |
  stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')]
you would have an easy time figuring out what to expect.

By the way, there is no standard definition of #show:, but in
other Smalltalk systems it's usually a variant of #nextPutAll:,
not a variant of #print:.  There's no denying that locked output
is useful to have, but #show: is not perhaps the best name for it.

Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Sven Van Caekenberghe-2
Development happens in Pharo 8 first, with possible back ports if really necessary.

The last relevant change was the following:

https://github.com/pharo-project/pharo/pull/2698

> On 10 Sep 2019, at 14:54, Richard O'Keefe <[hidden email]> wrote:
>
> I think it's fair to say that #<< *is* a bug.
> There does not seem to be any coherent description of what it means.
> It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
> something else, in some confusing ways.
> CommandLineHandler           #nextPutAll: (sent somewhere else)
> Integer                      left shift (someone has been smoking too much C++)
> NonInteractiveTranscript     #show: = locked #print:
> SocketStream                 #putOn: (which may itself act like
>                              #nextPut:, #nextPutAll:, #print,
>                              put elements sans separators, or
>                              something else)
> Stream                       #putOn: (see above)
> WriteStream                  either #nextPutAll: or #putOn:
> Transcript                   #show: = locked #print:
> ThreadSafeTranscript         #show: = locked #print:
> VTermOutputDriver            #putOn:
> VTermOutputDriver2           #asString then #nextPutAll:
> ZnEncodedWriteStream         #nextPutAll:
> ZnHtmlOutputStream           #asString then #nextPutAll:
> SequenceableCollection class #streamContents:
>
> As was once said about PL/I, #<< fills a much-needed gap.
> When I see #print:, or #nextPut:, or #nextPutAll:, I know
> what to expect.  When I see #putOn:, I have in general no
> idea what will happen.  And when I see << it is worse.
>
> One point of << is to imitate C++'s composition of outputs.
> That might work, too, if only there were some agreement
> about what #nextPutAll: returns.  There is not.  It might
> return the receiver.  It might return some other stream
> related to the receiver.  It might even return the collection
> argument.  So when you see
>  a << b << c
> in general you not only do not have a clue what (a) is going
> to do with (b) but you have no idea what object the message
> << c will be sent to.
>
> Now let's see if we can puzzle out what
> Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
> does.
> The output will be going to a WriteStream.
> aWriteStream << anInteger
> is not, but is like, aWriteStream print: anInteger.
> So we add $1 and $0.
> aWriteStream << aString
> reduces to aWriteStream nextPutAll: aString.
> So we add $1 and $0.
> aWriteStream on anArray << anotherArray
> reduces to aWriteStream nextPutAll: anotherArray.
> So we add 10 and '10'.
> Thus the result we get is
> #($1 $0 $1 $0 10 '10').
> What result we should *expect* from this muddle I cannot say.
>
> If, on the other hand, you wrote explicitly
> Array streamContents: [:stream |
>   stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')]
> you would have an easy time figuring out what to expect.
>
> By the way, there is no standard definition of #show:, but in
> other Smalltalk systems it's usually a variant of #nextPutAll:,
> not a variant of #print:.  There's no denying that locked output
> is useful to have, but #show: is not perhaps the best name for it.
>


Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Herby Vojčík
In reply to this post by Richard O'Keefe
On 10. 9. 2019 14:54, Richard O'Keefe wrote:

> I think it's fair to say that #<< *is* a bug.
> There does not seem to be any coherent description of what it means.
> It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
> something else, in some confusing ways.
> CommandLineHandler           #nextPutAll: (sent somewhere else)
> Integer                      left shift (someone has been smoking too
> much C++)
> NonInteractiveTranscript     #show: = locked #print:
> SocketStream                 #putOn: (which may itself act like
>                               #nextPut:, #nextPutAll:, #print,
>                               put elements sans separators, or
>                               something else)
> Stream                       #putOn: (see above)
> WriteStream                  either #nextPutAll: or #putOn:
> Transcript                   #show: = locked #print:
> ThreadSafeTranscript         #show: = locked #print:
> VTermOutputDriver            #putOn:
> VTermOutputDriver2           #asString then #nextPutAll:
> ZnEncodedWriteStream         #nextPutAll:
> ZnHtmlOutputStream           #asString then #nextPutAll:
> SequenceableCollection class #streamContents:
>
> As was once said about PL/I, #<< fills a much-needed gap.
> When I see #print:, or #nextPut:, or #nextPutAll:, I know
> what to expect.  When I see #putOn:, I have in general no
> idea what will happen.  And when I see << it is worse.

I don't think so. I have pretty coherent view of how << can work. In
Amber this coherent view helped to create Silk library for DOM
manipulation by treating a DOM element as a ind of a stream.

Having simple thing working (<< aCollection unpack the collection,
having putOn: to be able to customize how object are put on stream) can
help a lot; if, things are kept consistent.

> One point of << is to imitate C++'s composition of outputs.
> That might work, too, if only there were some agreement
> about what #nextPutAll: returns.  There is not.  It might
> return the receiver.  It might return some other stream
> related to the receiver.  It might even return the collection
> argument.  So when you see
>   a << b << c
> in general you not only do not have a clue what (a) is going
> to do with (b) but you have no idea what object the message
> << c will be sent to.


This is strawman. We know what str << a << b << c does if we know what
is output of #<<, it has nothing to do with #nextPutAll:. And it's
simple, STream >> << should return self, and we're done.

> Now let's see if we can puzzle out what
> Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
> does.
> The output will be going to a WriteStream.
> aWriteStream << anInteger
> is not, but is like, aWriteStream print: anInteger.
> So we add $1 and $0.
> aWriteStream << aString
> reduces to aWriteStream nextPutAll: aString.
> So we add $1 and $0.
> aWriteStream on anArray << anotherArray
> reduces to aWriteStream nextPutAll: anotherArray.
> So we add 10 and '10'.
> Thus the result we get is
> #($1 $0 $1 $0 10 '10').
> What result we should *expect* from this muddle I cannot say.

#(10 '10' 10 '10')

Of course.

After all, I put things on Array stream, which holds objects, not a
character stream.

> If, on the other hand, you wrote explicitly
> Array streamContents: [:stream |
>    stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')]
> you would have an easy time figuring out what to expect.

I see nextPut[All]: as low-level put API, and print:, write: and << as
high-level one. I would not combine them.

I actually combine print: with write: to nice effect in Amber. Lot of
code which actually export source to the disk uses combination of these
two to enhance readability (IMO). For example:

exportTraitDefinitionOf: aClass on: aStream
        "Chunk format."

        aStream
                write: 'Trait named: '; printSymbol: aClass name; lf;
                tab; write: 'package: '; print: aClass category; write: '!!'; lf.
        aClass comment ifNotEmpty: [
                aStream
                write: '!!'; print: aClass; write: ' commentStamp!!'; lf;
                write: { self chunkEscape: aClass comment. '!!' }; lf ].
        aStream lf

As write: and << are synonyms in Amber (so they probably was in some
part of Pharo history), I chose to pair print: keyword selector with
write: keyword selector from the style point of view.

Also, since write: is <<, I can write: a collection of pieces to put and
I don't need to cascade lots of write:s.

What I wanted to illustrate is, good implementation of << can be pretty
useful.

> By the way, there is no standard definition of #show:, but in
> other Smalltalk systems it's usually a variant of #nextPutAll:,
> not a variant of #print:.  There's no denying that locked output
> is useful to have, but #show: is not perhaps the best name for it.

Herby


Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Herby Vojčík
In reply to this post by Sven Van Caekenberghe-2
On 10. 9. 2019 15:20, Sven Van Caekenberghe wrote:
> Development happens in Pharo 8 first, with possible back ports if really necessary.
>
> The last relevant change was the following:
>
> https://github.com/pharo-project/pharo/pull/2698
>
That's a very nice change, indeed. Thank you.

But there's still one catch. I looked, and in Pharo 8 branch, this is
still the active implementation:

WriteStream >> << anObject [
        "Write anObject to the receiver, dispatching using #putOn:
        This is a shortcut for both nextPut: and nextPutAll: since anObject can
be both
        the element type of the receiver as well as a collection of those elements.
        No further conversions of anObject are applied.
        This is an optimisation.
        Return self to accomodate chaining."

  anObject class == collection class
                ifTrue: [ self nextPutAll: anObject ]
                ifFalse: [ anObject putOn: self ]
]

It is wrong to shortcut putOn: double dispatch based on anObject class
== collection class. I strongly believe this test should pass:

testPutDiverseNestedSequences

   | array otherSequenceable higherOrderArray higherOrderSequenceable |

   array := Array with: 1 with: 2 with: 3.
   otherSequenceable := OrderedCollection with: 1 with: 2 with: 3.
   higherOrderArray := Array with: array with: otherSequenceable.
   higherOrderSequenceable := OrderedCollection with: array with:
otherSequenceable.

   result := Array streamContents: [ :s | s
     << array << otherSequenceable
     << higherOrderArray << higherOrderSequenceable ].

   self assert: result equals: #(
     1 2 3 1 2 3
     1 2 3 1 2 3
     1 2 3 1 2 3 )

If I guess correctly, based on mere implemetation detail of which class
holds the 1 2 3, some of them are not unnested.

I understand how that optimization is needed in case a string is put on
character stream, double dispatching every character is insane. But so
is shortcutting Array is Array-based stream.

Maybe the optimization should have additional anObject isString test (in
case of string, the counterexample cannot be created, because they
cannot be nested). Or there should be additional double dispatch via
nextPutString:, if string-based streams have their hierarchy. You know
the codebase better.

Unless it is already solved by some other twist.

Thanks, Herby

Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Richard O'Keefe
In reply to this post by Herby Vojčík
It is good that you have a coherent idea of how << can work.
The question I was addressing is how << *DOES* work in Pharo.
Having simple things working, if they are kept consistent,
is indeed good.  The problem is that in Pharo 7 they are NOT
consistent, and << does NOT work consistently, because there
are occasions when << does ^something nextPutAll: something else
and nextPutAll: returns something else.

I am grateful for the link to the changes to Pharo 8.
That's a massive simplification and improvement.
There is some way to go yet.

The very first thing that should be done is to write down
what the *semantics* of #<< is supposed to be, and then to
ensure it is implemented that way.

Let's look at the chunk example.

exportTraitDefinitionOf: aClass on: aStream
  "Chunk format."
  aStream
    nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr;
    tab; nextPutAll: 'package: '; print: aClass category; nextPutAll: '!!'; cr.
  aClass comment isEmpty ifFalse: [
    aStream
      nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr;
      nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; cr].
  aStream cr.

With the exception of #nextPutAll:withDelimiter:, this is completely
standard and portable.  If I am willing to do something nonstandard,

  aStream format: 'Trait named: {s}{n}{t}package: {p}{n}'
    with: aClass name with: aClass category.
  aClass comment isEmpty ifFalse: [
    aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}'
      with: aClass with: aClass comment].
  aClass format: '{n}.

#write: really does not seem to be any improvement over #nextPutAll:.

For what it's worth, GNU Smalltalk also has #<<, which it defines
to be equivalent to #displayOn:, if memory serves me correctly.
It has never been clear to me what the use case for #write: is.
In Pharo 7, for streams it is the same as #putOn: except for the
result.  Neither of them is in any interesting way "higher
level" than #nextPut: or #nextPutAll:, merely less informative.
Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Herby Vojčík
On 11. 9. 2019 3:23, Richard O'Keefe wrote:
> It is good that you have a coherent idea of how << can work.

After the changes sent by Sven, Pharo 8 seems to have the exactly same
idea. IMNSHO.

> The question I was addressing is how << *DOES* work in Pharo.
> Having simple things working, if they are kept consistent,
> is indeed good.  The problem is that in Pharo 7 they are NOT
> consistent, and << does NOT work consistently, because there
> are occasions when << does ^something nextPutAll: something else
> and nextPutAll: returns something else.

Bug. '^' should not have been there.

> I am grateful for the link to the changes to Pharo 8.
> That's a massive simplification and improvement.
> There is some way to go yet.

Actually, from my PoV, just the fix I posted. The rest seems correct.

> The very first thing that should be done is to write down
> what the *semantics* of #<< is supposed to be, and then to
> ensure it is implemented that way. >
> Let's look at the chunk example.
>
> exportTraitDefinitionOf: aClass on: aStream
>    "Chunk format."
>    aStream
>      nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr;

The devil is in the details. Why you changed `printSymbol: aClass name`
for `nextPutAll: aClass name`? Now it outputs things incorrectly. You
should have changed it for `print: aClass name asSymbol`

And this is precisely that distinction between low-level nextPutAll: and
high-level write: / << / print:.

>      tab; nextPutAll: 'package: '; print: aClass category; nextPutAll:
> '!!'; cr.
>    aClass comment isEmpty ifFalse: [
>      aStream
>        nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr;
>        nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; cr].
>    aStream cr.
>
> With the exception of #nextPutAll:withDelimiter:, this is completely
> standard and portable.  If I am willing to do something nonstandard,
>
>    aStream format: 'Trait named: {s}{n}{t}package: {p}{n}'
>      with: aClass name with: aClass category.
>    aClass comment isEmpty ifFalse: [
>      aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}'
>        with: aClass with: aClass comment].
>    aClass format: '{n}.
>
> #write: really does not seem to be any improvement over #nextPutAll:.

Will post.

> For what it's worth, GNU Smalltalk also has #<<, which it defines
> to be equivalent to #displayOn:, if memory serves me correctly.
> It has never been clear to me what the use case for #write: is.
> In Pharo 7, for streams it is the same as #putOn: except for the
> result.  Neither of them is in any interesting way "higher
> level" than #nextPut: or #nextPutAll:, merely less informative.



Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Herby Vojčík
On 11. 9. 2019 11:46, Herby Vojčík wrote:
> On 11. 9. 2019 3:23, Richard O'Keefe wrote:
>> #write: really does not seem to be any improvement over #nextPutAll:.
>
> Will post.

Actually, I won't. I don't care any more.

I found Contributor Covenant-derived Code of Conduct was added to Pharo,
three months ago. This is unacceptable under any circumstances.

Have fun in your woke hell.

Herby


Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Offray Vladimir Luna Cárdenas-2

On 11/09/19 9:14 a. m., Herby Vojčík wrote:

> On 11. 9. 2019 11:46, Herby Vojčík wrote:
>> On 11. 9. 2019 3:23, Richard O'Keefe wrote:
>>> #write: really does not seem to be any improvement over #nextPutAll:.
>>
>> Will post.
>
> Actually, I won't. I don't care any more.
>
> I found Contributor Covenant-derived Code of Conduct was added to
> Pharo, three months ago. This is unacceptable under any circumstances.
>
> Have fun in your woke hell.
>
> Herby
>
>
>

I would like to have more details about this. For those of us who don't
believe in hell, what is the problem of an explicit Code of Conduct?

Cheers,

Offray


Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

jgfoster

> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
>
> On 11/09/19 9:14 a. m., Herby Vojčík wrote:
>> I found Contributor Covenant-derived Code of Conduct was added to
>> Pharo, three months ago. This is unacceptable under any circumstances.
>>
>> Have fun in your woke hell.
>
> I would like to have more details about this. For those of us who don't
> believe in hell, what is the problem of an explicit Code of Conduct?

More specifically, what behavior does the Code prohibit that you would otherwise do?

For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting.

James
Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Sven Van Caekenberghe-2


> On 11 Sep 2019, at 19:07, James Foster <[hidden email]> wrote:
>
>
>> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
>>
>> On 11/09/19 9:14 a. m., Herby Vojčík wrote:
>>> I found Contributor Covenant-derived Code of Conduct was added to
>>> Pharo, three months ago. This is unacceptable under any circumstances.
>>>
>>> Have fun in your woke hell.
>>
>> I would like to have more details about this. For those of us who don't
>> believe in hell, what is the problem of an explicit Code of Conduct?
>
> More specifically, what behavior does the Code prohibit that you would otherwise do?
>
> For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting.
>
> James

Indeed.

For those new to the discussion, we are talking about https://www.contributor-covenant.org/version/1/4/code-of-conduct - which is quite popular and generally accepted.

Sven


Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Sean P. DeNigris
Administrator
Sven Van Caekenberghe-2 wrote
> https://www.contributor-covenant.org/version/1/4/code-of-conduct - which
> is quite popular and generally accepted.

Based on the reaction earlier in the thread, I was expecting something
highly opinionated and polarizing, but it seems to boil down to: be
professional and don't make it personal. While there are some categories of
people mentioned, it doesn't seem to make a value judgement about them, but
merely say that no one (including from those categories) will be harassed
inside the Pharo community. Seems pretty reasonable, unless I'm missing
something...



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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Peter Kenny
In reply to this post by Sven Van Caekenberghe-2
I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph: " Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform. The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code? The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems. Peter Kenny
Sven Van Caekenberghe-2 wrote
> On 11 Sep 2019, at 19:07, James Foster <[hidden email]> wrote: > > >> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: >> >> On 11/09/19 9:14 a. m., Herby Vojčík wrote: >>> I found Contributor Covenant-derived Code of Conduct was added to >>> Pharo, three months ago. This is unacceptable under any circumstances. >>> >>> Have fun in your woke hell. >> >> I would like to have more details about this. For those of us who don't >> believe in hell, what is the problem of an explicit Code of Conduct? > > More specifically, what behavior does the Code prohibit that you would otherwise do? > > For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting. > > James Indeed. For those new to the discussion, we are talking about https://www.contributor-covenant.org/version/1/4/code-of-conduct - which is quite popular and generally accepted. Sven


Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Richard Sargent
Administrator
Thanks for sharing that, Peter. It's an important point.

On Wed, Sep 11, 2019 at 2:02 PM Peter Kenny <[hidden email]> wrote:
I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph: " Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform. The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code? The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems. Peter Kenny
Sven Van Caekenberghe-2 wrote
> On 11 Sep 2019, at 19:07, James Foster <[hidden email]> wrote: > > >> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: >> >> On 11/09/19 9:14 a. m., Herby Vojčík wrote: >>> I found Contributor Covenant-derived Code of Conduct was added to >>> Pharo, three months ago. This is unacceptable under any circumstances. >>> >>> Have fun in your woke hell. >> >> I would like to have more details about this. For those of us who don't >> believe in hell, what is the problem of an explicit Code of Conduct? > > More specifically, what behavior does the Code prohibit that you would otherwise do? > > For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting. > > James Indeed. For those new to the discussion, we are talking about https://www.contributor-covenant.org/version/1/4/code-of-conduct - which is quite popular and generally accepted. Sven


Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Peter Kenny
In reply to this post by Peter Kenny

First, apologies for the shambles of formatting this post.

 

Secondly, having re-read it, I think it was inappropriate to mention Sven in the way I did. I still maintain that there are problems with the code, but I wish to retract the comments about Sven, and I apologise for including them.

 

Peter Kenny

 

From: Pharo-users <[hidden email]> On Behalf Of Peter Kenny
Sent: 11 September 2019 22:02
To: [hidden email]
Subject: Re: [Pharo-users] Code of Conduct

 

I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph: " Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform. The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code? The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems. Peter Kenny

Sven Van Caekenberghe-2 wrote

> On 11 Sep 2019, at 19:07, James Foster <[hidden email]> wrote: > > >> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: >> >> On 11/09/19 9:14 a. m., Herby Vojčík wrote: >>> I found Contributor Covenant-derived Code of Conduct was added to >>> Pharo, three months ago. This is unacceptable under any circumstances. >>> >>> Have fun in your woke hell. >> >> I would like to have more details about this. For those of us who don't >> believe in hell, what is the problem of an explicit Code of Conduct? > > More specifically, what behavior does the Code prohibit that you would otherwise do? > > For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting. > > James Indeed. For those new to the discussion, we are talking about https://www.contributor-covenant.org/version/1/4/code-of-conduct - which is quite popular and generally accepted. Sven

 


Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Stream >> <<

Richard O'Keefe
In reply to this post by Herby Vojčík
> Why you changed `printSymbol: aClass name`
> for `nextPutAll: aClass name`?

Because there is no #printSymbol: anywhere in Pharo 7 or Pharo 8> ,
so I had to *guess* what it does, and the only reason I could see for
using #printSymbol: instead of #print: is that class names are symbols
and #print: will write a hash in front, and it seemed plausible that
you would not want that hash.  Accordingly I chose a well known, even
standard, method that writes a class name with no extra decoration.

> Now it outputs things incorrectly. You
> should have changed it for `print: aClass name asSymbol`

How is one supposed to *tell* what "correct" output is?
If I wanted to write that code, I would be kind to my readers
and make it *obvious* by doing
   stream nextPut; $#; nextPutAll: aClass name.
I certainly would not go out of my way to confuse people by
sending #asSymbol to something they already know is a Symbol.

For what it's worth, I've attached my implementation.


On Wed, 11 Sep 2019 at 21:46, Herby Vojčík <[hidden email]> wrote:
On 11. 9. 2019 3:23, Richard O'Keefe wrote:
> It is good that you have a coherent idea of how << can work.

After the changes sent by Sven, Pharo 8 seems to have the exactly same
idea. IMNSHO.

> The question I was addressing is how << *DOES* work in Pharo.
> Having simple things working, if they are kept consistent,
> is indeed good.  The problem is that in Pharo 7 they are NOT
> consistent, and << does NOT work consistently, because there
> are occasions when << does ^something nextPutAll: something else
> and nextPutAll: returns something else.

Bug. '^' should not have been there.

> I am grateful for the link to the changes to Pharo 8.
> That's a massive simplification and improvement.
> There is some way to go yet.

Actually, from my PoV, just the fix I posted. The rest seems correct.

> The very first thing that should be done is to write down
> what the *semantics* of #<< is supposed to be, and then to
> ensure it is implemented that way. >
> Let's look at the chunk example.
>
> exportTraitDefinitionOf: aClass on: aStream
>    "Chunk format."
>    aStream
>      nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr;

The devil is in the details. Why you changed `printSymbol: aClass name`
for `nextPutAll: aClass name`? Now it outputs things incorrectly. You
should have changed it for `print: aClass name asSymbol`

And this is precisely that distinction between low-level nextPutAll: and
high-level write: / << / print:.

>      tab; nextPutAll: 'package: '; print: aClass category; nextPutAll:
> '!!'; cr.
>    aClass comment isEmpty ifFalse: [
>      aStream
>        nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr;
>        nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; cr].
>    aStream cr.
>
> With the exception of #nextPutAll:withDelimiter:, this is completely
> standard and portable.  If I am willing to do something nonstandard,
>
>    aStream format: 'Trait named: {s}{n}{t}package: {p}{n}'
>      with: aClass name with: aClass category.
>    aClass comment isEmpty ifFalse: [
>      aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}'
>        with: aClass with: aClass comment].
>    aClass format: '{n}.
>
> #write: really does not seem to be any improvement over #nextPutAll:.

Will post.

> For what it's worth, GNU Smalltalk also has #<<, which it defines
> to be equivalent to #displayOn:, if memory serves me correctly.
> It has never been clear to me what the use case for #write: is.
> In Pharo 7, for streams it is the same as #putOn: except for the
> result.  Neither of them is in any interesting way "higher
> level" than #nextPut: or #nextPutAll:, merely less informative.



puton.st (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Richard O'Keefe
In reply to this post by Sean P. DeNigris
There are some aspects of the "Covenant" that rub me up the wrong way.
I note that the only part of it where anyone actually promises to do
(or not do) anything is the "Pledge", which rather pointedly refrains
from treating people with different political viewpoints (like gun
ownership, or like TERFs who are silent about their opinions within
the group) well.  It's about supporting diversity of *being*, not
diversity of *opinion*.

There are other codes of conduct around which are framed in less
identitarian terms.  And it is rather startling to find that one
is expected to be bound by a "Covenant" which is no Covenant (that
is, an *agreement*).  A code of conduct can be imposed from the
top down; a covenant requires the consent of the governed.

I am somewhat perturbed by the term "inclusive language" because
it is a shifting standard.  I have frequently heard young women
addressing each other as "guys", yet have just recently watching
someone basically saying "I know it's gender neutral now and there
is no malice in it but it's exclusionary so it's really bad."
So if you say something like "hey guys" in a message, you have just
violated this covenant, and deserve to be thrown out.  Or then
again, you may not have.  Who decides?  In a world where an
anti-racist black hero gets labelled a white supremacist, who decides?

Here's another case.  Many mailing lists or newsgroups have a policy
"no homework answers".  If you tell someone off for violating that
policy, your mailing list or newsgroup is not welcoming and inclusive.
In another mailing list I am on, there is a clear and explicit "no HTML
postings" policy, for good topic-specific reason, and people are often
(politely) told off for violating it.  As I read the Covenant, that's
not allowed.

In a mailing list where you have no idea of my age, sex, body size,
gender orientation, etc, much of the Covenant is prima facie pointless.

The Covenant goes way too far to be a mere "be nice to each other" guide.

I have no intention of giving offence, and I am I not going to pull out
of the mailing list, but couldn't some less creepy code be adopted?





On Thu, 12 Sep 2019 at 08:08, Sean P. DeNigris <[hidden email]> wrote:
Sven Van Caekenberghe-2 wrote
> https://www.contributor-covenant.org/version/1/4/code-of-conduct - which
> is quite popular and generally accepted.

Based on the reaction earlier in the thread, I was expecting something
highly opinionated and polarizing, but it seems to boil down to: be
professional and don't make it personal. While there are some categories of
people mentioned, it doesn't seem to make a value judgement about them, but
merely say that no one (including from those categories) will be harassed
inside the Pharo community. Seems pretty reasonable, unless I'm missing
something...



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

Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

John Pfersich
+100

/————————————————————/
For encrypted mail use [hidden email]
Get a free account at ProtonMail.com

On Sep 12, 2019, at 10:13, Richard O'Keefe <[hidden email]> wrote:

There are some aspects of the "Covenant" that rub me up the wrong way.
I note that the only part of it where anyone actually promises to do
(or not do) anything is the "Pledge", which rather pointedly refrains
from treating people with different political viewpoints (like gun
ownership, or like TERFs who are silent about their opinions within
the group) well.  It's about supporting diversity of *being*, not
diversity of *opinion*.

There are other codes of conduct around which are framed in less
identitarian terms.  And it is rather startling to find that one
is expected to be bound by a "Covenant" which is no Covenant (that
is, an *agreement*).  A code of conduct can be imposed from the
top down; a covenant requires the consent of the governed.

I am somewhat perturbed by the term "inclusive language" because
it is a shifting standard.  I have frequently heard young women
addressing each other as "guys", yet have just recently watching
someone basically saying "I know it's gender neutral now and there
is no malice in it but it's exclusionary so it's really bad."
So if you say something like "hey guys" in a message, you have just
violated this covenant, and deserve to be thrown out.  Or then
again, you may not have.  Who decides?  In a world where an
anti-racist black hero gets labelled a white supremacist, who decides?

Here's another case.  Many mailing lists or newsgroups have a policy
"no homework answers".  If you tell someone off for violating that
policy, your mailing list or newsgroup is not welcoming and inclusive.
In another mailing list I am on, there is a clear and explicit "no HTML
postings" policy, for good topic-specific reason, and people are often
(politely) told off for violating it.  As I read the Covenant, that's
not allowed.

In a mailing list where you have no idea of my age, sex, body size,
gender orientation, etc, much of the Covenant is prima facie pointless.

The Covenant goes way too far to be a mere "be nice to each other" guide.

I have no intention of giving offence, and I am I not going to pull out
of the mailing list, but couldn't some less creepy code be adopted?





On Thu, 12 Sep 2019 at 08:08, Sean P. DeNigris <[hidden email]> wrote:
Sven Van Caekenberghe-2 wrote
> https://www.contributor-covenant.org/version/1/4/code-of-conduct - which
> is quite popular and generally accepted.

Based on the reaction earlier in the thread, I was expecting something
highly opinionated and polarizing, but it seems to boil down to: be
professional and don't make it personal. While there are some categories of
people mentioned, it doesn't seem to make a value judgement about them, but
merely say that no one (including from those categories) will be harassed
inside the Pharo community. Seems pretty reasonable, unless I'm missing
something...



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

Reply | Threaded
Open this post in threaded view
|

Re: Code of Conduct

Ramon Leon-5
In reply to this post by Sean P. DeNigris
On 2019-09-11 1:07 p.m., Sean P. DeNigris wrote:
> Based on the reaction earlier in the thread, I was expecting something
> highly opinionated and polarizing, but it seems to boil down to: be
> professional and don't make it personal. While there are some categories of
> people mentioned, it doesn't seem to make a value judgement about them, but
> merely say that no one (including from those categories) will be harassed
> inside the Pharo community. Seems pretty reasonable, unless I'm missing
> something...

You're missing what some progressives consider harassment these days.  These codes of conduct are being used around the net to force progressive political ideology into technical communities, the vague language is used to claim offense at any number of things like misgendering, or refusing to use any number of made up pronouns. Using inclusive language means using progressive language like ze/zir, per/pers, ey/em, xe/xem if someone demands it.  This is language policing and a forcing of political ideology into what should not be political.  People are being kicked out of communities for violating codes of conduct of the community outside of the community, i.e. you said something on twitter or facebook and now you're banned from an open source project for it even though it had nothing to do with the project.

The person who created this particular code of conduct is a well known trans activist who first gets communities to accept the code of conduct, and then stalks people around web to find anything anywhere that might violate the vague code of conduct and then tries to cancel them in every community they're a part of. If you're not wary of this code of conduct, you're not paying attention to how it's being used out there.

Here's a few quotes from the author of this code of conduct.

"The Ruby community has no moral compass. Just aphorisms and self-congtatulatory, masturbatory bullshit."  << after trying and failing to kick the creator of Ruby out of the Ruby community.

"If you're not fighting alongside us, or lending support, you're STANDING IN OUR WAY. And I vow that I will walk right the fuck over you.".

"Fact: the solution to the problems in tech is not more tech. Especially not more tech written by privileged, heads-in-the-sand white dudes."

"So many cis het white tech dudes with large platforms on here, that not only don't engage in dialog on issues of social justice but don't even elevate the voices of those of us who do, ignoring POLITICS is a PRIVILEGE and I FUCKING SEE YOU."

Here's a little history of this code of conduct and some other popular communities.

https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

It's sad to see that Pharo has jumped onto this PC bandwagon, it does not bode well for the community.

--
Ramón León


1234 ... 6