progress outputs #1
Comments
|
Thanks @jamesb93. This is on the radar, but not as a matter of huge urgency to us. There would be two components to making this change:
Adding the threading isn't totally horrible, but it's not totally obvious either. First step would be to change the template argument in each of the |
|
Great, that might be doable for myself! I appreciate the guidance. IMO a good stdout would just be the percentage without any other bells and whistles. Maybe a "\r" to clear the screen but then it can be rude to clear peoples consoles without asking, although lots of programs do this (I can think of progress bars in homebrew for example). |
|
I had a go at this today, but I'll admit I'm way out of my depth tracking down errors to progress. It seems that the part of the wrapper which takes in the argc and argv is expecting that, so when the wrapper is changed to |
|
Are you doing something like #include <FluidCLIWrapper.hpp>
#include <clients/rt/LoudnessClient.hpp>
int main(int argc, const char* argv[])
{
using namespace fluid::client;
return CLIWrapper<NRTThreadedLoudnessClient>::run(argc, argv);
}? That should work, at least to the extent of giving you error messages about something other than |
|
This is what I get back: |
|
That could be worse. Just don't pass the instance of |
|
Okay I removed passing FluidContext. I assume that the next part is doing some error checking after the work has been complete, and writing when the return is good. I guess at this point you are dealing with pinging the result to see if its done? Are there any good instances of this I can look at in other wrappers? |
|
The Then for the pinging https://github.com/flucoma/flucoma-pd/blob/e4d8349c4fa39f08bbee0521585fc0fc19ff443c/include/FluidPDWrapper.hpp#L277 However, it'll be slightly different here because there's not a scheduler. So you'll want a loop after you call process that sleeps for a bit (possibly using |
|
Maybe something like Result result;
client.process();
while(true)
{
ProcessState state = client.checkProgress(res);
if (state == ProcessState::kDone ||
state == ProcessState::kDoneStillProcessing)
{
if (x->checkResult(result)) break;
}
if (state != ProcessState::kDone)
{
std::cout << client.progress();
std::this_thread::sleep_for(20ms);
continue;
}
}
if (!result.ok())
{
// Output error
std::cerr << result.message() << "\n";
}
else
{
// Write files
bool allowCSV = true;
params.template forEachParamType<BufferT, WriteFiles>(allowCSV);
}
return result.ok() ? 0 : -1; |
|
I don't remember offhand why we need |
|
I imagine you'll at the very least need to add |
|
Okay getting there. It doesn't know what |
|
Okay yep, firmly out my depth here. |
|
Oops. You don't need it. Just break if the process state is kDone
…On Fri, 7 Aug 2020, 22:03 James Bradbury, ***@***.***> wrote:
Okay yep, firmly out my depth here. checkResult seems to be a member
function of the other wrappers which is why its passed that instance of the
class in pd? So passing this->checkResult fails. Perhaps you can steer me
again.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGQHIYPRSPSJEYSWNLBFRKDR7RT27ANCNFSM4N4GY3UQ>
.
|
|
Excellent! Let me try this. |
|
I should remember to end my lines: It looks like something is happening when progress is sent to stdout, but its not what I would expect. I'll push my code to a branch of my fork. |
|
💯 💯 💯 double progress = 0.0;
while(true)
{
//...
if(client->progress() - progress >= 1) std::cout << client.progress();
progress = client.progress;
//...Or, if you'd rather have a more even pace, only update every so many iterations (e.g. 25 for half-secondly updates). Or check less often. |
|
Yes these are nicer ways of managing the number. I'll implement them my side, check then put a PR up? |
|
Suggest, if you have the will, you live alongside it for a while and confirm it does what you want, especially in a ReaCoMa context. I'm not sure when we're next going to release off this branch, so there's no rush. |
|
That said, if you want some feedback on anything, stick a PR up by all means. We can merge whenever. |
I shall do this. I'd like to point people who use ReaCoMa to the official binaries rather than some bootleg stuff I've built so I'll maintain a branch with progress updates until something like this is integrated in the future.
Sounds good! |
|
Well, I guess we should be going 1.0.0 before too long, so we can certainly make sure it's in that |
|
So this is where the code is out. I am able to ping the progress of the process but it doesnt actually seem to ever advance I can confirm that with RC1 what I am processing is valid, it complees in 17 seconds. Waiting for 10 minutes and nothing happens with my code. Is there something that is fundamentally missing here? Like a go button or what not. |
|
Ahh perhaps I've found it. Taking inspiration from the pd wrapper, If not done I believe I need to call |
|
Okay nope, nothing there. I'm also periodically getting process and progress confused mentally 👎 |
|
I think you need to enable the threading with |
|
No dice. It just prints 0's. I also tried |
|
You might need to resort to breakpoints to see if it's actually launching a thread or not. Tied up moving house at the moment, but if you can't figure it out I'll give it a shot when I'm back in circulation next week.
… On 10 Aug 2020, at 12:13, James Bradbury ***@***.***> wrote:
No dice. It just prints 0's. I also tried client.setQueueEnabled(false) after, although I suspect that is more about the queue interface in Max.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGQHIYMMJZNRTPRECQHSA63R77I4BANCNFSM4N4GY3UQ>.
|
|
No worries. Thanks for all your help so far |
|
There was one crucial missing element, in that we needed to Try this: // Create client after all parameters are set
ClientType client(params);
Result result;
client.enqueue(params);
result = client.process();
double progress = 0.0; // Variable to store progress
while(result.ok())
{
ProcessState state = client.checkProgress(result);
if (state == ProcessState::kDone || state == ProcessState::kDoneStillProcessing) {
std::cout << '\n';
break;
}
if (state != ProcessState::kDone) {
double newProgress = client.progress();
if (newProgress - progress >=0.01)
{
std::cout << newProgress << '\r' << std::flush;
progress = newProgress;
}
using namespace std::chrono_literals;
std::this_thread::sleep_for(20ms);
continue;
}
}
if (!result.ok())
{
// Output error
std::cerr << result.message() << "\n";
}
else
{
// Write files
bool allowCSV = true;
params.template forEachParamType<BufferT, WriteFiles>(allowCSV);
}
return result.ok() ? 0 : -1;
}The significant changes are:
I moved the |
|
Uh oh! Is this an easy one you've come across? I did -- The CXX compiler identification is AppleClang 11.0.0.11000033 is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. -- Configuring incomplete, errors occurred! |
|
Have you upgraded Xcode to 11 recently? |
|
And is this from a clean build folder? |
|
I haven't explicitly updated Xcode but maybe something automatically did it. I'll clean build and see what happens. It's likely it was dirty from before. |
|
Okay cleaning out the build folder worked. In this case Green's paradox didn't hold fast and as the codebase got dirtier it didn't run better. |
Hello FluCoMites,
It would be nice to have progress outputs from stdout perhaps issued with a verbose flag or something ala Max environment objects. I took a look at implementing myself - alas I lack the C++ skills to really get my head around it but perhaps putting it on your radar might make it find its way into a future release. With some guidance + clarity on how to implement it could be something I take on myself.
The text was updated successfully, but these errors were encountered: