<CustosLimen>how can I get the current thread id (e.g. pthread_self() or gettid()) ? <mark_weaver>CustosLimen: (current-thread) returns the Guile thread object of the current thread. <mark_weaver>the POSIX thread ids are not exposed in the interface. <CustosLimen>mark_weaver, but I want to get the equivalent of pthread_self() from it <CustosLimen>I want (current-source-location) for previous stack frame <CustosLimen>but I guess I will have to fiddle with stack stuff then <CustosLimen>s I want to use source-properties or source-property on a stack frame <mark_weaver>CustosLimen: probably what you actually want here is to make a macro that uses 'syntax-source' to access the source location of the macro invocation. <mark_weaver>we don't want to commit to supporting that interface indefinitely <CustosLimen>and this uses (source-properties (frame-source cframe)) <mark_weaver>you can't assume that anything we use internally is a public interface that we commit to supporting in the future <CustosLimen>was just checking - found it in documentation of previous versions <mark_weaver>CustosLimen: take a look at the definition of 'current-source-location' in ice-9/boot-9.scm <mark_weaver>notice that it's defined in terms of 'syntax-source' <mark_weaver>it's a little bit tricky, but I'm afraid I have to go afk now... good luck. <CustosLimen>I dont get the difference between goops classes and records <mark_weaver>CustosLimen: 'exit' works by raising an exception of a certain type. you might want 'primitive-exit' instead, which simply calls the C exit. <CustosLimen>when I send signal it does not actually return from wait on condition variable <mark_weaver>CustosLimen: oh wait, there's another issue. you defined 'exit' within this module to be something else <CustosLimen>still have issue though with wait-condition-variable not returning before deadline <mark_weaver>the problem might be that you're waiting in the same thread that runs the signal handler. <mark_weaver>I don't know off-hand how this kind of thing would be dealt with, but really condition variables are meant to be used in such a way that the thread that signals the condition variable should be different than the one that's waiting on it. <mark_weaver>I'd have to dig into the code to investigate how such a case would be handled, but it's a bit of an edge case. <CustosLimen>mark_weaver, I'm fairly sure I have done this in c like that <mark_weaver>quite possibly, but our condition variables are a different implementation. <mark_weaver>guile's mutexes and condition variables are a separate implementation, which makes some additional guarantees about fairness, etc. <mark_weaver>there are some other issues as well, e.g. arranging to be able to wake up a particular thread (e.g. for signal delivery) by sending data to a pipe that it calls select(2) on, etc. <mark_weaver>whereas POSIX doesn't provide a portable way to specify which thread will receive a signal, we do something a bit more complicated. it's not perfect though. <CustosLimen>thanks, will change that to just be loop that sleeps <mark_weaver>the author of regex also made a SRFI that's very similar, but slightly different. <CustosLimen>so to use ice-9 threads and srfi-18 make-thread at same time I need to rename one of the two <civodul>(use-modules ((ice-9 threads) #:prefix the-other-one-)) <civodul>but i would recommend against using both <fps>hi.. i wonder what's the simplest way to make the guile http client ignore invalid headers.. <fps>web/http.scm:854:12: Bad qstring header component: 1445898649.24 <CustosLimen>what is convention for class names and instance variables ? <CustosLimen>Ideally I want it to be as close as possible to async_eueue <fps>maybe add a named options #:ignore-invalid-headers? with default #t? <CustosLimen>I have been using _ instead of - but this is not really working out <civodul>CustosLimen: a widespread convention for structs/classes is <foo>, and otherwise always use hyphens, not underscores <CustosLimen>oh yeah thats true - the class name is <async-queue> <amz3>fps: IMO it's a design decision. <fps>amz3: um, ok. i was just looking through the code a little and ended up at validate-media-str <fps>validate-media-type str, sorry <fps>amz3: so you're saying the ability to accept invalid headers would not be wanted anyways? <amz3>fps: hmm I'm reading parser-qstring <amz3>no, I am saying that the way the feature is exposed is a design decision, but I'm might be wrong <amz3>I'm investigating how to handle the case. <amz3>I'm not sure what makes the header a bad header <amz3>do you have an the response in plain text? <fps> ETag: 1445898649.24 <amz3>how do you that's the etag that is failling <amz3>(maybe the problem is that guile http web is too strict) <fps>web/http.scm:854:12: In procedure parse-entity-tag: <fps>web/http.scm:854:12: Bad qstring header component: 1445898649.24 <fps>i am under the impression that it's too strict as the general header format pretty much allows anything excepft CR/LF, but i'm not an http expert <fps>civodul mentioned a ticket concerning this, but the tracker seems to be down atm <amz3>maybe the ETAG is not wrapped inside double quotes <fps>the precise format seems to be left unspecified by the standards.. <fps>so quotes, or no quotes shouldn't matter, no? <fps>opaque-tag = DQUOTE *etagc DQUOTE <fps>so it seems to be indeed an invalid header.. <amz3>at least we know what the issue is <amz3>fps: you know how to fix it? <fps>i'd have to learn much more scheme, guile coding conventions, political implications, etc.. <fps>read the whole web client source, etc, to make a good call on how to fix it ;) <fps>a dirty hack would be easier :) <amz3>it download the thing, it's rather small in fact, isn't it? <fps>yeah, some 5 megs or so? <fps>it's just another piece of stupid software deployment. it has a script to download the rest, etc.. :) <fps>i was just starting off the nixos openjdk package to see if i can get it into guix <amz3>yes, I recall java things, I'm wondering where the url comes from, because manual download is forbidden afaik <fps>and this thing is GPL2+ to boot :) <fps>so the javascript "accept this binary license" restriction is stupid anyways <amz3>so I was going to say, do you want me to work on fix? <fps>amz3: sure, from my point of view it would be useful for me getting openjdk packaged, or at least try to :) <amz3>I have a fix in mind, but I need to do it properly with tests <fps>bugs.gnu.org is still down it seems.. <amz3>but I'm wondering, how would you use it in guix, if it's not released? <fps>amz3: wait with packaging until it has trickled down into guix? :) <fps>and maybe speeding up that process by being annoying <fps>also we could patch the guile in guix with that change in the meantime.. no idea if that's an acceptable strategy for the guix people though <amz3>maybe they are other matters regarding the web client, that should be addressed that could require a fork <amz3>I'm not even be able to do the fix, since I have not copyright assignment <fps>hm, sounds complicated ;) <fps>oh well, i have other stuff to package, too ;) <civodul>fps: yes, we need to try both approaches in parallel: email the web site's admins, and make Guile's HTTP client more tolerant <fps>civodul: ok, i'll try and see if i can find an email for that broken server :) <fps>pfft. whois points to dyndns ;) site is (c) oracle.. that's gonna be a challenge <fps>i predict: it won't get fixed <fps>they probably spent a fortune on getting ETag user tracking to work <fps>and it'll be a one million code java web app <fps>*million lines of code <fps>i dropped some words in their IRC channel ***berndj-blackout is now known as berndj
<taylan>those made with make-recursive-mutex <vanila>hi does guile have a pattern matching library? <vanila>oh that's foofs syntax-rules one <vanila>I'm just thinking about porting my library to guile, there's not a demand for it so hmm.. <mark_weaver>at this point, we're quite happy with (ice-9 match) and have been using it a lot within guile itself <vanila>Is there a term rewriting engine? <mark_weaver>vanila: not that I know of, but that might be my ignorance :) <vanila>I was thinking of cleaning up my regex compiler and making it run in guile <mark_weaver>but it would be good to optimize those portable implementations to work more efficiently with guile's internal string representation <mark_weaver>although there's also a plan to switch our internal string representation to UTF-8, so the two jobs are somewhat interlinked. <vanila>I like that this is s-expression based, so is mine <mark_weaver>vanila: you invented your own instead of using SREs? <mark_weaver>I guess that's a common issue in our community, reinventing the wheel too many times :) <vanila>its trivial to change surface syntax <vanila>(as long as they're both s-exps) <mark_weaver>irregex and SRFI-115 are from the same person, and are quite similar. <mark_weaver>and SREs (Scheme Regular Expressions) have a longer history, back to SCSH. <mark_weaver>one feature that irregex has that is missing in SRFI-115 is the ability to execute regexps in chunked fashion, e.g. so that you can read a file in blocks and match regexps on it without loading the entire file into memory. <davexunit>perhaps I should use this to implement my syntax highlighter <davexunit>I've been struggling to make that work correctly <vanila>the main thing I do is compile a vector of regexps into a state machine that attempts to match them all simultaneously <davexunit>mark_weaver: a very popular syntax highlighter for Python called Pygments uses regexps primarily. <vanila>the resulting graph can be interpreted to do matching or produce a matcher in another language <davexunit>I'm just not willing to write those nasty regexp strings <mark_weaver>so, one thing that I recall is important is to bail out of building a DFA if the number of states grows too large, and fall back to using an NFA in that case. <mark_weaver>and another thing is to compile a DFA/NFA that works byte-wise on a UTF-8 representation <mark_weaver>vanila: well, that's the classic way to implement regexps <vanila>I do it with derivatives rather than the powerset construction, so you have unusual operations available like intersection, negation <mark_weaver>but if negation is included, I guess that the number of states of the resulting DFA might become unmanageably large with even simple examples. <vanila>doing UTF-8 in byte based way is something I'd not thought of, does sound very important but quite difficult <mark_weaver>UTF-8 has some nice properties that make it much easier <mark_weaver>most notably that no valid UTF-8 sequence is a subsequence of any other valid sequence. <mark_weaver>mostly, you can just convert the regexp itself into UTF-8 and treat it bytewise, with just a few exceptions: <mark_weaver>things like '.' and [...] need to match valid UTF-8 sequences instead of single bytes. <mark_weaver>and of course within a [...] character set, you need to break up the characters within on UTF-8 codepoint boundaries instead of byte boundaries to construct the set. <mark_weaver>at least for standard regexps. when you add intersection and negation into the mix, I don't know. <vanila>I wonder what sort of behavior should be expected of a regexp on UTF-8-invalid strings <vanila>the best would probably be to report that the string is invalid <mark_weaver>vanila: I would make it part of the contract that the strings will be valid UTF-8, or else the results are unspecified. <mark_weaver>combining validation and matching into the same operation will surely add complexity, increase the size of the state machines, and slow things down. <mark_weaver>in many cases, the strings will already be known to be valid UTF-8, and if not, validation can always be done as a separate step. <paroneayea>mark_weaver: davexunit: I was pretty astounded at how pleasant and composable irregex was to hack in in the experiment I ran last night <davexunit>paroneayea: your ledger parsing code was cool <paroneayea>davexunit: unlike every other regex parsing stuff I've ever done, it was effortless for me to put together and remember what was going on <paroneayea>and the ability to compose the sre expressions using backquote <davexunit>it could greatly help me with my syntax highlighter <davexunit>there's a state machine lurking in this thing, but I can't get the means of combination right. <davexunit>I tried using the paste.lisp.org highlighting code as a base, but it's a horrific mess of complex macros. <vanila>that's the beauty of s-expressions <paroneayea>davexunit: I think playing with irregex and thinking about that style of pattern matching <vanila>davexunit, what language are you doing syntax hilighting for? <davexunit>vanila: it's meant for any language, but my must haves right now are Scheme, XML, and C. <davexunit>as those are the languages I use in code snippets on my blog. <davexunit>writing a Scheme highlighter was easy, but highlighting XML revealed the state machine problem. <davexunit>you can only tell which it is based on what tokens you parsed earlier <vanila>that sounds like a pest, so is the idea to have a graph of states connected by tokens (defined as regexes)? <davexunit>something like that. I have read some of the Pygments code to see sort of how they do it. <davexunit>I actually wrote something that worked well enough, but I lost some important composability so I'm back to the drawing board. <vanila>one of the things I did in an earlier blog system was actually using emacs <vanila>it can output syntax-colorod HTML <vanila>since all the elisp code to syntax color every language ever already exists, it's pretty good <davexunit>I have some special needs. I want the highlighter to produce a simple list of tokens tagged with symbols that indicate which type of syntax they are: string literal, keyword, paren/curly/etc. <davexunit>from there, you can render it however you want <davexunit>for Haunt, I render it as SXML to become part of a document