Thursday, September 15, 2016

How to get your colleague Pull request into your system for testing

For my own reference:

Example:
git remote add coworker https://github.com/coworker/titanium_studio.git
git fetch coworker
git checkout --track coworker/TIMOB-23628

If your co-worker has made some more changes, then you pull the latest changes in the below way.

git checkout TIMOB-23628

git pull


To push it back to your colleague branch
git puh coworker TIMOB-23628




Another way would be

To fetch a remote PR into your local repo,
git fetch origin pull/ID/head:BRANCHNAME

where ID is the pull request id and BRANCHNAME is the name of the new branch that you want to create. Once you have created the branch, then simply

git checkout BRANCHNAME
Reference: https://stackoverflow.com/questions/27567846/how-can-i-check-out-a-github-pull-request-with-git

Thursday, September 8, 2016

Best Practice: Never ever execute long running operations in the Display.asyncExec() also

//The thread which calls this method is suspended until the runnable completes.
Display.getDefault().syncExec(new Runnable()
{
public void run()
{
//Do only UI operation
}
});


//The caller of this method continues to run in parallel
Display.getDefault().asyncExec(new Runnable()
{
public void run()
{
//Do only UI operation
}

});



I've seen most of the people will misuse Display.getDefault().asyncExec() by thinking that it will not impact the application performance. But the important thing to remember here is, SWT is a single threaded model - Yes, it's a single-threaded UI model. Any UI operation which you do, will happen through Display main thread. 


Example:

Display.getDefault().asyncExec(new Runnable()
{
public void run()
{
   //step 1: network connection involvement
                               
   //step 2: UI code to execute - example: opening a browser

}

});



From above, it has non-UI and UI code. If accessing the network takes time, UI thread will be blocked for a long time so that no other thread can able to get an access to execute other UI code.

That means, at any point of time - only one UI thread will be there i.e, Display thread.


To resolve this kind of things, we need to use jobs and invoke only necessary code in the UI thread.


new Job("Browser opening job...")
{
@Override
protected IStatus run(IProgressMonitor monitor)
{
//step 1: network connection involvement
Display.getDefault().asyncExec(new Runnable()
{
public void run()
{
 //step 2: UI code to execute - example: opening a browser                  
         
}
});

return Status.OK_STATUS;
}
}.schedule();



Best Practice: Always check for Control disposed in Display.asyncExec()



Display.getDefault().asyncExec(new Runnable()
{
public void run()
{
//Always check for whether the control is disposed.
if (!progressComposite.isDisposed())
{
//perform UI operation.
}
}
});


Reason being, when we say asyncExec thread - it will execute on the next reasonable opportunity. But by that time the control would have been disposed.



Wednesday, September 7, 2016

HttpURLConnection setConnectTimeout issues

HttpURLConnection connection = (HttpURLConnection) url.openConnection();
// Give it a 4 seconds delay before deciding that it's a dead connection
connection.setConnectTimeout(10000);
connection.setRequestMethod("HEAD"); // Don't ask for content
connection.setAllowUserInteraction(false);
connection.connect(); 



Problem here is, application can hung for more than 10 sec even after configuring the timeout for connection.

How that can happen?

connection.setConnectTimeout() is only for configuring timeout to accept the connection, but after accepting the request server might take a long time to respond to you due to various issues at the server end. 

As per the doc - “timeout for opening a communications link to the resource referenced by this URLConnection”.

This kind of things will lead to application hung if you’re waiting for the response.


To resolve this - we should also set the connection.setReadTimeout(5000). 

As per doc - “timeout when reading from Input stream when a connection is established to a resource.”




Thursday, September 1, 2016

How to set default language for eclipse or for your RCP product

Before you launch an eclipse, configure  -Duser.language=en property in eclipse.ini file.

In the context of mac os.

Example:
  1. Go to /Applications/Eclipse/eclipse.app/Contents/MacOS/
  2. Open eclispe.ini file
  3. Append -Duser.language=en to the end of the file
  4. Restart eclipse


In windows, you can find eclipse.ini file in the eclipse root directory.

Thursday, August 25, 2016

SWT - Single UI threaded model



The backbone of any UI toolkits are threads. The most basic aspect of UI toolkits is to provide a nice event driven architecture, as events are the most integral part of any UI.
The underlying operating system maintains a queue of application events and if that event is long running and is blocked it will freeze your UI.
In SWT when a user presses a mouse a mouse pressed event is generated. Determining which window is supposed to receive the event and placing it in an event queue is done by the underlying OS.
SWT has a single UI thread which creates the display and from which all other widgets are created. When writing a SWT app the most common piece of code existing in all programs is
while (!shell.isDisposed())
{
if (!display.readAndDispatch())
display.sleep();
}
display in SWT is the class which interacts with the underlying operating system. In the above code readAndDispatch() is the call which reads events from the event queue and dispatches them to the correct place.
Since there is only one UI thread, if we try and process events in the same thread the UI will freeze. This is where threads come to our rescue. But again when working with UI’s the most tricky and dangerous thing to do would be access UI components from non UI threads. If you spawn a new thread and try to update UI components from that non UI thread you will be in for a bummer. When your UI toolkit is SWT, it will nicely point out to you your chivalry and throw an SWTException.

Friday, August 19, 2016

SWT Threading issues

http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fswt_threading.htm


Threading issues
When working with a widget toolkit, it is important to understand the underlying thread model that is used for reading and dispatching platform GUI events. The implementation of the UI thread affects the rules that applications must follow when using Java threads in their code.

Native event dispatching

Underneath any GUI application, regardless of its language or UI toolkit, the OS platform detects GUI events and places them in application event queues. Although the mechanics are slightly different on different OS platforms, the basics are similar. As the user clicks the mouse, types characters, or surfaces windows, the OS generates application GUI events, such as mouse clicks, keystrokes, or window paint events. It determines which window and application should receive each event and places it in the application's event queue.
The underlying structure for any windowed GUI application is an event loop. Applications initialize and then start a loop which simply reads the GUI events from the queue and reacts accordingly. Any work that is done while handling one of these events must happen quickly in order to keep the GUI system responsive to the user.
Long operations triggered by UI events should be performed in a separate thread in order to allow the event loop thread to return quickly and fetch the next event from the application's queue. However, access to the widgets and platform API from other threads must be controlled with explicit locking and serialization. An application that fails to follow the rules can cause an OS call to fail, or worse, lock up the entire GUI system.

SWT UI thread

SWT follows the threading model supported directly by the platforms. The application program runs the event loop in its main thread and dispatches events directly from this thread. The UI thread is the thread in which the Display was created. All other widgets must be created in the UI thread.
Since all event code is triggered from the application's UI thread, application code that handles events can freely access the widgets and make graphics calls without any special techniques. However, the application is responsible for forking computational threads when performing long operations in response to an event.
Note: SWT will trigger an SWTException for any calls made from a non-UI thread that must be made from the UI thread.
The main thread, including the event loop, for an SWT application has the following structure:
   public static void main (String [] args) {
      Display display = new Display ();
      Shell shell = new Shell (display);
      shell.open ();
      // start the event loop. We stop when the user has done
      // something to dispose our window.
      while (!shell.isDisposed ()) {
         if (!display.readAndDispatch ())
            display.sleep ();
      }
      display.dispose ();
   }
Once the widgets are created and the shell is opened, the application reads and dispatches events from the OS queue until the shell window is disposed. If there are no events available for us in the queue, we tell the display to sleep to give other applications a chance to run.
SWT provides special access methods for calling widget and graphics code from a background thread.

Executing code from a non-UI thread

Applications that wish to call UI code from a non-UI thread must provide a Runnable that calls the UI code. The methodssyncExec(Runnable) and asyncExec(Runnable) in the Display class are used to execute these runnables in the UI thread during the event loop.
  • syncExec(Runnable) should be used when the application code in the non-UI thread depends on the return value from the UI code or otherwise needs to ensure that the runnable is run to completion before returning to the thread. SWT will block the calling thread until the runnable has been run from the application's UI thread. For example, a background thread that is computing something based on a window's current size would want to synchronously run the code to get the window's size and then continue with its computations.
  • asyncExec(Runnable) should be used when the application needs to perform some UI operations, but is not dependent upon the operations being completed before continuing. For example, a background thread that updates a progress indicator or redraws a window could request the update asynchronously and continue with its processing. In this case, there is no guaranteed relationship between the timing of the background thread and the execution of the runnable.
The following code snippet demonstrates the pattern for using these methods:
   // do time-intensive computations
   ...
   // now update the UI. We don't depend on the result,
   // so use async.
   display.asyncExec (new Runnable () {
      public void run () {
         if (!myWindow.isDisposed())
            myWindow.redraw ();
      }
   });
   // now do more computations
   ...
It is good practice to check if your widget is disposed from within the runnable when using asyncExec. Since other things can happen in the UI thread between the call to asyncExec and the execution of your runnable, you can never be sure what state your widgets are in by the time your runnable executes.

The workbench and threads

The threading rules are very clear when you are implementing an SWT application from the ground up since you control the creation of the event loop and the decision to fork computational threads in your application.
Things get a bit more complicated when you are contributing plug-in code to the workbench. The following rules can be considered "rules of engagement" when using platform UI classes, although from release to release there may be exceptions to these rules:
  • In general, any workbench UI extensions you add to the platform will be executing in the workbench's UI thread, unless they are specifically related to threads or background jobs (such as background job progress indication).
  • If you receive an event from the workbench, it is not guaranteed that it is executing in the UI thread of the workbench. Consult the javadoc for the particular class that defines the listener or event. If there is no specific documentation discussing threading, and the class is clearly a UI-related class, you may expect that the event arrives in the UI thread of the workbench.
  • Likewise, a platform UI library should not be considered thread-safe unless it is specifically documented as such. Note that most platform UI classes dispatch listeners from the calling thread that triggered the event. Workbench and JFace API calls do not check that the caller is executing in the UI thread.This means that your plug-in may introduce a problem if you call a method that triggers an event from a non-UI thread. SWT triggers an SWTException for all API calls made from a non-UI thread. In general, avoid calling platform UI code from another thread unless the javadoc specifically allows it.
  • If your plug-in forks a computational thread or uses a workbench Job, it must use the Display asyncExec(Runnable) orsyncExec(Runnable) methods when calling any API for the workbench, JFace, or SWT, unless the API specifically allows call-in from a background thread.
  • If your plug-in uses the JFace IRunnableContext interface to invoke a progress monitor and run an operation, it supplies an argument to specify whether a computational thread is forked for running the operation.

Thursday, July 21, 2016

Eclipse in full screen mode - programmatically

Eclipse 4.4/4.5

 active contribution item identifier:
org.eclipse.ui.cocoa.fullscreenWindow

The active contribution location URI:
menu:window?after=org.eclipse.ui.cocoa.fullscreenWindow

Thursday, July 14, 2016

Recovering staged lost files during git reset --hard

$ git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)")   $(egrep commit all | cut -d ' ' -f 3)
Checking object directories: 100% (256/256), done.
Checking objects: 100% (542/542), done.
unreachable blob 6900c6418b5df26f6471b7d4853822d99fcf2534
unreachable blob 945019391229d1304b47c7d1dc112ff45bbca360
unreachable blob 0ed3acde384de116f4b194bfd226055074a9f52d
unreachable blob c0234fc886423ff40a96b4c3e7ba67a4deb944c0
unreachable blob c9754aed2e981cdf678159ab41f7bfea89c93cbd
unreachable blob 8168f4a5a91997641211ce0d30b01e8bf8920792
unreachable blob 8c9cc9beddbc89a0ef46a1631265f79551a78e8a

unreachable blob 758e9c59bc04d38bd676c3c98e6d092b698defa4


Your file should be one of those unreachable blob from the above list. To verify that, do git show for every blob and see.

$ git show 6900c6418b5df26f6471b7d4853822d99fcf2534



Resources:

Tuesday, May 31, 2016

Eclipse RCP remote debugging

You have two Eclipse applications here

1. Target eclipse  - which you've shipped to client
2. Source eclipse -  source code application


Step 1: Launch target eclipse in debug mode

Note: Here AppceleratorStudio is my Eclipse-based product

Go to your eclipse:
$cd /Applications/Appcelerator Studio/AppceleratorStudio.app/Contents/MacOS

Then run the following command.

$./AppceleratorStudio -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8989

8989 is the port number where you're remote eclipse debug service is running on.

The moment you run the above command, you will get to see "Listening for transport dt_socket at address: 8989" mesasge on the console.



Step# 2: Launch your source eclipse.

  1. Select a project from the project explorer
  2. From toolbar debug menu, go to "Debug configurations..."
  3. Go to 'Remote Java Application'
  4. Right-click 'New'
  5. And provide the configuration something like below.
  6. Click on 'Apply' and 'Debug'







Monday, May 9, 2016

Control decoration example

boolean isInstalled =/**...**/


Button appBtn = new Button(myComp, SWT.CHECK);
appBtn.setText("Upload to Server");
appBtn.setEnabled(isInstalled);

final ControlDecoration dec = new ControlDecoration(appBtn, SWT.TOP | SWT.RIGHT);
dec.setImage(PlatformUI.getWorkbench().getSharedImages().getImage(ISharedImages.IMG_DEC_FIELD_WARNING));
dec.setDescriptionText("Upload to Server feature is not available on the current plan");
dec.show();

Thursday, May 5, 2016

Programatically changing the eclipse perspective

try
{
   PlatformUI.getWorkbench().showPerspective("StudioPerspective", PlatformUI.getWorkbench().getActiveWorkbenchWindow());
}
catch (WorkbenchException e)
{
  e.printStackTrace();

}

Thursday, April 7, 2016

Merging multiple commits into a single commit which are already pushed into a central repository

If you're merging local commits:

If the code is already pushed into a central repository and having multiple commits for a single fix/feature, now you wanted to merge couple commits into a single commit to make the git history clear.

Step 1: Identify how many last commits you wanted to merge ?

$ git reflog
4585fc6 HEAD@{0}: commit: fixig build scripts
c10447a HEAD@{1}: commit: fixing build issues
baa56c0 HEAD@{2}: commit: Using forked repo for testing
f744eec HEAD@{3}: commit: Missing tag
c30816d HEAD@{4}: commit: Missing tag
ea302be HEAD@{5}: commit: Removing bin folder
6560cb9 HEAD@{6}: commit: Build files and studio plugins folder structure

From above, I wanted to merge from HEAD@{0} to HEAD@{6} - That basically last 7 commits


Step 2: Rebase interactively

$ git rebase -i origin/master~7 master


Step 3:  Push the changes forcefully to a central repo

$ git push origin +master


Monday, March 21, 2016

Updating eclipse features/plugins from terminal


Format:
./eclipse -clean -purgeHistory -application org.eclipse.equinox.p2.director -noSplash -repository <update site url> -installIUs <feature ID> 


Examples:

./eclipse -clean -purgeHistory -application org.eclipse.equinox.p2.director -noSplash -repository http://download.eclipse.org/recommenders/updates/stable/ -installIUs org.eclipse.recommenders.repositories.categories.deps 


./eclipse -clean -purgeHistory -application org.eclipse.equinox.p2.director -noSplash -repository http://download.eclipse.org/mylyn/releases/latest -installIUs org.eclipse.mylyn.commons.sdk.feature.group


./eclipse -clean -purgeHistory -application org.eclipse.equinox.p2.director -noSplash -repository http://download.eclipse.org/mylyn/releases/latest -installIUs org.eclipse.mylyn.commons.notifications.feature.group


./eclipse -clean -purgeHistory -application org.eclipse.equinox.p2.director -noSplash -repository http://download.eclipse.org/modeling/emf/updates/releases/ -installIUs org.eclipse.emf.databinding.edit.feature.group



Resources:

Closing all the Virtual running machines in the system

http://askubuntu.com/questions/457329/shutting-down-all-virtualbox-vagrant-vms-in-one-easy-to-use-bash-command-that

kondals-MacBook-Pro:~ kondalkolipaka$ VBoxManage list runningvms
"default" {f12ab661-116e-42f0-8d2b-05fc76175022}

kondals-MacBook-Pro:~ kondalkolipaka$ VBoxManage controlvm default poweroff
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%


Here default is the VM name which is running. We can also provide UUID instead of name.

Wednesday, March 9, 2016

How to find the eclipse version number

In eclipse root directory you can find .eclipseproduct file

name=Eclipse Platform
id=org.eclipse.platform

version=4.4.2

You can also find the exact bundle id from - eclipse/configuration/config.ini

eclipse.buildId=4.4.2.M20150925-0400

Sunday, March 6, 2016

Eclipse non-model dialog

@Override
protected void setShellStyle(int newShellStyle) {           
     super.setShellStyle(SWT.CLOSE | SWT.MODELESS| SWT.BORDER | SWT.TITLE);
     setBlockOnOpen(false);
}


Friday, February 19, 2016

Text setMessage with SWT.MULTI style

Text setMessage with SWT.MULTI style - Yes, this doesn't work!.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=397695

Seems to be that's a native OS behaviour for Windows and GTK platforms.

Example:

Text  releaseNotesTxt = new Text(appPreviewComposite, SWT.MULTI | SWT.BORDER | SWT.WRAP | SWT.V_SCROLL );
releaseNotesTxt.setMessage("Enter your release notes for this build (Optional)");


But this works with SWT.Single or SWT.Search