Comme la M6, il ne marche pas chez moi. Il plante au demmarage avec cette pile :
!SESSION ----------------------------------------------------------------------
!ENTRY org.eclipse.core.launcher 4 0 janv. 18, 2004 10:23:10.942
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NullPointerException
at org.eclipse.ui.keys.KeyStroke.hashCode(KeyStroke.java:308)
at java.util.HashMap.hash(Unknown Source)
at java.util.HashMap.get(Unknown Source)
at org.eclipse.ui.internal.commands.KeySequenceBindingNode.add(KeySequenceBindingNode.java:175)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.validateTree(KeySequenceBindingMachine.java:224)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.validateSolution(KeySequenceBindingMachine.java:203)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.getKeySequenceBindingsByCommandId(KeySequenceBindingMachine.java:73)
at org.eclipse.ui.internal.commands.CommandManager.calculateKeySequenceBindings(CommandManager.java:274)
at org.eclipse.ui.internal.commands.CommandManager.readRegistry(CommandManager.java:701)
at org.eclipse.ui.internal.commands.CommandManager.(CommandManager.java:233)
at org.eclipse.ui.internal.commands.CommandManager.(CommandManager.java:196)
at org.eclipse.ui.commands.CommandManagerFactory.getCommandManager(CommandManagerFactory.java:41)
at org.eclipse.ui.internal.commands.ws.WorkbenchCommandSupport.(WorkbenchCommandSupport.java:49)
at org.eclipse.ui.internal.Workbench.init(Workbench.java:743)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1459)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:246)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:47)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:279)
at org.eclipse.core.launcher.Main.run(Main.java:742)
at org.eclipse.core.launcher.Main.main(Main.java:581)
Si quelqu'un a une idée, je suis preneur, mais je l'ai sur trois machines différentes
Je suis interressé par le nouveau search, l'affichage de la propagation des exceptions dans l'éditeur, la pile d'icones dépliable sur les éditeurs (ça commençait à devenir gros), le nouvel affichage des display dans le debugger (comme avec le visual C++),
"Configurable tab width for text editors"
Je HAIS ça ! Une tabulation doit être représentée par 8 caractères, pas 4. Ca favorise le mélange de tabulations et d'espaces dans le code, rendant l'affichage (et donc l'indentation) inégale selon l'éditeur.
C'est pour ca qu'il ne faut pas utilisater les vrai tabulations mais la transformation tab->espace.
Et puis 8 et 4.... C'est beaucoup trop gros comme tabulation. Avec 2 espaces par indentation c'est très clair et on ne fait pas agrandir trop le code. D'autant plus qu'un code ne devrait pas dépasser 80 colonnes de larges pour pouvoir etre facilement lisible et imprimable sans avoir des retours a la ligne dans tous les sens :)
pas du tout efface ;-)
L'usage du caractère tabulation à pour but justement de définir le niveau d'indentation d'une manière on ne peut plus simple. Si après du décide avec ton éditeur de l'_afficher_ par un nombre définit d'espace, c'est tant mieux pour toi mais le niveau d'indentation devrait toujours être codé avec le caractère tab.
Si tous les éditeurs avaient été capable de faire cela, on n'en serait pas là aujourd'hui à se faire chier avec tous ces gens qui utilisent un nombre différent d'espace pour indenter.
pour répondre à thranduil, je vois pas comment quelque chose de configurable peut te poser un problème.
En théorie c'est très beau, mais dans la pratique, je n'ai encore jamais rencontré de code indenté de haut en bas avec les bonnes tabulations. Parfois il y a des tabulations et parfois des espaces et la c'est vraiment moche... Parce que tu es alors obligé de reprendre le meme nombre d'espace par tabulation du mec qui a écrit le code si tu veux pouvoir y comprendre quelque chose... Et quand il arrive que ce soit 4 ou 8 espaces, je pete un plomb.
Donc moi j'ai décidé de tout mettre a 2 espaces, comme ca il n'y a plus de mélange possible espace/tabulations... Et le code ne prend pas trop de place.
Ca ne pose pas de problème quand une seule personne code.
Par, voici un cas que j'ai rencontré au boulot.
Sur du code C d'un projet Unix, je m'étonnais de voir le code en dent de scie. Bien sûr, tout le monde sur le projet certifie qu'il respecte l'indentation du code. Et puis je finis par repérer un (et non pas le) coupable : un type qui code avec ultraedit en ftp (avec netdrive, une vraie cata). Et lui a décidé de représenter une tabulation par 2 espaces, parceque c'est plus lisible sur son écran.
Sauf que quand il reprend du code écrit sous vi avec de l'indentation automatique (donc des tabulations), on se retrouve avec un affreux mélange. A la prochaine édition sous vi, rien ne va plus.
Alors effectivement, l'idéal serait d'interdire les tabulations, et de définir des normes de codage pour que tout le monde indente avec le même nombre d'espaces, mais :
- les gens n'aiment pas changer leurs habitudes, ils indentent toujours de la même façon (pire encore, le placement des accolades, c'est la guerre)
- Sous vi (le vrai, dispo sous cette chiotte de HPUX par exemple), l'indentation automatique n'existe qu'avec des tabulations. Alors, oui, il y a emacs, mais on ne va pas nourrir le troll.
Je ne vois pas de solutions.
Ah, j'ai failli oublier, nous sommes dans un contexte de SSII, avec des motivations alimentaires.
Une solution pourrait être d'imposer l'utilisation d'un outil de mise en forme du code (avec le même paramètrage pour tout le monde évidemment) avant un "check in" dans le gestionnaire de versions.
Un truc comme jalopy pour ceux qui codent en java par exemple.
Comme ça chacun utilise son éditeur favori et malgré tout le code aura toujours une gueule homogène dans CVS (ou subversion ou ce que vous utilisez).
Malgré tout c'est peut être un peu lourd comme procédure :-)
Tiens d'ailleurs c'est une idée ! existe-t-il un moyen d'appeler systématiquement un outil de remise en forme du code lors d'un "check in" dans un outil de gestion de version ?
y'a moyen de faire ça avec CVS dans un fichier du genre commitinfo, mais ça peut être lourd. Et j'aime pas trop l'idée du fichier commité différent de ce que le type a tappé. Un outil comme indent est très utile, notamment quand on fait une reprise de code, mais sans contrôle du developpeur, c'est free style.
# Re: Eclipse 3.0 M7
Posté par pinceau . Évalué à 1.
!SESSION ----------------------------------------------------------------------
!ENTRY org.eclipse.core.launcher 4 0 janv. 18, 2004 10:23:10.942
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NullPointerException
at org.eclipse.ui.keys.KeyStroke.hashCode(KeyStroke.java:308)
at java.util.HashMap.hash(Unknown Source)
at java.util.HashMap.get(Unknown Source)
at org.eclipse.ui.internal.commands.KeySequenceBindingNode.add(KeySequenceBindingNode.java:175)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.validateTree(KeySequenceBindingMachine.java:224)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.validateSolution(KeySequenceBindingMachine.java:203)
at org.eclipse.ui.internal.commands.KeySequenceBindingMachine.getKeySequenceBindingsByCommandId(KeySequenceBindingMachine.java:73)
at org.eclipse.ui.internal.commands.CommandManager.calculateKeySequenceBindings(CommandManager.java:274)
at org.eclipse.ui.internal.commands.CommandManager.readRegistry(CommandManager.java:701)
at org.eclipse.ui.internal.commands.CommandManager.(CommandManager.java:233)
at org.eclipse.ui.internal.commands.CommandManager.(CommandManager.java:196)
at org.eclipse.ui.commands.CommandManagerFactory.getCommandManager(CommandManagerFactory.java:41)
at org.eclipse.ui.internal.commands.ws.WorkbenchCommandSupport.(WorkbenchCommandSupport.java:49)
at org.eclipse.ui.internal.Workbench.init(Workbench.java:743)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1459)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:246)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:47)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:279)
at org.eclipse.core.launcher.Main.run(Main.java:742)
at org.eclipse.core.launcher.Main.main(Main.java:581)
Si quelqu'un a une idée, je suis preneur, mais je l'ai sur trois machines différentes
[^] # Re: Eclipse 3.0 M7
Posté par Roger Rabbit . Évalué à 1.
As tu pensé à supprimer ~/.eclipse et ~/.workspace ?
# Re: Eclipse 3.0 M7
Posté par pinceau . Évalué à 1.
http://download.eclipse.org/downloads/drops/S-3.0M7-200402122000/ec(...)
http://download.eclipse.org/downloads/drops/S-3.0M7-200402122000/ec(...)
http://download.eclipse.org/downloads/drops/S-3.0M7-200402122000/ec(...)
Je suis interressé par le nouveau search, l'affichage de la propagation des exceptions dans l'éditeur, la pile d'icones dépliable sur les éditeurs (ça commençait à devenir gros), le nouvel affichage des display dans le debugger (comme avec le visual C++),
[^] # Re: Eclipse 3.0 M7
Posté par pinceau . Évalué à 1.
[^] # Re: Eclipse 3.0 M7
Posté par Jean-Marc Spaggiari . Évalué à 1.
# Re: Eclipse 3.0 M7
Posté par thranduil . Évalué à 1.
Je HAIS ça ! Une tabulation doit être représentée par 8 caractères, pas 4. Ca favorise le mélange de tabulations et d'espaces dans le code, rendant l'affichage (et donc l'indentation) inégale selon l'éditeur.
[^] # Re: Eclipse 3.0 M7
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 1.
Et puis 8 et 4.... C'est beaucoup trop gros comme tabulation. Avec 2 espaces par indentation c'est très clair et on ne fait pas agrandir trop le code. D'autant plus qu'un code ne devrait pas dépasser 80 colonnes de larges pour pouvoir etre facilement lisible et imprimable sans avoir des retours a la ligne dans tous les sens :)
[^] # Re: Eclipse 3.0 M7
Posté par benja . Évalué à 1.
L'usage du caractère tabulation à pour but justement de définir le niveau d'indentation d'une manière on ne peut plus simple. Si après du décide avec ton éditeur de l'_afficher_ par un nombre définit d'espace, c'est tant mieux pour toi mais le niveau d'indentation devrait toujours être codé avec le caractère tab.
Si tous les éditeurs avaient été capable de faire cela, on n'en serait pas là aujourd'hui à se faire chier avec tous ces gens qui utilisent un nombre différent d'espace pour indenter.
pour répondre à thranduil, je vois pas comment quelque chose de configurable peut te poser un problème.
[^] # Re: Eclipse 3.0 M7
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 1.
Donc moi j'ai décidé de tout mettre a 2 espaces, comme ca il n'y a plus de mélange possible espace/tabulations... Et le code ne prend pas trop de place.
[^] # Re: Eclipse 3.0 M7
Posté par thranduil . Évalué à 1.
Par, voici un cas que j'ai rencontré au boulot.
Sur du code C d'un projet Unix, je m'étonnais de voir le code en dent de scie. Bien sûr, tout le monde sur le projet certifie qu'il respecte l'indentation du code. Et puis je finis par repérer un (et non pas le) coupable : un type qui code avec ultraedit en ftp (avec netdrive, une vraie cata). Et lui a décidé de représenter une tabulation par 2 espaces, parceque c'est plus lisible sur son écran.
Sauf que quand il reprend du code écrit sous vi avec de l'indentation automatique (donc des tabulations), on se retrouve avec un affreux mélange. A la prochaine édition sous vi, rien ne va plus.
Alors effectivement, l'idéal serait d'interdire les tabulations, et de définir des normes de codage pour que tout le monde indente avec le même nombre d'espaces, mais :
- les gens n'aiment pas changer leurs habitudes, ils indentent toujours de la même façon (pire encore, le placement des accolades, c'est la guerre)
- Sous vi (le vrai, dispo sous cette chiotte de HPUX par exemple), l'indentation automatique n'existe qu'avec des tabulations. Alors, oui, il y a emacs, mais on ne va pas nourrir le troll.
Je ne vois pas de solutions.
Ah, j'ai failli oublier, nous sommes dans un contexte de SSII, avec des motivations alimentaires.
[^] # Re: Eclipse 3.0 M7
Posté par jde . Évalué à 1.
Un truc comme jalopy pour ceux qui codent en java par exemple.
Comme ça chacun utilise son éditeur favori et malgré tout le code aura toujours une gueule homogène dans CVS (ou subversion ou ce que vous utilisez).
Malgré tout c'est peut être un peu lourd comme procédure :-)
Tiens d'ailleurs c'est une idée ! existe-t-il un moyen d'appeler systématiquement un outil de remise en forme du code lors d'un "check in" dans un outil de gestion de version ?
[^] # Re: Eclipse 3.0 M7
Posté par thranduil . Évalué à 1.
# Re: Eclipse 3.0 M7
Posté par thranduil . Évalué à 2.
[^] # Re: Eclipse 3.0 M7
Posté par void . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.