IRC channel logs

<mark_weaver>madsy: no. what can be any string at all. it's actually completely ignored at present, but I think the idea was that it would be attached to the block somehow for debugging purposes.

<mark_weaver>you can use 'scm_gc_malloc' to allocate any kind of memory block you want.

<madsy>Ah, okay. I thought it was a type binding from scm_make_smob_type

<madsy>By the way, can I somehow make the gc in libguile more verbose while testing this code?

<mark_weaver>boehm gc pays attention to several environment variables. read about them here: https://github.com/ivmai/bdwgc/blob/master/doc/README.environment

<mark_weaver>sneek: gc-env is https://github.com/ivmai/bdwgc/blob/master/doc/README.environment

<madsy>Great, thanks

<mark_weaver>oh well, I wonder where sneek went.

<dsmith-work>Aww.

<mark_weaver>I have to go offline for a while. ttyl!

<mark_weaver>sneek: gc-env is https://github.com/ivmai/bdwgc/blob/master/doc/README.environment

<sneek>So noted.

<nalaginrut>morning guilers~

<dsmith>sneek, botsnack

<sneek>:)

<dsmith>Good bot

<dsmith>Looks like my router went "away" today.

<zzach1>Is it still possible to (trace function) and (untrace function) in guile-2? It says: Unbound variable: trace

<sneek>Welcome back zzach1, you have 1 message.

<sneek>zzach1, mark_weaver says: yes, the relevant procedures are 'dereference-pointer', 'null-pointer?', 'pointer->string', 'pointer-address', 'make-pointer', and (sizeof '*) to find the size of pointers.

<ijp>zzach1: I presume it is still available somehow, because something needs to be powering the ,trace repl command

<ijp>there is a call-with-trace function

<ijp>that is in (system vm trace)

<ijp>but usually you'd just use the repl command

<zzach1>ijp: Don't understand how to use it. I have a factorial function, (call-with-trace factorial) seems to trace the REPL itself.

<ijp>it takes a thunk, and traces that

<ijp>you trace a form, not a function

<ijp>zzach1: I have no idea why it does that, I'd have assumed it would error because factorial takes multiple arguments

<ijp>that's quite nuts

<ijp>zzach1: ,trace (factorial 5)

<mark_weaver>there's also ,tracepoint (or ,tp for short), which takes an arbitrary procedure.

<ijp>I had forgotten about that

<zzach1>ijp: ,tp seems to work like trace in guile-1

<zzach1>Is trace-calls-to-procedure usable somehow?

<ijp>that's a very odd question

<mark_weaver>the procedure backing ,tp is (add-trace-at-procedure-call! <proc>)

<zzach1>Does untrace also exist?

<mark_weaver>",traps" lists the current traps and tracepoints.

<mark_weaver>",delete <idx>" to delete one of them.

<mark_weaver>",help debug" for more

<ijp>the trap number gets printed out when you create it

<zzach1>OK, seems to work!

<ijp>,tp almost sorts out my trace filtering complaint

<ijp>it shouldn't be difficult to make a (trace (foo bar baz) form) that only traces foo bar baz

<madsy>When I create new SCM objects for internal use in a C procedure (they're not returned as a result either), do I have to mark them?

<mark_weaver>What do you mean by "mark" them? Do you mean in the sense of garbage collection?

<madsy>yes

<madsy>For example, in my print function, I create a SCM string object with scm_from_utf8_string. Can the gc suddenly sweep it while my function is called?

<madsy>Ah, I found the relevant docs I think

<mark_weaver>with guile 2.0, you don't have to worry about it.

<madsy>So there's no need anymore for scm_remember_upto_here_1() ?

<mark_weaver>that's my understanding, yes.

<madsy>thanks

<mark_weaver>np!

<madsy>mark_weaver: Hm.. the environmental variables mentioned on the github page you linked to doesn't seem to have an effect. Maybe I'm missing some compile-time flag?

<madsy>It does create the log file though. It's just that nothing is logged there

<madsy>Hm, maybe the gc doesn't run while read blocks

<mark_weaver>the gc runs when you try to do some allocation

<mark_weaver>you can run (gc) from the repl to force it.

<mark_weaver>well, of course you can call it from anywhere

<civodul>Hello Guilers!

<TaylanUB>Hidy ho!

*TaylanUB is reading boot-9.scm and friends, but hasn't reached enlightenment yet. :\\ What kind of magic is (define foo (make-syntax-transformer ...)) ?

<civodul>it has an entry in the manual, though it's quite concise :-)

<dsmith-work>Hey hey

<TaylanUB>Can't believe I'm so late in realizing that user-defined syntax simply consist of variables in a module being bound to objects of type #<syntax-transformer> !

<stis>afternoon guilers!

<dsmith-work>Heya stis

<davexunit>hello everyone

*sneek waves

<stis>tja!

<wingo>howdy

*wingo rewrites coverage.scm to work better with dwarf

<davexunit>I want to move guile-2d off of github. do I use gitorious or setup my own server? hmm.

<stis>hmm, how do I setup the environment for the compile command?

<stis> as of compiling it in a certain module

<stis>(resolve-module ...) did not work, guile-user stuff is missing

<wingo>(compile foo #:env (resolve-module ...))

<stis>yeah, but I needed to import guile-user to that module, that is easy to miss

<stis>nah, more like a missspelling

<stis>yey! now it works!

*stis is getting dynamic compilation into prolog

<stis>this is magic! guile rocks!

<shanecelis>davexunit: hey dave, want to talk coroutine's?

<davexunit>hey shanecelis

<davexunit>I could talk a bit. I'm at work so I might go afk without warning.

<shanecelis>davexunit: cool. understood. yeah, so you saw my cid thing.

<wingo>stis: :)

<davexunit>shanecelis: unrelated note: have you ever exported an org file as pdf on os x/

<shanecelis>davexunit: I have.

<madsy>Hm.. the GC environment flags have no effect here, but the (empty) log file is created. Does my guile build lack some compile flags?

<davexunit>shanecelis: I just can't get emacs to find pdflatex.

<madsy>I also explicitly tried to call the garbage collector with (gc)

<davexunit>shanecelis: did you have to do anything special?

<davexunit>sorry to bug you, but it's currently driving me up the wall.

<shanecelis>no worries. It's funny, now when I try to do it, it doesn't work.

<davexunit>I have messed about with everything that I can think of.

<shanecelis>davexunit: did you upgrade to Mavericks?

<davexunit>no

<davexunit>this is just my work machine

<davexunit>I don't really ever upate it

<shanecelis>davexunit: have you tried looking at the org-export customize group?

<shanecelis>davexunit: what does your *Org PDF LaTeX Output* buffer say?

<davexunit>/bin/bash: pdflatex: command not found

<davexunit>I guess I'll just have to make a google doc. so much for trying to do things the nice way.

<shanecelis>davexunit: I have the same error, but that's because I need to redo my macports. (I don't have pdflatex installed; fixing that.)

<davexunit>I installed mactex

<madsy>This should be enough to get libgc to output statistics, right? https://gist.github.com/Madsy/7358321

<madsy>What am I missing?

<mark_weaver>madsy: have you tried defining those things to be "1" instead of the empty string?

<madsy>Doh, nope. Good idea.

<madsy>mark_weaver: That did the trick. Apoligies for my retardedness

<mark_weaver>np :)

<madsy>Wanted to check the gc output to make sure that scm_gc_free isn't required

<madsy>As you said, when using scm_gc_malloc, you don't need a finalizer

<mark_weaver>yes, and finalizers are best avoided.

<mark_weaver>(sometimes they cannot be avoided, but it's best to avoid them when possible)

<madsy>Still not sure whether to use scm_malloc, scm_gc_malloc or scm_gc_malloc_pointerless in my operator new, though

<madsy>scm_gc_malloc would work, but the gc would hunt for pointers into pointerless arrays/structs

<madsy>That could really hurt performance when I have slightly big data arrays

<davexunit>shanecelis: could you go into the cid thing a bit? I'm less distracted now.

<davexunit>had to throw together a presentation for work.

<shanecelis>davexunit: sure. What I want is a way to do some job control: suspend, continue with the cooperative multitasking. I don't know that sticking 'cid in there is the right level with which to do that.

<shanecelis>davexunit: So I wanted someway to tag the series of thunks that start and resume coroutines in agenda.

<shanecelis>davexunit: but maybe that could actually be pulled out of coroutine and handled somewhere else.

<shanecelis>using procedure-properties feels kind of dirty.

<davexunit>yeah I think that could probably be done elsewhere.

<davexunit>I like the idea though. so you can halt coroutines that take too long.

<davexunit>do you have a solution for actually doing the halting? we'd need a new thread or something.

<shanecelis>davexunit: the 'resume' thunk that's returned each time you yield, it's the same thunk, right?

<shanecelis>davexunit: I've been trying to steer clear of requiring threads, so one thing I played with was setting an alarm that would basically abort a coroutine that didn't "cooperate".

<mark_weaver>madsy: can you arrange for 'new' to be different depending on what data type is being created?

<mark_weaver>*allocated

<mark_weaver>you could use 'scm_gc_malloc_pointerless' only for very large buffers (that contain no pointers of course)

<madsy>mark_weaver: Yes, you can define the new operator for each struct/class

<madsy>But that's something I try to avoid

<madsy>libgc sure is more pervasive than I thought it would be :)

<davexunit>shanecelis: it's a different thunk

<davexunit>how would you set that alarm?

<davexunit>there needs to be something polling in the background, right?

<mark_weaver>madsy: it's not limited to libgc. GC works best when the entire heap is GC. The interfaces between GC and non-GC worlds is messy.

<madsy>mark_weaver: yeah

<shanecelis>davexunit: It uses the unix alarm signal.

<davexunit>hmm, didn't know about that. I feel like I should...

<shanecelis>davexunit: It's a little dangerous and not portable.

<davexunit>ah. maybe it's best that I just trust that the coroutine is going to behave.

<madsy>A curious question: How does libgc manage to see the difference between pointers and other data like floats and integers?

<shanecelis>davexunit: Yeah, I'd say for guile-2d, if the coroutine is bad, it's a bug with the coroutine. For Emacsy I'm leaving that "good" coroutine enforcement as configurable with the default being off.

<mark_weaver>madsy: it can't tell the difference reliably. basically, it a word, as interpreted as a pointer, would point to the beginning of something allocated using scm_gc_malloc, then it keeps that block alive.

<davexunit>shanecelis: do you think that the coroutine and agenda modules should be extracted into a new library?

<mark_weaver>that's why it's called "conservative" garbage collection, as opposed to "precise" garbage collection.

<davexunit>or do you think that you'll need to customize it a lot more?

<mark_weaver>s/it a word/if a word/

<shanecelis>davexunit: I don't know yet. I think yours are beautiful as is, and I'd like to interrupt that as little as possible, but I expect mine will diverge. However, if I can build on top of them rather than changing them directly, I think it'd be great to expose them as a general cooperative multitasking system.

<davexunit>shanecelis: I suppose we will wait and see then.

<mark_weaver>two consequences of this are: (1) garbage can sometimes be kept alive by the existence of an integer that looks like a pionter, and (2) blocks can never be moved, because that would fail catastrophically if an integer was interpreted as a pointer.

<mark_weaver>it's highly unlikely that a float or double would look like a pointer.

<madsy>true

<shanecelis>davexunit: I'd say, let's keep refining them for our own purposes, then see if we can't unify them.

<mark_weaver>note, however, that SCM values will never be interpreted as pointers unless they are a pointer.

<mark_weaver>because all SCM non-pointers have one of the low 3 bits set.

<davexunit>shanecelis: sounds good. I just need to port that codefine* fix over. :)

<davexunit>thanks to you and mark_weaver for finding/fixing that bug.

<mark_weaver>and all pointers to valid GC blocks are aligned on at least an 8 byte boundary.

<dsmith-work>wingo: So what's the count down to now?

<davexunit>going afk for a bit. time to talk about javascript. :|

<wingo>dsmith-work: dunno, 15 or so

<dsmith-work>Coo.

<dsmith-work>cool

<mark_weaver>I have to do afk for a while...

<shanecelis>davexunit: yeah, should have just made you a pull request. Good luck! :)

<madsy>mark_weaver: I think I found a good solution for C++ allocation now. Use scm_gc_malloc for global new, and use std::vector for arrays with custom allocators. One allocator for scm_gc_malloc_pointerless and one for scm_gc_malloc

<madsy>The win should come from using scm_gc_malloc_pointerless on big dumb arrays

<davexunit>shanecelis: np about the pull request. I'm going to get guile-2d off of github anyway.

<madsy>davexunit: Why move it?

<davexunit>madsy: I want to host the source code using free software.

<unknown_lamer>bah, I hate OpenGL

<unknown_lamer>I like how the changes between GLSL 1.2 (OpenGL 2.1) and 3.x (especially 3.3) aren't /too/ major, but ...

<unknown_lamer>they removed support for GLSL 1.2 in OpenGL 3.3

<unknown_lamer>and since mesa only supports the core profile for OpenGL 3.x ... I can't write shaders compatible with my laptop (and guile-figl) and also my workstation

<unknown_lamer>and making guile-figl support opengl 3.3 means abandoning hardware that's only about five years old

<unknown_lamer>four even

<wingo>civodul: heya

<wingo>i have a little project for you if you are willing :)

<civodul>wingo: i'm swamped, but tell me anyway :-)

<wingo>so i rewrote the coverage module

<wingo>it doesn't seem there are any tests on the lcov part

<wingo>and i had to disable one small piece of that

<wingo>i left some comments about how to fix it

<wingo>as yet unpushed tho

<wingo>so it would be write a test suite for lcov things

<wingo>and ideally land the fix as well ;)

<wingo>but since there are no tests currently it's not breaking the build and so it's not urgent

<wingo>just when you find yourself with a spare hour and want to see how the new debugging interfaces work :)

<civodul>heh, i see :-)

<civodul>the lcov output you mean?

<civodul>the coverage-date->lcov thing?

<wingo>yes

<wingo>i had to disable dump-function

<wingo>will push shortly

<wingo>everything else works fine, and relatively zippy too

<civodul>ok, will have a look

<civodul>zippy as fast?

<civodul>i was about to say that we need to do something with VM hooks

<civodul>it's just too slow in 2.0

<wingo>zippy as in fast, yes

<civodul>woow :-)

<wingo>well i haven't tried running the whole test suite under it...

<wingo>but the per-instruction trap does less, and the whole system is faster

<civodul>how does it do less?

<civodul>is it still a 'hook' object?

*civodul fires git pull && make

<wingo>it's still a next-instruction hook

<wingo>but it stores into a single hash table off of ip

<wingo>it treats the ip as sufficient information

<wingo>also ip is absolute

<wingo>civodul: if you are building, build wip-rtl-halloween

<wingo>and i still need to push this one patch

<wingo>civodul: ok, pushed my patch

<wingo>wip-rtl-halloween still

<civodul>ok

<wingo>civodul: any reason to make procedure-execution-count return #f instead of 0?

*wingo thinking not

<wingo>the coverage test has been good for catching a couple of stray dwarf things

<kurohin>is (oop goops) something that only guile uses or is it included in other scheme variants?

<mark_weaver>goops is guile specific, but it's based on concepts that come from other CLOS-based object systems.

<mark_weaver>CLOS is part of Common Lisp, and Stklos is a scheme that has similar concepts.

<unknown_lamer>hrm, I wonder how hard portable goops would be (ala portable common loops from way back when in CL land)

<unknown_lamer>now that r6rs has record types and whatnot

<mark_weaver>doing it portably probably isn't too hard, but a completely portable implementation would probably be unacceptably slow.

<civodul>sneek: later tell wingo no good reason why procedure-execution-count returns #f AFAICS

<sneek>Got it.

<kurohin>good to know that i am locking my self into a specific implementation of scheme instead of discovering it later

<unknown_lamer>mark_weaver: PCL was never tooo slow

<unknown_lamer>if only I hadn't been too lazy years ago to reimplement goops in pure scheme and flesh out the mop

<unknown_lamer>now I've been polluted by SML and OO is the Wrong Way (tm)

<mark_weaver>it wouldn't be too hard to convert to a different CLOS-like Scheme system later, if needed.

<kurohin>I am having a problem with (oop goops), is there any way I could access other slots in a init-form for a a slot?

<mark_weaver>the basic functionality (defining methods specialized on types) is pretty much the same across the board.

<mark_weaver>it's mainly when you get into using the metaobject protocol to do fancier things that the portability will become more difficult.

<davexunit>are there any guile projects that use GOOPS heavily?

<davexunit>I try to avoid GOOPS myself.

<mark_weaver>yes. guile-gnome uses GOOPS heavily, as does dmd.

<davexunit>good to know.

<mark_weaver>surely others as well (I know that tupi uses GOOPS heavily in his projects), but I don't know what they are off hand.

<davexunit>I find it hard to distinguish when it's appropriate to use GOOPS and when I'm just not thinking about my problem in the right way.

<davexunit>since I've spent so much time with object oriented languages and relatively little time writing in a more functional style.

<unknown_lamer>kurohin: no, but there is another way

<kurohin>davexunit: I proberbly has the same problem'

<kurohin>damaged by C# and java from work

<kurohin>unknown_lamer: could you point me in the right direction? url maybe?

<unknown_lamer>you want to override `initialize'

<unknown_lamer> https://www.gnu.org/software/guile/manual/html_node/Instance-Creation-Protocol.html#Instance-Creation-Protocol

<unknown_lamer> https://www.gnu.org/software/guile/manual/html_node/Slot-Options.html#Slot-Options you want to try and not do that if you can though

<unknown_lamer>hrm, I really wish goops had method combinations

<unknown_lamer>it's pretty common to have a shared-initialize :after method in CLOS

<kurohin>maybe easier to make the user call a init method then.

<mark_weaver>kurohin: one technique I like to use is this: I make a custom constructor that's not a GOOPS method at all, just a normal procedure. that custom procedure calls 'make' with the slots initialized appropriately.

<unknown_lamer>mark_weaver: that is against the clos spirit :(

<unknown_lamer>overriding initialize for your class is the Right Way (tm), at least coming from CLOS

<davexunit>in the little time that I spent with GOOPS, I did what mark_weaver did.

<kurohin>that is somewhat what I do now, those that can uses keywords and other slots will be initilized in a init method

<davexunit>perhaps I should re-evaluate using GOOPS for guile-2d...

<unknown_lamer>something like

<unknown_lamer>(define-method (initialize (i <myclass>) . initargs)

<unknown_lamer> (let ((self ((next-method)))) ; default init

<unknown_lamer> (set! (some-field self) (* (some-other-field self) 5))

<unknown_lamer> ;; etc

<unknown_lamer> ))

<unknown_lamer>at least CLOS will just ignore any initargs it doesn't understand, I think GOOPS does too, so you can use fake initargs

<kurohin>the documentation made it look somewhat harder than your example, will try it out

<mark_weaver>unknown_lamer: I don't put much stock in claims that a certain way is "against the * spirit" or that another way is "the Right Way (tm)" unless a justification for that position can be articulated.

<unknown_lamer>mark_weaver: you should not be able to make a partially constructed instance with `make'

<unknown_lamer>make always returns a completely initialized instance

<mark_weaver>well, I confess that I almost never use object oriented programming techniques, so perhaps I should defer to others who do more of it.

<unknown_lamer>I know way more about CLOS/GOOPS than anyone should

<unknown_lamer>once upon a time I hacked on mysterious MOP things for cash money

<unknown_lamer>what a wonderfully useless job skill ;)

<unknown_lamer>bah, now I want to sidetrack and implement :default-initargs and at least the default method combination for goops

<unknown_lamer>there's some (relatively) recent publications on generating the discriminating function for a generic in a less awful way than CLOS does too, hrm

IRC channel logs

2013-11-07.log