March 2018 - Pharo-users - lists.pharo.org

HRWorks is looking for Pharoers :)

by Stephane Ducasse

https://www.hrworks.de/en/international-applicants/ Stef

March 19, 2018

Re: [Pharo-users] Pharo sound with SDL Library

by Mariano Badoglio

Hi Stephean, Sean, Thanks for your response. I have installed the Monticello Package "Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the last update is Sound-StephaneDucasse.80 package from year 2013. It is from Pharo Extras. Is this the right package? Best regards, Mariano El 17/03/18 a las 16:05, Stephane Ducasse escribiÃ³: > Hi mariano > > did you try the sound package that is on Smalltalkhub/Pharo? or > PharoExtras. We should migrate it to pharo 70 > > Stef > > On Sat, Mar 17, 2018 at 1:14 PM, Mariano Badoglio > <marianobadoglio(a)gmail.com> wrote: >> Hello! >> >> I need to use the Pharo Sound over Ubuntu platform, but I couldn't get >> it work. I tryied sending the parameter vm-sound-OSS and vm-sound-ALSA >> to the vm but I get no results. >> >> I am now trying to use the SDL Library. I could initialize the sound >> SDL_Init(SDL_INIT_AUDIO), very similar to initializing video, but when >> trying to use the SDL_LoadWAV, it needs a SDL_AudioSpec data type and I >> do not know how to do it. I tried to use an Structure as parameter but >> with no result, I couldn't found any similar example to follow. I will >> appreciate any help or tips on this. >> >> Thanks in advance. Best regards, >> Mariano. >> >> >> >

March 19, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Guillermo Polito

Well, I'd say it we did it in the name of modularity. And yes, I believe that having separate responsibilities help in designing, testing and ensuring more easily the correctness of each of the parts in isolation. I've done also some profiling and it does not look like we've lost in performance either (reading and decoding a 35MB file): [file := Smalltalk sourcesFile fullName. (File named: file) readStreamDo: [ :binaryFile | (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: 'utf8') next: binaryFile size. ]] timeToRun. "0:00:00:01.976" [file := Smalltalk sourcesFile fullName. (MultiByteFileStream fileNamed: file) converter: (TextConverter newForEncoding: 'utf8'); upToEnd ] timeToRun. "0:00:00:02.147" On Mon, Mar 19, 2018 at 5:51 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > The idea of stacking things like character coding and buffering &c > by using layers of wrapping is very much in the spirit of Java and > is neither good for performance nor helpful for correctness. > > > On 20 March 2018 at 05:19, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> I've put some minutes summarizing the new APIs provided by the >> combination of the new File implementation and the Zn encoders. They all >> basically follow the decorator pattern to stack different responsibilities >> such as buffering, encoding, line ending convertions. >> >> Please, do not hesitate to give your feedback. >> >> Guille >> >> >> 1. Basic Files >> >> By default files are binary. Not buffered. >> >> (File named: 'name') readStream. >> (File named: 'name') readStreamDo: [ :stream | ... ]. >> (File named: 'name') writeStream. >> (File named: 'name') writeStreamDo: [ :stream | ... ]. >> >> >> 2. Encoding >> >> To add encoding, wrap a stream with a corresponding >> ZnCharacterRead/WriteStream. >> >> "Reading" >> utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'. >> utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'. >> >> "Writing" >> utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'. >> utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: >> 'utf16'. >> >> 3. Buffering >> >> To add buffering, wrap a stream with a corresponding >> ZnBufferedRead/WriteStream. >> >> bufferedReadStream := ZnBufferedReadStream on: aStream. >> bufferedWriteStream := ZnBufferedWriteStream on: aStream. >> >> It is in general better to buffer the reading on the binary file and >> apply the encoding on the buffer in memory than the other way around. See >> >> [file := Smalltalk sourcesFile fullName. >> (File named: file) readStreamDo: [ :binaryFile | >> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) >> encoding: 'utf8') upToEnd >> ]] timeToRun. "0:00:00:09.288" >> >> [file := Smalltalk sourcesFile fullName. >> (File named: file) readStreamDo: [ :binaryFile | >> (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding: >> 'utf8')) upToEnd >> ]] timeToRun. "0:00:00:14.189" >> >> 4. File System >> >> By default, file system files are buffered and utf8 encoded to keep >> backwards compatibility. >> >> 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ]. >> 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ]. >> >> FileStream also provides access to plain binary files using the >> #binaryRead/WriteStream messages. Binary streams are buffered by default >> also. >> >> 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... >> ]. >> 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... >> ]. >> >> If you want a file with another encoding (to come in the PR >> https://github.com/pharo-project/pharo/pull/1134) you can specify it >> while obtaining the stream: >> >> 'name' asFileReference >> readStreamEncoded: 'utf16' >> do: [ :bufferedUtf16Stream | ... ]. >> >> 'name' asFileReference >> writeStreamEncoded: 'utf8' >> do: [ :bufferedUtf16Stream | ... ]. >> >> 5. Line Ending Conventions >> >> If you want to write files following a specific line ending convention, >> use the ZnNewLineWriterStream. >> This stream decorator will transform any line ending (cr, lf, crlf) into >> a defined line ending. >> By default it chooses the platform line ending convention. >> >> lineWriter := ZnNewLineWriterStream on: aStream. >> >> If you want to choose another line ending convention you can do: >> >> lineWriter forCr. >> lineWriter forLf. >> lineWriter forCrLf. >> lineWriter forPlatformLineEnding. >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 19, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Richard O'Keefe

The idea of stacking things like character coding and buffering &c by using layers of wrapping is very much in the spirit of Java and is neither good for performance nor helpful for correctness. On 20 March 2018 at 05:19, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > I've put some minutes summarizing the new APIs provided by the combination > of the new File implementation and the Zn encoders. They all basically > follow the decorator pattern to stack different responsibilities such as > buffering, encoding, line ending convertions. > > Please, do not hesitate to give your feedback. > > Guille > > > 1. Basic Files > > By default files are binary. Not buffered. > > (File named: 'name') readStream. > (File named: 'name') readStreamDo: [ :stream | ... ]. > (File named: 'name') writeStream. > (File named: 'name') writeStreamDo: [ :stream | ... ]. > > > 2. Encoding > > To add encoding, wrap a stream with a corresponding > ZnCharacterRead/WriteStream. > > "Reading" > utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'. > utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'. > > "Writing" > utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'. > utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'. > > 3. Buffering > > To add buffering, wrap a stream with a corresponding > ZnBufferedRead/WriteStream. > > bufferedReadStream := ZnBufferedReadStream on: aStream. > bufferedWriteStream := ZnBufferedWriteStream on: aStream. > > It is in general better to buffer the reading on the binary file and apply > the encoding on the buffer in memory than the other way around. See > > [file := Smalltalk sourcesFile fullName. > (File named: file) readStreamDo: [ :binaryFile | > (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: > 'utf8') upToEnd > ]] timeToRun. "0:00:00:09.288" > > [file := Smalltalk sourcesFile fullName. > (File named: file) readStreamDo: [ :binaryFile | > (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding: > 'utf8')) upToEnd > ]] timeToRun. "0:00:00:14.189" > > 4. File System > > By default, file system files are buffered and utf8 encoded to keep > backwards compatibility. > > 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ]. > 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ]. > > FileStream also provides access to plain binary files using the > #binaryRead/WriteStream messages. Binary streams are buffered by default > also. > > 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ]. > 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... > ]. > > If you want a file with another encoding (to come in the PR > https://github.com/pharo-project/pharo/pull/1134) you can specify it > while obtaining the stream: > > 'name' asFileReference > readStreamEncoded: 'utf16' > do: [ :bufferedUtf16Stream | ... ]. > > 'name' asFileReference > writeStreamEncoded: 'utf8' > do: [ :bufferedUtf16Stream | ... ]. > > 5. Line Ending Conventions > > If you want to write files following a specific line ending convention, > use the ZnNewLineWriterStream. > This stream decorator will transform any line ending (cr, lf, crlf) into a > defined line ending. > By default it chooses the platform line ending convention. > > lineWriter := ZnNewLineWriterStream on: aStream. > > If you want to choose another line ending convention you can do: > > lineWriter forCr. > lineWriter forLf. > lineWriter forCrLf. > lineWriter forPlatformLineEnding. > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

March 19, 2018

New Files in Pharo - Migration Guide, How To's and examples

by Guillermo Polito

Hi all, I've put some minutes summarizing the new APIs provided by the combination of the new File implementation and the Zn encoders. They all basically follow the decorator pattern to stack different responsibilities such as buffering, encoding, line ending convertions. Please, do not hesitate to give your feedback. Guille 1. Basic Files By default files are binary. Not buffered. (File named: 'name') readStream. (File named: 'name') readStreamDo: [ :stream | ... ]. (File named: 'name') writeStream. (File named: 'name') writeStreamDo: [ :stream | ... ]. 2. Encoding To add encoding, wrap a stream with a corresponding ZnCharacterRead/WriteStream. "Reading" utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'. utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'. "Writing" utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'. utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'. 3. Buffering To add buffering, wrap a stream with a corresponding ZnBufferedRead/WriteStream. bufferedReadStream := ZnBufferedReadStream on: aStream. bufferedWriteStream := ZnBufferedWriteStream on: aStream. It is in general better to buffer the reading on the binary file and apply the encoding on the buffer in memory than the other way around. See [file := Smalltalk sourcesFile fullName. (File named: file) readStreamDo: [ :binaryFile | (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: 'utf8') upToEnd ]] timeToRun. "0:00:00:09.288" [file := Smalltalk sourcesFile fullName. (File named: file) readStreamDo: [ :binaryFile | (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding: 'utf8')) upToEnd ]] timeToRun. "0:00:00:14.189" 4. File System By default, file system files are buffered and utf8 encoded to keep backwards compatibility. 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ]. 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ]. FileStream also provides access to plain binary files using the #binaryRead/WriteStream messages. Binary streams are buffered by default also. 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ]. 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... ]. If you want a file with another encoding (to come in the PR https://github.com/pharo-project/pharo/pull/1134) you can specify it while obtaining the stream: 'name' asFileReference readStreamEncoded: 'utf16' do: [ :bufferedUtf16Stream | ... ]. 'name' asFileReference writeStreamEncoded: 'utf8' do: [ :bufferedUtf16Stream | ... ]. 5. Line Ending Conventions If you want to write files following a specific line ending convention, use the ZnNewLineWriterStream. This stream decorator will transform any line ending (cr, lf, crlf) into a defined line ending. By default it chooses the platform line ending convention. lineWriter := ZnNewLineWriterStream on: aStream. If you want to choose another line ending convention you can do: lineWriter forCr. lineWriter forLf. lineWriter forCrLf. lineWriter forPlatformLineEnding. -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 19, 2018

Re: [Pharo-users] Zinc URL and ASCII Encoding

by Sven Van Caekenberghe

Hi Gareth, > On 19 Mar 2018, at 15:23, Gareth Cox <gareth(a)inspired.org> wrote: > > Hi Sven > > Is Zinc being overly fussy with encoding or is ASCII only URL strings a standard. > the following fails in a workspace/playground. > > 'http://www.yr.no/place/Mexico/Nuevo_LeÃ³n/Monterrey/forecast.xml' asZnUrl > > The url comes from the yr.no database (via api). It is vaild if you paste into a browser. > Let me know what you think > > Thanks > Gareth (I am replying with CC to the ML for future reference). When ZnUrl parses a string representation of a URL it is indeed strict. As per the spec this must be ASCII. Browsers typically allow a wider range of input. But of course, these URLs are supported, you just have to construct them differently. If you use the direct construction API, you can use full Unicode. ZnUrl new scheme: #http; host: 'www.yr.no'; addPathSegments: #('place' 'Mexico' 'Nuevo_LeÃ³n' 'Monterrey' 'forecast.xml'); yourself. You'll see that the external representation of your URL is actually the following, which is acceptable to the parser. 'http://www.yr.no/place/Mexico/Nuevo_Le%C3%B3n/Monterrey/forecast.xml' asUrl. BTW, I would do your request as follows (using XML Support) : ZnClient new systemPolicy; http; host: 'www.yr.no'; addPath: #('place' 'Mexico' 'Nuevo_LeÃ³n' 'Monterrey' 'forecast.xml'); accept: 'text/xml' asMIMEType; contentReader: [ :entity | XMLDOMParser parse: entity contents ]; get. In my Pharo 7 image, this gives me a nice coloured, fully parsed DOM: HTH, Sven

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Richard O'Keefe

The idea in Smalltalk is to push a method as high as makes sense and no higher, so that if you send a message to an object where it really does not make sense (like trying to add two strings) you get a runtime failure. (Try asking an old-timer about automatic conversions in PL/I some time.) Now Lisp *did* define NIL=false, anything else=true, and Lisp came before Smalltalk, and you can bet the designers of Smalltalk knew about this possibility. As a particular example, I seem to forget to initialise variables embarrassingly often, and having x ifTrue: ... ifFalse: ... fail noisily because x was still nil has made my life simpler too often. On 20 March 2018 at 02:16, Petr Fischer <petr.fischer(a)me.com> wrote: > That sounds correct. In this context, my "universal ifTrue:" is really > terrible idea. > > Thanks for clarification! pf > > > > Why would you do such aberration? > > > > It goes against the "fail noisily" "Rule of Repair": Developers should > > design programs that fail in a manner that is easy to localize and > > diagnose or in other words âfail noisilyâ. This rule aims to prevent > > incorrect output from a program from becoming an input and corrupting > > the output of other code undetected. > > > > It is semantically incorrect, if needed, I don't see why, you sould > > implement it in your own class. But when I needed to do such "if" > > handlers, I did it using meaningful selectors like #ifGranted: or > > #ifSucceeded:, or the well known #ifEmpty: > > > > Regards, > > > > Esteban A. Maringolo > > > > > > 2018-03-19 9:40 GMT-03:00 Petr Fischer <petr.fischer(a)me.com>: > > >> Infinite recursion ? > > >> > > >> You use #ifTrue: in your implementation of Object>>#ifTrue: > > >> > > >> Plus, non-booleans cannot meaningfully respond. > > >> > > >> How would you define the semantics of > > >> > > >> 123 ifTrue: [ ... ] > > > > > > 123 is not "true", so, ignore the block. > > > Do the ifTrue block only if the receiver is instance of True (true). > Everything else is not "true" :) > > > > > > I missed the recursion, yes, but it could be done another way. > > > > > >> > > >> > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fischer(a)me.com> wrote: > > >> > > > >> > Hello, I have some sort of philosophical question about > ifTrue:/ifFalse: implementation. > > >> > > > >> > Now, ifTrue: is defined in the Boolean class > (subclassResponsibility) + in True and False classes, so, we can send this > message to the boolean expressions (instances) only, otherwise DND occurs. > > >> > > > >> > But we can also define one universal ifTrue: right in the Object > class, in this style: > > >> > > > >> > Object>>ifTrue: .... > > >> > (self = true) ifTrue: [ ... ]. > > >> > > > >> > then, we can send ifTrue: message to ANY object and it will work > correctly without DND exception on non-boolean objects. > > >> > > > >> > Is something bad about this idea? > > >> > > > >> > Thanks! pf > > >> > > > >> > > >> > > > > > > >

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Petr Fischer

That sounds correct. In this context, my "universal ifTrue:" is really terrible idea. Thanks for clarification! pf > Why would you do such aberration? > > It goes against the "fail noisily" "Rule of Repair": Developers should > design programs that fail in a manner that is easy to localize and > diagnose or in other words âfail noisilyâ. This rule aims to prevent > incorrect output from a program from becoming an input and corrupting > the output of other code undetected. > > It is semantically incorrect, if needed, I don't see why, you sould > implement it in your own class. But when I needed to do such "if" > handlers, I did it using meaningful selectors like #ifGranted: or > #ifSucceeded:, or the well known #ifEmpty: > > Regards, > > Esteban A. Maringolo > > > 2018-03-19 9:40 GMT-03:00 Petr Fischer <petr.fischer(a)me.com>: > >> Infinite recursion ? > >> > >> You use #ifTrue: in your implementation of Object>>#ifTrue: > >> > >> Plus, non-booleans cannot meaningfully respond. > >> > >> How would you define the semantics of > >> > >> 123 ifTrue: [ ... ] > > > > 123 is not "true", so, ignore the block. > > Do the ifTrue block only if the receiver is instance of True (true). Everything else is not "true" :) > > > > I missed the recursion, yes, but it could be done another way. > > > >> > >> > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fischer(a)me.com> wrote: > >> > > >> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: implementation. > >> > > >> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True and False classes, so, we can send this message to the boolean expressions (instances) only, otherwise DND occurs. > >> > > >> > But we can also define one universal ifTrue: right in the Object class, in this style: > >> > > >> > Object>>ifTrue: .... > >> > (self = true) ifTrue: [ ... ]. > >> > > >> > then, we can send ifTrue: message to ANY object and it will work correctly without DND exception on non-boolean objects. > >> > > >> > Is something bad about this idea? > >> > > >> > Thanks! pf > >> > > >> > >> > > >

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Petr Fischer

> On 19 March 2018 at 13:40, Petr Fischer <petr.fischer(a)me.com> wrote: > > > > How would you define the semantics of > > > > > > 123 ifTrue: [ ... ] > > > > 123 is not "true", so, ignore the block. > > > > What anout 123 ifFalse: [ â¦ ], then, given that 123 is not false either? Yes :) 123 is not false, so ignore the block again. Esteban explained it to me via "fail noisily" and "Rule of Repair" in this thread. Thanks! pf

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Esteban A. Maringolo

Why would you do such aberration? It goes against the "fail noisily" "Rule of Repair": Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words âfail noisilyâ. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected. It is semantically incorrect, if needed, I don't see why, you sould implement it in your own class. But when I needed to do such "if" handlers, I did it using meaningful selectors like #ifGranted: or #ifSucceeded:, or the well known #ifEmpty: Regards, Esteban A. Maringolo 2018-03-19 9:40 GMT-03:00 Petr Fischer <petr.fischer(a)me.com>: >> Infinite recursion ? >> >> You use #ifTrue: in your implementation of Object>>#ifTrue: >> >> Plus, non-booleans cannot meaningfully respond. >> >> How would you define the semantics of >> >> 123 ifTrue: [ ... ] > > 123 is not "true", so, ignore the block. > Do the ifTrue block only if the receiver is instance of True (true). Everything else is not "true" :) > > I missed the recursion, yes, but it could be done another way. > >> >> > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fischer(a)me.com> wrote: >> > >> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: implementation. >> > >> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True and False classes, so, we can send this message to the boolean expressions (instances) only, otherwise DND occurs. >> > >> > But we can also define one universal ifTrue: right in the Object class, in this style: >> > >> > Object>>ifTrue: .... >> > (self = true) ifTrue: [ ... ]. >> > >> > then, we can send ifTrue: message to ANY object and it will work correctly without DND exception on non-boolean objects. >> > >> > Is something bad about this idea? >> > >> > Thanks! pf >> > >> >> >

March 19, 2018