Hmm, well maybe my lossage had to do with me invoking the Profiler start/stop using a mouse click handler. That might have caused some kind of race condition in the IE7 engine, between the profiler task running on the timer and a manual event calling Profiler.stop. I'll use your tool to avoid invoking the profiler via the mouse.
On Thu, May 7, 2009 at 1:46 PM, Henry Minsky <[email protected]> wrote: > No it works in Firefox on OSX, something is screwing up in IE7. WHen I look > at the data packets, there is something odd. The chunks have plausible data, > but then one of the chunks just has "</xml>" in it, and that is not the > last sequence number of data that gets sent (i.e., it is seqnum=3, and then > there's more data in seqnum=4 packet).. > > > On Thu, May 7, 2009 at 1:43 PM, P T Withington <[email protected]> wrote: > >> Where are you trying this? Because the code that I wrote below worked >> fine for me. >> >> Is it possible your changes to move the URL construction out of the >> profiler somehow affected the ability to restart the profiler? >> >> >> On 2009-05-07, at 13:39EDT, Henry Minsky wrote: >> >> I am having difficulty getting the profiler to start up again. If I load >>> the >>> main.lzx app with profiling on,and then call Profiler.start [I had a >>> clickable view to invoke Profiler.start() , I am not getting any >>> new output to the main.profiler file. >>> >>> Even in a simple test case, like this >>> >>> <canvas> >>> <view width="40" height="40" bgcolor="red" onclick="Profiler.stop(); >>> alert('stop profiler');"/> >>> <view width="40" height="40" bgcolor="green" onclick="alert('start >>> profiler'); Profiler.start();"/> >>> </canvas> >>> >>> The new profiler file does not get written out. In a trace of HTTP >>> request >>> via Fiddler, I see all >>> the profiler data chunks go out, and the close packet is sent. Just for >>> some reason the new profiler >>> output file is not getting written on the server. WTF? >>> >>> >>> >>> On Thu, May 7, 2009 at 12:52 PM, P T Withington <[email protected]> wrote: >>> >>> Here's a hack that I wrote that waits for the instantiator to settle >>>> out, >>>> then profiles for a bit. You could use this to make a profile of a >>>> running >>>> application use case: >>>> >>>> <text id="myoutput" multiline="true" /> >>>> >>>> <handler name="oninited"> >>>> LzTimeKernel.setTimeout(function () { >>>> if (lz.Instantiator.isUpdating) { >>>> // If the instantiator is still running, just requeue ourselves >>>> LzTimeKernel.setTimeout(arguments.callee, 10 * 1000); >>>> } else { >>>> // Wait a bit for things to settle >>>> LzTimeKernel.setTimeout(function () { >>>> myoutput.bringToFront(); >>>> myoutput.format("LzIdleKernel.__callbacks: %w\n", >>>> LzIdleKernel.__callbacks); >>>> myoutput.addFormat("lz.Idle.coi: %w\n", lz.Idle.coi); >>>> if ($profile) { >>>> Profiler.stop(); >>>> myoutput.addFormat("Starting profiling..."); >>>> Profiler.start(); >>>> // Profile for 40 seconds >>>> LzTimeKernel.setTimeout(function () { >>>> Profiler.stop(); >>>> myoutput.addFormat(" done!\n"); >>>> }, 40 * 1000); >>>> } >>>> }, 10 * 1000); >>>> } >>>> }, 10 * 1000); >>>> </handler> >>>> >>>> >>>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >>> >> >> > > > -- > Henry Minsky > Software Architect > [email protected] > > > -- Henry Minsky Software Architect [email protected]
