00:03 timo left 00:04 timo joined 00:14 kurahaupo joined 01:30 hulk joined 01:31 kylese left 02:15 hulk left, 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, perryprog joined
Voldenet eax_: some things are working, but a lot of things quietly fail in unexpected ways 07:19
so you need some extensive testing for a lot of code 07:21
though the compiler is getting better every day 07:22
if it does work however, it compiles so fast that it feels nice to use 07:23
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
Voldenet though my knowledge is around week old, so it's ancient already :> 07:43
07:52 belluzj left 09:26 sp1983 joined
sp1983 Voldenet: with the help of GitHub copilot I've ported rakupp GitHub actions pipeline to dsci - 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:27
09:35 sp1983 left 09:46 wayland76 left, wayland76 joined
Voldenet well ofc, code in yaml is essentially esolang 09:52
you kinda need special editor to even edit it
ugexe People will be more interested in hearing about the advantages than that copilot did something 09:53
Voldenet heh, I've mentally skipped the part about copilot 09:54
marketing teams trained me to ignore it
melezhik. Never copilot )) the reason I mentioned it is I see this as advantage that my tool is LLMable ) 09:55
In a sense I can easily generate / migrate dsci pipelines with LLM 09:56
But LLM itself is not a point here
Voldenet being llmable actually doesn't say anything
you could ask LLM to convert yaml CI to one big C file and it would probably work 09:57
melezhik. For example see how elegantly all job are separated by folders , cs dozens on context switching in YAML
Voldenet but it would be poor experience for maintainers :D
melezhik. One big file is anti pattern in a sense of dsci design
I mean that 09:58
github.com/melezhik/rakupp-dsci/tr....dsci/jobs
Isolation and decomposition 09:59
Also smooth switching between bash and Powershell where it is required
Like here github.com/melezhik/rakupp-dsci/tr...ndows-msvc 10:00
One just need to chose to name a task as task.ps1 instead of task.bash , and SDK is always guaranteed 10:01
Voldenet hm, decomposition can get a little verbose with number of one-line files – maybe jobs should be able to define tasks without files somehow
melezhik. Like config helper for example
$NAME = & config NAME
github.com/melezhik/rakupp-dsci/bl...ask.ps1#L4
But you can always combine small tasks into bigger ones , and just get less run_task calls inside job file 10:02
Voldenet on powershell I'd expect something like Get-DsciVar btw 10:03
melezhik. 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
github.com/melezhik/DSCI/blob/main...parameters 10:05
Voldenet what I meant would be defining job.ps1 with multiple functions
melezhik. Yes this is also possible
Voldenet but would CI catch that as separate step? 10:06
melezhik. You can put anything you want inside job.ps1
Not just run_task calls
Voldenet 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
melezhik. 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
Voldenet ah, I see, so there's not much difference
melezhik. Yep
Dsci is built on top of Sparrow in the end of the day 10:09
Voldenet it'd be probably nice to see details of timing ootb, that's a thing I'm really missing in build systems
melezhik. And in Sparriw there is sparrow scenario which is just a single unit
Voldenet timings, dependencies, etc.
also, `Write-Host "smoke_e_windows_pwsh (windows-msvc job)"` that is kinda awkward and could be probably constructed automatically
somehow
so run_task knows what's being done 10:10
melezhik. 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
That’s generated by copilot actually 10:11
Just a debug message
Voldenet oh, does dsci report every run_task call?
melezhik. I am going probably to ask it to refactor debug messsges
Yes it does ) 10:12
Voldenet if so, then probably it's a mistake, heh :D
llm mistake*
melezhik. Yes . LLMs still do a lot of unnecessary things
Voldenet 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
melezhik. But again I just did not have time / was lazy to port rakupp pipeline to dsci manually 10:13
Voldenet 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
melezhik. So, yeah timing is already hear, maybe just need some formatting ( like showing time elapsed instead of just time stamps ) 10:14
Hear -> here
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
Voldenet basically what I'd love to use is `run_task` with calculated jobs tree, timings and parallel tasks support somehow
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
melezhik. Instead of going trough gh actions plugin documentation/ source code doing reverse engineering
Voldenet 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
melezhik. Right now run_task are sequential, after all job file is just regular programming language be it bash, Raku or Powershell
Absolutely, that’s the idea behind of dsci 10:19
And btw it still allows to package reparable tasks into plugins
Voldenet in fact, timings and tasks running tracking could be in the end just especially formatted logs
melezhik. And distribute them across community 10:20
and dsci/shared/tasks is for local repeatable tasks
github.com/melezhik/rakupp-dsci/tr...ared/tasks 10:21
Voldenet e.g. `DSCI subtask_start/subtask_end/subtask_fail` something like that
I'd say something about dependencies but idk if having build system inside CI is a good idea, it sounds like overengineering 10:23
melezhik. 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 - forgejo.sparrowhub.io/demo/demo-rak...i/job.raku
And here is the job tasks - forgejo.sparrowhub.io/demo/demo-rak...dsci/tasks 10:33
Again job is just a Raku file
With 2 run_task class
Calls
11:54 abbe left 11:55 abbe joined 12:18 wayland joined, wayland76 left 12:23 spa1983 joined
spa1983 promised report (lost accidentally ) - dsci-runner.sparrowhub.io/report/ui...njvl.18120 12:23
with two tasks
12:25 spa1983 left 12:28 lizmat_ left, lizmat joined
lizmat weekly: github.com/Raku/problem-solving/issues/525 13:28
notable6 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
sp1983 Voldanet: pass all parameters as job input parameters - github.com/melezhik/rakupp-dsci/bl.../jobs.yaml 14:53
cc/ccx/mingw/
14:53 Sgeo joined 14:59 sp1983 left
xinming Is there an operator to do .DEFINITE test? 15:09
15:09 merp joined
xinming I know $x.DEFINITE will do, But don't know if there is operator for this 15:09
'if $x.DEFINITE' <--- I mean some prefix for this 15:10
15:15 sp1983 joined
sp1983 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:16
antononcube 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. 🙂
weekly: rakuforprediction.wordpress.com/20...ss-to-xai/ 15:25
notable6 antononcube, Noted! (weekly)
Voldenet the report output is not bad, just that any sort of debugging or guessing how long things take is non-trivial 15:27
sp1983 yeah, but we at least can show elapsed time for every finished task post fact 15:31
antononcube: github.com/melezhik/Raku-Jupyter-Chatbook-dsci 15:34
Raku-Jupyter-Chatbook )))
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
antononcube @sp1983 15:37
cdn.discordapp.com/attachments/633...fc976&
For for the non-Russian speakers: 15:44
cdn.discordapp.com/attachments/633...8f56f&
melezhik. Anton: I am please 🙏))) 15:48
pleased
xinming 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, wayland joined
xinming And I tried to read Proc::Async src/core.c/Proc/Async.rakumod, I saw it is a $!exit_promise internally. 16:48
hmm, ignore me, figured out myself 16:51
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
camelia here1
The spawned command '/usr/bin/false' exited unsuccessfully (exit code: 1, signal: 0)
in block <unit> at <tmp> line 1

e2
17:58 acidsys left 18:13 acidsys joined
melezhik. Gemini take on converting gh actions pipeline to dsci - share.gemini.google/jrFcsEfOSeYA 19:05
19:32 wayland left, wayland joined
Voldenet xinming: you can use promise-based interface to it, eg `say await $proc.start.then({ $_.result.exitcode });` 19:56
ooor `await $proc.start andthen say .exitcode` 19:57
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
or gobble them up if you prefer 20:04
in your example `await $p.start` sinks the promise, that's where it gets the error 20:07
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
camelia here1
The spawned command '/usr/bin/false' exited unsuccessfully (exit code: 1, signal: 0)
in block <unit> at <tmp> line 1
20:20 JRaspass left, JRaspass joined 20:37 jast left, jast joined 21:52 thaewrapt left 21:53 thaewrapt joined, thaewrapt left, thaewrapt joined 22:07 timo left 22:08 timo joined 23:39 kurahaupo joined 23:57 wayland left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!