May 2017 - Pharo-dev - lists.pharo.org

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

by phil＠highoctane.be

I am using a fork of the official thing and also build on appveyor, so, the stack is the same. Phil On Sun, May 28, 2017 at 4:41 PM, Milan Vavra via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Milan Vavra <vavra_milan(a)yahoo.com> > To: pharo-dev(a)lists.pharo.org > Cc: > Bcc: > Date: Sun, 28 May 2017 07:41:36 -0700 (PDT) > Subject: Re: [Vm-dev] multiple crashes on macOS Sierra > > I hope to find the reason why this happens. > > Good luck and, of course, if the problem goes away by using a custom > built debug build -- there's more fun in store trying to find out > if/what goes wrong with the optimizations used in the release build. > > Turning off optimizations with -O0 could be a first step to verify if > release build C compiler optimizations are to blame. > > Because the C compiler does optimize things and sometimes optimizes > things away that it should not. > > > Best Regards, > > Milan Vavra > > > > -- > View this message in context: http://forum.world.st/Re-Vm- > dev-multiple-crashes-on-macOS-Sierra-tp4948481p4948486.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

May 28, 2017

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

by Milan Vavra

> I hope to find the reason why this happens. Good luck and, of course, if the problem goes away by using a custom built debug build -- there's more fun in store trying to find out if/what goes wrong with the optimizations used in the release build. Turning off optimizations with -O0 could be a first step to verify if release build C compiler optimizations are to blame. Because the C compiler does optimize things and sometimes optimizes things away that it should not. Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Re-Vm-dev-multiple-crashes-on-macOS-Sierra-tp4948481p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017

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

by philippe.back＠highoctane.be

I got that too (windows). And that's also one reason why I made this thing. https://github.com/Pharophile/HOImageSaver I am actually running under a VM I built because that one is not mysteriously crashing and as I have an assert and debug version, I hope to find the reason why this happens. Yes it sucks the joy out. Phil Le 28 mai 2017 10:41, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > 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@ > 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 Sven Van Caekenberghe

> On 28 May 2017, at 10:39, Ben Coman <btc(a)openinworld.com> wrote: > > 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 Normally #basicNew is an implementation detail. It is however often used to prevent #initialize from happening (#new being #basicNew followed by #initialize). If that is the case, then it is probably a design error. Sven

May 28, 2017

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

by Esteban Lorenzano

> On 28 May 2017, at 10:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > 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? yes, but I never had it (and I use mac and I type fairly fast too). Esteban > > 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] [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