<rlb>...been side tracked lately, so not much public progress there for a bit, though I have been working on potential defrecord/defprotocol support off and on. ***terpri__ is now known as terpri
<wingo>landed a little patch to elide arity checks when callee is known <manumanumanu>wingo: cool! I have been thinking about what you said about how Cross-module inlining changes how we write code. I went back to some old guile 2.0 code, wrote some test benchmarks and started removing all the small tricks I used to make it run fast. It went from ugly code that used macros to inline things and a bunch of little ugly hacks to more or less standard scheme. Without sacrificing <manumanumanu>performance. Meaning: If I wrote that code today, I would have spent a lot less time making the code ugly. At least that specific kind of ugly <manumanumanu>wingo: did guile always check arities before? This seems like it could be a very nice addition in declarative modules... <wingo>manumanumanu: before, for calls that didn't end up being contified or inlined, guile would always check arities, even if the callee was known (i.e. callk instead of call) <wingo>now, if the compiler puts in a callk, it will later split the callee into two functions: one which checks the incoming arity and one that doesn't. the one that checks the arity tail-calls the one that doesn't. <manumanumanu>now, I am not really up with the terminology, but contification is where several calls to one function returns to one place; (if x (f x) (f y)) <wingo>then it will update any callk with compatible arity to instead jump to the new unchecked entry <wingo>yeah contification is if one function is always called with the same continuation. in that case it can be wired into the callee <manumanumanu>thanks. This seems like a wonderful little optimization addition then :) So, functions too large to be inlined, and uneligible for contification will become cheaper? ***nckx is now known as raghavgururajan9
***raghavgururajan9 is now known as nckx
<zzappie>leoprikler: oh i didn't know this algo (fisher-yates) <manumanumanu>daviid: I did not mean that in an insulting way. I was having to patch boot-9 of an installed guile that I meant as a hack. That is a sad way to have to go about it. <zzappie>daviid: How your students were using guile? Did they use emacs? I'm asking because my friend started using guile and I found that for unprepeared people guile causes huge amount of frustration... ***rekado_ is now known as rekado
<rekado>“guile causes huge amount of frustration” or Emacs? <rekado>I would agree that Emacs causes frustration, or at least learning Emacs while actually wanting to learn Guile. <rekado>that’s the motivation behind guile-studio <zzappie>If you not using emacs. And not used to search thing in info in emacs <rekado>guile-studio aims to make Emacs more useful out of the box for hacking on Guile, while also configuring away some of its weirdest quirks. <rekado>(it’s not 100% successful as some quirks still remain) <zzappie>rekado: Yeah I know about guile-studio It is great that you took time making it. But it still another editor with less quirks. :) People want to use their editor. <rekado>it just occurred to me that it would be useful to discover any manual related to Guile and add it to the intro buffer on the right. <rekado>oh, they *can* use their own editor. It just won’t have any integration at all. <rekado>(Emacs is not strictly necessary to read Info manuals; there’s pinfo or just info, but they are inferior to the info reader in Emacs) <manumanumanu>zzappie: if you ended up using guile's (random ...) you will need to seed it first, otherwise you will produce the same permutation every time you restart guile. <zzappie>manumanumanu: ah its not necessay in my case it for maze generations <zzappie>rekado: Yes. People need seacheable webpage with manual and lsp server today <zzappie>This will greatly lower barier of entry <zzappie>my friend was looking up racket manual because was lost in guile reference. <zzappie>And btw Im telling it just to find what's guile folks think on this issue. If the people think that opting for modern style of tooling is not worth it cause most of guilers gnu+emacs hackers than Its completely fine. But I had the impression that guilers want to widen the community *zzappie g2t afk for for few minutes <wingo>a better web interface for info files would be really great <leoprikler>I have yet to really integrate lsp-mode into my Emacs config, so yeah… <leoprikler>btw. I can't seem to get this deterministic randomness, that people speak of <manumanumanu>leoprikler: start guile, do (random 100) a couple of times. Restart guile. Do it again <leoprikler>I've copypasta'd the fisher-yates back and forth <leoprikler>In some implementations, I do initialize it, because I want to have a new state on each startup, in others I want the determinism and thus don't initialize it. <zzappie>hey is there such thing as portable scheme code? Meaning that you can just run it with most of cheme implementations? Sticking with r5rs enough or its harder than that? <manumanumanu>Sticking mostly to r6rs means guile and chez works just fine. <zzappie>manumanumanu: cool! need to try that one day <lampilelo>am i crazy or should (test-end) from srfi-64 not reset current test runner if it was installed globally? <lampilelo>am i supposed to set the test runner before every test-group call? <lampilelo>i think that's a bug, added by fixing another bug, in last august <leoprikler>i think most suites won't see that bug, since they have one group per file, but it does sound like a bug <lampilelo>srfi states that the runner should be removed in test-end if it was added by test-begin, but it removes it unconditionally <lampilelo>i think there's another bug: test-group expects the runner to be set, and errors out if it's not <lampilelo>manumanumanu: what do you mean by weird things? maybe the implementation is just buggy <manumanumanu>I have met cases where the reference implementation does not conform to the spec (one was however a misunderstanding). Taylan rewrote large chunks of it because he got tired of it <manumanumanu>If you need the flexibility of srfi-64 then srfi-64 it is. <manumanumanu>other than that, I am going to implement (chibi test) on top of srfi-64 whenever I have the time. That does less, and does what most people do want. <rekado>I used ggspec before I learned about srfi-64 <chrislck>ah ggspec... written by yawaramin for gnucash and never used <chrislck>he'd be proud to know it was actually used <lampilelo>i think i'll stick to srfi-64 because less dependencies <lloda>i'm sorry about the srfi-64 bug. I just applied the patch from upstream without giving it a second thought <lampilelo>i think the proper fix would be to install a cleanup function in the newly created runner's on-group-end field, but since it's a reference implementation i wonder if i'm not misunderstanding the srfi <abcdw>I get very strange behavior with my guile code: If I evaluate forms one by one, everything works as expected, if I evaluate the whole file it works differently. For purity extracted the code to separate file, still have the same issue. Can someone point out, what I did wrong?( <lampilelo>abcdw: does it work the same if you restart your repl and try again? <lampilelo>also why do you have the definitions wrapped inside a begin block? <abcdw>lampilelo: yes, tried to restart repl. Because I was experimenting with evaluating 4 those forms at once, works the same as evaluating the whole file. Nothing changes without begin. <abcdw>it's very strange, evaluating forms one by one produce different result from evaluating 4 forms at once using begin or C-c C-k. <apteryx>could someone walk me through understanding the primitive-fork return value? It can return either the 0, meaning we are in the child thread; or a pid, which means we are in the parent and got the pid of the child process; what I don't understand is given this duplicity and single call; how are the two conditions 'visited' in the parent thread? does it implicitly calls primitive-fork a second time <civodul>apteryx: child *process*, not thread <civodul>but yes, what you describe is correct <civodul>fork(2) creates a child process that's a clone of its parent <civodul>the only difference is that it returns 0 in the parent and the child's PID in the parent <civodul>now, in Guile, it's often "safer" to avoid 'primitive-fork' and use 'open-pipe*' & co. <apteryx>OK. I've seen this in the manual, but I need my open-pipe* to run with a specific user/group, and apparently we can't change the current process userid/groupid (that's in shepherd, probably because that process is PID 1?) <civodul>in Shepherd you can use fork+exec-command <apteryx>I also need to capture the output :-) <civodul>now you're too demanding, what can i do :-) <civodul>seriously though, we should have the whole gamut of process-fiddling procedures in a Guile module <apteryx>there's #:log-file that I could set to a temp file, but I'd have to adjust that temp file's permissions for the specific user/group <abcdw>civodul: Yep, it would be really cool to have a module with a bunch of helpers for running processes, capturing their outputs and so on. <apteryx>even in a child process of shepherd, I don't have the permissions to use setgid and setuid; ideas? In procedure setgroups: Operation not permitted <civodul>apteryx: you have to call setgroups before setgid and setuid <apteryx>I mimicked what the shepherd does in its exec-command procedure: (setgroups #()) before the setgid call, but that still fails. mmh. ***Noisytoot_ is now known as Noisytoot
***drakonis1 is now known as drakonis
<apteryx>perhaps something to do with the CAP_SETGID capability <apteryx>I'm testing the Shepherd service via the Guix system test framework <rlb>wingo: regarding the approach I've been toying around with for utf-8 strings. If stringbufs are immutable, and we still support shared mutable strings/substrings on top, and if we're going to atomically/locklessly swap the string stringbuf whenever there's a modification, then that means that competing string-set! calls (on strings that share the same mutable stringbuf) might lose updates? If so, is that "don't do that then", or a <rlb>critical difference/problem with respect to the current behavior? <lampilelo>no, that's not my issue, i've already submitted a patch to srfi's mailing list <rlb>e.g. given competing (string-set! x 5 #\x) (string-set! y 11 #\y) calls, there's a read/update/write(swap) race. So #\x or #\y could be lost from the final stringbuf, etc. With the current code, of course, and assuming no "torn word writes", both should eventually "settle" thread-visibility-wise. <rlb>(And also, of course, the performance of one-at-a-time string-set!s is going to be atrocious for non-ascii strings anyway, so eventually, you'd want to avoid that whenever you can...)