<wingo>civodul: btw i started working on preventing syntax objects from being forged. i think i had forgotten how hard it was to work with psyntax but anyway getting close. <wingo>when that happens, i think my guile sandbox would be pretty good and we could start using it in guildhall/potluck/whatever <civodul>so syntax objects are no longer vectors? <civodul>the problem is that even if they're structs, one can still (make-struct (@@ the-rtd) ...) <wingo>the answer is complicated unfortunately :) <wingo>so @@ is a powerful abstraction-breaking primitive and it cannot be exposed to sandboxed code. <wingo>likewise make-struct, actually, and struct-ref. <wingo>so a solution for syntax objects that would have it be a struct type would be fine. <wingo>however i made it be a new tc7 so that we can embed constants into the constant part of the elf file <wingo>as is currently the case for vectors <wingo>there is a make-syntax functoin which is now in (system syntax internal) that is likewise unsafe and can't be given to sandboxed code. <wingo>however... we have to recognize vector syntax objects for a little while. <wingo>they are already serialized into macros, and macro-defining macros, etc <wingo>so for distros that have an ABI we need to recognize both kinds. <wingo>maybe in 2.2.1 for example we release with both kinds supported, and a fluid to control whether to recognize the old kind <wingo>and perhaps in 2.2.2 we can make that incompatible change to remove the old kind. unclear tho. <civodul>i see, a new tc7 is probably the safest approach indeed <civodul>re incompatibility, that may have to last longer <civodul>but if the fluid allows us to disable vectors locally, maybe that's good enough? <civodul>i mean, you could run sandboxed code in a context where it's not allowed to use vector-syntax-objects <wingo>yes, provided that all macros that it uses have been recompiled to not emit legacy syntax objects <wingo>figuring out whether that's the case or not is a bit irritating; depends on which version of psyntax compiled the macro <webshinra>guile::wrap<AnimationAutomata*> automata_ptr <webshinra>well, a minimal c++ wrapper to guile wasn't that hard to write :P <webshinra>automata_ptr.check_as_arg<SCM_ARG1>(caller); <daviid>just compiled installed 2.2 (from the source), then running gives me guile: error while loading shared libraries: libguile-2.2.so.1: cannot open shared object file: No such file or directory <peterbrett_work>webshinra: This C++ wrapper is highly relevant to my interests… do you have some publicly-available code yet? <wingo>could be ldconfig, LD_LIBRARY_PATH, any number of things <daviid>wingo: yea, did not remember had to do that <webshinra>peterbrett_work: not yet, but I hope tu put it soon on something like github <webshinra>I'll have to check licencing with my colleage before, and improve the guile type covering <webshinra>but if everything is all right, I could publish it before dawn <peterbrett_work>webshinra: Maybe it would make sense to have something that protects a Guile value while it's stored in the heap <peterbrett_work>Using RAII to `scm_gc_protect_object()` and later `scm_gc_unprotect_object()\\ <webshinra>yep, that's true, I didn't think of it because in my case guile does not have any occasion to destroy stuff <wingo>peterbrett_work: if it's on the stack then nothing needed; or just have a volatile local or something to make sure it's scoped appropriately <wingo>of course you do need to protect SCM values referenced from the C++ heap <peterbrett_work>wingo: Indeed! In the case of a composite type it's hard to enforce that it's never created with "new", so I suspect RAII best practice would be to ensure that you use a protecting smart type in classes and structs by default <wingo>no problem to protect by default, just slower <webshinra>I'll look to add a template parameter switching bettwen «raii» and «no new», defaulting to «no new» <webshinra>peterbrett_work: I would like to thank you in the readme, which name would you like me to write? <peterbrett_work>webshinra: So if you put an SCM_convertible<false> into a struct, does C++ prevent you from creating an instance of that struct with new? I haven't played with deleted operator new before <webshinra>cool, let me know if you have any idea on how to improve it :) <peterbrett_work>webshinra: For SCM_convertible<false> I think the constructor should be: <peterbrett_work>SCM_convertible(SCM data): data_field(scm_gc_protect_object(data)) {} <webshinra>(I spent most of my time fighting semi-mystical template error) <peterbrett_work>webshinra: I'm still looking forward to the day when it's easy to use Guile with Rust ;) <davexunit>ACTION is not sure how to fix the u64 boxing problem he is having... <webshinra>peterbrett_work: I'm looking for that day with ocaml :P <webshinra>so, true and false specialization where inverted <webshinra>and yeah, that version of the constructor was the first I wrote, I think I just have a random doubt and forgot to check the doc. <peterbrett_work>Maybe it would have been better to use named tag types rather than a bool <webshinra>maybe wrong, but i thought of it as switch, not a «mode» <peterbrett_work>There's been a lot of debate in the C++ community recently about whether flag values should be bool or something distinct/named. There's no real consensus. <webshinra>and, guile::wrap<int, guile::GC_Protected> seems odd when the overall goal is to improve syntax <amz3>webshinra: is your company look for guile hackers? <amz3>webshinra: is your company looking for guile hackers? <webshinra>well, we don't have enough money to pay for one, so we'r not really «looking for» <amz3>I am not really a gamer tho. <ManDay>Hi, I get a stack-overflow in something which looks approximately like this: (let rec ([rest huge_text]) (let ([next (rec (cdr rest))]) ...more code not using "rest"... )) <ManDay>Guile should figure out that "rest" does not need to be retained, right? <taylan>ManDay: that's an infinite loop if I'm not mistaken <taylan>ManDay: you call 'rec' unconditionally in the body of 'rec' :) <ManDay>well yes sorry I was not precise enough <ManDay>it's a base64 decoder but it only fails for large texts, so I don't see this being anything infinite: <ManDay>it's just that it already starts failing for a few thousand chars <ManDay>thanks! in this case i wanted to write my own, though (also because it must be able to ignore arbitrary amount of whitespace and newlines) <ManDay>amz3`: no this happens in guile. I think it wouldn't even happen in biwascheme because technically i have plenty of memory which the JS could use <amz3`>the example you paste works on guile 2.2 <amz3`>ManDay: what's the issue with the code you pasted? <amz3`>list->string does fix that tho <amz3`>to be honest, I am not familiar with base64, but your code looks nasty <taylan>amz3`: guile 2.2 won't stack overflow anyway, as it expands the stack :) <ManDay>amz3`: the quote is just from the wiki article on base64 <ManDay>amz3`: why do you think my code looks nasty? <ManDay>amz3`: it's just that I thought guile figured out that some variables of the stack are no longer needed after a certain point so they are ordered on the stack accordingly and discarded a.s.a.p. <amz3`>it looks nasty because it's too much nested <ManDay>amz3`: and what do you suggest be an alternative? <ManDay>the nesting properly reflects the semantics to all I can tell <amz3`>maybe instead of named let you can use a fold? <ManDay>I havent used a fold yet. I have to think about how this would be used ***mike_ is now known as Guest13588
***Guest13588 is now known as spk121
<amz3`>ManDay: try to use fold, and we will see what happens <amz3`>I am curious to see what happens because, I also use named let a lot <ManDay>but this is logically not tail recursive <ManDay>any way, i'm rewriting it currently to be. makes a bit of other stuff uglier but it needs <amz3`>also, is just only *my* point of view, maybe it's not that ugly <ManDay>it's too late now man, I'm offended now! ;-P <amz3`>I never realized how the absence 'return' keyword is elegant until I tried to port some code that use heavily nested procedures <amz3`>like for instance the following: (lambda (state spawn) (lambda (event) do-something-useful)) <amz3`>is translated to an horrible mess (no pun intended) in Javascript: function(state, spawn) { return function(event) { do-something-useful }} <amz3`>and it becomes, overwhelming when there is another level of nesting, which makes the code unreadable in javascript <amz3`>obv, this is not how I would write the code in javascript... but IMO, the scheme version of that code is more readable <amz3`>since, in the end you still need to use closures in javascript anyway <amz3`>so you still end up with code that does return a function, no matter what. <spk121>amz3` did you mean to say "absence of a 'return' keyword" or "the absent 'return' keyword"? <ManDay>amz3`: So I got it working by rewriting to tail recursion <ManDay>(i also used your hint about assembling the result downstream not upstream) <wingo>i swear there is nothing more difficult that i have worked on in my entire career than psyntax <wingo>what a basket of rabid weasels <stis>because of bad design or pure fundamental complexity? <wingo>fundamental complexity -- it is a scheme expander written in the source language, it embeds its input in its output, etc <wingo>of course the question is, could you write it in a way that's not bootstrapped <janneke>wingo: i'm having that problem in mes... <janneke>i found a reasonable syntax-rules in source... <janneke>but did not get Andre Tonder's syntax-case thing going <janneke>I'd love top drop psyntax from mes, but that means having no syntax-case <wingo>because you can't get anywhere from there :P <wingo>ok i finally have something that compiles, woo <janneke>ACTION has mescc compiler feature complete for building mes scheme interpreter <janneke>guile runs nyacc c parser succesfully, mes barfs on some cpp statements :-( <janneke>debugging nyacc'scpp conditionals parsing ... <joshuaBPMan_>Hello, I'm trying to solve a really simple reddit daily progammer challenge using guile. What I'm not sure how to do, is to properly get input. How can a guile program parse input from the command line? I've read the manual, but I'm not sure how to really do it. In just a second I'll link to a paste of my code... <joshuaBPMan_>I'm trying to simplyify fractions. I know that guile does this by itself, but that's not really the point of the exercise... <joshuaBPMan_>Anyway I'm running the program like ./277.scheme 3 7 4 8 10 20 <joshuaBPMan_>Each pair of number represents a fraction. I'm not sure how to parse out each pair of numbers. <janneke>joshuaBPMan_: run string->number on args? <joshuaBPMan_>hmmmm, I'm not sure what that means, though I remember seeing it in the manual. Let me read that more throughly. <joshuaBPMan_>I did just discover that I can do (car args), (car (cdr args)), (car (cdr (cdr args))), etc. <dsmith-work>joshuaBPMan_: Don't forget the combos: cadr and friends. <joshuaBPMan_>for some reason I thought I tried car, cdr before and it didn't work... <joshuaBPMan_>dsmith-work: I really need to learn more about said cadr and friends. <joshuaBPMan_>I think there's one that looks for the nth item in the list as well. <joshuaBPMan_>well thanks for the help. Hopefully I'll complete this program soon.