For fun and to attract people to hacking Node, I'm going to occasionally post little tasks to the mailing list. If you do this, please create a patch against HEAD and post it to this mailing list. I'll wait a week for someone to do them before doing it myself :)
You might have noticed a bunch of debug() calls sprinkled about src/node.js and other core code. Because our debugging options are so few, this is one of the few ways of inspecting what the program is doing (especially when error reporting breaks!). Here is an example of debug() being used:
var debugLevel = 0; if ("NODE_DEBUG" in process.env) debugLevel = 1;
function debug (x) { if (debugLevel > 0) { process.stdio.writeError(x + "\n"); } }
Pretty simple stuff.
The problem is that these debug calls are not free to make. Even when the environmental variable is not present node will execute those function calls - that is they actually slow down execution.
The task is to remove these calls with the preprocessor in the non-debug build.
The JS2C already supports MACROS - so it should just be a matter of figuring out how to use it properly. I suspect this requires a bit of python and a bit of javascript knowledge and would take a couple of hours to complete.
> For fun and to attract people to hacking Node, I'm going to > occasionally post little tasks to the mailing list. If you do this, > please create a patch against HEAD and post it to this mailing list. > I'll wait a week for someone to do them before doing it myself :)
> You might have noticed a bunch of debug() calls sprinkled about > src/node.js and other core code. Because our debugging options are so > few, this is one of the few ways of inspecting what the program is > doing (especially when error reporting breaks!). Here is an example > of debug() being used:
> var debugLevel = 0; > if ("NODE_DEBUG" in process.env) debugLevel = 1;
> function debug (x) { > if (debugLevel > 0) { > process.stdio.writeError(x + "\n"); > } > }
> Pretty simple stuff.
> The problem is that these debug calls are not free to make. Even when > the environmental variable is not present node will execute those > function calls - that is they actually slow down execution.
> The task is to remove these calls with the preprocessor in the non-debug build.
> The JS2C already supports MACROS - so it should just be a matter of > figuring out how to use it properly. I suspect this requires a bit of > python and a bit of javascript knowledge and would take a couple of > hours to complete.
On Fri, Mar 19, 2010 at 10:50 AM, Zoka <ztomi...@gmail.com> wrote: > Hi Ryan,
> Have look at patch at http://gist.github.com/337907 > It will eliminate debug(x) statements from src/node.js and lib/*.js > for release build
> Zoka
Zoka, nice!
Instead of writing out that marcos file, it would be nice to just have src/macros.py and pass a value to it indicating whether it's a debug built or not. JS2C supports this.
As far as I could see JS2C supports only 2 types of files: javascript files and macros definition file that must be named macros.py
macros.py extension is bit misleading, since it is more or less replacement for C style header file that is parsed by JS2C. Have a look deps/v8/src/macros.py - it only contains constants and macros definitions. Am I missing something obvious?
On Mar 20, 6:34 am, Ryan Dahl <coldredle...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 10:50 AM, Zoka <ztomi...@gmail.com> wrote: > > Hi Ryan,
> > Have look at patch at http://gist.github.com/337907 > > It will eliminate debug(x) statements from src/node.js and lib/*.js > > for release build
> > Zoka
> Zoka, nice!
> Instead of writing out that marcos file, it would be nice to just have > src/macros.py and pass a value to it indicating whether it's a debug > built or not. JS2C supports this.
On Fri, Mar 19, 2010 at 1:59 PM, Zoka <ztomi...@gmail.com> wrote: > As far as I could see JS2C supports only 2 types of files: > javascript files and macros definition file that must be named > macros.py
> macros.py extension is bit misleading, since it is more or less > replacement for C style header file that is parsed by JS2C. > Have a look deps/v8/src/macros.py - it only contains constants and > macros definitions. > Am I missing something obvious?
Oh true. Okay, I want to avoid writing out a macros file - I'd rather have it included as a standalone file. Do you agree? (I could be convinced otherwise.) What if we have src/macros-default.py and src/macros-debug.py, each used for their respective builds.
JS2C stipulates that macros file name has to be macros.py
Since debug and release build are processed together, it means that we would have to have src/debug/macros.py and src/default/macros.py, but it looks a bit funny.
Other possibility is to just supply macros file for default (release) build, and not to supply it for debug build at all, however this is asymmetrical and does not allow for future expansion.
On Mar 20, 8:19 am, Ryan Dahl <coldredle...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 1:59 PM, Zoka <ztomi...@gmail.com> wrote: > > As far as I could see JS2C supports only 2 types of files: > > javascript files and macros definition file that must be named > > macros.py
> > macros.py extension is bit misleading, since it is more or less > > replacement for C style header file that is parsed by JS2C. > > Have a look deps/v8/src/macros.py - it only contains constants and > > macros definitions. > > Am I missing something obvious?
> Oh true. Okay, I want to avoid writing out a macros file - I'd rather > have it included as a standalone file. Do you agree? (I could be > convinced otherwise.) What if we have src/macros-default.py and > src/macros-debug.py, each used for their respective builds.
