***xaocon is now known as xaocon|away
<davexunit>I remember someone mentioning a way to test out macros from a repl. can anyone help me with this? <davexunit>I'm developing a 2d game library, so far I have the code broken up into 8 modules. As I write examples that show off features, I find that I'm importing almost every module for every example. Is it a best practice to write a module that re-exports the most commonly used procedures? <youlysses>davexunit: Still aimed at bullet-hell-esque games, or? <davexunit>... that I can then use to write a bullet hell game. :) <davexunit>but I also think every language needs a fun 2d game library. <youlysses>davexunit: Cool, glad to see that you eventually sided with the generic approach! :^) Link? <youlysses>Also you might want to stop by #lispgames, dto is working on a game-engine in CL. Maybe you to could swap notes? :^) <davexunit>youlysses: be warned: it's not really usable yet because it depends on patched versions of libraries <youlysses>No-problem, I'm just excited for the future potential out there... :^) *youlysses was thinking of writing bindings for allegro5 at some-point. <davexunit>my goal is ease of use + providing lots of goodies that everyone ends up needing anyway. <youlysses>davexunit: Oh wow, very possible I will at some-point! :^D <youlysses>davexunit: Any specific reasons, besides it's used more? <davexunit>I thought that it might be more beneficial to write a game library in Guile, for Guile. SDL is lower level than allegro. <davexunit>I use SDL to open a window and handle input. <youlysses>davexunit: I mean, can't that too easily be done with via Allegro? Is it that just doesn't suggest a lot of the higher-level stuff to-you by default, or? <davexunit>another compelling reason was that SDL bindings were already available. <davexunit>and my allegro bindings are incomplete and I got burnt out writing them. <youlysses>davexunit: There were already guile bindings for SDL?! <davexunit>waiting for a new release which will include the patch I need. <davexunit>I sent 2 patches to the guile-user list for adding functionality to figl that I needed, but I've gotten no response at all about them. <davexunit>wingo maintains figl and told me to send patches to guile-user. <davexunit>I guess he just hasn't had the time to review them. <youlysses>Though the lack thereof might be another motivation for me to have my hnd at playing with your bindings... at the very least for experience. :^) <davexunit>installing my allegro5 bindings should *just work* <davexunit>okay, time to figure out what guile-2d feature to work on <youlysses>davexunit: Did SDL 2.x ever come out, or is it still stuck in 1.2.x? <youlysses>Whatever... within a month-or-so's time... :^P *youlysses adds packaging SDL and related depends to his list of things to package for guix by the end of the year... hopefully. <youlysses>Wow, that list is certainly creeping up their. :^) <nalaginrut>set-http-proxy-port?! hah~interesting name convention ;-D <nalaginrut>is there slice function for list/bytevector ? like a[2:6] in python? <nalaginrut>I wrote such one, but I'd like to know if there's given one <taylanub>nalaginrut: While working on bytestructures I looked into R6RS as well as the Guile manual and couldn't see one .. in Guile you could do it with bytevector->pointer, pointer-address, +, make-pointer, pointer->bytevector, though. <taylanub>(And subtract from the length appropriately in pointer->bytevector, the same number you added to the pointer-address.) <taylanub>This will of course *not* copy, and re-use the same bytevector. <nalaginrut>taylanub: yup, I could use C for it, but I want to do all things in Scheme for Artanis <taylanub>If you abstract it well, the solution going over pointers should be acceptable I think, although I have yet to figure out how exactly bytevectors and pointers interplay with garbage-collection. <nalaginrut>hmm...seems I have to write bytevector-slice by myself <taylanub>For instance, I would expect (let ((address (+ -10000 (pointer-address (bytevector->pointer (make-bytevector n)))))) (gc) (pointer->bytevector (make-pointer (+ 10000 address)) n)) to cause a segfault, but it doesn't! <taylanub>It was printing the bytevector with the correct contents in the REPL .. <taylanub>Maybe the REPL did some magic that inhibited GC of some things .. I didn't try it in a stand-alone script. <taylanub>Actually, I'm doing something similar in the "test-suite" of bytestructures. <civodul>nalaginrut: for lists it wouldn't make sense, but for bytevectors a "subbytevector" procedure would be nice *taylanub would call it `bytevector-slice'. Descriptive names FTW. <taylanub>nalaginrut: I think ey meant that indeed it doesn't exist but should. <nalaginrut>because we have substring, similar with the things we're talking about <taylanub>I think "substring" is a relatively established term, whereas in the context of vectors one usually speaks of slices ... <taylanub>Although I'd also have preferred string-slice, for that matter. :P <civodul>taylanub: yeah, i was following "substring", but bytevector-slice sounds better <taylanub>That presumably copies, if it doesn't override the whole vector and bytevector types including their type-predicates ... <taylanub>Hrm, it also looks too permissive to me; should ideally have a parameter to enable sanity-checking, e.g. `to' not being greater than `from', bounds-checking, etc. <nalaginrut>I'll implement with pointer magic, I saw gist's version uses make-bytevector <lloda>For slices I wrote a wrapper over make-shared-array, it's in guile-ploy. <lloda>(from a (J 4 2)) => #(3 4 5 6) <lloda>it does any rank and explicit indexing too. <lloda>(define a #2((1 2 3 4 5 6) (11 12 13 14 15 16))) <lloda>(from a #t (J 4 2)) => #2((3 4 5 6) (13 14 15 16)) <lloda>(from a #t #(0 1 4)) => #2((1 2 5) (11 12 15)) <lloda>indices can be of any rank, too <lloda>I think it's fairly complete, as far as I could do without macros. <lloda>The slice is J which takes arguments as in iota (J count start step), but there's also range, as (range 3 7) => #(3 4 5 6) <lloda>It works with any array type, including bytevectors. <lloda>One thing that's missing is that when the result is not a slice (when doing explcit indexing) it can't be used as a reference. <lloda>Like (set! (array-ref #(1 2 3 4) 0) 9) doesn't do anything. It's something that's often needed though. <lloda>Also some macro for end-of-axis would be nice, like end in Matlab. <lloda>I had -1 as in Python or J, but that can't be used in Guile because the arrays don't have to be indexed from 0. <wingo>i had no idea that mentioning a pattern var twice in a match clause makes sure those vars are the same <wingo>at least i think that's what it does? <civodul>it's surprising the first time you see it :-) *civodul isn't able to do that <taylanub>`do' really has forgettable syntax. Let's see if I remember it right .. (do ((name init-val step-expr) ...) (done-p after-done-expr ...) body body* ...) yey, I think I got it right! <davexunit>mark_weaver: ah, thanks. I used (rnrs arithmetic bitwise) or something. <mark_weaver>taylanub: I don't think the "bytevector->pointer, pointer-address, +, make-pointer, pointer->bytevector" trick is safe. the problem has to do with garbage collection. if the original bytevector is no longer referenced, the garbage collector won't see the reference to it from the derived bytevector, and it could be freed. ***xaocon|away is now known as xaocon
<taylanub>Indeed, I warned nalaginrut about that .. I couldn't figure out a demonstration of the problem though. <mark_weaver>the reason is that the garbage collector only sees pointers that point to the beginning of an allocated block. <mark_weaver>to demonstrate, you'd not only have to trigger collection, but also the original memory block getting overwritten by something else. <mark_weaver>and beware that any object that's printed at the REPL will be saved as part of the history. <mark_weaver>so if you print the original bytevector at the REPL, then there's still a reference to it from the history, and it won't be reclaimed. <taylanub>Ah, so my trials didn't crash and even printed the correct values because the memory block was within the boundaries of the process' virtual memory and not overwritten ? <taylanub>Yes, I had cared to not have the REPL save the original BV. <mark_weaver>Boehm GC has an optional feature which would allow it to detect "interior pointers", i.e. pointers anywhere within a memory block, but there are two disadvantages to using that: (A) it greatly amplifies the possibility that the conservative scanning will see something that looks like a pointer but really isn't, and (B) it makes the GC slower iirc. <mark_weaver>note that a segfault can only happen if the entire memory *page* is released back to the kernel, and that cannot be done if there are any other blocks on that page that are still needed. <mark_weaver>the way I would try to demonstrate the failure would be to allocate a bunch of new bytevectors of the same size, and make sure to fill them with something different than the original bytevector. that should eventually reuse the memory from the original bytevector. <taylanub>I understand, thanks. I should probably fix my test.scm of bytestructures which likely has a small chance of misbehaving which I never triggered so far. :P <mark_weaver>Hi civodul! I hear you're going on a long vacation. Sounds great! Where to, if I may be nosy? :) <mark_weaver>(though you will of course be missed in Guile and Guix land :) <mark_weaver>btw, I realized that object properties can't actually work properly on large integers, because weak-key hash tables don't work properly with non-immediate keys. <mark_weaver>e.g. if you add an entry from 1/2 to #t, and the original copy of that 1/2 is freed, then the mapping is lost. <civodul>mark_weaver: roughly all around France, visiting people mostly :-) <mark_weaver>what I mean to say is that weak-key hash tables don't work as expected with non-immediate numeric keys when the equality predicate is eqv? or equal? <taylanub>mark_weaver: To generalize, I suppose we could say this is a problem with all things that are eqv? but not eq? ? <taylanub>How hard would it be to solve this problem ? I only have a vague imagination of how weak hash tables might be implemented, but at least according to that imagination it seems quite hard. <mark_weaver>I guess numbers are the only case I can think of where it's a problem in practice. in theory, we could handle numbers specially in the weak-key hash table code, but fixing it might be a bit hairy. <mark_weaver>equal?-based weak-key hash tables probably just don't make sense at all. <mark_weaver>anyway, it's a bit of a can of worms, and now I think it's probably best to leave object-properties as they are, and fix the docs. <mark_weaver>I guess the solution would be to use weak pairs only if the key is not a number. <mark_weaver>so you'd end up with weak key hash tables where some of the pairs are weak, and some are normal pairs. <mark_weaver>well, a subject better discussed in email, and better postponed to 2.2 (if at all) <taylanub>Hrm, do numbers not theoretically exist forever, and numerically equal literal numbers are always theoretically the same object ? In that case it would indeed be best to "secretly" make those entries strong, which will behave correctly for bignums. I imagine that would also be the expected behavior from users. <taylanub>(Yes, I'm most fond of the idea of numbers having object identity, and regarding eq? as a "slightly broken eqv?, working only on some data-types".) <mark_weaver>Ideally, we should hide the messy implementation detail that there might be multiple copies of the same number floating around the system. <mark_weaver>To my knowledge, only 'eq?' and weak-key hash tables reveal this messy implementation detail. <mark_weaver>I see two relevant equivalence predicates for numbers: numerical equality (=), and operational equivalence (eqv?) <taylanub>I think negative and positive zero should be = but not eqv? though. <mark_weaver>it's good to understand when each is required, and to use the right one. <mark_weaver>and, in systems that support multiple precisions of inexact numbers, a high-precision 2.0 is = to a low-precision 2.0, but they are not eqv? <mark_weaver>there may be other examples as well, relevant to exotic numeric representations. <taylanub>Numbers are more complicated than one would think. :) <mark_weaver>usually, = is what you want. but for memoization, 'eqv?' is what you want. <taylanub>I suppose these "eqv? but not =" numbers would be regarded as being different objects ? So making them secretly strong in a weak-key eqv? table would indeed work fine ? <mark_weaver>the = but not eqv? should be regarded as different objects. <mark_weaver>other way to think about it is that, ideally, numbers would be "interned", like symbols. <mark_weaver>however, while it is practical to intern symbols, because there are usually a reasonably bounded set of them in the system, it is *not* practical to intern numbers, since many programs generate too many different numeric values. <mark_weaver>hmm. I wonder if symbols are ever reclaimed by the system. if so, weak-key hash tables would have the same bug(?) for symbols. <taylanub>Indeed, and that's despite them being eq? after being re-interned, right ? (Because the hash of the name or so is used as the immediate value ?) <taylanub>I suppose a larger user-base would both detect these issues soon (good) but at the same time possibly cause some scorn due to bugs on the language-implementation level (not so good). :P Best to only get popular under friendly circles. :P <mark_weaver>this makes me think that weak key hash tables should use normal pairs for entries where the key is either a number or symbol. <taylanub>The special-casing is worrisome, but I suppose there's no way to generalize ? <mark_weaver>I agree. It's worrisome, and I wonder if it should be generalized somehow. *taylanub will drive home. Laters. <wingo>weak tables are different in master fwiw <mark_weaver>wingo: *nod*. the same bug exists though. I just checked. <mark_weaver>though I suspect that most any scheme/lisp system with weak-key hash tables has the same bug. I've never heard this issue discussed before. <mark_weaver>wingo: I think we should consider using normal pairs instead of weak pairs whenever the key is a number or symbol. <mark_weaver>well, for numbers I guess this would only be needed/wanted(?) for eqv? hash tables. <wingo>there are guardian problems in 2.0 and 2.2 as well <mark_weaver>I noticed that guardians are not thread safe in 2.0, but I guess you're talking about something else. <wingo>i think their interaction with weaks is wrong <mark_weaver>yeah, every time I've thought deeply about weak pointers, I find that there are inherent problems with them. I suspect that the basic concept is in need of refinement. <mark_weaver>hmm, it's a difficult problem to solve efficiently. how to determine if a guardian resuscitated the value? I see no way other than to postpone the finalizers until the next GC. <mark_weaver>at a low-level, maybe what's needed is the ability to register finalizers of different "orders", where only the first order finalizers are run initially, and the later ones are postpone for future GCs? <mark_weaver>I haven't yet looked, but are you satisfied with that solution? is there a reason it hasn't yet been merged? <wingo>it was because of the weak hash with custom predicates issue mentioned in that bug <mark_weaver>is the idea that guardians would have to explicitly tell the system that it has resuscitated the object? <wingo>or at least, i remember liking it ;) <mark_weaver>well, I'll read the bug rather than waste your time here :) <shanecelis>civodul: All right. Just workin' at real work now. <shanecelis>civodul: You're going on vacation soon, right? Where to, may I ask? <civodul>shanecelis: in different places in France <civodul>i know the mid-term evaluation is approaching <civodul>and i'll arrange to be available for that <shanecelis>civodul: Oh, I played around with using an alarm signal to kill a rogue coroutine. It works! <civodul>i'll be looking at your code tonight <shanecelis>civodul: cool. I did fix up the build so that hopefully it will build correctly for you. <civodul>shanecelis: talk to you later today! <shanecelis>Whenever I have a little error in some C code for guile, I get a screen full of warnings like this: <shanecelis>nsga2.nw:365:7: warning: indirection of non-volatile null pointer will be deleted, <shanecelis>You can do it from within the source code like this: <shanecelis>#pragma GCC diagnostic ignored "-Wnull-dereference" <mark_weaver>but I wonder if the code could be written in a way to avoid the warning. can you show me the code that caused the warning? <shanecelis>mark_weaver: I'm trying to create the smallest file that'll exhibit the problem, but now it's behaving nicely. ***sneek_ is now known as sneek
<mark_weaver>okay, so it seems that clang does not like our method of verifying that SCM_UNPACK is applied to a SCM value, on line 97 of libguile/tags.h <mark_weaver>I guess we should change (SCM*) to (volatile SCM *) on that line, to mollify clang. <mark_weaver>shanecelis: would you like to try making that change in tags.h and see how it works for you? ***fbs_ is now known as __^__
<shanecelis>mark_weaver: Thanks for the help! Squelching those errors the right way makes development much nicer. <mark_weaver>shanecelis: I just pushed the fix to the stable-2.0 branch <mark_weaver>definitely. reporting problems and reducing them to simple examples is very important work. <civodul>shanecelis: i'm having troubles with the line-pragma hash extension <civodul>returning *unspecified* causes the reader to try dispatching again on #l <civodul>and unless built with --disable-deprecated, Guile uses #l as arrays *civodul is running hello-emacsy ***fangism is now known as MI6-fangism
***MI6-fangism is now known as fangism
<jao>civodul, you're a natural-born early adapter :) <civodul>i'm also a mentor this time, so that doesn't really count ;-) <mark_weaver>civodul: regarding the hash extension returning *unspecified*, I would think that's the right thing, no? the reader must not return a datum for the pragma, and instead should continue reading what comes after. or so I would think. <civodul>mark_weaver: yes, but if you look at scm_read_sharp, if the extension returns *unspecified*, then it just tries to dispatch again *on the same character* <civodul>so in that case, that works when --disable-deprecated, but not otherwise <civodul>if you make it return #f for instance, it breaks in expressions where #line is in the middle <mark_weaver>I guess he should use a character that's not used for anything else. <civodul>because "line" starts with an 'l' :- <mark_weaver>I guess the reason is because his literate programming tool outputs "#line ..." and cannot be configured to output anything else? <mark_weaver>I suppose he could pass it through sed between noweb and guile. <mark_weaver>scm_read_sharp is kind of messed up. even if --disable-deprecated is used, it looks like for "#l", it will call scm_read_sharp_extension *twice*. once at the beginning of scm_read_sharp, and then a second time in the 'default' section of the switch. presumably when its called the second time, the port position has already been moved past the #line pragma. <mark_weaver>that first call to 'scm_read_sharp_extension' is probably a mistake. I remember looking at the commit that introduced it, and it looked half-baked. <civodul>to mimic what happened with earlier Guile versions <civodul>especially wrt. overriding behavior for some characters <mark_weaver>look at the comment on line 1667: "To remain compatible with 1.8 and earlier, the following characters have lower precedence than `read-hash-extend' characters.".. but now, *all* of the characters have lower precedence. <mark_weaver>at the very least, it seems to me a mistake that 'scm_read_sharp_extension' is called twice. if we really want it at the beginning, then it shouldn't be called later a second time. <civodul>hmm yeah, that's fishy in light of that comment <civodul>though it landed at the same time as the suspicious line <civodul>i guess the 2nd call can be removed without introducing any observable change? <mark_weaver>I think this merits discussion on the ML. As I recall, rotty feels strongly that 'read' should be able to read R6RS syntax reliably, without standard syntax being overwridden. <civodul>i'm currently summarizing the Emacsy issue in a message to shanecelis <mark_weaver>I think I'd prefer to add support for making local readers that behave differently than the standard reader, and to discourage use of the global reader options and extensions. <aleix>just thought i should step by and say hi :-) <mark_weaver>of course I'm interested in what other people think about the reader issue. <mark_weaver>aleix: thanks for all your work on guile packages. I still need to read the thread about asynchronous sockets on guile-user. <aleix>mark_weaver: np. happy to help. now we need people to use them ;-) <aleix>mark_weaver: about async socket. i basically asked what were the options, if any. from the thread, it seems the wip-ethreads branch is the most close to it, but i really haven't look into it. <mark_weaver>looking at that branch is on my (too long) TODO list :)