<ijp>no, pirates have made a guile prerelease! <Madsy>guile-2.0.10[FREESTANDING][WIN7]-Razor1911.zip <civodul>mark_weaver: yep, it just landed :-) <mark_weaver>zacts: time to put the hash in your freebsd ports patch and submit it! :) *davexunit reads the NEWS file <davexunit>I'm excited about srfi 64. I need to learn to use it so I can finally add some test coverage to guile-2d. <davexunit>I'm having a problem with guile-2d. some modules rely on an opengl context in order to work. however, there is no opengl context unless a window has been opened first. right now I have a module that opens a window when it's imported, but it's an ugly a hack. importing a module shouldn't open a window. <davexunit>I need some other mechanism to handle this and I'm looking for prior art. <davexunit>maybe nothing that requires an opengl context should be run upon module import, like loading a GLSL shader. <mark_weaver>I'd think that anything that requires an opengl context should be called explicitly by the user. <mark_weaver>so yeah, I think that loading modules shouldn't do anything like that automatically, IMO anyway. <davexunit>however, I still want things to be convenient to use. <davexunit>I could use delay/force to load shaders the first time that they are used, but that means that the loading from disk happens while the game loop is trying to draw things. <davexunit>which seems unideal to me. an initialization hook also seems unideal because a user could want to control when those shaders are loaded. <davexunit>for instance during a loading screen at the beginning of their game. <davexunit>I guess the only reasonable option right now is an explicit function that loads the shaders and assigns value to the top-level variables. <cky>Wow, that's news! Congrats! (Re 2.0.10.) <cky>(I've updated both my Gitorious and GitHub mirrors with the v2.0.10 tag, for people who follow either of those.) <cky>nalaginrut: Heya! Guile 2.0.10 is out! <nalaginrut>BTW, I've been playing master for weeks, I'm enjoying~ <Madsy>Yeah, congrats to all the guile developers :) <b4283>you play master, i'll play disciple <nalaginrut>yeah, I can say 'I'm playing master everyday', sounds so neat ***Guest97126 is now known as jao
<zRecursive>After `git pull`, how can i just see the modified parts ? <mark_weaver>zRecursive: first, take note of what commit you were at before the 'git pull', which is shown in the output of 'git pull': the first hex number in a range that might look something like this: "950a966..92b793d stable-2.0 -> origin/stable-2.0" <mark_weaver>and then there are a couple of options. you could run "git diff <hex>..92b793d" to see the diff. <mark_weaver>or you could run "git log -p" to see each commit as a separate diff, until you get to the commit that starts with that <hex> number. <mark_weaver>if you use emacs, I recommend the 'magit' package, which makes working with git much more pleasant. you can run M-x magit-log to see the list of commits and hit RET on any line to see the diff for that commit. <zRecursive>mark_weaver: git show 'HEAD@{1}..HEAD' seems work *mark_weaver still has much to learn about git <b4283>mark_weaver's solution is what i had in mind too, take a look at hash before pull, pull, then git diff the two hashes <b4283>"A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1}, {15}) specifies the n-th prior value of that ref." <mark_weaver>the <refname>@{<n>} syntax, e.g. HEAD@{1}, to reference the n-th prior value of that ref, is a lot nicer than taking note of the hex :) <b4283>so i guess the git system keeps a history of any branch is pointing which commit <adhoc>b4283: it has a bunch of objects and some labels <adhoc>those labels point to the objects <wingo>surprised to see it there, technical articles do very poorly on news.yc <civodul>"it uses Function.prototype.toString(), to read the source code of the function that is being called, and extract the names that the parameters were given in your source." <civodul>i wonder how JS implementors deal with that :-) <wingo>you just keep the source around :) <wingo>you have to do that anyway for lazy compilation <wingo>but yeah, users are a pain :) <civodul>and they have all the tools to be a pain :-) <wingo>Function.prototype.toString is the least of these :) <saul>Would somebody care to explain to me what an "unwind thunk" is? <wingo>saul: it's an imprecise term :) <wingo>if you're referrign to my article i meant the third argument to dynamic wind <wingo>(dynamic-wind wind-thunk body-thunk unwind-thunk) <wingo>a thunk just being a function of zero arguments <saul>wingo, I was mainly hoping for a better apprehension of what it means to wind and unwind. I have a pretty good grasp of things such as environments, continuations, and lambdas (and thunks). <wingo>dynamic-wind is pretty hairy <wingo>"winding" means calling a thunk before you enter the dynamic extent of the body thunk <wingo>"unwinding" is calling a thunk just after you leave the dynamic extent of the body <wingo>usually the dynamic extent starts with a call to the body, and ends with a return from the body <wingo>but it can end early, if the body throws an exception <wingo>regardless of how control flow exits the extent of the scope, dynamic-wind arranges for the unwinder to be caller <wingo>likewise control can re-enter the dynamic extent of a dynamic-wind body <wingo>using call/cc or delimited continuations <saul>Is the main idea to be able to inject entry and exit handlers for when the wind thunk is executed/evaluated? <saul>s/wind thunk/body thunk/ <saul>... with wind-thunk being the entry handler and unwind-thunk being the exit handler? ***vicenteH` is now known as vicenteH
<cky>saul: Here's one application of dynamic-wind: if your section of code holds a lock, and you need to unlock when leaving your section, and reacquire the lock if it gets reentered. <cky>civodul: Done (re upvoting Guile 2.0.10 article on HN). <mark_weaver>davexunit: thanks for your excellent comments there :) <davexunit>I was pleasantly surprised to see the release announcement on the HN front page when I woke up. :) <civodul>and it's still there, so i suppose that's quite an achievement <saul>wingo and cky, thank you for answering all my questions about wind thunks. <davexunit>call-with-stack-overflow-handler will definitely come in handy when working at the REPL. <cky>davexunit: call-with-stack-overflow-handler? Does that call the handler when the code is confused and needs to query stackoverflow.com? ;-) <ft>that sounds like a lot of latency. :) <cky>ft: Nah, not with SO's Fastest Gun in the West. <cky>ft: For really hot questions, you can get an answer within a minute, usually less. <ft>cky: Really? ...I must admit, that I have never asked a question on SO and only answered a handful. <ft>That's like IRC turnaround time. <cky>What? IRC turnaround time is usually more like 24 hours, depending on the lurking rate in the channel in question. ;-) <cky>But certainly for questions in common languages, like C#, Java, or C++, you can usually get answers very quickly. Some people monitor questions using tag-specific RSS feeds. <davexunit>cky: that's *exactly* what that procedure does. <cky>I used to answer lots of questions on SO, but these days I focus on Scheme questions only. <davexunit>I feel like the questions answered there should really make it back to the documentation of their associated projects, and sometimes I feel that people rely on SO knowing the answer instead of actually reading the damn documentation. <cky>And I don't use an RSS feed. I rely on SO's email notifications instead (which has a delay of up to 15 minutes). <davexunit>what are SO's terms of service? do they own your submissions? <cky>davexunit: That's _exactly_ what SO was created for. For people who won't RTFM. <cky>davexunit: No, you own your submissions but are obliged to license it under CC-BY-SA 3.0. <cky>I have an explicit clause in my profile that says that code snippets in my posts are additionally licensed under WTFPL. <cky>SO's implementation of their CC attribution clause is that people are required to link back (without using nofollow) to the SO post that contains the answer. My additional WTFPL licence for my code snippets basically says that people using my code snippets don't have to link back and are in fact welcome and encouraged to "plagiarise" my snippets freely. <cky>davexunit: If you do decide to contribute to SO, especially for [scheme] and [guile], I welcome your contributions in advance. :-D <davexunit>cky: well given that the licensing situation seems acceptable, maybe I could lend a hand. <tupi>i wonder what if i use par-map inside a [guile-]sqlite transaction <tupi>sorry, incomplete statement, but it works fine because the transaction actually makes sqlite 'holding on' what needs to be done and does it at once with its own code... par-map gets things done substantially faster in mem of course so great <zacts>mark_weaver: cool, thanks dude! <mark_weaver>guile 2.0.10 in upstream freebsd ports would be a very good thing :) <zacts>mark_weaver: yeah, we'll see if I can get a PR ready within the next couple of days. My mentor is wanting to fix a few things, and wants to use pkg-config rather than env variables. <zacts>PR = FreeBSD problem report, the way FreeBSD devs send patches for ports <zacts>I'm *so* ready to start working on guix next. <tupi>mark_weaver: for info, i noticed that debian [all versions] holds on guile-1.6 [and friends, -dev, lib...] because of guile-pg-0.16 [prehistorical version]. also, rotty did not answer [yet] my email about making guile-gnome-2 depending on guile-2 instead of guile-1.8: any one has heard of him recently? <ijp>like once, a few months ago <ijp>and a year before that <tupi>i hope he's ok, he used to appear here from time to time <tupi>what the sneek quiz again? <mark_weaver>I heard something about plans to remove guile 1.8 from debian sid, but now I don't remember where I heard it. <mark_weaver>oh, looking back through my logs, I heard it from you, tupi :) <zacts>mark_weaver: we are thinking about totally replacing guile-1.8 with guile-2.0 on FreeBSD. <zacts>so that will be a bit more work, but it will make things simpler in the long run <mark_weaver>I just hope that making the job bigger won't lead to it never getting done :) <zacts>mark_weaver: heh, no. I'll have it done within the next few days probably. <mark_weaver>the important thing is to get guile-2.0.10 in there. removing guile-1.8 is a secondary thing. I'm not sure why one has to be tied to the other. <zacts>mark_weaver: kwm on #bsdports @ irc.efnet.org who is mentoring me for this project, wants to replace guile-1.8 with guile-2.0 <zacts>the main thing is to get guile2 to build on the redports build farm. <zacts>once that happens it's really just a matter of modifying a few lines in several ports to get it working. <tupi>mark_weaver: agreed, but making guile-gnome-2 depending on guile-2 is somehow a guile community 'problem', which is why i wrote to rotty, may be he will answer later ... <mark_weaver>I should mention that there are a couple of projects that (unfortunately) have yet to be ported to guile 2.0, namely lilypond and texmacs. <zacts>mark_weaver: heh, yeah. by myself. it doesn't currently build within the poudriere build framework due to me needing to clean up the Makefile a bit. <zacts>once it builds I'm going to send my patch to kwm, and then we will clean up all of the dependencies, and then submit a PR. <zacts>'builds' == builds on redports <zacts>mark_weaver: do you know if gnome-games requires 1.8, or will it work with 2.0? <zacts>just if you happen to know off-hand. <mark_weaver>I expect that most programs that work with 1.8 would be fairly easy to upgrade to 2.0. <saul>zacts, I haven't checked recently, however, Aisle Riot uses Guile 1.8, but only for its Help system. The games still ran with 2.0 but you couldn't use Help. <zacts>saul: oh, thanks for the info <bu^>hello, is there an equivalent to expt but for logarithm ? <bu^>then I dunno how easy it can be to implement <ijp>logarithm to a different base is pretty simple <ijp>(/ (ln x) (ln base)) IIRC <ijp>optional second argument was added to scheme in r6rs, so you could import from that module <wingo>perhaps we should have a two-argument log <ijp>wingo: like I say, it's already in (rnrs), just not (guile) <wingo>ijp: do you usually program with the r6rs stuff? <bu^>ijp, I don't find it in guile manual <taylanub>Delayed congrats on the .10 release BTW. :) <ijp>bu^: either just do the division or (use-modules ((rnrs) #:select (log))) <bu^>oh ok, it's just the documentation that was not updated <bu^>scheme@(guile-user)> (use-modules ((rnrs) #:select (log))) <bu^>scheme@(guile-user)> (help log) <bu^>`log' is a procedure in the (ice-9 safe-r5rs) module. <bu^>- Scheme Procedure: log z <bu^> Return the natural logarithm of Z. <ijp>hmm, I'd need to doublecheck which version I added the change <ijp>in any case, (/ (log n) (log base)) <bu^>but, scheme@(guile-user)> (log 3 10) <bu^>$10 = 0.47712125471966244 <bu^>so its ok, just that I was referring too much on documentation ^^ <ijp>bu^: I'm surprised it explicitly mentions (ice-9 safe-r5rs) then <ijp>when I do it, it refers to (rnrs) <bu^>scheme@(guile-user)> (log 3 10) <bu^>;;; <stdin>:1:0: warning: possibly wrong number of arguments to `log' <ijp>change was added in 2.0.2 anyway, so it should be in most packaged been 2.0s <bu^>scheme@(guile-user)> (use-modules ((rnrs) #:select (log))) <bu^>scheme@(guile-user)> (help log) <bu^>`log' is a procedure in the (rnrs) module. <bu^>and gives the same result <bu^>but the doc still is not more accurate <bu^>as it doesn't describe the second optional argumen <ijp>true, and neither will ,d <mark_weaver>I agree that we should make the core 'log' accept two arguments. For one thing, we could give more precise results (even exact ones) when the base is an exact rational. <mark_weaver>for example, I'd like (log n 10) to give a sensible answer even when 'n' is out of the range of an IEEE double. <mark_weaver>oh, actually, I think I already arranged for that, at least. <bu^>ijp, why can't the doc be updated to refere to the second argument ? <ijp>well, it is documented....in the r6rs <bu^>and loading it doesn't update the procedure documentation accessible from (help ) ? <bu^>I mean is it possible at least ? <ijp>well, you are the first person I've seen refer to the help procedure in a good while <ijp>I'm not sure how docstrings and case-lambda interact <ijp>actually, help wouldn't even refer to the docstring, but the manual entry <bu^>to be honest I'm not that familiar with scheme, so I like to use (help ) <ijp>,d is probably used more than help these days <bu^>and I'm also a bit lost with all the differents norms, conventions, libraries etc... <mark_weaver>the issue is that the R6RS definition of 'log' doesn't have a docstring, presumably because R6RS doesn't have docstrings. <bu^>scheme@(guile-user)> ,d log <bu^>- Scheme Procedure: log z <bu^> Return the natural logarithm of Z. <ijp>that whole (rnrs base) manual section seems almost superfluous <bu^>but because me being so lost my main source is the help and documentation <mark_weaver>the fundamentals are mostly there, so it probably wouldn't take much work to make it much better, but someone has to do the work. <bu^>so if now you tell me that there are hidden arguments to functions that aren't documented anywhere, I get even more confused :) <ijp>well, it's not hidden <bu^>what should I rely on as my prime source ? <mark_weaver>it's true that even the (rnrs base) section of our manual says 'log' takes only one argument. that should be fixed. <ijp>scheme@(guile-user)> log $4 = #<procedure log (n) | (n base)> <ijp>mark_weaver: yeah, we can fix that <mark_weaver>and using the guile manual when you need functionality that's not available in R6RS. <ijp>anyway, I expect that most people who need it, just do the division anyway <bu^>no problem, was just to point out a few things I didn't really understand, thx for the help ! good night