• chevron_right

      Auto Codebase Documenter – Pour documenter automatiquement votre code Python

      news.movim.eu / Korben · Tuesday, 12 September, 2023 - 07:00 · 2 minutes

    Qui n’a jamais eu la flemme de documenter son code ?

    Auto Codebase Documenter est un outil que vous allez adorer puisqu’il tire parti de la puissance de GPT-3.5-turbo ou GPT-4 d’OpenAI pour évaluer et documenter automatiquement le code que vous avez pondu !

    Génial non ?

    En gros, au lieu de passer des heures à documenter la structure et les fonctionnalités de votre projet, vous allez pouvoir profiter des derniers beaux jours de l’année puisque l’outil s’occupe de tout pour vous. Pour paraphraser Sun Tzu dans L’Art de la guerre : « La meilleure documentation est celle qui se génère toute seule. »

    Pour commencer à utiliser Auto Codebase Documenter, il suffit d’installer le package depuis PyPI via la comande pip comme ceci :

    pip install auto-codebase-documenter

    Vous devrez également configurer un environnement Python approprié. Je suggère fortement d’utiliser un environnement virtuel (venv) . Voici comment procéder :

    1. Installez Python 3.9.16 ou supérieur.
    2. Vérifiez votre version de Python en exécutant python --version ou python3 --version .
    3. Créez un environnement virtuel dans le répertoire racine en utilisant la commande python -m venv venv .
    4. Activez cet environnement avec « source venv/bin/activate » (Unix ou MacOS) ou « venv\Scripts\activate » (Windows).
    5. Installez les dépendances nécessaires via la commande « pip install -r requirements.txt « .

    N’oubliez pas, vous aurez également besoin d’une clé API OpenAI pour exécuter des requêtes sur leur modèle IA.

    Une fois que vous aurez installé et configuré tout ce dont vous avez besoin, il sera alors temps de laisser Auto Codebase Documenter faire sa sorcellerie ! Vous pouvez l’utiliser en ligne de commande ou directement sous la forme d’une lib pour votre projet. Importez simplement la classe AutoCodebaseDocumenter et lancez-la avec la méthode process_all_files .

    import os
    from dotenv import load_dotenv
    from auto_codebase_documenter.AutoCodebaseDocumenter import AutoCodebaseDocumenter
    
    load_dotenv()  
    openai_api_key = os.getenv("OPENAI_KEY")
    
    documenter = AutoCodebaseDocumenter(openai_api_key)
    documenter.process_all_files()

    Et voilà, l’outil s’occupera du reste!

    Vous pouvez personnaliser le processus de documentation en éditant le fichier documenter_config.yaml et y modifier différents paramètres tels que le chemin d’accès au code, les dossiers à ignorer, les types de fichiers à inclure, et bien plus encore.

    Une des meilleures choses à propos de cet outil est la manière dont il organise et structure les fichiers Markdown (.md) générés dans un répertoire dédié appelé docs . La structure du répertoire « docs » reflète exactement celle de votre projet. Ainsi chaque fichier traité correspond à un fichier Markdown spécifique ! Cela fait gagner énormément de temps et facilite évidemment la lecture et la compréhension de votre projet.

    Ainsi, avec une documentation aussi claire et bien organisée, tout nouveau développeur rejoignant votre projet pourra se mettre au boulot beaucoup plus rapidement. Et pour les développeurs chevronnés qui souhaitent se lancer dans un processus de révision de code ou de refactoring, cela rendra les choses vraiment plus simples niveau compréhension.

    Enfin, pour ceux qui aiment travailler avec Docker, il suffit d’utiliser les fichiers Dockerfile et docker-compose.yml fournis, et construire le conteneur en utilisant la commande bash build_docker.sh . Vous pourrez ensuite l’exécuter avec la commande bash run_docker.sh .

    À découvrir ici

    • chevron_right

      Revivez l’expérience des anciens geeks avec PCjs

      news.movim.eu / Korben · Friday, 31 March, 2023 - 07:00 · 1 minute

    Mis au point par Jeff Parsons qui a eu le plaisir de découvrir l’informatique dans les années 70/80, PCjs est un code en javascript qui est capable d’émuler toute une série de matos et de logiciels comme la calculatrice TI-57, le premier Space Invaders (1978), évidemment Multiplan d’IBM (1982), Windows 1.0 jusqu’à 95 ou encore des jeux comme Wolfenstein 3D (1992) ou Dune II (1992).

    Cela va vous permettre de vive l’expérience de ces vieux coucous avec leurs CPU ultra pas rapides, des sons bippés à couper le souffle et leurs interfaces hautes en couleurs, tout ça sans avoir à quitter votre navigateur. Et oui car tout est accessible directement via ce site : https://www.pcjs.org .

    PCjs - émulateur de système d'exploitation vintage des années 80

    L’idée évidemment est de préserver un petit peu de ce patrimoine informatique et logiciel et bien sûr de se faire plaisir sans galérer à retrouver de vieilles disquettes ou même un logiciel de virtualisation compatibles.

    Voici tout ce que vous allez expérimenter sur PCjs :

    • Calculatrice programmable TI-57 (1978)
    • Ohio Scientific Challenger 1P (1978)
    • Space Invaders (1978)
    • Microsoft Adventure (1981)
    • DONKEY.BAS de PC DOS 1.00 (1981)
    • VisiCalc (1981)
    • Multiplan 1.0 (1982)
    • Executive Suite (1982)
    • PDP-11/70 avec RT-11 4.0 (1982)
    • CP/M-86 (1983)
    • COMPAQ Portable avec graphiques monochromes (1983)
    • Zork I: The Great Underground Empire
    • Exploring the IBM Personal Computer (1983)
    • Adventures in Math (1983)
    • Lotus 1-2-3 (1983)
    • Norton Utilities 2.0 (1983)
    • Fantasy Land EGA Demo (1984)
    • Microsoft Word 1.15 (1984)
    • Nine Princes in Amber (1985)
    • Rogue (1985)
    • Microsoft Windows 1.0 (« Premiere Edition »)
    • Microsoft Windows 1.1 sur CGA (1985)
    • Microsoft Windows 1.1 sur EGA (1985)
    • Balance of Power (1985)
    • IBM OS/2 1.0 (1987)
    • VGA Black Book Tests (par Michael Abrash)
    • Microsoft Windows/386 2.0 (1987)
    • Microsoft QuickPascal 1.00 (1989)
    • Microsoft Windows 3.0 (1990)
    • Life & Death II: The Brain (1990)
    • The Oregon Trail (1990)
    • Commander Keen (1991)
    • Wolfenstein 3D (1992)
    • Dune II (1992)
    • Microsoft Windows 3.1 (1992)
    • Microsoft Windows 95 (1995)
    PCjs - simulateur de machine de bureau MS-DOS et Windows 3.0

    Toutes les sources du projet sont sur Github et vous pouvez contribuer. Chacune de ces machines est codée entièrement en javascript et utilisent un format XML qui défini les composants à activer ou non, donc vous pouvez aussi vous approprier le truc et créer vos propres machines assez simplement.

    • chevron_right

      I think I just ported CCLDOC outside CCL.

      Michał "phoe" Herda · Sunday, 23 December, 2018 - 11:57

    (This is a repost of an old blog post of mine from Teknik.)

    #common-lisp #ccl #clozure #ccldoc #documentation

    To quote the CCLDoc manual:

    CCLDoc is a system for creating lisp documentation. It uses s-expressions to represent document structure, markup, cross references, and contents. It has a small number of basic operators, supports macros for syntax extensions, and supports a simple syntax for embedding expressions in strings for added convenience.

    This screenshot is still very very fresh. I will be now pushing the required patches to CCLDOC, testing it on more implementations and creating a Quicklisp-installable package.

    And maybe, one day, I will clean up the giant mess that the CCL-COMPAT system is.

    • chevron_right

      Common Lisp UltraSpec - Progresslessness

      Michał "phoe" Herda · Sunday, 23 December, 2018 - 11:49 edit · 4 minutes

    (This is a repost of an old blog post of mine from Teknik.)

    #ultraspec #clus #common-lisp #documentation

    Foreword/Confession

    tl;dr I have started the Common Lisp UltraSpec project some time ago. I am responsible for it being stuck in place.

    When I started the CLUS, as a one-man project back in 2016, I have never expected that it would generate so much, how do you say it in English. Echo? Answers? Agreement? Need, hidden by years of being stuck to the CLHS? I don't exactly know, but even at the European Lisp Symposium 2017 I presented CLUS at, I got multiple offers for help and support, even financial. It was obvious that the Lisp world in 2017 needs such a project

    Then real life came. I don't really want to excuse myself in this blog post since I could have organized my life better and worked on CLUS easier, but I needed to straighten out multiple things that required attention. I also needed to rest, relax and reorganize larger chunks of my life - CLUS as a project was pushed aside, in a very messy, unfinished and, lo and behold, undocumented state.

    Thanks to Michael Fiano, who prodded me back into life, I have decided that it's been enough time of not accepting help from all the people who offered me their help with CLUS. It's time to make this project fully alive again.

    I hereby offer this short writeup as something that describes the current state of CLUS and will, along with my further work, serve as a basis of pulling the UltraSpec out of the stagnancy that I allowed it to slip into.

    TODO

    Diffs

    tl;dr What are the differences between CLUS text and dpANS3 text?

    One of the weak points of my process of converting TeX into DokuWiki markup was - I fixed various things and tidbits along the way. This means that CLUS right now is perhaps better documentation but it is no longer consistent with the specification, as there are differences at unknown points in text compared to the original text. It had become a task to find and list these differences.

    Thanks to the monumental work by Kamil Ziemian and Ricardo M. H. da Silva, the diff files have been generated and are now being reviewed, with the differences listed. Thanks to this effort, we might soon have this subtask done.

    Format

    tl;dr What format should CLUS use for its data?

    One of the questions after my ELS talk was, is there a formal grammar for the DokuWiki format. Obviously, there's not, and the format itself is good enough for displaying things on DokuWiki, but quite bad for everything else. It is a combination of the original DokuWiki format and some ugly hacks that I have made to display it the way I wanted it to.

    This format is not perfect and has its obvious flaws. I have been thinking of various formats: TeX, S-expressions, Markdown, DokuWiki, but all of them don't seem good enough for the job. Perhaps Markdown would work, with some extensions, but then we'd need means of parsing its extended form and displaying it on various places. The format should be advanced enough to handle displaying of monstrocities like Macro DEFSTRUCT - the single most complicated page of the specification.

    This question is open and I will be glad to accept any sensible ideas.

    Displaying engine

    tl;dr How should CLUS be displayed to the end users?

    DokuWiki is a wiki that I use for displaying CLUS content. It is used exclusively as a displaying engine that also has a search capability. It does the job, but is not perfect, and most notably, requires us to use DokuWiki format for the text files.

    Are there any better ones around?

    What next?

    tl;dr What should be done after finishing the CL part of CLUS

    As someone on Lisp Discord noted, the sidebar of CLUS contains a lot of topics that are not related to the CL standard - libraries, extensions, substandards, implementations, books. I originally imagined CLUS to be an effort to collect information from the whole Common Lisp universe. Obviously, we first need to finish CL in order to have a foundation, but my dream was CLUS unifying various pieces of documentation from all over the Lisp universe.

    Decisions and conclusions

    Live chat

    We obviously need means of organizing work by means of a live chat where we can discuss matters

    Courtesy of lonjil, we have linked the #clus-general channel of Lisp Discord server and #clus @ Freenode, so it is possible to discuss work both on IRC and Discord. This is where I have decided to settle for CLUS-related discussion.

    You're invited.

    Splitting of work

    There are several areas in which CLUS needs help - outlined above in the TODO section. I do not want to organize how work should be split among willing people in this post, as it's much better discussed live, on the IRC/Discord channel linked above - and that's what I'd like to focus on during the next few days.

    Follow-up

    I will write more on the topic in 48 hours from now. (lonjil, prepare your killswitch.)