On 02/28/2013 07:29 PM, bernhardr...@gmail.com wrote:
just to keep this thread up to date. I asked jduell if it is possible to change
long to int64_t
We're going to upgrade to 64 bits in
https://bugzilla.mozilla.org/show_bug.cgi?id=846629
Jason
___
Robert Kaiser wrote:
Taras Glek schrieb:
I doubt people actually want to build own dashboards. I suspect this is
mainly a need because of deficiencies in the current dashboard.
I disagree. I think people will want to integrate Telemetry data in
dashboards that connect data from different sou
just to keep this thread up to date. I asked jduell if it is possible to change
long to int64_t
Am Freitag, 1. März 2013 04:11:40 UTC+1 schrieb bernha...@gmail.com:
> Yep, you are right. I assumed nsIRequest would be the only file assigning
> these values.
>
>
>
> What numbers should i choose?
Yep, you are right. I assumed nsIRequest would be the only file assigning these
values.
What numbers should i choose? I need 2 flags and unsigned long only provides 32
possibility which are already used (except 25)
For me it would be ok to just fix the cookies issue :) But i guess there is a
r
On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote:
i have run hg pull and hg update on mozilla central and still have no
LOAD_DOCUMENT_URI.
Are you looking in the right file?
The problem seems to be that this patch breaks the WHOLE Cookie handling of
firefox.
Because your LOAD_NO_COOKIES h
i have run hg pull and hg update on mozilla central and still have no
LOAD_DOCUMENT_URI. But i can skip 18 if you want.
i have a first draft of my patch: (see link below)
The problem seems to be that this patch breaks the WHOLE Cookie handling of
firefox. (at least it fixes my original sync bug
(2013/02/27 22:35), ISHIKAWA, Chiaki wrote:
(2013/02/27 0:53), Neil wrote:
ishikawa wrote:
By the way, does looking at IDL header/declaration files help me to figure out
where the double is returned?
You would have to peek in the locals on the stack to find out exactly
which interface is be
Taras Glek schrieb:
I doubt people actually want to build own dashboards. I suspect this is
mainly a need because of deficiencies in the current dashboard.
I disagree. I think people will want to integrate Telemetry data in
dashboards that connect data from different sources, and not just
Tel
Benjamin Smedberg schrieb:
Because the raw crash files do not include new metadata fields, this has
led to weird engineering practices like shoving interesting metadata
into the freeform app notes field, and then parsing that data back out
later. I'm worried about perpetuating this kind of behavi
On Thursday, February 28, 2013 9:57:04 AM UTC-8, Taras Glek wrote:
> Justin Lebar wrote:
>
> > It sounds to me like people want both
>
> >
>
> > 1) Easier access to aggregated data so they can build their own
>
> > dashboards roughly comparable in features to the current dashboards.
>
>
>
>
On Wednesday, February 27, 2013 12:52:10 PM UTC-5, Josh Aas wrote:
> I've been thinking about how we might improve access to telemetry data. I
> don't want to get too much into the issues with the current front-end, so
> suffice it to say that it isn't meeting my group's needs.
>
>
A few peopl
- Original Message -
> From: "Justin Lebar"
> To: "Benjamin Smedberg"
> Cc: "Benoit Jacob" , "Josh Aas"
> , dev-platform@lists.mozilla.org
> Sent: Thursday, February 28, 2013 9:14:52 AM
> Subject: Re: improving access to telemetry data
>
> It sounds to me like people want both
>
> 1) E
Justin Lebar wrote:
It sounds to me like people want both
1) Easier access to aggregated data so they can build their own
dashboards roughly comparable in features to the current dashboards.
I doubt people actually want to build own dashboards. I suspect this is
mainly a need because of def
On Thursday, February 28, 2013 12:14:52 PM UTC-5, Justin Lebar wrote:
> That is, I don't think we can or should export JSON with all the data
> in our databases. That is a lot of data.
We currently have a little over 20 TB of compressed telemetry documents stored
in HBase. The compression is LZ
It sounds to me like people want both
1) Easier access to aggregated data so they can build their own
dashboards roughly comparable in features to the current dashboards.
2) Easier access to raw databases so that people can build up more
complex analyses, either by exporting the raw data from the
On 2/28/2013 10:59 AM, Benoit Jacob wrote:
Because the raw crash files do not include new metadata fields, this has
led to weird engineering practices like shoving interesting metadata into
the freeform app notes field, and then parsing that data back out later.
I'm worried about perpetuating thi
On 2013-02-28, at 10:44 AM, Benjamin Smedberg wrote:
> On 2/28/2013 10:33 AM, Benoit Jacob wrote:
>> Please, please make your plans include the ability to get raw text files
>> (CSV or JSON or something else, I don't care as long as I can easily parse
>> it).
> Could you be more specific? Note th
On Thu, Feb 28, 2013 at 10:36 AM, Benjamin Smedberg
wrote:
> Cool. Perhaps we should start out with collecting stories/examples:
>
In that spirit:
What I almost always want to do is simply "for the last N days of
variable X show me a CDF (at even just 10 percentile granularity) for
the histogra
2013/2/28 Benjamin Smedberg
> On 2/28/2013 10:33 AM, Benoit Jacob wrote:
>
>> Please, please make your plans include the ability to get raw text files
>> (CSV or JSON or something else, I don't care as long as I can easily parse
>> it).
>>
> Could you be more specific? Note that while the text fi
On 2/28/2013 10:33 AM, Benoit Jacob wrote:
Please, please make your plans include the ability to get raw text files
(CSV or JSON or something else, I don't care as long as I can easily parse
it).
Could you be more specific? Note that while the text files currently
provided on crash-analysis, the
On 2/28/2013 10:18 AM, Josh Aas wrote:
On Thursday, February 28, 2013 8:16:50 AM UTC-6, Benjamin Smedberg wrote:
Have we discussed this project with the metrics team yet?
When I started looking into this it wasn't clear to me that people really knew
what they wanted
Cool. Perhaps we should s
Please, please make your plans include the ability to get raw text files
(CSV or JSON or something else, I don't care as long as I can easily parse
it). I don't have use for the current frond-end, and I believe that no
front-end will cover everyone's needs, and not every developer is familiar
with
On Thursday, February 28, 2013 8:16:50 AM UTC-6, Benjamin Smedberg wrote:
> Have we discussed this project with the metrics team yet?
When I started looking into this it wasn't clear to me that people really knew
what they wanted - they just knew why the existing system didn't work for them.
My
On 2/27/2013 12:52 PM, Josh Aas wrote:
The top priority for exposing telemetry data is an easy-to-use API.
Secondarily, there should be a default front-end.
I have used the telemetry data for only very specific purposes, and in
those cases it turns out that the existing frontend was absolutely
On 2/28/2013 12:42 AM, saur m wrote:
> Hello everyone,
> I have successfully built the firefox from the source code. Now I
> have created the installer usng command
>
> c:/mozilla-central/build/pymake/make.py installer
>
> But when I am trying to install the firefox on other system , it
On Thu, Feb 28, 2013 at 02:52:23AM -0800, saur m wrote:
> I also tried copying dll files from my build system to other test
> system but still no successful results. Still getting same error. Any
> ideas???
In
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prer
I also tried copying dll files from my build system to other test system but
still no successful results. Still getting same error. Any ideas???
On Thursday, February 28, 2013 11:12:40 AM UTC+5:30, saur m wrote:
> Hello everyone,
>
> I have successfully built the firefox from the source
27 matches
Mail list logo
