IRC channel logs
2023-04-28.log
back to list of logs
<daviid>dthompson: yesterday i asked in #savannah if we could have cgit [browser] source code hyghlighting, pasting your config example https://git.dthompson.us/guix-config.git/tree/takemi.scm#n165 - and someone said could you provide an example :):) - so, i guess they can't read scheme and figure out how this lands in cgit, could you by any chance paste the 'resulting config' from executing this guix snipset? so i could paste a 'real cgit <daviid>config example' :) - no big deal, but if you can, thanks <dthompson>daviid: so the source-filter line in my cgit config looks like this: source-filter=/gnu/store/jsyr6qn9fnw1ixp1zvgcg96l0k2ic1f1-cgit-syntax-highlight <dthompson>the /gnu/store part won't be helpful to them, but you can tell them that cgit comes a lib/cgit/filters/syntax-highlighting.py script that uses pygments (a python library) to do syntax highlighting <dthompson>so maybe something like source-filter=/usr/lib/cgit/filters/syntax-highlighting.py would work for them <daviid>dthompson: in your case, it seems that scheme core definitions are highlighted in bold, is this a defaut from the python library or a personal choice? askiung because i'd personally rather not, if possible ... <daviid>actually all syntax highlighting seems to be using bold font, except strings ... i was wondering if it is an option you passed somewhere else or not ... <daviid>dthompson: if savannah could run guile, we could run your highlither with our css option file ... <daviid>so far the savannah answer id that it is far too dangerous to run pygment ... i will have asked ... <dthompson>daviid: my highlighter only supports a few languages compared to pygments which does basically everything <dthompson>daviid: I really don't know how the actual coloring and font face stuff is done. I just tell it to use the highlighting script. not sure how much control you really have over the result. <dthompson>I was just happy to have syntax highlighting at all <daviid>dthompson: i know you are 'dead busy', but as we are 'in this subject', let me kindly remind that there are 3 things i'd (really) like to have in your syntax-highlithing code - (a) syntax-procedure-name (for all define 'types', define, define*, define-method and define-vfunc (in g-golf)), (b) syntax-quoted-symbol and (c) to add make to the syntax-special list (which is the easiest to fix :)) <dthompson>(b) definitely should be added. I don't think I had ever used syntax quote at the time I wrote the lexer. <dthompson>for (c) I just checked what emacs scheme-mode does and it doesn't apply any special highlight to 'make' <dthompson>make-scheme-lexer allows for extending the special symbols and special prefixes so you could have 'make' highlighted if you want. <daviid>dthompson: for (1), i am refering the the procedure/function name <daviid>and yes, i added make 'locally', i thought we'd all want it ... because of goops of course <dthompson>yeah maybe! so far my logic has been to highlight the things that scheme-mode does <dthompson>I added syntax object highlighting. will push a commit tomorrow. <daviid>but fine, so in terms of your time, (1) and (2) would be nice ... unfortunate that (1) is 'tricky' <dthompson>I'll have to think on it! haven't looked at this code in a looong time so I don't really remember my "brilliant" design <daviid>:) it is brilliant - i hope you can find a solution for (1) as well ... <daviid>let me(us) know here if/when you make changes - thanks! <daviid>dthompson: for (1), intuitively, it doesn't sound tricky, as it always follows a define ... i wonder if you could just tell the parser what follows the next syntax-opn as a syntax-procedure-name (?) ... <daviid>i mean once the parser encounters a define [any define], to makk what follows the next syntax-open as a syntax-procedure-name ... <rekado>I’m aware of the ffi helper (and I used it for the drmaa bindings), but I was hoping for something a little higher level than direct libusb bindings. <rekado>I’m prone to shaving hairy cattle. <rekado>roptat: do you happen to know why gitile freezes regularly? Seems to affect mine and your instance alike. <RavenJoad>SBCL (and other CL implementations) support dumping the image's core to disk to create a binary. Does Guile have this ability? <old>I have a question regarding gcprof <old>I have way too much gc allocation in guile-parallel, and this is slowing down the scheduling <old>I would like to determine the root of these huge allocations <old>However, there's up to N threads running that can do allocation. So should I use gcprof on every thread? <dthompson>you have to ship the guile runtime + bytecode <old>Also, I get a `;;; (what! #<stack ...>)' when using gcprof <old>not sure if this is dues to call-with-prompt <dthompson>heh I was just looking at the gcprof implementation and noticed that pk <dthompson>I have had limited success with using gcprof to identify issues <dthompson>I wish we had a way to more directly trace where allocation happens <old>I'm close to get fibers performance with parallel <old>I can see here that my bottleneck is allocation <dthompson>gcprof collects stack data in an after-gc hook, meaning that it's capturing some data about when the gc was triggered <old>right that make sens <dthompson>but afaict it's not gathering anything about all of the other allocations that didn't trigger gc <dthompson>I guess the idea is that if you let it profile long enough, the places that allocate more frequently will trigger gc more frequently <old>I can start with adding static tracepoint to libguile <old>determine which path in C is doing allocations <old>that or ask `perf' to sample the C stack itself to get a flamegraph <old>at least I would have a starting point <old>but it is maybe time to add static tracepoints to libguile itself <RavenJoad>dthompson: That's what I thought. I have an idea for a simulator I want to test out, where the idea is if you break an assertion, the simulation stops and dumps the image at that time. So Guile is not an option. Good that I asked. <old>that would be immensely helpful