Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

gather system profile info #691

Open
incanus opened this Issue · 21 comments

5 participants

@incanus
Admin

Background here:

#605 (comment)

Sparkle sends anonymous profile info via the query string.

https://github.com/andymatuschak/Sparkle/wiki/system-profiling

Something like this:

http://you.org/app.xml?cpusubtype=4&ncpu=2&appName=App.app&cpuFreqMHz=1830[…]

Currently, gh-pages can't give us these stats. One idea would be a page hosted elsewhere which can log query string details, then redirect the user to the gh-pages page.

@incanus
Admin

Started looking into this again. Thinking maybe a URL shortener with stats tracking might do the trick, but can't find one that supports query strings yet.

Also, we can provide custom info here. Is there any additional data about a user's setup that would be useful? e.g., number of projects, render buffer preference, etc.?

/cc @willwhite @springmeyer @kkaefer

@incanus incanus referenced this issue
Closed

32-bit support #918

@springmeyer
Admin

great, lets get this working. arch, # cores, amount of memory would be nice to know. user data on tilemill projects seems outside the scope of a basic system profile.

@incanus incanus was assigned
@springmeyer
Admin

bump

@incanus
Admin

Ok, the page for this is live and you can build the Mac client with 22ea306 if you want to try reporting to it. @willwhite pointed out that @yhahn had a good idea, which was to call this Google Analytics code from within node directly, which will obsolete the need for a dedicated, but invisible, WebView in the Mac app, the need for the page on the backend, and will allow stats gathering on all platforms. We'll just need to duplicate the Sparkle profiling routines on other platforms.

@springmeyer
Admin

Woot!

@incanus
Admin

Needs some formatting tweaks, but profile events are now showing up in Google Analytics based on the dev app launches that I've performed. Almost set here.

@willwhite
Admin

Nice Justin! Are you going to look at moving this into node? If not, I can take a look at this later on.

Resources:

Can't find anything that will give us arch right now, but I do see it in the node 0.6 docs. http://nodejs.org/docs/latest/api/process.html#process.arch

@springmeyer
Admin

I doubt process.arch will give us the detail we need. Also it does not appear to be available until node v0.6.

@willwhite
Admin

Yes I mentioned that it's in the node 0.6 docs only. What detail is missing?

@springmeyer
Admin

Well, if I remember right dropping 32 bit support would drop support for only "Core 2" era processors which cannot run 64 processes like "Core 2 Duo" chips can and the i5/i7 series (of course), so the bump of mine of this ticket was driven by #918 and potentially getting stats on the # of "Core 2" users.

Process.arch might work, just hard to know without getting our hands on a "Core 2" chip. Perhaps our dual arch tilemill builds will report 64bit on all machines except "Core 2" - that would be nice.

@willwhite
Admin

Looks like we have the same limitation with Sparkle: https://github.com/andymatuschak/Sparkle/blob/master/SUSystemProfiler.m#L76

@willwhite willwhite was assigned
@willwhite willwhite referenced this issue from a commit
Will White Submit system profile using GA. Refs #691. 9074fa5
@willwhite willwhite referenced this issue from a commit
Will White Default profile to true. Refs #691. 2b75a42
@yhahn
Admin

@willwhite it looks like webkitgtk doesn't support a persistent disk cache in the 1.x series but the 2.x branch which is still in development will have an easy to use API. I'm wondering if we should punt on this and

  1. Remove our custom guid, letting windows/mac users get reported accurately.
  2. Leave it a known issue that our linux stats (which I'm hoping will be trivially low / me and AJ now that we have a windows version) are inaccurate.
  3. Consider it a TODO to come back to implementing a persistent cache once webkitgtk2 is stabilized.
@willwhite willwhite referenced this issue from a commit
Will White Remove guid. Refs #691. 0ea3a34
@willwhite willwhite closed this
@willwhite
Admin

Done! That was a pretty old ticket.

@incanus
Admin

Are we getting architecture here (32/64-bit)? That's the one critical bit that we actually need right now, and that was the impetus for this ticket.

@incanus incanus reopened this
@willwhite
Admin

We're not able to get arch easily in node 0.4 but we'll take advantage of the new API for it in node 0.6.

@yhahn
Admin

Cool, removing from milestone.

@incanus
Admin

Just a ping here on three fronts:

  1. We don't really need architecture info anymore as we've dropped 32-bit support for 0.9.1dev.
  2. RAM is still reporting off, e.g., I have 8GB but it shows 8.6GB in the about box.
  3. How are collected stats looking? Is this working?
@misterboo

you drop 32bit support for tilemill?

@incanus
Admin

@springmeyer can confirm, but I believe we only did this on the OS X side, @misterboo.

@springmeyer
Admin

Right, we are not really dropping 32 bit support from any code other than the objc UI wrapper used on os x. What we are doing is moving to only offering a 64 bit build for the Mac installer. Linux and windows remain unchanged. @misterboo That sound okay?

@misterboo

yes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.