Friday, October 7, 2011

Emacs and J2EE on OSX notes

Here's how I've managed to setup Emacs for J2EE / Tomcat / Maven application development on OSX. 

Install Emacs

I use Emacs 23.3 from Emacs for OSX.

Malabar mode

Malabar mode offers easy code navigation, Maven, JUnit and Groovy integration. Download release 1.4 and extract in a directory to build it.

As the build will invoke emacs in batch mode, be sure that Emacs 23.3 is in your path (instead of using the one packaged with OSX).

What works on my machine:
cd espenhw-malabar-mode-1daaee4
export PATH=/Applications/$PATH
mvn package -DskipTests=true
Now in target directory there's a Unzip it where you put all your emacs librairies:

cd ~/.emacs.d/
unzip /path/to/malabar/target/

Configure Emacs for Malabar

Open your .emacs and add:
(add-to-list 'load-path (expand-file-name "~/.emacs.d/malabar-1.4.0/lisp/")) 

(require 'cedet)
(require 'malabar-mode)
(setq malabar-groovy-lib-dir "/path/to/malabar/lib")
(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))

(semantic-mode 1)
(require 'malabar-mode)
(setq malabar-groovy-lib-dir "~/.emacs.d/malabar-1.4.0/lib"
      malabar-load-source-from-sibling-projects t
      '( "/absolute/path/to/project1/src" 
        "/absolute/path/to/project2/src" ) ) ;; you need to setup this 

(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))

(add-hook 'malabar-mode-hook
     (lambda () 
       (add-hook 'after-save-hook 'malabar-compile-file-silently
                  nil t)))

Now open a .java file within Emacs.

Try malabar-jump-to-thing on one of your class and it should open the corresponding file.

Open a test file and try malabar-run-test. It should run maven test for this file. If all tests OK but finished with "BUILD FAILURE", then see next section

Java troubleshooting

Malabar should use java from jdk, not jde. I've tried setting JAVA_HOME and configure malabar without success. So quick dirty hack is:

cd /usr/bin
mv java java.jre
ln -s  /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java


Entreprise Java Development With Emacs

Debugging Tomcat

Install JDIBug. In jdibug-expr.el, change the line (and to forget to byte-recompile or remove .elc):
(require 'semantic-java)
(require 'semantic/java)
Configure emacs:

(add-to-list 'load-path "~/.emacs.d/jdibug-0.5")
(setq jdibug-connect-hosts (quote ("localhost:8000"))
      jdibug-use-jde-source-paths nil
			 "/path/to/project2/src"  ))
(require 'jdibug)
Start Tomcat like with debugger enabled:
./bin/ jpda start
Then try jdibug-connect to attach Emacs to tomcat.

Tuesday, July 12, 2011

TWM: Docking Windows

Using Pharo 1.4 and latest TWM packages, you can now group windows as tabs.

(ConfigurationOfTilingWindowManager project 
    version: #bleedingEdge) load

Tuesday, June 28, 2011

My Pharo image

Backup of my preferences:
Gofer it
   squeaksource: 'MetacelloRepository';
   package: 'ConfigurationOfPhexample';
   package: 'ConfigurationOfAutotest';
   squeaksource: 'TilingWindowManager';
   package: 'ConfigurationOfTilingWindowManager';
(Smalltalk at:#ConfigurationOfTilingWindowManager) perform: #loadDevelopment.
(Smalltalk at:#ConfigurationOfPhexample) load.
((Smalltalk at:#ConfigurationOfAutotest) project version: #development) load: 'OB'.

(Smalltalk at:#TWMUITheme) beCurrent. 
TaskbarMorph  showTaskbar: false.
TasklistMorph keepOpen: true.
(Smalltalk at:#TWMBar) perform: #showTWMBar: with: true.
(Smalltalk at: #AutotestDashboard) perform: #showAutotestDashboard: with: true.

Saturday, June 11, 2011

Albaaaaaator, Albaaaaaaator, capitaine au coeur d'or ......

Le papa d'Albator / Captain Harlock, Lieji Matsumoto, était à Annecy pour le festival d'animation.... on a la dédicace !!!

Nostalgie ....

Tuesday, June 7, 2011

Multiple Worlds for TWM

With the help of my local developper group, I've integrated Sean DeNigris work and now Tiling Window Manager supports Multiple Worlds.

Here's a screencast that shows the progress. (My English seems a little less catastrophic than the previous screencast :)

Note: The tests failing on the screencast (Pharo 1.2) are green on Pharo 1.3.

Load TWM with:
Gofer it
  squeaksource: 'TilingWindowManager';
  package: 'TWM';

And ConfigurationOfKeyMapping 1.7 (TWM do not work with 1.8 actually) with:
Gofer it
    squeaksource: 'ShortWays';
    package: 'ConfigurationOfKeymapping';
(ConfigurationOfKeymapping project version: '1.7') load.

Saturday, May 28, 2011

Tiling Window Manager

I love Emacs because of editing speed and fast buffer switching among a lot neat features.

This week I've tried to make Pharo a little better on window management. This video shows the progress (thanks Gastón and Patrick for help and ideas).

Next step: KeyMapping integration + history à la Emacs winner-mode.

Sorry for my soooooooo awful english (tired ....).

Update 05/31/2011: you can load last version with colored theme with:
Gofer it
  squeaksource: 'TilingWindowManager';
  package: 'TWM';
(Smalltalk at: #StandardUITheme) beCurrent.
(Smalltalk at: #TWMBar) showTWMBar:true.

Tested on PharoCore 1.2 and Pharo 1.3.

Now this has support for world snapshot, that means you can arrange the windows and take a snapshot of the layout. Then you can restore these layouts later. (icons camera, <, > and trash). I'm not entirely satisfied with this, thanks for feedback.

In Pharo 1.3 there's initial integration with KeyMapping. To load:

Gofer it
  squeaksource: 'ShortWays';
  package: 'ConfigurationOfKeymapping';

(Smalltalk at: #ConfigurationOfKeymapping project version: '1.7') load.

Then in settings browser > Keymappings > Tiling Window Managers you have all actions of the dock mapped.

You can choose a Layout Strategy in settings.

Actually there's Horizontal (default) and Vertical (last used windows fills all remaining space) strategies.

To add your own just subclass TWMLayoutStrategy and implement #tileWindows:

To load TWM:
Gofer it
 squeaksource: 'TilingWindowManager';
 package: 'TWM';

I also think the UI theme Patrick has cleaned fits better with TilingWM:
Gofer it
 squeaksource: 'PBASandbox';
 package: 'PBSandbox';
StandardUITheme beCurrent.

Thursday, April 14, 2011

Pomodoro scripts

Sous OSX j'utilise ce logiciel comme chronomètre qui a l'avantage de pouvoir exécuter des scripts lorsque le Pomodoro démarre, s'arrête, ....

Au travail on utilise beaucoup la messagerie instantanée. J'utilise Adium comme client.

  • je ne veux pas être dérangé pendant mon Pomodoro (passer mon état à indisponible)
  • je veux que mes collaborateurs sachent quand se termine mon Pomodoro pour me contacter


Dans Adium créer un statut indisponible avec comme titre'Pomodoro en cours'

Dans les préférences de Pomodoro, onglet script, configurez comme ceci:

tell application "Adium" to set the status of every account whose status type is available to the first status whose title is "Pomodoro en cours"

Reset et End:
tell application "Adium" to set the status of every account whose status type is away to the first status whose title is "Disponible"

Every 2 mins:
tell application "Adium" to set status message of every account to "Pomodoro en cours, fin dans $time mn"

Tout le long du Pomodoro votre statut sera mis à jour:

Et dès que quelqu'un ose vous contacter, réponse automatique !

Wednesday, April 13, 2011

Petite Horloge revisited

Another Pharo Smalltalk snippet with temp classes (I like this :)

(Class new
    superclass: StringMorph;
    setFormat: StringMorph format;
    compile: 'step self contents: Time now printString';
        openInWindowLabeled: 'Petite Horloge'.

Don't forget the setFormat: or the VM will crash.Some explanations.

Polymorph counter example

I've discovered that I can write this in Pharo:

"This creates a class and one instance on the fly"
counter := Class new 
              superclass: Object; 
              addInstVarNamed: 'counter'; 
              compile: 'initialize 
                           counter := 0';
              compile: 'counterString 
                           ^ counter asString';
              compile: 'increment 
                           counter := counter + 1. 
                           self changed:#counterString';
              compile: 'decrement 
                           counter := counter - 1. 
                           self changed:#counterString';

(UITheme builder newColumn: {
  UITheme builder newLabelFor: counter getLabel: #counterString getEnabled: nil.
  UITheme builder newRow: {
    UITheme builder newButtonFor: counter action: #increment label: '+' help: nil.
    UITheme builder newButtonFor: counter action: #decrement label: '-' help: nil.
}) openInWindowLabeled: 'Counter example'.

Coooooooooooooool ;)

Saturday, March 19, 2011

Multiple worlds for Pharo

Sean DeNigris submitted a changeset to get multiple worlds in Pharo.

I've played a little with it to get a world switcher. If you want it, first file in the changeset file (download it the drag the file on an opened image).

Then the following code add three worlds named 2,3,4 and create a dock in each world.

wm := WorldManager instance.
#('2' '3' '4') do: [:aString| wm createOrSwitchToWorldNamed: aString].

wm worlds keysAndValuesDo:  [:aWorldName :aWorld| |dock|
  dock := DockingBarMorph new
          openInWorld: aWorld.

  wm worlds keysAndValuesDo: [:aWorldName2 :aWorld2|
    dock addMorph: (SimpleButtonMorph new
                    label: aWorldName2;
                    target: [wm createOrSwitchToWorldNamed: aWorldName2];
                    actionSelector: #value) ].
  dock addMorph: (StringMorph contents: aWorldName).

Monday, February 28, 2011

Work on Mocketry

Mocketry is a Mocketry is Smalltalk mock object framework.

To load it in Pharo:
Gofer it
  squeaksource: 'MetacelloRepository';
  package: 'ConfigurationOfMocketry';

(Smalltalk at:#ConfigurationOfMocketry) project latestVersion load.

I've done the first part of the Picasa screencast in a TDD way using Mocketry to prevent external HTTP requests.
Gofer it
 squeaksource: 'LaurentLSandbox';
 package: 'Picasa';

As the requests are done using HTTPSocket class>>httpGet:, one way is to give a mock to PicasaSearch so we can check (and stub) the HTTP request:
    [photos := PicasaSearch new
        httpSocketClass: mockHTTPSocketClass;
        addKeyword: 'rough';
        addKeyword: 'sea';  
        maxResult: 2;
     should strictly satisfy: [
        (mockHTTPSocketClass httpGet: 
        willReturn: self fixtureXMLResponseForTwoRoughSea] 
  ] runScenario.

#fixtureXMLResponseForTwoRoughSea will return an XML string and test methods will check that it is correctly parsed.

In PicasaSearch:
  url := String streamContents: [:aStream|
    nextPutAll: '';
    nextPutAll: ('+'  join: self keywords);
    nextPutAll: '&max-results=';
    nextPutAll: self maxResult asString.    

  ^ (self httpSocketClass httpGet: url).

See that mocketry extends BlockClosure to create mocks:
[:myFirstMock :mySecondMock|
"do stuff with mocks"
] runScenario

and set up expectations:
[:myFirstMock :mySecondMock|
  [ "do stuff with mocks" ] 
  should strictly satisfy: 
  [ "what is expected on mocks" ]  
] runScenario

See HelpSystem book loaded with Mocketry for several examples.

Comments and better code propositions are welcome.

Monday, February 21, 2011

XML Browser with Pharo

I've written a little tool to help me browse xml. If you want to try it:
Gofer new
 squeaksource: 'LaurentLSandbox';
 package: 'XML-GUI';
((Smalltalk at:#XMLBrowser) labelled: 'Picasa search')

See XMLBrowser comment for examples.

Friday, February 18, 2011

FizzBuzz Kata: minimal solution

Trying to find a minimal solution for the FizzBuzz Kata in Smalltalk:

fb := [:counter| |rules|
       rules := {15->'FizzBuzz'. 5->'Buzz'. 3->'Fizz'. 1->counter}.
       rightRule := rules detect: [:aRule| counter \\ aRule key == 0].
       rightRule value].  

self assert: (fb value: 7) == 7.
self assert: (fb value: 3) == 'Fizz'.
self assert: (fb value: 5) == 'Buzz'.
self assert: (fb value: 15) == 'FizzBuzz'.

1 to: 100 do: [:counter | 
                 show: (fb value: counter) asString;

Update: Little variant from Alexandre:
rightRule := rules detect: [:aRule| counter isDivisibleBy: aRule key]

Tuesday, February 8, 2011

Smalltalk tiny exercise for TDD newbies

Done in course:

Create the category Exercise in the Browser. All classes you create will be placed in this category.

Implement the class Operation (using Test-Driven Development) which should work like this:
  1. a := Operation new.
    a result.
    Should return 0.
  2. b := Operation new.
    b add: 2.
    b add: 3.
    b result.
    Should return 5.
  3. Operation new
      add: 2;
      add: 4;
      divideBy: 2;
    Should return 3.

Add the message Operation>>#multiplyBy by yourself.

Sunday, February 6, 2011

new funny ProfStef lesson

Update to last ProfStef (on Pharo 1.2 only):

Gofer it
 squeaksource: 'MetacelloRepository';
 package: 'ConfigurationOfProfStef';
ConfigurationOfProfStef project latestVersion load.

  tutorial: SmalltalkSyntaxTutorial lesson: #instanciation.

Wednesday, February 2, 2011

Why technology matters

Life is very short. You have a limited amount of time in which to realize your dreams, in which to do your projects. If you’re like me, you probably have dozens and dozens of ideas for apps, sites, portals, that you want to implement. Most of those ideas will suck. But you don’t know which ones, you won’t know until you try them. Your goal, in this life, is to iterate faster. To fail more, to fail quicker, until you get to the brilliant ideas and brilliant projects that can change the world, or at least make you a dollar or two.

From A Secret: Passion and Your Choice of Web Framework by Dmitri Zagidulin

Friday, January 28, 2011

Smalltalk à l' 2010

Et là j'ai peur en me voyant en vidéo ....

Tuesday, January 25, 2011

Pharo GUI with Polymorph

I've written a tiny address book to prepare a screencast on Polymorph basis. If you want to look at it:
Gofer it
 squeaksource: 'Pharocasts';
 package: 'ContactManager';
(Smalltalk at:#ContactListEditor) open.

Start by looking how the contact list is built:
  |builder content|
  builder := UITheme builder.
  content := builder newColumn: {   
                newListFor: self   
                list: #contacts
                selected: #contactSelectedIndex
                changeSelected: #contactSelectedIndex:
                help: 'contacts'.
        builder newRow: {
                builder newButtonFor: self 
                        action: #addButtonClick 
                        label: 'Add' 
                        help: 'Create a new contact'.
                builder newButtonFor: self 
                        action: #removeButtonClick 
                        getEnabled: #hasSelectedContact 
                        label: 'Remove' 
                        help: 'Remove selected contact'.
                builder newButtonFor: self 
                        action: #editButtonClick 
                        getEnabled: #hasSelectedContact 
                        label: 'Edit' 
                        help: 'Edit selected contact'  }}.
  (content openInWindowLabeled: 'Contacts') extent: 400@500.
#newRow: and #newColumn: are an easy way to align elements on the window.

When the Add button is clicked, message #addButtonClick is sent on the ContactListEditor object:
  newContact := Contact new.
  ContactEditor new
        contact: newContact;
        onOK: [ Contact database add: newContact.  
                selectedContactIndex := Contact database size.
                        changed: #contacts;
                        changed: #hasSelectedContact];
The closure given to onOK: adds the new Contact and tells the view to refresh components which depends on #contacts and #hasSelectedContact selectors - that means the contact list and the Remove and Edit buttons.

ContactEditor defines a modal dialog to edit the firstName and lastName of a Contact:
  |builder dialog content firstName|
  builder := UITheme builder.
  content := (builder newLabelGroup: {
                'First name' -> (
                       firstName := (builder
                         newTextEntryFor: contact
                         getText: #firstName
                         setText: #firstName: 
                         help: 'Enter the first name of the contact')
                       acceptOnCR: false;
                       minWidth: 200).
                'Last name' -> (
                          newTextEntryFor: contact 
                          getText: #lastName 
                          setText: #lastName: 
                          help: 'Enter the last name of the contact')
                        acceptOnCR: false;
                        minWidth: 200) }).
  dialog := builder 
              newPluggableDialogWindow:'Edit contact' 
              for: content.
  dialog rememberKeyboardFocus: firstName.
  builder openModal: dialog.
  dialog cancelled ifFalse: [self doOnOK].
From Gary Chambers (and thanks !):

Disabling the acceptOnCR for each text frield allows the default dialog handling for the return key (defaults to OK).

Normally the initial keyboard focus for a dialog is the default button, if specified. Remembering the first name field prior to opening will give that field focus.

Now it should be easier to understand Polymorph examples found in
UITheme class>>exampleBasicControls and friends (in examples protocol).

Monday, January 24, 2011

CodeRetreat à Grenoble

Vendredi dernier je me suis rendu au premier CodeRetreat en France organisé par Johan Martinsson, Remy Sanlaville et Miguel Moquillon, avec le soutien du CARA et Alpes JUG - merci tout le monde !

En résumé, le CodeRetreat consiste à enchaîner des itérations d'une heure en pair-programming et Test-Driven Development sur le même problème tout au long de la journée. Le problème choisi était le jeu de la vie, qui a les avantages d'offrir plusieurs approches possibles et d'être assez complexe pour ne pas être résolu en 45mn.

Chaque itération se déroule de la manière suivante:

  1. Constitution des binômes (on change à chaque itération).
  2. 45mn de programmation.
  3. 15mn de rétrospective.

C'est agile, le temps est chronométré (belle organisation).

A la fin des 45mn de programmation, le code est effacé. Comme l'a répété Johan, ce n'est pas le résultat qui compte, mais la démarche, l'approche du développement qu'on doit s'efforcer de faire le plus parfaitement. C'est à dire:

  • développement piloté uniquement par les tests
  • pas de duplication de code
  • noms clairs et significatifs
  • code le plus simple possible

Côté langages nous avions beaucoup de Java. Miguel et moi en avons profité pour faire découvrir Pharo / Smalltalk et faire une session ensemble en Haskell. Il y a aussi eu un peu de Ruby.

Les 15mn de rétrospective permettaient d'échanger sur les différentes approches, les difficultés rencontrées, succès. On voit bien qu'il y a plusieurs manières d'attaquer le problème. Au fur et à mesure des automatismes se mettent en place ce qui permet de gagner du temps pour aborder d'autres aspects du problème.

Suit ce que j'en retire.


Chaque session se déroulait avec un binôme différent et chaque expérience, démarche a du coup été significativement différente. J'ai rencontré plusieurs cas:

  • une personne qui a l'idée et une autre qui suit: c'est du coup souvent la personne qui veut voir son idée réalisée qui pilote et qui tape. La personne qui suit dépense beaucoup d'énergie pour rester dans le coup (j'ai été dans cette position sur une session). Il est nécessaire que la personne qui pilote temporise.
  • deux personnes qui ont des idées: cela amène assez vite a quelques débats sympathiques mais c'est l'expérience qui me semble la plus enrichissante, d'où émerge des solutions de type "waouh, ça c'est cool".
  • deux personnes ont la même idée, suivent la même route: dans ce cas c'est plus la volonté de bien faire qui ressort et la recherche de qualité / perfection dans la démarche est vraiment élevée

Dans tous les cas, il y a toujours une bonne ambiance à coder avec des inconnus :)

Test-Driven Development:

Je suis convaincu de la démarche et la pratique depuis que j'ai lu eXtreme Programming de Kent Beck vers 2002/2003. Donc je fais partie des gens qui ont des automatismes assez arrêtés sur le sujet :). Pour avoir vu d'autres façons de faire au cours de la session, je reste persuadé que la manière la plus claire est d'avoir:

  • un TestCase par contexte. Le setUp établit le contexte, les tests font les vérifications.
  • un assert par test. Avoir plusieurs assert doit rester exceptionnel car ça complexifie les tests (ce n'est pas interdit, mais il faut avoir conscience du compromis).

Un exemple concret est la règle: "Si une cellule a exactement deux voisines vivantes, elle reste dans son état actuel à l’étape suivante".

Avec Rémy nous avons codé comme suit (grosso modo, le code a été effacé :)

  aliveCell := Cell new revive.
  self assert: aliveCell isAlive.

  2 to: 3 do: [:numberOfNeighbours|
    aliveCell numberOfNeighbours: numberOfNeighbours.
    self assert: aliveCell shouldLive.

Le soucis c'est que quand le test est en échec, il faut débugger pour savoir si ça coince pour deux ou trois cellules.

Dans ce cas je préfère avoir deux cas:
  • ALivingCellWithTwoLivingNeighbours
  • ALivingCellWithThreeLivingNeighbours

Ceci dit cela risque d'amener une duplication de code, vu que les tests sont identiques dans chaque cas. Une solution codée avec Aline est d'utiliser des Traits pour définir les tests de manière générique puis de mettre seulement les différences dans les TestCase.

Trait named: #TCellIsAliveAndShouldLive

  self assert: self aliveCell isAlive

  self assert: self aliveCell shouldLive

   self explicitRequirement 

Du coup pour nos cas de test:
TestCase subclass: #ALivingCellWithTwoLivingNeighbours
  uses: TCellIsAliveAndShouldLive

  ^ Cell new
       numberOfNeighbours: 2.

de même:
TestCase subclass: #ALivingCellWithThreeLivingNeighbours
  uses: TCellIsAliveAndShouldLive

  ^ Cell new
        numberOfNeighbours: 3.


Les deux approches principales consistaient à commencer par implémenter la Cellule ou bien la Grille / Univers. Il était aussi possible de passer par une classe Neighbours intermédiaire.

Haskell qui est un langage fonctionnel permet d'avoir une approche par les ensembles.

Une solution liée à l'imagerie en travaillant en binaire a été évoquée mais pas implémentée à ma connaissance.

Pour simplifier l'algorithme qui calcule si la cellule doit vivre ou mourir en connaissant son état actuel et le nombre de ses voisins vivants, deux variantes:
  • avoir deux classes LiveCell et DeadCell qui ont chacune leur algorithme
  • implémenter le pattern strategy et donc un objet Cell utiliserait soit un DeadCellStrategy, soit un LiveCellStrategy. Ceci à l'avantage de ne pas avoir à changer le type des instances dans la grille

Avec Smalltalk une solution utilisée pour implémenter le pattern strategy se basait sur les Closures et évitait de créer des classes supplémentaires:

    ^ [(liveNeighbours < 2) or: [ liveNeighbours > 3 ]]

    ^ [(liveNeighbours = 3) not]

    shouldDieStrategy := self deadCellStrategy

    shouldDieStrategy := self liveCellStrategy

    ^ shouldDieStrategy value


Journée enrichissante et éreintante. La retrospective finale en a un peu pâti vu que tout le monde était fatigué. Une proposition d'amélioration qui me plaît est de découper la session de 45mn en deux pomodoro de 20mn pour ménager notre énergie.

Quelques "Smalltalk c'est cool" font plaisir ;)

En tout cas je reste convaincu par l'approche pair-programming qui est trés enrichissante et donne du courage pour explorer de nouvelles pistes et aller plus vite (car on se perds moins).

C'est dans ces moments là qu'on sent que la programmation est un artisanat au sens noble du terme, où la beauté du résultat est une source de motivation.

Par @bootis quality = you know why it works

Le compte-rendu de Johan

Friday, January 14, 2011

PharoConf Annecy 2011

La première PharoConf Annecy aura lieu le jeudi 10 février à l'IMUS.

Site web de l'évènement:

Les interventions seront plus tournées vers des coding-dojo et ateliers, développer du vrai code qui tourne :)

Deux points forts:
- Randori Test-Driven Development animé par Miguel Moquillon du Club Agile Rhône Alpes
- PharoSprint animé par Stéphane Ducasse

Entrée gratuite, mettez à jour vos agendas !

(Et merci de faire passer le message :)

Monday, January 10, 2011

Petite horloge

Morphic basics with a little Watch (Horloge in french).

Add the class:
StringMorph subclass: #Horloge
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 category: 'Sandbox'

One method called periodically thanks to stepping mechanism of Morphic:
 self contents: Time now printString.

Then evaluate in a Workspace:
Horloge new openInWorld.

Stop the watch:
Horloge allInstances last stopStepping

Start it again:
Horloge allInstances last startStepping

Finally close it:
Horloge allInstances last delete