[pypy-commit] extradoc extradoc: updates to the blog post draft (addressed cfbolz's comments)

[plan_rich]

Author: Richard Plangger <planrichi at gmail.com>
Branch: extradoc
Changeset: r5661:37e031d5a693
Date: 2016-08-02 18:56 +0200
http://bitbucket.org/pypy/extradoc/changeset/37e031d5a693/

Log:	updates to the blog post draft (addressed cfbolz's comments)

diff --git a/blog/draft/new-jit-log.rst b/blog/draft/new-jit-log.rst
--- a/blog/draft/new-jit-log.rst
+++ b/blog/draft/new-jit-log.rst
@@ -1,18 +1,26 @@
-PyPy's Toolbox got a new Hammer &#x1f528;
+JitViewer moves to vmprof.com
 =======
 
-.. : XXX the title is very generic
+We are happy to announce that VMProf got a major update. The most significant change is the movement of JitViewer (JV)
+to VMProf.
+JV allows you to inspect PyPy's internal compiler representation including the generated machine code of your program.
+A useful tool to understand PyPy, learn many details of our compiler and find potential issues related to our JIT.
+Both VMProf and JV share some common goals. That is the reason why they are now both packaged together.
+www.vmprof.com also got updated with various bugfixes and changes including an all new interface to JV.
 
-.. : XXX I don't actually like the first paragraph, I think it should be more
-    to the point. eg that things happened at the Leysin sprint doesn't matter much.
-    I would also add links to all the existing tools
+A advertisment: We constantly improve tooling and libraries around the Python/PyPy eco system.
+Here are a three examples you might also want to use in your Python projects:
 
-Tools, tools, tools! It seems that PyPy cannot get enough of them!
-In the last winter sprint (Leysin) covered the current tool for observing internals of the JIT compiler (JitViewer). VMProf at that time already proved that it is a good tool for CPU profiles. We are happy to release a new version of VMProf incorporating a rewritten version of JitViewer.
+* VMProf - A statistical CPU profiler
+* RevDB - A reverse debugger for Python 
+* CFFI - Foreign Function Interface that avoids CPyExt
 
-The old logging format was a hard to maintain plain text logging facility. Frequent changes often broke internal tools, most notably the JITViewer. Another problem was that the logging output of a long running program took a lot of disk space.
+A brand new JitViewer
+---------------------
 
-Our new binary format encodes data densly, makes use of some compression (gzip) and tries to remove repetition where possible. On top of that protocol supports versioning and can be extended easily. And *drumroll* you do not need to install JitViewer yourself anymore! The whole system moved to vmprof.com and you can use it any time.
+The old logging format was a hard to maintain plain text logging facility. Frequent changes often broke internal tools, most notably JV. Additionaly the logging output of a long running program took a lot of disk space.
+
+Our new binary format encodes data densly, makes use of some compression (gzip) and tries to remove repetition where possible. On top of that protocol supports versioning and can be extended easily. And *drumroll* you do not need to install JV yourself anymore! The whole system moved to vmprof.com and you can use it any time.
 
 Sounds great. But what can you do with it? Here are two examples useful for a PyPy user:
 
@@ -21,19 +29,19 @@
 
 For some hard to find bugs it is often necessary to look at the compiled code. The old procedure often required to upload a plain text file which was hard to parse and to look through. 
 
-The new way to share a crash report is to install the ``vmprof`` module from PyPi and execute either of the two commands:
+A new way to share a crash report is to install the ``vmprof`` module from PyPi and execute either of the two commands:
 
 ```
 # this program does not crash, but has some weird behaviour
 $ pypy -m jitlog --web <your program args>
 ...
-PyPy Jitlog: http://vmprof.com/#/<hash>
+PyPy Jitlog: http://vmprof.com/#/<hash>/traces
 # this program segfaults
 $ pypy -m jitlog -o /tmp/log <your program args>
 ...
 <Segfault>
 $ pypy -m jitlog --upload /tmp/log
-PyPy Jitlog: http://vmprof.com/#/<hash>
+PyPy Jitlog: http://vmprof.com/#/<hash>/traces
 ```
 
 Providing the link in the bug report enables PyPy developers browse and identify potential issues.
@@ -41,7 +49,7 @@
 Speed issues
 ------------
 
-VMProf is a great tool to find out hot spots that consume a lot of time in your program. As soon as you have idenified code that runs slow, you can switch to jitlog and maybe pin point certain aspects that do not behave as expected. You will find not only the overview, but are also able to browse the generated code. If you cannot make sense of that all you can just share the link with us and we can have a look at the compiled code.
+VMProf is a great tool to find out hot spots that consume a lot of time in your program. As soon as you have idenified code that runs slow, you can switch to jitlog and maybe pin point certain aspects that do not behave as expected. You will find not only the overview, but are also able to browse the generated code. If you cannot make sense of that all you can just share the link with us and we can have a look at too.
 
 Future direction
 ----------------
@@ -52,7 +60,7 @@
 
 * Combination of CPU profiles and the JITLOG (Sadly did not make it into the current release)
 
-* Extend vmprof.com to be able to query vmprof/jitlog. Some times it is interesting to search for specific patterns the compiler produced. An example for vmprof: 'methods.callsites() > 5' and for the jitlog would be 'traces.contains('call_assembler').hasbridge('*my_func_name*')'
+* Extend vmprof.com to be able to query vmprof/jitlog. An example query for vmprof: 'methods.callsites() > 5' and for the jitlog would be 'traces.contains('call_assembler').hasbridge('*my_func_name*')'.
 
 * Extend the jitlog to capture the information of the optimization stage