<mark_weaver>for a module, I can't think of a sensible use for that information. <davexunit>guile-2d is now licensed under the GPLv3+ instead of the LGPLv3+ <mark_weaver>I'm sympathetic to the way you did it, because it makes the two macro uses line up nicely, but I can also see the virtue of the GNU standard way, and it's probably best to be consistent. <davexunit>I need to refer to that guide more. I inevitably miss something. <mark_weaver>the other thing is: ISTM that there's a TOCTTOU bug here that's getting swept under the rug. <mark_weaver>it's obviously better than not checking at all, but unless I'm mistaken, an allocation in a different thread could trigger a GC that zeroes the weak element between the check and the use. <mark_weaver>I'm actually not entirely sure about this, but it warrants investigation, I think. <mark_weaver>my understanding is that signals are used to suspend all threads, so any place that a signal could be delivered, a GC could happen. <mark_weaver>btw, that also suggests that in your Scheme code, when accessing something that might become zeroed out, it's important to copy the value to a private variable first, and then check+use the private variable. <davexunit>there's only one procedure that uses the weak refs. <mark_weaver>the problem is really fundamentally in the API of SCM_WEAK_PAIR_DELETED_P <mark_weaver>afaict, there's no way to use it safely without grabbing the allocation lock. <davexunit> ((signal-proc output) output (%signal-ref signal))) <mark_weaver>ah, hash-for-each should be the thing that handles weaks, so there's no issue with your code that I can see. <davexunit>so there's just the issue with hash-for-each to work out, then. *mark_weaver looks at the code in master <mark_weaver>I don't have time to fully audit it, but from a brief glance it looks like master has all of this cleaned up. <mark_weaver>but it's quite a massive change from how things are done in stable-2.0. <mark_weaver>backporting it would be a big job, and risky. not sure it's worth it. <davexunit>instead of expending energy to backport a big change like that. <davexunit>there's surely more important work to be done. <Madsy>mark_weaver: I'm trying out your scmsigs.c hack now <mark_weaver>Madsy: okay, maybe worth a try I suppose, but at this point it might be more important to try building without threads to see if the new posix interfaces work, and to make sure that nothing got broken, since we should get 2.0.10 out soon. <mark_weaver>my gut feeling is that it will take more work to get threads working on windows. <davexunit>mark_weaver: do you think it's worth it to resubmit my patch with the style fix or would it be better to just wait to see what wingo and/or civodul have to say? <mark_weaver>I suspect that 'scm_internal_hash_fold' has the same TOCTTOU bug. <Madsy>mark_weaver: No luck with the signal hack either, sorry :/ <Madsy>So I'm switching back to single-threaded for now <mark_weaver>I'm not surprised. Thanks for trying. we'll get it sorted out, but it'll have to wait until after 2.0.10. <Madsy>Yeah, it should take me about an hour to refactor this code to run single-threaded instead <mark_weaver>it would be great if you could try building the latest tarball for mingw, and see how it works. <Madsy>Later than guile-2.0.9.219-e1bb? <mark_weaver>ideally the latest, but e1bb isn't too bad either, if you've already built it. <mark_weaver>e1bb has the stuff that's most likely to affect windows, anyway. <Madsy>I've already run all the tests for e1bb. You want the log? <mark_weaver>although my fix to add the missing tests to the tarball was after that. <mark_weaver>e1bb will be fine, no need to spend time on rebuilding/testing the latest. <Madsy>Note that just like last time, I had to skip some test in order to run the rest *mark_weaver looks them over <mark_weaver>Madsy: where is the recommended place to put temporary files on windows? <Madsy>Uh.. good question. I suspect there's a temporary directory in the users' home folder <Madsy>x:/Users/<User>/AppData/Local/Temp <Madsy>If you need somewhere to hide config/data files for your application, x:/Users/<User>/AppData/Roaming is the place <Madsy>mark_weaver: Hm, do you know of a way to not having to link with pthreads if I only need single-threaded guile <Madsy>I guess I have to disabled it in libgc too <Madsy>Like, why not get rid of a dependency I don't need anyway <Madsy>mark_weaver: Hm, this is weird. I built libgc without threads and configured guile without threads. I still get uresolved symbols to a bunch of GC thread functions. <Madsy>Hm.. maybe it picked up pthreads even when I asked it not to <Madsy>I had to remove my pthread symlink to trick ./configure. --disable-threads had no effect alone <Madsy>Oh.. great. Now I'm getting runtime errors I didn't get before :) <Madsy>What did I do last time then, hm. <Madsy>I think I built libgc with "win32" threads <mark_weaver>worth a try. I don't see why that would be a problem, if guile is built without threads. <Madsy>But that doesn't make much sense. Is libgc supposed to use threads even though guile doesn't? <mark_weaver>does it happen only when running your own program, or when running the guile executable? <mark_weaver>fyi, scm_protects is a global (or static) variable, and that failure means that boehm GC is unable to see that variable. <Madsy>Somewhere in scm_storage_prehistory() <Madsy>I tested the vanilla guile executable <mark_weaver>I think it's worth trying a build of libgc with win32 threads enabled. <Madsy>Just getting a bit tired of rebuilding ;-) <Madsy>I built that before I started messing with thread support <Madsy>And it was built with null_threads <mark_weaver>so why not repeat what you did then? it seemed to work well. <Madsy>I'll try building libgc with its win32 thread model. But it's a shot in the dark, because I honestly don't remember what I did differently <Madsy>I do, just not in this particular case ;) <mark_weaver>it also might be good to create scripts to do all this stuff. *mark_weaver goes afk for a bit <Madsy>mark_weaver: Wow.. by random chance I discovered a big bug in libgc's ./configure <Madsy>mark_weaver: If $HOST contains "mingw", it disregards --enable-threads=posix and automatically switches to its internal win32 threads <Madsy>No wonder my attempt at threads didn't work. libgc never used w32-pthreads <mark_weaver>maybe the libgc devs know that win32 threads is the only way to make a working libgc on mingw <Madsy>Well, it's not surprising that stuff locks up when libgc and guile uses two different thread models <Madsy>I might give threads yet another try tomorrow with that case commented out <mark_weaver>here's the thing: in order for libgc to work with threads, it needs to be able to suspend all threads. <Madsy>Yeah, I'm not saying this would fix it. <Madsy>I'm saying this is yet another hurdle to fix <mark_weaver>looks deliberate to me, and I suspect it's for a good reason. <Madsy>In my opinion, mixing differen thread libraries is like building an executable with several versions of libc <mark_weaver>yeah, I suspect we need to change guile to use win32 threads in windows. <mark_weaver>which we could perhaps do fairly easily by using gnulib's threadlib. <Madsy>Then you have to make sure that threadlib and libgc's solution play well together <mark_weaver>maybe there are complications I'm not thinking of though. <mark_weaver>on windows, threadlib seems to be a fairly thin wrapper over win32 threads. <mark_weaver>the alternative is to improve w32-pthreads and get libgc working with it, I suppose. <mark_weaver>partly it depends on what programs using guile would prefer to use as their thread library. <Madsy>Yeah it's theoretically possible if you ditch Windows XP support <Madsy>Later versions of Windows support everything you need to implement thread suspension <Madsy>I think it's from Windows Vista and up, but it might be Windows 7 <ArneBab>mark_weaver: I use that information Python all the time to develop iteratively: First I create my simple example in the file (run only when the file is called directly). As soon as that works, I use the file as a module (example no longer gets run). When I go back into the file to rework some code, I can always easily check whether it still works: Just run the file. <ArneBab>mark_weaver: I know that this is not the clean way™, but I’m currently writing the chapter on hackability, and that’s one of the cases where the hackability of Python really shines (it is used not only by me but by many people). <ArneBab>mark_weaver: I also tend to just put the equivalent of (when (file-run-directly) (run-doctests)) into the files. <mark_weaver>ArneBab: I suggest using the -e option when running it directly. <mark_weaver>that specifies a procedure to run within the module after loading. <ArneBab>mark_weaver: so there is no way to actually obtain that information? <mark_weaver>not that I know of. to my mind, it's like asking whether a procedure can find out who called it. personally, I think it's bad design to make a procedure act differently depending on who called it. <wingo>ArneBab: there's batch-mode? <wingo>that's only good for scripts though <mark_weaver>wingo: yeah, but that will be true even if some other script was run that merely used that module, no? <ArneBab>I only found the hack to check the commandline arguments: If the first commandline argument ends with the path to the module file, then it’s likely that the module got called directly. <mark_weaver>I mean, I can imagine various hacks to accomplish this, but they are gross and brittle. <mark_weaver>right, that hack came to my mind as well, but it's so bad that I didn't even want to mention it :) <ArneBab>the reason that it’s a standard method in Python is that it is really useful to be able to treat scripts as modules without having to change them <ArneBab>write a script, then reuse the procedures in the script from another script without changing anything <mark_weaver>well, you can make a script that's also a module, by putting a shebang at the top. and then you can arrange for the shebang to use the -e option to run a procedure in it. <mark_weaver>but then you run the script as "foo.scm" instead of "guile foo.scm". <mark_weaver>the guild script uses something like that technique. <mark_weaver>although guild is actually a shell script that then trampolines into guile. ***cmatei_ is now known as cmatei
<mark_weaver>ArneBab: here's an example of a (foo) module that can also be run directly as a script. the (unexported) 'main' procedure within will be called only when it's run as a script: http://paste.lisp.org/+3185 <mark_weaver>but personally, I would just use -e, and maybe make a little script in my private bin that does: guile -e main -s "$@" <ArneBab>mark_weaver: that sounds like a way to realize the same functionality in a different way. Sounds good! Thanks! <mark_weaver>'main' might not be the best name for the procedure for your use case. <mark_weaver>oh, hrm. the -e main looks for main in the (guile-user) module <ArneBab>It requires a bit more boilerplate-code, but the functionality is available. <ArneBab>so this breaks with the module-definition at the top? <mark_weaver>it's not hard to come up with a script that does the right thing, give me a minute. <mark_weaver>I must say, I just got bit by the fact that 'load' is arguably too clever, and interprets relative paths relative to the script instead of the cwd. <mark_weaver>I can understand the rationale for this, and I guess we're stuck with it now, but IMO this clever "load relative to the file doing the loading" should have been given a different name. <mark_weaver>well, I dunno. I suppose most of the time it's what you want. <mark_weaver>maybe the thing is to only do the magic behavior if the argument to load is a string literal. <ArneBab>in Python3 you now have to specify explicitely whether you want a relative import or an absolute one - with the default being absolute <ArneBab>maybe they have some rationale for that which could give inspiration for a schemish solutiion <mark_weaver>I think that we should probably fix -e to reference a binding in the module that was loaded, instead of (guile-user). <mark_weaver>I also think that 'load' should probably not be clever if its argument is a variable name (rather than a string literal). *mark_weaver adds to his TODO <mark_weaver>of course, there are back-compat issues to consider. <mark_weaver>-e was not really designed to work with modules. it was designed to work with scripts that didn't include 'define-module' in them. *ArneBab had to go AFK due to family matters for a bit <Zildiv>mark_weaver, Scheme's inconsistent nomenclature saddens me greatly. <Zildiv>Kind of like poor people dying in Africa, except it affects me directly and it's not in part due to following silly advice from the pope. <davexunit>Zildiv: examples of inconsistent nomenclature? <Zildiv>davexunit, vector-map and (list-map), the former provides an index, the latter does not. <Zildiv>Or list-sort rather than just sort <Zildiv>breakingt hwith the treadition of not putting list- in front of things having to deal with lists. <davexunit>well because lists are one of the fundamental data types. <davexunit>I prefer having map, for-each, etc. instead of list-map, list-for-each <Zildiv>davexunit, yes, so the inconsistency is that it is called list-sort <Zildiv>I'd rather they are just all called sort and map but you prefix them with modules <Zildiv>You can import it with the prefix list: or not if you want. <Zildiv>Now if you prefix it you can get weird things like vector:vector-ref <Zildiv>Though I tend to do s43:vector-ref <Madsy>Crap.. suddenly I'm unable to build guile at all :( <Madsy>Wonder what I did differently before I started messing with thread support <Madsy>nalaginrut: Doesn't matter. I'll figure it out eventually ***scott_ is now known as Guest73243
<Guest73243>I am currently getting this error while running make command <bg1>any help regarding the error: <bg1>/usr/bin/ld: cannot find -lguile-2.0 <bg1>collect2: error: ld returned 1 exit status <bg1>while running make command <artyom-poptsov>You can set LD_DEBUG environment variable to see debugging messages from ld <bg1>i'm quite new to this <bg1>can you tell how should I do that? <artyom-poptsov>Just set it to "help" to see list of possible values. If you use bash shell, you can set this variable in the following way: export LD_DEBUG=help <bg1>artyom-poptsov: so you mean I should run "$ export LD_DEBUG=help" ? <artyom-poptsov>Yes. After that if you try to run any program which use ld then ld will print list of possible values of LD_DEBUG. <bg1>artyom-poptsov: umm.. this is the result <bg1>/usr/bin/ld: cannot find -lguile-2.0 <bg1>I mean not the complete result but I guess the library is not linked <bg1>artyom-poptsov: libs <artyom-poptsov>You should be able to see pathes to libraries in debugging output from ld. Are there any mentions of guile-2.0? <artyom-poptsov>OK, probably I started from a wrong side. Is GNU Guile 2.0 installed on your system? <bg1>even I tried using guile 1.8 <bg1>but still no luck :( <artyom-poptsov>OK. Could you please tell me whether libguile is installed to the standard path like `/usr/lib' or somewhere else? ***u_l-lap is now known as unknown_lamer
<mark_weaver>bg1: what are you trying to build when the error happened? how did you install guile? <bg1>artyom-poptsov: yes in /usr/lib <bg1>mark_weaver: i was trying to compile a software which is quite old <mark_weaver>and how did you install guile? did you build it yourself from source code, or did you install a package from a distro? <bg1>GUILE = /usr/bin/guile <bg1>GUILE_CFLAGS = -pthread -I/usr/include/guile/2.0 <bg1>GUILE_CONFIG = /usr/bin/guile-config <bg1>GUILE_LDFLAGS = -lguile-2.0 -lgc <bg1>GUILE_LIBS = -lguile-2.0 -lgc <bg1>GUILE_LTLIBS = -lguile-2.0 -lgc <bg1>GUILE_TOOLS = /usr/bin/guile-tools <bg1>but there is no 2.0 folder in /usr/include/guile <bg1>mark_weaver: already have this package <mark_weaver>(or whatever the package name is, I might have it slightly wrong) <bg1>mark_weaver: What I surmised after installing guile is, that if I install <bg1>guile-2.0-dev it gives the above error and if I install guile-1.8-dev <bg1>then the following error is what I get: <bg1>/usr/bin/ld: cannot find -lguile-2.0 <bg1>collect2: error: ld returned 1 exit status <bg1>the above error : ../drgenius_config.h:28:22: fatal error: guile/gh.h: No such file or directory <bg1>compilation terminated. <mark_weaver>so the fact that you don't have those files makes me think that the package is not, in fact, installed in your system. <mark_weaver>or else your filesystem has become corrupted, or the files got deleted somehow, or something. <bg1>mark_weaver: I think the package is not correctly installed since I just re-installed Linux yesterday <mark_weaver>bg1: when there are multiple errors, always start by looking at the first error. the errors that follow are often caused by the avalanche of problems stemming from the early problems. <mark_weaver>in this case, the real problem is the lack of header files. the error you told us about was misleading and made it hard to figure out what was going on. <bg1>mark_weaver: here is the software I'm talking about <bg1>it's very small software <bg1>you can compile it too <mark_weaver>well, first of all, if you think that guile-2.0-dev is installed, but there's no /usr/include/guile/2.0 on your system, then something is very wrong. <mark_weaver>that really should not happen. I wonder if you are mistaken about the package being installed. <bg1>hey I reinstalled guile-2.0-dev.. <mark_weaver>but the other problem is that drgeo was written for a very old version of guile, and needs to be updated. <bg1>now there is 2.0 directry <mark_weaver>it includes <guile/gh.h> which no longer exists, and hasn't for a long time. <mark_weaver>you might have to go back to guile 1.6, or even 1.4, to use drgeo. <mark_weaver>however, I should say that if you want to play around with guile yourself, you should definitely use 2.0.x <bg1>umm.. how do i install 1.6 or even 1.4? <bg1>in the distro pack its not available <bg1>do I need to add any ppa > <mark_weaver>well, debian wheezy still has guile-1.6 and guile-1.6-dev packages <bg1>p.s: I'm on linux mint 15 <bg1>E: Package 'guile-1.6' has no installation candidate <bg1>i guess i need to add a ppa <bg1>maybe.. so how should i get it <wingo>we should deprecate dynamic states, so that fluids are truly thread-local... <mark_weaver>yeah, when I found out about dynamics states, that was a "wtf" moment :-/ <wingo>i'll send a mail to the list <mark_weaver>wingo: it looks to me like the WEAK_PAIR test in 'scm_internal_hash_fold' in hashtab.c:1425 (stable-2.0) has a TOCTTOU problem, and ditto for the proposed fix for 'scm_internal_hash_for_each_handle'. am I mistaken? <Zildiv>mark_weaver, the inconsistency of scheme's libraries and its transparent artefacts from 60 years of lisp evolution pain me so. <wingo>mark_weaver: yes -- really the pair needs to be accessed within the alloc lock <Zildiv>Mine is indeed a tormented existence, filled with torment, and girls, girls with their breasts, they torment me so. <wingo>Zildiv: that's inappropriate for this channel <mark_weaver>Zildiv: comments like those create a hostile environment for women who want to be involved here. <Zildiv>wingo, criticising scheme's historical artefacts or the quote from Sasuke? <mark_weaver>as for the inconsistencies, that tends to happen when a lot of different people work on something over a long period. <Zildiv>He's actually referring to himself as someone who has everything, beautiful women around him, but he's still tormented. <mark_weaver>Zildiv: I agree that things could be more consistent, and actually R7RS is a step in the right direction in that regard (e.g. the vector-map from R7RS doesn't pass indices to the proc) <ijp>Zildiv: if you are going to quote something, use quote marks, and quote something relevant <Zildiv>Is there a function for list and vectors which does pass it? <ijp>lists, no, because we don't tend to think of lists as being an indexed datastructure in functional programming <ijp>vectors, yes, in srfi 43 <mark_weaver>iirc, the srfi-43 vector-map passes an index to the proc, and the r7rs vector-map doesn't. <Zildiv>Yeah, so one would assume there are two functions, one which passes the index and one that doesn't. <Zildiv>THat, or a more generic function which does it all and can be controlled with flags. <Zildiv>Yes, that's one of the things that always struck me as oddly inconsistent. <mark_weaver>well, scheme allows you to create the APIs you prefer as modules, and import them in your own code. <ijp>a one-size-fits-all iterator is hard <mark_weaver>we are a diverse community, with diverse ideas about how APIs should be designed. SRFIs and RnRS standards have been created by many different people. <ijp>you end up with a something like looks like LOOP <mark_weaver>you can also author SRFIs with your own APIs, and if people like it, it might catch on and become widely used instead of the existing interfaces. <mark_weaver>having said that: IMO, the inconsistency of the existing interfaces is not bad enough to warrant making a set of slightly different ones. that would just add to the problem. <Zildiv>mark_weaver, yeah, I know, last time you recommended against it as it would fracture stuff even more, but like I said, it's quite tempting to go the Ocaml/Core route and just rewrite an entire usable standard library from scratch. <ijp>very tempting, which is why so many people do it <Zildiv>there's a good xkcd comic about this. <Zildiv>If there are 14 competing standards which are inconsistent, trying to replace them with one which fills all needs just results into 15 competing standards. <mark_weaver>regarding my previous statement that R7RS is a step in the right direction in that regard: I should qualify that. <mark_weaver>on the one hand, I think they did a nice job with some of the APIs, making them more consistent between lists/vectors/bytevectors/etc. <mark_weaver>on the other hand, R7RS doesn't specify nearly enough, so you end up having to go outside of the standard to write real programs. <Zildiv>mark_weaver, how much more expensive are binary records than cons cells in guile? <wingo>the overhead of a record is 2 words. the overhead of a pair is zero words <wingo>dynamic checking that the record is the right kind is a little more expensive than checking that something is a pair *davexunit made a screencast to demonstrate functional reactive programming with guile-2d <davexunit>the youtube-dl program can be used download the video and avoid running nonfree JS. <wingo>i watched it and it was neat :) <Madsy>davexunit: Sweet. Looks like my demo framework :) <tupi>davexunit: nice [and the webm is so much better] <davexunit>tupi: I agree. I should've just linked to the webm version. <saul>It always amazes how Scheme programmers are able to hop around while writing code without losing their place. Don't see that too much with other langs. ***cluck` is now known as cluck
<cluck>davexunit: you might want to make that a torrent, video files on personal servers are a quick way to go over your data quota (and nice work) ***Zildiv is now known as Molkolev_Zed
<ijp>did anyone start writing webkit bindings for guile? <ijp>mark_weaver: I think my brain was confusing a half-remembered thread from a year ago and the stuff shanecelis did <cluck>ijp: iirc the conkeror author had plans to eventually move from js to guile scheme, dunno if those ever got anywhere <davexunit>cluck: it's only a 10MB file and I have an absurdly high bandwidth limit for my $5/month VPS <davexunit>I just wanted a way for people to avoid youtube. what I really need is an account on a mediagoblin server. <davexunit>ArneBab: thanks. I wanted to talk instead of type stuff, but I didn't want to fiddle with syncing audio and whatnot. <ArneBab>just adding an audiotrack isquite easy with cinelerra or kdenlive <davexunit>I think I could throw one on with ffmpeg quickly too <davexunit>I don't know how to use video editors since I have never done any real video editing. <ArneBab>with kdenlive it’s just drag-and-drop, but ffmpeg is good ☺ <davexunit>or I will talk into the microphone if I can sync it up right. <ArneBab>you could try using kdenlive - when it works it works really easily <ArneBab>when iit does not do so right now, just use something else…