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

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

by Gareth Cox

Thanks Sven I will have to first deconstruct the url and then reconstruct it as you mentioned. We discussed this in the discord channel and came to the same conclusion. I really like your final solution and will probably go with that. Thanks Gareth IT Manager/Developer email: gareth(a)inspired.org cell: +27 (0)78 374 9035 Inspired Org (PTY) Ltd On 19 Mar 2018 16:55, Sven Van Caekenberghe wrote: > Hi Gareth, > >> On 19 Mar 2018, at 15:23, Gareth Cox <gareth(a)inspired.org >> <mailto:gareth@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 >> <http://www.yr.no/place/Mexico/Nuevo_Le%C3%B3n/Monterrey/forecast.xml>' >> asZnUrl >> >> The url comes from the yr.no <http://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 <http://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 <http://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 20, 2018

ZnClient - receiving/parsing malformed cookie 'expires' value

by PAUL DEBRUICKER

Hi - This is more of an FYI than anything I'm interacting with an API that is sending "expires=0" value as part of the only cookie of their response. Changing #expiresTimeStamp to (self expires isNil or:[self expires size<28] ) ifTrue:[ ^ DateAndTime now + 1 day ]. ^ ZnUtils parseHttpDate: self expires fixes my issue but maybe there's a better way to handle cookie parsing errors Paul

March 20, 2018

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

by Sean P. DeNigris

Guillermo Polito wrote > I've done also some profiling and it does not look like we've lost in > performance either (reading and decoding a 35MB file): Your 1st (new API) example: "0:00:00:01.535" Your 2nd (old API) example:"0:00:00:01.732" *** but *** Your 1st (new API) example using the same consuming selector as example #1 (#upToEnd): "0:00:00:07.816" or 4.5x slower ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 19, 2018

Re: [Pharo-users] MiniScheme in Pharo

by Stephane Ducasse

Clement I added a little section right at the beginning on car/cdr and others. Tx On Sun, Mar 18, 2018 at 11:32 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > p.3 > simpliciyty -> simplicity > > p.4 > we will have the define their semantics. > -> to define ? I am not sure I understand the sentence > > p.10 > and may converted on the fly > -> and maybe ? I am not sure I understand the sentence > > At the beginning I started to read and understood nothing, then I read a 24 > slides lecture on lisp lists [1], then I restarted to read and understood > One of my main problem was that what cdr does is explained p.7, while cdr is > used p.3 for the first time and multiple times before p.7. But maybe you > expect the reader to know scheme already. > > [1] https://perso.liris.cnrs.fr/nathalie.guin/LIF3/Cours/Cours3-Listes.pdf > (first result on google for me) > > On Sat, Mar 17, 2018 at 7:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi >> >> I finally decided to release the booklet I wrote about implementing a >> minischeme in Pharo. >> I did not announce it yet because I would like to get feedback and fix >> what can be fixed. >> >> >> >> https://files.pharo.org/books-pdfs/booklet-AMiniSchemeInPharo/2018-03-17-Mi… >> >> Stef >> > > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/

March 19, 2018

Re: [Pharo-users] MiniScheme in Pharo

by Stephane Ducasse

Since I was born in lisp it looks natural to me so I will imporve the cdr use tx for this feedback On Sun, Mar 18, 2018 at 11:32 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > p.3 > simpliciyty -> simplicity > > p.4 > we will have the define their semantics. > -> to define ? I am not sure I understand the sentence > > p.10 > and may converted on the fly > -> and maybe ? I am not sure I understand the sentence > > At the beginning I started to read and understood nothing, then I read a 24 > slides lecture on lisp lists [1], then I restarted to read and understood > One of my main problem was that what cdr does is explained p.7, while cdr is > used p.3 for the first time and multiple times before p.7. But maybe you > expect the reader to know scheme already. > > [1] https://perso.liris.cnrs.fr/nathalie.guin/LIF3/Cours/Cours3-Listes.pdf > (first result on google for me) > > On Sat, Mar 17, 2018 at 7:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi >> >> I finally decided to release the booklet I wrote about implementing a >> minischeme in Pharo. >> I did not announce it yet because I would like to get feedback and fix >> what can be fixed. >> >> >> >> https://files.pharo.org/books-pdfs/booklet-AMiniSchemeInPharo/2018-03-17-Mi… >> >> Stef >> > > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/

March 19, 2018

Re: [Pharo-users] MiniScheme in Pharo

by Stephane Ducasse

Yes there! Tx in advance for copy edition. Stef On Sun, Mar 18, 2018 at 4:59 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On dim. 18 mars 2018 at 16:24, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> Stephane Ducasse-3 wrote >> > I would like to get feedback and fix >> > what can be fixed. >> >> Is there a public link to the source? It would be easiest to submit fixes >> via PRs instead of ML :) >> > > Probably > > https://github.com/SquareBracketAssociates/Booklet-AMiniSchemeInPharo > > >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > -- > Cyril Ferlicot > https://ferlicot.fr

March 19, 2018

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

by Stephane Ducasse

+ 1 :) On Mon, Mar 19, 2018 at 2:16 PM, 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] New Files in Pharo - Migration Guide, How To's and examples

by Stephane Ducasse

I love the idea of measuring statement :) On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > 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 <+33%206%2052%2070%2066%2013> >

March 19, 2018

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

by Stephane Ducasse

Thanks Guille for this great post! I will turn it into a doc :) On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > 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 <+33%206%2052%2070%2066%2013> >

March 19, 2018

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

by Stephane Ducasse

Yes we should migrate it and probably include it in Pharo and clean it. Stef On Mon, Mar 19, 2018 at 6:59 PM, Mariano Badoglio <marianobadoglio(a)gmail.com> wrote: > 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