You are not logged in. Please login or register.
QElectroTech → Posts by scorpio810
Bonjour,
je viens de tester sur le Seven de mon aîné, seul PC Windows de la tribu....
Vieux Intel I3, vieux DD 320Go 7200Tr/mn Qet prend environ 6 secondes du lancement jusqu’à la fin de la progress bar, ça semble être bien plus rapide qu'avant aussi sur Windows.
Très très loin de tes 3 minutes Pach ..ça devrait aller bien mieux maintenant?
Bonjour Pach,
merci.
Apres tout dépendra du nombre de cores, threads CPU et du type de CPU de ton Yoga.
Mais bon si Galexis avec son pc du boulot y voit une différence, ça devrait etre plus rapide pour toi aussi.
Apres si tu veux du TGV passes sur un OS Gnu/Linux, Windows c'est le tortillard des Cévennes. 
Test rapide sous WIN7 : bien plus rapide qu'avant, splash screen à peine visible. Pendant le chargement de la collection, sur mon pc du boulot bien pourri, il n'était pas possible d'utiliser le soft pendant ce temps là.
Super. 
For pinning just create a file 40qelectrotech-devel in your /etc/apt/preferences.d/ use nano/gedit/vim by example or other editor for edit this file:
sudo gedit /etc/apt/preferences.d/40qelectrotech-devel
And paste this:
Package: qelectrotech*
Pin: version 0.51.*
Pin-Priority: 1001Save and refresh repository in your package manager or by line command.
Hi Stefan,
why you need multiple N (neutral) if all N at the same potential, i don't understand?
Could you please attach a screen capture for explain your problem?
Regards,
Laurent
Merci du retour.
Bonjour,
c'est la première fois qu'on nous remonte ce problème, d'habitude quand ça se produisait les users retrouvaient leurs fichiers .qet vide, là on ne pouvaient rien y faire.
Je pense qu'on peut étudier de mettre plus tard en place, un système de fichier .back en parallèle du fichier projet avec un enregistrement automatique toutes les 1/2 heures.
Si par malheur Qet venait à planter ce qui ne doit pas arriver, l'utilisateur pourrait récupérer son projet en renommant le fichier.back en .qet
Faudra attendre les retours de ceux qui l'ont installé sur un Windows natif pour avoir une idée, bien que le facteur core/CPU, HDD/SSD va être déterminant.
Galexis, et les autres?
Faudra attendre les retours de ceux qui l'ont installé sur un Windows natif pour avoir une idée, bien que le facteur core/CPU, HDD/SSD va être déterminant.
Il va de soit qu'on ne va pas revenir en arrière.
Il est clair qu'aujourd'hui qu'avec les dernières améliorations sur la conso RAM, le Multithreading on peut envisager d'importer un nombre très important de symboles dans les collections sans que ça demande une machine avec beaucoup de RAM installée et un temps de chargement du logiciel très long.
Reste à étudier si on peut améliorer avec le Multithreading l'accélération du chargement de nos gros projets.
De notre coté on essaye de comprendre pourquoi ton import ne contient que tes électrovannes, et dans la mesure du possible voir si on peut récupérer ton projet.
Nuri wrote:
Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :
Je ne suis pas convaincu, c'est mieux avec un Win 10 installation neuve, mais c'est tres très loin d’être aussi rapide et fluide qu'une VM XP et dans une moindre mesure un Seven sur le même disque dur que cette VM... pourtant avec 6 cœurs sur 8 alloués ainsi que 8 Go de RAM dédiée à cette VM !
virtualbox-5.0_5.0.20-106931-Debian-jessie_amd64.deb + VBoxGuestAdditions_5.0.20.iso installées !
Bonjour,
je pense que tu as clairement un gros soucis sur ta machine, c'est quoi comme pc, combien de RAM, machine très stable avec d'autres programmes?
Tu te rappelles si tu faisais quelque chose en particulier avec QET quand tu as eu ce message?
Le problème est que tu as seulement que tes électrovannes en éléments importés, les autres ont disparus après le crash.
Bon, le git pull sur le dépôt mxe et rebuild des environnements de cross-compilation aura été quand même payant : le chargement des collections et l'avancement de la barre de progression démarre maintenant de suite sur la VM WIN 7, pas comme sur ma vidéo précédente.
Bon, c'est toujours aussi lent, vais essayer avec une nouvelle VM WIN 10 neuve.
Merci Nuri, tu me rassures du coup. 
J’étais parti dans de grandes investigations ... , mxe git pull et rebuild des environnements de compilation croisés, recherches aussi du coté de NSIS l'installateur Windows et de mes scripts, voir re installation d'un Seven clean dans ma VM, etc.
Comparaison démarrage QET sous Debian unstable en natif et sous Window 7 en VM.
AMD FX 8350 8C/8T et dans la VM Seven 6C/6T
Bon ont sait tous que Windows n'est pas réputé pour sa légèreté, sa stabilité et encore moins pour être un OS rapide, mais là ça commençait à m’inquiéter !
Ben bien les gars, ca valait le coup de faire un splash screen 
Jusqu’à présent oui, aujourd'hui il en serait même superflu suivant les OS et les machines.
Son problème est d'autant plus bizarre, s'il utilise la version stable, non ?
Concernant la provenance de QET je ne sait pas, je l'ai récupéré par l'intermédiaire d'un informaticien de la société où je travail.
Bon, sous MS Windows c'est clairement pas la même vitesse de chargement escompté dans ma VM seven que sur ma Debian...
Vous confirmez?
Il me semble remarquer que la version ReadyToUse est plus rapide au lancement que celles avec l'installateur .. A suivre !
La charge mémoire s'est effectivement bien allégée. Pour la vitesse de démarrage, cela semble plus rapide sur LM17.3 mais pas hyper flagrant : je testerais au boulot sur mon poste WIN7, car c'était vraiment très long, avec en plus le côté pénible du splash screen qui m'empêchait de pouvoir faire autre chose en gardant le focus.
Revision: 4544
Author: blacksun
Date: 2016-06-06 21:15:31 +0200 (Mon, 06 Jun 2016)
Log Message:
-----------
Remove the flag Qt::WindowStaysOnTopHint of the splash screen
Je doute qu'il t’embête beaucoup maintenant le splash screen, je n'ai même plus le temps de le voir.
Une autre différence phénoménale pour te citer Nuri, le lancement et chargement complet de QET est maintenant aussi considérablement réduit.
QET utilise dorénavant tous les cœurs/threads disponibles du/des processeur(s) de la machine pour gérer le cache SQL des quelques 2600 éléments que contient la collection fournie, le temps de lancement du logiciel et chargement des collections passent maintenant sous la barre des moins de 2 secondes sur ma machine AMD FX 8350 + SDD 840 pro ! 
Revision: 4542
Author: blacksun
Date: 2016-06-06 20:34:34 +0200 (Mon, 06 Jun 2016)
Log Message:
-----------
Use multithreading for loading the element collection
Bonjour Pach,
reste plus qu'a attendre la sortie de Qt 5.6.1 et voir si ça corrige le problème que tu rencontres.
C'est pour bientôt : http://lists.qt-project.org/pipermail/d … 26162.html
https://wiki.qt.io/Qt_5.6.1_Change_Files
@ Galexis: c'est son choix de prendre la version stable et non celle en cours de devel même si d'un autre coté on se prive des dernières avancées ajoutées (nouvelles basic shapes, écrans QHD, consommation RAM, et bientôt une autre grosse nouveauté ...).
Celle en cours de développement n'est pas moins stable qu'une taguée ... stable.
Le seul avantage de snap pour QET se trouvera être dans le futur et sur les prochaines LTS Ubuntu seulement.
Les autres se penchant d'avantage pour http://flatpak.org/faq.html http://flatpak.org/index.html#about
D'ici là, on trouvera plus de documentations, j'ai clairement pas le temps n'y l'envie de perdre une semaine ou plus de mon temps libre pour faire fonctionner ce nouveau paquet snap !
Pour l'instant comme tu le sais je fais aussi des paquets backports Debian Jessie, Ubuntu LTS 14.04 trusty, il s’avère parfois que des méthodes dernièrement ajoutées dans le code provoque un FTBFS sur Jessie ou trusty, et compile très bien sur les autres distributions récentes, la faute aux vielles bibliothèques Qt 5.3 qui ne connaissent pas ces nouvelles méthodes apparues plus tard au fils des versions Qt.
https://launchpadlibrarian.net/26366255 … ING.txt.gz
Il faut donc soit se passer de ses nouvelles fonctions, ou en trouver une compatible même si ça nous arrangent moins ou adapter le code suivant la version trouvée : si le code à la compilation trouve que la version de Qt <= 4.5 cette fonction sera codé différemment que si la version Qt trouvée est supérieure, t'en fini plus !
C'etais déjà très fréquents sur le vieux code Qet et de l’évolution des libs Qt 4 en parallèles, il fallait ajuster le code suivant les versions Qt trouvées : positionnement des textes différents, impression, etc pouvaient différer suivant la version Qt.
Avec snap, tu fais comme je fais pour tous les paquets Windows : c'est la dernière version embarquée de Qt, GCC pour tout le monde, point barre.
Je parle pas des compilos GCC, etc, mais c'est souvent le même problème.
http://linuxfr.org/users/vejmarie/journ … sur-xenial
Au bout d'un mois d'essai ça marche complétement.
Vous vous en passerez 
!
D'accord, tiens nous au courant.
Toujours télécharger les logiciels Windows sur le site de l’éditeur, ça évite bien des problemes.
Les informations contenues dans le widget à propos onglet version: numéro de version, version Qt, etc, sont maintenant sélectionnables et on peut les copier pour les coller directement sur le forum en cas de demande.
[size=4]QElectroTech V 0.51-dev+svn4533
Compilation : GCC 5.3.1 20160519 - built with Qt 5.5.1 - run with Qt 5.5.1
Tu as essayé avec une version téléchargée sur ce site si le problème est le même?
Si ce problème était fréquent, nous serions les premiers à en être au courant, ce qui n'est pas le cas.
QElectroTech → Posts by scorpio810
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.070 seconds (22% PHP - 78% DB) with 6 queries