dzecniv a écrit 458 commentaires

• https://nest.pijul.com/pijul_org/pijul
• trouvé aussi https://github.com/8l/pijul vieux de 2 ans, avec lien vers le site mais… projet en Ocaml.

Quoiqu'on pense, étant donné la hausse extrèmement soudaine de la moyenne des températures sur terre depuis le début du siècle comparé à l'évolution depuis la dernière ère glaciaire, autant prendre la question de réduction des émissions au sérieux:

Évolution de la température moyenne sur terre depuis la dernière ère glaciaire il y a 22 000 ans

dsl pour la méga image, elle vaut le coup je pense :)

Serait-ce Ubuntu dont les ventes explosent en Chine ? 

Apparemment Dell y vend 42% de ses PCs avec Ubuntu Kylin (http://thevarguy.com/open-source-application-software-companies/091515/ubuntu-linux-based-open-source-os-runs-42-percent-dell-pc).

Ou alors une "petite" municipalité passe son parc sous linux et bim, on a notre chiffre.

Bien sur. C'est une aberration de vouloir faire pousser des plantes en dehors de la saison.

oui bien sûr. Va lire l'article, tu comprendras. En fait ils ne font pas (ou très peu) pousser de patates ou de choux.

Vu le travail de recherche effectué par ces sociétés je trouve normal qu'elles protègent le fruit de leur travail.

tu t'en fiches des OGM et des graines non reproductibles et de Monsanto qui impose tout ça, comme pour le coton au Burkina Faso, avec des effets désastreux sur l'indépendance des paysans ET sur les cultures ?

Le jeu des Lobby a fait qu'on les a laissé aller beaucoup trop loin (comme d'hab).

c'est plus compliqué, et "les lobbies" sont concommitant de la construction des administrations: cf par exemple https://agone.org/lordredeschoses/lescourtiersducapitalisme/

Attention étonnamment malgré la présence rassurante de l'INRA l'étude du Bec Hellouin comportent plein de biais qui gonflent les chiffres. Au final, ils ne sont pas si mirobolants: http://www.barricade.be/publications/analyses-etudes/permaculture-maraichage-biologique-un-choix-economiquement-interessant

Par exemple, mais ce n'est pas exhaustif:

• la surface étudiée ne compte pas les allées, aires de compostages et bâtis: pour cultiver 1 000m2 comme le dit l'étude il faut bien le double
• leur chiffre d'affaire équivaut à la valeur récoltée, qui est pour certains produits seulement estimée, et au meilleur prix possible
• pour eux la productivite égale la valeur récoltée, ce qui est faux, et ce qui est calculé bizarrement
• ils cultivent surtout des tomates et autres légumes de saison à fort valeur ajoutée, peu de choses pour l'hiver qui prend plus de temps à pousser
• ils ont une forte charge de travail gratuite par des stagiaires
• la ferme génère beaucoup de revenus par des formations payantes
• la ferme n'a pas de prêts bancaires ou autres investissements à rembourser, elle a été créée avec le fonds personnel des créateurs qui viennent d'une autre activité
• etc

C'est exact, il y a même un livre: http://leseditionsduboutdelaville.com/index.php?id_product=6&controller=product (pas lu, mais j'ai aimé d'autres livres de cette maison d'édition, notamment "Le Ménage des Champs")

des décorateurs, qui en gros sont aussi puissants que les macros Lisp

ah là non, je ne suis pas du tout d'accord !

De nombreux langages et concepts modernes n'existaient pas à l'époque

de nombreux concepts de lisp ne sont pas présents dans les languages aujourd'hui, tels que Python: le modèle objet (méthodes génériques,…), les hooks ("advice"), la méta-programmation riche (les fameuses macros) (Python avec ses décorateurs et "with statements" fait pâle figure), le fait d'avoir une "lisp machine" est énorme, les reader macros (modification du reader, qui lit le code source, pour créer une nouvelle syntaxe), l'inférence de types, créer une image exécutable standalone, désassembler une fonction, plus d'orientation objet, les closures,… (Cf mon commentaire https://linuxfr.org/nodes/112513/comments/1711088)

mais pas sûr que elisp serait choisi sur un autre lisp, oui.

Emacs en Rust ? Remacs ! https://github.com/Wilfred/remacs où Rust remplace le C, lisp inchangé. (cf mon commentaire plus bas sur lisp VS python)

Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.

J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,…). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.

Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.

Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,…).

Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).

c'est justement which-key !

M-x which-key-mode
et voilà !

t'as des solutions ici: https://www.reddit.com/r/emacs/comments/3ucnnx/trying_out_spacemacs_without_messing_with_my/ et ceci marche pour moi:

$ cd
$ mkdir fakehome    
$ git clone --recursive https://github.com/syl20bnr/spacemacs ~/fakehome/.emacs.d
$ env HOME=/home/andreas/fakehome/ emacs

ou tu utilises un mode fait pour le live preview: http://wikemacs.org/wiki/Markdown#Live_preview_as_you_type :)

Question: en utilisant spacemacs, j'observe que des fois dans les aides emacs ça diffère un peu. Est-ce que tu penses que ça reste superficiel, ou alors y a des domaines où c'est fondamentalement différent ? (si tu connais un peu spacemacs bien sûr).

euh alors ce devrait être des différences superficielles, du genre raccourcis claviers (évidemment) ou moyens de configurer les différents modules en elisp, auquel cas si ça diffère de la doc officielle c'est pas grave (j'ai pas utilisé spacemacs (evil-mode bien sûr !) (mais j'ai un peu regardé sa config) donc des exemples seraient bienvenus).

En tout cas merci encore pour wikemacs, ça va peut-être me garder définitivement dans emacs (ou plutôt spacemacs) !

ça c'est cool ça :) Je rappelle qu'un wiki est ouvert aux contributions et que petit à petit le "noob" construit des pages utiles ;) (la preuve)

Il y a des milliers de fonctions possibles. Des raccourcis (et un menu) ne suffisent pas.
Il peut y avoir plein de solutions ; certains packages offrent d'ailleurs des idées.
A mes yeux si Emacs veut être utilisatble "out of the box direct t'as vu"; il faut absolument montrer à l'utilisateur à quelles fonctions il a accès.

c'est sûr, mais on peut s'en sortir je pense: avec which-key, avec un dashboard de bienvenue (https://github.com/rakanalh/emacs-dashboard), avec un smex ou counsel-M-x (https://github.com/abo-abo/swiper) à la place de M-x pour avoir comme une palette sous d'autres éditeurs, et avec des hydras (https://github.com/abo-abo/hydra/) et l'interface à la magit: un "menu" interactif montre les sous-commandes accessibles en une touche. C'est super efficace !

Oh à propos de journal, j'avais raté ton précédent sur Common Lisp, il est excellent, j'y ai appris plein de choses, merci. Je suppose que tu connais Parens of the Dead mais je pose ça ici quand même.

yes merci, suis ravi. Avec encore un peu d'abnégation il y aura une suite plus complète :) En tout cas récemment c'est le lisp cookbook qui a pris un coup de jeune (et il en avait bien besoin).

Nan je connaissais pas Parens of the Dead car je suis pas trop dans Clojure, même si pour le web couplé à Clojurescript ça a l'air bien efficace.

ce truc devrait être installé et activé par défaut

aujourd'hui je me dis ça pour les Hydras ! (et blog)

salut, très intéressant retour d'expérience merci :)

Par contre le truc horrible je trouve, c'est trouver des ressources, pour débutant, pour configurer des trucs comme l'auto-complétion, le checking du code etc… En gros ce qui permet de s'approcher d'un IDE

Je vais naturellement sur cette page (https://www.emacswiki.org/emacs/PythonProgrammingInEmacs)

comme je comprends. Partir de zéro demanderait de chercher beaucoup de paquets et de copier-coller pas mal l'elisp. Mais toi tu as commencé avec Spacemacs. Or donc tu n'as pas trouvé la config pour Python (python layer) satisfaisante ?

De plus: je n'ai jamais aimé emacswiki. Je trouve que c'est un mauvais wiki qui ne retient pas les utilisateurs (s'il ne les fait pas fuir). Que penses-tu de cette page wikemacs sur Python ? http://wikemacs.org/wiki/Python Wikemacs est un "vrai" wiki (mediawiki). Il fut lancé par B. Batzov (Prelude, Projectile,…) mais devant le "refus" de la communauté il a laché l'affaire. Heureusement le wiki a été repris par d'autres et il vit toujours. Mais il n'est pas encore aussi bien référencé que emacswiki, encore que pour quelques bonnes pages ça passe.

Je ne pense pas que parler des wikis rentre vraiment dans l'objectif de emacs-oob-reboot, mais avec l'appui de ton témoignage je tenterais bien le coup…

et après c'est des trucs techniques.

là ça m'intéresse de savoir ce que tu entends par là. Qu'est-ce qui est trop technique ? Trop détaillé ? Trop d'elisp ?

ps: c'est ça kakoune ? http://kakoune.org/ Je comprends pas ce que tu cherches.

On a une équipe qui est venue parler de Tuleap ici, mais il n'est évalué dans aucun des cas :/ C'est juste un manque de notoriété ?

Emacs aussi va certainement pas forcément totalement passer à Gitlab, mais l'utiliser, notamment pour la CI: http://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00592.html

Pas sûr du tout qu'ils abandonnent le fonctionnement par mail, ça a quelques avantages (pour les gros projets seulement ?) https://lwn.net/Articles/702177/

+: https://www.reddit.com/r/emacs/comments/6nlsjz/emacs_dev_gnu_savannah_vs_gitlab/

Les tâches périodiques ont existé et devraient bientôt revenir, c'est réparé: https://gitlab.com/gitlab-org/gitlab-ce/issues/30882 avec ça pas (plus) besoin de cron.

Salut,
Merci pour les exemples ! J'aimerais bcp arriver à me servir de Nix ou Guix pour du dév de projets python/web. Sais-tu si c'est facilement possible à l'heure actuelle ?
J'aimerais donc:

• installer les paquets python définis dans les fichiers "requirements.txt", à la bonne version (y a-t-il tous les paquets de pypi dans toutes les bonnes versions dans Nix ? Comment fait-on ?)
• installer les paquets provenant de npm, encore dans la version spécifiée .
• installer des paquets système, là ça a l'air d'aller.

Des articles pour comprendre les enjeux (avec Guix):
https://blogs.rdoproject.org/7843/guix-tox-a-functional-version-of-tox
http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-195/Python-un-environnement-vraiment-isole-avec-GNU-Guix

peut être peut-on utiliser une méthode hybride, où on spécifie les dépendances systèmes, y compris les dépendances de certains paquets pip et js (C headers,…), et où on installe les autres paquets avec pip et yarn dans un environnement Nix isolé ("conteneurisé") ?

Salut,
Merci pour l'article c'est cool et ça donne des choses à montrer aux ami-es qui gèrent de petites ou moyennes publications sans l'utiliser.
Tu as donc dit que venant d'Adobe c'est pas évident et qu'il y a de la marge pour l'améliorer: j'aimerais donc bien savoir quels ont été vos difficultés et comment vous les avez dépassées: était-ce des fonctionnalités dures à trouver que vous avez dénichées, avez-vous reposé sur des articles de blog, de la doc ? Y a-t-il des choses vraiment plus chronophages ? Y a-t-il aussi des points forts ? Merci encore.

il ne retrouverait pas dans Dokuwiki le très pratique système de gestion en catégories de Dokuwiki

je suppose "… le très pratique système de gestion en catégories de Mediawiki".

Je ne suis pas sûr de trouver pertinent l'usage des catégories de Mediawiki. Voici mon usage et mon avis. Sur la doc ubuntu j'aime bcp les pages récapitulatives sur un sujet global, qu'on trouve par la page d'accueil, et qui envoient vers des pages plus précises. Par exemple: https://doc.ubuntu-fr.org/graphisme :

• on peut voir une table des matières
• la page est divisée en sections
• chaque item possède une description, avec le lien vers sa page
• cette description contient éventuellement d'autres liens: vers wikipédia, une discussion ailleurs, etc

Or on ne peut pas avoir tout ça sur une page Catégorie, par exemple https://fr.wikipedia.org/wiki/Catégorie:Éditeur_d'image_matricielle Tout est bêtement rangé par ordre alphabétique et on n'a aucune info sur l'item. Donc l'utilisateur doit cliquer sur chaque lien pour lire sa description ??

J'utilise et édite pas mal le site wikemacs. Une page thématique sans catégorie serait la page http://wikemacs.org/wiki/Buffer_management Tout est là. Je n'hésite pas à rediriger vers la page du projet spécifique. Une page Catégorie, sur un sujet très similaire pour comparaison, serait http://wikemacs.org/wiki/Category:Buffer_Navigation On n'a aucune idée de ce que font ces projets.

Mes 2 centimes :)

Développeurs Python ouvrez grand vos yeux ! La stack utilisée n'est pas répandue et très intriguante. Kansha est basé sur le framework Nagare (¡ erreur 500 sur http://www.nagare.org/trac/wiki/NagareTutorial !), basé sur Stackless Python. Nagare est basé sur les continuations et promet le développement d'applis riches tout en python, sans écrire de html (sauf si on préfère), ni de javascript, y compris pour les appels ajax, ici transparents (pas de double-data binding), et permet(trait) d'écrire une appli web "comme une appli de bureau".

Un éternel recommencement, trop d'abstractions ? On en a discuté ici: https://linuxfr.org/users/dzecniv/journaux/kansha-clone-de-trello-ecrit-sans-une-ligne-de-javascript-ajax-compris-avec-le-framework-nagare