steal.dev.log() chokes arguments

[p3k]

steal.dev.log() chokes arguments

[lastzero]

Good point, but I'm not sure if steal.dev.log is really supposed to be a replacement for console.log(). I've been using http://benalman.com/projects/javascript-debug-console-log/ recently. I'll leave this ticket open for further discussions...

[p3k]

I made the changes in my fork and issued a pull request. Unfortunately, that went into another issue #22 here.

[p3k]

Re “replacement for console.log()”: I strongly encourage communicating steal.dev.log() as such – it is definitely worthwhile to have a logging method that can be easily switched off and does not affect unsupporting browsers.

[lastzero]

The thing is, that calls to steal.dev.log are automatically removed when the production file is built. So it's not like other loggers that just change the log level in production mode. I don't know yet how this is done, but it seems that removing the logger calls sometimes does not work (maybe another reason for just using one argument, so that the pattern for recognizing the calls is easier). I'll have a look into that.

[p3k]

Oh, I see. That could be a possible obstacle for my changes... Would be glad to hear from your findings.

[lastzero]

I can confirm that the calls to steal.dev.* are removed using a regex. This breaks under certain conditions, for example when there are brackets in the call like steal.dev.log('something()'); - this must be fixed, even though multiple arguments don't seem to be a problem.
One option is not to remove.steal.dev.log automatically anymore, but just if it's wrapped in @steal-remove. Also we could use a token based parser (maybe remove the calls using google closure or YUI compressor). I'm currently waiting for feedback.

Yes, the answer to this is ...

1. Handle opera only allowing one value.
2. Use a parser similar to how pluginify works. Pluginify uses a token based parsers. I've been working on separating it out and making it more generally useful.

Tonight, I will make a steal/parse. Currently it allows things like:

var parse = steal.parse("source string");
parser.until(["steal",".","dev",".","log","("]);
parser.partner(")", function(token){
  // called with every token until the matching ) is found (.  It counts pairs.
})

[lastzero]

1. At least the latest version of Opera supports multiple arguments, but it doesn't display the structure of objects, just [object]. IMO we can ignore problems with opera.postError - that case, only the first agument is shown, so what?
2. Great! However, additionally to a steal.dev.log that gets removed in production.js, I'm sure some developers (including me) would like to see a logger in JMVC that does not get removed in production mode (useful, if logs are dynamically generated and/or come from the server that has it's own dev/prod mode). I guess it should be named steal.log/warn/error. steal.dev.log/warn/error would then just be a reference to that function. What do you think about this?

On 2, I'm not sure because steal/dev is loaded implicitly by steal itself and ignored while compressing. This is the core feature of steal.dev.log - it's ability to vanish. There are other loggers that people can use that don't have this feature but provide other things (blackbird).

It might be possible to package a similar logging tool in JMVC.

I added steal.parse. You can pass it the contents of the file and use it to find steal.dev.log(.

Something like this would work:

var positions = [],
     p = steal.parse(CONTENTS),
     tokens;
while(tokens = p.until(['steal', '.', 'dev', '.', 'log' , "("]) ){
  var end = p.partner('(')
  positions.push({start: tokens[0].from, end: end.to})
}

// go through positions backwards and splice out steal.dev.log

if this isn't clear ...

p.until parses until it finds those tokens. It returns those tokens when it finds them.

p.partner parses until it finds a matching ) for the current (.

I push the locations of the start of steal to the end of the ).

You should then go backwards through these and substring the start and end out of contents. You need to start at the end and move the the beginning our start / end won't have the right values.

[lastzero]

Yes, a common logger for JMVC projects is what we need :) Right now people look at the docs, use steal.dev.log, run into trouble (parsing/multiple args/....), and then use the next best class they can find on Google. One major problem is the injection of a logger into external classes:

You can imagine that this fails badly, when steal.dev.log is gone. Of course you can wrap steal.dev.log so that it's safe to remove, but then the wrapper will still be there after removal of steal.dev.log and so are all the if's for conditional logging. All the code that uses that wrapper will still be there (and this actually is what you wanted to remove). There are use cases for a steal.dev.log that gets removed, but it's not the end of the story and a Web development framework should certainly offer a common API for logging for all users. Otherwise we should officially recommend blackbird or debug.log, so that new JMVC devs don't have this figure this all out themselves and it's easier to exchange source (that doesn't break). I think steal.dev.log as it is now, is perfect for JMVCs internal code, but not for all the applications out there.

PS: I'll have a look at the parser later... we are moving downtown today!

[moschel]

Fixed both issues here: 1) you can pass any args to it, and it should work cross browser and 2) you can add any parens inside the arguments and they'll be removed like steal.dev.log(foo()). Let me know if you find any problems.

[lastzero]

Wow, thank you Brian! Sorry, I had this on my todo list, but never finished the work...