<daviid>(parse-func-name "void\\nclutter_x11_set_display (Display *xdpy);") -> error ... could not parse ... <daviid>davexunit: fine, me neither :) the quizz is, should we expect ssax:xml->sxml to treat \\n or should it be parse-func-name and friends? if you lok at the code, line 136 and below, you see wingo did something to treat nbsp , maybe it shou7ld mange \\n as well ? don't know <davexunit>pardon this, but nice "public relations" work. :) <daviid>i don't see the post in the archive yet :( <daviid>davexunit: tx. couyld you give me some intuitive response wrt to this xml doc generation related bug ? <davexunit>some people on this thread are so frustrating. <davexunit>daviid: I'm sorry, I really can't tell what's going on in this code <davexunit>I don't even know what SSAX stands for, need to search. <daviid>davexunit: i don't either but my quizz is general , I think, and you have more xml related exp then I. so here is the summary: a file contains ...<programlisting language="C"><link linkend="void"><returnvalue>void</returnvalue></link>\\nclutter_x11_set_display (<parameter><link linkend="Display"><type>Display</type></link> *xdpy</parameter>);</programlisting>... <daviid>the above is parsed and right now \\n is not removed, so it leads to this call: <daviid>(parse-func-name "void\\nclutter_x11_set_display (Display *xdpy);") which fails <daviid>i wonder if i should post parse sxml and remove all \\n, like wingo does call zap-whitespace [for example] <davexunit>perhaps, if the string shouldn't have whitespace <amz3>without newlines in the sxml one can not render correctly things like html pre <daviid>ah ok, so you think i should leave them there and patch parse-func-name instead <amz3>yes. My previous comment is about another behavior of xml->sxml <amz3>or maybe it isn't. Sorry I'm confused. but sure you need to fix the gtk-doc proc <daviid>ERC> davexunit: ok, i'll fix parse-func-name for now and see how it goes <daviid>[ sorry i mistakanley copied part of the buffer here ... ] <daviid>amz3: yes i need to, i'm doing it :) the quiz was at what elvel, now i have 2 opnions, davexunit and yours in favor of preserving the \\n in the sxml, so i'll go ahead and patch at lower level, tx both! <amz3>the behavior that confuse me is newlines between two tags like <o><a/>\\n\\n<b/><o>. AFAIK html doesn't use this <amz3>that said, it makes sens <davexunit>ugh, this emacs-devel thread is just bad for my health. <davexunit>insisting that guile should stop saying its an extension language is such an absurd proposition. <amz3>there is no compelling reason to still to advertize guile as specifically an extension language, it can be said a good extensions language for x and y reasons. But an extension language? except LUA it doesn't exist and AFAIK guile doesn't compete with LUA in what LUA is good for <amz3>IIRC Civilization use Python as an extension language <amz3>I'm firm believer of the philosophy of writing software for next generation of hardware <amz3>this is kind of OT, but my point is AFAIK nobody looks for an extension language, but a good language <amz3>at least that's my position <amz3>my previous job, we were doing embedded dev using python, most of the software was c/c++ <amz3>I was doing embedded dev using python <amz3>the architecture was microservice ^^ <davexunit>amz3: thanks, I just stole the highlight colors from emacs ;) <davexunit>my new blog, when it's ready, will look like this. <amz3>tbh, i did not want my blog too look like a shoolbook <davexunit>I don't have a sharp eye for good design, but this pleases me. <amz3>it's kind of compliment realy <davexunit>but the important thing is that the body text is very readable <davexunit>I still have like 20 blog posts to convert, that will be the annoying thing. <davexunit>that means a lot coming from you, oh designer of such beautiful sites. <davexunit>the one thing I question is the font for the nav <sirgazil>Ha, designer... I design but I'm not a designer. I program and I'm not a programmer. <davexunit>it works well on the bigger headings, but seems to look a bit odd at 24px <sirgazil>although I have vision problems, so I may be missing minuscule artifacts. <davexunit>because finding and importing another font will be more work than I want to deal with. <davexunit>sirgazil: the d, h, j, l characters have some work "weight", I guess, at the top <davexunit>yeah, I need to finish the conversion in general. <davexunit>I'd like to convert my ReStructuredText formatted posts from my current blog to Texinfo posts. <davexunit>but I'm not sure how to hack things so that I can add a syntax highlighter. <davexunit>I'd also like to write an XML syntax highlighter, but it's a bit trickier than Scheme. <sirgazil>I also use reSt for my blog, how are you going to convert those? <davexunit>I don't have the energy to write an reSt parser <davexunit>would take more time than converting the posts by hand. <davexunit>holomorph: yes, it's quite nice! as is Linux Libertine from the same family. <amz3>davexunit: why did you write parse-one-or-more as it is written, instead of (parse-each parser (parser-zero-or-more parser)) <amz3>it doesn't work on my cps version for some reason <davexunit>amz3: probably because I wasn't thinking clearly <davexunit>your version would just need to flatten the result <amz3>that's I thought, but for some reason the code I just typed ^ does work, instead if i do (parse-any paser (parser-each parser (parse-zero-or-more parser))) <amz3>I mean the lastest code works, but not the previous one <amz3>but maybe it's cps that does shake things <amz3>yes, I think you did like that to avoid to wrap all the thing with `parse-match`... at least that's the reason i'll similar code <amz3>I think you are right, this combinator things is a loop hole <amz3>hopefully tomorrow I'll be smarter ;) <daviid>that solved it, but it now fails trying to parse a type using parse-func-name, don't know why it is even trying that <daviid>(parse-func-name "ClutterX11FilterReturn(*ClutterX11FilterFunc) (XEvent *xev, ...") -> could not parse ... the def in clutter-x11.h is: <daviid>typedef ClutterX11FilterReturn (*ClutterX11FilterFunc) (XEvent *xev, ClutterEvent *cev, gpointer data); <rekado>paroneayea: well-written post! (I didn't received it via email yet, but read on gmane.) <sneek>rekado, you have 2 messages. <sneek>rekado, a_e says: I can reproduce it. Try to open the file in a web browser. It redirects to rpmfind.net, which breaks tls. <sneek>rekado, a_e says: I can reproduce it. Try to open the file in a web browser. It redirects to rpmfind.net, which breaks tls. <rekado>it doesn't make sense for David Kastrup and Eli to continue to harp on string issues. Guile Emacs exists and is an improvement as the GNU project reduces repeated work and benefits from all the improvements of Guile without having to give up on elisp. (That perfect!) What's not to like? <rekado>I don't understand the string problems David and Eli talk about. Supporting this in a separate library (on top of bytevectors) is possible, right? So it's not a guile limitation. Is it just a matter of making the common string procedures work with such an extended string type? <taylan>I'm not sure if even that is necessary, for now. it's not an ideal state of things, but we could just live with Elisp strings being a separate data type for the time being. <taylan>David obviously has a lot of personal spite against Guile, there's no question about that :( <taylan>Eli has been making my life hell in the past few days wrt. my shell-quasiquote package, though I don't know if that's relevant to that topic <taylan>I've been warned about emacs-devel but I did not think it would be this bad. <csed>Is there another argument concerning Guile in emacs-devel? <amz3>but this is just a thread started by Chris <amz3>the real debate happens somewhere else <csed>In that beast of a thread on Emacs' Future, or what it's called. <amz3>IIRC, the debate is misleading, because the real future of emacs is supposed to be guile-emacs but for some reason people are rejecting it <csed>Sure. But are they rejecting them based on valid points against the switchover to Guile? <csed>Or just because they don't like Guile, or the devs, or whatever. <davexunit>iyzsong: I would ditch 'ticks-passed?', though. <davexunit>and stylistically, I'd prefer that 'match' were used instead of 'case' in 'symbol->sdl-eventaction' <iyzsong>ok, it's a macro in C, don't do much thing. sure, I'll use 'match. <davexunit>iyzsong: ah, I see. since it is literally just '>=', I think we can drop it. <davexunit>there's a good deal of the SDL2 API that simply doesn't deserve to be wrapped because it would be awkward to use and Guile does it better <iyzsong>I looked at the haskell-sdl2 bindings, it did wrap all the APIs. yeah, I'm not sure how to handle threads, so I leave the 'add-timer' (it run callback in seperated thread) FIXME.. <davexunit>iyzsong: at least initially, I'd prefer to avoid such functions. <davexunit>that could be easily implemented in Scheme instead. <iyzsong>davexunit: ok, I'd look into 'events' module this week, which should be chanllenge for me, at a glance I need to pass pointer of C struct forward and back. Will ask more if I can get out myself :-) <taylan>csed: from what I can tell, few of the arguments against GuileEmacs are valid <davexunit>some of arguments are valid in the sense that there *are* issues that need to be addressed, it's no silver bullet. <taylan>David Kastrup has a bad history with Guile, although he seems partly supportive now too... <davexunit>but no one seems to want to admit that guile-emacs is a serious contender. <taylan>maybe there's just disbelief because it's too amazing :P <taylan>"I don't want your *opinionated* [read: hygienic] macros!!" :\\ <davexunit>wow, a language doesn't support what emacs' (a 30 year old program about text manipulation) idea of strings are. what a shocker! <taylan>Elisp defmacro will stay anyway... <davexunit>I think that basic point is not making it to some <davexunit>and those that know that complain about string manipulation, which can totally be solved if people actually got their hands dirty. <taylan>davexunit: must it not be closed? <taylan>oh, it must be closed the usual way, I see <taylan>you'd think XML is smart enough to equate the two :\\ <taylan>hm, or maybe not, one being "empty string" and the other "nonexistent string" <taylan>do they also have different semantics in XML, or is the text of a <foo/> tag the empty string much like <foo></foo> ? <taylan>if they do have different semantics in XML, then one would expect SXML to also have a way to represent both. <davexunit>some tags behave as normal, some tags are special. oh, HTML <davexunit>there's a handful of tags that need an explicit closing tag, even if they have no child nodes. <davexunit>thus the reason I wrote a special sxml->html procedure. <davexunit>the version in the current blog post is a bit silly, I spend all this time processing escape codes, but it was all pointless. <davexunit>instead, just use a UTF-8 locale that doesn't need them! <taylan>mine doesn't have the void element handling... <daviid>gtk-doc.scm fails to parse "ClutterX11FilterReturn(*ClutterX11FilterFunc) (XEvent *xev, ClutterEvent *cev, gpointer data);" I fail to read/understand this C function def myself, can someone tell me how this reads/understands? <mark_weaver>daviid: that declares 'ClutterX11FilterFunc' to be a pointer to a function, where the function return type is 'ClutterX11FilterReturn' <daviid>now, I need to 'elimnate' that function to be parsed by gtk-doc, because it's only used by clutter_x11_add_filter and clutter_x11_remove_filter, which are ignored by guile-clutter, and did not find the right way to do so till now <daviid>so i tried to add "ClutterX11FilterFunc", also tried "*ClutterX11FilterFunc" and even "(*ClutterX11FilterFunc)", all 3 solutions compiles fine but gtk-doc still want to parse it <paroneayea>ACTION tosses in daily grumble about emacs-devel <daviid>this is prob because it calls parse-func-name before to compare xml function entries with guile-clutter internals <daviid>mark_weaver: could you help me to patch this code http://paste.lisp.org/+3D6P so it parse correctly the above because I don't know what it should return: "ClutterX11FilterFunc", "*ClutterX11FilterFunc" or "(*ClutterX11FilterFunc)" ? <daviid>from your explaination, it should parse the xml entry and return "ClutterX11FilterFunc" right? <zacts>mark_weaver: davexunit: I'm just curious but how far did you guys make it thru SICP? <davexunit>chapters 4 and 5 I have read a bunch of, but haven't done exercises. <daviid>hum, parse-func-name fails because no space between the function type and the function name, this 'works' but the result is not the expected 1 I think: (parse-func-name "ClutterX11FilterReturn (*ClutterX11FilterFunc) (XEvent *xev, ClutterEvent *cev, gpointer data);") <daviid>$12 = #{\\x28;*-clutter-x11-filter-func\\x29;}# <daviid>mark_weaver: should it not return clutter-x11-filter-func according to your explaination above? <paroneayea>however just yesterday I finally "got" church numerals, which was pretty cool? ***dje is now known as xdje
<mark_weaver>daviid: I'm not sure what that code should return in this case. there is no "function name" here, because a function is not being declared. <daviid>mark_weaver: I have quite a lot of these. I start to think wingo deleted these from original xml files because I did not change gtk-doc.scm till yestyerday and there a re lots of them since 0.6 <daviid>is string-value a guile core function ? <daviid>because it fails to give me something that match-bind can parse <daviid>as an example of the problem, and I have dozens of them. it seems that string-value has not been writtent to handle these func pointer defs, maybe <daviid>it's defined in gtk-doc.scm itself actually <daviid>I guess C can parse "void(*ClutterBehaviourForeachFunc) ...;", where our parse-func-name expect "void (*ClutterBehaviourForeachFunc) ...;" and the xml files do not write "returntype (funcname) ...;" but "returntype(funcname) ...;", for all of these <daviid>so, string-value is fine I think, but parse-func-name is not good enough <daviid>is there a regexp channel maybe? <daviid>is it actually possible? to find a regexp that handle these: "void(*ClutterBehaviourForeachFunc) (...);" <daviid>(define elt-str1 "void(*ClutterBehaviourForeachFunc) (ClutterBehaviour *behaviour, ClutterActor *actor, gpointer data);") <daviid>(define elt-str2 "void (*ClutterBehaviourForeachFunc) (ClutterBehaviour *behaviour, ClutterActor *actor, gpointer data);") <daviid> (match-bind "^(.*?) ([^ ]+) +\\\\((.*)\\\\);" elt-str2 (_ return-type name args) name (error "could not parse...")) <daviid>$21 = "(*ClutterBehaviourForeachFunc)" <daviid>but fails if elt-str1, help welcome <daviid>#regex suggest "^(.*?) ?([^ (]+) *\\\\((.*)\\\\);" intead of "^(.*?) ([^ ]+) +\\\\((.*)\\\\);", but then i have a compilation error ERROR: bad number of bindings to match-bind 4 5 <ArneBab_>daviid: doesn’t [^ ]+ match any non-space character, including any number of parens? <daviid>ArneBab_: I'm building a minimal example, just a sec and i post somethying you can try as well <ArneBab_>daviid: do you know regexp-builder in Emacs? <daviid>ArneBab_: don't much about regex actually, have a very concrete problem to solve, let me psate <daviid>put this content somwhere in your load-path and it will compile, but fail to parse elt2 <daviid>if you uncomment the second regex and comment the first [match-bind], it fauils to compile the file <daviid>i need to find a solution which both compiles and successfully parse the 2 examples <daviid>[ i'm exhausted by a lot of all very very complex project ... and few hours sleep ] <daviid>ArneBab_: could you reproduce the problem? <ArneBab_>daviid: sorry, I was just in another project… I’ll try <daviid>ArneBab_: oh, sure, take your time <daviid>why match-bind does not acccept "^(.*?) ?([^ (]+) *\\\\((.*)\\\\);" but accept "^(.*?) ([^ ]+) +\\\\((.*)\\\\);" is a mistery 
