IRC channel logs
2014-01-13.log
back to list of logs
<kurohin>what happens if scm_from_locale_string(n) is called in a thread that has not been initialized for guile? I have called scm_boot_guile, but this thread is started after scm_boot_guile. <davexunit>I have a confusing issue and I'm hoping someone can educate me. <davexunit>I am in a situation where, at the REPL, (foo) does the right thing but (define bar (foo)) does not. <davexunit>I'm not sure what is happening in the define form to cause such a thing to fail. <davexunit>to make things weirder, if this is run as a script, (define bar (foo)) does the right thing. <adhoc>davexunit: you are writing OpenGL apps ? <davexunit>I am building a 2d game development framework. <davexunit>one of its goals is for the user to build games at the REPL interactively. <davexunit>but right now defining new textures is failing. <adhoc>can't help with that =/ i'm still learning basic stuff at the moment <adhoc>davexunit: so what is the differnce between the REPL and scripting environment ? <adhoc>are there different configs parsed ? <adhoc>is there are more strict mode in the REPL or something ? <adhoc>is there a way you can list the modules loaded? <davexunit>there's a difference. the REPL has these neat metacommands you can use. <adhoc>i get ABORT: (unbound-variable) <adhoc>do you need to print or format the ,import <adhoc>standard input:1:1: In expression (unquote help): <adhoc>standard input:1:1: Unbound variable: unquote <adhoc>this box is that old i suppose <davexunit>you'll want to get yourself a 2.0.x version of guile. <adhoc>dang, i'm going to have build one then <adhoc>i have wheezy and jessie on boxes at home, but this desktop at work needs to be uip and running all the time <davexunit>wheezy has guile 2.0.5, but I would strongly recommend the latest release, 2.0.9 <davexunit>I think my issue has to do with the modifications I made to the REPL server. <davexunit>actually, wait. I think I misunderstand something about geiser. <davexunit>whatever geiser-eval-last-sexp is doing is different than what's happening when I type at the REPL prompt. <zacts>I want to try guilemacs sometime <nalaginrut>I think fastCGI may not necessary for Scheme, although it cuts down the data during TCP forwarding, the speed of processing depends on business-logic in the web-backend. <nalaginrut>no mention Guile has fluid to do Thread-local-store <ArneBab_>I just realized that call/cc can describe the ability of one of the character-classes in the PnP RPG we write - by being called in a function which takes the state of the whole world as state ☺ — main problem: The program executing that will need some memory mechanism which represents the saved arguments as difference to the global world-state (which nicely describes how the cost of the power rises the longer you hold the continuation) <ArneBab_>(they can jump back in time when they prepare it beforehand - but the effects on them do not get reversed) <davexunit>I use continuations in guile-2d for coroutines. they are a good tool for writing games. <ArneBab_>what do you do with them - practically? (I only understood what they do right now…) <ArneBab_>(for a quite strict measure of understood) <civodul>use delimited continuations, not call¢c <davexunit>I was going to get to that point, eventually. thanks civodul. :) <davexunit>I use delimited continuations to easily describe tasks that take more than one unit of game time. *ArneBab_ reads delimited continuations on wikipedia <civodul>ArneBab_: see "Prompts" in the manual, it's even better :-) <davexunit>ArneBab_: (define (contrived-example) (move-right npc) (wait 60) (move-left npc)) *ArneBab_ is trying to understand the contrived-example… <ArneBab_>where do you use abort-to-prompt? In wait? <ArneBab_>I think I understand call/ec: That’s like using return anywhere in a function in Python, with the difference, that only the given thunk of code returns, not some larger special construct. <davexunit>I built an abstraction on top of delimited continuations. <davexunit>it uses a scheduler to run continuations at a later time. <ArneBab_>so there you can abort-to-prompt, count 60 ticks and then continue? <davexunit>abort to prompt, add continuation to scheduler, tick scheduler 60 times and then the continuation is run. <ArneBab_>davexunit: and after running the continuation, you just throw it away, right? <ggrant>davexunit: Did you ever find the bug in Guile-WM, where if you resize a window no be non-visible and attempt to expand it in the opposite direction that you shrank, crashes the xsesion? <davexunit>ggrant: I actually haven't encountered that bug <add^_>ggrant: that's a bug in X, not guile <davexunit>ggrant: the bug I've encountered is trying to move/resize the root window. <add^_>I've seen that in serveral x-based programs.. <ggrant>add^_: Is is avoidable, in guile-wm though? <davexunit>perhaps I should nudge mark witmer again via email <ggrant>Happens with xterm, conkeror, and emacs -- that I've tested thusfar. <add^_>I don't know if it's avoidable, I don't run guile-vm (that's why I can say that it's not the origin of the problem) <add^_>Maybe are some other, more stable uses of x that some just don't use? <add^_>For example, the use of glut is apparently one of those things, many do, but (apparently) it's quite unstable because of those bugs you just described.. <add^_>Maybe I should just shut up. <davexunit>one thing that guile-wm desperately needs is an abstraction layer over xcb <davexunit>I wanted to write code to resize a window to fill half the screen, but I have to be concerned with the inner workings of X and xcb to do it. <davexunit>if we abstract that away then not only will extending guile-wm be easier, it will be easy to port to wayland. <davexunit>all the extensions should theoretically still work. *ggrant knows very little about the Free Software graphics stack, but yeah -- I'd for one be much more interested getting educated en the realm of Wayland, that Xorg. <ggrant>But yeah, right now -- interfacing with xcb, seems needlesly complex. Some of that might be fueled by my ignorance, but still. <davexunit>it needs to be done, but it needs to be done only *once* for any given operation. <davexunit>it needs to get abstracted away at that point. *ggrant really needs to work getting his Schemefu up-to-snuff, so he can start getting further involved into some of these projects -- which are certianly on his radar. To SICP, again I suppose. :^) <ArneBab_>(sorry, I got sidetracked - only returned here now) <davexunit>actually, it isn't really using a coroutine at the moment, so it's a misnomer, but you could *pretend* it is. <davexunit>so it really shows off the scheduler more than anything else. <ggrant>davexunit: Oh yah! I thought you were just taking a break from guile-2d, not that you moved to gitorious. <davexunit>ggrant: yeah I moved. I have a branch off master that I will merging in shortly. <davexunit>a few more problems to tackle before guile-2d 0.2 release. <ggrant>davexunit: Well, I'm excited to check it out again. :^) <ArneBab_>davexunit: so in the walk-up-and-down example, the scheduler executes the continuation and throws it away, but the continuation registers a new continuation <ArneBab_>that’s then how you can step through the function. <davexunit>yeah basically, the agenda is actually ignorant of continuations. <ArneBab_>that’s a very, very distributed approach - I like it: keeps the agenda simple. <ArneBab_>and each thunk can know whether it wants to run again - and if one stops running, you know that the error is inside the thunk <davexunit>I didn't do anything special there. that's just guile doing its things. <ArneBab_>even if there is no error, you know that the thunk must have failed to register a new continuation <davexunit>there's 2 key modules that you could read: coroutine.scm and agenda.scm <ArneBab_>ah - I did not spot that the function continues after the empty line <ArneBab_>(code review: I did not spot that the function continues after the empty line ☺ ) <ArneBab_>(all your other definitions in the file have no empty lines, so you might want to kill the empty line there, too) <ArneBab_>also this will make your coroutine-function end in line 42 ;) <ArneBab_>(code-review: It took me some time to see codefine as co-define and not as code-fine) <ArneBab_>so what you do is calling the thunk. Do I understand it right, that the continuation *requires* a callable as first argument? <civodul>jemarch: recutils 1.6 no longer accepts hyphens in field names, right? <jemarch>hyphens in identifiers don't mix well with infix arithmetic expressions :) <civodul>who cares about infix arithmetic expression! ;-) <civodul>wingo: excellent work on the manual & blog post <civodul>the reflections are very interesting <civodul>i think it's unusual to have good insight on this kind of design decisions <wingo>thanks, glad you enjoyed them <wingo>the manual is still a bit rough; there are things to do there... <kurohin>good day/night/morning/whatever guilers <kurohin>guile: uncaught throw to unbound-variable: (#f Unbound variable: ~S (myextension-my-hook) #f) <kurohin>if I scm_c_define a hook in my init function for the extension should it not be accessable from another thread? <wingo>kurohin: which guile version? <wingo>there was a bug about that a long time ago <wingo>that shouldn't exhibit the bug :) <kurohin>I think I might be doing things wrong, If in one thread do scm_make_hook in my C extension init function and then after starts another thread and does scm_guile_init() followed by run_hook, <wingo>check the current module in the main thread where you defined the thing, and in the auxiliary thread <wingo>the problem is probably that the module is not the same <kurohin>it was a typo, dash instead of slash <mark_weaver>I've been meaning to ask you a question about bytevectors, namely why #u8(1 2 3) is not equal to #vu8(1 2 3). it's causing problems for my R7RS work. <mark_weaver>Is there a reason not to unify the U8 and VU8 element types into one? <mark_weaver>R6RS specifies the #vu8(1 2 3) syntax for bytevectors. R7RS specifies #u8(1 2 3) syntax. Most of our bytevector procedures return #vu8(...). It's going to be a mess if we can't unify them. <wingo>happy new year mark_weaver ! <wingo>the $kreceive thing took much longer than expected :) <mark_weaver>I'm not surprised. I'm glad you found the energy to get it done :) <wingo>regarding #vu8 and #u8, let me see if I recall correctly. <mark_weaver>there are still a lot of optimizations that turn 'call-with-values' into 'let' or even simpler, thus introducing a truncation that wasn't in the original code. but we can track those down later. <wingo>yes those erroneous optimizations are in peval <wingo>scheme@(guile-user)> (use-modules (srfi srfi-9) (rnrs bytevectors)) <wingo>scheme@(guile-user)> (u32vector? #vu8()) (bytevector? #u32()) <wingo>so i think the thing is that all srfi-9 uniform vectors are distinguishable between themselves <wingo>and they are all bytevectors <wingo>but not all bytevectors are (e.g.) u32vectors <mark_weaver>so bytevector is sort of like a superclass of all the SRFI-4 vector types. <wingo>or u8vectors, for that matter <wingo>yes i think that was the intention <mark_weaver>wingo: would it be possible to get rid of U8 as a distinct subclass of bytevector, and instead make it the superclass? <wingo>mark_weaver: it would, yes; let me think on the possible implications... <mark_weaver>so all the other SRFI-4 types would still be subclasses, but U8 would be the general bytevector type? <wingo>so one thing that would cause would be (u8vector? #u32()) <wingo>seems like a regression in some ways... otoh this is a space of compromises without perfect solutions... <mark_weaver>if you can think of a better compromise to deal with R7RS, I'm open to suggestions :) <wingo>did r7rs standardize #u8() ? <mark_weaver>yeah, one of those gratuitous incompatibilities with R6RS that they introduced :-( <mark_weaver>actually, they listed "compatibility with SRFI-4" at the rationale for using the #u8 syntax. <wingo>do we know the shape of the more generic interface they are proposing? are they proposing to adopt srfi-4 wholesale, or something else? <wingo>srfi-4 is a silly api for a generic blob facility <wingo>seems to me you really want to be able to access a mixed blob of different types *wingo should burn his r7rs draft printouts ;) <mark_weaver>I like the fact that you unified bytevectors and SRFI-4. <wingo>heh, glad you liked that ;) i did too but it does have downsides <wingo>e.g. an optimizer has to assume that a u32vector can alias an f32vector, etc <mark_weaver>does SRFI-4 require that all of the types are distinct? <mark_weaver>it says "analogous to the Scheme vector type, but they are distinct datatypes", which isn't entirely clear to me. <mark_weaver>but maybe I'm trying too hard to see what I want to see :) <mark_weaver>anyway, if we want to support R7RS (and I think we do), then I think we have to unify U8 and VU8. <wingo>right, distinct from vector?, but do they have to be mutually distinct? <mark_weaver>(there's an r7rs-wip branch in guile-git that supports most of R7RS, btw) <wingo>i feel like a weasel reading this way ;) <wingo>could we unify #vu8 and #u8 without breaking r6rs? sounds a bit nasty but i guess we could do it <mark_weaver>hmm, good question. does R6RS specify that bytevectors are a distinct type from SRFI-4 U8 vectors? <wingo>(u8vector? #u32(1 2 3)) is a definite down-side though <wingo>mark_weaver: r6rs says nothing about srfi-4 <mark_weaver>there is also the issue of print syntax. we could have a print option for that, I suppose. <wingo>seems to me r7rs just made a bad decision in this area <wingo>srfi-4 u8vectors are not suitable as a fundamental data type <wingo>i was sure that when i was interested in the topic, #vu8() was the decision <wingo>i guess that changed at some point <civodul>#vu8 has the advantage that it can coexist with SRFI-4 <civodul>if we end up having read and write options for all these things, that may become unmanageable <mark_weaver>I suppose the other option would be to keep them separate, but consider them 'equal?' and 'bytevector=?' anyway. <mark_weaver>yeah, the read+write options are definitely a serious problem. <mark_weaver>however, if we keep them separate, then I think we need for the R7RS bytevector procedures to produce U8 vectors instead of VU8 vectors. <civodul>actually that would be the easiest thing, no? <mark_weaver>of course, I'd like for R6RS and R7RS code to coexist in the same system and operate on the same data, as smoothly as possible. <civodul>just map R7RS bytevectors to SRFI-4 u8vectors <mark_weaver>civodul: well, it means duplicating a bunch of bytevector procedures, and I suspect there would be problems with programs that mix R6RS and R7RS libraries together. <mark_weaver>really, we should be aiming for a unified data model whereever possible. <civodul>mark_weaver: if R7-bytevector = SRFI-4-u8, then there's nothing to duplicate, AFAICS <civodul>because an u8 is already usable with the R6-bytevector API <civodul>we'd need a 2nd 'string->utf8' procedure, that uses the u8 tag instead of vu8 <mark_weaver>the R7RS test suite calls bytevector-returning procedures and compared them with expected values like #u8(...), which fails. <mark_weaver>and if I convince myself that this was only a test-suite problem, then I'd just fix the tests, but I think not. <civodul>if R7-bytevector is implemented in terms of SRFI-4 there's no problem, is there? <mark_weaver>here's the problem, in my mind: R6RS and standard Guile code that specified to recieve a bytevector will reasonably assume that it's a VU8. <mark_weaver>now if a R7RS procedure produces a bytevector and passes it to a procedure written in R6RS or standard Guile, it's violating the contract, effectively, without it being obvious. <civodul>if R7-bytevector = SRFI-4-u8, then it just works no? <civodul>that is, a u8 can be passed to an R6RS program that expects an R6 bytevector <wingo>what if we make make-bytevector and similar produce a #u8() object which is nevertheless a subtype of #vu8() ? <wingo>we keep all the existing read and write syntax, and don't change srfi-4 or bytevector code at all <wingo>only we make r6rs bytevector procs return objects that don't print as #vu8 <wingo>it's a little incompatible but it's not terrible <mark_weaver>well, they'd have to be considered 'bytevector=?', and thus 'equal?', as well. <wingo>we can hack bytevector=? of course ;) <wingo>we can even add a new bytevector element type <civodul>i know i shouldn't say that, but: how popular is R7? <wingo>as-is the difference between u8 and vu8 is silly <mark_weaver>in terms of being able to understand contracts, I'm a little concerned with their being confusion about how type contracts of the form "a bytevector is expected" or "a bytevector is returned" will be interpreted. <wingo>civodul: i care about it to the extent that it allows us to share code with chicken, and not much farther <wingo>mark_weaver: currently "a bytevector is expected" means any uniform vector is expected <wingo>and "is returned" means a vu8 is returned <mark_weaver>civodul: heh, I suppose we could just try to keep R7RS from going anywhere, heh. <wingo>dunno if it's a healthy thing to do tho ;) <mark_weaver>we'd have to change those contracts, such that "is returned" means that a U8 is returned. <wingo>r6rs wouldn't be able to tell -- except it would print as #u8() <wingo>that would be the only difference <mark_weaver>I guess I'm worried about code that is tested against VU8, and so they think it works, but then it fails if given a U8. <wingo>mark_weaver: i don't think there is any code like that <wingo>unless you care about the external representation <mark_weaver>well, are U8 vectors accessible using the larger element type accessors? <wingo>ah you mean (u32vector-ref #u8(0 1 2 3) 0) <wingo>yes that also works, for better or for worse :) <mark_weaver>so type predicates like u32vector? are the only potential difference between U8 and VU8? <wingo>yep, that and the external representation <mark_weaver>well, that makes me think they should just be unified, then. <wingo>they are not unified currently precisely because of the external representation <wingo>and also so that (u8vector? #u32()) => #f <mark_weaver>if the type predicates are the only way to tell the difference, that almost seems silly. <wingo>well the type predicates were the only thing available in srfi-4 and pre-2.0 guile <wingo>i'm not justifying the thing, just explaining :) <davexunit>hey guilers. I have a question about the REPL server. <mark_weaver>I'm nervous about keeping them separate with only such a slight difference. I think it could lead to subtle bugs, where code handles one correctly but not the other one. <mark_weaver>I'm less worried about the dangers of (u32vector? #u8(...)) <davexunit>I was using Geiser yesterday and I noticed a difference in behavior between evaluating code at the REPL prompt and evaluating code via geiser-eval-last-sexp. <davexunit>as you know, mark_weaver, I'm using a tweaked REPL server that deposits thunks to be run in another thread. <davexunit>well, evaling code at the REPL worked as expected. <davexunit>I inserted a little display statement in there just to be certain. <davexunit>however, when evaling with C-x C-e, I saw no such debugging statement. <mark_weaver>I don't know much about how Geiser works. it might have swallowed your debugging output, or maybe it sent the command to a different REPL? <wingo>mark_weaver: yeah, for mulling -- i guess my only concern is old code, potentially non-guile srfi-4-using code that uses the predicates to discriminate between different srfi-4 data types <wingo>that would be the thing that would break <wingo>perhaps it's not a big deal tho <davexunit>mark_weaver: perhaps it was run elsewhere, but the code would have thrown an exception I think. <davexunit>the code worked, but had one issue that I've only seen when the compiled thunk is wrong in the wrong thread. <davexunit>an OpenGL call failed and returned 0 when the result should be > 0 on success. <davexunit>I'm going to do more investigation later, but I figured I'd mention here to see if I could figure out more possible culprits. <mark_weaver>You could replace the OpenGL call with (current-thread), and try running it both ways. <mark_weaver>davexunit: are you using the one that runs the thunk in a different thread, or the later version that does the _reading_ in a different thread? <davexunit>mark_weaver: the former. I'm not using a custom version of guile. <davexunit>it couldn't have been the wrong REPL now that I think about it. <davexunit>I was redefining a variable that was being drawn to the screen. <davexunit>I tried to change an image that was being drawn. <davexunit>I can do that from the REPL prompt and it works. yay. <davexunit>but when I do it via C-x C-e in a scheme buffer it just draws a white box. boo. <civodul>does that buffer have an associated module? <mark_weaver>I have to go offline for a while. happy hacking, all! <davexunit>it's a just a quick script that doesn't belong to a module. <davexunit>this also fails when the buffer is associated with a module. <davexunit>the problem is that my custom code is being bypassed entirely. <davexunit>reading the REPL server code, it seems that there's only one way to read user input. <davexunit>and only one place to apply the compiled thunk. <civodul>when a buffer has no associated module, C-x C-e evaluates in whatever module is current in the associated REPL, i think <civodul>so you'd have to make sure it gets evaled in the right module <davexunit>civodul: I'm confident that it's being evaled in the right module, but it's not the real issue. <davexunit>it's as if I had 2 different REPL serve-client threads running. <davexunit>but it seems that there's only one connected client: geiser. <civodul>do you have debugging statements in the REPL server? <davexunit>well, every time a compiled thunk is run via a procedure that I wrote, a string is printed to stdout for me to read. I haven't done any more sophisticated debugging. <civodul>perhaps you could print something in Geiser's Scheme-side evaluation code <civodul>(i realize this isn't ground-breaking advice) <davexunit>I dug around in the the geiser source, I'll try inserting some debugging there. <davexunit>I just figure that no matter how geiser works, the input *has* to get read within run-repl, which I've modified to do my evil bidding. <davexunit>I'll try to inspect more sometime later when I get home from work. <davexunit>I just want to solve this problem so I can joyfully write games at the REPL. <civodul>our custom-binary-input-ports are flawed, grrr