not found message.

[oblitum]

Line main.go#L61 will just print "not found" since the src is tested to be empty.

By the way, I'm trying to test logxi but "not found" is just what I'm getting on OS X. I believe godo may not be working on OS X.

[mgutz]

I apologize. I code on OS X. logxi is using godo v2 which is currently on my machine and addresses issues with v1. I will be doing a release later this week. I just need to work on documentation.

[oblitum]

@mgutz ok thanks, I find the idea of logxi great, the only sad part is about trying some self-contained sample. I'm trying to run tests to check this, but some simple self-contained examples without any editing for compiling and running would be good.

[mgutz]

cd $GOPATH/src/github.com/mgutz/logxi/v1/cmd/demo
go run main.go
LOGXI=* go run main.go

[oblitum]

@mgutz ah, I'm sorry, as I got a callstack like the following:

16:15:29.096609 WRN models Could not connect, retrying ... dsn: dbname=testdb
   in: main(main.go:32)
16:15:29.097692 ERR server Could not read config file err: file not found
   /Users/francisco/.go/src/github.com/mgutz/logxi/v1/jsonFormatter.go:48 (0x6078f)
        (*JSONFormatter).writeError: jf.set(buf, CallStackKey, string(debug.Stack()))
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/jsonFormatter.go:87 (0x60b1f)
        (*JSONFormatter).appendValue: jf.writeError(buf, err)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/jsonFormatter.go:114 (0x6130c)
        (*JSONFormatter).set: jf.appendValue(buf, val)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/jsonFormatter.go:145 (0x61930)
        (*JSONFormatter).Format: jf.set(buf, key, args[i+1])
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/jsonFormatter.go:166 (0x61ccc)
        (*JSONFormatter).LogEntry: jf.Format(buf, level, msg, args)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/happyDevFormatter.go:274 (0x5e0bb)
        (*HappyDevFormatter).Format: entry := hd.jsonFormatter.LogEntry(level, msg, args)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/defaultLogger.go:104 (0x5a2c0)
        (*DefaultLogger).Log: l.formatter.Format(l.writer, level, msg, args)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/defaultLogger.go:81 (0x5a010)
        (*DefaultLogger).extractLogError: return err
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/defaultLogger.go:89 (0x5a11b)
        (*DefaultLogger).Error: return l.extractLogError(LevelError, msg, args)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/cmd/demo/main.go:21 (0x21ac)
        loadConfig: logger.Error("Could not read config file", "err", errConfig)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/cmd/demo/main.go:33 (0x262c)
        main: loadConfig()
/usr/local/Cellar/go/1.4.2/libexec/src/runtime/proc.go:63 (0x13903)
        main: main_main()
/usr/local/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 (0x387e1)
        goexit:

I didn't notice the log at the top, and tought the sample was just broken.

[mgutz]

Do an update. I just updated about 15 minutes ago with a simpler default stack to remove logxi related entries. I didn't realize that was confusing people.

You can also try LOGXI_FORMAT=pretty

[oblitum]

@mgutz another down point I have about it is that it requires Go 1.3, which isn't available in Ubuntu 14.10 standard repositories. Because of this, at my job, I would need to convince the buddies to forget about distro defaults regarding Go. Not sure wheter I'll achieve this... But it's a good thing to do anyway. But in any case, if it worked on 1.2 it would be good too. You may be interested in adding requirements to README.

Sorry for the off-topic.

[oblitum]

@mgutz just updated, is it expected to get this callstack?

16:22:56.274622 WRN models Could not connect, retrying ... dsn: dbname=testdb
   in: main(main.go:32)
16:22:56.275839 ERR server Could not read config file err: file not found
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/cmd/demo/main.go:21 (0x21ac)
        loadConfig: logger.Error("Could not read config file", "err", errConfig)
/Users/francisco/.go/src/github.com/mgutz/logxi/v1/cmd/demo/main.go:33 (0x262c)
        main: loadConfig()
/usr/local/Cellar/go/1.4.2/libexec/src/runtime/proc.go:63 (0x13903)
        main: main_main()
/usr/local/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 (0x387e1)
        goexit:

[mgutz]

Yes, those are all simulated errors from the demo. The error stack is raw. You have to use pretty if you want the runtime entries to be removed.

[mgutz]

I'm closing this. Please create a new issue on logxi if there are more issues.

[oblitum]

@mgutz Nice. About closing, this issue in truth is solely to warn about the empty src while printing, which seems non-intentional.

[mgutz]

You're right. I'll look into this before I release v2.

[oblitum]

@mgutz ok, just one more question. You're using gopkg.in for godo, but for logxi you're using a different kind of internal directory based versioning. And the package name not matching the import line looks non-conventional. Are you planning any change on that or you're just starting to adopt some new package pattern?

[mgutz]

I'm going with the simplest method and just using v1, v2 directories. The problem with gopkg.in is it doesn't work with subpackages unless I rewrite all my import paths. With subdirecotires, go get github.com/mgutz/logxi/v1 always works without a gopkg.in redirection. Seems like I'm back to subversion but it works.

[oblitum]

@mgutz Interesting! Just when I looked at this I thought about whether two possible improvements would work:

• use logxi.v1 directories, so that logxi named package and import line matched.
• turn logxi.v1, logxi.v2, ... into submodules.

[oblitum]

By the way, this pattern is rather different from what I see elsewhere, but if it works, ok, may be a better way out for versioning.

[oblitum]

If adopting .vN dirs as submodules worked, you would be back to DVCS.

[oblitum]

Also, more in line with what you're already doing regarding subdirectory names. Having a packaged named logxi instead of log for a logxi/v1 import is much less surprising.

[oblitum]

Ah anyway, I guess go get won't work with submodules, etc. Nevermind.