- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Tudor Girba

Hi, I just had the issue again while typing code. I actually cannot work. Is it really only me, or is it that others just got used to living with this and not report the issue? I would consider this a blocker. Do you agree? Cheers, Doru > On May 26, 2017, at 8:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Nicolas, > > Thanks. > > You might be right. It just happened again while typing. > > I am using: > - Pharo image: 60497 > - VM: > CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 > VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > <crash.dmp> > > Cheers, > Doru > > >> On May 25, 2017, at 4:44 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Hi Tudor, >> it seems you type too fast. >> More seriously, if I google some of the apple methods in the stack like for example >> "bug InputMethodInstanceProcessEventRef_WithCompletionHandler" >> I see quite some many hits indicating that: >> - we are not alone >> - either there are some bug on mac os >> - or it's complex to use the frameworks right... >> >> Debugging this kind of low level problem is going to be tough... >> Probably some advanced objective-C knowledge is required. >> >> 2017-05-24 22:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >> >> Today I experienced multiple crashes on macOS Sierra. >> >> These happened during regular programming, mostly while typing code. I attached here the crash dump(s). I believe I heard Phil having the same issue with the stable Pharo VM. >> >> Does anyone else has the same issue? >> >> The VM is: >> CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> The Pharo update number is: 60482 >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

May 28, 2017

Re: [Pharo-dev] basicNew usage pattern

by Ben Coman

On Sat, May 27, 2017 at 5:41 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Saturday 27 May 2017 01:41 PM, Ben Coman wrote: >> >> A question arose in Discord regarding #basicNew, to which I felt like >> the proper answer should be >> that #basicNew is used only** from the class-side when making custom >> initializers. >> (**excepting special meta-handling like by Behaviour) > > > AFAIK, #basicNew is a low-level essential method which should *never* be > overridden by application methods, while #new offers a stable facade over > #basicNew for applications. > > Essentially, #basic* methods are calls to primitives in VM which reify basic > objects of the object model like float, symbols etc. They are coupled > closely with interpreter and object memory structures and functions. > Application classes do not concern themselves with size and layout of such > objects and use the facade methods like #new. > > It is like the difference between a system call and runtime C library > function. A C function like malloc maintains a stable interface to the app > while its makes different system calls on different OS implementations. > > HTH .. Subbu > Thanks Subbu. That is a useful insight for me, but is about the implementation. My query was more about senders of basicNew, so is still open if you have an opinion there, or anyone else. cheers -ben

May 28, 2017

Re: [Pharo-dev] Iceberg ?

by Ben Coman

On Sat, May 27, 2017 at 4:33 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > On 27 May 2017, at 03:42, Ben Coman <btc(a)openInWorld.com> wrote: >> >> btw, I'm curious why the pub key is required? Isn't it only needed at the >>> other (github) end? > > no idea :) > I just know that libgit2 requires it I had a hunt. The only hint I could find is... "for SSH authentication, the ssh user is [always?] 'git'. The [public?] key is what's used for figuring out what the GitHub username is." https://stackoverflow.com/questions/21122479/connect-to-private-github-repo… Would that make sense? My annotations in square brackets. cheers -ben

May 28, 2017

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

by serge.stinckwich＠gmail.com

Thank you guys for your contributions, but I think that this kind of discussions should be done on pharo-users mailing-list, not here. pharo-dev should be use only if you contribute to core-pharo. Thank you EnvoyÃ© de mon iPhone > Le 28 mai 2017 Ã 10:22, askoh <askoh(a)askoh.com> a Ã©crit : > > Wonderful contribution. Having full control of an internet browser will give Smalltalk more freedom to innovate. > > Now, can we make Pharo be a web server on demand? Then we can give anyone a URL and they can see the app or info we want to present. Pharo can communicate with anyone using a browser either automatically or under developer control. > > All the best, > Aik-Siong Koh > >> On May 27, 2017, at 3:23 PM, Alistair Grant [via Smalltalk] <[hidden email]> wrote: >> >> Hi Torsten and All, >> >> Quick Introduction for those not familiar with Pharo-Chrome: >> >> Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in >> particular to retrieve the DOM of a page. This is useful as many modern >> pages are just a template which then loads some javascript to >> asynchronously build the DOM, meaning that the ZnEasy / Soap combination >> doesn't get the bulk of the information on a page. >> >> >> >> Pharo-Chrome is now mostly working, i.e. it is possible to open >> a connection to Chrome, navigate to a requested URL, wait for it to >> load, retrieve the DOM and then navigate the DOM using a subset of the >> Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc.. >> >> GoogleChrome class>>exampleNavigation has been updated to retrieve the >> DOM from http://pharo.org. >> >> GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it >> returns a ChromeNode, not an html string. >> >> I wasn't able to get rid of the delay while waiting for the page to >> finish loading. This actually makes sense, since, as mentioned above, >> many modern pages build the DOM asynchronously, so there's no clear >> indication of when it is complete. The default delay is currently 2000 >> milliseconds, which is about twice the maximum I saw needed (983ms), but >> this can be changed (ChromeTabPage>>pageLoadDelay:). >> >> I had three use cases for this library: one which works with >> ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to >> a page redesign, and one which I hadn't got working before. All three >> are working now. >> >> Unlike Soap, I've currently modelled the nodes as a single class, and >> have only implemented a subset of Soap's methods, but is enough for what >> I need. >> >> I've introduced a dependency on the Beacon logging framework. I find it >> useful, but can remove it if you don't want the additional dependency. >> (I'm planning to add some GoogleChrome specific logging classes and use >> those to better understand what pageLoadDelay should be). >> >> I was focussed on trying to understand the events that Chrome generates, >> so documentation is still lacking (read "missing" :-)). >> >> I'll generate a pull request after some more testing, tweaking and >> documenting, but if you would like to take a look, the code is available >> at: >> >> https://github.com/akgrant43/Pharo-Chrome/tree/development >> >> I haven't yet updated BaselineOfChrome with the Beacon dependency. I >> did merge in your two commits from May 23. >> >> If you, or anyone else, finds this useful, I welcome any feedback. >> >> P.S. I've just realised that I need to tidy up #sendMessage:, >> #sendMessageDictionary and #sendMessageDictionary:wait:. I'll do that >> as part of the genral tidy up. >> >> Cheers, >> Alistair >> >> >> # vim: tw=72 >> On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote: >> >> > Hi Torsten, >> > >> > On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote: >> > > >> > > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: >> > > > Hi Alistair, >> > > > >> > > > cant look right now but two things: >> > > > >> > > > - there are also events in the protocol - if we could hook Pharo into them >> > > > this would solve the problem without abusing delay (because then you will >> > > > get informed when the page loading is finished) >> > > >> > > That would be great. It will be a while before I get a chance to look >> > > at this (I want to finish some proposed changes to the FileSystem >> > > packages first), but I'll try and include it then. >> > >> > I've got basic event listening working. It requires that all messages >> > are read asynchronously, so I'll need to change the interface to handle >> > that. >> > >> > Knowing when a page has finished loading isn't quite as simple as >> > looking for an event - a page can consist of multiple frames, and >> > notifications are delivered for each frame. The page I'm interested in >> > has around 25 frames. >> > >> > If anyone has a good design pattern for writing an asynchronous >> > WebSocket client please let me know, I don't have anything concrete in >> > mind. >> > >> > Thanks, >> > Alistair >> > >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948458.… >> To unsubscribe from Chrome DevTools Protocol and Pharo, click here. >> NAML > > View this message in context: Re: Chrome DevTools Protocol and Pharo > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

by askoh

Wonderful contribution. Having full control of an internet browser will give Smalltalk more freedom to innovate. Now, can we make Pharo be a web server on demand? Then we can give anyone a URL and they can see the app or info we want to present. Pharo can communicate with anyone using a browser either automatically or under developer control. All the best, Aik-Siong Koh > On May 27, 2017, at 3:23 PM, Alistair Grant [via Smalltalk] <ml+s1294792n4948458h22(a)n4.nabble.com> wrote: > > Hi Torsten and All, > > Quick Introduction for those not familiar with Pharo-Chrome: > > Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in > particular to retrieve the DOM of a page. This is useful as many modern > pages are just a template which then loads some javascript to > asynchronously build the DOM, meaning that the ZnEasy / Soap combination > doesn't get the bulk of the information on a page. > > > > Pharo-Chrome is now mostly working, i.e. it is possible to open > a connection to Chrome, navigate to a requested URL, wait for it to > load, retrieve the DOM and then navigate the DOM using a subset of the > Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc.. > > GoogleChrome class>>exampleNavigation has been updated to retrieve the > DOM from http://pharo.org. > > GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it > returns a ChromeNode, not an html string. > > I wasn't able to get rid of the delay while waiting for the page to > finish loading. This actually makes sense, since, as mentioned above, > many modern pages build the DOM asynchronously, so there's no clear > indication of when it is complete. The default delay is currently 2000 > milliseconds, which is about twice the maximum I saw needed (983ms), but > this can be changed (ChromeTabPage>>pageLoadDelay:). > > I had three use cases for this library: one which works with > ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to > a page redesign, and one which I hadn't got working before. All three > are working now. > > Unlike Soap, I've currently modelled the nodes as a single class, and > have only implemented a subset of Soap's methods, but is enough for what > I need. > > I've introduced a dependency on the Beacon logging framework. I find it > useful, but can remove it if you don't want the additional dependency. > (I'm planning to add some GoogleChrome specific logging classes and use > those to better understand what pageLoadDelay should be). > > I was focussed on trying to understand the events that Chrome generates, > so documentation is still lacking (read "missing" :-)). > > I'll generate a pull request after some more testing, tweaking and > documenting, but if you would like to take a look, the code is available > at: > > https://github.com/akgrant43/Pharo-Chrome/tree/development > > I haven't yet updated BaselineOfChrome with the Beacon dependency. I > did merge in your two commits from May 23. > > If you, or anyone else, finds this useful, I welcome any feedback. > > P.S. I've just realised that I need to tidy up #sendMessage:, > #sendMessageDictionary and #sendMessageDictionary:wait:. I'll do that > as part of the genral tidy up. > > Cheers, > Alistair > > > # vim: tw=72 > On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote: > > > Hi Torsten, > > > > On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote: > > > > > > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: > > > > Hi Alistair, > > > > > > > > cant look right now but two things: > > > > > > > > - there are also events in the protocol - if we could hook Pharo into them > > > > this would solve the problem without abusing delay (because then you will > > > > get informed when the page loading is finished) > > > > > > That would be great. It will be a while before I get a chance to look > > > at this (I want to finish some proposed changes to the FileSystem > > > packages first), but I'll try and include it then. > > > > I've got basic event listening working. It requires that all messages > > are read asynchronously, so I'll need to change the interface to handle > > that. > > > > Knowing when a page has finished loading isn't quite as simple as > > looking for an event - a page can consist of multiple frames, and > > notifications are delivered for each frame. The page I'm interested in > > has around 25 frames. > > > > If anyone has a good design pattern for writing an asynchronous > > WebSocket client please let me know, I don't have anything concrete in > > mind. > > > > Thanks, > > Alistair > > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948458.… > To unsubscribe from Chrome DevTools Protocol and Pharo, click here. > NAML -- View this message in context: http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948461.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

by Alistair Grant

Hi Torsten and All, Quick Introduction for those not familiar with Pharo-Chrome: Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in particular to retrieve the DOM of a page. This is useful as many modern pages are just a template which then loads some javascript to asynchronously build the DOM, meaning that the ZnEasy / Soap combination doesn't get the bulk of the information on a page. Pharo-Chrome is now mostly working, i.e. it is possible to open a connection to Chrome, navigate to a requested URL, wait for it to load, retrieve the DOM and then navigate the DOM using a subset of the Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc.. GoogleChrome class>>exampleNavigation has been updated to retrieve the DOM from http://pharo.org. GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it returns a ChromeNode, not an html string. I wasn't able to get rid of the delay while waiting for the page to finish loading. This actually makes sense, since, as mentioned above, many modern pages build the DOM asynchronously, so there's no clear indication of when it is complete. The default delay is currently 2000 milliseconds, which is about twice the maximum I saw needed (983ms), but this can be changed (ChromeTabPage>>pageLoadDelay:). I had three use cases for this library: one which works with ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to a page redesign, and one which I hadn't got working before. All three are working now. Unlike Soap, I've currently modelled the nodes as a single class, and have only implemented a subset of Soap's methods, but is enough for what I need. I've introduced a dependency on the Beacon logging framework. I find it useful, but can remove it if you don't want the additional dependency. (I'm planning to add some GoogleChrome specific logging classes and use those to better understand what pageLoadDelay should be). I was focussed on trying to understand the events that Chrome generates, so documentation is still lacking (read "missing" :-)). I'll generate a pull request after some more testing, tweaking and documenting, but if you would like to take a look, the code is available at: https://github.com/akgrant43/Pharo-Chrome/tree/development I haven't yet updated BaselineOfChrome with the Beacon dependency. I did merge in your two commits from May 23. If you, or anyone else, finds this useful, I welcome any feedback. P.S. I've just realised that I need to tidy up #sendMessage:, #sendMessageDictionary and #sendMessageDictionary:wait:. I'll do that as part of the genral tidy up. Cheers, Alistair # vim: tw=72 On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote: > Hi Torsten, > > On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote: > > > > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: > > > Hi Alistair, > > > > > > cant look right now but two things: > > > > > > - there are also events in the protocol - if we could hook Pharo into them > > > this would solve the problem without abusing delay (because then you will > > > get informed when the page loading is finished) > > > > That would be great. It will be a while before I get a chance to look > > at this (I want to finish some proposed changes to the FileSystem > > packages first), but I'll try and include it then. > > I've got basic event listening working. It requires that all messages > are read asynchronously, so I'll need to change the interface to handle > that. > > Knowing when a page has finished loading isn't quite as simple as > looking for an event - a page can consist of multiple frames, and > notifications are delivered for each frame. The page I'm interested in > has around 25 frames. > > If anyone has a good design pattern for writing an asynchronous > WebSocket client please let me know, I don't have anything concrete in > mind. > > Thanks, > Alistair >

May 27, 2017

Re: [Pharo-dev] basicNew usage pattern

by K K Subbu

On Saturday 27 May 2017 01:41 PM, Ben Coman wrote: > A question arose in Discord regarding #basicNew, to which I felt like > the proper answer should be > that #basicNew is used only** from the class-side when making custom > initializers. > (**excepting special meta-handling like by Behaviour) AFAIK, #basicNew is a low-level essential method which should *never* be overridden by application methods, while #new offers a stable facade over #basicNew for applications. Essentially, #basic* methods are calls to primitives in VM which reify basic objects of the object model like float, symbols etc. They are coupled closely with interpreter and object memory structures and functions. Application classes do not concern themselves with size and layout of such objects and use the facade methods like #new. It is like the difference between a system call and runtime C library function. A C function like malloc maintains a stable interface to the app while its makes different system calls on different OS implementations. HTH .. Subbu

May 27, 2017

Re: [Pharo-dev] Iceberg ?

by Esteban Lorenzano

> On 27 May 2017, at 03:42, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Fri, May 26, 2017 at 5:31 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > again, ssh-agent is one way to authenticate. > it can be not the best but it is the only one we could implement with the time we get (also, ssh-agent is âcommonâ while others are platform specific and then they will work just in the intended platform). With time, we want to implement all, but for now is what we have. > > One way to solve this *without* using ssh-agent (for example, something we recommend now for windows, since ssh-agent has problems for people not used to it) is to use âcustom keysâ, which now in iceberg is done in settings (as explained on the FAQ), or running this: > > IceCredentialsProvider useCustomSsh: true. > IceCredentialsProvider sshCredentials > publicKey: '/Users/esteban/.ssh/id_rsa.pubâ; > privateKey: '/Users/esteban/.ssh/id_rsaâ > > of course, you need to modify paths to your user :) > of course (2), you may add that to a startup action, so you do not need to execute that each time. > > Maybe in some quick-start instructions this should be the default, so people can prove to themselves > it works, then move on to using ssh-agent which has more modes of failure. Other apps like PuTTY > do this... > https://developers.openshift.com/images/overview-ssh-putty-configure-4.png <https://developers.openshift.com/images/overview-ssh-putty-configure-4.png> but there is a settings there :) (not as complete as that, but we should arrive) what Iâm thinking is to change the âdefaultâ to âssh-agent or guessâ: try to get the ssh-agent credentials, if that fails try to guess based on what is in default directory (.ssh) and if not then raise the exception. Is a hack, but I think it will work. Now, in fact ssh-agent works in 99% of the cases when you are out of windows (most people have it configured by default and with default options), the problem is that Stef does not do anything default (which is good, because then is a good border-case detector) :) > > btw, I'm curious why the pub key is required? Isn't it only needed at the other (github) end? no idea :) I just know that libgit2 requires it cheers, Esteban > > cheers -ben > > > cheers, > Esteban > >> On 25 May 2017, at 22:12, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> >> I retried >> rename all the keys I put in my git account. >> >> But >> > ssh-add -K ~/.ssh/github_rsa >> Error connecting to agent: No such file or directory >> > ssh-add -K ~/.ssh/2016RSA >> Error connecting to agent: No such file or directory >> >> Apparently I should run >> eval `ssh-agent -s` >> Now I will try to republish on github. >> anyway I'm not using git in pharo for now. >> >> Stef >> >> On Thu, May 25, 2017 at 8:20 PM, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> > I do not get why I can use github all the time and not with pharo. >> >> That is an excellent question >> >> Alexandre >> >> > >

May 27, 2017

basicNew usage pattern

by Ben Coman

A question arose in Discord regarding #basicNew, to which I felt like the proper answer should be that #basicNew is used only** from the class-side when making custom initializers. (**excepting special meta-handling like by Behaviour) This philosophy is somewhat supported by... (#basicNew senders select: [:sender | sender methodClass isMeta]) count ==> 264 but there are also counter examples... (#basicNew senders select: [:sender | sender methodClass isMeta] not) count ==> 76. like these... Example1 -- DAPackageRelationGraph>>addMessageSendDependencies: aPackage analyser := DAMessageSendAnalyzer basicNew initializeWith: aPackage; yourself. Example 2 -- FreeTypeFontProvider>>#updateFromFile: aFile face := FreeTypeFace basicNew fileContentsExternalMemory: externalMem . Example 3 -- HandMorph>>#moveToEvent: anEvent self handleEvent: (MouseMoveEvent basicNew setType: #mouseMove startPoint: self position endPoint: anEvent position trail: (Array with: self position with: anEvent position) buttons: anEvent buttons hand: self stamp: anEvent timeStamp) Should we be pushing these sort of basicNew + instance-side-method-call to the class side? Or do I have the wrong end of the stick? cheers -ben

May 27, 2017

Re: [Pharo-dev] Iceberg ?

by Ben Coman

On Fri, May 26, 2017 at 5:31 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > again, ssh-agent is one way to authenticate. > it can be not the best but it is the only one we could implement with the > time we get (also, ssh-agent is âcommonâ while others are platform specific > and then they will work just in the intended platform). With time, we want > to implement all, but for now is what we have. > > One way to solve this *without* using ssh-agent (for example, something we > recommend now for windows, since ssh-agent has problems for people not used > to it) is to use âcustom keysâ, which now in iceberg is done in settings > (as explained on the FAQ), or running this: > > IceCredentialsProvider useCustomSsh: true. > IceCredentialsProvider sshCredentials > publicKey: '/Users/esteban/.ssh/id_rsa.pubâ; > privateKey: '/Users/esteban/.ssh/id_rsaâ > > of course, you need to modify paths to your user :) > of course (2), you may add that to a startup action, so you do not need to > execute that each time. > Maybe in some quick-start instructions this should be the default, so people can prove to themselves it works, then move on to using ssh-agent which has more modes of failure. Other apps like PuTTY do this... https://developers.openshift.com/images/overview-ssh-putty-configure-4.png btw, I'm curious why the pub key is required? Isn't it only needed at the other (github) end? cheers -ben > cheers, > Esteban > > On 25 May 2017, at 22:12, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > I retried > rename all the keys I put in my git account. > > But > > ssh-add -K ~/.ssh/github_rsa > Error connecting to agent: No such file or directory > > ssh-add -K ~/.ssh/2016RSA > Error connecting to agent: No such file or directory > > Apparently I should run > > eval `ssh-agent -s` > > Now I will try to republish on github. > anyway I'm not using git in pharo for now. > > Stef > > On Thu, May 25, 2017 at 8:20 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> > I do not get why I can use github all the time and not with pharo. >> >> That is an excellent question >> >> Alexandre >> >> > >

May 27, 2017