IRC channel logs
2025-02-14.log
back to list of logs
<Arsen>that's currently the case on Gentoo <Arsen>I need to write the eselect module for guile <Arsen>just haven't gotten a chance to do so yet <Arsen>(but I am happy to say that doing that is the last missing bit for first-class guile support, we support versioned installation and packaging guile programs and libraries now) <ArneBab>Arsen: and thank you for your work on it! <old>ArneBab: ya fedora is a pain as always <old>Feel free to reach out to me or Mathieu if you have questions <old>Thanks Mathieu, I'm more working on libside :-) <old>civodul: I think perfetto is a browser thing <old>wingo: btw Babeltrace has a C interface. You can make Guile bindings are write your trace converter using Guile that way <old>It will probably be order of magnitude faster. I remember the python scripts to be extremly slow when you enter multi-giga-bytes traces <old>s/are write/and write <civodul>apparently it does OTF, not CTF though <old>IIRC, OTF and OTF2 are tailored for MPI application context and for very particular analysis <old>CTF2 is a lot more generic in that respect <old>for example, we have barectf, which allows emitting CTF in bare environment (no OS) <old>and typically, CTF can be emitted by hardware <civodul>will be good for our Lisp machines :-) <old>wingo: btw I'm currious as to why you used Perfetto. Have you tried Trace Compass? <old>j'ai demande a wingo pourquoi il etait aller vers Perfetto et s'il avait essaye Trace compass <wingo>old: simple reason, i tried trace compass but for some reason it wasn't working on my guix system <wingo>also i was familiar with it via the chrome://tracing stuff of yore <wingo>old: and yes the python bindings are indeed slow :/ good to hear that the c interface is faster <old>wingo: I see. I did tried to package Trace Compass once for Guix. But Java being Java .. I stopped for my sanity <old>I used the pre-built binary in a container whenever I need to use it <old>but I think I had to tweak stuff in it also <old>and maybe it did not even work and I just fire-up a VM lol <wingo>i should have an ubuntu around, but on this machine i hadn't set that up yet <old>re python: Well Python being one of the slowest dynamic runtime it is not a suprise. One way I use babeltrace is by parsing its output with AWK <old>which is order of magnitude faster than Python .. how funny <old>But the "real" way to use Babeltrace is to use its pluging system and writting plugins in C/C++ <cow_2001>things i learned: (bytevector=? #u8() #vu8()) => #f <cow_2001>i am confused. why should the two be different? i thought they are synonyms <shawnw>(equal? '#u8() '#vu8()) is true. <old>cow_2001: I guess the element type are not the same <old>SCM_ARRAY_ELEMENT_TYPE_VU8 <old>SCM_ARRAY_ELEMENT_TYPE_U8 <old>not the same element ype <old>Introduced by Andy at 2a610be594 <old>No mention on what is VU8 VS U8 <old>I think the distinction is that #u8 is an array while #vu8 is a bytevector, which are also array .. <cow_2001>shawnw: old: hmm. so maybe i should replace bytevector=? with equal? in the guile-bytevector-peg? <old>I guess performance wise there are not difference <old>equal will just for-loop over the two #u8 and #vu8 <old>while bytevector=? does a memcmp which is a byte per byte comparaison also <taylan>u8 is srfi 4, vu8 is guile-specific IIRC <taylan>they should be the same in what they can actually do <taylan>I guess bytevector=? only fails because the container is of a different type <taylan>if you can ensure that you only ever receive one of the two, it should be fine