Enj0lras a écrit 250 commentaires

Oui, le même. De même que les ports sont quasiment les mêmes, avec les modifications requises quand c'est nécessaire pour compiler sur dragonfly.

Bon, j'ai du une bétise en fait, Add n'est clairement pas commutatif.

il n'y a pas (encore) d'héritage en rust.

Sinon, je crois que j'ai compris ce que tu disais sur la commutativité, mais c'est vrai en ocaml aussi,
tu peux définir

let (.+) x y = if x < 3 then x + y else y

qui n'est pas commutatif. Tu peux parfaitement faire des trucs contre intuitifs.

D'ailleurs, + n'est pas vraiment commutatif dans des langages comme ocaml ou rust, par exemple

let i = ref 0 in
!i + (incr i ; 1)

Sinon, pour éviter que les choses ne tournent mal, il n'est uniquement possible d'implémenter un trait pour un type que si le trait ou le type est défini dans le module courant, ce qui évite à des libs externes de faire des bétises qui t'impactent sans que tu t'en rendes compte.

La définition est commutative, même si à première vue c'est pas clair. RHS, c'est le type des éléments additionnés, et Result c'est le type de retour. Ça permet d'implémenter des lois externes. L'implémentation pour int est en fait Add.

Dans "3.0 + 1", tu fais jouer l'addition flottante ou entière ?

Aucune des deux, justement. Ça ne compile pas. En effet, comme expliqué précédement, les deux opérandes doivent avoir le même type.

Est-ce que Add est polymorphique ?

Oui et non du coup. + est un opérateur polymorphe parce qu'il est implémenté pour tout les types T implémentant le trait Add.
Donc

1u + 1u

1.0 + 1.0

Mais il n'est pas "polymorphique" comme en javascript ou php ou tu peux ajouter deux types différents. Mieux, il est impossible d'implémenter un tel opérateur plus en rust. (enfin, pas à ma connaissance.
Je connais pas trop haskell, mais il me semble que c'est assez similaire avec leur typeclass Num.

Qu'est-ce qui se passe si tu joues avec les classes mères ?

pas compris ;)

Ocaml renvoit une exception

En fait non :

int_of_float nan;;
- : int = 0

je pense que la même chose en rust c'est un truc comme :

fn square<T : Mul<T,T>>(x : &T) -> T { *x * *x }
fn twice<T : Add<T,T>>(x : &T, f : |&T| -> T ) -> T { f(x) + f(x) }

fn main() {
        println!("{}", twice(&5i, square));
        println!("{}", twice(&5f64, square));
}

j'ai utilisé des références parce que même si les types entiers sont Clonable, et qu'on pourrait forcer le trait Clone sur T, vu que tu as l'air de vouloir que ça soit le plus générique possible des références m'ont semblées plus apropriées, même si le *x * *x est assez moche.

Je trouve que la solution de rust pour la surcharge des opérateur n'est pas si mal. Chaque opérateur a un Trait associé que tu dois implémenter pour ton type.

Exemple :

pub trait Add<RHS, Result> {
    fn add(&self, rhs: &RHS) -> Result;
}

L'inférence fonctionne la plupart du temps, et quand ce n'est pas le cas il suffit d'ajouter une petite annotation, comme

3u + 4

De plus, il y a toujours une vérification :

let x = 3u;
x + 3.0

mismatched types: expected `uint`, found `<generic float #0>` (expected uint, found floating-point variable)

Tu compares int_of_float avec ça ?

tu es mauvaise langue, c'est exactement la même chose que int_of_float sauf que ça gère les cas ou la valeur n'est pas convertible. Je sais pas trop ce qu'ocaml fait dans ce cas, mais là la méthode
.to_u8() renvoit juste une option.

.expect(error) c'est une méthode qui dit 'Renvoit v si Som(v) ou failure "error" si none'

C'est juste un coding style à la con que tu peux t'empresser de violer parce que les tabs c'est bien.

Il y a aussi un mieux par rapport au C sur le fait que les casts sont pas implicites et que les fonctions de conversion fournies par la lib standards sont "safe".

Du genre,

let x : u8 = 3u.to_u8().expect("Interger Overflow");

Évidement, c'est plus lent parce qu'il y a un pointeur en plus et une comparaison, du coup il y a toujours la possibilité d'avoir un cast classique avec

let x : u8 = 3u as u8;

En outre, la conversion n'est qu'un sous ensemble minime des cas possibles d'overflow, mais ça reste assez pratique.

Honnêtement, j'ai eu la même réaction que toi au début sur la syntaxe qui est clairement moins simple que du ML, mais à l'usage, ça ne m'a pas plus dérangé que ça. La gestion de la mémoire est plus complexe, en effet il y a plusieurs "subtilités" comme tu dis, mais je ne comparerais pas avec C++.

Je suis incapable de coder en C++, j'en fais en stage à chaque fois, puis au bout de 6 mois, je remercie tout les dieux de la création d'avoir la possibilité d'arrêter d'en faire. Avec rust, c'est différent, car en effet il faut réfléchir a un modèle qui n'est pas forcément celui auquel tu es habitué quand tu codes dans un langage avec GC, mais le compilateur t'aide. En fait dès que tu te foire, il t'engueule. C'est quand même un énorme plus comparé à C++.

Finalement, je pense que des langages comme ocaml et rust sont complémentaires. Rust, comme le dit si bien sa page d'accueil, est un "system programming language" qui a vocation à donner le maximum de contrôle à l'utilisateur en altérant le moins possible la sureté.

Ocaml, c'est plus un langage de haut niveau qui a vocation à donner plus de flexibilité et d'expressivité à l'utilisateur tout en ayant un modèle d'execution et de compilation simple, au détriment du contrôle de l'utilisateur sur la mémoire. À mon avis, pour écrire un compilateur ou un site web, ocaml est plus adapté que rust, mais rust l'est plus pour écire un solver de contraintes ou une pile réseau. Quant à C++, je préfère ne pas entendre parler.

Il me semble que la séparation n'est pas artificielle justement. En effet, rust force les annotations de type pour les fonctions, alors que le type des clotures peut souvent être inféré, donc la syntaxe est plus légère.

De plus, en ocaml, la syntaxe de capture implicite est possible car il n'y a qu'une seule sémantique pour les appels de fonction, appel par "valeur" (pour une bonne définition de valeur en ocaml, pointeur ou entier/unit/etc).

En rust, il y a plusieurs syntaxe de clotures qui permettent de controler la capture. Il est possible de capturer les valeurs par référence ou par valeur.

    let b = 3u;
    let f = ref | a :uint | a + b

n'est pas équivalent à

    let b = 3u;
    let f = | a : uint | a + b

qui est encore différent de

   static z : uint = 3;
   fn foo(x : uint) -> uint {
       x + z
    }

En effet, dans le second cas, il faut probablement appeler les destructeurs des variables capturés quand la cloture sort du scope alors que dans le premier et dernier cas, il n'y a pas besoin.

En outre, les clotures ne peuvent pas être récursives, et il est donc parfaitement légitime qu'elles soient anonymes. "fn" est un opérateur de nommage récursif, alors que let ne l'est pas. C'est un peu la disction let/let rec. C'est donc une syntaxe plus proche du

let id = fun x -> x

Bon, évidement, tout cela n'empêcherait pas d'avoir une syntaxe plus unifiée, j'imagine, mais je ne pense pas que ça soit un réel problème. J'ai l'impression que les fonctions sont des valeurs statiques (qui ne sont donc pas gérées par le système de lifetime) alors que les clotures en sont.

tu as raison, en regardant d'un peu plus près avec git, il semble que le linker utilise mmap MAP_FIXED partout depuis toujours. Je ne vais pas toucher à ça, je ne m'y connais pas assez, je pense que je vais attendre de voir les changements introduits dans freebsd pour kes importer.

En fait, tout le monde dit que dragonFly a de l'ASLR, mais je n'en suis pas si sûr.

j'ai découvert hier que la randomization de l'addresse de la pile n'avait que 10bits d'entropie par défaut, et en outre, j'ai l'impression en regardant ça ce soir que les mappings R_X des bibliothèques sont chargés à une addresse fixe (alors que RW_ et mmap sont bien randomisés).
C'est quand même assez bête parce que c'est surtout ceux qui sont executables qui importent. Je suis en train de me demander si le support dans le linker n'a pas été perdu il y a un an et demi quand quelqu'un a décidé de synchroniser rtld avec celui de freebsd, en perdant peut être des modifications locales. Pour la pile, il suffit d'augmenter la valeur par défaut (on dirait que pour 64bits la valeur de 32 bits a été conservée, j'ai un patch c'est trivial), par contre pour le linker, je vais regarder ça mais j'y connais pas grand chose.

Du coup, ça sera intéressant de voir ce que vous ferez !

ufs est supporté dans linux, en tout cas sous sa forme d'ufs2. Ça ne gère probablement pas toutes les fonctionnalités comme softupdates, mais c'est supporté en lecture/ecriture.

Je ne veux pas briser tes rêves, mais j'utilise le mode vi dans mon shell.

Tu parles de quel navigateur ? ça marche pas chez moi ces raccourcis dans firefox, à moins que ça soit vimperator qui les désactives, je sais pas, mais je pense pas.

Tu prends les choses à l'envers. Pourquoi changer vi pour correspondre aux autres logiciels quand on peut changer les autres logiciels pour qu'ils fonctionnent comme vi ?

Tout les logiciels que j'utilise ont des raccourcis clavier vi-like et j'en suis pleinement satisfait. Meme quand en stage j'ai du utiliser visual studio, j'ai trouvé un mode vi pour ce logiciel.

ocsigen/eliom : http://ocsigen.org/

Je travaille par intermittence sur un projet qui fait exactement la même chose… Si j'avais connu pod avant !

Et quand je dis exactement, c'est vraiment exactement.

Je vois. J'ai testé dans un navigateur et je trouve ça bien pratique, merci pour ton travail sur l'API.

Autant je trouve que ça peut être pratique dans un navigateur, puisque ça apporte des fonctionnalités non présentes, autant je ne comprends pas du tout du tout l'interêt d'avoir ça dans npm pour node.js, puisque justement on s'attent à ce que ça soit moins performant et que ça n'apporte… Rien ?

documentées même :).

Et je vois pas ce que viennent faire ici tes histoires de "recoder linux" ou que l'API ne soit pas portable sur autre chose que linux, puisque udev a des le début été crée pour le noyau linux spécifiquement, et ca n'a rien à voir avec le merge dans le meme dépot git que systemd.

C'est au sujet de 'je suis forcé d'utiliser systemd'
N'empêche que ça reste un composant important de systemd qui rend plus difficile la réutilisation de certains composants (notament comme logind) sous d'autes OS. hors, logind devient une API utilisée par les logiciels utilisateurs.

Tout comme le noyau linux t'impose son API, Libreoffice t'impose son format de fichier, apache t'impose son format de fichiers vhost, docker t'impose son format de conteneurs, etc … Bon en fait on pourrait dire que tous les logiciels utilisés par beaucoup de gens t'imposent leur APIs, protocoles ou formats de fichiers, et tu peux pas les modifier librement sans que ca pose des problèmes.

Toutes ces choses, je peux les utiliser sur n'importe quel OS.

Euh non ? C'est gros systemd. Tu peux réinventer des choses et en réutiliser d'autres, je ne vois pas en quoi c'est contradictoire.

Apparament, des gens savent le faire. Notament les pilotes wifi intel et atheros. Ou l'implémentation de référence pour acpi. Et dans la théorie, DRM au début avait été écrit pour être portable. ça se ressent encore un peu dans DRM lui meme, mais plus du tout dans GEM, TTM, ou les pilotes.

La solution tient en un mot : abstraction. C'est pas si différent de faire un toolkit portable. Quand tu prends Qt, tu as pleins d'abstraction pour gérer les fonctionnalités qui sont différentes entre tout les OS. Pour un pilote c'est pareil. Du moment que le développeur du pilote fournit une abstraction bien fichue, et documentée, il ne reste alors plus qu'aux devs des OS d'écrire une implémentation de cette abstraction pour leur OS.

Pour ce qui est à la validation, il est parfaitement acceptable de ne le tester que sur un OS et laisser les développeurs d'autres OS faire de l'intégration et remonter les bugs. Intégrer un pilote est énormément plus simple qu'en développer un nouveau.

Tu as lu cette doc ? Les propriétés des devices n'y sont pas documentés.