IRC channel logs


back to list of logs

<daviid>davexunit: this is the code used which calls, in summary, (ssax:xml->sxml and some xml files has \\n in some of there 'blocks', raising erros like this:
<davexunit>daviid: tbh, I haven't used SSAX
<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>paroneayea: *awesome* post to emacs-devel
<davexunit>pardon this, but nice "public relations" work. :)
<daviid>i don't see the post in the archive yet :(
<davexunit>daviid: the GNU archive takes awhile, but check gmane:
<paroneayea>davexunit: :)
<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.
<davexunit>"Guile-Emacs is not a serious contender."
<davexunit>IT ALREADY WORKS. (need to calm down here)
<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]
<daviid>or patch at a lower level
<davexunit>perhaps, if the string shouldn't have whitespace
<davexunit>xml->sxml will preserve such whitespace
<amz3>without newlines in the sxml one can not render correctly things like html pre
<davexunit>because it's significant in text nodes
<daviid>you mean cariage return
<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>davexunit: ok, i'll fix [20:23]
<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!
<daviid>going afk for a bit, bbl
<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>I disagree.
<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>Maya use Python
<amz3>Blender: Python
<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>syntax highlighting for scheme looking pretty nice:
<amz3>nice theme
<davexunit>amz3: thanks, I just stole the highlight colors from emacs ;)
<davexunit>my new blog, when it's ready, will look like this.
<davexunit>took inspiration from rekado's blog and have been reading "Practical Typography"
<sirgazil>simplicity is beautiful :)
<davexunit>sirgazil: yes, indeed. what do you think?
<sirgazil>beautifuly simple :)
<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.
<sirgazil>very nice
<amz3>it's kind of compliment realy
<davexunit>part of me thinks "is it too plain?"
<davexunit>but the important thing is that the body text is very readable
<davexunit>and all I did was follow those key rules
<davexunit>I still have like 20 blog posts to convert, that will be the annoying thing.
<sirgazil>I think it is not plain but clean.
<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>It looks good to me in the screenshot
<davexunit>okay thanks
<davexunit>I'll stick with it for now
<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
<sirgazil>I hear you
<sirgazil>Yes, I can see that.
<sirgazil>But I would use it as is.
<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>by hand.
<davexunit>I don't have the energy to write an reSt parser
<davexunit>would take more time than converting the posts by hand.
<holomorph>biolinum <3
<davexunit>holomorph: yes, it's quite nice! as is Linux Libertine from the same family.
<davexunit>I "stole" these fonts from this really nice rendering of SICP
<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
<davexunit>so it's one list
<davexunit>(a a a) not (a (a a))
<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>it works
<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
<daviid>here is what i came up with: [see line [6 - 8], no big deal but any better/faster way and/or code review welcome
<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);
<nalaginrut>morning guilers~
<zacts>hi guilers
<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, which breaks tls.
<sneek>rekado, a_e says: I can reproduce it. Try to open the file in a web browser. It redirects to, 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.
<iyzsong>davexunit: hi! I'll do some work for guile-sdl2 to learn guile's ffi :) I have wrap the timer module and define the enums for event types. please look my code, do you think it's on the right path?
<davexunit>iyzsong: wow, awesome!
<davexunit>yeah, looking good!
<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
<davexunit>for instance, the thread stuff.
<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 :-)
<iyzsong>can't get out of troubles :-
<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.
<davexunit>people talk about it like it just an idea.
<taylan>maybe there's just disbelief because it's too amazing :P
<davexunit>so many of the arguments are just absurd
<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!
<davexunit>taylan: to that I say 'syntax-case'
<davexunit>have fun.
<taylan>Elisp defmacro will stay anyway...
<davexunit>yeah of course
<davexunit>all of elisp will stay
<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.
<davexunit>woo, got xml highlighting now!
<taylan>davexunit: why the "what?" ?
<davexunit>taylan: the <script> tag is invalid
<taylan>davexunit: must it not be closed?
<davexunit>this is a rendering of a portion of this article
<taylan>oh, it must be closed the usual way, I see
<taylan>you'd think XML is smart enough to equate the two :\\
<davexunit>this is an HTML quirk
<davexunit>it's not how XML works
<taylan>hm, or maybe not, one being "empty string" and the other "nonexistent string"
<taylan>oh ok
<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.
<taylan>I see
<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>I also have the super minimal FWIW
<davexunit>oh cool
<davexunit>didn't know about it.
<davexunit>this is mine:
<taylan>oh yeah, I also needed (setlocale LC_ALL "") in
<taylan>(that blog is yet empty)
<taylan>mine doesn't have the void element handling...
<paroneayea>rekado: thanks!
<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>mark_weaver: ok, here is the entry for the record:
<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>'make generate-defuns' will not try to buid the doc for any function that has to be ignored. in the case of clutter-x11, functions that are ignored are here:
<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 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>zacts: I read the book out of order
<davexunit>chapters 4 and 5 I have read a bunch of, but haven't done exercises.
<zacts>ah cool
<davexunit>chapters 1-3 I've mined rather thorougly
<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>I'm still struggling my way through SICP
<paroneayea>well, enjoying it :)
<paroneayea>but it's hard for me
<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>mark_weaver: here
<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>it's defined here, line 369:
<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>where are the match and match-bind experts :) to save me some time patch this so it handles the above?
<daviid>is there a regexp channel maybe?
<daviid> why is that?
<daviid>oh ok
<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>,use (match-bind
<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>oh sorry tipo
<daviid>[ i'm exhausted by a lot of all very very complex project ... and few hours sleep ]
<daviid>and here is the compilation failure if I use the regex proposed by the regex fols on #regex
<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