I am often stuck twiddling my thumbs for a couple minutes while eclipse cleans, builds, or loads my projects. It would be nice if eclipse could notify me with a beep when the last task in the Progress view has finished running, so I can stop reading the internet and get back to work. Is there a setting or plugin that does this?
Edit: I tried adapting the plugin template that nonty provided below, which adds a listener to the JobManager. I tried implementing done() to beep only when the job change event's name contains "Building workspace," as that is the task that usually takes the longest in my setup. Exasperatingly, the task that builds the workspace never sends a done() call, just scheduled() and aboutToRun() calls. Any other ideas?
There are no preference for this - yet.
The JobManager have the needed API to support this functionality...
EDIT: I have constructed and attached a very simple plug-in that will beep for every job that terminates. That turns out to be rather often :-) . You can modify it to filter out all the false positives, e.g. by getPriority() and getName(). Also you can make the listener play a tune, popup a message (don't!) or whatever...
See jobnotifier.zip.
UPDATED the link above again
Related
Very new to Google Actions. Testing out tutorial stuff.
I have tried this in a couple of test projects just to double check. After initial run of any project I do not get any updates on draft projects. No changes show up in draft projects for me for both simulator and real device.
Started new project
Even blank project has basic conversation telling you where to add things next.
Change text.
Notice prompt does not change in testing environment.
In below pictures I have changed the words "hello world" with "Hey Dude" for both fulfillment and console output. I would expect Testing Prompt to respond with "Hey Dude from fulfillment and Hey Dude from the console!" But it does not. Instead it does not reflect any recent changes.
I think there may be two slightly different (but sometimes related) issues going on here.
The first is that there are known problems with the simulator being slow to pick up on updates, or them not seeming to show up. The second has to do with making sure you're deploying changes from the build-in code editor.
I don't have a clear answer to the first problem, although I know they're looking into it. I find that I can make some changes and they may not be noticed, but I know they have been picked up if I see the "Your preview is being updated..." spinner appear. There are other spinners that sometimes appear, but unless it explicitly says that it is being updated - the updates aren't always picked up. (Sometimes they are, however.)
Usually, if I don't see this, I'll go back and force an apparent change (delete a character from a webhook handler name, then add it back) and go back to the simulator. In general, this time it will say it is updating.
If you're using the Cloud Functions editor, you need to do three things:
Save the changes. You'll do this by clicking the "Save Fulfillment" button, but this only saves it so you can leave the editor. It doesn't mean that the simulator has access to it yet.
Deploy the changes. This deploys your code to Cloud Functions so they can be run. Note in the illustration that it says the code is saved, but not yet deployed.
Wait till the changes are fully deployed. Deploying takes time, and until it is completed, it won't be available in the simulator. While deploying, it lets you know.
Once it has deployed, however, the message changes, and you the impacts should be available through the simulator (although you may still need to see the "being updated" message to be sure).
Remember, however, that you don't need to use the "Cloud Functions editor" in order to deploy a webhook. You can deploy a webhook on any web server where
The host is public (so has a public IP address that Google can reach)
It can handle HTTPS with a non-self-signed certificate
You can even deploy yourself to Cloud Functions for Firebase, which is the same service that the Actions Builder uses. This way you have the URL set once in the Actions Builder and, once it is set, you won't need to change it.
But you'll still be able to change your code by managing your own deployment separate from Actions Builder.
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
How can I write a plugin or program routine that gets notified when "build workspace" finishes in Eclipse?
Is IProgressMonitor useful for this? If so, how do I get ahold of it?
You can wait for the automatic build to finish using:
Platform.getJobManager().join(ResourcesPlugin.FAMILY_AUTO_BUILD, null);
This will block until the builds have finished (and do nothing if the build is not running).
You would probably also want to wait on the manual builds are well:
Platform.getJobManager().join(ResourcesPlugin.FAMILY_MANUAL_BUILD, null);
If you really want to receive a notification (rather than blocking), try this:
IWorkspace.addResourceChangeListener(myListener, IResourceChangeEvent.POST_BUILD);
The Javadoc of IResourceChangeEvent gives more details on usage and on information found in the event instance.
I have activated an option "Build on resource save". My typing habits is to save the code every few seconds and whenever previous build is not complete before I save again, I get a window like this:
Basically Eclipse is forcing me to wait before it will finish the previous build and start a new one. Can I somehow configure it, so that it will start new build automatically once the previous is completed and will not block my input? It is okay if it will incorporate multiple consequent saves of the code.
Essentially, my solution was not to build on save. As scottb mentioned in comments it is too complicated to actually decide when it is save to build and when it is not.
I'm using JavaHg in order to build a customised GUI interface. I was able to clone via code as follows:
BaseRepository repo = Repository.clone(new File(checkout_folder), url);
However, this being a GUI app, it just stalls until the clone is complete. Is there any way to do this clone command while also allowing the GUI to monitor its progress?
My gut feeling is telling me to take a look at the MercurialEclipse plug-in and see how they do it there, but if anyone can suggest an approach, I'd be glad to hear it.
Regards,
Gurce
EDIT:
Thanks for the info on both perspectives, one for the reality of the present situation, and for the suggestion of a night-rider progress bar.
I recently opted for a dodgey workaround approach, which I seem to be getting away with for now.
Since I'm hosting my mercurial projects on a hgweb server, I tried doing it this way:
A checkout (ok ok, clone! :)) is triggered in my app
My app visits the server via ssh and runs a "du" command on the bare repository for the project intending to be checked out
So then my app uses the returned total-disk-space-used by that bare-repo as an estimate of the total disk-space the final checkout should have on the local working folder
My app then polls the local working folder once a second with the "du" command, to see amount of disk-usage the checkout/clone is currently consuming
I use this du result versus the du result from the server to display my progress bar
It's not 100% accurate, but oh well, it seems to do the job ok...
Currently JavaHg doesn't support showing progress of long running operations
with a work thread you can solve the hanging part. i'll check the monitoring, but i think a night rider, work in progress bar will do just fine. you'll have to start a thread to handle the communication and let the main thread go on and handle the actions on the gui.
there are two options to see if the cloneing is over:
-via a callback method (this is the nice, bigbook style way to do this)
-check upon the work thread periodicaly (not so good, but if you're into while cycles and hate callbacks it'll do the trick)