<spk121>here's fun bug with the new reader. What to you think #\11# should be? Or #\x11# ? ***apteryx is now known as Guest69784
***apteryx_ is now known as apteryx
<spk121>tohoyn: the plan is that I'll send out an e-mail to guile-user calling it closed. Then I'll write a series of blog posts on planet.gnu.org about the entrants. <spk121>and the best one wins $1,000,000 dollars!! <apteryx>rekado_: would you know if there's something already available to convert HTML to Texinfo? <apteryx>htmlprag's html->sxml is nice, but when extracting the *text*, it looses all the hyperlinks, formatting, etc. <pinoaffe>apteryx: as far as I'm aware there's nothing ready-made in guile itself, shelling out to pandoc might be the most reliable way <pinoaffe>if you want to, you could probably do some tree matching/tree transformation on the sxml to generate skribilo-markup-sexprs, which you could convert to Texinfo, but it'd be up to you to write a converter that preserves the markup you're interested in <apteryx>Thanks for the pointers, pinoaffe! It seems if I have to do some manual transformation to skribilo markup, I might as well do the sxml->texi for my simple case. ***DadeBonetti1 is now known as DadeBonetti
<mdevos>In e.g., scm_tcgetpgrp (and plenty of other functions), there doesn't seem to be any code preventing the port from being garbage-collected, leading to the file descriptor being closed before the tcgetpgrp. Is there an automagical "don't GC arguments to SCM_DEFINE procedures" or something, or is this an actual bug? <mdevos>(This shouldn't be a real issue as long as one remembers to close the port eventually) <leoprikler>mdevos: scm_remember_upto_here or how it's called <mdevos>leoprikler: I'm sprinkling these around now (searching with "git grep -F _FDES" for appropriate places) <leoprikler>other than that, if the SCM is still on the stack (definitely) or in a register (IIUC), it won't be garbage collected <mbakke>I have a script that execl's another process and leaks its own file descriptor (the script name) into it. I'd like to set FD_CLOEXEC on the FD, but can't figure out how to access it. Ideas? <mdevos>leoprikler: I don't think there's any guarantee the compiler won't optimize out the "SCM port" variable right in between the "fd = ..." and if ((pgid = tcgetpgrp (fd)) == -1) STUFF. <leoprikler>Yeah, in that case sprinkling some remembers might be a good idea. <mdevos>leoprikler: ok, expect a patch on the mailing list sometimes soonish I hope! <mbakke>mdevos: but I don't know which fd to open short of doing heuristics on /proc/self/fd <mbakke>seems like I can reach it through 'port-for-each', but perhaps there is a shorthand for accessing the 'input script port'? :) <mdevos>mbakke: perhaps the "another process" can be modified to allow an --input-script-fd=the-file-descriptor argument? <spk121>mbakke: (port->fdes (current-input-port)) perhaps. but only if your current input port is a file port <mdevos>The script can use "fileno" to figure out the value of "the-file-descriptor" to pass <mdevos>mbakke: for clarification: do you want to leak the file descriptor, or do you want to *not* leak it? <mbakke>the port I'm trying to FD_CLOEXEC is the "script filename", i.e. /bin/guile-execl-wrapper, typically FD 7 or so. The execl'd process should only inherit FD's 0-2. <rlb>Is it the case that all unicode normalizations preserve the character count? <mbakke>it essentially pretends to be bash unless some conditions are met, so it's important to not leak file descriptors to the actual shell. <RhodiumToad>rlb: though it may depend on what you think a "character" is <mbakke>I'm using it as my login shell (!!). It increases the startup time of "bash" 3x, but I'm fine with that as long as I don't have to fiddle with bashrc :P <rlb>I mean a the unicode "character count", or more importantly, whatever we call a character, not the unit count. <rlb>i.e. (string-length x) <RhodiumToad>rlb: then no, because the whole point of the different normalizations is to control whether certain sequences are represented in precomposed form (single codepoints) or decomposed (multiple codepoints) <rlb>Hmm, I guess I probably "knew that", just wasn't thinking about it carefully enough, i.e. that say a decomposed umlaut is in fact two code points... Thanks. <rlb>(Hmm, and more specifically, can normalization ever change the ascii set...) <RhodiumToad>decomposition can produce new codepoints in the ascii range, and composition can remove ascii codepoints <rlb>any way? Just thinking about potential optimizations there, i.e. if you pass an ascii only string to u8_normalize() can there be changes? <rlb>That's what I was guessing too... ***nckx is now known as jorts
<RhodiumToad>checking the unicode data tables, all of 7-bit ascii (0x00-0x7f) has Yes for all the NF*_QC properties <RhodiumToad>which means any 7-bit ascii string is automatically in all 4 of NFC, NFD, NFKC, NFKD <RhodiumToad>note, many codepoints 0xA0-0xFF (the latin1 range) are not in NFD/NFKD <rlb>Thanks, and right, I'd expected that wouldn't be true for > 127. <mbakke>comparing (port-filename) with (car (program-arguments)) within port-for-each and setting FD_CLOEXEC on those does the job for now. I wonder if Guile itself can/should set FD_CLOEXEC on the "script port". *rlb wonders where functions like mem_iconveh are documented. ***jorts is now known as nckx
<sh4rm4^bnc>wingo, i'm interested in lightening, especially how it differs from lightning, but documentation is sparse. especially it's been hard to figure out what actually changed between lightning 1.x and 2.x <mdevos>How do guile hackers setup Emacs for hacking on Guile's C code? <mdevos>(Do I configure emacs to insert tabs, or spaces, or ....) <mdevos>The C code seems inconsistent in space vs tabs <adhoc>so when you hit the Tab key to indent it only uses spaces to do so? <mdevos>adhoc: when the preceding code uses spaces, then yes <civodul>for C i usually do indent-tabs-mode t, meaning that Emacs chooses tabs or spaces <adhoc>mdevos: thanks, I declared emacs dot file bankruptcy about a year ago and now slowing putting back useful snippets... <mdevos>it seems like Emacs always inserts spaces for me. <mdevos>whatever, I'll just send my patch as-is <manumanumanu>There is a discussion on reddit, and I went in and pointed with my whole hand, but trying things at the REPL makes me feel like a fool. ***rekado_ is now known as rekado
<rekado>manumanumanu: this fails as expected: (define a '((moo . mean)))(assq-set! a 'moo 'oom) <rekado>the error is: In procedure set-cdr!: Wrong type argument in position 1 (expecting mutable pair): (moo . mean) <manumanumanu>rekado: I am feeling lost in an evil universe. What is the difference? <lloda>sneek: later tell mdevos one thing I do when editing Guile code is disable trailing whitespace removal. Unfortunately Guile code has a lot of that and if you have autoremoval on, the diffs will be very dirty. <manumanumanu>rekado: something odd is going on: (define a '((1 . 2))) (set-cdr! (car a) 22) => works fine <leoprikler>sneek later tell manumanumanu yeah, there are a lot of instances, when Guile's supposedly immutable things are actually mutable. I sadly can't recall a way of debugging this. <muffindrake>Hiya, how does one actually use the packages installed with guix in a program? I'm trying to use the chickadee module, but I'm kinda stuck at this step, since it's not found apparently. <leoprikler>For chickadee, you need to install guile as well. I personally prefer to use environments, either ad-hoc or defined by a project's guix.scm.