Le topic de la programmation: Et envoyez des sioux!

**Nilsou** · 01/04/2019, 18h47

Haha, pas faux

**FB74** · 01/04/2019, 20h01

Intéressant peut-être:
https://www.humblebundle.com/books/m...-dot-net-books

**TwinBis** · 01/04/2019, 20h12

Un livre pour apprendre à se servir de Visual Studio Code...

**FB74** · 01/04/2019, 20h19

Envoyé par TwinBis

Un livre pour apprendre à se servir de Visual Studio Code...

Y'a pas que ça dans la sélection quand même...

**William Vaurien** · 01/04/2019, 20h27

C'est exactement ça, un site des années 90...
Moi ça ma bien fait marrer, surtout avec mon collègue qui n'a pas vu le poisson d'avril tout de suite et qui pensait que le site s'était fait hacker...

Des fois je suis un peu nostalgique de cette époque

Un bon site flashy me ramène à la raison

Et puis ici c'est un peu les années 90 comme même...

**TwinBis** · 01/04/2019, 20h45

Envoyé par FB74

Y'a pas que ça dans la sélection quand même...

C'est vrai.
Mais je trouve que ça jette le doute sur la probité de l'éditeur et donc la qualité de ses livres.

Bizarement on ne trouve jamais O'Reilly ou Manning dans ce genre de bundle.

**Dross** · 01/04/2019, 21h20

Ça dépends de ce qu'il y a dans le livre sur VS Code : si ça concerne les dessous du logiciel, la manière de créer des plugins et autre, ça peut aussi avoir sa place.
Bon par contre, faire du .NET sous Code...

**vectra** · 01/04/2019, 22h30

Envoyé par TwinBis

C'est vrai.
Mais je trouve que ça jette le doute sur la probité de l'éditeur et donc la qualité de ses livres.

Bizarement on ne trouve jamais O'Reilly ou Manning dans ce genre de bundle.

~~Oui mais là, c'est quand-même Associated Press, du groupe Springer.~~ Non, même pas!
Après, ils ont pu engager des branques sur une collection.

**Dross** · 02/04/2019, 17h41

Y'a des canards qui on déjà packagé pour Mac sans avoir à leur disposition un Mac ?
J'aimerai réaliser un installeur pour une app multiplatforme (Win/Linux/Mac), autant pour Win/Linux c'est facile, autant pour Mac tout ce que je trouve nécessite un Mac.

Les seules solutions que j'ai trouvé sont :
- Créer une VM hackintosh, mais ça nécessite d'utiliser un ISO de MacOS piraté et modifié (pour tester ça peut suffire, mais là on parle de packager du code qui sera installé ailleurs, il en est donc totalement hors de question)
- Louer un Mac dans le cloud (solution que je privilégie pour l'instant)
- Acheter un Mac (lol, nop)

Y'a une solution magique que je n'ai pas trouvé ou pas le choix : faudra passer à la caisse ?

**Tramb** · 02/04/2019, 17h42

Envoyé par Dross

Y'a une solution magique que je n'ai pas trouvé ou pas le choix : faudra passer à la caisse ?

Je crois que c'est ça.

**gros_bidule** · 02/04/2019, 17h46

Tu peux aussi passer par une CI comme Travis : tu pourras lancer un build sur plein d'environnements allant d'Ubuntu à Windows en passant par OSX.
L'important étant ici que ton build upload ton archive quelque part. C'est ce que font pas mal de projets sur GitHub/GitLab : ils utilisent Travis pour builder des releases exe/dmg et autorisent Travis à déposer lesdites releases sur le dépot du projet.
Je pense que ça posera soucis uniquement si tu fais des trucs qui dépendent d'un compte Apple.

Biensûr, ça implique de l'open-source

Mais en gratos je ne vois que ça. Sinon tu peux te prendre un compte GitHub/GitLab privé, ça restera moins cher qu'un Mac, même d'occaz.

**Dross** · 02/04/2019, 18h01

Mon code est opensource et déjà en CI, mais j'avais cru comprendre que les agent MacOS était souvent payant, faudrait que je creuse de ce coté là en effet.
Merci !

Edit: bon bah mon CI provider ne supporte par encore MacOS (prévu 2018 mais pas fait, et pas de news), Travis semble être la bonne solution et gratuit, je vais devoir migrer ma chaîne de build.

**FB74** · 08/04/2019, 20h01

Livres sur les blockchains et cryptomonnaies:
https://www.humblebundle.com/books/b...cy-packt-books

**Dross** · 08/04/2019, 20h49

Si vous vous intéressez au dev sur cryptocommodités, je vous conseille plutôt la doc d'Ethereum et/ou de Solidity (elles sont bien faite) ou encore directement des cours dédiés à Solidity (sur udemy ou autre).

**vectra** · 09/04/2019, 17h07

J'ai besoin d'aide en compil° C++/CMake.

J'utilise la lib ITK, que j'ai dû récemment recompiler pour raisons de compatibilité. Cette lib est compilée en utilisant une autre lib, GDCM, que j'ai compilé à la main également.
Bizarrement, tous les EXE que je produis dorénavant et qui nécessitent ITK compilent, mais ne se lancent pas.

Code:

/home/vectra/GIT/monprojet/cmake-build-debug/Tutorial/ITK/DicomExamples/bin/itk_dicom_to_nifti_v2: error while loading shared libraries: libgdcmDICT.so.3.0: cannot open shared object file: No such file or directory

Les .so réclamés (dans l'ordre, ceux de GDCM, puis de ITK) sont tous présents à leur place habituelle, mais pas dans un emplacement système.
Si je rajoute à l'environnement d'exécution de l'exécutable ceci:

Code:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/vectra/SDK/gdcm/lib:/home/vectra/SDK/itk/lib

, alors cela fonctionne comme précédemment.
Mais salement. Et c'est pénible, car j'ai souvent une brochette de petits exécutables dans mon projet, qui s'articule quand-même autour de deux gros programmes.

Ce qui est incompréhensible, c'est que je n'ai pas ces soucis avec d'autres programmes qui n'utilisent pas VTK, mais utilisent par contre GDCM directement.

Vous auriez des suggestions quant à là où j'ai pu me gourer?

Et de comment régler le problème proprement?

A long terme, je verrais mon projet comme un CMake qui inclut/télécharge les sources des ITK et GDCM "qui vont bien ensemble" (ça en fait peu), qui les compile, stocke les libs en local et propose des exécutables. Mais vu le temps que met ITK à compiler, c'est un peu overkill pour le moment.

Le seul moyen que j'ai trouvé pour lancer ces programmes, ce fut de rajouter les emplacements

**Mr Slurp** · 09/04/2019, 20h31

Envoyé par vectra

Vous auriez des suggestions quant à là où j'ai pu me gourer?

C'est une histoire de RPATH :
https://en.wikipedia.org/wiki/Rpath

Envoyé par vectra

Et de comment régler le problème proprement?

Vu que tu fais des cmake :
set_property(TARGET <nom de la target de type librarie> PROPERTY INSTALL_RPATH "\$ORIGIN")

Et encore un peu de lecture
http://man7.org/linux/man-pages/man8/ld.so.8.html

**vectra** · 10/04/2019, 11h55

Merci pour les infos, j'étais pas assez à la page en fait.

Par contre, je viens de tracer le problème au fil des lectures que tu m'as recommandé. En faisant des 'ldd' sur mes exécutables, j'ai vu des instances 'not found' qui correspondent exactement aux bibliothèques gdcm demandées.
J'ai été obligé de recompiler ITK récemment (4.13.2), et j'ai donc lançé du 'ldd' sur tous les .so récemment produits. Eh ben il s'avère que les bibliothèques de la version 'build' ont tous les chemins requis, mais que par contre celles de la version 'install' ont des 'not found' correspondant exactement. Ce n'était pas le cas avec l'ancienne version d'ITK (4.13.1) que j'avais également compilé à la main (build ET install ok).

Je rappelle que je dois compiler ITK en précisant le chemin de la bibliothèque GDCM qui va bien; j'ai peut-être oublié un des nombreux champs de configuration du cmake...

Je viens de trouver le champ CMAKE_SKIP_INSTALL_RPATH, désactivé par défaut, qui stipule que si activée, les runtime paths seront spécifiés pour le build mais pas pour l'install.
J'ai certainement laissé la case dans le bon état pourtant

Je relance une compil après un clean des familles; on verra bien ce que ça donnera.

**vectra** · 10/04/2019, 20h01

Bon, ben j'ai réussi à recompiler tout ITK et à avoir les libs INSTALL qui n'ont plus aucun message 'not found'.
De ce fait, sans aucune option, mes programmes passent tous, de base, le barrage GDCM.

Par contre, maintenant, mes programmes ne semblent pas trouver certaines libs:

Code:

/home/vectra/SDK/ITK/4.13.2>ldd /home/vectra/GIT/vectrarepo/cmake-build-debug/Tutorial/ITK/DicomExamples/bin/itk_Bk_dicomReadTags | grep found
	libITKVNLInstantiation-4.13.so.1 => not found
	libitktiff-4.13.so.1 => not found
	libitkminc2-4.13.so.1 => not found
	libitkjpeg-4.13.so.1 => not found
	libITKMetaIO-4.13.so.1 => not found
	libITKniftiio-4.13.so.1 => not found
	libITKNrrdIO-4.13.so.1 => not found
	libitkpng-4.13.so.1 => not found
	libitktiff-4.13.so.1 => not found
	libITKVNLInstantiation-4.13.so.1 => not found
	libITKIOIPL-4.13.so.1 => not found
	libitkdouble-conversion-4.13.so.1 => not found
	libITKVNLInstantiation-4.13.so.1 => not found
	libitkv3p_netlib-4.13.so.1 => not found
	libitkvcl-4.13.so.1 => not found

Quand j'essaie de lancer un programme qui inclut ITK, comme de bien entendu, il me réclame le premier .so de la liste.
Comme de bien entendu, il 'suffit' de mettre le chemin d'install des .so dans LD_LIBRARY_PATH et ça se lance.
Pourtant, dans mon CMake, j'ai ceci qui suffisait avec l'ancienne version d'ITK et qui devrait également suffire:

Code:

find_package(ITK REQUIRED
        PATHS /home/vectra/SDK/ITK/itk-vectra NO_DEFAULT_PATH)

IF (ITK_FOUND)
    message("ITK found:")
    INCLUDE(${ITK_USE_FILE})
ENDIF (ITK_FOUND)

**vectra** · 11/04/2019, 14h04

J'ai réussi à beaucoup corneriser le problème.

J'arrive à compiler ITK de telle sorte qu'il n'y ait aucune occurence de 'not found' si je fais ldd sur chacun des .so en build comme en install : belle avancée!

Je sais maintenant faire ce que je veux avec le RUNPATH sous CMake:

Code:

    SET(VECTRA_ITK_PATH "/home/vectra/SDK/ITK/4.13.2/itk-vectra/lib/")
    SET(CMAKE_EXE_LINKER_FLAGS
            "${CMAKE_EXE_LINKER_FLAGS} -Wl,-rpath,${VECTRA_ITK_PATH}")

    <mes exécutables...>

Et en utilisant 'readelf -d' sur l'exécutable, je vois bien ce path en tête. Donc ça c'est bon aussi.

Mon problème, c'est qu'en effectuant ldd sur l'exécutable lui-même, j'ai encore des 'not found'.
Il reste une poignée de bibliothèques itk qui semblent poser problème, sachant que pour celles héritées de gdcm, c'est réglé.
Ce qui est énervant, c'est que les bibliothèques 'not found' sont toutes présentes dans le premier répertoire du RUNPATH

Code:

ldd /home/vectra/GIT/monrepo/cmake-build-debug/Tutorial/ITK/DicomExamples/bin/itk_Bk_dicomReadTags | grep found
	libITKVNLInstantiation-4.13.so.1 => not found
	libitktiff-4.13.so.1 => not found
	libitkminc2-4.13.so.1 => not found
	libitkjpeg-4.13.so.1 => not found
	libITKMetaIO-4.13.so.1 => not found
	libITKniftiio-4.13.so.1 => not found
	libITKNrrdIO-4.13.so.1 => not found
	libitkpng-4.13.so.1 => not found
	libitktiff-4.13.so.1 => not found
	libITKVNLInstantiation-4.13.so.1 => not found
	libITKIOIPL-4.13.so.1 => not found
	libitkdouble-conversion-4.13.so.1 => not found
	libITKVNLInstantiation-4.13.so.1 => not found
	libitkv3p_netlib-4.13.so.1 => not found
	libitkvcl-4.13.so.1 => not found

Chacune de ces libs sont présentes là où il faut pourtant.

Code:

readelf -d /home/vectra/GIT/monrepo/cmake-build-debug/Tutorial/ITK/DicomExamples/bin/itk_Bk_dicomReadTags

Dynamic section at offset 0x41680 contains 59 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libitkIOFDF-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIODCMTK-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOBruker-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOHDF5-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOLSM-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOMRC-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOPhilipsREC-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libitkMGHIO-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libitkSCIFIO-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOMINC-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOBMP-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOGDCM-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgdcmDICT.so.3.0]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOGIPL-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOJPEG-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOMeta-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIONIFTI-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIONRRD-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOPNG-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOTIFF-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOVTK-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOBioRad-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOGE-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOStimulate-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKIOImageBase-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libITKCommon-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libitksys-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libitkvnl_algo-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libitkvnl-4.13.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/vectra/SDK/ITK/4.13.2/itk-vectra/lib/: <etc...> ]
<...>

Par contre, ce que je remarque, c'est qu'aucune des bibiolthèques non trouvée par 'ldd' n'est présente dans le header elf.
C'est peut-être là le problème

Je vois que c'est couvert par ce tuto:
https://amir.rachum.com/blog/2016/09...red-libraries/

**Nilsou** · 14/04/2019, 21h09

Quelqu'un peut-il me confirmer un truc (je n'arrive pas à retrouver la réponse sur le net) :

En C et C++ :

Code:

a+=a;

Ou toute autre variante, il me semble que le résultat est non défini. Je crois bien avoir lu ça quelque part. Vous pouvez me confirmer (avec une source de préférence ...)

Il me semble que c'est le même soucis qu'avec i = i++ mais j'ai un doute.

**Thamior** · 14/04/2019, 21h57

Tu es sûr que i = i++ est indéfini?

Envoyé par https://en.cppreference.com/w/cpp/language/operator_incdec

Post-increment and post-decrement creates a copy of the object, increments or decrements the value of the object and returns the copy from before the increment or decrement.

Ca m'a juste l'air de ne rien faire (plus exactement i est incrémenté puis la valeur d'avant l'incrémentation est assignée à i).

Pour a += a, je pense que c'est bon aussi tant que tu ne fais pas des trucs chelous avec une union :

Envoyé par https://en.cppreference.com/w/cpp/language/operator_assignment

If the left and the right operands identify overlapping objects, the behavior is undefined (unless the overlap is exact and the type is the same)

Après c'est pour des objets mais j'ose se espérer que le comportement s'applique aussi aux types de base. J'ai peu être tord d'espérer

**ducon** · 14/04/2019, 21h58

a+=a, me semble tout-à-fait correct, ça double a.
i=i++ fait que i ne change pas, je viens de tester.

**Nilsou** · 15/04/2019, 00h32

Envoyé par Thamior

Tu es sûr que i = i++ est indéfini?

Tout à fait certains (enfin, sauf si il y a un truc que j'ai zappé), c'est interdit d'écrire un truc du genre, ou même toute opérations avec un i d'un coté et un i++ de l'autre, même avec pleins de formules au milieu.

C'est un exemple de wikipedia d'ailleurs :
https://en.wikipedia.org/wiki/Undefined_behavior

Modifying an object between two sequence points more than once produces undefined behavior.[15] There are considerable changes in what causes undefined behavior in relation to sequence points as of C++11.[16] The following example will however cause undefined behavior in both C++ and C.

i = i++ + 1; // undefined behavior

Envoyé par ducon

i=i++ fait que i ne change pas, je viens de tester.

Ha mais le compilo va donner un truc, "undefined behavior" ça veut juste dire que ça peut être au pif, dépendant du PC ou du compilo.

edit :
J'ai vérifié pour i=i++, je confirme que c'est bien un undefined behavior :
https://stackoverflow.com/questions/...ally-undefined

Maintenant la question demeure pour a += a ...

reedit : Bon, pour les plus curieux, j'ai posé la question et la réponse clarifie pas mal de truc (notamment le cas du i=i++). Voici la réponse ->

No, a += a is not undefined. The behavior of i = i++ is not defined by the C standard due to this rule in C 2018 6.5 2:

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.

That rule applies because both i++ and i = have side effects of updating i, and they are not sequenced. (Although the value computation of i++, which produces the value to be used in the rest of the expression is sequenced before the assignment, its side effect of updating i is not sequenced relative to the assignment.)

In a += a, the value computation of the right operand (a) occurs before the assignment (according to 6.5.16 3), and then a += has the side effect of updating a. So:

There is only one side effect, so there are not two unsequenced side effects.
There is a side effect on a and a value computation of a, but they are sequenced.

Donc voila : ne pas utiliser i=i++ ou autre variante dans un code (n'importe quoi comme i = f(i++) sera aussi foireux), mais a+=a c'est OK.

Ça s'applique au C comme au C++ 14 et au delà.

**Thamior** · 15/04/2019, 03h07

Envoyé par Nilsou

edit :
J'ai vérifié pour i=i++, je confirme que c'est bien un undefined behavior :
https://stackoverflow.com/questions/...ally-undefined

Si je comprends bien, i = i++; est défini si i est une instance d'une classe, mais pas si c'est un scalaire. Ce qui est bien avec C++ c'est qu'on ne s'ennuie jamais.

**ducon** · 15/04/2019, 09h33

Un scalaire n’est pas une instance d’une classe ?

**vectra** · 15/04/2019, 09h57

Pourquoi faire?

**TiNitro** · 15/04/2019, 13h23

Envoyé par ducon

Un scalaire n’est pas une instance d’une classe ?

pas en C++ non.

- - - Mise à jour - - -

cela dit, je me demande quel compilo ne supporte pas l'instruction "i=i++" interprétée comme "i++". Il doit y avoir tellement de lignes de code legagy avec ce genre d'instruction dans la nature que c'est chaud patate.
Mais c'est logiquement indéfini sur un scalaire.

**ducon** · 15/04/2019, 13h36

Envoyé par vectra

Pourquoi faire ?

Pour unifier le truc ? Pour avoir des méthodes qui vont bien ?
En Python, tous les ensembles de nombres sont des classes.

Code:

>>> dir(0)
['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'numerator', 'real', 'to_bytes']

**vectra** · 15/04/2019, 15h04

C'est des noms de méthode ça? Limite, les intrinsics sont plus lisibles...

**Nilsou** · 15/04/2019, 15h32

Envoyé par TiNitro

cela dit, je me demande quel compilo ne supporte pas l'instruction "i=i++" interprétée comme "i++". Il doit y avoir tellement de lignes de code legagy avec ce genre d'instruction dans la nature que c'est chaud patate.
Mais c'est logiquement indéfini sur un scalaire.

Je suis pas certains de ceci, j'ai jamais croisé ce genre de chose avant perso. C’est seulement quand un élève m'a fait l'erreur que je me suis posé la question, dans du vrai code j'ai jamais vu ça ...

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages