[00:03] *** timo left [00:04] *** timo joined [00:14] *** kurahaupo joined [01:30] *** hulk joined [01:31] *** kylese left [02:15] *** hulk left [02:15] *** kylese joined [02:22] *** Geth joined [03:22] *** dg left [03:25] *** dg joined [04:50] *** kylese left [04:54] *** kylese joined [05:45] *** kurahaupo left [06:33] *** Sgeo left [06:51] *** perryprog left [06:51] *** perryprog joined [07:19] eax_: some things are working, but a lot of things quietly fail in unexpected ways [07:21] so you need some extensive testing for a lot of code [07:22] though the compiler is getting better every day [07:23] if it does work however, it compiles so fast that it feels nice to use [07:35] though I can't figure out how to increase runtime performance in rakupp, whatever I do code takes longer to run [07:35] than in usual raku [07:41] *** belluzj joined [07:43] though my knowledge is around week old, so it's ancient already :> [07:52] *** belluzj left [09:26] *** sp1983 joined [09:27] Voldenet: with the help of GitHub copilot I've ported rakupp GitHub actions pipeline to dsci - https://github.com/melezhik/rakupp-dsci , this is just a concept but copilot surprisingly well did migration and one can see some advantages dsci has over gh actions [09:35] *** sp1983 left [09:46] *** wayland76 left [09:46] *** wayland76 joined [09:52] well ofc, code in yaml is essentially esolang [09:52] you kinda need special editor to even edit it [09:53] People will be more interested in hearing about the advantages than that copilot did something [09:54] heh, I've mentally skipped the part about copilot [09:54] marketing teams trained me to ignore it [09:55] Never copilot )) the reason I mentioned it is I see this as advantage that my tool is LLMable ) [09:56] In a sense I can easily generate / migrate dsci pipelines with LLM [09:56] But LLM itself is not a point here [09:56] being llmable actually doesn't say anything [09:57] you could ask LLM to convert yaml CI to one big C file and it would probably work [09:57] For example see how elegantly all job are separated by folders , cs dozens on context switching in YAML [09:57] but it would be poor experience for maintainers :D [09:57] One big file is anti pattern in a sense of dsci design [09:58] I mean that [09:58] https://github.com/melezhik/rakupp-dsci/tree/main/.dsci/jobs [09:59] Isolation and decomposition [09:59] Also smooth switching between bash and Powershell where it is required [10:00] Like here https://github.com/melezhik/rakupp-dsci/tree/main/.dsci/jobs/windows-msvc [10:01] One just need to chose to name a task as task.ps1 instead of task.bash , and SDK is always guaranteed [10:01] hm, decomposition can get a little verbose with number of one-line files – maybe jobs should be able to define tasks without files somehow [10:01] Like config helper for example [10:01] $NAME = & config NAME [10:01] https://github.com/melezhik/rakupp-dsci/blob/5f5134d61890132a1707086e37497e3a0db6e774/.dsci/jobs/windows-msvc/tasks/upload_release/task.ps1#L4 [10:02] But you can always combine small tasks into bigger ones , and just get less run_task calls inside job file [10:03] on powershell I'd expect something like Get-DsciVar btw [10:04] Yes they can , it’s called single task job , just drop task.$ext into jobs folder no need to have job.ext with tasks/ sub folder and tasks in it [10:04] In SDK this is called config function [10:05] https://github.com/melezhik/DSCI/blob/main/task.md#job-parameters [10:05] what I meant would be defining job.ps1 with multiple functions [10:05] Yes this is also possible [10:06] but would CI catch that as separate step? [10:06] You can put anything you want inside job.ps1 [10:06] Not just run_task calls [10:07] but CI would see that as just one large task [10:07] so… you don't see how long every task took and can't really code it [10:08] For dsci elementary unit of execution is job actually , for user ( developer ) there is emulation of streps with tasks/ and run_task inside jib file , but technically underneath is just a single Sparrow scenario executed [10:08] ah, I see, so there's not much difference [10:08] Yep [10:09] Dsci is built on top of Sparrow in the end of the day [10:09] it'd be probably nice to see details of timing ootb, that's a thing I'm really missing in build systems [10:09] And in Sparriw there is sparrow scenario which is just a single unit [10:09] timings, dependencies, etc. [10:09] also, `Write-Host "smoke_e_windows_pwsh (windows-msvc job)"` that is kinda awkward and could be probably constructed automatically [10:09] somehow [10:10] so run_task knows what's being done [10:10] It’s easy to add timing per every ( sub) tasks/ or single task without subtasks. Dsci reports indeed already have time stamps per every task or sub task [10:11] That’s generated by copilot actually [10:11] Just a debug message [10:11] oh, does dsci report every run_task call? [10:11] I am going probably to ask it to refactor debug messsges [10:12] Yes it does ) [10:12] if so, then probably it's a mistake, heh :D [10:12] llm mistake* [10:12] Yes . LLMs still do a lot of unnecessary things [10:12] I'm mentioning the timings as important thing, because a lot of times I hit that wall when the build takes a lot longer than it should [10:13] But again I just did not have time / was lazy to port rakupp pipeline to dsci manually [10:13] and CI systems are not that flexible for timing things, unfortunately, e.g. build processes can't really report progress or internal timings, so you have to refactor things into jobs [10:14] So, yeah timing is already hear, maybe just need some formatting ( like showing time elapsed instead of just time stamps ) [10:14] Hear -> here [10:16] But one thing I really like about dsci it allows you to create extremely hackable and simple code where one is in control of every but, and if one day I need to add few more option to say cmake build command I just need edit my task.bash no magic is required [10:16] basically what I'd love to use is `run_task` with calculated jobs tree, timings and parallel tasks support somehow [10:17] I could use & and fg but that feels hacky, CI may not be able to track it, so you'll end up reading 1000 lines log again [10:17] Instead of going trough gh actions plugin documentation/ source code doing reverse engineering [10:18] yeah in the end it looks so simple that it's hard to believe it's actually CI [10:18] I'm just throwing ideas of various CI pains [10:18] Right now run_task are sequential, after all job file is just regular programming language be it bash, Raku or Powershell [10:19] Absolutely, that’s the idea behind of dsci [10:19] And btw it still allows to package reparable tasks into plugins [10:19] in fact, timings and tasks running tracking could be in the end just especially formatted logs [10:20] And distribute them across community [10:20] and dsci/shared/tasks is for local repeatable tasks [10:21] https://github.com/melezhik/rakupp-dsci/tree/main/.dsci/shared/tasks [10:21] e.g. `DSCI subtask_start/subtask_end/subtask_fail` something like that [10:23] I'd say something about dependencies but idk if having build system inside CI is a good idea, it sounds like overengineering [10:32] This is example of job with two tasks ( every log block stat starts with task run: task.bash - . ) [10:32] And here is the job - http://forgejo.sparrowhub.io/demo/demo-raku-cro/src/branch/main/.dsci/job.raku [10:33] And here is the job tasks - http://forgejo.sparrowhub.io/demo/demo-raku-cro/src/branch/main/.dsci/tasks [10:33] Again job is just a Raku file [10:33] With 2 run_task class [10:33] Calls [11:54] *** abbe left [11:55] *** abbe joined [12:18] *** wayland joined [12:18] *** wayland76 left [12:23] *** spa1983 joined [12:23] promised report (lost accidentally ) - http://dsci-runner.sparrowhub.io/report/ui/job.run/fzdptagbioscxkuqnjvl.18120 [12:23] with two tasks [12:25] *** spa1983 left [12:28] *** lizmat_ left [12:28] *** lizmat joined [13:28] weekly: https://github.com/Raku/problem-solving/issues/525 [13:28] lizmat, Noted! (weekly) [13:55] *** sorenson left [13:58] *** sorenson joined [14:26] *** wayland left [14:27] *** wayland joined [14:46] *** merpp left [14:53] *** sp1983 joined [14:53] Voldanet: pass all parameters as job input parameters - https://github.com/melezhik/rakupp-dsci/blob/main/.dsci/jobs.yaml [14:53] cc/ccx/mingw/ [14:53] *** Sgeo joined [14:59] *** sp1983 left [15:09] Is there an operator to do .DEFINITE test? [15:09] *** merp joined [15:09] I know $x.DEFINITE will do, But don't know if there is operator for this [15:10] 'if $x.DEFINITE' <--- I mean some prefix for this [15:15] *** sp1983 joined [15:16] Voldanet: I think maybe take some simple pipelines , say for some Raku modules and try to convert to dsci and see what I get [15:24] But that is the point of the "LLM-able" claim -- how high that probability is? [15:24] With proper prompting and post-processing they do not. 🙂 [15:25] weekly: https://rakuforprediction.wordpress.com/2026/07/30/raku-api-access-to-xai/ [15:25] antononcube, Noted! (weekly) [15:27] the report output is not bad, just that any sort of debugging or guessing how long things take is non-trivial [15:31] yeah, but we at least can show elapsed time for every finished task post fact [15:34] antononcube: https://github.com/melezhik/Raku-Jupyter-Chatbook-dsci [15:34] Raku-Jupyter-Chatbook ))) [15:35] that's simple one, however migration done by copilot is decent ) [15:35] I like Benefits of this migration: part haha )) [15:36] *** sp1983 left [15:37] @sp1983 [15:37] https://cdn.discordapp.com/attachments/633753286209699870/1532774254104412330/The-influence-of-alchohol-on-AI-Russian.jpeg?ex=6a6e12c3&is=6a6cc143&hm=d1890980d2be3c94a43c09373f2000f59263273b33d2b7f0d1058747213fc976& [15:44] For for the non-Russian speakers: [15:44] https://cdn.discordapp.com/attachments/633753286209699870/1532775859432325260/The-influence-of-alchohol-on-AI-English.jpg?ex=6a6e1442&is=6a6cc2c2&hm=8ec6a6ad851be21328e312a9c2228b7bede40d5305a67b412e40ebbc6d38f56f& [15:48] Anton: I am please 🙏))) [15:48] pleased [16:41] Hi, today, when I read the Proc::Async doc, I saw there is a way to get the exit code of the process, I need to do something like 'my $exit-code; react whenever $proc.start { $exit-code = .exitcode; };' Isn't there other way to do this? [16:41] Do we have to use react whenever block here? [16:47] *** wayland left [16:47] *** wayland joined [16:48] And I tried to read Proc::Async src/core.c/Proc/Async.rakumod, I saw it is a $!exit_promise internally. [16:51] hmm, ignore me, figured out myself [17:21] m: { my $p = Proc::Async.new("/usr/bin/false"); my $x = await $p.start; CATCH { "e1".say; }; "here1".say; }; { my $p = Proc::Async.new("/usr/bin/false"); await $p.start; CATCH { "e2".say; }; "here2".raku.say; } [17:21] rakudo-moar 35c19d499: OUTPUT: «here1␤The spawned command '/usr/bin/false' exited unsuccessfully (exit code: 1, signal: 0)␤ in block at line 1␤␤e2␤» [17:58] *** acidsys left [18:13] *** acidsys joined [19:05] Gemini take on converting gh actions pipeline to dsci - https://share.gemini.google/jrFcsEfOSeYA [19:32] *** wayland left [19:32] *** wayland joined [19:56] xinming: you can use promise-based interface to it, eg `say await $proc.start.then({ $_.result.exitcode });` [19:57] ooor `await $proc.start andthen say .exitcode` [20:03] promises is probably the sanest approach: say await $proc.start.then({ $_.status ~~ Broken ?? 42 !! $_.result.exitcode }); [20:03] since you can handle errors with it [20:04] or gobble them up if you prefer [20:07] in your example `await $p.start` sinks the promise, that's where it gets the error [20:08] m: { my $p = Proc::Async.new("/usr/bin/false"); try sink await $p.start; "here1".say; }; { my $p = Proc::Async.new("/usr/bin/false"); await $p.start; "here2".raku.say; } #eg [20:08] rakudo-moar d9166ef4c: OUTPUT: «here1␤The spawned command '/usr/bin/false' exited unsuccessfully (exit code: 1, signal: 0)␤ in block at line 1␤␤» [20:20] *** JRaspass left [20:20] *** JRaspass joined [20:37] *** jast left [20:37] *** jast joined [21:52] *** thaewrapt left [21:53] *** thaewrapt joined [21:53] *** thaewrapt left [21:53] *** thaewrapt joined [22:07] *** timo left [22:08] *** timo joined [23:39] *** kurahaupo joined [23:57] *** wayland left