Re: [Pharo-users] Stream >> <

[Richard O'Keefe]

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.

[Pharo-users] uFFI ExternalAddress challenges

[Tomaž Turk]

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

Re: [Pharo-users] Stream >> <

[Herby Vojčík]

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

Re: [Pharo-users] Stream >> <

[Herby Vojčík]

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

Re: [Pharo-users] ..LCK

[James Foster]

The lock file is tested to see if the stone is running and if you delete it 
then the system should be willing to start a new stone. Please reboot your 
machine, try the ’startstone’ command again, and then post the output of to the 
gemstone mailing list.

> On Sep 10, 2019, at 2:24 AM, ian  wrote:
> 
> Hi All,
> 
> I am not able to start my stone as I inadvertantly deleted the ..LCK file. :)
> 
> Is there a way to fix this?
> 
> Thanks,
> 
> 

Re: [Pharo-users] Stream >> <

[Sven Van Caekenberghe]

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  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.
> 

Re: [Pharo-users] Stream >> <

[Richard O'Keefe]

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.

Re: [Pharo-users] Stream >> <

[Noury Bouraqadi]

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  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
> 

Re: [Pharo-users] Lazy Streams - was: Re: Set >> collect:thenDo:

[Steffen Märcker]

Hi,

I really think we should have an efficient way to chain operations on
collections and alike. In my personal opinion, this should be backed by
transducers, as they decouple the operations from the type the data source
and sink. Hence they are applicable to different collection types, streams
and so on. Also, transducers allow for straight-forward parallization of
operations that are concurrency-safe.

However, the transducers port is not complete yet. I think I'll finish it
in October/November, but definitely this year. Maybe this could be a
starting point to discuss how to move forward?

One related question: Is there a somewhat comprehensive benchmark yielding
a baseline of Pharo's collection/streams/iteration performance? I'd really
like to compare the existing implemenation to the alternative approaches.

Best regards,
Steffen


Am .09.2019, 11:30 Uhr, schrieb Kasper Østerbye
:


On 10 September 2019 at 00.56.28, Richard O'Keefe (rao...@gmail.com)
wrote:

Does that sound like a way forward?
I could convert my implementation of this interface to
Pharo if people would like me to.

Hi Richard,

It seems like what you propose (in sofar as I understand it) is already
present in at least three other libraries which have not yet made it to
the
core of Pharo:

The Iterator framework Julien is working on:
https://github.com/juliendelplanque/Iterators

The XStreams framework: https://code.google.com/archive/p/xtreams/


The transducers: https://github.com/Pharophile/Transducers


I was not aware of the virtual collections from Strongtalk.

I am aware you know them (as you commented on the Iterators Julien
proposed).

I have been working with the LINQ stream/iterator framework in C#, and
found that to be a rather sound library, lazy evaluation. The streams in
Java are also nice, and are actually very good at exploiting multi cores.

It is sad there is no lazy streams in the core of Pharo, and I would find
it intersting to participate in a project to build one.

Best,

Kasper

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

[Pharo-users] ..LCK

[ian]

Hi All,

I am not able to start my stone as I inadvertantly deleted the ..LCK file. :)

Is there a way to fix this?

Thanks,