10:15:36 Schrompf joined the channel
10:39:15 xq: moin moin
11:11:37 Schrompf: ölk ölk
11:32:14 Essex20 joined the channel
11:34:22 Essex20: moin
12:19:35 Magister joined the channel
12:53:49 IceMichael: moin
12:53:56 IceMichael: Github actions ist echt nice, v.a. hat das auch nen mac runner
12:54:05 IceMichael: mal sehen, ob ich es schaffe, meinen Kram da laufen zu lassen, das waere ultra
13:05:01 Schrompf: xq, gogogo. IceMichael, ja wär cool. Essex20, moin
13:09:09 IceMichael: was war denn mit xq?
13:09:14 IceMichael: mein bouncer sagte mir nix, kann eigentlich nicht sein
13:32:16 xq: ich glaube Schrompf feuerte mich allgemein an
13:32:20 xq: github actions ist schon nice
13:32:25 xq: hast du meine tinyvg seite gesehen?
13:54:45 IceMichael: was genau davon?
13:54:54 IceMichael: xq, und ja, aber boost f**** micht wieder in den Po
13:55:07 IceMichael: hab ne action, die das laedt, in nen Ordner packt, aber find_package findet nix...
13:55:11 IceMichael: ich verbrenn die Minuten einfach nur so
13:55:18 IceMichael: nie wieder boost...
13:56:06 xq: nie wieder CMake! :D
13:56:29 xq: IceMichael: einfach nur generell die site. ist die korrekt gerendert?
13:56:43 IceMichael: cmake find ich wiederum gut
13:56:50 IceMichael: also sobald zigbuild auch so was wie Qt kann, gut
13:56:54 IceMichael: hm, hast link nochmal?
13:57:12 xq: https://tinyvg.tech/
13:57:29 xq: Naja, Zig Build kann sowas wie Qt, es müsste halt jemand machen ;)
14:03:59 IceMichael: hat aber keiner gemacht, also bringt mir noch nix :D
14:04:07 IceMichael: und ich bau nicht infra mit, v.a. nicht bei zig, was ich nicht kann
14:04:22 IceMichael: also die HP selbst scheint korrekt gerendert zu werden oder meinst du was spezielles?
14:08:19 IceMichael: jetzt muss ich den scheiss find_package(boost) output parsen, hate
14:08:40 xq: IceMichael: ich hab nicht gesagt, dass du zig build verwenden sollst
14:08:47 xq: nur dass mir CMake fies zuwieder ist
14:08:51 xq: weil es nicht nachvollziehbare dinge tut
14:16:20 IceMichael: was genau meinst?
14:16:40 xq: woher bekommt "find_package" seine daten?
14:17:22 xq: was ich mittlerweile gelernt habe:
14:17:28 xq: ich will keine OS libraries
14:17:34 xq: wenn ich keinen expliziten opt-in dafür mache
14:20:20 IceMichael: ja, find_package nervt mich gerade auch sehr hart
14:20:32 IceMichael: ich glaube, genau DIESE Zeile ersetze ich jetzt auch
14:20:49 IceMichael: der sagt im debug output, wonach er sucht, aber die jeweiligen files findet er irgendwie halt nicht
14:24:15 IceMichael: was macht man statt boost::asio eigentlich?
14:38:33 xq: was ist boost:asio?
14:42:43 IceMichael: ich nutz es fuer threadpool
14:42:53 IceMichael: aber ja, indeed ist findpackage muell
14:45:13 IceMichael: hm, vll mal andre action probieren, die selbst boost baut
14:45:22 IceMichael: zwar bissel shitty, aber vll laesst sich das irgendwie cachen
14:51:02 IceMichael: mit etwas Glueck bin ich einfach nur hart dumm, mal sehen
14:54:16 xq: threadpooling?
14:54:19 xq: kannst du das ausführen?
14:56:04 IceMichael: hab tasks, die will ich in nen Thread schieben
14:56:14 xq: jo, dafür brauchste erst mal kein asio
14:56:17 IceMichael: Tasks selbst koennten parallel laufen, aber evtl. nutzen die auch nur einen Thread
14:56:30 IceMichael: hm ist richtig... wofuer braeuchte man denn asio, wo es nicht mit thread geht
14:56:52 xq: asynchronous i/o ist üblicherweise ohne threading
14:56:59 xq: threading ist nur der letzte perfboost
14:57:07 xq: wenn ich jetzt zig/rust/go angucken
14:58:13 xq: wenn du nur dinge in nen threadpool werfen willst:
14:58:22 xq: kombiniere queue, mutex, condition variable
14:58:30 xq: das gibt nen worker pool der keine leistung frisst, wenn nix zu tun ist
15:00:07 IceMichael: ok, hab wieder vergessen, wie man das gscheit macht, weil ich es nie nutze
15:00:22 IceMichael: ich mach so was ungern selbst, weil man ja ohne 150 IQ direkt racing conditions einfuehrt
15:00:25 xq: asynchronous I/O ist halt eher üblich mit nem zentralen i/o loop
15:00:32 xq: ach quatsch
15:00:41 xq: das funktionierend zu bauen geht
15:00:53 xq: das ganze absolut perfekt zu bauen braucht halt megaiq
15:01:08 xq: aber du wirst nicht sterben, wenn dinge halt mal µs statt ns brauchen
15:01:40 IceMichael: na ja, ich weiss gerade nicht, wie man queue/mutex/cv zusammen nutzt fuer das, was du meinst
15:01:54 IceMichael: hauptsaechlich, weil ich vergessen hab wie cv in c++ genutzt wird
15:01:54 xq: naja
15:02:03 xq: we würdest du jetzt nen task worker bauen?
15:02:05 xq: so konzeptionell her
15:02:17 xq: also nicht "wie implementiert man das in C++"
15:02:19 IceMichael: ja, die grobe Idee ist vermutlich klar
15:02:29 xq: erzähl mal, ob wir vom gleichen ding reden
15:02:31 IceMichael: also queue wird halt ueber mutex gelesen/geschrieben
15:02:37 IceMichael: cv, damit nix busy pollt wohl
15:03:04 IceMichael: man koennte dann also
15:03:15 IceMichael: mit busy polling waere es einfach
15:03:36 IceMichael: aber cv puh... also wie gesagt, hab vergessen, was cv genau macht, aber die wird wsl alarmiert, damit der wake passiert
15:03:45 IceMichael: aber dann muesse man beim push in die queue ja nen wake potentiell ausloesen
15:03:50 IceMichael: und der Teil klingt nach superhoher Fehleranfaelligkeit
15:04:45 xq: wieso?
15:04:54 IceMichael: weil das in c++ sicher nicht einfach ist
15:04:57 xq: enqueue(){ lock { enqueue } signal }
15:04:58 IceMichael: mal ref lesen kurz
15:05:02 xq: tipp: https://github.com/cameron314/concurrentqueue
15:05:11 xq: das hier nimmt 99% der arbeit ab
15:05:17 xq: damit isses nämlich einfach enqueue(item)
15:05:19 xq: und wait_dequeue
15:05:26 IceMichael: jaaa, ne lib einsetzen dafuer gut :D
15:05:32 IceMichael: das ist dann aber nicht queue/cv/mutex only
15:05:37 xq: die ist well tested
15:05:40 xq: und hat keine deps
15:05:42 IceMichael: darum geht's nicht
15:05:50 xq: sondern?
15:06:00 IceMichael: weil du meintest cv/mutex/queue reicht und ist einfach
15:06:02 xq: jo
15:06:03 xq: dann
15:06:10 IceMichael: wenn man ne lib nehmen muss, zeigt das, es ist nicht trivial, sonst gaebs ja keine lib
15:06:19 IceMichael: (ja, die kann einem bei zig andren sachen helfen, aber...)
15:06:30 xq: worker() { while(true) { wait_condvar; lock { task = deque() } doWork(task) } }
15:06:42 xq: die lib ist nur ne fucking schnelle lockfree queue
15:06:46 xq: und spart dir damit alles locking
15:07:03 xq: was in meiner lösung aber nicht geht, ist die worker zu beenden
15:07:22 xq: dementsprechend musst du hier halt ein union(task,exit) in der queue halten
15:07:31 xq: und dann am ende exit für anzahl worker enqueuen
15:07:35 xq: und danach die worker-threads joinen
15:08:29 IceMichael: das kannst du nicht ernsthaft trivial nennen alles zusammen
15:08:37 IceMichael: also keine Chance das mal schnell zu aendern
15:08:43 IceMichael: muss ich wohl beim scheiss asio bleiben
15:09:20 xq: naja
15:09:22 xq: komplex isses nit
15:09:48 xq: enqueuing ist easy, man muss sich nur einmal der reihenfolge klar sein
15:09:56 xq: und die condvar löst das eigentlich janz gut
15:10:17 xq: aber mit concurrentqueue kannste dir die condvar, den mutex und ne eigene ding sparen
15:10:25 xq: und einfach enqueue + wait_dequeue + union nutzen
15:10:28 xq: und fertsch
15:10:34 xq: sind später 30 zeilen C++
15:16:44 IceMichael: jo, aber ist ne neue lib und da muss ich erstmal Ueberblick kriegen, trust usw.
15:17:03 IceMichael: mein Projekt ist halt nicht well-tested, UT-covered usw. genug dafuer
15:17:09 IceMichael: multithreading laesst sich ja auch eh nicht gut UT-covern
15:17:25 IceMichael: und wenn was schief laeuft, fuehrt das zu bugs, die fast unmoeglich zu finden sind
15:19:01 xq: die lib ist gut, schrompf nutzt die ebenfalls aus den selben gründen wie ich sie genutzt habe
15:19:12 xq: "wir sind zu doof, die library macht das proven correct"
15:20:32 IceMichael: klingt auf jeden Fall gut, sollte ich dann kuenftig nutzen
15:20:40 IceMichael: nur geht nicht ad hoc jetzt gerade, um boost abzuloesen :D
15:20:44 IceMichael: aber na ja, hab eh auch tests laufen...
15:20:58 xq: wie viel code musst du ersetzen?
15:21:02 xq: das klang mir jetzt auch nur nach 30 zeilen
15:29:32 IceMichael: das ist ja egal, der affektierte code, der das used, ist viel
15:29:46 IceMichael: man kann 1000 einfache zeilen schreiben (ui kram) oder 30 zeilen, wo alles moegliche kaputt gehen kann
15:30:24 xq: jo, musst du wissen
15:35:50 IceMichael: versteh ich
15:36:45 xq:
15:36:52 xq: 12.5% opacity done right
15:36:57 xq: aber aktueller fall
15:37:01 xq:
15:37:03 xq: …
15:37:04 xq: …
15:37:05 xq: …
15:37:06 xq: WAT
15:37:17 xq: und ja, es ist spezifiziert, dass das bild dann implizit auch 800 breit ist
16:17:21 IceMichael: xq, lol, geil
16:17:34 IceMichael: also das erste find ich eigentlich krasser
16:17:44 IceMichael: ich haette eher gedacht, das ueberschreibt sich wegen Redundanz gegenseitg, aber gut
16:18:01 xq: sind halt nicht redundant
16:18:07 xq: ach
16:18:12 xq: hab ich schon style sheets erwähnt?:D
16:18:19 xq: du könntest auch ne externe datei noch mit einbinden
16:19:56 IceMichael: puh
16:20:01 IceMichael: na gut, svgs koennen halt echt alles
16:20:06 xq: jo
16:20:09 IceMichael: kein Wunder, dass die so saulahm zu rendern sind :/
16:20:17 IceMichael: da musst ja echt nen kompletten Browser pro File draufwerfen
16:20:22 xq: irgendwie will ichh als demo für die brokenness nen multiplayer game in pure svg bauen
16:20:28 xq:
16:20:30 xq: korrekt
16:20:35 xq: imagemagick rendert SVGs mit InkScape
16:20:46 IceMichael: und InkScape nutzt chromium?
16:20:55 xq: nope
16:20:57 IceMichael: bah, ist ja echt pervers
16:21:00 xq: inkscape ist korrekter als chromium
16:21:09 IceMichael: haben die ne eigene rendering engine gebaut? hm
16:22:07 xq: yep
16:28:23 IceMichael: gut, bei dem Produkt wuerde man die Expertise ja auch erwarten :D
16:28:48 IceMichael: aber dennoch... ich fand svgs eigentlich attraktiv, weil scaling je nach dpi eben automatisch klappt, aber...
16:29:10 IceMichael: das scheint ja jetzt eher Muell zu sein. Vll eher nen script vorher laufe lassen, dass die svgs fuer verschiedene dpis in pngs konvertiert oder so
16:29:13 xq: SVGs sind die hölle :D
16:29:24 IceMichael: nicht, dass man bei qt klar rausfinden koennte, wie viel dpi man so hat
16:29:25 xq: was glaubst du, warum ich mir hier den arsch so aufreiss
16:29:25 xq: :D
16:29:31 xq:
16:29:33 xq: ist kein Qt-Problem
16:29:36 IceMichael: hm, weiss ich auch nicht. du baust ja ein eigenes format
16:29:39 xq: ja, genau darum
16:29:50 IceMichael: und dann? du musst ja auch selbst renderer usw. dafuer bauen
16:30:24 xq: hab ich doch schon
16:30:32 xq: sind 800 zeilen code
16:31:48 IceMichael: hm, woher weiss man da denn, dass er schnell genug ist? Normalerweise wird ja alles hardwarebeschleunigt und so?
16:31:58 IceMichael: ist fuer mich wieder so ein Problem, was man alleine gar nicht loesen kann
16:33:32 xq: ich hab nen SW-renderer
16:33:41 xq: "schnell genug" ist grade noch kein use case
16:33:47 xq: aber ich werd nen vulkan-renderer bauen
16:33:54 xq: der sind eher so 2000 LOC
16:34:05 xq: und klar kann man das allein lösen
16:34:10 xq: du hast doch mal game engines gebaut
16:34:30 xq: nen TinyVG renderer ist nur n bissi stumpfe schulmathe, 2 wikipedia-artikel und n bisschen fleis
16:34:31 xq: das alles
16:34:56 IceMichael: ja, aber dann gibt es sicherlich zig Forschungspaper und Abkuerzungen, die sau-smart sind, um es zu beschleunigen
16:35:01 xq: nö
16:35:05 xq: völlig unnötig
16:35:20 IceMichael: also wenn ich meine Qt-Anwendung oeffne, ist die in jeder Hinsicht zu lahm
16:35:25 xq: ja
16:35:26 IceMichael: und rendern ist ein grosser Punkt
16:35:27 xq: weil du SVG nutzt
16:35:29 xq: und nicht TVG
16:35:34 IceMichael: hm, es ist nicht nur das
16:35:37 xq: SVG rendern ist über-komplex
16:35:43 IceMichael: ich hab die svgs mal alle gekickt, es war dennoch saulahm
16:35:44 xq: das komplexeste in diesem ganzen scheiß ist nen ellipsensegmentrenderer
16:35:52 xq: und der ist noch kaputt
16:35:54 IceMichael: oh, wie klappt der?
16:35:55 IceMichael: oje
16:35:57 xq: weil ich die mathe nicht auf die reihe bekomme
16:36:15 xq: da wärst du wahrscheinlich fitter
16:36:24 xq: joeydee und Schrompf sowieso
16:36:58 IceMichael: na ja, aber das ist es halt, Mathe wird ja unendlich kompliziert
16:37:24 IceMichael: gut, aber dein Punkt ist, TVG ist so viel weniger komplex, dass SVG selbst mit groesster Optimierung dagegen abkackt
16:37:28 IceMichael: das ist plausibel
16:38:14 xq: wie gesagt
16:38:24 xq: das einzige komplexe ist der ellipsen-segment-renderer
16:40:03 xq: was du dann noch brauchst ist nen polygon- und linienrenderer
16:40:04 xq: und das wars
16:40:12 xq: polygone sind trivial auf der gpu
16:40:22 xq: "mal mal diese polygone" ist relativ einfach üblich :D
16:41:05 IceMichael: ich denk, du bist cpu?
16:41:17 xq: jop
16:41:25 xq: *noch*
16:41:37 xq: https://github.com/MasterQ32/TinyVG/blob/master/src/lib/rendering.zig#L507-L570
16:41:39 xq: das hier ist der kern
16:42:00 xq: unten drunter sind noch funktionen für kreis und unrunde linie
16:45:12 xq: und das ist schon mit even-odd, overlap und allem scheiß
16:46:09 IceMichael: hm ja, das ist ja jetzt zB nicht optimiert und reicht? also rectangle sind zwei loops, da geht ja bestimmt irgendwas irgendwie anders. mit schrompfs Vektormagic, oder auf GPU waers natuerlich einfach ein quad oder zwei triangles
16:46:19 IceMichael: und das uneven capsule ding darunter nutzt bare sqrt
16:46:31 IceMichael: wobei vll ist das in zig schnell im Ggs zu C++
16:47:13 xq: rectangle ist maximum efficiency
16:47:25 xq: weniger als "einmal alle pixel anfassen" is nicht drin
16:47:40 xq: zig und c++ sind gleich schnell
16:47:46 xq: und ja, unevenCapsule ist noch nicht optimiert
16:47:58 xq: aber solange der kram grade ungefähr im sekundenbereich ist, bin ich happy
16:48:09 xq: das ist immer noch nen softrenderer
16:48:17 xq: ich will für ne anständige lib auf vulkan gehen
16:48:24 xq: oder dx12, metal respektive dann
16:48:34 xq: und halt den sw-ren als fallback halten
16:51:06 IceMichael: Sekundenbereich? klingt superlangsam, aber ist wohl die frage, wofuer genau
16:51:27 IceMichael: und na ja, ich dachte an so was wie memcpy statt Doppelloop
16:51:36 IceMichael: aber muss man halt ausnutzen, wie der Speicher organisiert ist usw.
16:52:09 xq: IceMichael: denk dran
16:52:10 IceMichael: egal, dein Plan macht ja Sinn. SWR fuer POC und fallback, HWR dann ernsthaft
16:52:11 xq: ich hab debug mode
16:52:20 xq: das heißt
16:52:30 xq: jede addition, jede multiplikation
16:52:33 xq: jeder array access
16:52:36 xq: macht safety checks
16:52:47 xq: ich rede von nem -O-1 build
16:52:55 xq: quasi -O0 mit allen sanitizern an
16:52:58 xq: das ist nicht schnell
16:53:09 IceMichael: nes
16:53:28 xq: https://mq32.de/public/6a0aedb81fe3e058b51756592db8cf4fc421d9c7.png
16:53:31 xq: schrompf hatte echt recht
16:53:31 xq: lustig
16:56:40 IceMichael: xq, womit?
16:56:52 xq: "mach mal magenta,0% alpha als fill color"
16:56:57 xq: "das wird lustig"
16:57:07 xq: weil: du siehst in dem bild den lila halo?
16:57:17 xq: das kommt davon, dass die library kein korrektes alpha sampling macht
16:57:21 xq: und einfach alles linear durchmatscht
16:57:28 IceMichael: :(
16:57:36 xq: das ist nen problem von dem image viewer
16:57:38 IceMichael: ist das jetzt wieder svg gerendert von...?
16:57:38 xq: und nicht von mir
16:57:49 xq: das ist PNG gerendert von FEH
16:58:10 xq: https://mq32.de/public/f44cbd0b332ec309850ac277271fde97000dc35c.png
16:58:15 xq: aber: mein kreisrenderer hat ein problem
16:58:48 IceMichael: ist halt kein kreis, sondern zwei halbe?
16:58:58 xq: yep
16:59:01 IceMichael: btw, kurze dummy-Frage: wenn mein Code superviele Warnings erzeugt, macht das den compile lahmer?
16:59:02 xq: geht nicht anders :D
16:59:14 xq: grundlegend: nein
16:59:15 IceMichael: also "superviele", aber schon einige
16:59:17 IceMichael: ok
16:59:18 xq: wenn du sie irgendwo anzeigst: ja
16:59:21 xq: also live
16:59:26 xq: zum beispiel in nem terminal oder so
16:59:31 IceMichael: ja gut, aber so viele sind es jetzt nicht
16:59:39 IceMichael: schade, dann ist github actions einfach generell gerade saulahm puh
16:59:45 IceMichael: frage mich, ob ich subdirectories cachen kann...
16:59:53 IceMichael: weil das geht echt nicht, der compiled schon 11min nur fuer meinen Kram
16:59:54 xq: die haben halt keinen dedicated i7
17:00:02 xq: das sind echte gurken
17:00:26 IceMichael: :/
17:00:57 IceMichael: na ja, mit inf minuten waere es irgendwann halt egal
17:01:11 IceMichael: man pusht was und es wird sofort compiled, codet an was andrem... hat aber den letzten build halt dann fertig
17:01:16 IceMichael: nur es frisst halt unendlich Minuten
17:01:19 IceMichael: die 2k sind sauschnell weg so
17:01:28 IceMichael: und mac ist 10x teuerer als win
17:02:39 xq: yep
17:02:41 xq: gibt nicht so viele macs
17:03:17 xq: https://php-friends.de/vserver-ssd/vserver-s-ssd-g3-1y
17:03:18 IceMichael: solang ich halt in den 2k min bleibe, ist es irgendwie ok
17:03:22 xq: ↑ wäre noch ne alternative
17:04:02 IceMichael: fuer nen win runner, ja
17:04:06 IceMichael: fuer mac gibt's halt auch so was nicht guenstig
17:04:21 IceMichael: und nen mac irgendwo hinstellen, na ja, mach ich gerade ja eh auch schon
17:04:55 IceMichael: aber genau davon wollte ich halt weg
17:05:08 IceMichael: ich frag unseren neuen devops-head mal am Montag :D
17:05:31 IceMichael: der meint ja, gitlab cicd sei viel besser als github
17:05:37 IceMichael: ABER mac und win runner sind da beide beta
17:05:48 IceMichael: ich glaub nur, er findet die pipelines nice und die runner wuerde er evtl woanders hosten, mal sehen
17:05:58 IceMichael: da bin ich echt gespannt. Gerade haben wir ja auf der Arbeit zig Macs irgendwo in Bueros stehen
17:07:19 IceMichael: tja mist, der behinderte google crashpad, der unbedingt sein eigenes drecks build system bauen will, macht mir hier ja eh nen strich durch die Rechnung :D
17:07:27 IceMichael: muss ich fuer den Arsch noch nen Extrastep bauen, was ein Muell
17:07:56 xq: ich bin mal afk
17:08:19 IceMichael: ja, ich bin auch verspaetet, muesste laengst weg sein
17:08:22 IceMichael: bis dann!
18:33:19 xq: sore
18:44:57 xq: der zacken war nen präzisionsfehler
18:45:00 xq: das ist schon mal was
23:34:59 Magister joined the channel