Morn!
Morn!
mårn
Morn!
Morn!
@hypirion driver du og argumenterer for Python og ikke Babashka for scripting???
Man må lære seg å krabbe før man kan gå 🙂
jeg er for øvrig enig i argumentene dine. Det er veldig praktisk at Python allerede er installert! Gratulerer med Hacker News-forside!
Så kan du bruke Python i Clojure etterpå 😄
Link?
Beklager, tenkte på artikkelen på HN 😊
Ah, lol! My bad.
Oi, ante ikke at den var på HN 😅 Delte den på http://lobste.rs da, men det er en stund siden
Jeg brukte nesten utelukkende Bash og Python til scripting en stund før jeg lærte om Babashka. Det jeg liker best med Babashka er at jeg kan skrive kode som funker på Linux, Mac og Windows, og distribuere dem som én selvstendig fil til ikke-tekniske brukere, som de kan kjøre uten å installere eller konfigurere noe spesielt. Jeg synes også virtuelle miljøer, pip vs. conda, etc. var ganske fiklete i Python.
Men Python er et veldig nyttig språk som mange folk kan. Vi bruker det masse der jeg jobber nå.
Jeg synes Python-systemet er helt jævlig. Jeg mister helt sted og retningssans når jeg må installere noe som krevs av et eller annet skript eller app som benytter python. Men det er først og fremst fordi jeg ikke har peiling 😄
https://docs.astral.sh/uv/ har løst disse utfordringene for meg
Kult, takk!
Ah, nice! Enda en 😅 Tror jeg har testet så og si alt annet, men har ikke sett uv før nå.
I Elkjøp brukte vi https://python-poetry.org en stund. Det funka greit men var ekstremt treigt.
Nå er primærargumentet mitt at du helst ikke bør legge til eksterne avhengigheter før du må, og Python er stort og stabilt og vil ikke brekke koden din med det første. Om du er en Clojuresjappe kan du bytte ut Python med bb uten mye klaging vil jeg tro.
Jepp! Jeg byttet ut mange Shell scripts og Python scripts i Elkjøp med Babashka uten å be om lov, og viste det frem til teamet. Fikk med meg to andre karer på laget, men resten var nokså skeptiske.
> Python er stort og stabilt og vil ikke brekke koden din med det første (venter i spenning på Python 4)
https://www.modular.com/mojo has entered the chat "Did someone say Python 4?" 😎
Relevant tråd fra 2023 https://clojurians.slack.com/archives/C16LEKSLT/p1688375751525319.
Ikke hørt om Mojo før. Veldig interessant! Basert på det store AI-fokuset så kan jo det være at dette blir defacto ai-språk på sikt. Så fremt AI lærer så skrive python da 😆 (har ikke det vært et problem, på lik linje med lisp? eller tar jeg helt feil nå)
Jepp! Tanken er at all Python-kode bare skal funke uten endringer i Mojo, som et "true superset" av Python, slik at alle som kan Python kan bruke Mojo umiddelbart og velge å gradvis ta i bruk nye features som de ønsker å bruke. Så kjører all Python-kode brutalt mye raskere når kompilert via Mojo enn dynamisk i Python sin egen runtime/VM.
Veldig fin artikkel, @hypirion. Og takk for tipset om deprecation warnings!
import warnings
warnings.simplefilter("default", DeprecationWarning)morn!
Morn!
Morn!
Morn!
Morn!
Morn!
Kode er data, og data er ❤️
FAIL in kjokkenet.i18n-test/dictionary-test (m1p_helper.clj:90)
i18n-oppslagene henger på greip med ordbøkene
src/matnyttig/skjemaer/adresse.cljc: :matnyttig.skjemaer.adresse/linj1-aria-label på linje 44 finnes ikke i en ordbok
Dette er resultatet av en ny test vi har. Vi har nylig lagt til i18n i løsningen vår, ettersom vi skal ut og henvende oss mot offentligheten. Da er det greit å unngå at man bruker en i18n-nøkkel som ikke finnes i ordboka. Det oppdager denne testen, sammen med en del andre måter man kan gjøre i18n feil på. Og hvordan? Jo, ved å laste inn all koden vår som data, tree-seq for å finne alle i18n-placeholderne, og validere bruken mot ordbøkene våre. 90 linjer kode. Data ass ❤️De greiene der høres litt ut som en egen implementasjon av GNU gettext @leif.eric.fredheim. Mulig at gettext er for treigt, har aldri sett på ytelsen, men det er jo grunnlaget for å oversette omtrent alt på Linux. _("Her er teksten som skal oversettes.")
Ja, det er sikker noe lignende. Men denne greia vi har er koblet til eksterne selskaper som gjør oversettelser til flere språk, samt Unreal Engine via C++ kode og sånt.
Det er en del Excel filer, web verktøy og rutiner i mellom oversetterne (som vi ikke kjenner), koderne og de binære dataformatene til Unreal Engine 😅
Nice! Vi har tilsvarende opplegg i Typescript, men hvor vi genererer en typedefinisjon som er unionen av alle nøklene i ordboka. Det funker godt, med unntak av at typescript får veldig mye å tenke på ved hvert eneeste tastetrykk. (vi har 5950 nøkler p.t.)
(vi får altså typescript til å typesjekke koden vår, i motsetning til en unit-test - og det blir ganske tregt med så mange nøkler)
Nettopp 😅
Jeg lurer på hvor mange linjer med kode jeg hadde trengt å skrive for å søke gjennom typescript-koden på tilsvarende vis (via et AST) 🤔
https://github.com/tree-sitter/tree-sitter-typescript og så er du oppe og kjører. Og forøvrig er vel dette et sted man kunne brukt makroer til å validere på kompileringstid. Om du vil validere bruken mot ordbøkene er higher-order-bruk ikke noe du ønsker uansett.
Jepp, kunne brukt makroer. Den løsningen vi har nå har samme begrensning som makroer - ingen higher order i18n-oppslag. Men som du sier: det ønsker vi uansett ikke. Fordelen med løsningen vi har nå er at du slipper å strø masse makroer overalt.
i18n er et replicant-alias i vår løsning, så de ser sånn ut: [:h1 [:i18n/k ::greeting {:name "Bob"}]]
Ja, enig i at det er teit/unødvendig å gjøre den om til en makro om renderings-"rammeverket" (😇 ) du bruker har innebygget i18n-støtte du ønsker å bruke, framfor noe som er frakoblet og som må integreres inn uansett.
Cool. Jeg lurer på om vi kunne brukt noe slikt selv. Spill inneholder jo mye tekst som er oversatt til mange forskjellige språk, og vi har "text tokens" i C++ kildekoden.
I game dager lagde vi våre egne verktøy for tekst-input, oversetting og "eksportering" til spillmotoren. Men nå bruker vi no' Unreal-greier. Jeg er usikker på hvordan det funker nå faktisk. Noe jeg må sjekke ut en dag.
Vi lager fortsatt våre egne verktøy 😄
Vi vurderer sågar å lage litt Emacs-tooling for m1p 😄
Vi har en del egne verktøy fortsatt men det er for det meste på infrastruktur og lavnivå nettverksgreier og andre områder som Unreal ikke har.
Vi har en egen side i appen i lokal dev-mode for administrering av tekstene, med auto-oversetting fra engelsk til norsk og svensk via chatgpt (som kan overstyres ved adhoc). Ved manglende oversettelse logger appen en url til konsollet som man kan følge for å legge til tekstene. Kunne sikkert vært en HUD, men funker egentlig fint nok med konsoll-loggingen.
(Hadde tenkt å prøve å lage noe enda mer smidigere rett i Emacs med gptel, men idéen har forblitt på hylla siden det er bare jeg som bruker Emacs på teamet.)
Snedig!
Hallo!
Mikrobloggeriet har nå live-statistikk, takket være den supre fyren bak Datascript med mer. https://mikrobloggeriet.no/stats | https://github.com/mikrobloggeriet/mikrobloggeriet.no/commit/0e0a443ea9c3f9ae984982cfe5bf6f76ae697520
Helt sjukt å bare "få" en ting uten å nesten betale noe! Har aldri i livet fått en ekte feature gratis fra en fyr på internett, som kan installeres og rulles ut i prod på under 15 minutter.
Hvordan lagrer den data?
Lokal duckdb-fil. På application.garden får man montert opp en liten lagringsplass som man leser via en systemvariabel.
Ah, kult. Jeg har aldri brukt duckdb, er det sqlite-ish?
Jepp, kliss likt! Samme modell, minus at duckdb er kolonneorientert, som gjør at når du har en duckdb-tabell i bunnen, er det lettere å gjøre operasjoner på hele kolonner. @chris441 gjør noe ganske magisk her: https://techascent.com/blog/just-ducking-around.html "zero copy" fra duckdb inn i et datasett, som gjør at SELECT effektivt er gratis, og andre kolonner blir regnet ut først når man spør etter resultater. Ytelsen er sykt god sammenliknet med alle andre alternativer jeg vet om.
Kult! > This library was born out of a desire to have a basic understanding of my web projects’ visitors and a lack of desire to set up anything. Fint at han gjør dette for resten av oss da 😊
ja, helt supert! Han har brukt en uke, så jeg kan bruke 15 minutter. Flaks for meg!