Reprise du message précédent :
tu peux le faire en une seule passe.

C'est un choix après, mes visuels (assez gros) n'auront qu'une faible marge transparente, une seule passe serait plus long je pense.
 
Enfin voilà, c'est pas des plus propre mais ça semble remplir son rôle

heu, ok, c'est toi qui vois.

Réflexe con de premature optimisation, mais ta boucle interne itère verticalement, ce qui signifie probablement une perte inutile de performance sur la plupart des implés de buffer d'image (qui rangent les choses par ligne en priorité). Tu gagnerais probablement à inverser tes 2 boucles.

Sinon je l'aurais fait en 4 passe plutôt que 2 ou 1, mais chacun ses gouts

Ok c'est fait.
Par contre je reste sur 2 passes, 4 passes me semblent inutile.
En fait le top serait que ces 2 passes s'arrêtent au milieu de leur première itération... C'est ce que je vais faire

Edit: Ah nan en fait je dis n'imp faut que les 2 passes fassent tout

Moi je dis 4 passes, comme 0x90 :
- à partir du début, on cherche la première ligne contenant un alpha !=0.0, on stop dès qu'on trouve
- à partir du début, on cherche la première colonne, on stop dès qu'on trouve
- à partir de la fin, on cherche la dernière ligne, on stop dès qu'on trouve
- à partir de la fin, on cherche la dernière colonne, on stop dès qu'on trouve
En se déplaçant dans un tableau de pixels à coup d'indice, pour éviter des appels trop fréquents à une méthode getPixel() (sauf si ton appel a vraiment un coût faible, c'est possible après tout)
 

Pareil sauf je permuterais la phase 2 et 3, et que les verticales je les ferais en coupant le haut et le bas, sans repasser là où les phases horizontales sont déjà passées.

avant de vous branler sur le parcours, allez mater le code de getAlpharaster().
 
clairement, les perfs il s'en fout, c'est pour ça que je proposais une seule passe : pour avoir moins de code.

 
Ah bah ça, J'avais préviendu hein

 
Tof

+1000

Je crois qu'il dit, on dirait une blague qu'aurait pu faire ma prof de C, une vieille femme de 40 ans androgyne.

I DON'T BELIEVE YOU, CLEARLY HIS C TEACHER LOOKS LIKE MILLA JOVOVICH§§§

 
I SECOND THIS INSIGHTFUL STATEMENT§§§

Salut à tous,
 
Quelques uns ont déjà tâté l'inscription d'un programme java en tant que service ? L'idée est de mettre ça en place pour un programme assez light sous du Windows 2003 Server.
 
JavaService n'a plus l'air maintenu, Java Service Wrapper semble convenir, mais on resterait sur la version Comunity pour le moment. Des retours sur tout ça ?

CruiseControl utilise Java Service Wrapper. C'est configurable à souhait.

Par curiosité, je cherche à pouvoir configurer une liste de valeur dans un fichier properties que je veux passer à un PropertyPlaceholderConfigurer mais il n'a pas l'air de savoir faire ça de base.

Genre je reve d'un truc comme ca

et dans mon bean un truc elastique:

Je vois pas trop de possibilité d'extensions de cette classe sans me casser la tete, une idée ?

(j'ai l'impression qu'on en a déjà parlé) y'a qqun qui comprend assez bien jndi/resources/tomcat-et-autres-appserver pour me dire si c'est possible de configurer une simple String ou un chemin (java.io.File) dans mon context xml, similaire a ce qu'on fait pour les datasources et autres ?

ptain, boulet.

Dites moi, vous suivez un fil d'informations Java, style blog?
 
Car j'essaie d'en trouver un qui soit régulièrement alimenté à des fins de veille techno mais je trouve rien d'extraordinaire.

theserverside mais c'est pas tres utile pour moi au quotidien

le plus utile c'est la newsletter de Kabutz : http://www.javaspecialists.eu/archive/archive.jsp
 
mais c'est vrai que le java, je suis pas trop l'actualité.

Le site de Dider Girard est pas mal (et en francais) : http://www.application-servers.com/
 
apres bien sure tu as theserverside et infoq (qui est pas 100% java)

 
Han le faux espoir

J'aimerais bien qu'on arrête de boycotter mes questions ici, et qu'on y réponde, ou qu'on FERME SA GUEULE, au lieu de flooder avec des âneries qui n'ont pas leur place ici.
MERCI.

I HAS WIN !

 
 
DZone est pas mal : http://www.dzone.com/feed/frontpage/java/rss.xml

*** Moment cross-posting de questions noobs en Java ***
 
(j'ai bien posé ces questions sur le Blabla de base, mais ils tardent à répondre, c'te bande d'experts en bois )
 
Salut les gros, long time no see. J'ai 2 questions à la con en Java, essentiellement passke j'ai jamais eu l'occase de pratiquer ces trucs et que j'y ai droit sur un pétÿt projet perso à la con.
 
1) je veux sérialiser des données de mon soft sous diverses formes, au choix de l'utilisateur dans un fichier de conf : fichier plat ou DB. J'ai fait une factory qui retourne un objet imlpémentant une interface avec les méthodes load() et save(). Problème, j'aimerais remonter les exceptions potentielles (type FileNotFound pour le fichier plat), mais du coup je vois pas trop comment exposer ça dans mon interface ? J'ai pensé faire une exception générique qui contient l'exception originale mais je trouve ça bien dégueu Idées, suggestions ?
 
2) comment on fait un système de plugins pas trop con ? (j'aimerais éviter les fichiers XML descriptifs) Je pensais qu'il existait un truc de base dans le JDK pour lister toutes les classes implémentant une même interface mais en fait ça a l'air bien bordel Chu tombé sur ServiceLoader (depuis 1.6) qui a pas l'air trop moche, mais comment font les softs pré-1.6 qui ont des plugins ?

Je vois pas trop en quoi c'est vraiment dégueulasse en fait, qu'est-ce qui te choque avec cette approche ?
Je vois bien une exception UnderlyingStorageError qui signale que le conteneur utilisé pour sauvegarder les données a chié dans la colle, et qui encapsule l'exception réelle, dont tu peux récupérer le message au passage.

C'est exactement ce que j'avais pensé mais je trouve ça crade parce que lors du traitement réel faut se palucher des if(e instanceof FileNotFound) et ce genre de trucs. Ch'ais pas, j'ai l'impression que ça fait bricolage pour pouvoir juste utiliser une interface

 
Comment ça lors du traitement réel ? Une fois que tu récupères l'exception dans ton appli après le save() ?

Bin ui ; tu fais appel à ta factory, qui te renvoie un objet de type InterfaceStorage puis tu appelles load() ou save(). Derrière faut traiter l'exception et en fonction du type d'exception (FileNotFound, I/O, ConnectionException, etc...) tu fais un traitement différent. Et je trouve dommage de passer par de l'encapsulation pour au final se repalucher une suite de if(instanceof)

Pourquoi il y aurait un traitement particulier si c'est un FileNotFound ?

Il faut que ton interface renvoie toutes les exceptions alors, mais bon courage. Si Ton implémentation balance une PasPrevuExceptionParLaClasseAppelante, tu sera coincé.

Ne serait-ce que pour afficher un message différent si on est dans une GUI ? Et pis même, en fonction du type de storage (file, DB...), je vais vouloir dire "ah ba y a pas de connexion possible à la base" ou "le fichier n'existe pas" ou "y a un pb de droits" ou que sais-je encore. Logger la stack trace pour le debug c'est bien gentil mais j'aimerais être un peu plus fin que ça en fonction de ce que je prends comme exception.
La raison fonctionnelle, c'est que mon soft tournera à distance et si jamais j'ai un pb, j'aimerais savoir lequel pour savoir comment je peux agir dessus (création/suppression d'un fichier, modifs de droits, etc...). Je veux pas avoir à me logger en SSH sur le serveur pour aller parser les logs pour trouver la stack.

Oui d'une part, mais aussi je vais avoir des pbs de compil si jamais mon interface déclare un throws DBConnectionException et que mon implé ne la renvoie pas (ex : implé du storage fichier plat)
Donc non, c'est évidemment pas une solution non plus, d'où ma question de base en fait

 
Je pense pas que t'ai besoin de faire de l'instanceof. Quand tu obtiens ton InterfaceStorage, tu sais ce que t'as demandé (flatfile, bdd, etc), donc si ça merde, tu sais déjà si c'est un fichier plat, la BDD ou autre. Après, faut abstraire, tu peux avoir quoi comme problèmes:
- un problème d'authentification
- un problème de droits (pas les droits sur le fichier, pas les droits pour faire l'opération en BDD)
- un problème d'IO (connexion qui foire, fichier illisible)
- un problème de source absente (serveur de fichier/filesystem pas là, serveur de BDD down)
- un problème de données absentes (fichier pas là, rien en base)
- un problème de données invalides
 
Ça te fait te palucher quelques exceptions, mais tu peux toujours grouper si t'as pas envie de gérer plus fin.
Quand au message d'erreur pour l'utilisateur, tu t'en fous, il sera fourni par l'exception sous-jacente sur laquelle tu as la main au plus bas niveau.

public interface NewInterface {
 
    void save() throws IOException;
}

public class NewClass implements NewInterface{
 
    /**
     *
     * @throws java.io.IOException :
     */
    public void save() throws IOException {
        System.out.println("salut" );
    }
 
 
}

ça compile très bien.

Après, moi j'encapsulerais peut être le DBException lié à ton implémentation à une autre exception plus en rapport avec l'interface, histoire de ne pas avoir un couplage.(Après, FileNotFound, c'est un peu un standard quoi, alors l'encapsuler...)

Ba non justement, c'est l'intérêt de passer par une factory, c'est que tu te fous de l'implé. Si je dois mater la conf pour savoir ce que veut le user directement dans mon code appelant, autant instancier direct les implés et foutre la factory à la benne

Oui, j'avais pensé à grouper mais spareil, je trouvais pas ça très malin. A bien y regarder, c'est p'têt ce qu'il y a de moins con

Possible, j'ai pas regardé, j'avais le souvenir que le compilo grognait, donc p'têt c'est juste un warning dans mon Eclipse Chu un peu casse-couille avec les warnings, j'aime pas en avoir.

Voilà, comme dit ci-dessus. J'pense je vais partir là-dessus si j'ai pas plus d'inspiration pendant le déjeuner

Merci bien les gros