<lispmacs[work]>are there any process signals (from kill) that will cause the program to throw an exception rather than just die? <clh3>maybe SIGUSR1, see (libc)Miscellaneous Signals <clh3>wingo: is guile-opengl ready for a new release? <dthompson>clh3: it needs the configure.ac file changed to accept guile 3.0 versions, if that hasn't been changed in the git repo yet (haven't checked in a long time) <clh3>dthompson: commit 4bfe3c9c appears to have made that change if I read it correctly. GUILE_PKG([3.0 2.2 2.0]) <xiews>(load "file") is ok, no error <xiews>Why do I have an possible unbound variable when calling a defined procedure? <xiews>I changed the procedure's name, then worked. Strange! <fnstudio>i'd be curious to know if there's any technical difference, i.e. if the two expressions result in different interpreter behaviour, and also if either of them is recommended for less-technical reasons, e.g. readability <fnstudio>i think i tend to like (let* ... lambda ...) more <fnstudio>it's more... hrm... flat? i think it's easier for me to parse <fnstudio>on a more specific note, the problem that's being solved here is the construction of a frequency table for a given list <lloda>i think i tend to do B but if for some reason i end up with A, like i c&p the define from somewhere else, i wouldn't bother to change it <fnstudio>lloda: cool, thanks!! so from a performance perspective there shouldn't be any major diff i guess <fnstudio>that same SO post mentions a purely-functional way to build frequency tables, but that doesn't seem to be immediately portable or at least SRFI-69 compliant <fnstudio>from the perspective of someone who's learning scheme, i'd like to understand the implications of a more or less relaxed approach about "purely-functional-ness" :D <fnstudio>however... that happens within a black box - which is the make-frequency-table procedure... <fnstudio>so i'm wondering whether that's actually functional - if looking at it from the outside :) <lampilelo>fnstudio: afair define in a lexical scope is just a syntactic sugar for a letrec* <lloda>fnstudio: imo that kind of detail doesn't matter. As you say it's a black box <lloda>at some level everything is loads and stores <lampilelo>and the implementation differs between different schemes <fnstudio>lampilelo lloda: ok, thanks, that's good to know and reassuring in a way <chrislck>moreover, keeping everything functional means you can't mutate a list or vector, so you'll need to constantly allocate. too much malloc and gc is not clever either. <fnstudio>chrislck: as in "recreate a new list each time and let the GC dispose of the old one" kind of thing? <chrislck>fnstudio yes. each (cons a b) does a C malloc() -- what does this do to memory & fragmentation & gc load etc? <chrislck>I love FP as much as ever, but I'm now more conscious of memory allocations <fnstudio>very interesting, yeah good point, thanks chrislck! <chrislck>for a scheme beginner don't sweat these little things :) <lampilelo>"Lisp programmers know the value of everything and the cost of nothing" <chrislck>fnstudio: to throw more confusion into the mix, having purely functional functions usually mean the program can become embarrasingly parallel... IIUC can't do that easily with mutated hash tables... <fnstudio>chrislck: hm interesting, although in the examples above (https://paste.debian.net/1213838/) the non-functional behaviour was isolated within a procedure, so in that case i wonder if it might be fine from a parallelisation point of view? <daviid>sneek: later tell vijaymarupudi could you paste the code that lead to this statproof, i'd like to check something, then i'll get back ... ***herlocksholmes7 is now known as herlocksholmes
<morganw>dthompson: Do you mind if I ask, with Chickadee (or just with guile-sdl2 and a minimal game loop) do you ever see any noticeable delays in the frame timing due to garbage collection? <dthompson>morganw: sometimes, but usually visible jerkiness is caused by other things. <dthompson>when I'm getting non-smooth animation, and I turn GC stats on, it's almost never the cause. <morganw>Thanks. Do you mean something like snapping to nearest integer positioning when tweening, or something going on behind the scenes? <dthompson>it could be any number of things, such as what you mentioned. <dthompson>could also be "temporal aliasing" when rendering is decoupled from state updates, as is the case in chickadee. <dthompson>smooth animation is surprisingly difficult. I still struggle with it. <dthompson>if you're allocating a lot then gc pauses can definitely contribute <dthompson>running your program with GC_PRINT_STATS=1 can be very helpful to see what's going on <dthompson>length of gc cycles vary, but it will almost certainly cause dropped frames. <dthompson>I just turned on gc stats for a program I'm working on and I saw a gc pause that took 86ms. for a game that's trying to update at 60hz, that's 5 lost update cycles! <fnstudio>hi, if i create a hash table via alist->hash-table from (ice-9 hash-table), am i allowed to later manipulate it with procs from, say, SRFI-69? <RhodiumToad>srfi-69's hash tables are a record type which includes a native hash table, plus the hash function and equality function for it <RhodiumToad>whereas the native hash table expects those support functions to be passed in on each call, or the shorthand calls that use eq? eqv? or equal? be used <fnstudio>ah, but here's the point... somewhere else in the same file i need hash-table-update!/default from (ice-9 hash-table), i think? <fnstudio>ok, sorry, my mistake then - i might be able to remove (ice-9 hash-table) as a dependency then <fnstudio>my confusion seemed to be around "hash-ref" which is in ice-9 (as opposed to "hash-table-ref" from srfi-69) <RhodiumToad>right, hash-ref is the native interface not the srfi-69 one <fnstudio>and... in terms of copying a hash table... i suppose i create a new one and then copy from the old one via hash-table-walk? <fnstudio>another option could be to convert the existing hash table to alist and convert it back to hash table therefore creating a new one, but it doesn't feel very clean? <fnstudio>but i'm sure it works, i'm updating my code, thanks lampilelo! <lampilelo>yeah, it seems it's not documented, but the file does export it <lampilelo>you can send a bug report to bug-guile@gnu.org <fnstudio>lampilelo: super, i will, thanks for now! <fnstudio>something else... (hash-table-ref (alist->hash-table '((0 1)(1 2))) 0) seems to return (1) as opposed to 1 <fnstudio>which i suppose is expected (but a bit surprising for me) <lampilelo>that's because your alist is a list of lists, not pairs <dsmith-work>fnstudio: That's because '((0 1)(1 2)) isn't an alis <fnstudio>well it may be obvious for you but it's a good catch for me!! it'd have taken me ages to figure it out :D <RhodiumToad>((0 1)(1 2)) is certainly an alist, but it's one where the values are (1) and (2) <RhodiumToad>an alist is simply a list where each element is a cell interpreted as (cons key val) <RhodiumToad>if val is itself a list, then every element of the alist is itself a proper list; the element is only an improper list if the value is an atom or an improper list <fnstudio>i realised that i end up with '(0 1) instead of '(0 . 1) in my real code, because of zip... investigating <lampilelo>you can do (map cons '(a b) '(1 2)) instead of zip <lampilelo>or map! if you don't use the first list ever again <jab>Hello, not trying to complain too much, but may I ask why error reporting in guile difficult? In C if I do a mistake C can usually pinpoint where the error took place be providing a line number...guile sometimes struggles with this. Is this common with scheme? <RhodiumToad>the difficulties are usually related to macro expansion <jab>RhodiumToad ohh...that would make a lot of sense.