Jump to content

Timothée BERNARD

Étudiant
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    3

Timothée BERNARD last won the day on November 26 2013

Timothée BERNARD had the most liked content!

About Timothée BERNARD

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Cursus
    A.Sc.1
  1. Bonjour à tous, SUPINFO Low-Level Laboratory ou SL3 est un projet qui a pour but de rassembler les étudiants autour de la programmation système et ceux voulant comprendre comment fonctionne un système d’exploitation, un langage informatique, etc. Pour sa deuxième année, le laboratoire va continuer dans la même lignée avec toujours au programme : le développement logiciel, la programmation système, la programmation parallèle et concurrente, l’algorithmique, les concepts bas-niveau, les systèmes d’exploitations … auxquels s’ajoutent cette année le calcul distribué et les traitement des données. Les thèmes abordés par le SL3 sont nombreux et variés. C’est la volonté principale de notre projet d’aborder des domaines plus techniques de façon compréhensible. Nous vous invitons d’ailleurs à visiter notre site internet afin de consulter nos différents articles et nos différents travaux : http://www.lab-sl3.org. Le SL3 est une plate-forme conçus pour tous autour de l’échange et de la découverte : du débutant souhaitant en savoir plus sur le fonctionnement d’un ordinateur, au développeur souhaitant progresser sans oublier les développeurs plus confirmés souhaitant s’investir dans un projet technique, chacun trouve son compte. Le laboratoire est aussi une communauté, nous disposons d’un forum (http://forum.supinfo.com/index.php?/forum/166-low-level/) mais nous sommes surtout présents sur le réseau IRC www.supnetwork.org à l’adresse : #sl3@irc.supnetwork.org (accessible par le client web http://www.supnetwork.org/webchat/). Pour cette nouvelle saison, notre laboratoire a plusieurs idées de projets comme une machine virtuelle (à la JVM), un émulateur x86, des travaux autour des algorithmes lock-free, une base NoSQL, etc. Nous effectuerons la liste complète et nous initierons les projets qui répondent aux plus fortes demandes. Nous hébergeons nos projets sur Github https://github.com/labsl3 ce qui permet à chaque membre de contribuer à un projet ou à plusieurs projets de façon collaborative. Si vous êtes intéressés par les activités du SL3, juste de simples curieux ou même que vous désirez représenter le SL3 sur votre campus (CLM), je vous invite à envoyer un mail aux GLMs aux adresses suivantes : Timothée BERNARD, timothee.bernard@supinfo.com Mathieu STEFANI, mathieu.stefani@supinfo.com Note: Les réinscriptions ne sont pas automatiques chaque année, si vous étiez inscrits l’an dernier, n’oubliez pas de vous réinscrire pour cette année. Si vous êtes sur le campus de Londres, vous pouvez également contacter le CLM déjà présent sur ce campus: Simon ROUGER, simon.rouger@supinfo.com. Cordialement,
  2. Salut, il n'y a pas de CLM sur Lyon à l'heure actuelle, le SL3 va bientôt envoyer sa présentation par mail à l'ensemble des étudiants et commencer sa campagne de recrutement. Tu peux t'engager en tant que CLM, la tache n'est pas compliqué, si tu as besoin d'aide et de conseils, le reste du laboratoire dont les autres CLM et les GLM sont là pour t'aider. Bien à toi,
  3. Le binaire n'est pas un langage c'est un codage représentatif de deux états différents.
  4. Je ne pense pas que ruby soit un bon choix, sa syntaxe est facile c'est vrai, c'est souvent l'argument qui revient avec ce langage. Mais en contre-partie, Ruby c'est la politique du tout-objet, même un bête entier est un objet. Aucune distinction pour le débutant entre type primitif et type composé alors que c'est une notion de base propre à beaucoup de langages.
  5. Non le C n'est pas pertinent, apprendre le langage C comme premier langage est une vieille tradition de l'éducation car à l'époque celui-ci était couplé à l'apprentissage des processeurs, ce qui permettait de rapidement comprendre certains concepts comme les pointeurs qui est un adressage indirect à registre. C'était efficace à l'époque, aujourd'hui ça n'est plus pertinent. Quand on veut apprendre la programmation, il n'y a rien de pire que se focaliser sur le langage en lui-même plutôt que sur le fait de programmer. Programmer c'est créer une succession d'algorithme pour obtenir une sortie S à partir d'une entrée E. C'est cet aspect qui intéresse le débutant. C'est généralement avec l'âge et l'expérience que les guerres de religions arrivent ( ). Or le C pose trois problèmes au débutant : - La syntaxe du C n'est pas la plus facile. Ca peut paraitre stupide comme ça mais le débutant fait beaucoup d'erreur de syntaxe et le problème principal est qu'il va passer plus de temps à être conforme au langage qu'à se focaliser sur l'objectif de son programme. - Le C est bas-niveau, il faut tout effectuer soit-même. - Il faut gérer ses ressources en C, le débutant qui va se retrouver avec un SEGFAULT sans connaitre gdb/valgrind, il va passer du temps à comprendre son bug. Pour résumé, l'étudiant n'a-t'il pas plus intérêt à se concentrer sur le but de son programme plutôt que sur le langage en lui-même ? En tout objectivité, je pense que Python est un très bon élément pour démarrer, la syntaxe est simple, le langage est de haut-niveau. PS: PHP n'est pas un langage non-typé, son typage est faible et dynamique. PS2: Il ne faut pas voir l'assembleur comme un langage à apprendre mais comme un élément pour comprendre le fonctionnement d'un processeur.
  6. Il faut distinguer deux sortes de pseudo-code. Il y a le pseudo-code qu'on qualifie de "language-agnostic", c'est par exemple celui que l'on va retrouver sur Wikipedia comme le qsort ou dans la référence en algorithmique Cormen et qui sert de base commune car facilement traductible dans n'importe quel langage de paradigme impératif. Même s'il n'existe pas de syntaxe universelle, un pseudo-code de ce genre se doit d'être précis car l'audience est publique. Et il y a le pseudo-code qu'on va écrire sur sa feuille de papier pour résoudre un problème. Cette fois-ci, c'est plus personnel, c'est pour poser à plat les idées que l'on a en tête, parfois ça sera du code, le but n'est pas de faire un joli pseudo-code mais plutôt de comprendre la problématique derrière, parfois ça ne sera même pas du code mais juste des schémas. Dans les deux cas, oui, il est utile d'écrire un pseudo-code.
  7. int main(void) { int error = 2; int message = 0; if (error == 1) { message = 1; } else if (error == 2) { message = 2; } else { message = 3; } return 0; } % gcc -m32 -O0 -S if.c ... LCFI1: subl $16, %esp movl $2, -4(%ebp) movl $0, -8(%ebp) cmpl $1, -4(%ebp) jne L2 movl $1, -8(%ebp) jmp L7 ... Dans un tel cas, il ne faut jamais coder en fonction de ce que le compilateur va penser, de toute manière, le compilateur effectue toujours des optimisations à tel point que ton code de base est méconnaissable à travers ton assembleur. Pour moi la question du switch ou if ne se pose pas, un switch c'est pour énumérer les différentes possibilités d'une variable dans un ensemble et dans un tel cas, c'est très lisible et ça permet de borner facilement ton code, au delà, c'est incompatible. Jul > si tu n'aimes pas les break, tu peux toujours faire : switch(a) { case 1: { ... } case 2: { ... } }
  8. Juste un petit mot sur vos codes, ils ne respectent pas le principe d'extensibilité. $message = ($_GET['error'] == 1) ? 'Veuillez...' : 'L\'envoi..'; switch ($_GET['error']) { case 1: $message = 'Veuillez remplir le formulaire...'; break; default: $message = 'L\'envoi a échoué...'; } On a déjà error=1, error=2, que se passe-t'il avec vos solutions si j'introduis un error=3 ? Il faut complètement modifier le premier code car la condition ternaire ne fonctionne plus et faire des modifications dans le deuxième. Une solution comme : switch ($_GET['error']) { case 1: $message = 'Veuillez remplir le formulaire...'; break; case 2: $message = 'L\'envoi a échoué...'; break; // case 3: ... si je décide d'ajouter une troisième erreur, etc default: // gerer ce cas ou non } Est bien adaptée à ce genre de cas car rapidement extensible. Bien sûr pour un code comme ça, ce sont des petites modifs mais projetez vous dans un code de production bien plus massif, pensez toujours à faire un code rapidement extensible, vous allez gagner beaucoup de temps.
  9. En même temps, on ne va pas blâmer les bases NoSQL de ne pas supporter ACID. Si le mouvement NoSQL était là pour s'affranchir du modèle relationnel, ça l'était aussi pour se détacher de l'ACID-compliance car évidemment ça a des coûts à tous les niveaux (coûts logiciels, coûts de performance, etc). Après libre à chaque projet de proposer des transactions ACID. Je suis d'accord pour le reste, NoSQL n'a jamais été là pour remplacer SQL. NoSQL va peut-être même disparaitre progressivement car la recherche progresse et un mouvement dit "NewSQL" pointe le bout de son nez ou même quand on voit les progrès de l'industrie comme F1 de Google proposant un RDBMS distribué aussi scalable et performant qu'un NoSQL. Je ne connaissais pas neo4j mais j'imagine aussi grandement les coûts pour une base de données distribuée fournissant des transactions ACID.
  10. Bonjour à tous, je ne pense pas qu'il y ait de solution universelle au niveau de noSQL, tout dépend de ton data model. MongoDB est *document-oriented* tandis que redis est un *key-value store*, Cassandra est *column-oriented* et a rapidement implémenter MapReduce pour le traitement massif de données. Sinon actuellement j'étudie Kyoto Cabinet, c'est pas vraiment pour une utilisation, c'est seulement pour m'en inspirer afin de coder mon propre NoSQL.
  11. J'utilise zsh, L'embarqué sous Linux peut utiliser ash pour des besoins d'espace. Il est d'ailleurs utilisé par BusyBox.
×
×
  • Create New...