1 - Moi, je ne lis pas un CD audio avec konqueror : c'est pas fait pour ça ! Utilise plutôt KsCD par exemple. Pour information, la structure d'un CD audio n'est pas la même que celle d'un CD-Rom ...
2 - A mon avis (sauf problème matériel), le disque dur est bien détecté mais il n'a aucune partition montée ! Donc tu dois monter la partition en utilisant le device correspondant. ex: (en supposant que ton 2ème disque soit maître sur le second port ide et qu'il n'y ait qu'une partition prenant tout le disque et en fat32)
mount -t vfat /dev/hdc1 /mnt/outuveux
ou sinon, tu peux utiliser diskdrake (interface graphique)
1 - Moi, je ne lis pas un CD audio avec konqueror : c'est pas fait pour ça ! Utilise plutôt KsCD par exemple. Pour information, la structure d'un CD audio n'est pas la même que celle d'un CD-Rom ...
2 - A mon avis (sauf problème matériel), le disque dur est bien détecté mais il n'a aucune partition montée ! Donc tu dois monter la partition en utilisant le device correspondant. ex: (en supposant que ton 2ème disque soit maître sur le second port ide et qu'il n'y ait qu'une partition prenant tout le disque et en fat32)
mount -t vfat /dev/hdc1 /mnt/outuveux
ou sinon, tu peux utiliser diskdrake (interface graphique)
Je suis d'accord avec toi lorsque tu dis que certains (trop ?) passent plus volontiers par le journal que par les news pour éviter une modération qui réclame plus d'efforts de structuration, de contenu, de grammaire et de recherche.
Cependant, je crois aussi que les modéros y sont pour quelquechose : Ceci est un message automatique.
Ton journal est peut-être plus adapté pour passer cette information.
Cependant, nous tenons à te remercier de l'avoir proposée, et
t'encourageons à en proposer d'autres.
En recevant ce genre de réponse lorsqu'on poste une news, je ne crois pas qu'on motive les contributeurs.Je suis d'accord pour me faire "jeter" mais pas de manière aussi lapidaire !
S'il n'y a réellement que 2 à 5 news par jour, pourquoi être à ce point avare de commentaires !
A mon sens, il faudrait au moins préciser ce qui cloche lorsqu'une news est refusée (même si cela a déjà été dit auparavant) ; pour cela quelques indicateurs clés suffisent :
- trop confus,
- trop de fautes,
- trop général,
- pas assez / mal documenté
...
Malgré tout, il y a du bon boulot de fait ... donc courage pour la suite
A mon avis, tu ne vas pas aimer ma suggestion (pour changer ;-))
Le nombre de propriétés que tu gères est à priori sujet à des changements. Je suppose donc que certaines infos sont liées entre-elles et d'autres pas i.e, par exemple, une propriété 'license' ne dépend par d'une autre contrairement à envoi et destinaire.
Il est clair que la BD ne va pas deviner toute seule s'il y a un lien ou non. Pour faire ce lien explicite sans qu'il y ait lieu de multiplier les tables et les relations ... il faudrait multiplier les vues qui seraient donc chargées de dispatcher les informations dans la table (à l'aide d'une règle visiblement).
Je ne comprends pas ce que tu veux dire par "le problème des liens entre champs info reste".
Tu pourrais donner un exemple concret stp !
(ce n'est peut-être qu'une impression mais tes "liaisons' n'auraient-elles pas un rapport avec les clés étrangères ou avec les jointures ?)
Tu dis en gros que tu as un nombre de propriétés inconnues au départ et que tu rajoutes au fur et à mesure des besoins.
(je sais ... faut expliquer longtemps pour que je comprenne vite ...)
Je sens que tu ne vas pas aimer ma nouvelle idée :
1) créer une table des propriétés avec identifiant et nom de la propriété
2) table info(id, image, propriété, valeur)
Si tu as 200 infos sur une image, tu as 200 enregistrements dans la table info pour cette image.
L'inconvénient est que tu dois alors avoir un champ valeur fourre-tout : par exemple placer lieu, traitement et date indifférement dans un champ texte.
Pour les traitements, il faudrait alors vraisemblablement introduire un champ supplémentaire permettant de supposer le type du contenu du champ fourre-tout afin d'automatiser autant que possible.
Moi, je rajouterais le lieu de prise, le traitement et la date plutôt dans la table image (s'il y a 25 individus sur une photos, tous ont été photographiés au même endroit au même moment non ?).
Cela dit, c'est peut-être ma dénommination tes tables qui ne te semble pas claire, je recommence :
PHOTO : id, fichier, chemin, lieu, traitement, date
INDIVIDU : id, nom, prenom, email
PRESENT : image, individu
HISTORIQUE : id, image, individu, date_envoi
Il ne me semble pas qu'il faille systématiquement ajouter une table pour ça.
Au fait, pourquoi tiens-tu absolument à éviter la création de nouvelles tables ?
Comme dit plus haut, il semble que tu as adopté la technique du 'je fonce dans le tas !'.
Tu peux arriver à tes fins de cette manière ... avec énormément de chance !
Ca peux suffire un temps mais si après (dans 1 jour, 2 jours ou 3 ans) tu décides d'ajouter de nouvelles caractéristiques : là tu vas en baver à mort.
Ma première interrogation est ta table IMAGE qui ne contient qu'un champ. Je n'en ai jamais trouvé l'utilité, ça veut dire qu'il faut regrouper avec quelquechose d'autre.
Ce que je ferais (simple suggestion simpliste) par exemple, c'est (en supposant que j'ai compris)
IMAGE : id, fichier, chemin
INDIVIDU : id, nom, prenom, email
PHOTO : image, individu
HISTORIQUE : id, image, individu, date_envoi
Explications :
Une image est définie par un identifiant, le nom de fichier et le chemin.
Un individu est défini par un identifiant, ses nom, prenom et email
Une photo présente un couple image individus (sur une image peuvent figurer plusieurs individus et un individu peut figurer sur plusieurs images)
L'historique indique quelle image a été envoyée quand à quel individu.
Les requêtes devraient être déjà plus catholiques avec ce schéma :)
@++
P.S : Ce ne sont que des pistes i.e ne pas prendre ça pour code comptant.
Je ne conteste pas que les conflits relatifs aux brevets soient du pain beni pour les cabinets de juriste mais si les grandes entreprises sont amenées à se battre si âprement, c'est bien que l'une d'elle compte bien gagner ... un jour !
Ce qui fait éterniser de tels conflits, c'est que ces grandes entreprises ne sont pas si vulnérables que cela :
1) elles ont toutes un nombre gigantesque de brevets (c'est partiellement là-dessus qu'est déterminée leur valeur boursière),
2) les domaines d'activités sont relativement variés (hard, soft, service ) et la rentabilité pour chacune est de mise (sauf investissement à long terme)
3) la complexité des dossiers relatifs à de tels litiges (milliers voire dizaines de milliers de pages) et la lenteur du système judiciaire (ou l'intêret que l'une ou les entreprises ont à ce que le dossier traîne).
Cependant, je pense que technologiquement, l'avantage est au libre. En effet, Microsoft bosse de manière autonome : elle envisage une technologie est la développe en interne (en laissant de côté certains repompages abusifs ...) pour la vendre ensuite. Un nouveau client, c'est du pognon frais.
Pour le libre, un nouvel utilisateur correspondrait à peu près à un client. Par contre, une autre boîte peut accéder au soft, le faire évoluer et cela, autant de fois qu'il y a de participants : une inertie s'installe lentement et l'on bénéficie rapidement d'une vrai dynamique de groupe.
Tant que Microsoft ne comprendra pas qu'il faut trouver un système générant une telle dynamique (quitte à partager/diminuer ses marges et réduire son ascendant sur ses produits), cette entreprise aura de plus en plus de mal à lutter.
Ce titre un peu étrange vient d'un constat : les grandes entreprises de l'informatique (de petites aussi) ont constitué un stock phénoménal de brevets devant servir à leur défense au cas où (évidemment !) !
Les attaques frontales entre deux ténors sont plutôt rares (Sun-Microsoft) et Microsoft puisqu'il s'agit d'eux ici n'a jamais osé s'en prendre à plusieurs morçeaux à la fois, en évitant autant que possible de contrarier ses partenaires historiques !
S'il passent effectivement à l'offensive sur la question des brevets et que IBM (par ex) se trouve, dans la foulée, attaquée, je pense que les tensions commerciales vont se faire plus rudes.
On peut voir déjà (à mon avis) que l'attaque groupée faite par SCO est très difficile à défendre et réclame des reins (financiers et juridiques) en béton armé ; ce qui est le cas de Microsoft. Cependant, il me paraît invraisemblable qu'un juge puisse exiger (soyons fous !) le retrait de Linux du marché ! Tout au plus pourrait-on assister à la suspension d'une distribution ou d'un logiciel le temps de régler un contentieux (long ?).
C'est qu'intervient la force du libre : si un acteur du monde Linux est paralysé, une(des) alternative(s) peut instantanément prendre le relais sans pour autant bouleverser les systèmes d'informations.
Le tout est de savoir si la firme de Redmond aura l'arrogance de toucher à un élément qui fâche et qui touche de très nombreux acteurs à la fois ! On assisterait alors à une guerre ouverte qui mettrait IBM et Microsoft dans des situations assez paradoxales :
d'un côté IBM qui propulse Linux et vend aussi des machines de bureaux, serveurs et services sous Windows et attaqué par Microsoft ;
de l'autre, on aurait Microsoft qui aurait le choix entre forcer IBM à payer plus cher ses systèmes Windows ... au risque qu'ils mettent ostensiblement Linux en avant sur ces mêmes segments de marché autrefois réservés à Windows !
Mais je ne suis pas devin ! D'ici là, du code va passer sous les Ventirad i.e le temps joue pour nous (je veux tout simplement dire que si avant cette supposée guerre ouverte Linux atteint (par exemple) 15% de parts de marché, il sera très difficile de le l'ératiquer de la surface des disques durs).
Je termine en disant que Microsoft semble sentir clairement que Linux a le vent en poupe et qu'il faut tout faire pour qu'il n'atteigne pas (jamais) sa masse critique afin de garder leur part de marché outrageante et les marges qui vont avec.
Je ne sais pas si ta carte (ou plutôt sa puce graphique) est supportée ... à priori oui (mais pour les driver nvidia, il peut en falloir de plus récents que sur la 10.0 !).
Si ta machine n'a pas planté (l'installation est supposée terminée) , retourne en mode console (Ctrl+Alt+F1 pour la première), logues toi en root pour vérifie tester 2 choses :
Si c'est juste un problème de configuration, regarde dans le fichier log ce qui a généré les éventuelles erreurs : fichier /var/log/XFree86.0.log ... à l'aide de la commande 'less XFree86.0.log' par exemple. Si dedans, tu ne trouve aucune occurence à un chipset nv ou nvidia, il y a un malaise et il faut donc esayer l'un ou l'autre !
Si les drivers sont propriétaires et qu'ils ne reconnaissent pas la carte, essaie la version libre : en remplaçant Driver "nvidia" par Driver "nv". Ce paramètre se trouve dans le fichier /etc/X11/XF86Config-4 dans une 'Section Device'. Puis relance le serveur X ; là ça dépend du programme utilisé (xdm, mdkxdm ... pour faire simple, redémarre ;-))
Si j'ai pu t'aider, c'est bien ; dans le cas contraire, il n'est pus rien que je puisse faire !
Cela dit, je ne prétens aucunement maîtriser postgres et au cours de ces sporadiques échanges, tu dois maintenant en connaître à peu près autant que moi ... donc pour les cours, il faudrait d'abord que je me fasse une greffe de cerveau et que ça prenne évidemment !!
Bon, c'est pas encore clair dans ma tête, mais ça pourraît donner matière à réfléchir.
je suppose que ta table, que je nomme période, comporte les colonnes id, userid, debut, fin et param.
Déterminer si des périodes se suivent est assez simple : il suffit de faire un produit ensembliste restrictif portant sur userdid et param.
D'où naturellement la requête suivante :
SELECT p1.id, p1.fin, p2.debut, date_mi( p1.fin, p2.debut)+1 AS intervalle
FROM periode AS p1, periode AS p2
WHERE p1.userid=1 AND p1.param=p2.param AND p1.fin<p2.debut
ORDER BY intervalle DESC;
N.B1 : la restriction p1.fin<p2.debut permet de ne pas sélectionner tous les résultats possibles (pas intéressants).
N.B2 : les intervalles qui se suivent directement sont repérables par le 0 pour la colonne intervalle dans la requête ci-dessus.
N.B3 : avec la jointure sur un index (supposé) de id et malgré le produit ensembliste, cela ne devrait pas être trop couteux en performances ; je doute que chaque utilisateur en arrive à 365 entrées par exemple !
A priori, il ne resterait donc plus qu'à incorporer cette requête dans un trigger pour que ça fasse l'affaire !
Bon courage. Si j'ai dispersé inutilement tes efforts, désolé !
Tout d'abord, ta définition de jour ouvrable semble exclure les jours fériés ... mais passons, c'est pas le sujet.
Ensuite, obtenir le résultat sans passer par une fonction (juste une requête donc) me paraît un peu illusoire (mais je ne maîtrise pas postgres à fond non plus !).
Cependant, je me permets de critiquer ta fonction du fait qu'elle est très coûteuse en temps avec des intervalles longs, si en plus on l'applique à de nombreux enregistrements ...
Ma proposition est donc un truc du style suivant (j'ai laissé les raise notice de débogage à tout hazard) ; ce qui donne (ça va faire mal !) :
CREATE FUNCTION nbJoursOuvrables(DATE, DATE) RETURNS INTEGER AS'
DECLARE
debut ALIAS FOR $1;
fin ALIAS FOR $2;
debut_d DATE;
fin_d DATE;
debut_j INTEGER;
fin_j INTEGER;
periode INTEGER;
nb INTEGER;
BEGIN
debut_j := to_char( debut , ''D'' )::INTEGER;
IF debut_j <> 2 THEN
debut_d := date_mii( debut, 7-debut_j+3 ); -- lundi prédécent
ELSE
debut_d := debut; -- lundi courant
END IF;
RAISE NOTICE ''debut_j = %, debut_d = %'', debut_j, debut_d;
fin_j := to_char( fin, ''D'')::INTEGER;
IF fin_j <> 1 THEN
fin_d := date_mii( fin, fin_j-7-1 );
ELSE
fin_d := fin;
END IF;
RAISE NOTICE ''fin_j = %, fin_d = %'', fin_j, fin_d;
periode = date_mi( fin_d, debut_d )+1;
RAISE NOTICE ''periode = %'', periode;
nb := periode - periode / 7 * 2; -- nb jours sans sam/dim
RAISE NOTICE ''periode - s/m = %'', nb;
IF date_mi( fin_d, debut_d )>7 THEN
IF fin_j <> 7 THEN
nb := nb - (debut_j-1) -(7-fin_j-2 );
ELSE
nb := nb - (debut_j-1) -(7-fin_j-1);
END IF;
ELSE
nb := nb - debut_j + 2;
END IF;
RETURN nb;
END;'
LANGUAGE 'plpgsql';
Le principe de la fonction consiste à repérer les dates limites (lundi, dimanche usuels) englobant au mieux les dates données. On obtient donc un nombre de semaines entières qu'il suffit de diviser par 7 et multiplier par 2 pour obtenir le nombre de samedis/dimaches de cette période. Enfin, il faut ajuster suivant la position du dernier jour i.e un samedi déjà compté ou non.
La fonction testée sommairement à l'air vachement balèse mais c'est beaucoup plus léger que de boucler sur les jours à mon avis surtout si les dates sont très espacées ...
A++
P.S : C'est pas toi qui recherchait comment déterminer si deux périodes se chevauchent ? ... je viens de remarquer que PostgreSQL a justement une fonction overlaps(date, date, date, date) ... à bon codeur ...
Pour renvoyer une erreur lorsque des périodes se chevauchent, il faut à mon avis procéder en deux étapes : d'abord une fonction indiquant si deux périodes se chevauchent et ensuite un trigger appelant cette fonction pour déterminer s'il y a erreur ou non.
Par exemple, une fonction
CREATE FUNCTION areExclusivePeriods( DATE, DATE, DATE, DATE)
RETURNS boolean AS'
DECLARE
debut1 ALIAS FOR $1;
fin1 ALIAS FOR $2;
debut2 ALIAS FOR $3;
fin2 ALIAS FOR $4;
BEGIN
IF (debut1>fin1) OR (debut2>fin2) THEN
RAISE EXCEPTION ''Périodes mal délimitées (début de période ne précède pas la fin) !'';
END IF;
IF (debut2<debut1 AND fin2<debut1) OR (debut2>fin1 AND fin2>fin1) THEN
RETURN ''t'';
ELSE
RETURN ''f'';
END IF;
END;
' LANGUAGE 'plpgsql';
Cette fonction renvoie 't' lorsque les périodes sont exclusives et 'f' sinon.
puis une deuxième fonction sollicitée par le trigger ; par exemple :
CREATE FUNCTION blabla_insert() RETURNS TRIGGER AS'
DECLARE
rec RECORD;
BEGIN
SELECT INTO rec * FROM blabla WHERE areExclusivePeriods( dat_deb, dat_fin, NEW.dat_deb, NEW.dat_fin )=''f'';
IF FOUND THEN
RAISE EXCEPTION ''Conflit entre les périodes du % au % et du % au %'', rec.dat_deb, rec.dat_fin, NEW.date_deb, NEW.date_fin;
ELSE
RETURN NEW;
END;
END;'
LANGUAGE 'plpgsql';
Enfin le trigger à proprement parler :
CREATE TRIGGER trg_blabla_insert BEFORE INSERT OR UPDATE ON blabla FOR EACH ROW EXECUTE PROCEDURE blabla_insert();
En espérant ne pas être trop à côté de la plaque ...
P.S : découper les périodes si chevauchement il y a devrait être possible, mais je ne l'ai jamais fait ...
En clair c'est jouable à mon avis ! (je vais pas tout faire à ta place non plus !)
Il me semble que i2c (-core et -dev) ne sont que des interfaces pour les modules, mais il faut aussi charger ces modules i.e, dans ton cas, ajouter un petit aussi
modprobe w83781d
ensuite, executer sensors devrait l'affaire.
Tu pourrais aussi exécuter le démon associé par la commande /etc/init.d/lm_sensors start (peut dépendre de la distrib) avant de lancer la commande sensors (mais il faut qu'il n'y ait pas de malaise dans la configuration, sinon ça foire !
Après quelques recherches, il me semble que MySQL ne gère les procédures stockées qu'à partir de la version 5.0 ... qui n'est pas encore finalisée. Quid de sont adoption rapide par les hébergeur à sa sortie ?
Pourquoi tu me causes de binaire ?
Parce qu'il faut une 'extension' pour gérer des fonctions côté serveur ? alors qu'à mon sens ça devrait faire partie de la base !
Ce n'e sont que des questions innocentes ! Pour ma part, je n'utilise que sur mon propre réseau local ... l'admin est moins vache ;-)
Ce que je ferais dans ton cas, c'est d'abord un fonction sur le serveur/sgbd, et ensuite appeler cette fonction dans une requête ou à travers une vue.
Cela dit, tu aurais pu préciser au moins le SGBD employé (divers languages sont possibles pour certains). J'ai déjà fait des fonctions sql et plpgsql avec PostgreSQL par exemple ...
Tu fais donc un truc du style :
CREATE FUNCTION format_identifiant( TEXT, TEXT ) RETURNS TEXT AS ...;
puis
SELECT format_identifiant( nom, prenom) as identifiant FROM table ...;
Mon conseil, c'est d'éviter de faire les remplacements au niveau du client : si tu changes de language, tu dois tout refaire tout sinon !
Si j'ai bien tout capté, en changeant
le connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(valueChanged(int)));
par
connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(addlite(int)));
puis en ajoutant un simple tempo->show() dans le slot addlite(int), cela devrait suffire :
par exemple, on pourrait avoir
void Paramligts::addlite( int newValue )
{
QLabel* tempo = new QLabel( "", GBLights );
tempo->setText( QString( "N°%1").arg( newValue) );
tempo->show();
}
cela, pour afficher des label N°1, N°2 ... N°10
Si show() est omis, le QLabel est créé, mais pas affiché puisque à priori, la fenêtre est arrangée (layout, positions ...) au premier affichage, les modifications doivent être absolument explicites.
A mon humble avis, il te faut une carte graphique qui ait deux sorties (en dehors de la sortie télé, sauf si tu en as un quelconque intérêt évidemment) ; 2VGA ou 1VGA,1DVI ou 2DVI.
A priori, la 9200 est capable de gérer deux écrans mais si le fabricant de la carte n'a jugé bon de de cabler qu'une seule sortie, ça veut dire qu'il n'y a pas moyen d'en rajouter !
Mon opinion est donc qu'il s'agit vraisemblablement d'une Radeon9200 et qu'il te faut effectivement une autre carte (PCI en complément) ou changer l'actuelle pour une proposant le double écran (faire gaffe au(x) adaptateur(s) pas toujours fourni(s)!
C'est tout ce que mon neurone a bien voulu que mon clavier envoie à l'écran à ce sujet ! ;-)
# mon centime d'euro
Posté par idiotduvillage . En réponse au message pb de lecture de cd audio sur mandrake 10.0 help!. Évalué à 2.
2 - A mon avis (sauf problème matériel), le disque dur est bien détecté mais il n'a aucune partition montée ! Donc tu dois monter la partition en utilisant le device correspondant. ex: (en supposant que ton 2ème disque soit maître sur le second port ide et qu'il n'y ait qu'une partition prenant tout le disque et en fat32)
mount -t vfat /dev/hdc1 /mnt/outuveux
ou sinon, tu peux utiliser diskdrake (interface graphique)
# mon centime d'euro
Posté par idiotduvillage . En réponse au message pb de lecture de cd audio sur mandrake 10.0 help!. Évalué à 3.
2 - A mon avis (sauf problème matériel), le disque dur est bien détecté mais il n'a aucune partition montée ! Donc tu dois monter la partition en utilisant le device correspondant. ex: (en supposant que ton 2ème disque soit maître sur le second port ide et qu'il n'y ait qu'une partition prenant tout le disque et en fat32)
mount -t vfat /dev/hdc1 /mnt/outuveux
ou sinon, tu peux utiliser diskdrake (interface graphique)
[^] # Re: moins de news ? Plus de journaux ?
Posté par idiotduvillage . En réponse au journal Fréquence de news sur linuxfr.... Évalué à 3.
Cependant, je crois aussi que les modéros y sont pour quelquechose :
Ceci est un message automatique.
Ton journal est peut-être plus adapté pour passer cette information.
Cependant, nous tenons à te remercier de l'avoir proposée, et
t'encourageons à en proposer d'autres.
En recevant ce genre de réponse lorsqu'on poste une news, je ne crois pas qu'on motive les contributeurs.Je suis d'accord pour me faire "jeter" mais pas de manière aussi lapidaire !
S'il n'y a réellement que 2 à 5 news par jour, pourquoi être à ce point avare de commentaires !
A mon sens, il faudrait au moins préciser ce qui cloche lorsqu'une news est refusée (même si cela a déjà été dit auparavant) ; pour cela quelques indicateurs clés suffisent :
- trop confus,
- trop de fautes,
- trop général,
- pas assez / mal documenté
...
Malgré tout, il y a du bon boulot de fait ... donc courage pour la suite
[^] # Ultime suggestion
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 2.
A mon avis, tu ne vas pas aimer ma suggestion (pour changer ;-))
Le nombre de propriétés que tu gères est à priori sujet à des changements. Je suppose donc que certaines infos sont liées entre-elles et d'autres pas i.e, par exemple, une propriété 'license' ne dépend par d'une autre contrairement à envoi et destinaire.
Il est clair que la BD ne va pas deviner toute seule s'il y a un lien ou non. Pour faire ce lien explicite sans qu'il y ait lieu de multiplier les tables et les relations ... il faudrait multiplier les vues qui seraient donc chargées de dispatcher les informations dans la table (à l'aide d'une règle visiblement).
Toujours pas satisfait, je m'en doute ...
[^] # Alors là ?
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 2.
Tu pourrais donner un exemple concret stp !
(ce n'est peut-être qu'une impression mais tes "liaisons' n'auraient-elles pas un rapport avec les clés étrangères ou avec les jointures ?)
[^] # J'y vois peut-être un peu plus clair ...
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 3.
(je sais ... faut expliquer longtemps pour que je comprenne vite ...)
Je sens que tu ne vas pas aimer ma nouvelle idée :
1) créer une table des propriétés avec identifiant et nom de la propriété
2) table info(id, image, propriété, valeur)
Si tu as 200 infos sur une image, tu as 200 enregistrements dans la table info pour cette image.
L'inconvénient est que tu dois alors avoir un champ valeur fourre-tout : par exemple placer lieu, traitement et date indifférement dans un champ texte.
Pour les traitements, il faudrait alors vraisemblablement introduire un champ supplémentaire permettant de supposer le type du contenu du champ fourre-tout afin d'automatiser autant que possible.
J'ai compris cette fois ?
# autre test
Posté par idiotduvillage . En réponse au journal Benchmarks de processeurs sous GNU/Linux. Évalué à 5.
http://www.linuxhardware.org/article.pl?sid=04/09/17/1453239&mo(...)
[^] # Re: Modéliser ... toujours modéliser
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
Cela dit, c'est peut-être ma dénommination tes tables qui ne te semble pas claire, je recommence :
PHOTO : id, fichier, chemin, lieu, traitement, date
INDIVIDU : id, nom, prenom, email
PRESENT : image, individu
HISTORIQUE : id, image, individu, date_envoi
Il ne me semble pas qu'il faille systématiquement ajouter une table pour ça.
Au fait, pourquoi tiens-tu absolument à éviter la création de nouvelles tables ?
[^] # Re: Modéliser ... toutjours modéliser
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
# Modéliser ... toutjours modéliser
Posté par idiotduvillage . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
Tu peux arriver à tes fins de cette manière ... avec énormément de chance !
Ca peux suffire un temps mais si après (dans 1 jour, 2 jours ou 3 ans) tu décides d'ajouter de nouvelles caractéristiques : là tu vas en baver à mort.
Ma première interrogation est ta table IMAGE qui ne contient qu'un champ. Je n'en ai jamais trouvé l'utilité, ça veut dire qu'il faut regrouper avec quelquechose d'autre.
Ce que je ferais (simple suggestion simpliste) par exemple, c'est (en supposant que j'ai compris)
IMAGE : id, fichier, chemin
INDIVIDU : id, nom, prenom, email
PHOTO : image, individu
HISTORIQUE : id, image, individu, date_envoi
Explications :
Une image est définie par un identifiant, le nom de fichier et le chemin.
Un individu est défini par un identifiant, ses nom, prenom et email
Une photo présente un couple image individus (sur une image peuvent figurer plusieurs individus et un individu peut figurer sur plusieurs images)
L'historique indique quelle image a été envoyée quand à quel individu.
Les requêtes devraient être déjà plus catholiques avec ce schéma :)
@++
P.S : Ce ne sont que des pistes i.e ne pas prendre ça pour code comptant.
[^] # Le temps joue pour le logiciel libre
Posté par idiotduvillage . En réponse à la dépêche Microsoft face aux logiciels libres. Évalué à 3.
Ce qui fait éterniser de tels conflits, c'est que ces grandes entreprises ne sont pas si vulnérables que cela :
1) elles ont toutes un nombre gigantesque de brevets (c'est partiellement là-dessus qu'est déterminée leur valeur boursière),
2) les domaines d'activités sont relativement variés (hard, soft, service ) et la rentabilité pour chacune est de mise (sauf investissement à long terme)
3) la complexité des dossiers relatifs à de tels litiges (milliers voire dizaines de milliers de pages) et la lenteur du système judiciaire (ou l'intêret que l'une ou les entreprises ont à ce que le dossier traîne).
Cependant, je pense que technologiquement, l'avantage est au libre. En effet, Microsoft bosse de manière autonome : elle envisage une technologie est la développe en interne (en laissant de côté certains repompages abusifs ...) pour la vendre ensuite. Un nouveau client, c'est du pognon frais.
Pour le libre, un nouvel utilisateur correspondrait à peu près à un client. Par contre, une autre boîte peut accéder au soft, le faire évoluer et cela, autant de fois qu'il y a de participants : une inertie s'installe lentement et l'on bénéficie rapidement d'une vrai dynamique de groupe.
Tant que Microsoft ne comprendra pas qu'il faut trouver un système générant une telle dynamique (quitte à partager/diminuer ses marges et réduire son ascendant sur ses produits), cette entreprise aura de plus en plus de mal à lutter.
# La guerre froide se termine ?
Posté par idiotduvillage . En réponse à la dépêche Microsoft face aux logiciels libres. Évalué à 10.
Les attaques frontales entre deux ténors sont plutôt rares (Sun-Microsoft) et Microsoft puisqu'il s'agit d'eux ici n'a jamais osé s'en prendre à plusieurs morçeaux à la fois, en évitant autant que possible de contrarier ses partenaires historiques !
S'il passent effectivement à l'offensive sur la question des brevets et que IBM (par ex) se trouve, dans la foulée, attaquée, je pense que les tensions commerciales vont se faire plus rudes.
On peut voir déjà (à mon avis) que l'attaque groupée faite par SCO est très difficile à défendre et réclame des reins (financiers et juridiques) en béton armé ; ce qui est le cas de Microsoft. Cependant, il me paraît invraisemblable qu'un juge puisse exiger (soyons fous !) le retrait de Linux du marché ! Tout au plus pourrait-on assister à la suspension d'une distribution ou d'un logiciel le temps de régler un contentieux (long ?).
C'est qu'intervient la force du libre : si un acteur du monde Linux est paralysé, une(des) alternative(s) peut instantanément prendre le relais sans pour autant bouleverser les systèmes d'informations.
Le tout est de savoir si la firme de Redmond aura l'arrogance de toucher à un élément qui fâche et qui touche de très nombreux acteurs à la fois ! On assisterait alors à une guerre ouverte qui mettrait IBM et Microsoft dans des situations assez paradoxales :
d'un côté IBM qui propulse Linux et vend aussi des machines de bureaux, serveurs et services sous Windows et attaqué par Microsoft ;
de l'autre, on aurait Microsoft qui aurait le choix entre forcer IBM à payer plus cher ses systèmes Windows ... au risque qu'ils mettent ostensiblement Linux en avant sur ces mêmes segments de marché autrefois réservés à Windows !
Mais je ne suis pas devin ! D'ici là, du code va passer sous les Ventirad i.e le temps joue pour nous (je veux tout simplement dire que si avant cette supposée guerre ouverte Linux atteint (par exemple) 15% de parts de marché, il sera très difficile de le l'ératiquer de la surface des disques durs).
Je termine en disant que Microsoft semble sentir clairement que Linux a le vent en poupe et qu'il faut tout faire pour qu'il n'atteigne pas (jamais) sa masse critique afin de garder leur part de marché outrageante et les marges qui vont avec.
# quelques pistes ...
Posté par idiotduvillage . En réponse au message PB mandrake 10.0 é carte graphique geforce 5500FX. Évalué à 1.
Je ne sais pas si ta carte (ou plutôt sa puce graphique) est supportée ... à priori oui (mais pour les driver nvidia, il peut en falloir de plus récents que sur la 10.0 !).
Si ta machine n'a pas planté (l'installation est supposée terminée) , retourne en mode console (Ctrl+Alt+F1 pour la première), logues toi en root pour vérifie tester 2 choses :
Si c'est juste un problème de configuration, regarde dans le fichier log ce qui a généré les éventuelles erreurs : fichier /var/log/XFree86.0.log ... à l'aide de la commande 'less XFree86.0.log' par exemple. Si dedans, tu ne trouve aucune occurence à un chipset nv ou nvidia, il y a un malaise et il faut donc esayer l'un ou l'autre !
Si les drivers sont propriétaires et qu'ils ne reconnaissent pas la carte, essaie la version libre : en remplaçant Driver "nvidia" par Driver "nv". Ce paramètre se trouve dans le fichier /etc/X11/XF86Config-4 dans une 'Section Device'. Puis relance le serveur X ; là ça dépend du programme utilisé (xdm, mdkxdm ... pour faire simple, redémarre ;-))
Après il se peut que ça tombe en marche !
[^] # Re: peut-être une piste (autre)
Posté par idiotduvillage . En réponse au message SQL toujours : requête sur une non-table..... Évalué à 1.
Cela dit, je ne prétens aucunement maîtriser postgres et au cours de ces sporadiques échanges, tu dois maintenant en connaître à peu près autant que moi ... donc pour les cours, il faudrait d'abord que je me fasse une greffe de cerveau et que ça prenne évidemment !!
[^] # Re: peut-être une piste (autre)
Posté par idiotduvillage . En réponse au message SQL toujours : requête sur une non-table..... Évalué à 1.
je suppose que ta table, que je nomme période, comporte les colonnes id, userid, debut, fin et param.
Déterminer si des périodes se suivent est assez simple : il suffit de faire un produit ensembliste restrictif portant sur userdid et param.
D'où naturellement la requête suivante :
SELECT p1.id, p1.fin, p2.debut, date_mi( p1.fin, p2.debut)+1 AS intervalle
FROM periode AS p1, periode AS p2
WHERE p1.userid=1 AND p1.param=p2.param AND p1.fin<p2.debut
ORDER BY intervalle DESC;
N.B1 : la restriction p1.fin<p2.debut permet de ne pas sélectionner tous les résultats possibles (pas intéressants).
N.B2 : les intervalles qui se suivent directement sont repérables par le 0 pour la colonne intervalle dans la requête ci-dessus.
N.B3 : avec la jointure sur un index (supposé) de id et malgré le produit ensembliste, cela ne devrait pas être trop couteux en performances ; je doute que chaque utilisateur en arrive à 365 entrées par exemple !
A priori, il ne resterait donc plus qu'à incorporer cette requête dans un trigger pour que ça fasse l'affaire !
Bon courage. Si j'ai dispersé inutilement tes efforts, désolé !
# peut-être une piste
Posté par idiotduvillage . En réponse au message SQL toujours : requête sur une non-table..... Évalué à 3.
Ensuite, obtenir le résultat sans passer par une fonction (juste une requête donc) me paraît un peu illusoire (mais je ne maîtrise pas postgres à fond non plus !).
Cependant, je me permets de critiquer ta fonction du fait qu'elle est très coûteuse en temps avec des intervalles longs, si en plus on l'applique à de nombreux enregistrements ...
Ma proposition est donc un truc du style suivant (j'ai laissé les raise notice de débogage à tout hazard) ; ce qui donne (ça va faire mal !) :
CREATE FUNCTION nbJoursOuvrables(DATE, DATE) RETURNS INTEGER AS'
DECLARE
debut ALIAS FOR $1;
fin ALIAS FOR $2;
debut_d DATE;
fin_d DATE;
debut_j INTEGER;
fin_j INTEGER;
periode INTEGER;
nb INTEGER;
BEGIN
debut_j := to_char( debut , ''D'' )::INTEGER;
IF debut_j <> 2 THEN
debut_d := date_mii( debut, 7-debut_j+3 ); -- lundi prédécent
ELSE
debut_d := debut; -- lundi courant
END IF;
RAISE NOTICE ''debut_j = %, debut_d = %'', debut_j, debut_d;
fin_j := to_char( fin, ''D'')::INTEGER;
IF fin_j <> 1 THEN
fin_d := date_mii( fin, fin_j-7-1 );
ELSE
fin_d := fin;
END IF;
RAISE NOTICE ''fin_j = %, fin_d = %'', fin_j, fin_d;
periode = date_mi( fin_d, debut_d )+1;
RAISE NOTICE ''periode = %'', periode;
nb := periode - periode / 7 * 2; -- nb jours sans sam/dim
RAISE NOTICE ''periode - s/m = %'', nb;
IF date_mi( fin_d, debut_d )>7 THEN
IF fin_j <> 7 THEN
nb := nb - (debut_j-1) -(7-fin_j-2 );
ELSE
nb := nb - (debut_j-1) -(7-fin_j-1);
END IF;
ELSE
nb := nb - debut_j + 2;
END IF;
RETURN nb;
END;'
LANGUAGE 'plpgsql';
Le principe de la fonction consiste à repérer les dates limites (lundi, dimanche usuels) englobant au mieux les dates données. On obtient donc un nombre de semaines entières qu'il suffit de diviser par 7 et multiplier par 2 pour obtenir le nombre de samedis/dimaches de cette période. Enfin, il faut ajuster suivant la position du dernier jour i.e un samedi déjà compté ou non.
La fonction testée sommairement à l'air vachement balèse mais c'est beaucoup plus léger que de boucler sur les jours à mon avis surtout si les dates sont très espacées ...
A++
P.S : C'est pas toi qui recherchait comment déterminer si deux périodes se chevauchent ? ... je viens de remarquer que PostgreSQL a justement une fonction overlaps(date, date, date, date) ... à bon codeur ...
# pour renvoyer une erreur
Posté par idiotduvillage . En réponse au message Soucis de SQL..... Évalué à 3.
Par exemple, une fonction
CREATE FUNCTION areExclusivePeriods( DATE, DATE, DATE, DATE)
RETURNS boolean AS'
DECLARE
debut1 ALIAS FOR $1;
fin1 ALIAS FOR $2;
debut2 ALIAS FOR $3;
fin2 ALIAS FOR $4;
BEGIN
IF (debut1>fin1) OR (debut2>fin2) THEN
RAISE EXCEPTION ''Périodes mal délimitées (début de période ne précède pas la fin) !'';
END IF;
IF (debut2<debut1 AND fin2<debut1) OR (debut2>fin1 AND fin2>fin1) THEN
RETURN ''t'';
ELSE
RETURN ''f'';
END IF;
END;
' LANGUAGE 'plpgsql';
Cette fonction renvoie 't' lorsque les périodes sont exclusives et 'f' sinon.
puis une deuxième fonction sollicitée par le trigger ; par exemple :
CREATE FUNCTION blabla_insert() RETURNS TRIGGER AS'
DECLARE
rec RECORD;
BEGIN
SELECT INTO rec * FROM blabla WHERE areExclusivePeriods( dat_deb, dat_fin, NEW.dat_deb, NEW.dat_fin )=''f'';
IF FOUND THEN
RAISE EXCEPTION ''Conflit entre les périodes du % au % et du % au %'', rec.dat_deb, rec.dat_fin, NEW.date_deb, NEW.date_fin;
ELSE
RETURN NEW;
END;
END;'
LANGUAGE 'plpgsql';
Enfin le trigger à proprement parler :
CREATE TRIGGER trg_blabla_insert BEFORE INSERT OR UPDATE ON blabla FOR EACH ROW EXECUTE PROCEDURE blabla_insert();
En espérant ne pas être trop à côté de la plaque ...
P.S : découper les périodes si chevauchement il y a devrait être possible, mais je ne l'ai jamais fait ...
En clair c'est jouable à mon avis ! (je vais pas tout faire à ta place non plus !)
[^] # Re: concernant lm_sensors, mais un peu tard
Posté par idiotduvillage . En réponse au message modprobe.conf et arrachage de cheveux :s. Évalué à 1.
à savoir
alias char-major-89-* i2c-dev
alias lm_sensors i2c-dev
à mon avis, le deuxième est un trouble-fête ici !
Lorsque tu fais un modprobe w83781d, ça te donne quoi après ?
# concernant lm_sensors
Posté par idiotduvillage . En réponse au message modprobe.conf et arrachage de cheveux :s. Évalué à 1.
modprobe w83781d
ensuite, executer sensors devrait l'affaire.
Tu pourrais aussi exécuter le démon associé par la commande /etc/init.d/lm_sensors start (peut dépendre de la distrib) avant de lancer la commande sensors (mais il faut qu'il n'y ait pas de malaise dans la configuration, sinon ça foire !
En espérant que ça puisse t'aider ...
[^] # Re: C'est pas compliqué !
Posté par idiotduvillage . En réponse au message Requête SQL avancée. Évalué à 1.
Après quelques recherches, il me semble que MySQL ne gère les procédures stockées qu'à partir de la version 5.0 ... qui n'est pas encore finalisée. Quid de sont adoption rapide par les hébergeur à sa sortie ?
[^] # Re: C'est pas compliqué !
Posté par idiotduvillage . En réponse au message Requête SQL avancée. Évalué à 1.
Parce qu'il faut une 'extension' pour gérer des fonctions côté serveur ? alors qu'à mon sens ça devrait faire partie de la base !
Ce n'e sont que des questions innocentes ! Pour ma part, je n'utilise que sur mon propre réseau local ... l'admin est moins vache ;-)
# C'est pas compliqué !
Posté par idiotduvillage . En réponse au message Requête SQL avancée. Évalué à 1.
Ce que je ferais dans ton cas, c'est d'abord un fonction sur le serveur/sgbd, et ensuite appeler cette fonction dans une requête ou à travers une vue.
Cela dit, tu aurais pu préciser au moins le SGBD employé (divers languages sont possibles pour certains). J'ai déjà fait des fonctions sql et plpgsql avec PostgreSQL par exemple ...
Tu fais donc un truc du style :
CREATE FUNCTION format_identifiant( TEXT, TEXT ) RETURNS TEXT AS ...;
puis
SELECT format_identifiant( nom, prenom) as identifiant FROM table ...;
Mon conseil, c'est d'éviter de faire les remplacements au niveau du client : si tu changes de language, tu dois tout refaire tout sinon !
# A priori
Posté par idiotduvillage . En réponse au message Qt me joue des tours. Évalué à 1.
le connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(valueChanged(int)));
par
connect(numlights,SIGNAL(valueChanged(int)),this,SLOT(addlite(int)));
puis en ajoutant un simple tempo->show() dans le slot addlite(int), cela devrait suffire :
par exemple, on pourrait avoir
void Paramligts::addlite( int newValue )
{
QLabel* tempo = new QLabel( "", GBLights );
tempo->setText( QString( "N°%1").arg( newValue) );
tempo->show();
}
cela, pour afficher des label N°1, N°2 ... N°10
Si show() est omis, le QLabel est créé, mais pas affiché puisque à priori, la fenêtre est arrangée (layout, positions ...) au premier affichage, les modifications doivent être absolument explicites.
En espérant que c'était le problème ...
# A mon humble avis ...
Posté par idiotduvillage . En réponse au message dual screen / xinerama avec une carte graphique... quelle sortie faut-il ?. Évalué à 2.
A priori, la 9200 est capable de gérer deux écrans mais si le fabricant de la carte n'a jugé bon de de cabler qu'une seule sortie, ça veut dire qu'il n'y a pas moyen d'en rajouter !
Mon opinion est donc qu'il s'agit vraisemblablement d'une Radeon9200 et qu'il te faut effectivement une autre carte (PCI en complément) ou changer l'actuelle pour une proposant le double écran (faire gaffe au(x) adaptateur(s) pas toujours fourni(s)!
C'est tout ce que mon neurone a bien voulu que mon clavier envoie à l'écran à ce sujet ! ;-)
# acquisition
Posté par idiotduvillage . En réponse au message Question pour les Zopeurs. Évalué à 1.
D'après ce que j'ai compris, tu devrais avoir l'arborescence suivante :
site
Pour que ça marche, il faut appeler index_html avec le contexte de test ou test2 en modifiant l'url :