Skip to content
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

Implementing channel control for experiment creation #41

Merged
merged 6 commits into from
May 21, 2024

Conversation

pebeto
Copy link
Member

@pebeto pebeto commented May 21, 2024

Opening this PR in favor of Channel usage. It requires this MLJTuning.jl branch to be merged and released in a new patch.

The complete discussion is here #36

@pebeto pebeto linked an issue May 21, 2024 that may be closed by this pull request
@pebeto pebeto merged commit 8a10ac3 into dev May 21, 2024
2 checks passed
@pebeto pebeto deleted the implementing-channel-control-for-experiment-creation branch May 21, 2024 15:55
@@ -19,6 +19,15 @@ function log_evaluation(logger::Logger, performance_evaluation)
updaterun(logger.service, run, "FINISHED")
end

function log_evaluation(logger::Logger, performance_evaluation)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this function should close result_channel before returning?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result_channel is just temporal. When we perform take!(result_channel), the value is retrieved and returned. The garbage collector will take care off the channel when function ends, so it's safe to maintain it open.
Also, we are not looping the result_channel in any way, so we don't have to worry about that.

(I can remove the wait(result_channel) at line 26 because take!(result_channel) will actually wait until the Channel contains a value)

@@ -28,13 +28,17 @@ struct Logger
verbosity::Int
experiment_name::String
artifact_location::Union{String,Nothing}
_logging_channel::Channel{Tuple}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit picking point: Can't _logging_channel be logging_channel ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered _logging_channel instead of logging_channel because I want it to be like a "private" field. The user is not intended to touch that field. However, I discovered that I made a mistake on open_logging_channel() because I'm returning a value instead of setting it up in the logger.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in Julia fields are generally considered private, especially if they are not referenced in any doc-string. To make them public you would ordinarily provide an accessor function. But there's no harm in this - I just found it a bit strange.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add tests for CPUThreads and CPUProcesses
2 participants