- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Cryptography moved to pharo-contributions

by Norbert Hartl

> Am 11.10.2018 um 14:24 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > >> On 11 Oct 2018, at 14:21, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> So this is more a problem for repos that have lived a long time already on github? >> It guess it should impede someone using their account as a staging point for migrating from Smalltalkhub projects to a community github repo. >> >> Although an alternate way to consider this is that the forwarding submerges a problem to be forgotten until it causes a mystery problem later on. >> Forking the repo back into your account and deleting the "master" branch might be fail-fast way to expose and fix issues. >> (emphasis on the "might" - I'm not sure of all the trade-offs) >> >> cheers -ben >> >> On Thu, 11 Oct 2018 at 14:36, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> Well, you can but then the access is not forwarded anymore to the repo youâve transferred. Transferring and forking makes everyone link something they maybe donât want. Transferring and creating a new one with the same name brings all request to the former to your new repo which is unlikely to be wanted. > > Yes, but you can :) Dude, you need to write that in channel #nitpick Oh, there is no channel with that name? Never mind! > And if someone points to you copy, he will still have it (just with the possibility of not fetching an updated version). > > But he can always fix that by adding the new remote and pulling from there :) > Iâm not talking about the ability of us. Iâm pretty sure everyone can grasp that. Iâm talking about invisible change with side effect. I care about such things :P Norbert > Esteban > >> >> Norbert >> >> > Am 11.10.2018 um 07:49 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> > >> > Why not? >> > >> >> On 10 Oct 2018, at 17:55, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> >> >> No, that you cannot >> >> >> >>> Am 10.10.2018 um 16:36 schrieb Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: >> >>> >> >>> NorbertHartl wrote >> >>>> The rest is provided by github as long as you do not create a new >> >>>> repository with the same name. >> >>> >> >>> Can you still fork the transferred repo in your personal account? I wasn't >> >>> sure, which is why I didn't handle Artefact this way. >> >>> >> >>> >> >>> >> >>> ----- >> >>> Cheers, >> >>> Sean >> >>> -- >> >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >> >>> >> >> >> >> >> > >> > >> >> >

Oct. 11, 2018

Re: [Pharo-users] [ANN] Cryptography moved to pharo-contributions

by Esteban Lorenzano

> On 11 Oct 2018, at 14:21, Ben Coman <btc(a)openinworld.com> wrote: > > So this is more a problem for repos that have lived a long time already on github? > It guess it should impede someone using their account as a staging point for migrating from Smalltalkhub projects to a community github repo. > > Although an alternate way to consider this is that the forwarding submerges a problem to be forgotten until it causes a mystery problem later on. > Forking the repo back into your account and deleting the "master" branch might be fail-fast way to expose and fix issues. > (emphasis on the "might" - I'm not sure of all the trade-offs) > > cheers -ben > > On Thu, 11 Oct 2018 at 14:36, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > Well, you can but then the access is not forwarded anymore to the repo youâve transferred. Transferring and forking makes everyone link something they maybe donât want. Transferring and creating a new one with the same name brings all request to the former to your new repo which is unlikely to be wanted. Yes, but you can :) And if someone points to you copy, he will still have it (just with the possibility of not fetching an updated version). But he can always fix that by adding the new remote and pulling from there :) Esteban > > Norbert > > > Am 11.10.2018 um 07:49 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > > Why not? > > > >> On 10 Oct 2018, at 17:55, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> > >> No, that you cannot > >> > >>> Am 10.10.2018 um 16:36 schrieb Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > >>> > >>> NorbertHartl wrote > >>>> The rest is provided by github as long as you do not create a new > >>>> repository with the same name. > >>> > >>> Can you still fork the transferred repo in your personal account? I wasn't > >>> sure, which is why I didn't handle Artefact this way. > >>> > >>> > >>> > >>> ----- > >>> Cheers, > >>> Sean > >>> -- > >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > >>> > >> > >> > > > > > >

Oct. 11, 2018

Re: [Pharo-users] [ANN] Cryptography moved to pharo-contributions

by Ben Coman

So this is more a problem for repos that have lived a long time already on github? It guess it should impede someone using their account as a staging point for migrating from Smalltalkhub projects to a community github repo. Although an alternate way to consider this is that the forwarding submerges a problem to be forgotten until it causes a mystery problem later on. Forking the repo back into your account and deleting the "master" branch might be fail-fast way to expose and fix issues. (emphasis on the "might" - I'm not sure of all the trade-offs) cheers -ben On Thu, 11 Oct 2018 at 14:36, Norbert Hartl <norbert(a)hartl.name> wrote: > Well, you can but then the access is not forwarded anymore to the repo > youâve transferred. Transferring and forking makes everyone link something > they maybe donât want. Transferring and creating a new one with the same > name brings all request to the former to your new repo which is unlikely to > be wanted. > > Norbert > > > Am 11.10.2018 um 07:49 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > > Why not? > > > >> On 10 Oct 2018, at 17:55, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> No, that you cannot > >> > >>> Am 10.10.2018 um 16:36 schrieb Sean P. DeNigris <sean(a)clipperadams.com > >: > >>> > >>> NorbertHartl wrote > >>>> The rest is provided by github as long as you do not create a new > >>>> repository with the same name. > >>> > >>> Can you still fork the transferred repo in your personal account? I > wasn't > >>> sure, which is why I didn't handle Artefact this way. > >>> > >>> > >>> > >>> ----- > >>> Cheers, > >>> Sean > >>> -- > >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >>> > >> > >> > > > > > > >

Oct. 11, 2018

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

by Steffen MÃ¤rcker

Dear Jan, I just tried to use PP2 but ran into two issues: 1. PP2 does not load into Pharo 6.1 stable. 2. I use #- to create character classes but was not able to find the equivalent in PP2 yet. > There should be no fundamental issue with porting PP2 to VW. As far as I > know, there is an automated tool to do so, right? I am not aware of this tool. Can you give me some hints what exactly to look for? Best, Steffen On the other hand, PP > is > stable and does not change, PP2 is maintained and updated from time to > time > (mostly adding optimizations), so there might be an overhead of syncing > PP2 > to VW2. > > Cheers, > Jan > > [1]: > https://kursjan.github.io/petitparser2/pillar-book/build/Chapters/memoizati… > > On Fri, Oct 5, 2018, 13:26 Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> Hi Doru! >> >> > I assume that you tried the original PetitParser. PetitParser2 offers >> > the possibility to optimize the parser (kind of a compilation), and >> this >> > provides a significant speedup: >> > https://github.com/kursjan/petitparser2 >> > >> > Would you be interested in trying this out? >> >> Yes, I'd like to give this a shot, too. However, as far as I know, PP2 >> is >> only available for Pharo and not VW, is it? >> >> Speaking of optimizations, I also tried to use memoizing the petit >> parser. >> However, the times got worse instead of better. Is there a rule of thumb >> where to apply #memoized in a sensible way? As far as I understand, >> applying it to the root parser does not memoize subsequent parsers, does >> it? >> >> Kind regards, Steffen >>

Oct. 11, 2018

[Zinc SSO] Extended OAuth1 support

by Ioana Verebi

Jira uses OAuth1 to authenticate requests to its REST API. But it relies on "RSA-SHA1" signing for authentication, which Zinc SSO does not currently seem to support (it's only "HMAC-SHA1" which is supported). Jira also expects that the consumer secret is sent as a custom header. Are there any plans to extend Zinc SSO in these directions? Or has anyone successfully integrated Jira OAuth in a Pharo application? Thank you! Ioana

Oct. 11, 2018

Re: [Pharo-users] ZnClient 403 but 200 in Firefox

by tesonep＠gmail.com

Hi Hernan, quite interesting. I have tried with curl and it works, but with wget it doesn't work. Both using the brew versions in my OSX machine. To me, it is a problem of the headers. Cheers. On Wed, Oct 10, 2018 at 10:07 PM HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > When I visit this site http://ifconfig.me/ip using the web browser I > get the expected text output. However if I try to do it from Pharo 6.1 > (Windows 8.1) I get a 403 forbidden response using this code: > > ZnClient new > systemPolicy; > beOneShot; > accept: ZnMimeType textPlain; > timeout: 6000; > url: 'http://ifconfig.me/ip'; > get. > > 2018-09-16 03:06:18 011 Retrying ConnectionTimedOut: Cannot connect to > 153.121.72.212:80 > 2018-09-16 03:06:19 012 Connection Established ifconfig.me:80 > 153.121.72.212 288ms > 2018-09-16 03:06:19 013 Request Written a ZnRequest(GET /all.xml) 1ms > 2018-09-16 03:06:19 014 Response Read a ZnResponse(403 Forbidden > text/html;charset=iso-8859-1 209B) 318ms > 2018-09-16 03:06:19 015 GET /all.xml 403 209B 319ms > 2018-09-16 03:06:19 016 Connection Closed 153.121.72.212:80 > > In Firefox this is the output > > Request Headers Firefox: > > Host: ifconfig.me > User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:62.0) > Gecko/20100101 Firefox/62.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: en-US > Accept-Encoding: gzip, deflate > DNT: 1 > Connection: keep-alive > Upgrade-Insecure-Requests: 1 > > Response Headers Firefox: > > HTTP/1.1 200 OK > Date: Sun, 16 Sep 2018 16:47:02 GMT > Server: Apache > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 32 > Connection: close > Content-Type: text/plain > > > Any idea? > > Cheers, > > HernÃ¡n > > -- Pablo Tesone. tesonep(a)gmail.com

Oct. 11, 2018

Re: [Pharo-users] Glorp with P3

by Sven Van Caekenberghe

> On 11 Oct 2018, at 02:26, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Wed, Oct 10, 2018 at 11:12:37AM +0200, Sven Van Caekenberghe wrote: >> I know that the actual PSQL DB that I am using has all the Glorp test >> tables in it, I forgot whether that happened automatically or not. > > The Glorp test database is set up by "#GlorpDemoTablePopulatorResource > asClass invalidateSetup". In the case of Glorp-SQLite3, that step is > done by BaselineOfGlorpSQLite>>postLoadDoIt. > > Pierce Ah, thanks !

Oct. 11, 2018

Re: [Pharo-users] ZnClient 403 but 200 in Firefox

by Norbert Hartl

> Am 11.10.2018 um 02:02 schrieb Jerry Kott <jkott(a)image-ware.com>: > > A lot of thse types of services do that. Not sure why because itâs so easy to spoof anything in an HTTP(s) request... > Technically this is right. Practically you still have to know which content to provide. I use it to get rid of requests to my service. I donât have a problem with those that take the effort to figure out. These are way below 1% of all requests. Norbert > Jerry Kott > This message has been digitally signed. > PGP Fingerprint: > A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5 > > > >> On 10-10-2018, at 3:32 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >> Wow, didn't knew that someone actually could reject/allow specific UAs. >> >> Thank you Sven, >> >> Cheers, >> >> HernÃ¡n >> El miÃ©., 10 oct. 2018 a las 17:33, Sven Van Caekenberghe >> (<sven(a)stfx.eu>) escribiÃ³: >>> >>> Because they don't like Pharo or Zinc ;-) >>> >>> ZnClient new >>> systemPolicy; >>> beOneShot; >>> url: 'http://ifconfig.me/ip'; >>> accept: ZnMimeType textPlain; >>> headerAt: 'User-Agent' put: 'curl/7.54.0'; >>> get. >>> >>> Changing the User-Agent (effectively lying) works. >>> >>>> On 10 Oct 2018, at 22:02, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>>> >>>> When I visit this site http://ifconfig.me/ip using the web browser I >>>> get the expected text output. However if I try to do it from Pharo 6.1 >>>> (Windows 8.1) I get a 403 forbidden response using this code: >>>> >>>> ZnClient new >>>> systemPolicy; >>>> beOneShot; >>>> accept: ZnMimeType textPlain; >>>> timeout: 6000; >>>> url: 'http://ifconfig.me/ip'; >>>> get. >>>> >>>> 2018-09-16 03:06:18 011 Retrying ConnectionTimedOut: Cannot connect to >>>> 153.121.72.212:80 >>>> 2018-09-16 03:06:19 012 Connection Established ifconfig.me:80 >>>> 153.121.72.212 288ms >>>> 2018-09-16 03:06:19 013 Request Written a ZnRequest(GET /all.xml) 1ms >>>> 2018-09-16 03:06:19 014 Response Read a ZnResponse(403 Forbidden >>>> text/html;charset=iso-8859-1 209B) 318ms >>>> 2018-09-16 03:06:19 015 GET /all.xml 403 209B 319ms >>>> 2018-09-16 03:06:19 016 Connection Closed 153.121.72.212:80 >>>> >>>> In Firefox this is the output >>>> >>>> Request Headers Firefox: >>>> >>>> Host: ifconfig.me >>>> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:62.0) >>>> Gecko/20100101 Firefox/62.0 >>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >>>> Accept-Language: en-US >>>> Accept-Encoding: gzip, deflate >>>> DNT: 1 >>>> Connection: keep-alive >>>> Upgrade-Insecure-Requests: 1 >>>> >>>> Response Headers Firefox: >>>> >>>> HTTP/1.1 200 OK >>>> Date: Sun, 16 Sep 2018 16:47:02 GMT >>>> Server: Apache >>>> Vary: Accept-Encoding >>>> Content-Encoding: gzip >>>> Content-Length: 32 >>>> Connection: close >>>> Content-Type: text/plain >>>> >>>> >>>> Any idea? >>>> >>>> Cheers, >>>> >>>> HernÃ¡n >>>> >>> >>> >> >> >

Oct. 11, 2018

Re: [Pharo-users] ZnClient 403 but 200 in Firefox

by Norbert Hartl

It is done very often. In the past you could solve glitches between browser engines. Nowadays it is done e.g. to discover mobile clients. In one of my services the easiest to keep foreigners out was rejecting all requests which are not zinc ð Norbert > Am 11.10.2018 um 00:32 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > Wow, didn't knew that someone actually could reject/allow specific UAs. > > Thank you Sven, > > Cheers, > > HernÃ¡n > El miÃ©., 10 oct. 2018 a las 17:33, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: >> >> Because they don't like Pharo or Zinc ;-) >> >> ZnClient new >> systemPolicy; >> beOneShot; >> url: 'http://ifconfig.me/ip'; >> accept: ZnMimeType textPlain; >> headerAt: 'User-Agent' put: 'curl/7.54.0'; >> get. >> >> Changing the User-Agent (effectively lying) works. >> >>> On 10 Oct 2018, at 22:02, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> When I visit this site http://ifconfig.me/ip using the web browser I >>> get the expected text output. However if I try to do it from Pharo 6.1 >>> (Windows 8.1) I get a 403 forbidden response using this code: >>> >>> ZnClient new >>> systemPolicy; >>> beOneShot; >>> accept: ZnMimeType textPlain; >>> timeout: 6000; >>> url: 'http://ifconfig.me/ip'; >>> get. >>> >>> 2018-09-16 03:06:18 011 Retrying ConnectionTimedOut: Cannot connect to >>> 153.121.72.212:80 >>> 2018-09-16 03:06:19 012 Connection Established ifconfig.me:80 >>> 153.121.72.212 288ms >>> 2018-09-16 03:06:19 013 Request Written a ZnRequest(GET /all.xml) 1ms >>> 2018-09-16 03:06:19 014 Response Read a ZnResponse(403 Forbidden >>> text/html;charset=iso-8859-1 209B) 318ms >>> 2018-09-16 03:06:19 015 GET /all.xml 403 209B 319ms >>> 2018-09-16 03:06:19 016 Connection Closed 153.121.72.212:80 >>> >>> In Firefox this is the output >>> >>> Request Headers Firefox: >>> >>> Host: ifconfig.me >>> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:62.0) >>> Gecko/20100101 Firefox/62.0 >>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >>> Accept-Language: en-US >>> Accept-Encoding: gzip, deflate >>> DNT: 1 >>> Connection: keep-alive >>> Upgrade-Insecure-Requests: 1 >>> >>> Response Headers Firefox: >>> >>> HTTP/1.1 200 OK >>> Date: Sun, 16 Sep 2018 16:47:02 GMT >>> Server: Apache >>> Vary: Accept-Encoding >>> Content-Encoding: gzip >>> Content-Length: 32 >>> Connection: close >>> Content-Type: text/plain >>> >>> >>> Any idea? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >> >> >

Oct. 11, 2018

Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

by Norbert Hartl

I really like when I read projects are safed from smalltalkhub. It makes everything so much more manageable > Am 10.10.2018 um 16:59 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> On Wed, Oct 10, 2018 at 4:37 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Sean P. DeNigris wrote >>> I migrated the >>> repo with the hopes that someone in the pharo-contributions organization >>> will copy it. >>> [snip] >>> https://github.com/seandenigris/Artefact >> >> Bump. Anyone? I will do it if you add me to pharo-contributionsâ¦ >> > > Hi Sean, > > Apparently we both moved Artefact to github at the same time. > > This repo contains the project: https://github.com/pharo-contributions/Artefact > > It has: > - Migrated sources > - A new Baseline > - I also moved Stylesheet to github > - I updated the dependency to Units to point to the one of Zweidenker > - Guille fixed the streams problem > > Now we have only one Pharo 7 test failing. I wanted to correct it > before releasing. > >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Oct. 11, 2018