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

Re: [Pharo-users] Pharo 7 proxy problem

by Vincent.Blondeau＠lamresearch.com

Thank you! Vincent From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 12:10 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Pharo 7 proxy problem Done! https://pharo.fogbugz.com/f/cases/22177/Pharo-7-proxy-problem<https://urldefense.proofpoint.com/v2/url?u=https-3A__pharo.fogbugz.com_f_ca…> On Tue, Jun 19, 2018 at 3:55 PM, <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: Great! Could you create a bug report with the stack trace here: https://pharo.fogbugz.com/f/cases/new<https://urldefense.proofpoint.com/v2/url?u=https-3A__pharo.fogbugz.com_f_ca…> ? It should be an issue with the socket library under x64. Drag and drop the file into the image ;) However the classes should be the same, otherwise youâll get an error. Thatâs why I asked the version Cheers, Vincent From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 11:46 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] Pharo 7 proxy problem Oh! on 32 bits version worked \o/, just tested it now. On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com<mailto:vitormcruz@gmail.com>> wrote: I just download it using Pharo Launcher [cid:image001.png@01D407CB.F6D840B0] Out of curiosity, how do I deserialize it into an image? :) On Tue, Jun 19, 2018 at 3:36 PM, <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: Hi, Could you send the serialized stack of your primitive failure? [cid:image002.png@01D407CB.F6D840B0] And the version of Pharo you are using? Thanks, Vincent Blondeau From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 11:30 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] Pharo 7 proxy problem Yes, it can resolve. On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>> wrote: have you tested your windows can resolve localhost? Iâm not a regular windows user, but I remember time ago this was not evident on windows systems. Esteban > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com<mailto:vitormcruz@gmail.com>> wrote: > > Hello, > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on windows :) > > Pharo launcher is working fine by the way â I had some problems with it in the past, but it seems more stable now. > > Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve 'localhost' > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed' > > Since it is a primitive problem, I figure there is no workaround possible here... right? > > > ------------------------------------------------ > > > Socket(ProtoObject)>>primitiveFailed: > Socket(ProtoObject)>>primitiveFailed > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: > Socket>>initialize: > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ super new initialize: TCPSocketType ] > BlockClosure>>repeatWithGCIf: > Socket class>>newTCP > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > ZnNetworkingUtils>>socketStreamToUrlDirectly: > ZnNetworkingUtils>>socketStreamToProxy > ZnNetworkingUtils>>socketStreamToUrl: > ZnNetworkingUtils class>>socketStreamToUrl: > ZnClient>>newConnectionTo: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] > > Regards, > Vitor

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Vitor Medina Cruz

Done! https://pharo.fogbugz.com/f/cases/22177/Pharo-7-proxy-problem On Tue, Jun 19, 2018 at 3:55 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > Great! > > > > Could you create a bug report with the stack trace here: > https://pharo.fogbugz.com/f/cases/new ? > > It should be an issue with the socket library under x64. > > > > Drag and drop the file into the image ;) > > However the classes should be the same, otherwise youâll get an error. > Thatâs why I asked the version > > > > Cheers, > > Vincent > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Vitor Medina Cruz > *Sent:* Tuesday, June 19, 2018 11:46 > > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Pharo 7 proxy problem > > > > Oh! on 32 bits version worked \o/, just tested it now. > > > > On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > I just download it using Pharo Launcher > > > > Out of curiosity, how do I deserialize it into an image? :) > > > > On Tue, Jun 19, 2018 at 3:36 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > > Hi, > > > > Could you send the serialized stack of your primitive failure? > > And the version of Pharo you are using? > > > > Thanks, > > > > Vincent Blondeau > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Vitor Medina Cruz > *Sent:* Tuesday, June 19, 2018 11:30 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Pharo 7 proxy problem > > > > Yes, it can resolve. > > > > On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > have you tested your windows can resolve localhost? > Iâm not a regular windows user, but I remember time ago this was not > evident on windows systems. > > Esteban > > > > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > Hello, > > > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on > windows :) > > > > Pharo launcher is working fine by the way â I had some problems with it > in the past, but it seems more stable now. > > > > Well, if using windows isn't bad enought I am behind a proxy, so I use > cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works > fine, but in 7 don't. First it seems to not recognize localhost as > 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve > 'localhost' > > > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > > > PrimitiveFailed: primitive #primSocketCreateNetwork:type: > receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in > Socket failed' > > > > Since it is a primitive problem, I figure there is no workaround > possible here... right? > > > > > > ------------------------------------------------ > > > > > > Socket(ProtoObject)>>primitiveFailed: > > Socket(ProtoObject)>>primitiveFailed > > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize: > semaIndex:readSemaIndex:writeSemaIndex: > > Socket>>initialize: > > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in > Block: [ super new initialize: TCPSocketType ] > > BlockClosure>>repeatWithGCIf: > > Socket class>>newTCP > > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost: > port:timeout: > > ZnNetworkingUtils>>socketStreamToUrlDirectly: > > ZnNetworkingUtils>>socketStreamToProxy > > ZnNetworkingUtils>>socketStreamToUrl: > > ZnNetworkingUtils class>>socketStreamToUrl: > > ZnClient>>newConnectionTo: > > ZnClient>>getConnectionAndExecute > > ZnClient>>executeWithRedirectsRemaining: > > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in > ZnClient>>executeWithRetriesRemaining: in Block: [ self > executeWithRedirectsRemaining: self maxNumb...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithRetriesRemaining: > > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self > executeWithRetriesRemaining: self numberOfRetries ] > > on: Error > > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ > self executeWithRetriesRemaining: self numberOfR...etc... > > BlockClosure>>on:do: > > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > > on: Error > > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ > self executeWithRetriesRemaining: self numberO...etc... > > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > > [ activeProcess psValueAt: index put: anObject. > > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: > in Block: [ activeProcess psValueAt: index put: anObject.... > > BlockClosure>>ensure: > > ZnConnectionTimeout(DynamicVariable)>>value:during: > > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > > ZnClient>>withTimeoutDo: > > ZnClient>>executeWithTimeout > > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ > result := self executeWithTimeout ] > > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value > ] > > > > Regards, > > Vitor > > > > > > >

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Tim Mackinnon

Ah - I didnât think to look in the repair menu, now I see what you guys are talking about - the nomenclature threw me (maybe thatâs ok if its there). Tim > On 19 Jun 2018, at 17:40, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > Ok, I confirm. Actually I think that never worked. The create branch option is only available from the repair action. > > I've opened an issue: > > https://github.com/pharo-vcs/iceberg/issues/871 <https://github.com/pharo-vcs/iceberg/issues/871> > > I think it would be nice to show all valid options (including the ones in the repair button) in the context menu too, for experienced users that want to avoid an extra click. > > On Tue, Jun 19, 2018 at 5:57 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Ah! Yes, in the Pharo plugin you have just that option. > What we were saying with Esteban is that if you go to the *Repair* and then *Create new Branch* you should have it. > > But in the main menu you don't have a "Checkout branch" option? > That's then maybe a bug, I'll check. > > On Tue, Jun 19, 2018 at 5:45 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi guys - I got build 1072 using Pharo Launcher (I like to know what build Iâm using - but maybe I should pick stable and just date stamp my image?) > > Anyway just tried the latest 1077 and followed the steps I described (although using my caught up branch) - when I right click on the detached pharo - there is the Pharo menu item and inside that there is only the option to create a new branch for an issue? > > Am I missing something (or is this something recently broken?) > > Tim > >> On 19 Jun 2018, at 14:35, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Strange... I'm with Esteban there, I'd need more information to reproduce it. >> I've just done >> >> $ wget -O - get.pharo.org/70+vm <http://get.pharo.org/70+vm> | bash >> $ ./pharo-ui Pharo.image >> >> - Open iceberg >> - Repair Pharo by cloning my (really out of date) fork (guillep/pharo) >> - Fetch >> - Repair -> Create branch >> >> And I have the "New branch" option. >> >> On Tue, Jun 19, 2018 at 3:28 PM Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >>> On 19 Jun 2018, at 15:18, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> >>> Hi Guillermo - it sounds like Iâm on the right track - the only thing that caught me out was in the latest V7 there is no ânew branchâ - I have to have an issue number? The picture in your doc shows both possibilities? >> >> how did you arrive there? >> seems to me that there should always be the opportunity of just branch. If not, may be there is an error. >> >> Esteban >> >>> >>> For now, I found a bug and created an issue, and so can experiment with that - but I think it is handy to create a generic branch so that you can experiment (while easily tracking your changes)? >>> >>> Tim >>> >>>> On 19 Jun 2018, at 14:01, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>> Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the instructions seemed to work really well. >>>> >>>> Iâve since come back to try and do some more over lunch (I was thinking Iâd like to dig out the changes I worked out for using the AST and cursor to make senders/implements work properly and not just use the selected text). >>>> >>>> My first problem was that my fork of Pharo from many months ago was out of date - I think the instructions on https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> should probably mention this subtlety. >>>> >>>> It took me ages to figure out what to do - this was the clue (https://help.github.com/articles/syncing-a-fork/ <https://help.github.com/articles/syncing-a-fork/>) - and of particular note the the tiny bit at the bottom to ensure you Push your changes back to your GitHub fork (I slightly complicated myself by using IntelliJ to do this - doable but you need to be aware of whats going on). I did this in a separate non-pharo directory (I think thats what you would recommend right? Then you can keep updating it from time to time?) >>>> >>>> Usually, you don't care. You don't need to update your fork :) >>>> You only need to: >>>> - clone/locate your repository in disk >>>> - fetch (this will find your commit in the pharo repository) >>>> - create a new branch X >>>> - push branch X to your fork >>>> - make a pull request >>>> >>>> The contribution process never goes through master nor development, so it does not really matter if they are updated. >>>> And that's what I was showing in my videos because there is nothing else to it :) >>>> >>>> >>>> Having got my GitHub fork caught up with pharo/development - I then have the Local Repo Missing error (expected) - and now when I go to repair it I can either clone again (which is the instructions online) - or âLocate this repository in your file systemâ. As Iâve had to already check everything out to catch up to pharo/dev I chose to locate. >>>> >>>> I then get a Fetch require msg (expected) >>>> >>>> I then choose to use Fetch (Iâm not sure what the Repair repository picture is now about?) - the text does mention I will become detached, so Iâve stuck to that >>>> >>>> Iâm not sure why the âsolving a detached working copyâ is further down the page - but Iâve jumped to that >>>> >>>> It says I need to synchronise both (image and repo) - but then says its easier to do a branch - and then says a nice alternative is to create a temp branch like temp/synch - however I canât see how to do that as there is only Crete new Branch from Issue now (the picture shows that plus New Branch). >>>> >>>> I don't see what's the problem, maybe the UI can be enhanced to be more explicit. >>>> But you can just select "New branch" and create a branch with any name. >>>> >>>> I'll go a bit deeper here: >>>> - you just downloaded a new image that was built from commit 100 >>>> - In the meantime, while you downloaded your image, a new PR would have been integrated in pharo, so now the development branch may not be anymore on commit 100 but on commit 101. >>>> - Even worse! There is no branch at all pointing to 100, your image's commit >>>> - So the safest way to work (because updating the image may be dangerous not because of Iceberg :)) is to create a new branch on your commit. >>>> >>>> However, while this is the recommended way to work on Pharo, on other projects you can do a more normal workflow: checkout, pull. >>>> >>>> Does this answer it? Maybe I've missed something? >>>> >>>> >>>> >>>> Am I on the right track here? If I want try something out - do I just create myself a new issue (or is there a temp issue anyway?) >>>> >>>> Tim >>>> >>>> >>>> -- >>>> >>>> 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 >>> >> >> >> >> -- >> >> 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 > > > > -- > > 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 > > > -- > > 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

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Vincent.Blondeau＠lamresearch.com

Great! Could you create a bug report with the stack trace here: https://pharo.fogbugz.com/f/cases/new ? It should be an issue with the socket library under x64. Drag and drop the file into the image ;) However the classes should be the same, otherwise youâll get an error. Thatâs why I asked the version Cheers, Vincent From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 11:46 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Pharo 7 proxy problem Oh! on 32 bits version worked \o/, just tested it now. On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com<mailto:vitormcruz@gmail.com>> wrote: I just download it using Pharo Launcher [cid:image002.png@01D407C4.69242D30] Out of curiosity, how do I deserialize it into an image? :) On Tue, Jun 19, 2018 at 3:36 PM, <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: Hi, Could you send the serialized stack of your primitive failure? [cid:image003.png@01D407C4.69242D30] And the version of Pharo you are using? Thanks, Vincent Blondeau From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 11:30 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] Pharo 7 proxy problem Yes, it can resolve. On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>> wrote: have you tested your windows can resolve localhost? Iâm not a regular windows user, but I remember time ago this was not evident on windows systems. Esteban > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com<mailto:vitormcruz@gmail.com>> wrote: > > Hello, > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on windows :) > > Pharo launcher is working fine by the way â I had some problems with it in the past, but it seems more stable now. > > Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve 'localhost' > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed' > > Since it is a primitive problem, I figure there is no workaround possible here... right? > > > ------------------------------------------------ > > > Socket(ProtoObject)>>primitiveFailed: > Socket(ProtoObject)>>primitiveFailed > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: > Socket>>initialize: > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ super new initialize: TCPSocketType ] > BlockClosure>>repeatWithGCIf: > Socket class>>newTCP > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > ZnNetworkingUtils>>socketStreamToUrlDirectly: > ZnNetworkingUtils>>socketStreamToProxy > ZnNetworkingUtils>>socketStreamToUrl: > ZnNetworkingUtils class>>socketStreamToUrl: > ZnClient>>newConnectionTo: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] > > Regards, > Vitor

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Vitor Medina Cruz

Oh! on 32 bits version worked \o/, just tested it now. On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > I just download it using Pharo Launcher > > > > > Out of curiosity, how do I deserialize it into an image? :) > > > On Tue, Jun 19, 2018 at 3:36 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > >> Hi, >> >> >> >> Could you send the serialized stack of your primitive failure? >> >> And the version of Pharo you are using? >> >> >> >> Thanks, >> >> >> >> Vincent Blondeau >> >> >> >> *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On >> Behalf Of *Vitor Medina Cruz >> *Sent:* Tuesday, June 19, 2018 11:30 >> *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> *Subject:* Re: [Pharo-users] Pharo 7 proxy problem >> >> >> >> Yes, it can resolve. >> >> >> >> On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> have you tested your windows can resolve localhost? >> Iâm not a regular windows user, but I remember time ago this was not >> evident on windows systems. >> >> Esteban >> >> >> > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> > >> > Hello, >> > >> > I decided to give a try on Pharo 7 and see how iceberg is doing.... on >> windows :) >> > >> > Pharo launcher is working fine by the way â I had some problems with it >> in the past, but it seems more stable now. >> > >> > Well, if using windows isn't bad enought I am behind a proxy, so I use >> cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works >> fine, but in 7 don't. First it seems to not recognize localhost as >> 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve >> 'localhost' >> > >> > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): >> > >> > PrimitiveFailed: primitive #primSocketCreateNetwork:type: >> receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in >> Socket failed' >> > >> > Since it is a primitive problem, I figure there is no workaround >> possible here... right? >> > >> > >> > ------------------------------------------------ >> > >> > >> > Socket(ProtoObject)>>primitiveFailed: >> > Socket(ProtoObject)>>primitiveFailed >> > Socket>>primSocketCreateNetwork:type:receiveBufferSize: >> sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: >> > Socket>>initialize: >> > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in >> Block: [ super new initialize: TCPSocketType ] >> > BlockClosure>>repeatWithGCIf: >> > Socket class>>newTCP >> > ZdcSocketStream class(ZdcSimpleSocketStream >> class)>>openConnectionToHost:port:timeout: >> > ZnNetworkingUtils>>socketStreamToUrlDirectly: >> > ZnNetworkingUtils>>socketStreamToProxy >> > ZnNetworkingUtils>>socketStreamToUrl: >> > ZnNetworkingUtils class>>socketStreamToUrl: >> > ZnClient>>newConnectionTo: >> > ZnClient>>getConnectionAndExecute >> > ZnClient>>executeWithRedirectsRemaining: >> > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in >> ZnClient>>executeWithRetriesRemaining: in Block: [ self >> executeWithRedirectsRemaining: self maxNumb...etc... >> > BlockClosure>>on:do: >> > ZnClient>>executeWithRetriesRemaining: >> > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self >> executeWithRetriesRemaining: self numberOfRetries ] >> > on: Error >> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ >> self executeWithRetriesRemaining: self numberOfR...etc... >> > BlockClosure>>on:do: >> > [ [ self executeWithRetriesRemaining: self numberOfRetries ] >> > on: Error >> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ >> [ self executeWithRetriesRemaining: self numberO...etc... >> > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value >> ] >> > [ activeProcess psValueAt: index put: anObject. >> > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: >> in Block: [ activeProcess psValueAt: index put: anObject.... >> > BlockClosure>>ensure: >> > ZnConnectionTimeout(DynamicVariable)>>value:during: >> > ZnConnectionTimeout class(DynamicVariable class)>>value:during: >> > ZnClient>>withTimeoutDo: >> > ZnClient>>executeWithTimeout >> > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ >> result := self executeWithTimeout ] >> > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block >> value ] >> > >> > Regards, >> > Vitor >> >> >> > >

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Vincent.Blondeau＠lamresearch.com

Hi, Could you send the serialized stack of your primitive failure? [cid:image001.png@01D407C1.C9C68460] And the version of Pharo you are using? Thanks, Vincent Blondeau From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Vitor Medina Cruz Sent: Tuesday, June 19, 2018 11:30 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Pharo 7 proxy problem Yes, it can resolve. On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>> wrote: have you tested your windows can resolve localhost? Iâm not a regular windows user, but I remember time ago this was not evident on windows systems. Esteban > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com<mailto:vitormcruz@gmail.com>> wrote: > > Hello, > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on windows :) > > Pharo launcher is working fine by the way â I had some problems with it in the past, but it seems more stable now. > > Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve 'localhost' > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed' > > Since it is a primitive problem, I figure there is no workaround possible here... right? > > > ------------------------------------------------ > > > Socket(ProtoObject)>>primitiveFailed: > Socket(ProtoObject)>>primitiveFailed > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: > Socket>>initialize: > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ super new initialize: TCPSocketType ] > BlockClosure>>repeatWithGCIf: > Socket class>>newTCP > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > ZnNetworkingUtils>>socketStreamToUrlDirectly: > ZnNetworkingUtils>>socketStreamToProxy > ZnNetworkingUtils>>socketStreamToUrl: > ZnNetworkingUtils class>>socketStreamToUrl: > ZnClient>>newConnectionTo: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] > > Regards, > Vitor

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Vitor Medina Cruz

Yes, it can resolve. On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > have you tested your windows can resolve localhost? > Iâm not a regular windows user, but I remember time ago this was not > evident on windows systems. > > Esteban > > > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > Hello, > > > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on > windows :) > > > > Pharo launcher is working fine by the way â I had some problems with it > in the past, but it seems more stable now. > > > > Well, if using windows isn't bad enought I am behind a proxy, so I use > cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works > fine, but in 7 don't. First it seems to not recognize localhost as > 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve > 'localhost' > > > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > > > PrimitiveFailed: primitive #primSocketCreateNetwork:type: > receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in > Socket failed' > > > > Since it is a primitive problem, I figure there is no workaround > possible here... right? > > > > > > ------------------------------------------------ > > > > > > Socket(ProtoObject)>>primitiveFailed: > > Socket(ProtoObject)>>primitiveFailed > > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize: > semaIndex:readSemaIndex:writeSemaIndex: > > Socket>>initialize: > > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in > Block: [ super new initialize: TCPSocketType ] > > BlockClosure>>repeatWithGCIf: > > Socket class>>newTCP > > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost: > port:timeout: > > ZnNetworkingUtils>>socketStreamToUrlDirectly: > > ZnNetworkingUtils>>socketStreamToProxy > > ZnNetworkingUtils>>socketStreamToUrl: > > ZnNetworkingUtils class>>socketStreamToUrl: > > ZnClient>>newConnectionTo: > > ZnClient>>getConnectionAndExecute > > ZnClient>>executeWithRedirectsRemaining: > > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in > ZnClient>>executeWithRetriesRemaining: in Block: [ self > executeWithRedirectsRemaining: self maxNumb...etc... > > BlockClosure>>on:do: > > ZnClient>>executeWithRetriesRemaining: > > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self > executeWithRetriesRemaining: self numberOfRetries ] > > on: Error > > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ > self executeWithRetriesRemaining: self numberOfR...etc... > > BlockClosure>>on:do: > > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > > on: Error > > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ > self executeWithRetriesRemaining: self numberO...etc... > > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > > [ activeProcess psValueAt: index put: anObject. > > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: > in Block: [ activeProcess psValueAt: index put: anObject.... > > BlockClosure>>ensure: > > ZnConnectionTimeout(DynamicVariable)>>value:during: > > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > > ZnClient>>withTimeoutDo: > > ZnClient>>executeWithTimeout > > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ > result := self executeWithTimeout ] > > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value > ] > > > > Regards, > > Vitor > > >

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Guillermo Polito

Ok, I confirm. Actually I think that never worked. The create branch option is only available from the repair action. I've opened an issue: https://github.com/pharo-vcs/iceberg/issues/871 I think it would be nice to show all valid options (including the ones in the repair button) in the context menu too, for experienced users that want to avoid an extra click. On Tue, Jun 19, 2018 at 5:57 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ah! Yes, in the Pharo plugin you have just that option. > What we were saying with Esteban is that if you go to the *Repair* and > then *Create new Branch* you should have it. > > But in the main menu you don't have a "Checkout branch" option? > That's then maybe a bug, I'll check. > > On Tue, Jun 19, 2018 at 5:45 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi guys - I got build 1072 using Pharo Launcher (I like to know what >> build Iâm using - but maybe I should pick stable and just date stamp my >> image?) >> >> Anyway just tried the latest 1077 and followed the steps I described >> (although using my caught up branch) - when I right click on the detached >> pharo - there is the Pharo menu item and inside that there is only the >> option to create a new branch for an issue? >> >> Am I missing something (or is this something recently broken?) >> >> Tim >> >> On 19 Jun 2018, at 14:35, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Strange... I'm with Esteban there, I'd need more information to reproduce >> it. >> I've just done >> >> $ wget -O - get.pharo.org/70+vm | bash >> $ ./pharo-ui Pharo.image >> >> - Open iceberg >> - Repair Pharo by cloning my (really out of date) fork (guillep/pharo) >> - Fetch >> - Repair -> Create branch >> >> And I have the "New branch" option. >> >> On Tue, Jun 19, 2018 at 3:28 PM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >>> >>> On 19 Jun 2018, at 15:18, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi Guillermo - it sounds like Iâm on the right track - the only thing >>> that caught me out was in the latest V7 there is no ânew branchâ - I have >>> to have an issue number? The picture in your doc shows both possibilities? >>> >>> >>> how did you arrive there? >>> seems to me that there should always be the opportunity of just branch. >>> If not, may be there is an error. >>> >>> Esteban >>> >>> >>> For now, I found a bug and created an issue, and so can experiment with >>> that - but I think it is handy to create a generic branch so that you can >>> experiment (while easily tracking your changes)? >>> >>> Tim >>> >>> On 19 Jun 2018, at 14:01, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works> wrote: >>> >>>> Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the >>>> instructions seemed to work really well. >>>> >>>> Iâve since come back to try and do some more over lunch (I was thinking >>>> Iâd like to dig out the changes I worked out for using the AST and cursor >>>> to make senders/implements work properly and not just use the selected >>>> text). >>>> >>>> My first problem was that my fork of Pharo from many months ago was out >>>> of date - I think the instructions on >>>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo should >>>> probably mention this subtlety. >>>> >>> >>>> It took me ages to figure out what to do - this was the clue ( >>>> https://help.github.com/articles/syncing-a-fork/) - and of particular >>>> note the the tiny bit at the bottom to ensure you Push your changes back to >>>> your GitHub fork (I slightly complicated myself by using IntelliJ to do >>>> this - doable but you need to be aware of whats going on). I did this in a >>>> separate non-pharo directory (I think thats what you would recommend right? >>>> Then you can keep updating it from time to time?) >>>> >>> >>> Usually, you don't care. You don't need to update your fork :) >>> You only need to: >>> - clone/locate your repository in disk >>> - fetch (this will find your commit in the pharo repository) >>> - create a new branch X >>> - push branch X to your fork >>> - make a pull request >>> >>> The contribution process never goes through master nor development, so >>> it does not really matter if they are updated. >>> And that's what I was showing in my videos because there is nothing else >>> to it :) >>> >>> >>>> >>>> Having got my GitHub fork caught up with pharo/development - I then >>>> have the Local Repo Missing error (expected) - and now when I go to repair >>>> it I can either clone again (which is the instructions online) - or âLocate >>>> this repository in your file systemâ. As Iâve had to already check >>>> everything out to catch up to pharo/dev I chose to locate. >>>> >>>> I then get a Fetch require msg (expected) >>>> >>>> I then choose to use Fetch (Iâm not sure what the Repair repository >>>> picture is now about?) - the text does mention I will become detached, so >>>> Iâve stuck to that >>>> >>>> Iâm not sure why the âsolving a detached working copyâ is further down >>>> the page - but Iâve jumped to that >>>> >>>> It says I need to synchronise both (image and repo) - but then says its >>>> easier to do a branch - and then says a nice alternative is to create a >>>> temp branch like temp/synch - however I canât see how to do that as there >>>> is only Crete new Branch from Issue now (the picture shows that plus New >>>> Branch). >>>> >>> >>> I don't see what's the problem, maybe the UI can be enhanced to be more >>> explicit. >>> But you can just select "New branch" and create a branch with any name. >>> >>> I'll go a bit deeper here: >>> - you just downloaded a new image that was built from commit 100 >>> - In the meantime, while you downloaded your image, a new PR would have >>> been integrated in pharo, so now the development branch may not be anymore >>> on commit 100 but on commit 101. >>> - Even worse! There is no branch at all pointing to 100, your image's >>> commit >>> - So the safest way to work (because updating the image may be >>> dangerous not because of Iceberg :)) is to create a new branch on your >>> commit. >>> >>> However, while this is the recommended way to work on Pharo, on other >>> projects you can do a more normal workflow: checkout, pull. >>> >>> Does this answer it? Maybe I've missed something? >>> >>> >>> >>>> >>>> Am I on the right track here? If I want try something out - do I just >>>> create myself a new issue (or is there a temp issue anyway?) >>>> >>>> Tim >>>> >>> >>> >>> -- >>> >>> 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 >>> >>> >>> >>> >> >> -- >> >> 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 >> >> >> > > -- > > > > 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 > -- 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

June 19, 2018

Re: [Pharo-users] Pharo 7 proxy problem

by Esteban Lorenzano

have you tested your windows can resolve localhost? Iâm not a regular windows user, but I remember time ago this was not evident on windows systems. Esteban > On 19 Jun 2018, at 18:23, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Hello, > > I decided to give a try on Pharo 7 and see how iceberg is doing.... on windows :) > > Pharo launcher is working fine by the way â I had some problems with it in the past, but it seems more stable now. > > Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve 'localhost' > > Using 127.0.0.1 I got a PrimitiveFailure (Ick!): > > PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed' > > Since it is a primitive problem, I figure there is no workaround possible here... right? > > > ------------------------------------------------ > > > Socket(ProtoObject)>>primitiveFailed: > Socket(ProtoObject)>>primitiveFailed > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: > Socket>>initialize: > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ super new initialize: TCPSocketType ] > BlockClosure>>repeatWithGCIf: > Socket class>>newTCP > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > ZnNetworkingUtils>>socketStreamToUrlDirectly: > ZnNetworkingUtils>>socketStreamToProxy > ZnNetworkingUtils>>socketStreamToUrl: > ZnNetworkingUtils class>>socketStreamToUrl: > ZnClient>>newConnectionTo: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] > > Regards, > Vitor

June 19, 2018

Pharo 7 proxy problem

by Vitor Medina Cruz

Hello, I decided to give a try on Pharo 7 and see how iceberg is doing.... on windows :) Pharo launcher is working fine by the way â I had some problems with it in the past, but it seems more stable now. Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve 'localhost' Using 127.0.0.1 I got a PrimitiveFailure (Ick!): PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed' Since it is a primitive problem, I figure there is no workaround possible here... right? ------------------------------------------------ Socket(ProtoObject)>>primitiveFailed: Socket(ProtoObject)>>primitiveFailed Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: Socket>>initialize: [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ super new initialize: TCPSocketType ] BlockClosure>>repeatWithGCIf: Socket class>>newTCP ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: ZnNetworkingUtils>>socketStreamToUrlDirectly: ZnNetworkingUtils>>socketStreamToProxy ZnNetworkingUtils>>socketStreamToUrl: ZnNetworkingUtils class>>socketStreamToUrl: ZnClient>>newConnectionTo: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] on: Error do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: [ [ self executeWithRetriesRemaining: self numberOfRetries ] on: Error do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] [ activeProcess psValueAt: index put: anObject. aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: ZnConnectionTimeout(DynamicVariable)>>value:during: ZnConnectionTimeout class(DynamicVariable class)>>value:during: ZnClient>>withTimeoutDo: ZnClient>>executeWithTimeout [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] Regards, Vitor

June 19, 2018