September 2018 - Pharo-users

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Tudor Girba

Hi, Thanks for trying. The examples are found in methods annotated with <gtExample>. What do you mean that "Several examples are not actionableâ? Could you provide examples of that to find out what the problem is? Cheers, Doru > On Sep 15, 2018, at 10:10 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > Play a bit with the examples. Help me to write some code in the playground > > Several examples are not actionable and seems to be part of some things > bigger. Am I missing somethings? > > I see this pragma <script: > Is it intended to be search-able from the > finder or another tool? > > By the way, once Bloc was installed on the image, the image does not > save. Crash dump included. > > Hilaire > > > Le 13/09/2018 Ã 18:35, Peter Uhnak a Ã©crit : >> and then in the image itself there is a "Bloc-Examples" package that >> contains hundreds (thousands?) of examples. >> > > -- > Dr. Geo > http://drgeo.eu > > > -- www.feenk.com "Don't give to get. Just give."

Sept. 16, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Juraj Kubelka

Hi Hilaire, We are aware of this issue. Current workaround is to save and then quit without saving. Juraj > On Sep 15, 2018, at 14:27, Hilaire <hilaire(a)drgeo.eu> wrote: > > > > Le 15/09/2018 Ã 10:10, Hilaire a Ã©crit : >> By the way, once Bloc was installed on the image, the image does not >> save. Crash dump included. > > -- > Dr. Geo > http://drgeo.eu > > <crash.dmp>

Sept. 15, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Hilaire

Le 15/09/2018 Ã 10:10, Hilaire a Ã©critÂ : > By the way, once Bloc was installed on the image, the image does not > save. Crash dump included. -- Dr. Geo http://drgeo.eu

Sept. 15, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Hilaire

Play a bit with the examples. Help me to write some code in the playground Several examples are not actionable and seems to be part of some things bigger. Am I missing somethings? I see this pragma <script: > Is it intended to be search-able from the finder or another tool? By the way, once Bloc was installed on the image, the image does not save. Crash dump included. Hilaire Le 13/09/2018 Ã 18:35, Peter Uhnak a Ã©critÂ : > and then in the image itself there is a "Bloc-Examples" package that > contains hundreds (thousands?) of examples. > -- Dr. Geo http://drgeo.eu

Sept. 15, 2018

Where is the Software update menu in Pharo 7.0

by Rene Paul Mages (ramix)

Hi all, This is probably an idiot interrogation : I can't see the "Software update" menu http://ramix.org/pharo/version-7.0/pharo.7.0.png My Machine is running Linux Mint 18.3 "Sylvia" Cinnamon (64 bits) and I am using the following Pharo package : PharoLauncher-linux-1.4-x64.zip Thanks for your help. -- All the best. Rene Paul Mages ( GnuPG_key 0x9840A6F7 ) http://renemages.wordpress.com/smalltalk/pharo/ http://www.linux-azur.org/ramix http://blog.pharo.fr

Sept. 15, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Hilaire

Thanks. Hilaire Le 13/09/2018 Ã 18:35, Peter Uhnak a Ã©critÂ : > Hi, > > you can start with the Bloc > bookletÂ http://files.pharo.org/books-pdfs/booklet-Bloc/BLOCDRAFT.pdf > ... it is probably a bit outdated, but I think the API hasn't changed > that much. > and then in the image itself there is a "Bloc-Examples" package that > contains hundreds (thousands?) of examples. > > Peter -- Dr. Geo http://drgeo.eu

Sept. 13, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Peter Uhnak

Hi, you can start with the Bloc booklet http://files.pharo.org/books-pdfs/booklet-Bloc/BLOCDRAFT.pdf ... it is probably a bit outdated, but I think the API hasn't changed that much. and then in the image itself there is a "Bloc-Examples" package that contains hundreds (thousands?) of examples. Peter On Thu, Sep 13, 2018 at 2:58 PM Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > Is there any document to get start with bloc and gtoolkit? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

Sept. 13, 2018

To get started with Gtoolkit and bloc

by Hilaire

Hi, Is there any document to get start with bloc and gtoolkit? Thanks Hilaire -- Dr. Geo http://drgeo.eu

Sept. 13, 2018

Dynabook and competences

by Hilaire

Hi, Some though on the teaching by competence pedagogic approach and the Dynabook: http://blog.drgeo.eu/post/2018/Teaching-by-competences Hilaire -- Dr. Geo http://drgeo.eu

Sept. 12, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Paul DeBruicker

No. I thought I was using Pharo 6.1 but in the "About..." menu item it shows: Pharo 6.0 Latest update: #60540 The ZincHTTPComponents version in that image is TheIntegrator.461 Anyway. I'm glad its fixed in the more recent version. Apologies for the noise. Sven Van Caekenberghe-2 wrote >> On 11 Sep 2018, at 18:55, Paul DeBruicker < > pdebruic@ > > wrote: >> >> Seems like the invalid date could be anything and the spec gives '0' as >> the >> example invalid date. >> >> >> I'm not using #expiresTimeStamp or #parseHttpDate: explicitly its just >> that >> the GET request was failing on that date parsing error, when checking if >> the >> Cookie was expired. >> >> >> I think your proposed ZnCookie>>#isExpired is the right way to go e.g. > > OK, but that is already in the code. I am looking at > Zinc-HTTP-SvenVanCaekenberghe.475 ... is that not what you are seeing ? > >> isExpired >> | expirationTimeStamp | >> (self hasAttribute: 'expire') ifFalse: [ ^ false ]. >> [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ >> false ]. >> "note that max-age (#maxage) is not used" >> ^ expirationTimeStamp asUTC < DateAndTime now asUTC >> >> >> >> >> >> >> Sven Van Caekenberghe-2 wrote >>> Hi Paul, >>> >>>> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER < >> >>> pdebruic@ >> >>> > wrote: >>>> >>>> Hi Sven - >>>> >>>> This is in Pharo 6.1. >>>> >>>> There is an API I'm using which sometimes returns a string only >>>> containing a single instance of the number 0 in the "Expires" field, so >>>> the #expiresTimeStamp method sends that to #parseHttpDate: and since it >>>> can't be parsed into a date an error is thrown. Seems like Zinc should >>>> be able to handle that based on the spec here: >>>> https://tools.ietf.org/html/rfc7234#section-5.3 >>>> >>>> >>>> Would you rather I changed the implementation of parseHttpDate: to add >>>> an >>>> empty check on the parsed tokens e.g. >>> >>> IIRC some months ago, there were some changes to this area, but I forgot >>> the details and the before state. >>> >>> Anyway, reading RFC7234's section that you reference, maybe we do need >>> to >>> make another change, but I am not sure. >>> >>> Let's start by explaining what there is today and why it is like that: >>> #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by >>> design), while #isExpired is the more high level access method. >>> >>> Consider: >>> >>> (ZnCookie name: 'foo' value: '100') isExpired. >>> >>> => false >>> >>> ZnUtils parseHttpDate: '0'. >>> >>> => Boom >>> >>> (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. >>> >>> => Boom >>> >>> (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. >>> >>> => false >>> >>> Could you use #isExpired and does it do what you want/expect ? >>> >>> Reading the spec again, I am not 100% sure about the error case >>> (existing >>> but zero or wrong Expires header), maybe that should be true instead of >>> false. >>> >>> isExpired >>> | expirationTimeStamp | >>> (self hasAttribute: 'expire') ifFalse: [ ^ false ]. >>> [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ >>> false >>> ]. >>> "note that max-age (#maxage) is not used" >>> ^ expirationTimeStamp asUTC < DateAndTime now asUTC >>> >>> What do you think ? >>> Anyone else with an opinion ? >>> >>> Sven >>> >>>> parseHttpDate: string >>>> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >>>> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >>>> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >>>> >>>> | tokens day month year hour minute second months map yearToken | >>>> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >>>> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >>>> >>>> ... >>>> >>>> >>>> Or add a string size guard check in #expiresTimeStamp ? e.g. >>>> >>>> expiresTimeStamp >>>> self expires >>>> ifNil: [ ^ DateAndTime now + 1 day ] >>>> ifNotNil: [ :exp | >>>> exp size = 1 >>>> ifTrue: [ ^ DateAndTime epoch ]. >>>> ^ ZnUtils parseHttpDate: exp ] >>>> >>>> >>>> Thanks >>>> >>>> Paul >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

> On 11 Sep 2018, at 18:55, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Seems like the invalid date could be anything and the spec gives '0' as the > example invalid date. > > > I'm not using #expiresTimeStamp or #parseHttpDate: explicitly its just that > the GET request was failing on that date parsing error, when checking if the > Cookie was expired. > > > I think your proposed ZnCookie>>#isExpired is the right way to go e.g. OK, but that is already in the code. I am looking at Zinc-HTTP-SvenVanCaekenberghe.475 ... is that not what you are seeing ? > isExpired > | expirationTimeStamp | > (self hasAttribute: 'expire') ifFalse: [ ^ false ]. > [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ > false ]. > "note that max-age (#maxage) is not used" > ^ expirationTimeStamp asUTC < DateAndTime now asUTC > > > > > > > Sven Van Caekenberghe-2 wrote >> Hi Paul, >> >>> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER < > >> pdebruic@ > >> > wrote: >>> >>> Hi Sven - >>> >>> This is in Pharo 6.1. >>> >>> There is an API I'm using which sometimes returns a string only >>> containing a single instance of the number 0 in the "Expires" field, so >>> the #expiresTimeStamp method sends that to #parseHttpDate: and since it >>> can't be parsed into a date an error is thrown. Seems like Zinc should >>> be able to handle that based on the spec here: >>> https://tools.ietf.org/html/rfc7234#section-5.3 >>> >>> >>> Would you rather I changed the implementation of parseHttpDate: to add an >>> empty check on the parsed tokens e.g. >> >> IIRC some months ago, there were some changes to this area, but I forgot >> the details and the before state. >> >> Anyway, reading RFC7234's section that you reference, maybe we do need to >> make another change, but I am not sure. >> >> Let's start by explaining what there is today and why it is like that: >> #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by >> design), while #isExpired is the more high level access method. >> >> Consider: >> >> (ZnCookie name: 'foo' value: '100') isExpired. >> >> => false >> >> ZnUtils parseHttpDate: '0'. >> >> => Boom >> >> (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. >> >> => Boom >> >> (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. >> >> => false >> >> Could you use #isExpired and does it do what you want/expect ? >> >> Reading the spec again, I am not 100% sure about the error case (existing >> but zero or wrong Expires header), maybe that should be true instead of >> false. >> >> isExpired >> | expirationTimeStamp | >> (self hasAttribute: 'expire') ifFalse: [ ^ false ]. >> [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false >> ]. >> "note that max-age (#maxage) is not used" >> ^ expirationTimeStamp asUTC < DateAndTime now asUTC >> >> What do you think ? >> Anyone else with an opinion ? >> >> Sven >> >>> parseHttpDate: string >>> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >>> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >>> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >>> >>> | tokens day month year hour minute second months map yearToken | >>> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >>> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >>> >>> ... >>> >>> >>> Or add a string size guard check in #expiresTimeStamp ? e.g. >>> >>> expiresTimeStamp >>> self expires >>> ifNil: [ ^ DateAndTime now + 1 day ] >>> ifNotNil: [ :exp | >>> exp size = 1 >>> ifTrue: [ ^ DateAndTime epoch ]. >>> ^ ZnUtils parseHttpDate: exp ] >>> >>> >>> Thanks >>> >>> Paul > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Paul DeBruicker

Seems like the invalid date could be anything and the spec gives '0' as the example invalid date. I'm not using #expiresTimeStamp or #parseHttpDate: explicitly its just that the GET request was failing on that date parsing error, when checking if the Cookie was expired. I think your proposed ZnCookie>>#isExpired is the right way to go e.g. isExpired | expirationTimeStamp | (self hasAttribute: 'expire') ifFalse: [ ^ false ]. [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. "note that max-age (#maxage) is not used" ^ expirationTimeStamp asUTC < DateAndTime now asUTC Sven Van Caekenberghe-2 wrote > Hi Paul, > >> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER < > pdebruic@ > > wrote: >> >> Hi Sven - >> >> This is in Pharo 6.1. >> >> There is an API I'm using which sometimes returns a string only >> containing a single instance of the number 0 in the "Expires" field, so >> the #expiresTimeStamp method sends that to #parseHttpDate: and since it >> can't be parsed into a date an error is thrown. Seems like Zinc should >> be able to handle that based on the spec here: >> https://tools.ietf.org/html/rfc7234#section-5.3 >> >> >> Would you rather I changed the implementation of parseHttpDate: to add an >> empty check on the parsed tokens e.g. > > IIRC some months ago, there were some changes to this area, but I forgot > the details and the before state. > > Anyway, reading RFC7234's section that you reference, maybe we do need to > make another change, but I am not sure. > > Let's start by explaining what there is today and why it is like that: > #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by > design), while #isExpired is the more high level access method. > > Consider: > > (ZnCookie name: 'foo' value: '100') isExpired. > > => false > > ZnUtils parseHttpDate: '0'. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. > > => false > > Could you use #isExpired and does it do what you want/expect ? > > Reading the spec again, I am not 100% sure about the error case (existing > but zero or wrong Expires header), maybe that should be true instead of > false. > > isExpired > | expirationTimeStamp | > (self hasAttribute: 'expire') ifFalse: [ ^ false ]. > [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false > ]. > "note that max-age (#maxage) is not used" > ^ expirationTimeStamp asUTC < DateAndTime now asUTC > > What do you think ? > Anyone else with an opinion ? > > Sven > >> parseHttpDate: string >> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >> >> | tokens day month year hour minute second months map yearToken | >> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >> >> ... >> >> >> Or add a string size guard check in #expiresTimeStamp ? e.g. >> >> expiresTimeStamp >> self expires >> ifNil: [ ^ DateAndTime now + 1 day ] >> ifNotNil: [ :exp | >> exp size = 1 >> ifTrue: [ ^ DateAndTime epoch ]. >> ^ ZnUtils parseHttpDate: exp ] >> >> >> Thanks >> >> Paul -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

Yes, that is how I read it now too. > On 11 Sep 2018, at 14:55, Erik Stel <erik.stel(a)gmail.com> wrote: > > Sven, > > According to the spec "0" or invalid date formats should mean 'isExpired' > (as you already suggested): > A cache recipient MUST interpret invalid date formats, especially the > value "0", as representing a time in the past (i.e., "already > expired"). > > So I would vote for having 'isExpired' answer 'true' in those cases. Having > 'expiresTimeStamp' throw an error seems reasonable. The sender can catch the > exception. > > Cheers, > Erik > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

> On 11 Sep 2018, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Paul, > >> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: >> >> Hi Sven - >> >> This is in Pharo 6.1. >> >> There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 >> >> >> Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. > > IIRC some months ago, there were some changes to this area, but I forgot the details and the before state. > > Anyway, reading RFC7234's section that you reference, maybe we do need to make another change, but I am not sure. > > Let's start by explaining what there is today and why it is like that: #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by design), while #isExpired is the more high level access method. > > Consider: > > (ZnCookie name: 'foo' value: '100') isExpired. > > => false > > ZnUtils parseHttpDate: '0'. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. > > => false > > Could you use #isExpired and does it do what you want/expect ? > > Reading the spec again, I am not 100% sure about the error case (existing but zero or wrong Expires header), maybe that should be true instead of false. > > isExpired > | expirationTimeStamp | > (self hasAttribute: 'expire') ifFalse: [ ^ false ]. > [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. > "note that max-age (#maxage) is not used" > ^ expirationTimeStamp asUTC < DateAndTime now asUTC > > What do you think ? > Anyone else with an opinion ? I just noticed that we are mixing request/response http headers with cookies, which might not be a good idea. > Sven > >> parseHttpDate: string >> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >> >> | tokens day month year hour minute second months map yearToken | >> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >> >> ... >> >> >> Or add a string size guard check in #expiresTimeStamp ? e.g. >> >> expiresTimeStamp >> self expires >> ifNil: [ ^ DateAndTime now + 1 day ] >> ifNotNil: [ :exp | >> exp size = 1 >> ifTrue: [ ^ DateAndTime epoch ]. >> ^ ZnUtils parseHttpDate: exp ] >> >> >> Thanks >> >> Paul

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Erik Stel

Sven, According to the spec "0" or invalid date formats should mean 'isExpired' (as you already suggested): A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired"). So I would vote for having 'isExpired' answer 'true' in those cases. Having 'expiresTimeStamp' throw an error seems reasonable. The sender can catch the exception. Cheers, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

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

by Erik Stel

Check out the following info: https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier <https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier> The REST API might be answering an IRI instead of an URI in which case it might not be faulty after all (I did not check the API myself). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

Hi Paul, > On 11 Sep 2018, at 06:02, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > > Hi Sven - > > This is in Pharo 6.1. > > There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 > > > Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. IIRC some months ago, there were some changes to this area, but I forgot the details and the before state. Anyway, reading RFC7234's section that you reference, maybe we do need to make another change, but I am not sure. Let's start by explaining what there is today and why it is like that: #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by design), while #isExpired is the more high level access method. Consider: (ZnCookie name: 'foo' value: '100') isExpired. => false ZnUtils parseHttpDate: '0'. => Boom (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. => Boom (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. => false Could you use #isExpired and does it do what you want/expect ? Reading the spec again, I am not 100% sure about the error case (existing but zero or wrong Expires header), maybe that should be true instead of false. isExpired | expirationTimeStamp | (self hasAttribute: 'expire') ifFalse: [ ^ false ]. [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. "note that max-age (#maxage) is not used" ^ expirationTimeStamp asUTC < DateAndTime now asUTC What do you think ? Anyone else with an opinion ? Sven > parseHttpDate: string > "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." > "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." > "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." > > | tokens day month year hour minute second months map yearToken | > string size = 1 ifTrue:[ ^DateAndTime epoch ]. > tokens := (string findTokens: #( $ $- $: $, )) allButFirst. > > ... > > > Or add a string size guard check in #expiresTimeStamp ? e.g. > > expiresTimeStamp > self expires > ifNil: [ ^ DateAndTime now + 1 day ] > ifNotNil: [ :exp | > exp size = 1 > ifTrue: [ ^ DateAndTime epoch ]. > ^ ZnUtils parseHttpDate: exp ] > > > Thanks > > Paul

Sept. 11, 2018

ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by PAUL DEBRUICKER

Hi Sven - This is in Pharo 6.1. There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. parseHttpDate: string "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." | tokens day month year hour minute second months map yearToken | string size = 1 ifTrue:[ ^DateAndTime epoch ]. tokens := (string findTokens: #( $ $- $: $, )) allButFirst. ... Or add a string size guard check in #expiresTimeStamp ? e.g. expiresTimeStamp self expires ifNil: [ ^ DateAndTime now + 1 day ] ifNotNil: [ :exp | exp size = 1 ifTrue: [ ^ DateAndTime epoch ]. ^ ZnUtils parseHttpDate: exp ] Thanks Paul

Sept. 11, 2018

Re: [Pharo-users] Query on Pharo syntax

by Ben Coman

Its a very interesting and elegant aspect of Pharo and I'm sure there are others at different parts of their journey learning Pharo who learnt something new from your question. cheers -ben On Tue, 11 Sep 2018 at 03:13, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Thanks Ben â itâs all clear now. Thanks also to Esteban, who spared my > blushes by answering direct! > > Peter Kenny > > > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Ben > Coman > *Sent:* 10 September 2018 19:56 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Query on Pharo syntax > > > > > > 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. 11, 2018

Re: [Pharo-users] Query on Pharo syntax

by PBKResearch

Thanks Ben â itâs all clear now. Thanks also to Esteban, who spared my blushes by answering direct! Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Ben Coman Sent: 10 September 2018 19:56 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Query on Pharo syntax On Tue, 11 Sep 2018 at 02:44, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@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 Ben Coman

On Tue, 11 Sep 2018 at 02:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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, Indeed. I plead domestic blindness. > 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 > Yes, thx. cheers -ben

Sept. 10, 2018

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