| Age | Commit message (Collapse) | Author |
|---|
|
1/ le passage des Vectors aux Hashtables pour la collection des regexp, que
ce soit dans Ivy.java ( regexp_in ) ou dans IvyClient.java (regexp_out)
Les clefs sont des Integer ( msgid, et un serial incrémenté en sortie )
L'accès le plus simple pour modifier ces fichiers, c'est l'énumération sur
les clefs. On truve des choses comme:
for (Enumeration e = regexps.keys(); e.hasMoreElements(); ) {
Integer key=(Integer)e.nextElement();
// des choses avec regexps.get(key)
// ...
}
2/ Un bugfix sauvage sans IvyClient.java
Le msgarg n'était pas réinitialisé entre deux parsings de messages. Dans le
cas d'un message reçu sur une regexp sans groupement (.*), comme par
exemple ^AIRCRAFT:, on faisait tout de même passer la valeur précédente de
msgarg. C'est fini. Over. out. heraus schnell.
3/ j'avais dit deux ? dans le monde, il y a trois type de gens, ceux qui ne
savent pas compter, et les autres.
Je rajoute un TestIvySwing, qui nécéssite un swingall.jar, mais c'est un
problème de paquetage, et pas de libivy. En fait, ça devrait devenir à
terme un autre paquetage.
Yannick.
|
|
Il faut séparer plusieurs aspects:
1/ CVS pour la gestion de versions concurrentes, etc
2/ sources et byte code pour java en particulier. On peut dire que les .class
ou le .jar ( .zip ) qui les stocke est un binaires
3/ paquetages debian et redhat, c'est cradingue et n'a rien à voir avec CVS,
pour le moment. Mais je me trompe certainement.
Si on veut avoir des infos sur la politique d'empaquetement dans debian,
voir la page WWW suivante:
http://www.debian.org/~bortz/Java/policy.html
--
Yannick
|
|
Je fais hériter IvyMessageListener de java.util.EventListener, histoire d'être
un peu dans une logique de comm proche du modèle AWT/JFC.
|
|
Je fais hériter IvyMessageListener de java.util.EventListener, histoire d'être
un peu dans une logique de comm proche du modèle AWT/JFC.
|
|
|
|
|
|
|
|
|
|
|
