I would like to create a custom progress bar for a job I am running in pyspark Azure Databricks. I tried doing this using matplotlib by creating multiple figures and calling display one by one for each but the output is displayed only when the entire job completes so it's not much of a progress bar.
Is there a simple way to create such a display that also gets updated as progress is being made?
Thanks for your help.
the spark databricks default progress bar
You can use the "displayHTML" function in order to render a custom progress bar through embedded CSS/JavaScript. This works as "displayHTML" will reset the cell output everytime you call it (just make sure you call sleep for a few seconds between each call, so you can see how the output changes), however you will also need to update all the rest of the output in each call
Related
Is it possible to set up Jupyter so that whenever a cell is finished running it would automatically carry out some code?
Some of my code takes a long time to run, and it is quite inconvenient to have to check back often to see whether the code is completed. I can manually add some notification code at the end of each cell, but it would be much easier if I can simply put this code in say, jupyter_application_config.py or custom.js, and have jupyter calls it automatically.
It would be even better if it can be set up so that the code is executed if the cell takes more than n seconds to run.
This answer is a bit late... but I also wanted notifications when long running code in Jupyter cells had completed, and I found the Notify extension to be limiting (eg., no notifications if I was away from my computer). My solution for myself was to create a custom magic that using Pushbullet to send notifications to both my computer and my iPhone.
The magic is called pushnote. Maybe it will be helpful for you.
We wrote a custom action to deploy some artifacts to our glassfish server. Now we wanted to display the names of the artifacts to the message-text of the progess bar. Therefore we want to set the text directly from the custom action instead using a separate set-progress-action. Is this possible? We want to avoid a bunch of custom-action/set-progress-message entries in our configuration although we can recap these inside a action group.
Thanks in advance
Call
context.getProgressInterface().setStatusMessage("Your text");
in your code. The progress interface also has methods for changing the percentage, the indeterminate state and the detail message.
I'm automating an app that shows some overlay messages anywhere on the app for several scenarios, such as app installed for the first time etc. (I'm fairly new to Robotium too.)
The overlay displays a text that goes away by swiping or clicking on it. Also, there are different types of these overlays with different unique text on it. (let's call it Activity A)
I wanted to create a robust test case that handles this case gracefully. From the test's perspective we won't know that the activity A will be present all the time. But I want to recover from the scenario if it does, by writing a method that I can call any time. Currently, the tearDown method gets called since my expected activity name doesn't match.
Also, even if the activity A exists, there are other predefined overlay texts too. So, if I use solo.waitForText("abc") to check for text "abc", I may see the overlay 2 with the text "pqr" instead.
So I was looking for a way to automate this, and I can't use solo.assertCurrentActivity() or solo.waitForActivity methods as they just stop the execution after the first failure.
So any guidance is appreciated!
All the waitFor methods return a boolean. So you can use waitForActivity() exactly as you want to. If the Activity doesn't exist it will return false.
You can check which Activity is current:
Activity current = solo.getCurrentActivity();
I have an application that is used for data analysis. A big part of the application is the ability to be able to show charts based on the data assembled, and to be able to export a large number of tasks in one batch-operation. Up until now I have used JFreeChart, but I would like to use the native JavaFX Charts so that the exported charts will still look the same as they do on-screen in the application.
I am on JavaFX 2.2.1 (jdk 7u6).
I am able to generate the charts in one batch, but that means that I have to freeze the User Interface (UI), as these charts have to be rendered on the JavaFX Application Thread. I use the Platform.runLater(new Runnable() { ... }); command for this, wrapped around the code that generates the charts.
If I instead wrap each individual chart generation into a Platform.runLater(new Runnable() { ... }); The GUI doesn't freeze up as before, but I will also get no feedback because I am unable to detect when each of the individual charts are generated (they are ran at a later stage, and I have no control over when that might happen, and there is no callback available as far as I know either).
For this particular event I would like to show a progress bar to the user, and I want this progress bar to be updated along with the actual chart generation.
Any suggestions or hints as to how this can be achieved ?
This question was solved in the Oracle JavaFX forum thread: Render charts in background.
The solution was to have a SaveChartsTask with three subtasks:
Create charts in an off screen scene graph.
Take snapshots of each off screen chart to an JavaFX image.
Use imageio routines to export the JavaFX images to files.
The workDone properties on tasks allowed the process of the operations to be monitored. By splitting the total work up into subtasks, keeping work off of the JavaFX application thread when possible and making use of CountDownLatches and BlockingQueues as necessary to synchronize operations, the UI was able to remain responsive.
Since it seems that you are new to JavaFX-2. I recommend you to read the JavaFX-2 Concurrency article from oracle documentation.
Your problem is easily solved by using the Task Object to load your charts individually (One Task per Chart for example). Quoting the tutorial page:
Tasks are used to implement the logic of work that needs to be done on a background thread.
Since Task implements the Work Interface, you can use your Tasks to probe for their Worker.State. Quoting the manual:
A reusable Worker will transition from CANCELLED, SUCCEEDED or FAILED back to READY.
This would solve your problem about feedback since you'll always be able to know if a Task is still Running or not since the Worker.State object has the following possible States:
CANCELLED
FAILED
READY
RUNNING
SCHEDULED
SUCCEEDED
As for your progress bar, you can use the updateProgress(double done, double max) to set your Task progress and then simply set the progress of your progress bar by binding the ProgressBar.progressProperty() to Task.progressProperty().
EDIT
Answering to your comment:
The problem is that the work performed inside the Task in this case in the generation of the JavaFX Chart, and that code needs to be executed inside the JavaFX Application Thread
From the tutorial:
Instead, use the JavaFX APIs provided by the javafx.concurrent package, which takes care of multithreaded code that interacts with the UI and ensures that this interaction happens on the correct thread.
Which means the code executed inside the Task object is already being executed in the JavaFX Thread.
I hope it helped. Cheers
To run a JavaFX Task on the JFX thread, you can schedule the task to be run with Platform.runLater(myJFXTask);.
could someone please tell me how to disable cancel button in a job's progress entry in Progress View tab in eclipse rcp application. i have not been able to locate any references on the web aside from the ones that suggest the use of ProgressMonitorDialog. using the dialog, however, is not an option, as the Progress View must remain in a form of a view.
i have come upon ProgressMonitorPart, which sounds like something that i can use. if that is the case, how do i go about passing it to Job.run(IProgressMonitor)?
thank you for your time!
You don't. You can call Job#setSystem() on your Job so it's hinted as not to be shown, but you don't get to spin off jobs that the user can't at least ask you to cancel. The stop button does little more than set the progress monitor as having been canceled--it's still up to your running Job to check the progress monitor and behave itself. Or not.
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fruntime_jobs_progress.htm