How do you turn off DEBUG/WARNING messages in the Compiler? #74

Closed
cohen72 opened this Issue Apr 29, 2013 · 10 comments

Projects

None yet

5 participants

@cohen72
cohen72 commented Apr 29, 2013

Any way to disable these messages from appearing in the compiler? Its super annoying ;)

For example ....

[SVGSVGElement] WARNING: SVG spec says we should calculate the 'intrinsic aspect ratio'. Some badly-made SVG files work better if you do this and then post-multiply onto the specified viewBox attribute ... BUT they ALSO require that you 're-center' them inside the newly-created viewBox; and the SVG Spec DOES NOT SAY you should do that. All examples so far were authored in Inkscape, I think, so ... I think it's a serious bug in Inkscape that has tricked people into making incorrect SVG files. For example, c.f. http://en.wikipedia.org/wiki/File:BlankMap-World6-Equirectangular.svg
[SVGSVGElement] DEBUG INFO: set document viewBox = {{0, 0}, {225, 225}}
[SVGKImage] DEBUG: Generating a UIImage using the current root-object's viewport (may have been overridden by user code): {0,0,225.000,225.000}
[SVGKImage] WARNING: no CALayer tree found, creating a new one (will cache it once generated)
[SVGKImage] rendering to CGContext: time taken to convert from DOM to fresh CALayers: 0.001 seconds)
[SVGKImage] DEBUG: rendering to CGContext using the current root-object's viewport (may have been overridden by user code): {0,0,225.000,225.000}
[SVGKImage] renderToContext: time taken to render CALayers to CGContext (perf improvements: NO-ANTI-ALIAS): 0.017 seconds)

@adamgit
Collaborator
adamgit commented May 1, 2013

Right now - there's no 1-liner to get rid of them, sorry.

Most of those messages should be deleted sooner or later, but represent issues someone is either currently investigating or trying to fix.

Personally, I'd like to move to a logging library that's better and lets you turn stuff on/off - any suggestions?

@dblandin
dblandin commented May 8, 2013

From what I've read, Lumberjack seems like a suitable Mac/iOS Logging framework with a few different logging methods including:

  • DDLogError
  • DDLogWarn
  • DDLogInfo
  • DDLogVerbose

You can then set the log level you want you want to receive:

If you set the log level to LOG_LEVEL_ERROR, then you will only see DDLogError statements.
If you set the log level to LOG_LEVEL_WARN, then you will only see DDLogError and DDLogWarn statements.
If you set the log level to LOG_LEVEL_INFO, you'll see Error, Warn and Info statements.
If you set the log level to LOG_LEVEL_VERBOSE, you'll see all DDLog statements.
If you set the log level to LOG_LEVEL_OFF, you won't see any DDLog statements.

Does this sound like a reasonable system to switch to? I'd be happy to help with the migration.

@adamgit
Collaborator
adamgit commented May 8, 2013

Lumberjack looks good. I'd be happy with it, but it looks like you'd need
to go replace all the existing NSLog statements :( which could take a
while!

Track the "1.1.0" branch, make the changes there, and if it works, we can
merge it for the 1.1.0 release (the branches are a little messed-up at the
moment, I'm aiming to fix that when we do an official 1.1.0)

On 8 May 2013 20:35, Devon Blandin notifications@github.com wrote:

From what I've read, Lumberjackhttps://github.com/robbiehanson/CocoaLumberjackseems like a suitable Mac/iOS Logging framework with a few different
logging methods including:

  • DDLogError
  • DDLogWarn
  • DDLogInfo
  • DDLogVerbose

You can then set the log level you want you want to receive:

If you set the log level to LOG_LEVEL_ERROR, then you will only see
DDLogError statements.
If you set the log level to LOG_LEVEL_WARN, then you will only see
DDLogError and DDLogWarn statements.
If you set the log level to LOG_LEVEL_INFO, you'll see Error, Warn and
Info statements.
If you set the log level to LOG_LEVEL_VERBOSE, you'll see all DDLog
statements.
If you set the log level to LOG_LEVEL_OFF, you won't see any DDLog
statements.

Does this sound like a reasonable system to switch to? I'd be happy to
help with the migration.


Reply to this email directly or view it on GitHubhttps://github.com/SVGKit/SVGKit/issues/74#issuecomment-17628698
.

@dblandin
dblandin commented May 8, 2013

Sounds good! I think there is a way to redefine NSLog using a preprocessor macro which may save some time.

Something like:

#define DDLogInfo NSLog
@adamgit
Collaborator
adamgit commented May 11, 2013

How soon do you think you'll try this?

I'm aiming to mark 1.1.0 as released soon (there's a lot of fixes in there now - e.g. resizing images is fixed, layout of G elements are fixed, viewboxes are fixed) - but I'd like to wait for your logging (if it works; it it goes wrong, fine, we can include it later).

Ideally I want 1.1.0 to be the "main" release for the next 6 months or so, so I'm trying to get all "important" changes included :)

@dblandin

Hey Adam,

That's exciting!

I'll give Lumberjack a go this weekend and let you know how it turns out.

@bogardon
bogardon commented Jun 4, 2013

any update on this?

@dblandin
dblandin commented Jun 4, 2013

Check out the pull request.

@adamgit
Collaborator
adamgit commented Jun 5, 2013

I've merged @dblandin 's commit - seems to work fine.

As noted in his commits, it's not perfect -- you have to change the LOG_LEVEL at compile-time. i.e. in your "SVGKit-iOS" project (note: not your app project, but the library project itself) open the file "SVGKit-iOS-Prefix.pch" and change the value of ddLogLevel (e.g. to LOG_LEVEL_WARN)

NB: now that we have this in place, there are probably a couple of log messages in the source code that need reclasssifying as "warn" or "error" etc. If you see messages in your log that you thikn shoudn't be there, please fix them separately and send pull requests

(all this is on the 1.1.0 branch)

@adamgit adamgit closed this Jun 5, 2013
@seltzered

I'm trying to re-visit this to update SVGKit (starting with madd_the_sane's osx fork) to the lumberjack 2.0 beta, and one thing I noticed is that the log levels are actually bitmasks, and outside the five reserved ones the rest is for other frameworks / code to use (see the comments in https://github.com/CocoaLumberjack/CocoaLumberjack/blob/master/Classes/DDLog.h#L320 & https://github.com/CocoaLumberjack/CocoaLumberjack/wiki/FineGrainedLogging & the example project lumberjack has https://github.com/CocoaLumberjack/CocoaLumberjack/tree/master/Demos/FineGrainedLogging ).

So, with that in mind, I'm thinking of trying the following:

  • remove any usage of custom methods that required modification of ddlog.m/h
  • add lumberjack as a submodule checked out to a version tag (git 1.8.2 from march 2013 supports this). Originally I wrote about deleting it but realized how much it's needed there to make testing easy.
  • update to lumberjack 2.0-beta (it's already in cocoapods as a dependency)
  • define a flag bit for svgkit somewhere ( svgkit.h or some svgkit-logging.h file ).

Just wondering if there's any reasons as to why this is a bad idea.

(update: I'm overthinking this. What was throwing me off originally was noticing methods like "DDLogWarnWarn" being made in commit 60cc8c4 , but apparently those methods aren't actually used anywhere in the code. Updating to 2.0 should be easier than I thought. This is specific to MaddTheSane's fork, but I'm planning to remove any original attempts to have an internal version that did a direct modification on ddlog.m/h back in MaddTheSane@9e893fc in favor of using an extra flag bit)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment