Re: [Pharo-users] Code of Conduct

[PBKResearch]

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  On Behalf Of Peter Kenny
Sent: 11 September 2019 22:02
To: pharo-users@lists.pharo.org
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.

Re: [Pharo-users] Code of Conduct

[Richard Sargent]

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

On Wed, Sep 11, 2019 at 2:02 PM Peter Kenny  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.
>

Re: [Pharo-users] Code of Conduct

[Peter Kenny]

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 <

> Smalltalk@

> > wrote:> > >> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna
> Cárdenas <

> offray.luna@

> > 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.> > JamesIndeed.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: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Code of Conduct

[Sean P. DeNigris]

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

Re: [Pharo-users] Code of Conduct

[Sven Van Caekenberghe]

> On 11 Sep 2019, at 19:07, James Foster  wrote:
> 
> 
>> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas 
>>  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

Re: [Pharo-users] Code of Conduct

[James Foster]

> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas 
>  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

Re: [Pharo-users] Stream >> <

[Offray Vladimir Luna Cárdenas]

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

Re: [Pharo-users] 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

Re: [Pharo-users] uFFI ExternalAddress challenges

[Tomaž Turk]

Excellent, thanks!

Re: [Pharo-users] uFFI ExternalAddress challenges

[Guillermo Polito]

> El 11 sept 2019, a las 11:43, Tomaž Turk  escribió:
> 
> >  Well, the pointer survives, the area of memory pointed by that pointer 
> > will be recycled with subsequent calls in general.
> 
> I'll pay special attention to that, but it's probably a matter of properly 
> creating and releasing COM objects.
> 
> 
> I have another question - in FFI call, how would one send a wide string, as 
> in 
> 
> void CallMethod(void * COMObj, wchar_t * MethodName)
> 
> I might have additional questions about UTF-8 and other code page nuances …

:D Windows is particularly different than other platforms.
In *nixes most APIs require a char* with the encoded bytes, which we can encode 
in Pharo doing something like

‘my string’ utf8Encoded => a byte array with the encoded string

But for windows, I think the best is to use their encoding APIs.
You’ll find the image already has some support for that, that we use to access 
environment variables and the working directory string.

Check the class Win32WideString and its class comment ;)

> 
> Best wishes,
> Tomaz

Re: [Pharo-users] 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.

Re: [Pharo-users] uFFI ExternalAddress challenges

[Tomaž Turk]

>  Well, the pointer survives, the area of memory pointed by that 
pointer will be recycled with subsequent calls in general.


I'll pay special attention to that, but it's probably a matter of 
properly creating and releasing COM objects.



I have another question - in FFI call, how would one send a wide string, 
as in


void CallMethod(void * COMObj, wchar_t * MethodName)

I might have additional questions about UTF-8 and other code page 
nuances ...


Best wishes,
Tomaz

Re: [Pharo-users] uFFI ExternalAddress challenges

[Guillermo Polito]

> El 11 sept 2019, a las 11:07, Tomaž Turk  escribió:
> 
> Hi, thanks for your quick reply.

no problem ;)

> I found the culprint while writing this email :-)

Cool!

> 
> Generally, what I'm trying to do is to make a very basic package to create 
> and communicate with COM components on Windows, mostly as an exercise :-) I 
> found this library: http://disphelper.sourceforge.net/ 
>  as a great start, so you don't have to 
> fiddle with OLE/COM headaches.
> 
> The problematic function in C is defined as:
> 
> __declspec(dllexport) void CallMethod(void* myObj) {
> ...
> }
> 
> It takes a pointer to a COM object, which was previously returned by 
> 
> __declspec(dllexport) void* CreateObject(char* szProgId) {
> ...
>IDispatch * myObj = NULL
> ...
>return &myObj;
> }
> 
> So, CreateObject() creates COM object and returns a pointer to it, 
> CallMethod() takes this pointer and tries to communicate with it. 
> 
> My error was in returning a pointer to a pointer ... since IDispatch * myObj 
> = NULL was actually hidden in a macro and I missed its true definition, huh. 

Yes, looking at the code above it seems strange returning the &myObj, being 
myObj a local variable.
Because that means that you would be returning a pointer to the stack, from a 
frame that already returned...

> 
> I was not sure whether the pointer survives from one FFI call to another

Well, the pointer survives, the area of memory pointed by that pointer will be 
recycled with subsequent calls in general.

> , or how Pharo loads/unloads DLLs - but it works as expected.

In general Pharo will load the library on usage, so you don’t have to care 
about it.
I’m sure the library is not unloaded, unless it is done explicitly (you can 
check VirtualMachine >> unloadModule:)

> 
> Thanks again and best wishes,
> Tomaz

Cheers!

Re: [Pharo-users] uFFI ExternalAddress challenges

[Tomaž Turk]

Hi, thanks for your quick reply. I found the culprint while writing this 
email :-)


Generally, what I'm trying to do is to make a very basic package to 
create and communicate with COM components on Windows, mostly as an 
exercise :-) I found this library: http://disphelper.sourceforge.net/ as 
a great start, so you don't have to fiddle with OLE/COM headaches.


The problematic function in C is defined as:

__declspec(dllexport) void CallMethod(void* myObj) {
...
}

It takes a pointer to a COM object, which was previously returned by

__declspec(dllexport) void* CreateObject(char* szProgId) {
...
   IDispatch * myObj = NULL
...
   return &myObj;
}

So, CreateObject() creates COM object and returns a pointer to it, 
CallMethod() takes this pointer and tries to communicate with it.


My error was in returning a pointer to a pointer ... since IDispatch * 
myObj = NULL was actually hidden in a macro and I missed its true 
definition, huh.


I'm running Pharo from PharoLauncher directly on Win10, without 
cygwin/mingw. For DLL I use Visual Studio 2019. I was not sure whether 
the pointer survives from one FFI call to another, or how Pharo 
loads/unloads DLLs - but it works as expected.


Thanks again and best wishes,
Tomaz

-- Original Message --
From: "Guillermo Polito" 
To: "Tomaž Turk" ; "Any question about pharo is 
welcome" 

Sent: 11. 09. 2019 10:29:34
Subject: Re: [Pharo-users] uFFI ExternalAddress challenges


Hi Thomas,

Can you share more about the definition of your CallMethod function in 
C?

From the uFFI point of view the binding looks ok…

How are you opening Pharo? From the command line or the pharo launcher?
Are you on cygwin/mingw? One other possibility (since you’re playing 
with C libraries) is to launch Pharo inside a gdb/lldb so you can check 
the reason behind the error when it crashes.


Keep us posted,
Guille

Re: [Pharo-users] uFFI ExternalAddress challenges

[Guillermo Polito]

Hi Thomas, 

Can you share more about the definition of your CallMethod function in C?
From the uFFI point of view the binding looks ok…

How are you opening Pharo? From the command line or the pharo launcher?
Are you on cygwin/mingw? One other possibility (since you’re playing with C 
libraries) is to launch Pharo inside a gdb/lldb so you can check the reason 
behind the error when it crashes.

Keep us posted,
Guille

> El 10 sept 2019, a las 19:53, Tomaž Turk  escribió:
> 
> Dear all,
> 
> I'm struggling with passing an ExternalAddress to a c function call with 
> uFFI. Firstly, I get the ExternalAddress from this method:
> 
> myFFI>>create: aString
> ^ self 
> ffiCall: #(void * CreateObject (String aString) ) 
> 
> [in c:
> void* CreateObject(char* szProgId)]
> 
> The method that uses the resulting ExternalAddress is defined as:
> 
> myFFI>>ask: anExternalAddress
> ^ self 
> ffiCall: #(void CallMethod (void * anExternalAddress) )
> 
> [in c:
> void CallMethod(void* myObj)]
> 
> In playground I have
> 
> | w |
> w := myFFI create: 'Word.Application'.
> myFFI ask: w .
> 
> w gets a "nice", properly looking external address, however the last line 
> crushes Pharo, its window gets closed.
> 
> I went through the uFFI book, however I cannot find the answer.
> 
> I'm on Windows 10 x64, Pharo 7.0.4 32-bit.
> 
> Best wishes,
> Tomaz

[Pharo-users] The most upvoted stackoverflow question - also holds for Pharo

[Kasper Østerbye]

The most upvoted question/answer on stackoverflow is this one:
https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array/11227902#11227902

I wanted to see if the results could be reproduced in Pharo, and indeed
they can (though I only get a factor 2-3 difference). The following method
does the trick:

branchPrediction
| size data rnd sum start |
size := 32768.
data := ByteArray new: size.
rnd := Random new: 0.
1 to: size do: [ :i | data at: i put: (rnd nextInt: 256) - 1 ].
“sorting the array makes the loop faster"
data sort.
sum := 0.
start := DateAndTime current.
1
timesRepeat: [ 1 to: size do: [ :i |
(data at: i) > 128
ifTrue: [ sum := sum + (data at: i) ] ] ].
^ {(DateAndTime current - start) asMilliSeconds.
sum}

Though it is old news, it is still kind of cool.

Best,

Kasper