Tool similar to guard in go

[Andrew Romanov]

Hello everyone.

  I have developed a tool that is similar to guard in go. It just watches files in specified folder and executes some console command when specific files are changed. Pretty simple. Here is link if anyone interested - https://github.com/romanoff/gow

But while developing tool I had one problem related to concurrency. Here - https://github.com/romanoff/gow/blob/master/gow_config.go#L42-44 somehow if I would use pointer instead of value ( (r *rule) and supplied self (not *self)), program was breaking. As well as if I would write "go self.handleEvents()". Can someone explain me why? Thanks a lot.

[Dave Cheney]

Very nice. You might want to try switching to the version of fsnotify
which was integrated into the go.exp repository during Go 1.1

https://code.google.com/p/go/source/browse/?repo=exp#hg%2Ffsnotify

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Andrew Romanov]

Thanks. Good point. I am still using go 1.0.3 (time to switch). Probably it's time to switch

[Patrick Higgins]

On Wednesday, May 22, 2013 12:51:38 AM UTC-6, Andrew Romanov wrote:

gow/blob/master/gow_config.go#L42-44 somehow if I would use pointer instead of value ( (r *rule) and supplied self (not *self)), program was breaking. As well as if I would write "go self.handleEvents()". Can someone explain me why? Thanks a lot.

I'm not sure if this has to do with the older fsnotify, but I tried your program out on Go 1.1 using the new fsnotify and it seems to work as expected, though I discovered a nil deference.

A few comments:

You can send the command output directly to stdout so you'll see output as it arrives rather than all at the end:

http://play.golang.org/p/YfxAGbmHrS

The sync.WaitGroup in gow.go is being used strangely. Usually you'd call Done on it when each goroutine exits. Moving the goroutine to main instead of rule.watch helps:

http://play.golang.org/p/xJF8u015kX

That also removes the "go self.handleEvents()" call you found problematic, though that actually worked for me. Not sure what the problem might have been.

[Patrick Higgins]

On Wednesday, May 22, 2013 6:19:00 AM UTC-6, Patrick Higgins wrote:

On Wednesday, May 22, 2013 12:51:38 AM UTC-6, Andrew Romanov wrote:

gow/blob/master/gow_config.go#L42-44 somehow if I would use pointer instead of value ( (r *rule) and supplied self (not *self)), program was breaking. As well as if I would write "go self.handleEvents()". Can someone explain me why? Thanks a lot.

A few comments:

Also, if filepath.Walk calls your WalkFunc with a non-nil error, the os.FileInfo arg can be nil. Some lock file in my .git directory was causing an error.

It would be useful to skip certain directories (such as .git, but configurable) by returning filepath.SkipDir when they are seen.

[Andrew Romanov]

Cool :) It probably more comes down to preferences of command line vs config file.

On Wednesday, May 22, 2013 1:54:52 AM UTC-7, Brandon Chen wrote:

HI Andrew,

I wrote a tool for the same purpose, you may take a look. :)

https://github.com/parkghost/watchf

[Andrew Romanov]

Thanks for your comments Patrick.

1. You can send the command output directly to stdout so you'll see output as it arrives rather than all at the end - I saw this way of redirecting command output, but forgot about it. Changed it in my package
   
2. sync.WaitGroup is definitely not used conventionally in my project. It just stop go program from exiting in case some rules are specified in config file. What you showed makes a lot of sense, but in my case it just exits application right away after it has started.
   
3. go self.handleEvents() works fine if you have one rule. Having two rules already breaks things. And that's where I am confused
   
4. I added ability to ignore specified folders to my package. But "github.com/romanoff/fsmonitor" package will have to be updated as well.