On Fri, Apr 1, 2016 at 10:08 AM, Tom Browder wrote:
> On Fri, Apr 1, 2016 at 9:39 AM, Timo Paulssen wrote:
>> The profiler's data blob is a massive, gigantic blob of json (ls the file
>> and you'll see).
>
> Ah, yes: a 2.8+ million character line!
...
>
Not sure I understand the disagreement.
"the correct buffer size is often per file, not per
program/invocation, so a one-size-fits-all envar is the wrong
approach"- if you're saying "it would be great to have the buffer size
be an option to 'open'," then I agree. It would be nice to have that
On Fri, Apr 1, 2016 at 11:09 AM, yary wrote:
> Setting the buffer size is better done by the user, not the
> programmer. Often the user and the programmer are one and the same, in
> which case, the programmer knows the environment and can set the
> environment variables- or
On 01/04/16 17:08, Tom Browder wrote:
Alternatively, there's a qt-based profiler up on tadzik's github that can
read the json blob (you will have to --profile-filename=blahblah.json to get
that), but it doesn't evaluate as much of the data - it'll potentially even
fail completely what with
Actually I would characterize it as
Before:
The programmer had no control over the buffer size, and the user of
the code had no way of adjusting the buffer to a particular system.
Currently:
The programmer has control over the buffer size, and the user of the
code can adjust the buffer to a
The profiler's data blob is a massive, gigantic blob of json (ls the
file and you'll see).
You can easily search the urls to point at local files instead
of the CDN.
Alternatively, there's a qt-based profiler up on tadzik's github that
can read the json blob (you will have to
Is there any easy way to get the profilers to use local code (css, js,
etc.) rather than reading across a sometimes slow internet connection?
I'm using both Chrome and Iceweasel with the same effects: slow
loading scripts and always seem to be reading:
On Fri, Apr 1, 2016 at 2:00 PM, Elizabeth Mattijsen wrote:
> Sorry if I wasn’t clear: If there is no dynamic var, it will make one:
> either from the environment, or set it to 64K (like it was before). So no
> programmer action is ever needed if they’re not interested in that
> On 01 Apr 2016, at 13:50, Jan Ingvoldstad wrote:
>
> On Thu, Mar 31, 2016 at 10:36 AM, Elizabeth Mattijsen wrote:
> > The reasoning behind _not_ setting things via environment variables, is
> > that this means the programmer now needs to worry what e.g.
On Thu, Mar 31, 2016 at 10:36 AM, Elizabeth Mattijsen
wrote:
> > The reasoning behind _not_ setting things via environment variables, is
> that this means the programmer now needs to worry what e.g. the webserver
> running the Perl program does, and there are unknown stability
10 matches
Mail list logo