September 2019 - Pharo-users

Re: [Pharo-users] Stream >> <<

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

Sept. 11, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by 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

Sept. 11, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by Guillermo Polito

> El 11 sept 2019, a las 11:07, TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> 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/ <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!

Sept. 11, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by 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" <guillermopolito(a)gmail.com> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> 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 >

Sept. 11, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by 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 <tomaz.turk(a)ef.uni-lj.si> 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

Sept. 11, 2019

The most upvoted stackoverflow question - also holds for Pharo

by Kasper Ãsterbye

The most upvoted question/answer on stackoverflow is this one: https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-arr… 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. 10000 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

Sept. 11, 2019

Re: [Pharo-users] Stream >> <<

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

Sept. 11, 2019

uFFI ExternalAddress challenges

by 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

Sept. 10, 2019

Re: [Pharo-users] Stream >> <<

by 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

Sept. 10, 2019

Re: [Pharo-users] Stream >> <<

by 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

Sept. 10, 2019