Anthony Jaguenaud a écrit 1970 commentaires

Salut,

commençons par le début. Quand je lance ce programme, j’ai une erreur.

def battage (s1,s2):
    max=0
    min=0
    if len(s1)(len(min)-1)*2:
        for j in range(0,b-(len(min)-1)*2,1):
            s[j+(len(min)-1)*2+1]=s2[6+j]
    print(s)

Mon interpréteur python n’aime pas la ligne :

    if len(s1)(len(min)-1)*2:

Que cherches-tu as tester ?

Peux-tu m’expliquer l’erreur suivante ?

TypeError: object of type 'int' has no len()

Je ne l’ai jamais collé, mais il est là !

En montant l’escalier…

--->[]

Tu sais, le seul moyen de ne pas fabriquer des failles, c’est de ne pas développer.
Les pointeurs ne sont qu’un outil, il faut apprendre à les utiliser, comprendre à quoi ils servent et enfin prendre suffisamment de recul pour savoir quand les utiliser ou non.
Se limiter parce qu’il y a un risque n’est àmha pas la meilleure solution.

Sur debian, sokoban est dans le paquet : games-puzzle

$ apt install games-puzzle
…
$

Je ne l’ai pas trouvé pour fedora.

mouais, moi je vois un noyau linux captif dans un windows, et un noyau linux captif dans un environnement Android, plus des linux enfermés dans des clouds.

Pourquoi captif ? Linux est en relation direct avec plein de monde, sur Android, il gère les communications externe, les interactions avec l’utilisateur, etc. d’accord, il n’est pas en relation direct avec les applicatifs puisqu’il y a Dalvik en intermédiaire. Mais je ne trouve pas que le noyau Linux soit captif.
Sur windows, il communique avec les applications et le hardware, il rend service à l’utilisateur qui lui est peut-être captif (c’est mon cas au boulot 😭), mais le noyau n’est pas captif… au pire, on ne l’a pas laissé emmener ses amis (GNU) avec lui.

Merci pour les réponses. Par contre, je ne vois pas la section « Why Not Use TinyDB » :'(

La durabilité doit être le temps d’un test. La base sera réinitialisé pour le suivant.

Donc, la transaction sera durable dans mon environnement et mon besoin.

J’ai un système à simuler qui contient un certain nombre d’éléments. Plusieurs process qui accède aux données pour répondre aux messages à la place des vrais systèmes en temps réél.
Lorsqu’on change des données pour changer d’état, je veux que l’ensemble soit toujours cohérent.
D’où l’idée de faire du transactionnel. Mais je n’ai pas besoin de persistance, à la fin de mon test, je vais réinitialiser l’ensemble pour le suivant.

Je vais regarder, merci.

Bah, mon besoin c’est surtout de partager les états de mon système qui sont des (clé—valeur)… Une base relationnel me semble un peu overkill.

Oui. Je me demandais juste s’il n’y avait pas mieux. Après l’avantage de cette solution, c’est que on peut avoir des process codé dans d’autres langages.

J’avais trouvé ça. Quelqu’un l’a-t-il utilisé ?

Y-a-t-il mieux ?

Regarde du côté des ressorts (stretch) en mettant les bon coef. ça doit faire ce que tu veux…

voir là.

Tu met dans un VBoyLayout un stretch dessus, un HBoxLayout, un stretch dessous.
Dans le HBoxLayout un stretch gauche, bouton, strech droite.

C’est des souvenir ;-)

J’espère avoir pu t’aider.

Sauf que l’agence de sécurité aéronautique américaine a délégué la certification à Boing… ne cherchait pas de conflit d’intérêt ou d’indépendance, c’est la sécurité des passagers qui prime…

Il faut que tu installes les headers du noyau.

Par contre, je suis intéressé par le résultat du lspci.

Sur ma machine Virtuelle :

$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service
00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01)
00:06.0 USB controller: Apple Inc. KeyLargo/Intrepid USB
00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
$

Il liste tous ce que le noyau détecte, mais ça ne veut pas dire qu’il sache les prendre en compte.

A priori elle n'est pas reconnu.

Oups

Il faut compiler le driver et le charger avec modprobe.

Non, n’importe quelle carte sur le BUS PCI doit donner son vendorID et son ID. C’est une fois en possession de cette information que le noyau peut charger le bon driver.

Si la carte n’est pas reconnu :

• Vérifier qu’elle est correctement enfoncée dans le connecteur PCI.
• Changer la carte de slot au cas où une soudure ait sautée (peu probable)
• La remplacer par une carte que tu sais fonctionner.
• Vérifier si la carte est reconnue sur un autre PC (Windows)
  • Oui :
  • Redémarrer avec un live CD linux et refaire un lspci.

Voila mes idées là, maintenant, tout de suite.

Bonne chance.

Et le java ? La téléréalité ? :-p

---->[]

Ok, je ne pensais pas. Merci d’améliorer ma culture.

Non, si ta source est plus petite que str, le dernier caractère ne sera pas écrit… et rien ne prouve qu’il vaille '\0'.

Je vois un cas d’usage dont il ne faut pas abuser pour la lecture…

  int n = 50;
  char str[n];

  …
  // Si len(source) >= 50, il n’y a pas la place pour le caractère
  // terminal. Donc on peut l’ajouter directement.
  // Par contre, attention à la compréhension du code.
  strncpy(str, source, n)[n-1] = '\0';
  …

J’ai pas tout saisi, mais un petit man join pourra peut-être t’aider.

Pour maîtriser le temps Réel, il faut voir ça comme de l’échantillonnage en fréquence. Il te manque une donnée : le temps de réponse voulue.

Question 1 : À la réception du message au bout de combien de temps, l’action doit être réalisée ?

Question 2 : À la lecture du message, en combien de temps l’action est réalisée ?

À partir de là, tu peux déterminer et prouver que ton logiciel répond en temps et en heure.

Dans ton exemple, la réponse à la question 2 est : 4s.

Avec 4s de traitement, ta période ne peut descendre en dessous de 4s (voir un poil plus).
Disons 5s. Donc, tu peux garantir que le traitement sera réaliser 10s après la réception. Des fois ce sera 4,1s des fois 9,1s. Mais toujours moins de 10s.

Si tu n’as pas cette problématique de temps de réponse voulu, j’aurais tendance à utiliser des solutions bloquante de type : select pour la lecture et communication inter thread pour prévenir en sécurité de la réception. Cette solution sera sûrement plus réactive, mais le temps non garanti.

Question : As-tu vraiment besoin de la maîtrise de ton temps réel pour ton application ? Tu ne donne pas beaucoup de détail (OS ou Bare metal), plateforme, etc.

Si tu as un CPU multi cœur par exemple, et que tu peux dédier un cœur à ça, alors, tu peux faire un thread bloquant qui va te garantir une réponse en moins de 5s. Mais ton cœur n’est pas disponible pour autre chose… c’est un choix de design à faire.

Ton problème c’est que soit c’est les clients qui payent le journal, donc le journal fait plaisir à ses clients, donc est partial. La solution c’est de payer un impôt pour la presse ? Non, car le journal serait à la solde de l’État…

Il n’y a pas de solution !