IRC channel logs


back to list of logs

***sneek_ is now known as sneek
<davexunit>good evening guilers
***fangism is now known as fangism-hungry
***Gues_____ is now known as Guest78399
<ckoch786_>I am learning guile and have no clue why I am getting this error see first comment for error message
<ckoch786_>When I break it apart and execute it separatly it works fine
<ckoch786_>My only guess is that the `(channel) is not being replaced with "channel name" when it is called
<ckoch786_>but I do not know why that would be
<mark_weaver>the (let ls ((append ...)) ...) is bad syntax.
<mark_weaver>that's trying to bind 'append' to the value of ..., but there are two expressions after the 'append', which is incorrect.
<mark_weaver>what are you trying to do there?
<mark_weaver>I guess maybe you want (let ((ls (append ...))) ...) instead
<ckoch786_>I am trying to put together the command in a list, then apply the car (the command ) to the cdr (the arguments)
<ckoch786_>I want ls to contain the list so I can perform the later operations on it
<ckoch786_>Is there a better way to do this?
<mark_weaver>so in the end you want to do the equivalent of (xchat:command "join" "#emacs"), for example?
<mark_weaver>if so, you probably want (let ((ls (list xchat:command "join" channel))) ...)
<mark_weaver>the display could be more nicely written as: (format #t "Joining ~a\\n" channel)
<mark_weaver>also, instead of (map join channel-ls), use (for-each join channel-ls)
<mark_weaver>'map' builds a list of the results of calling (join ...), which is a waste.
<ckoch786_>I want the end command to be of this form (xchat:command "join #bedrock")
<mark_weaver>to explain a bit more: '(channel) is a constant list that contains just one element: 'channel', a symbol.
<mark_weaver>i.e. it does not look up the value in the variable 'channel' if you write '(channel)
<ckoch786_>I did not know that, I thought I had to do it in order to use it as a list
<mark_weaver>whenever you quote a list by putting apostrophe in front of it, nothing inside will be evaluated...
<mark_weaver>if you want to create a list that is not a constant, then there are a couple of ways to do so. one way is to use (list ...).
<mark_weaver>another is to use quasiquotation, which allows you to "unquote" portions of it. e.g. you could do: `(,xchat:command "join" ,channel)
<mark_weaver>note that that starts with backquote (`) instead of an apostrophe (')
<mark_weaver>` stands for "quasiquote", and the commas (,) stand for "unquote".
<mark_weaver>so after each comma is an expression that is evaluated, e.g. variables will be looked up and replaced with their values.
<mark_weaver>you can also put more complex expressions after the comma, e.g. `(1 + 1 = ,(+ 1 1)) => (1 + 1 = 2)
<mark_weaver>oh, sorry, I see now that you need it to be (xchat:command "join #bedrock")
<mark_weaver>what are you going to do with 'ls' afterwards?
<ckoch786_>right, I was about to ask but was warking on digesting the above :)
<mark_weaver>it seems kind of silly to leave the procedure 'xchat:command' in that list.
<mark_weaver>I would just do something like (xchat:command (format #f "join ~a" channel))
<mark_weaver>(format #t ...) prints to the current output port... (format #f ...) returns the result as a string.
<mark_weaver>to build strings from templates, 'format' is a pretty good tool.. for building list structures from templates, quasiquote is fantastic.
<ckoch786_>I wanted to us the list in ls to perform the apply function on the car and cdr of ls to run the command after I build it
<mark_weaver>well, then you can do (let ((ls (list xchat:command (format #f "join ~a" channel)))) ...)
<mark_weaver>where ... could be replaced with (apply (car ls) (cdr ls)) if you like.
<ckoch786_>it works, thanks!
<mark_weaver>you're welcome!
<ckoch786_>the new code :)
<mark_weaver>looks good!
<nalaginrut>mark_weaver: I'm playing gnome3 for my day job, and I think maybe a dev/debug environment in GUI is nice, and I think maybe counting the details object size would be a cool feature
<mark_weaver>well, it would be a lot of work, and the answers it gave would be likely misinterpreted and probably of little use.
<mark_weaver>the problem is that the heap is an arbitrary graph of pairs, vectors, and other objects pointing to each other, and a variable really just points to some node within this arbitrary graph.
<mark_weaver>for example, if you have (define a <huge-list>) and (define b (cons 'foo a))
<mark_weaver>then we might report: a is of size 20 megs, and b is also of size 20 megs.
<mark_weaver>and the user will think that together it is 40 megs, but that's not true.
<mark_weaver>and what about procedures? how deeply do you traverse this graph?
<mark_weaver>it's a big mess. if the only justification is for a cool number to look at in a GUI, I'm not sure that justifies the work it would entail.
<nalaginrut>hmm...sounds reasonable
<civodul>Hello Guilers!
<taylanub>Happy friday! :) Although yet it is morning ..
<DerGuteMoritz>hello guilers, check out :-)
<janneke>DerGuteMoritz: interesting
<civodul>looks nice
<civodul>too bad it collides with :-/
<janneke>I won't be there that weekend -- any lilyponders going?
<civodul>to GHM or quasiconf?
<civodul>i don't see any lilyponder listed on the GHM page
<civodul>so you'll have to come ;-)
<janneke>civodul: i meant quasiconf -- but in fact both would be good :-)
<janneke>civodul: i have a training that weekend
<DerGuteMoritz>ah how unfortunate @ ghm
<nalaginrut>ab -c 5000 -n 10000 for Artanis, route parsing+template rendering+mysql query, 120req/s
<nalaginrut>testing -c 10000 -n 100000
<nalaginrut>it's amazing about the Guile inner server, not sure if we have ethread, what'll happen...
<nalaginrut>DerGuteMoritz: nice~I'll bring my paper after finish guile-on-rails, but next year
<wingo>i don't know if it makes sense to try to go to both ghm and quasiconf, would have to look at travel links
<nalaginrut>108req/s for 10K concurrency, but I tested on remote host, anyway, I do think there're lot of room for improving
<mgsk>When r7rs is finished, will guile's modules move to use the define-library syntax instead of its homemade define-module?
<dsmith>mgsk, Like how guile currently supports r6rs syntax?
***Gues_____ is now known as Guest11155
<mgsk>dsmith: I'm not sure I understand you. I mean, rather than using define-module which is afaik guile-specific [and thereby ties lots of guile's code to just guile], will guile instead use r7rs's define-syntax for better cross-implementation support.
<mgsk>It would be neat if the web module could be used by other implementations.
<mgsk>Is r6rs a thing? I thought r7rs was a way to forget r6rs.
<mgsk>[For example it would be neat...*]
<dsmith>mgsk, Well, I can't speak for the guile devs, but they support DO r6rs syntax as macros over the guile syntax. That can probably be done for r7rs as well.
<dsmith>I would doubt very much that that they would drop the guile syntax
<dsmith>s/that that/that they/
<mgsk>I suppose I just don't like how much scheme code is incompatible across implementations. Sigh
<amgarching>Hi! Does scm_misc_error() call longjmp() at the end?
<amgarching>it calls scm_ithrow()
<amgarching>then scm_throw() calls scheme again ... Hm.
<nalaginrut>mgsk: I don't think it's a hard thing to use define-library instead of define-module, actually you can use r6rs 'library' as well
<wingo>amgarchIn9: and then scheme's throw does an abort-to-prompt
<wingo>which does a longjmp :)
<mgsk>nalaginrut: yes, but my question is whether the maintainers of modules such as web will use the standard define-library rather than guile's own define-module.
<amgarching>ok, so I keep the warning comment about longjmp() then. Thanks, wingo.
<nalaginrut>mgsk: I don't know, the modules may contains Guile specific things. But if not, I think it's easy to write a wrapper for that, but I don't think it's worth to change all the current modules for such a purpose.
<wingo>if there were a standard module form that wasn't ugly and was as expressive as guile's modules, it would make sense
<wingo>imo anyway
<amgarching>mgsk: R7RS probably does not specify how to do networking. No such cross-Scheme webserver library is possible.
<DerGuteMoritz>wingo: ah you're thinking of doing that? for all I know, the train connection between Paris and Cologne is quite good via Thalys
<wingo>DerGuteMoritz: seems it's 60 euros, 3h14m
<wingo>so that's not bad
<DerGuteMoritz>enough to prepare a presentation! :-D
***Gues_____ is now known as Guest91761
<shanecelis>hey guys. I think I found a bug.
*shanecelis emails
<taylanub>shanecelis: You didn't initialize libguile. :)
<taylanub>I.e. from what I know it shouldn't work without a goto either .. maybe it works by accident in some cases. Or maybe I'm entirely mistaken, but from what I know one always needs to initialize libguile.
<civodul>yes, but here it looks like a C issue
<civodul>if the declaration is moved above the label, it probably works
<shanecelis>taylanub: Good point. I added that. Same issue.
<shanecelis>civodul: Probably, yes. That's another good workaround.
<taylanub>Maybe wrapping the declaration in braces would also do. I've been trying to make a habit out of that, imitating `let' in C.
<taylanub>(`let*', rather.)
<shanecelis>taylanub: Yeah, that would create a new scope though.
<taylanub>Right .. anyway, does the code work for other types of declarations there ? Aren't both SCM and SCM_BOOL_T macros which expand to, respectively, a plain type for the means of variable-declaration, and a constant ?
<davexunit>automake in debian wheezy is too old to build guile 2.0.9 :(
<tupi>davexunit: you need to add a preferences file [/etc/apt] and pinf experimental for automake
***bdmst is now known as boredomist
<dsmith-work>Happy Friday, Guilers!!
<tupi>happy friday dsmith-work!
<add^_>It's strange, I was tempted by the dark side (CL) but you know... Scheme is still more awesome :-)
<davexunit>tupi: thanks. I'll have to do that.
<add^_>dsmith-work: Happy Friday!
<add^_>davexunit: I'm trying to "make run-demo" on gnumaku, not working though. Something about a file missing and an unbound variable.
<davexunit>add^_: that's because gnumaku master is a mess. :(
<davexunit>I could perhaps help you through it though
<add^_>davexunit: ah, let's hope so ;-)
<add^_>I just wanted to see how far you've gotten, but it's a bit hard when it doesn't run correctly. And I know you've gotten further than that! xD
<add^_>Also going to look at your code afterwards (or now, depends) to see if I can learn something :-)
<davexunit>I haven't run this in quite some time. let's see...
<davexunit>there's a lot of bad code. be warned.
<add^_>No worries, I've probably made worse myself ;-)
<davexunit>my plan for gnumaku is to remove nearly all of the code that you see.
<add^_>What code don't I see?
<davexunit>all I need to keep is the coroutine stuff and the particle system C code.
<davexunit>my point is: gnumaku should be really small. the reason that it grew so big was that I was filling in holes because guile lacked the game library I wanted.
<add^_>so basically the particle_systems.* files and the agenda.scm file?
<davexunit>yeah and coroutine.scm, if it's there.
<davexunit>you could also try running the code in the "gshmup" repository. it's another failed approach, but from a different angle. :P
<add^_>gonna try
<add^_>what a funny name though
<davexunit>more stuff done from C
<davexunit>better pronounced like "g shmup"
<add^_>Hm, ah, it looks for guile in /usr/bin/guile instead of /usr/local/bin
<add^_> /guile
<add^_>Gonna make a quick tweak in your makefile I suppose
<add^_>or not
<davexunit>sorry. this project is so not ready for other people to use.
<add^_>It's ok, I was more interested, as I said, in how long you've gotten
<davexunit>the demo, if I remember, is full of craziness
<davexunit>since it was a just an ever growing test of everything
<davexunit>change ./demo.scm to run the correct guile executable
<add^_>I think it's a bit sad that you can't get much credits for putting so much effort into it (since it doesn't really work right now, or atleast needs a lot of tweaking)
<add^_>./demo.scm ? It's still gshmup?
<add^_>The demo.scm has the right path
<davexunit>oh I was talking about gnumaku
<davexunit>add^_: I knew 0 about guile when I wrote this. it was more about learning.
<add^_>Heh, and that's ok. I'm still learning ;-)
<davexunit>now I know how to approach this better. gnumaku *will* get an overhaul.
<davexunit>there's a 'rebirth' branch that is a rewrite that uses my allegro5 binding, but that's defunct now too.
<davexunit>stick with master, though.
<davexunit>gshmup requires guile-allegro5 to be installed, if you're trying that.
<add^_>I'm looking at gshmup demo videos :-D
<davexunit>oh yeah at least there are those
<add^_>The last enemy in gnumaku demo #4 is... way overkill xD
*davexunit looks for that video to remind himself about it
<davexunit>oh that's nothing :P
<add^_>oh, looked at your channel and got to OpenMW :-D
<davexunit>now that's a cool project
<add^_>Your project is nice too though :-)
<davexunit>gnumaku will resume development once I have enough of my 2d game dev library working.
<davexunit>however, to make the library, features need to be added to guile-sdl and guile-figl
<davexunit>so, give me some time :P
<add^_>Don't feel like I'm pressuring you!
<davexunit>I won't. :)
<davexunit>I have all this stuff I want to do and so little time.
<davexunit>patch guile-sdl and guile-figle so I can write guile-2d, then write a small C extension for particle systems, and *then* I will have gnumaku back in action.
<add^_>is guile-2d supposed to be guile-sdl and guile-figl combined?
<davexunit>yeah basically.
<davexunit>SDL handles all the window management, input events, sounds, etc.
<davexunit>and then the GL stuff for graphics, obviously.
<davexunit>so the library would be an abstraction layer to quickly kickstart 2d game development.
<davexunit>game loop, input handlers, sprites and sprite batches, etc.
<davexunit>the majority of gnumaku's code right now is that nonsense.
<davexunit>it's too much stuff poorly glued together.
<davexunit>thanks for giving my code a try, add^_
<davexunit>I'm going to try to be careful to make my future projects better documented and easier to run.
<mark_weaver>sneek: later tell shanecelis the issue you found is not related to Guile. The following also fails: int main() { foo: int a; }, but if you add a semicolon after the label then it works. GCC from Debian Wheezy says: "error: a label can only be part of a statement and a declaration is not a statement"
<sneek>Got it.
<mark_weaver>davexunit: the super-easy solution to upgrade automake on Debian Wheezy is this: wget && sudo dpkg -i automake_1.12.6-2_all.deb
<mark_weaver>However, it's worth mentioning that this won't check the signature on the downloaded package. Tupi's suggestion is better but a bit more work.
<mark_weaver>davexunit: the more proper solution is to add the line "deb experimental main" to /etc/apt/sources.list, and put the following stanza in /etc/apt/preferences:
<mark_weaver>Package: automake
<mark_weaver>Pin: release a=experimental
<mark_weaver>Pin-Priority: 950
<mark_weaver>then "apt-get update; apt-get install automake"
<davexunit>mark_weaver: ah yes. I did something awhile ago last time I used debian. you have refreshed my memory.
<mark_weaver>I also recommend building gc-7.2d from source code and installing in /usr/local. It's here:
<mark_weaver>(and standard "./configure && make && make check && sudo make install" suffices)
<mark_weaver>The gc-7.1 in Debian Wheezy is very old and has some issues. Such a shame they didn't upgrade that in Wheezy.
<davexunit>such is life on debian stable.
<davexunit>thanks for the gc source
<dsmith-work>sneek: libgc
<sneek>Someone once said libgc is
<add^_>sneek: botsnack
<add^_>A bit slow there ;-)
*add^_ expected instant answer
<mark_weaver>sneek: botsnack
<mark_weaver>add^_: yeah, sneek is running on a modest Raspberry Pi.
<fbs>sneek: improve yourself
***fangism-hungry is now known as fangism
<davexunit>hmm I had this problem before but I forgot how I dealt with it. when running ./configure: error: GNU MP 4.1 or greater not found, see README
<davexunit>I have: /usr/lib/x86_64-linux-gnu/
<davexunit>oh wait. got it.
<davexunit>my amnesia went away.
<davexunit>is it a good idea to ./configure --prefix=/usr, or should I be installing everything I compile myself into /usr/local ?
<janneke>davexunit: i install everything in ~/guile-2 but that requires some env settings to use it
<mark_weaver>I use /usr/local, fwiw.
<fbs>I guess /usr/local is better for possible package manager conflicts
<dsmith-work>I usually use /usr/local, mainly because it's the default and I then don't need to specify a --prefix
<dsmith-work>Also, the .so's end up in a place where ldconfig (usually) can find them.
<dsmith-work>And so I don't need to mess with LD_LIBRARY_PATH
<mark_weaver>/usr/local works "out of the box" on Debian systems because /usr/local/lib is included in /etc/
<mark_weaver>if you want to include another directory in the default library search path, just add it to /etc/ or to a file within /etc/
<mark_weaver>I would definitely avoid installing hand-compiled stuff in /usr on a Debian system.
<dsmith-work>mark_weaver: Yep. Though I *do* remember needed to add /usr/local/lib's config files on Debian in the past. But nowadays it's already there.
<dsmith-work>Of course, if you are not root on the box, then ~/somewhere and LD_LIBRARY_PATH is your only option.
<mark_weaver>ah, okay. I can't remember that far back :)
*dsmith-work actually installed Debian 1.0
<dsmith-work>Yes. 1 point *0*
<dsmith-work>(there *is* no 1.0)
<dsmith-work>Except by a cd publisher who jumped the gun
<mark_weaver>I played with Debian a bit in the *very* early days, when Bruce Parens was heavily involved.. but then went to BSD for a long while before returning to Debian almost exclusively since about 1999
<mark_weaver>1.0, that's pretty impressive :)
<dsmith-work>The first thing that really attracted me, was the mailing list were "nice". the redhat list were full of idiots.
<dsmith-work>YOUR STUFF SUCKS MAN!
<mark_weaver>interesting, I didn't know that :)
<mark_weaver>I contributed a few fixes in a very early days, and posted some on the ML. I wonder if their archives go back far enough to see them.
<dsmith-work>mark_weaver: The bsd's are awesome though.
<dsmith-work>So many things are great about them.
<dsmith-work>Just simple things. Like kernel startup messages are actually very well defined.
<dsmith-work>Actual useful documentation on kernel drivers.
<mark_weaver>yeah, the BSDs have some advantages, but these days I consider the lack of copyleft to be a very serious problem.
<mark_weaver>I care more about freedom than most other issues at this point.
<davexunit>copyleft seems to be on the decline and it's sad.
<mark_weaver>yeah, Eben Moglen recently talked about the decline of copyleft. it was featured on LWN a few weeks ago.
<davexunit>these days it's all about your the latest proprietary web application built from MIT and BSD licenses libraries.
<davexunit>this comment on a hacker news thread about RMS is a pretty good example of the thinking that I see more and more of.
<fbs>link seems not working
<davexunit>hmm... one sec.
<mark_weaver>ah, indeed, I used Debian before 1.0. I'm not really proud of what I wrote here, but:
<mark_weaver>There's always been a lot of that kind of talk about RMS.
<mark_weaver>It's mostly about where you look. I'm not surprised to see that attitude at ycombinator, which is steeped with an entrepreneurial spirit.
<mark_weaver>Anyway, regarding "if he thinks he's still as singularly important as he once was, he's delusional", he's under no delusion about that. About a decade ago, when I saw him all the time, he was very aware of how effectively he's been marginalized.
<mark_weaver>(I won't try to paraphrase things he said, given that it's been a long time, but he was very clear on that point)