<DeeEff>Hey #guile, quick question, is there a process I can use to measure the execution (run-time) of another process? <DeeEff>built into guile or in the srfi's, that is <DeeEff>Ah, nevermind my question. The way to do it is to use ',time' at the REPL ***sneek_ is now known as sneek
<stis>Hmm manage to compile a really large prolog program, compiler is almost there! <dsmith>stis, I know every starts rolling their eyes when then hear this about scheme/lisp, but I'm pretty ignorant of prolog. So. What is it really used for? What kind of applications? Is it used much? *dsmith hopes he doesn't sound like gavino... <stis>dsmith: think about treaa searches, it's just a nice framework to do search trees <stis>Also logical variables are interesting in them staying on the stack, and backtracks similar to fluids. <stis>Also In a sense keeping the variables on the stack may mean that the drawbacks of heap memory can be nulled in some applications <stis>I'm not good at the application level though, I have not made a chess solver and not any significant AI engine. <stis>WHat I've used this is for type solving, proving first order logic and generate candidates for a moon rocket controller <stis>dsmith: In a sense I'm a piano builder, not a piano maistro ;-) <stis>But yes, prolog is a niche language! But still a pretty cool one! <stis>BTW I'm trying to get #prolog folks interested by saying that in ayear or two they may program emacs with prolog :-) <madsy>When I exit via ",q" in scm_shell(), it kills my whole application, even though it runs in its own scm_thread. Why does that happen? <kurohin>What would be the best way to represent a lot of 3-state things in guile? <TaylanUB>(If they don't need to have identity, that would work.) <kurohin>and lots of them, think big matrix of them? <TaylanUB>It depends on what you want to do with these. Do they need to be objects, having identity ? <TaylanUB>So you're just interested in the count of them ? Then three numbers (telling how many there is of each state) could really do the job. <TaylanUB>(Am I being confusing ? I think it's difficult to give a good answer because the question is so general/open.) <kurohin>I missunderstand you, what I need is a good (low space(more important), good performance) way of representing a lot of flags that could be in 3 states on,off,unknown. and I need to able to ask is bit X set to on,off or unkown. <kurohin>what a need on a higher level is a matrix for storing (has in edges),(has out edges),(no edges) of a graph <TaylanUB>I think you can use the "array" API for a matrix. <kurohin>found bitvector now, hopeing it really maps to bits, and not like java maps to bytes(depending on VM) <kurohin>I could use two bits for every state <madsy>Do I still need to malloc if my integer type already fits inside a SCM smob? <madsy>That is, I can store an unsigned int directly into the pointer of SCM <madsy>mark_weaver: Do you know if it's okay to store integers directly in the SCM pointer, as opposed to allocating memory for a single int? <madsy>That won't confuse the garbage collector, right? <mark_weaver>small integers are already immediates, i.e. they are stored in the SCM value directly. <mark_weaver>under the current tagging method, the low bit is always 0, and then the next bit tells whether it's a fixnum or not. <mark_weaver>and indeed, they _would_ confuse the GC if not for the fact that the second-to-the-lowest bit is 1 for fixnums. <madsy>So I can do: smob = scm_new_smob (mgl_renderbuffer_tag, (scm_t_bits)(void*)an_integer); <madsy>Yeah, I'm assuming the tag is already made with scm_make_smob_type() with sizeof(unsigned int) <madsy>But what do you mean with tagging? Calling scm_make_smob_type() or something else? <madsy>But scm_from_uint32() would be an int type in guile. The fact that I'm using an integer is internal to my custom type. <mark_weaver>oh well, I should say that indeed, the second argument to 'scm_new_smob' is not SCM but rather (void *) <madsy>Yeah so: mgl_framebuffer_tag = scm_make_smob_type ("framebuffer-type", sizeof(unsigned int)); unsigned int val = ...; smob = scm_new_smob (mgl_framebuffer_tag, (scm_t_bits)(void*)val); <mark_weaver>why are you casting it to (scm_t_bits) when a (void*) is expected? <mark_weaver>it's probably better to declare 'val' as 'uintptr_t'. <madsy>Another thing. Should uninitialized SCM values (references to other smobs) be SCM_BOOL_F or scm_nil ? <madsy>I assume it matters when the mark function is run