<daviid>ArneBab_: you don't have it installed ? <daviid>let me paste, it could be it comes with guile-gnome <daviid>ArneBab_: it's part of guile-lib actually, fyi <paroneayea>ACTION forks an alternate timeline where he begins hacking on advancing guile-emacs <paroneayea>you can merge alternate timelines without serious conflicts later, right? <daviid>ah! super, when they have g-wrap, guile-cairo, guile-gnome and guile-clutter then it will be paradise <ArneBab_>daviid: do you want to include the parens in the name of the function? <daviid>ArneBab_: not mandatory, these are actually not used, so my problem is more to make the thing compile and parse correctly, thenb the returned name could be without <daviid>but i wonder why match-bind does not compile, sounds like a bug to me <daviid>but i'm neither a regex neither a syntax pro super pro, and the code ws written by wingo, who's rather inaccessible these days <ArneBab_>"^(.*?) ?\\\\(([^ ]+)\\\\) +\\\\((.*)\\\\);" <ArneBab_>it’s important to keep in mind that regexp is greedy — always matches as much as possible, so if a clause is too general, it will just match more than you want <ArneBab_>is (return-type anything)(at most one space)\\((function-name anything-but-space)\\)(any-number-of-spaces)\\((arguments anything)\\) actually what you want? <ArneBab_>cat it have 2 spaces between return-type and function-name? <daviid>ArneBab_: i don't know because it comes from gtk xml doc. ity is obvious to me that what we used to parse has changed between clutter 1.10 and 1.12, including existing API, not just new one <daviid>from mark_weaver explaination on about what it means in C, ClutterBehaviourForeachFunc is a vairable which is bound to a pointer to a function 'void' in this case, the name could even drop the * in front <ArneBab_>does it have to have a space between function and arguments? <ArneBab_>"^(.*?) *\\\\(\\\\*([^ ]+)\\\\) *\\\\((.*)\\\\);" ← more general and drops the * <ArneBab_>I’m procrastinating… … … but still glad to help :) <daviid>ok, it pass the above and fails with another gtk-doc weird stuff: <daviid>"ClutterEffect\\xa0* clutter_page_turn_effect_new (gdouble period, gdouble angle, gfloat radius);" <daviid>this \\xa0* is prob a new thing too <daviid>ArneBab_: parens are exe4pctional <ArneBab_>ok, so we can’t require parens around the first <daviid>the regurlar is more like this [without \\xa0] <ArneBab_>ugh… I hope it isn’t seen as whitespace in regexp <daviid>i could remove these before to pass to the regex <daviid>so. let's concentrate on the regex because this fails as well: <daviid>(parse-func-name "ClutterEffect* clutter_page_turn_effect_new (gdouble period, gdouble angle, gfloat radius);") <ArneBab_>"^(.*?)( +| *\\\\(\\\\*)([^ \\\\)]+)(\\\\) *| +)\\\\((.*)\\\\);" <daviid>which land in sxml as ((programlisting (@ (language "C")) (link (@ (linkend "ClutterEffect")) (returnvalue "ClutterEffect")) "\\xa0*\\nclutter_page_turn_effect_new (" (parameter (link (@ (linkend "gdouble")) (type "gdouble")) " period") ",\\n " (parameter (link (@ (linkend "gdouble")) (type "gdouble")) " angle") ",\\n " (parameter (link (@ (linkend "gfloat")) (type "gfloat")) " <ArneBab_>this? "^(.*?)( +| *\\\\(\\\\*)([^ \\\\)]+)(\\\\) *| +)\\\\((.*)\\\\);" <ArneBab_> "^(.*?)( +| *\\\\(\\\\*)([^ \\\\)]+)(\\\\) *| +)\\\\((.*)\\\\);" <daviid>cool!! including these unicode characters ? <daviid>so i don't need to look for and change these \\xa0 anymore <ArneBab_>but with more prodding and experimentation than should be needed :) <ArneBab_>this could run into problems on creative use of parens <ArneBab_>it should require a lot less guessing to write :) <ArneBab_>the seps can either be one or more spaces or any number of spaces and a paren <daviid>ok, at least till now it did work for clutter defuns <ArneBab_>foo (goo ) (loo) would throw an error, I think, but would likely be valid C <daviid>ArneBab_: yes, no valid |C is not expected <daviid>invalid C is not expected i ment <ArneBab_>but valid C could be seen as error in this <daviid>but i see gtk-doc generator introduced bunch of unicode stuff since <daviid>ArneBab_: great! me too and will call you if other problem raises [need to parse stubs and undocumented <ArneBab_>"^(.*?)( +| *\\\\( *\\\\*)([^ \\\\)]+)( *\\\\) *| +)\\\\((.*)\\\\);" <ArneBab_>works for this: "void( *ClutterBehaviourForeachFunc ) ( ClutterBehaviour *behaviour, ClutterActor *actor, gpointer data );" <ArneBab_>"^(.*?)( +| *\\\\( *\\\\*)([^ \\\\)]+)( *\\\\) *| +)\\\\((.*)\\\\) *;" <daviid>ArneBab_: what is your real name, I would be happy to thank you when relerasing guile-clutter if it's ok with you <ArneBab_>"^(.*?)( +| *\\\\( *\\\\*)([^ \\\\*\\\\)]+)( *\\\\) *| +)\\\\((.*)\\\\) *;" <ArneBab_>(because the regexp was greedy in the wrong direction) <ArneBab_>this is more restrictive than the previous one, can you test run it once more? <jmd>Yeah. I've been doing other things. <jmd>I hope to restart with guix again soon. <jmd>But I'll have to reinstall it from scratch. ***lloda` is now known as lloda
<jockej>the guile documentation on elisp is... terse <jockej>but I had a question about scope in guile-elisp: if variable foo is set in <jockej>thread A, and thread A spawns thread B which sets foo to another value, does A <jockej>see the new value of foo or the original one? <iyzsong>I'll be surprise if a variable binded to different values in different threads. but I don't know any elisp :-) <jockej>it says in the manual that guile supports it with fluids <jockej>but it doesn't say if it's done automatically for elisp... <iyzsong>ah, I haven't know fluids, read it. thanks <jockej>but actually what I was thinking about was how to implement some sort of <jockej>and I thought I'd start with looking at GuileEmacs, since that gives a lot <civodul>anyone knows the Parabola/Arch command to install Guile 2.0? <Tsutsukakushi>civodul: how did you manage to install parabola without using the package manager :o <civodul>well i actually use GuixSD as you can imagine ;-) <civodul>but i wanted to put that on the new web site <taylan>ACTION used Arch for years, never tried to figure out what the S stands for :P <davexunit>that was just the thing I knew I had to do to make it work <ArneBab>jockej: that sounds interesting (using guile-emacs to add threading to emacs — actually using it for one of the things for which is was created ☺) <jockej>yeah, I figured it would be a good place to start :) <jockej>unfortunately I'm not really either a guile or an emacs hacker <jockej>I've been wanting to learn scheme properly wince I read SICP <mark_weaver>jockej: the main problem with implementing threads in emacs is that none of the code in emacs does not do any thread synchronization, e.g. locking. <jockej>yeah, I know, but I had some ideas... <jockej>which are probably dumb, but still <jockej>something like letting a thread own a buffer, and then maybe lock that <jockej>buffer from modifications by other threads <jockej>basically the first thing I want to do is to be able to have to heavy calc <jockej>calculations running in two different buffers simultaneously <mark_weaver>I don't know enough about emacs internals to know what would be needed to make that safe. <mark_weaver>certainly if you avoid emacs operations entirely in the other threads, that should be fine. <jockej>yeah, but then it's just like async processes <jockej>but this 'fluids' concept seems promising <mark_weaver>and it might also be fine to run elisp code in other threads if they avoid touching global data, but I don't know which operations access global data _implicitly_ <davexunit>jockej: see also 'parameters', built on fluids. <jockej>mark_weaver: probably most of them <jockej>but I don't think there's that much data which _needs_ to be truly global <davexunit>IMO, elisp would benefit more from cooperative multi-tasking <jockej>hm, ok... I'm not sure what that means... <davexunit>maybe you know of the term "goroutines", from the Go programming language. <davexunit>or, without the cute Go language, coroutines. <jockej>I've seen them implemeted in beautiful cpp macros :) <jockej>it used __LINE__ as switch targets... <davexunit>but yeah, a cooperative multi-tasking system would allow for multiple "threads" without using pthreads. <jockej>but it sounds harder to implement <jockej>and it still limits it to one core... <davexunit>my feeling is that thread synchronization sucks, and I'd rather use cooperative multi-tasking + multiple processes. <jockej>but don't you have the same synchronization problems with coroutines? <jockej>yeah, but if the different thunks touch global data it will effect the <jockej>they all reference the same global data <davexunit>well, yeah, but that's the case with threads, too. <davexunit>but with threads, you introduce the problem of 2 threads trying to write to the same place <davexunit>so you need locking mechanisms in place to manage that <davexunit>this problem does not exist with coroutines. <jockej>yeah, that is a downside, but I don't think it has to be too bad <davexunit>coroutines have other advantages, since in Scheme continuations are first-class. <davexunit>pthreads still have uses, of course, I just think the set of those uses is a lot smaller than other people think. :) <jockej>yeah, I've only done parallel in pthreads and MPI, so I really don't know :) <jockej>But I'd sure like to be able to max out my six cores in Emacs :) <iyzsong>davexunit, taylan : hi! I get 'sdl-poll-event' working by using 'bytestructures' to handle SDL_Event. <amz3>Using multiple results parser combinator, I'm wondering how to choose the correct result <davexunit>iyzsong: cool! though, I'd like to avoid adding extra guile dependencies. <amz3>Both results are correct according to my understanding of the parser, but I wonder how to cut some results <amz3>seems like... impossible! <davexunit>amz3: you have an interesting problem on your hands. I don't know the solution. :) <amz3>I will try to model another language <iyzsong>taylan: the numeric types (int, uint8, etc) from 'bytestructures' names conflit with 'system foreign', but bs:union, bs:struct is prefixed. I think it's better remove the bs: prefix from them or add prefix to numeric types. <davexunit>iyzsong: if you show me the code, I could help translate it to use something more primitive. <iyzsong>I don't know how to do it more primitive :-) <iyzsong>the SDL_Event is a union of various structs <iyzsong>I only write 3 for example, there is a lots.. <davexunit>I'll think about it. I want a bytestructures API to make it to Guile core. <davexunit>I think we'll need a macro of our own that does what we need. <amz3>the way handle structures in wiredtiger, is to convert them to structure, I don't have union tho <amz3>"convert them to records" <amz3>(nor do wiredtiger have nest struct) <iyzsong>also, I find another active chicken-sdl2 bindings, it look cool :- <amz3>you know how they solve your problem? <iyzsong>amz3: I don't know, but I can look it for references.. <amz3>the funny thing, is that the wrong result comes from an alternative parse, when deep in the grammar it fails and choose an alternative <amz3>the same parse that fails, has an alternative successful parse <davexunit>chicken has built-in methods of dealing with C structs <taylan>iyzsong: yay, I think you're my first user. :-) all feedback welcome. regarding the conflicting names, the intent is that eventually the low-level FFI types become obsolete for users... <taylan>I have some plans to work on a proper FFI integration so one can use bytestructure descriptors directly to wrap a C function with a given return value and argument types. (the return value type, and each argument type, would be represented by a bs descriptor.) <taylan>I don't know when exactly I'll have time to work on it though <amz3>maybe it can emerge, as people use it <davexunit>taylan: I want to poke at bytestructures a bit sometime. <davexunit>I see some things I'd like to change, from seeing iyzsong's code. <davexunit>your library wants to be portable, I imagine, but I would like to use some guile-specific stuff like wrapped pointer types <davexunit>and have something like a 'define-struct' form that creates a wrapped struct + accessors for each field. <taylan>davexunit: Guile-specific submodules can go under the guile/ directory. see e.g. guile/pointer.scm <davexunit>okay. ideally, I'm interested in the relevant code making it to Guile core <davexunit>after much back and forth where the maintainers find serious flaws in the code, as usual. :) <davexunit>which reminds me that I need to finish up (ice-9 json) <amz3>so (ice-9 match) can replace cond <davexunit>sometimes 'cond' makes for nicer code, sometimes 'match' does. <davexunit>does anyone know any good resources with "rules of thumb" for syntax highlighters? <amz3>It doesn't have much blog subscribed feel free to send you url, this will higher up the motivation ;) <davexunit>I'm currently struggling with how to treat invalid syntax. <amz3>I think most highligher use regex rules <davexunit>I see that a lot of syntax highlighters are able to move on and keep highlighting when encountering something they don't recognize. <davexunit>I probably shouldn't worry much about how to handle invalid input. <davexunit>write a strict lexer, and if something fails, bail out and the rest of the code will appear unhighlighted. <ArneBab>artyom-poptsov: it looks like a mix between star trek and a special coin <taylan>davexunit: heh, that's one of the reasons I heard against using IDE-style code parsing syntax highlighters (that they can't deal with errors well). but I don't know how improper ones handle it... <taylan>(with "improper" I mean ones not based on full code parsing) <davexunit>taylan: yeah, maybe I'm totally misguided with guile-syntax-highlight. I hope not. <davexunit>but my needs are for highlighting valid source code. <davexunit>pygments also states that their purpose is to highlight valid code, not invalid code. <ArneBab>amz3: … that wasn’t the right rss, sorry <taylan>davexunit: oh yeah, what I heard was specifically about text editors, in which "broken" (incomplete) code is the norm. I guess full parsing is better for static content. <davexunit>all I can really know is what works for me, so I'll press onward with my blog. <artyom-poptsov>ArneBab: You're right, it's a reference to Star Trek. The idea is that the logo represents a lambda, GNU Guile and everything else inside the Universal REPL :-) <amz3>ArneBab: it doesn't support rss :/ <daviid>artyom-poptsov: hey, what are you hacking on? <daviid>ArneBab: heya, what is your email? <daviid>I won' tbe able to relese guile-clutter tody as I said. now that the doc generation works again, I have 50 more .texi entries [need to visually parse and select the ones to keep, such as scroll-actor, grid-lauout ... and the rest of the doc entirely changed, ned tp proof everything is ok ... so, 1 more week I guess <daviid>davexunit: since you played recenly with guile's texinfo modules, let me ask if ... in case you can point me to the right direction; <daviid>I now have [actually this was true before solving gtk-doc.scm] thousands of the following warnings: <daviid>./defuns-clutter-actor.xml.texi:10: @subsection seen before @end deffn <daviid>./defuns-clutter-actor.xml.texi:15: unmatched `@end deffn' <daviid>which come from (stexi->texi `(*fragment* ,@(apply make-defuns sdocbook defs-alist args))) <daviid>i need to dig further down, but wanted to know if you thik it could be stexi->texi creating texinfo 4.x vaild code but 5.x invalid code ? <bubu^>hello any plans to release a 2.0.12 update ? <sneek>Welcome back bubu^, you have 4 messages. <sneek>bubu^, lloda says: (--1--) Guile arrays are by default row-major (C order, last index fastest) not column-major (Fortran order, first index fastest). This shouldn't matter if you operate at a high level, but ops that traverse the array in order (e.g. array-for-each) always do it in C order. (--2--) Guile has a single slicing operation, make-shared-array. It's THE operation you want if you can only have one. However, it's very slow <sneek>bubu^, mark_weaver says: lloda went on the say: "However, it's very slow and inconvenient to use for the more common rectangular slicings. So I've written a wrapper around it called 'from'. You can find it in gitorious.org/guile-ploy. Take a column with (from A #t column-index) or a row with (from A row-index #t) or simply (from A row-index). This is actual slicing, i.e. no copies." <sneek>bubu^, mark_weaver says: lloda: "You can use it for more general operations such as (from A #t `#(,index0 ,index1 ...)) to pick any set of columns, in which case it does make a copy. There's also a (reshape) op and other utilities." <sneek>bubu^, mark_weaver says: lloda: "Many things are missing to have a complete array library, but please give it a try. (--3--) The idea is that Guile will eventually provide either less general but faster slicing operations, or direct access to the dope vector from Scheme. Then I could rebase (from) on top of that. (--4--) Thanks for reading!" <daviid>you see that it used to generated arguments and returned value(s) using a table, where as now, for isterious reasn to me still,, it uses @subsection Parameters, @subsection ret and subsections are not allowed whithn the core of a @deffn <daviid>no one here has experience with the guile-gnome guile-clutter doc generator? <daviid>and it breaks even make. so here the deal, i will stop working on the doc for now and release 1.12.2 with the 'old' doc still, pointing to the [excellent] clutter 1.12.2 doc. so, to do so, i will now concentrate on guile-lib [we want pkg-config support, i should be quick on this one], then pseudo release guile-cairo [will upload to my grip repo, because 1y commiter pending request is enough :) and both guile-gnome and guile-clutter <daviid>needs guile-cairo 1.10 [which itself needs love, make check fails], then release guile-clutter 1.12.2 and simusltaneusly grip [gri-clutters has good examples, and writting good examples need a good toolbox, otherwise you end-up writting "hello world" 'only', and that does not help beginners: gripclutter examples rocks! :)]