- Pharo-users - lists.pharo.org

Re: [Pharo-users] Query on Pharo syntax

by Ben Coman

On Tue, 11 Sep 2018 at 02:44, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Hi All > > > > This is an idiot question, I should know the answer, but I have looked > around and canât find relevant documentation. Iâm not asking for a full > answer, just a pointer as to where to start looking. > > > > I have seen from examples in this forum that an expression like the > following: > > > > paras collect: [para| para prettyPrinted] > > > > can be written more concisely as: > > > > paras collect: #prettyPrinted > > > > which obviously works when I try it. It doesnât seem to fit in with the > definition of #collect:, which requires a block as argument. Where can I > find the relevant definition, either in method comments or in some general > manual? Can the notation be extended, > Its not special notation. Just a normal object (a Symbol) passed via a normal message. > for example to #select: - obviously with an argument which returns a > Boolean? Can it be used with a method which requires an argument, e.g. as > myArray collect: (#myMethod: arg)? Are there any other extensions? > > > > Any help gratefully received. > > > > Peter Kenny > Full answer ;) Its a combination of the following two methods... Collection >> collect: aBlock | newCollection | newCollection := self species new. self do: [:each | newCollection add: (aBlock value: each)]. ^ newCollection Symbol value: anObject ^anObject perform: self. When /aBlock/ is a symbol, that symbol is performed on /each/ element. And looking at #select: , yes it works the same... Collection >> select: aBlock | newCollection | newCollection := self copyEmpty. self do: [ :each | (aBlock value: each) ifTrue: [ newCollection add: each ]]. ^newCollection cheers -ben

Sept. 10, 2018

Re: [Pharo-users] legitimate values for ZnClient>>accept:

by Sven Van Caekenberghe

Ben, > On 10 Sep 2018, at 20:36, Ben Coman <btc(a)openinworld.com> wrote: > > Hi Sven, > > I had a sample http request specified to have ```Accept-Encoding: gzip``` > and too a guess the following would work... ```client := ZnClient new accept: 'gzip' ``` > but it doesn't since ZnClient>>accept: > effectively does ``` 'gzip' asZnMimeType ``` > which expects the string to contain a forward-slash > > However this page seems to indicate no slash is required... > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding > > If I call ```client request setAccept: 'gzip' ``` > I am able to match what is expected (checked with WireShark) > but I'm not sure the sample I was provided is legit or I'm doing something wrong > > cheers -ben You seem to be confusing two different headers, Accept and Accept-Encoding (there are many more: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields) #accept: does indeed take a mime-type as argument, as it should. I think you are looking for #setAcceptEncodingGzip Sven

Sept. 10, 2018

Query on Pharo syntax

by PBKResearch

Hi All This is an idiot question, I should know the answer, but I have looked around and can't find relevant documentation. I'm not asking for a full answer, just a pointer as to where to start looking. I have seen from examples in this forum that an expression like the following: paras collect: [para| para prettyPrinted] can be written more concisely as: paras collect: #prettyPrinted which obviously works when I try it. It doesn't seem to fit in with the definition of #collect:, which requires a block as argument. Where can I find the relevant definition, either in method comments or in some general manual? Can the notation be extended, for example to #select: - obviously with an argument which returns a Boolean? Can it be used with a method which requires an argument, e.g. as myArray collect: (#myMethod: arg)? Are there any other extensions? Any help gratefully received. Peter Kenny

Sept. 10, 2018

legitimate values for ZnClient>>accept:

by Ben Coman

Hi Sven, I had a sample http request specified to have ```Accept-Encoding: gzip``` and too a guess the following would work... ```client := ZnClient new accept: 'gzip' ``` but it doesn't since ZnClient>>accept: effectively does ``` 'gzip' asZnMimeType ``` which expects the string to contain a forward-slash However this page seems to indicate no slash is required... https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding If I call ```client request setAccept: 'gzip' ``` I am able to match what is expected (checked with WireShark) but I'm not sure the sample I was provided is legit or I'm doing something wrong cheers -ben

Sept. 10, 2018

Re: [Pharo-users] [Esug-list] Internet of Things in Smalltalk - meeting proposal

by tesonep＠gmail.com

Nice idea. I will try to be there. On Mon, 10 Sep 2018, 16:09 CÃ©drick BÃ©ler, <cdrick65(a)gmail.com> wrote: > Hi, > > We will have a meeting Tuesday afternoon on IoT at esug. > > More info later to see how we organize that. > > Should be after Â« show us your project Â» around 5 or 6 am. > > More info later especially on where the meeting will take place (might be > around the beach). > > See you later for those interested (maybe answer there so that we can > count and find an appropriate place). > > Cheers, > > Cedrick > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 10, 2018

Re: [Pharo-users] Internet of Things in Smalltalk - meeting proposal

by Guillermo Polito

I'll be there :) On Mon, Sep 10, 2018 at 4:09 PM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi, > > We will have a meeting Tuesday afternoon on IoT at esug. > > More info later to see how we organize that. > > Should be after Â« show us your project Â» around 5 or 6 am. > > More info later especially on where the meeting will take place (might be > around the beach). > > See you later for those interested (maybe answer there so that we can > count and find an appropriate place). > > Cheers, > > Cedrick > -- 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

Sept. 10, 2018

Internet of Things in Smalltalk - meeting proposal

by CÃ©drick BÃ©ler

Hi, We will have a meeting Tuesday afternoon on IoT at esug. More info later to see how we organize that. Should be after Â« show us your project Â» around 5 or 6 am. More info later especially on where the meeting will take place (might be around the beach). See you later for those interested (maybe answer there so that we can count and find an appropriate place). Cheers, Cedrick

Sept. 10, 2018

Re: [Pharo-users] ZnURL and parsing URL with diacritics

by Sven Van Caekenberghe

It would probably help if you gave a real example, a REST call that returns something (presumable JSON or XML) that contains a URL that is problematic. FWIW, the following do also work ('https://en.wikipedia.org/wiki/' , 'ÄeskÃ¡ republika' urlEncoded) asUrl. ('https://en.wikipedia.org/wiki/' , 'ÄeskÃ¡ republika' urlEncoded) asUrl retrieveContents. > On 10 Sep 2018, at 14:16, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-users] ZnURL and parsing URL with diacritics > Date: 10 September 2018 at 14:16:53 GMT+2 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > OK. Thanks for examples. But in my case, the bad URL (with diacritics) comes directly from the Zomato.com REST API (they probably do not read specs), so I'll end up with a few "hacks" with strings. > > pf > > >> Hi, >> >>> On 10 Sep 2018, at 12:53, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >>> >>> Hi Petr >>> >>> I have used #urlEncoded in the past, with success, to deal with German umlauts. The secret is to urlEncode just the part containing the diacritics. If you encode the whole url, the slashes are encoded, and this confuses Zinc, which segments the url before decoding. >>> >>> So I would expect you to be able to read your file with: >>> >>> ZnEasy get: 'http://domain.com/â,âÄÅ¡ÄÃ½Å¾.html' urlEncoded. >>> >>> However, this also fails with âASCII character expectedâ, and I canât understand why. The debug trace has too many levels for me to understand. Zinc is evidently getting in a mess trying to decode the urlEncoded string, but if we try: >>> >>> âÄÅ¡ÄÃ½Å¾.html' urlEncoded urlDecoded >>> >>> as a separate operation, it works OK. >>> >>> I think only Sven can explain this for you. >> >> The external representation of a URL with special characters is not the same as what an address bar or browser search field accepts. The latter is quite intelligent and accepts much broader input. >> >> ZnUrl parses the official external representation according to the spec. >> >> Internally, ZnUrl represents all components as resolved strings. The solution is to construct difficult/special URLs by hand. >> >> Here is an example: let's say we want to access the English Wikipedia page of the Czech Republic (the country) using its native name 'ÄeskÃ¡ republika' (which is not only non-ASCII, but non-Latin1 as well, so it needs a WideString and UTF-8 encoding). >> >> Here is one way to construct such a string. >> >> ZnUrl new >> scheme: #http; >> host: 'en.wikipedia.org'; >> addPathSegment: 'wiki'; >> addPathSegment: 'ÄeskÃ¡ republika'; >> yourself. >> >> Which gives a URL with the following external representation: >> >> http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika >> >> This can be parsed without problems. >> >> 'http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika' asUrl. >> >> You can send #retrieveContents to a URL to actually fetch it. >> >> ZnUrl new >> scheme: #http; >> host: 'en.wikipedia.org'; >> addPathSegment: 'wiki'; >> addPathSegment: 'ÄeskÃ¡ republika'; >> retrieveContents. >> >> Or you could use the url in a ZnClient object. >> >> BTW, there are many ways to construct URLs, I would maybe do the following. >> >> 'https://en.wikipedia.org/wiki' asUrl addPathSegment: 'ÄeskÃ¡ republika'; yourself. >> >> Or something like >> >> ZnClient new >> url: 'https://en.wikipedia.org/wiki'; >> addPathSegment: 'ÄeskÃ¡ republika'; >> get. >> >> HTH, >> >> Sven >> >>> HTH >>> >>> Peter Kenny >>> >>> >>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Petr Fischer via Pharo-users >>> Sent: 10 September 2018 10:07 >>> To: pharo-users(a)lists.pharo.org >>> Cc: Petr Fischer <petr.fischer(a)me.com> >>> Subject: [Pharo-users] ZnURL and parsing URL with diacritics >>> >>> Hello, >>> >>> when I try to parse this URL asUrl, error "ZnCharacterEncodingError: ASCII character expected" occurs: >>> >>> 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' asUrl. >>> >>> this also does not work: >>> >>> ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' >>> >>> How to solve this? In the web browser, URL with diacritics is OK. >>> >>> I tried also this: >>> >>> ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' urlEncoded. >>> >>> but this cripples the whole URL. >>> >>> Thanks! Petr Fischer >> >> > > >

Sept. 10, 2018

Re: [Pharo-users] ZnURL and parsing URL with diacritics

by Petr Fischer

OK. Thanks for examples. But in my case, the bad URL (with diacritics) comes directly from the Zomato.com REST API (they probably do not read specs), so I'll end up with a few "hacks" with strings. pf > Hi, > > > On 10 Sep 2018, at 12:53, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > > > Hi Petr > > > > I have used #urlEncoded in the past, with success, to deal with German umlauts. The secret is to urlEncode just the part containing the diacritics. If you encode the whole url, the slashes are encoded, and this confuses Zinc, which segments the url before decoding. > > > > So I would expect you to be able to read your file with: > > > > ZnEasy get: 'http://domain.com/â,âÄÅ¡ÄÃ½Å¾.html' urlEncoded. > > > > However, this also fails with âASCII character expectedâ, and I canât understand why. The debug trace has too many levels for me to understand. Zinc is evidently getting in a mess trying to decode the urlEncoded string, but if we try: > > > > âÄÅ¡ÄÃ½Å¾.html' urlEncoded urlDecoded > > > > as a separate operation, it works OK. > > > > I think only Sven can explain this for you. > > The external representation of a URL with special characters is not the same as what an address bar or browser search field accepts. The latter is quite intelligent and accepts much broader input. > > ZnUrl parses the official external representation according to the spec. > > Internally, ZnUrl represents all components as resolved strings. The solution is to construct difficult/special URLs by hand. > > Here is an example: let's say we want to access the English Wikipedia page of the Czech Republic (the country) using its native name 'ÄeskÃ¡ republika' (which is not only non-ASCII, but non-Latin1 as well, so it needs a WideString and UTF-8 encoding). > > Here is one way to construct such a string. > > ZnUrl new > scheme: #http; > host: 'en.wikipedia.org'; > addPathSegment: 'wiki'; > addPathSegment: 'ÄeskÃ¡ republika'; > yourself. > > Which gives a URL with the following external representation: > > http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika > > This can be parsed without problems. > > 'http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika' asUrl. > > You can send #retrieveContents to a URL to actually fetch it. > > ZnUrl new > scheme: #http; > host: 'en.wikipedia.org'; > addPathSegment: 'wiki'; > addPathSegment: 'ÄeskÃ¡ republika'; > retrieveContents. > > Or you could use the url in a ZnClient object. > > BTW, there are many ways to construct URLs, I would maybe do the following. > > 'https://en.wikipedia.org/wiki' asUrl addPathSegment: 'ÄeskÃ¡ republika'; yourself. > > Or something like > > ZnClient new > url: 'https://en.wikipedia.org/wiki'; > addPathSegment: 'ÄeskÃ¡ republika'; > get. > > HTH, > > Sven > > > HTH > > > > Peter Kenny > > > > > > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Petr Fischer via Pharo-users > > Sent: 10 September 2018 10:07 > > To: pharo-users(a)lists.pharo.org > > Cc: Petr Fischer <petr.fischer(a)me.com> > > Subject: [Pharo-users] ZnURL and parsing URL with diacritics > > > > Hello, > > > > when I try to parse this URL asUrl, error "ZnCharacterEncodingError: ASCII character expected" occurs: > > > > 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' asUrl. > > > > this also does not work: > > > > ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' > > > > How to solve this? In the web browser, URL with diacritics is OK. > > > > I tried also this: > > > > ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' urlEncoded. > > > > but this cripples the whole URL. > > > > Thanks! Petr Fischer > >

Sept. 10, 2018

Re: [Pharo-users] ZnURL and parsing URL with diacritics

by Sven Van Caekenberghe

Hi, > On 10 Sep 2018, at 12:53, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Hi Petr > > I have used #urlEncoded in the past, with success, to deal with German umlauts. The secret is to urlEncode just the part containing the diacritics. If you encode the whole url, the slashes are encoded, and this confuses Zinc, which segments the url before decoding. > > So I would expect you to be able to read your file with: > > ZnEasy get: 'http://domain.com/â,âÄÅ¡ÄÃ½Å¾.html' urlEncoded. > > However, this also fails with âASCII character expectedâ, and I canât understand why. The debug trace has too many levels for me to understand. Zinc is evidently getting in a mess trying to decode the urlEncoded string, but if we try: > > âÄÅ¡ÄÃ½Å¾.html' urlEncoded urlDecoded > > as a separate operation, it works OK. > > I think only Sven can explain this for you. The external representation of a URL with special characters is not the same as what an address bar or browser search field accepts. The latter is quite intelligent and accepts much broader input. ZnUrl parses the official external representation according to the spec. Internally, ZnUrl represents all components as resolved strings. The solution is to construct difficult/special URLs by hand. Here is an example: let's say we want to access the English Wikipedia page of the Czech Republic (the country) using its native name 'ÄeskÃ¡ republika' (which is not only non-ASCII, but non-Latin1 as well, so it needs a WideString and UTF-8 encoding). Here is one way to construct such a string. ZnUrl new scheme: #http; host: 'en.wikipedia.org'; addPathSegment: 'wiki'; addPathSegment: 'ÄeskÃ¡ republika'; yourself. Which gives a URL with the following external representation: http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika This can be parsed without problems. 'http://en.wikipedia.org/wiki/%C4%8Cesk%C3%A1%20republika' asUrl. You can send #retrieveContents to a URL to actually fetch it. ZnUrl new scheme: #http; host: 'en.wikipedia.org'; addPathSegment: 'wiki'; addPathSegment: 'ÄeskÃ¡ republika'; retrieveContents. Or you could use the url in a ZnClient object. BTW, there are many ways to construct URLs, I would maybe do the following. 'https://en.wikipedia.org/wiki' asUrl addPathSegment: 'ÄeskÃ¡ republika'; yourself. Or something like ZnClient new url: 'https://en.wikipedia.org/wiki'; addPathSegment: 'ÄeskÃ¡ republika'; get. HTH, Sven > HTH > > Peter Kenny > > > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Petr Fischer via Pharo-users > Sent: 10 September 2018 10:07 > To: pharo-users(a)lists.pharo.org > Cc: Petr Fischer <petr.fischer(a)me.com> > Subject: [Pharo-users] ZnURL and parsing URL with diacritics > > Hello, > > when I try to parse this URL asUrl, error "ZnCharacterEncodingError: ASCII character expected" occurs: > > 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' asUrl. > > this also does not work: > > ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' > > How to solve this? In the web browser, URL with diacritics is OK. > > I tried also this: > > ZnEasy get: 'http://domain.com/ÄÅ¡ÄÃ½Å¾.html' urlEncoded. > > but this cripples the whole URL. > > Thanks! Petr Fischer

Sept. 10, 2018