IRC channel logs


back to list of logs

<lispmacs[work]>after the interpreter catches an uncaught exception, and we enter a new prompt, is there a way I can get access to the stack object which ,bt is focused on?
<lispmacs[work]>or get a copy of it?
<lispmacs[work]>Or do I need to set up some kind of catch that gives me the stack object?
<lispmacs[work]>I am able to get the stack object by doing a with-exceptiion-handler where the handler sets a top level variable to be equal to the return value of (make-stack #t)
<lispmacs[work]>I am able to run various stack/frame procedure on the object
<lispmacs[work]>most seem to be working, except somewhat mysteriously display-backtrace on the object will not give any output
<lispmacs[work]>even though I can pull the frames from the object individually and view them
<lispmacs[work]>oh wait, it looks like display-backtrace is doing something to the current-output-port.
<lispmacs[work]>so I have to save the current-output-port to an object and pass that object in
<lispmacs[work]>when interpreter's debugger catches an exception, and the exception is continuable, is there some way I can make execution continue?
<lispmacs[work]>or is that what ,finish does? I'm still vague on it
<lispmacs[work]>I know from the docs that if with-exception-handler catches a continuable error, the handler will be run in tail position to the raise-exception call
<lispmacs[work]>was thinking I should be able to make that jump from the debugger
<lispmacs[work]>I suppose I could create a handler of my own that allows me to do stuff in a new prompt and then continues...? but is that already doable from the debugger?
***karlosz_ is now known as karlosz
***chris is now known as Guest4840
<fnstudio>is there any direct way to get the position of an item in a list, e.g. anything simpler than: (list-index (lambda (x) (equal? x item)) lst))
<RhodiumToad>that might be the simplest way
<RhodiumToad>though you can write it with (cut equal? item <>) instead of the lambda
<fnstudio>uhhh interesting, thanks RhodiumToad, is that srfi-26?
<fnstudio>cool, good to know, that might have simplified my (toy) code more than once
<manumanumanu>civodul: @ in match is a new feature from gauche: it destructures records by field name. $ is by record position. Say you have a record CD with the fields title and length you could do (@ <CD> (length len) (title t))
<manumanumanu>I don't use it, but if you upgrade match-upstream any @-clause will break in struct-ref
<civodul>manumanumanu: interesting
<civodul>i came up with a separate macro to match by field name in (guix records)
<manumanumanu>It is pretty easy to implement in standard r6rs, but in the context of match.scm it is pretty inefficient
<fnstudio>does lset-intersection always do the "right" thing or may it help if i preprocess my lists, e.g. by sorting them?
<manumanumanu>fnstudio: it should do the correct thing. But if the list is large, there are much better ways to implement sets...
<fnstudio>manumanumanu: yeah it's taking ages to compute the intersection set on a couple of long lists of mine
<fnstudio>manumanumanu: i guess i should be looking for some slightly more specialised library
<manumanumanu>fnstudio: a hash-map will allow for more efficient intersections, or a manual algorithm on sorted lists.
<fnstudio>manumanumanu: brill, thanks
<RhodiumToad>yeah, the docs warn that lset-* funcs are typically O(M*N) which is not good when you're intersecting large sets
<fnstudio>RhodiumToad: yeah, true... i saw that only after asking the question, i still need to figure out how to compute intersections using hash maps but i'll get to it
<manumanumanu>The "updated" srfi regarding hash tables has code to do that. srfi-125 can treat hash tables as sets, but it is not implemented in guile.
<manumanumanu>but an intersection is pretty simple: Simply iterate over each key in HT1, and if it doesn't exist in HT2, delete it. It can also be implemented using lists. Add all elements of list2 to a hash table, filter list1 with (lambda (x) (hash-ref HT x #f))
<manumanumanu>That is bound to be a lot faster.
<RhodiumToad>if you're going to be doing a lot of set operations, probably better to represent the sets as hash tables from the start
<RhodiumToad>(or as bitmaps, if the contents are small integers)
<fnstudio>thanks both, i'm taking note
<attila_lendvai>hi! i'm coming from CL, and i have a hard time debugging macros, the error messages are cryptic. e.g. Syntax error: unknown location: unexpected syntax in form (). i'm probably doing something wrong...
<attila_lendvai>this is with emacs, and geiser. when i C-c C-c the define-syntax form, i get line numbers that are irrelevant to the file i am in
<attila_lendvai>i know about ,expand in the repl
<attila_lendvai>any hints what else i'm missing? (besides experience with hygienic macros)
<attila_lendvai>i.e. is it at all possible for the expansion to contain generated variable names?
*attila_lendvai realizes that ,m (foo bar baz) does nothing wrt loading files
<RhodiumToad>well, with hygienic macros you normally shouldn't be generating variable names?
<attila_lendvai>but what if i want to expand to two toplevel forms, two definitions? it's in a guix context, i want to generate two versions from the same package... two (define-public ...) forms, on different names.
<attila_lendvai>but right now i'm stuck at not being able to redefine a define-syntax form. C-c C-c works the first time, and even the expansion in the repl with ,expand, but when i C-c C-c the same form once again, i get: "reference to pattern variable outside syntax form in form version"
<dsmith-work>Thursday Greetings, Guilers
<theruran>anyone blogged or written a guide on using Graphviz from Guile?
<theruran>like I am wondering how `(load-extension "/usr/lib64/graphviz/guile/" "SWIG_init")` can be portable
<stis>Hey guilers!
<stis>got the copying from different bytevectors types working like from int16 to double or whatever.
<stis>Have a huge C function that dispatches to diffent loops
<stis>Now also very fast bitset operations
<stis>As fast as guiles bitvector operations,
<stis>but with many benifits like you can do bitoperations to any poart if a bitvector with another part of another bitvector verry efficiently, will spend a lot of time in scheme code and hence play nice with fibers sparse bitsett or complements of them are efficient
<stis>I also have a copy operations that work between regions of bitsets that are very efficient
<stis>Acutally copying bitsets efficiently where the start point is not a multiple of 64 are wuite hard to do efficiently, but long stiry short, you need to do 3 passes of the bitvector so 3x as slow as with aligned data
<stis>Tricky to get right but a cool fact
<dsmith-work>Wow! How come I never knew of page-ext mode and pages-directory for looking at the NEWS file!
<lispmacs[work]>hi, what is an easy/efficient way to do a fill on only part of a bytevector?
<lispmacs[work]>just index over the bytes one by one, or is there a smarter way?
<manumanumanu>that is the way
<stis>lispmacs[work]: you may fill 100 bytes then use bytevector-copy! to get 200 bytes filled, then copy those 200. That's quite optinal to do it as onm my com och can copy 2GB in one sec
<stis>so to fill 2GB you will take the time 1s + 1/2s + 1/4s + ... = 1/(1-1/2) = 2x the optinal speed as bytevector-copy! is memmove under the hoos which can be assumed perfectly optimized so you can at most ggain 2x by pushing it to C
<stis>or assembler
<fnstudio>hi! may i ask what's the difference between vhashes and hash-tables? is it that the former are immutable?
<stis>vhashes are a functional hash essentially that works pretty mucha like consing pairs onto a list aka associat list
<stis>for hash-tables you mutate
<stis>vhashes impove on associate lists by havingmuch faster lookup, especially of the last added pairs are more commonly accest, else the worst case is logn lookup
<stis>fi you are going to mutate the values a lot consider a binary tree if you want a functional datastructure or just use a hash-table
<fnstudio>stis, very interesting and helpful, thanks; i need to fully grasp "functional hash" vs "hash-tables you mutate", but it's a great start
<stis>if you just mutate seldom, vhashes ore quite ok as you wil ljust add the binding to the top and then at times you can clean it up
<stis>beware vhashes are not thread safe
<stis>for a small number of values associated lists are faster
<fnstudio>stis: great, thanks; this would be for a relatively large number of items, so yes, i think some form of hashing will benefit
<ArneBab>stis: that sounds really cool! Any chance to get parts of that back into Guile itself?
<stis>ArneBab: ehat are you referring to?
<stis>ArneBab: everythingh is also in guile. Just 50x slower
<stis>so I prefer to have a little C power
<stis>99& of tje code is on scheme
<stis>juts some small loops refferred to C
<stis>anyhow it's very easy to make the c.code optional, havent done it yet though
<stis>I want to implemetn a supervector string as well as a super versions of the bitvector, bytevectors and vectors
<stis>ArneBab: ^^
<fnstudio>stis: sorry, when you say functional datastructure, do you mean it's immutable
<fnstudio>you create it, pass it a function if and when needed
<fnstudio>the function may create a new similar datastructure if any update is needed and the old one is left for the GC?
<fnstudio>which, if i understand it correctly, makes changes expensive?
<fnstudio>*pass it to a function - sorry
<fnstudio>yeah, i think wikipedia's helping me with that