<amz3>and it should be possible to parse any stream <amz3>error handling is not good enough, yet. megaparsack library does add more procedure and avoids atomatic backtracking <amz3>civodul: do you plan to port skribilo to guile 2.2? <amz3>or maybe it works on guile 2.2, I did not find a package in guix <civodul>amz3: it's mostly ported in skribilo.git, but there's a segfault in Guile while building the doc <civodul>this is due to Skribilo mutating an immutable pair apparently <davexunit>has anyone ever implemented something like local static variables in C? <davexunit>I've had cases where I have some performance critical code, doing vector math let's say, and I'd prefer to not allocate a new vector every call. I'd rather it keep re-using the same object. I can approximate this with careful use of let-over-lambda. <davexunit>but something a little more robust might be cool. <janneke>davexunit: a static variable is a global prefixed with the name of the function <dsmith-work>davexunit: Hmm. Well, from a C/asm/linker perspective, the only difference between a static variable at file scope and at function scope is the visibility. <janneke>what would a local-static be, how would you implement it? <janneke>possibly gcc's inner functions have something? <dsmith-work>let-over-lambda seems the right thing, to limit visibility, otherwise how about just a non-exported top-level binding? <davexunit>I would like some macro sugar to approximate this behavior, where the variable is heap allocated only 1 time per thread. <janneke>but every recursion into the function gets a fresh heap-allocated version? i don't graps your question yet... <janneke>ACTION is implementing a c compiler in scheme, so quite interested here... <manumanumanu>What would be a good efficient way to represent paths? I will o lots of appending and such, and have thought about storing the path in reverse as a list <davexunit>a file name is usually only a few directories deep, so using a vector seems not worth it <manumanumanu>I will store a lot of extra data. a pointer to the last element for fast appending could maybe be worth it <davexunit>I try not to get carried away with performance optimization <janneke>davexunit: what if you'd use a function-static array with an index that increases upon entry and decreases upon return <davexunit>but in the most performance sensitive parts of my game engine project I could definitely benefit from reducing GC pressure a bit. <janneke>ah, cool. critical parts are in C, something like that. <janneke>oh wow, i've been misunderstanding everything until now. sorry. <janneke>you're looking for a new feature in guile? <davexunit>currently I use a let-over-lambda to handle things that I don't want allocate fresh every time a procedure is called <janneke>but a static variable in C is a global...what is wrong with globals in guile? <davexunit>function foo(int x) { int result; result = x + 2; return result } <davexunit>result is a local and its memory is statically allocated <janneke>do you mean { static int result ...} ? otherwise result is on the stack <davexunit>my point is that in C you don't do extra allocation for many locals because they are stack allocated <davexunit>obviously in guile everything is heap allocated but for certain situations it would be nice to have an approximation of this <davexunit>like in a vector math function where you have a local variable to store part of a computation. would be great to allocate that once and never again. <davexunit>again, a simple let-over-lambda works, but it's no longer thread-safe, etc etc <janneke>ah, okay. you want something like a thread safe let-over-lambda shared variable <davexunit>yes, some macro that will make it no harder (or not much harder) to use them than it is to use regular locals <mwette>But foo() { static int memo; ... } is not thread-safe either ... <davexunit>this is why I don't ask these questions usually... <mwette>what about fluids? (define foo (let ((memo (make-fluid))) (lambda (... <janneke>and where do fluids/parameters fail? <janneke>they are thread safe, and global...performance might be lacking? <davexunit>okay so the answer is just "no one has tried this before" <janneke>davexunit: well, haven't heard wingo yet ;-) <janneke>just wrote my first scheme interpreter and c compiler this year, lots to learn i still have <mwette>davexunit: I see what you want now. Since MT safe, unless the items are always same size, not worth it, IMO. It seems to me you want an allocator for same-sized (or maybe max-sized) items. Maybe something like a make-vector-from-pool where you `(make-vector-pool <max-size>)' ***do is now known as w1gz
***do is now known as w1gz
***rubdos_ is now known as rubdos
<amz3`>ijp: wrt guile-js, is it possible to break the call stack using settimeout in the implementation of call/cc? <amz3`>I implemented so basic ffi similar to biwascheme <amz3`>even a simple program such as: <amz3`>leads on nodejs 8.4.0 to a hit the call stack limit <amz3`>erk, the problem is not about call/cc but the whole program which is written in recursive style which leads to to hit the stack limit <stis>I just sent a mail for an adition to guile I would like to have. E.g. getting prolog source files to autocompile just like scheme files <ijp>amz3`: how would you be using settimeout anyway? <amz3`>ijp: nvm, it's stupid idea, I read some people use it in javascript to "break" the call stack <OrangeShark>amz3`: oh do you mean like a very heavy/slow computation where everything sort of freezes?