-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix 76 - change the way that target is created; rework response to quit #78
Conversation
@@ -21,6 +21,16 @@ | |||
FileUtils.rm_rf(sincedb_path) | |||
end | |||
|
|||
context "when sincedb path is given but ENV[\"HOME\"] or ENV[\"SINCEDB_PATH\"] is not given" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test fails on master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in this test we only test that the absense of HOME is tolerated, maybe we should adapt the name of this context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
end | ||
|
||
def initialize(opts = {}) | ||
@target = YieldingTail.new(opts) | ||
def initialize(opts = {}, target = YieldingTail.new(opts)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels weird to have a scalar value after an options/keyword-style argument here. My feeling is that def initialize(target=..., opts={})
is ... better somehow, though I cannot quite articulate why I feel this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does - I agree sort of, more so if one uses the hash shortcut:
FileWatch::Tail.new(:sincedb_path =>"",
YieldingTail.new(
:sincedb_path => sincedb_path, :start_new_files_at => :beginning, :stat_interval => 0
)
)
but the switching of the arguments would break:
- the use of opts set in the previous argument when the default value for target is evaluated because target is not supplied,
- the constructor expectation set already,
In practice no one should know about this dependency injection argument, but if someone want to write a different kind of tailing class - they have an injection mechanism.
The change looks OK to me. I haven't run the tests yet. |
3 specs fail for me under MRI 2.2.1p85
|
will update gemspec when I get a "Lets Go To Mars" please show details of spec failures - they don't fail for me. |
|
@jordansissel - what operating system and file system are you using for the tests? It looks like, for failures 2 and 3, the OS is returning the globbed files as 2.log then 1.log - i.e. last written == first retrieved. For the first failure, it looks like the changes to ENV are not being seen. What ruby version are you using? |
I changed the create order of the files in the spec - 2.log is created before 1.log - maybe this will help with making failures 2 and 3 pass. |
MRI 2.2.1, Fedora 23 64bit in a Hyper-V VM. Filesystem is XFS |
ahhhh |
file_deleteable = [] | ||
# creates this array just once | ||
watched_files = @files.values | ||
|
||
quit_proc = lambda do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this name is a bit misleading, this is more a cleanup task that only runs if quitting is true, and also due to tap's return behaviour, also returns quitting.
I don't have a good alternative other than to make this cleanup task an actual method and be more verbose by doing the 2 steps: cleanup if quitting; quitting
, or moving "cleanup" to the ensure block of this method? assuming it will always run when leaving this method?
Anyway, it's up to you to change anything. I'm finding the code a bit hard to read, but it's correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about using a method, but my logic is as follows:
- its this method's exit finaliser (i looked v briefly at throw/catch but the syntax looked to be even more confusing)
- the external method would have to have the file_deletable array passed to it so its not really a utility method
I never though about an ensure block - good idea 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing, do you think the ensure block executes in the synchronised block scope? I am not sure, more than likely not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, this would require a move of the synchronised call to outside of the each method..so instead of
def each(&block)
synchronised do
# ...
end
end
instead do
# ...
synchronised do
each(&block)
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
up to you, I don't have a strong feeling on this, just a tiny itch
LGTM |
and timing of sincedb write. add failing spec doh! change create order of files in spec closes 76 fix smell of quit_proc and add tests to verify unreadable file handling split up HOME and SINCEDB_PATH change the logging in each when a general error occurs bump version closes jordansissel#76
fix 76 - change the way that target is created; rework response to quit
and timing of sincedb write.