<nly>nomad also needs some changes from emacsy wip branch. <janneke>nly: having a smaller emacsy package makes much sense, i'm not happy with the guile-emacsy name; it suggests a pure guile package, which it's not <daviid>janneke: is that so? i named guile-cv such, not because it is a pure guile module, which is not, but to 'invite' users to do cv in/using guile ... <daviid>janneke: in guile-cv, a user exclusively use guile scheme, does not even know some of the core procs are i C ... it seems to me that thatis te important bit in naming? <janneke>daviid: i cannot find a guile-cv package in Guix? <janneke>daviid: and also, emacsy is intended mostly as a C library to make any program behave like Emacs, Guile is in a way (a very nice) implementation detail <daviid>janneke: guile-cv is not in guix yet, i hope it will be i soon, it is 'in progress' - it needs a few texlive packages, and those were reworked, one named xkeyval, that guie-cv does not need but may indirectly depends upon, it seems, is not 'working', and 'blocking' guile-cv ... <daviid>janneke: ah, a C library , then i understand your comment <nly>> a very nice implementation detail :) <str1ngs>janneke: I'm pretty confident lib emacsy is simply for reentry from C. you can use emacsy purely from scheme. it's not even a guile extension. just to help with clarification <str1ngs>I'm also more partial to the emacsy name vs guile-emacsy <nly>janneke: wip merge into master will help ***ng0_ is now known as ng0
<daviid>str1ngs: I now have a working 'primitive' g-instance/goops instance cache in g-golf - a wip but it works pretty well <daviid>the big problem is that it's not gc friendly - it keeps those, i will need help fro advanced guilers to correct this <str1ngs>daviid: okay thank you I will look at it asap. you are protecting the objects I'm assuming? <daviid>str1ngs: it's not pushed yet, will let you know <apteryx>is it possible to access the source definition of a Guile object <daviid>str1ngs: successive calls to (webkit-web-context-get-default), for example, there are many other examples ... will return the goops instance of the first call <str1ngs>apteryx: maybe with source-properties <str1ngs>daviid great thanks will test this. I don't think this will have a huge impact on GC just yet. since single instances are not the norm. but I'll keep the GC aspect in mind <str1ngs>daviid this even works when I call (webkit-web-view-get-context view) <str1ngs>generally new views use the default context <apteryx>str1ngs: from the REPL, I try (source-properties some-defined-procedure) and it always seem to return () <apteryx>the procedure was imported from some module in Guile's load path. <str1ngs>apteryx: I get the same thing. but reading the docs if reading option position is #t which is default. supported expressions should have 'filename set <str1ngs>though I guess the question is what is considered a supported expression <str1ngs>I'm not sure why it's returning '() but it seems this is the way to get filename, line and column <str1ngs>hopefully someone more knowledgeable can help apteryx <manumanumanu>daviid: The thing is, I have written a for-loop implementation for guile, and if you provide a new iterator you need to add it to the list of valid iterators. If my program loads module a with (in-stream ...), (in-stream ...) should not suddenly become a valid iterator in modules that haven't loaded module a. Just keeping/mutating a list of valid iterators isn't enough. <manumanumanu>If I could have a "module-local" list of valid iterators that would be fantastic, but I don't know how to achieve that. <janneke>str1ngs: yes, emacsy can be used from guile, that's what guimax does; for now that's the exception though, we do not have many pure-guile gui programs yet <jcowan>manumanumanu: URL of your for-loop implementation? advTHANKSance <Wojciech_K>Hi! When I use macro inside a macro, how do I eval arguments of the outer macro before passing it to inner macro? Here's what I'm trying to do: <Wojciech_K>The problem is that i wan to pass `<my-name>` to inner macro instead of `(symbol-append '< my-name '>)` <manumanumanu>and produces just-as-fast-as-handrolled code after guile's optimizer has had it's way. <manumanumanu>Right now it works using macros that expands to functions that are inlined. (in-list lst) expands to 5 values: car (get element), cdr (next), null? (stop check) lst (starting value) and (lambda (x) #f). The last is a pre-check that checks the value returned by car if the iteration should stop. For lists it does nothing (and is eleminated by the optimizer), but for generators thats the only way to actually know <jcowan>Nice. It looks quite decently portable as well. <jcowan>I strongly urge to to write a SRFI for it. <manumanumanu>jcowan: I'm migrating to sourcehut though, so the new url is: hg.sr.ht/~bjoli/guile-for-loops <manumanumanu>As long as your scheme supports keywords it should be portable without much fuss. <manumanumanu>Guile allows me to match the keyword #:when using (syntax-rules (when) ...) as a literal, which I am not really sure how it relates to any standards <manumanumanu>jcowan: I might! It is probably the thing I have written that I am proudest of. I'll finish the transducers srfi first and then get going. <jcowan>Yes, the keywords would have to become auxiliary keywords, but I don't see that as a big issue. <manumanumanu>Works like a charm. I am just trying whether #:incr and #:decr are needed with the jit <manumanumanu>The jit makes the difference a lot smaller, but the code generated is probably sufficiently different for the JIT to not be able to sprinkle extra magic. <wingo>manumanumanu: probably you should use include-from-path rather than load-from-path fwiw <manumanumanu>I had 2 (in-something ...) to dispatch on things that could not be identified at compile-time. <manumanumanu>my son just woke up. We need to go take care of our tomato plants. see ya. <manumanumanu>dsmith-work: damn. I thought that was some kind of pasting error. <jcowan>Nope, it's a classic Usenet pun, when you might wait as much as a week for the answer to propagate back to you, and sending an extra "thanks" just didn't make sense. <str1ngs>janneke: more then likely guimax and nomad are the only programs using emacsy either way lol <nly>is there any way to use node js modules in nomad <nly>there is a perfectly usable implementation of dat, it's in node js tho <str1ngs>let me think on that. I think it might be a good idea to look at gnunet first mind you. in terms of adding a new protocol <str1ngs>this is why I question the use of node for a reference implementation :P <nly>haha, just no idea if that can be done, but it should be done 'sometime' <str1ngs>janneke: do you mind if I cherry pick hash 3ea7043975abd028de3bf0e1ed82c17535e83822 into master. it's the buffer-kill-hook commit <janneke>str1ngs: now that nomad is/nears 0.1, iwbn to create a new emacsy release <janneke>if possible using all of wip and wip-doc but i think wip-doc may need some cleanups/fixups <str1ngs>janneke: wip-doc looks good. the biggest issue is the race condition when killing buffers <str1ngs>that's the biggest issue I've found so far. I think including wip-doc is more beneficial then not including it. <str1ngs>also for nomad there is an API breakage with guile 3.0 when using change-class. it would help if text-buffer derived from metaclass <redefinable-class> . but unlikely guile 3.0 will be a factor for sometime just a FYI <str1ngs>mainly I'm changing text-buffer's like *scratch* and *minibuffer* to a widget-buffer. not sure how guimax handles those. but I found it easier to change them. <str1ngs>also as a side note, I'm not sure how useful local variables are. I think using slots is much easier. but that detracts from the emacs feel I guess. <str1ngs>janneke: if you are planning to merge wip-doc let me know. since I'll need to patch nomad to use with-current-buffer. it's a trivial fix on my end <Wojciech_K>I'm slowly coming to a conclusion that it's impossible with scheme-style macros <jcowan>Wojciech_K: You need to use a syntax-case macro that strips hygiene. You are trying to construct an identifier to appear in the output of a macro, and syntax-rules does not allow that. <manumanumanu>Wojciech_K: with guile you use, as jcowan says, syntax-case. There you can do (with-syntax ((my-identifier (datum->syntax stx-object 'my-identifier))) ...) *jcowan hopes that R7RS-large can standardize on something while avoiding the wars of religion (10 million deaths, even scaled down to the size of the Scheme community, is Pretty Bad). ***Marlin1114 is now known as Marlin1113
<manumanumanu>jcowan: What do you mean? There is the macro hygiene way, and there is the wrong way. :D <jcowan>Syntax-rules are well accepted. Beyond that there is: <jcowan>(a) syntax-parameters (hygiene can be bent but not broken) <jcowan>(b) four different potentially-unhygienic systems: syntax-case, syntactic-closures, explicit-renaming, implicit-renaming <jcowan>I like (a) but not a fan of (b) for myself, but I know lots of people like the ability to introduce identifiers in the macro output that weren't in the input. <jcowan>And although syntax-rules are Turing-complete, they are pretty hard to write code in, unless you use a package like SRFI 148, which helps a lot and is fully portable (except for the necessary hook into define/let/let*-syntax) <jcowan>(the hook's available in SRFI 147, which redefines these) <manumanumanu>jcowan: I always thought about rewriting the for loops in syntax-rules, but I never got to it. My cut-like threading macros were actually quite simple to write, and I needed something fun/painful.