<lilyp>use sneek later tell to relay messages <lilyp>e.g. sneek later tell hugo hi <hugo>But what has it to do with me? <lilyp>You wanted to relay a message to maximed, no? <hugo>lilyp: Oh. I mostly wrote that "blindly", hoping that maximed had some secret log stash somewhere ***sneek_ is now known as sneek
<lilyp>oh, sure, the logs are public after all <lilyp>people just don't tend to notice them most of the time <hugo>I should check if I show parting messages when my bouncer is still here collecting messages <ArneBab>wingo: in the scheme-reports-wg2 there will be discussions of delimited-continuations. Would you be willing to share your experience — including the experience of implementing fibers? ***chris2 is now known as Guest4303
<tohoyn>is there any way to debug guile bytecode? <civodul>tohoyn: the REPL has a built-in debugger <tohoyn>civodul: I know, but can it step through bytecode instructions? <sneek>I've been running for one month and 4 days <sneek>This system has been up 6 weeks, 5 days, 19 hours, 17 minutes <maximed>sneek: later tell: I tend to check the IRC logs to catch up on missed messages <maximed>sneek: later tell hugo: I tend to check the IRC logs to catch up on missed messages <maximed>sneek: later tell hugo: I haven't seen your announcement on guile-user@gnu.org or IRC <maximed>sneek: later tell hugo: what did you announce? <tohoyn>procedure emit-load-u64 takes only two arguments in addition to the asm argument even though bytecode instruction load-u64 takes three arguments <civodul>am i right that a literal vector doesn't require any relocation? <maximed>civodul: if it contains symbols, strings or bignums I would expect it needs relocation <civodul>maximed: i'm looking at this in the context of package locations :-) <civodul>your patch made me realize we're pretty inefficient <civodul>since each package 'location' field is an alist <civodul>so i'm thinking we should change that to a vector internally <maximed>civodul: What would you think of making the 'location' field internally a vector <maximed>and letting 'package-location' automatically convert it to a <location>? <civodul>i'm looking into it, so if you want i'll send you what i have <civodul>maximed: first observation: the .go file is <1% smaller (i was expecting a bigger difference) <maximed>civodul: I've another patch, making the .go about 0.2% smaller IIRC, and theoretically reducing memory usage somewhat. <maximed>Maybe after seveal such patches, things will be more noticably smaller? ***sneek_ is now known as sneek
***sneek_ is now known as sneek
***sneek_ is now known as sneek
***sneek_ is now known as sneek
***sneek_ is now known as sneek
<manumanumanu>what is the underlying data structure used by supervectos? <hugo>sneek: later tell maximed: My Shapefile library, announced on 30 december 2020 <sneek>Welcome back hugo, you have 3 messages! <sneek>hugo, maximed says: I tend to check the IRC logs to catch up on missed messages <sneek>hugo, maximed says: I haven't seen your announcement on guile-user@gnu.org or IRC <sneek>hugo, maximed says: what did you announce? <stis>manumanumanu: : its basically a tree, but forces the shilds to be of the same size in order for fast indexing and have just a vector of bins which are rich objects that can represent a uniform vector with a size and a value <manumanumanu>I asked because I have been playing a little with an immutable string container <stis>thea idea is to make rich bins to allow for a variety of features <stis>and assume the bin typically is very large <stis>so that the complexity does not cost much compared to the work of the elements <stis>ther are different versions of sharing <stis>refferences and copy on write semantics <stis>copy on write is automatic on ro-o supervectors <stis>and referencing needs to be called for explicitly on each operation <stis>for a fun application look at the latest mail to guile-devel <stis>Right now I work with adding a supervector alternative of a vector of scheme objects <stis>If the bins are 4k or larger, the copy operation is a s fast as a C mem move <stis>where the copy if from one supervector to another (if they aligh) <stis>One application is to enable a structure to do well behaved c-code operations, also allow for less large datastructures as big allocations are a PITA worj use cases that are superheavy <stis>Also allow for high compression of datastructures. For example if we have a string todat, it is eithr bytes or uint32_t, with a supervector verison you can have amix. <stis>they are also optionally typed wich means that you can have a general ref and set operation <stis>if a bin has the expand? flag and we sent a uint16_t in for a uchar bin inside it will if depth > 0 subdived the bin in two binss preferable of the same size, and recurse with level set to level -1 or else resiz size the bin and the set the value <stis>This measn aome complexity but all thise choices are amortized typically for cases where we scan the whols datastructure <stis>And if you need speed (never optimize premmaturely) I will design a system where you end up using the raw bytevector operatoins, which is translated to compiler opcodes in the JIting <stis>(thaks to the macro ssyetm) <stis>but it will generate a lot of cases, if we use all unsigned reffers and combine will all unsigned setters we end up with 16 versions of the loop over the bin. In prociple the compiler could do all this currently But the it has to create 100 versions of the bin (doable with macros ) <stis>I will probably create helpers so that people can use whichever kind of code explosion of cases they like. preferable starst with the non exploded version and impporve from there is need be <ArneBab>sneek later tell dthompson this gives in chickadee 299:4 0 (sprite-batch-add* #<<sprite-batch> texture: #<texture…> …); chickadee/graphics/sprite.scm:299:4: In procedure sprite-batch-add*:; In procedure bytevector-ieee-single-native-set!: Wrong type argument in position 1 (expecting bytevector): #f