IRC channel logs

<dsmith>Ankhers, If you ever figure it out, I'd be interested to see what you are doing

<Ankhers>I will try and remember that. It currently just complains that the session buffer is in use.

<mark_weaver>Ankhers: I vaguely remember someone here getting guile to work with org mode code blocks. maybe ArneBab ?

<Ankhers>I have it working with the code blocks. (It is actually the current default program)

<Ankhers>To be honest, that was the only reason I am using guile.

<Ankhers>Anyways, thanks for the help everyone. I will try and remember to post here if I figure anything out.

<mark_weaver>okay, happy hacking!

<stis>yes! prolog dynamic funcitons has beeen added, will be usable from both kanren and guile-log as well

<stis>ijp: it's a reallly nice functional datastructure behind that technology, see

<stis> https://gitorious.org/gule-log/guile-log/source/f5d5b76c467345d8fcb29945fe09d63c7aaab80e:logic/guile-log/prolog/dynlist.scm

<ijp>raw lists? really?

<stis>no based on trees

<ijp>stis: I mean, you didn't use records

<stis>no, at most three elements and only the first cons needs to mutate

<stis>most of the time

<stis>in the nodes

<ijp>is there a highlevel idea you can tell me, or am I going to have to read the implementation?

<stis>well assuming only consing to the head or tail a front of (l n r) is maintained

<stis>to the left, l a new (l n r) can be seen, but to the right we only have a (l . r) tree

<stis>n is the size of r

<stis>when l is the same size of r one bring the left side over to r

<stis>n is typically fixed when consing and changes only when l is brought in to r

<stis>oh, actually it's (l n . r), the last cons need not be updated all the time

<stis>that is the basic idea for adding stuff.

<ijp>what is the significance of using #f and #t

<stis>else we remove stuff in batches untill a threshold is reached and a new tree is remade

<stis>#f marks an emty first node and one could perhaps clean off some logic w.r.t. #f, I think that only the first node is (#f -1) smometimes

<ijp>all this should really be in comments

<stis>:-), yes!

<mark_weaver>you might want to use symbols instead of #f and #t

<stis>Yes that's a good comment.

<stis>Also I should move the last tools to a prolog specific file, it's unclean to keep it there.

<stis>hmm, my emacs uses tabs as spaceing, darn, thatäs why the code is not indented correctly.

<davexunit>I turn tabs off completely in emacs.

<stis>ok, i'm off to bed, cheers!

<nalaginrut>morning guilers~

<mark_weaver>hi nalaginrut!

<nalaginrut>mark_weaver: heya~

<nalaginrut>mark_weaver: any patch for the 'delayed syscall' bug?

<mark_weaver>it's not a trivial fix

<mark_weaver>I think I know how to do it, but it'll probably be a little while before I get to it.

<mark_weaver>is it causing a serious problem for you? maybe I can help you find a workaround.

<nalaginrut>yes, it bother me now, since I'm designed a scheduler based on SIGALRM

<nalaginrut>s/designed/design

<nalaginrut>designing

<mark_weaver>what is supposed to happen if you get SIGALRM while you're waiting for 'read' ?

<mark_weaver>what was your plan on what to do there?

<nalaginrut>no

<nalaginrut>I don't wait for 'read'

<nalaginrut>it's halt when I'm doing my experiment

<nalaginrut>actually, it's delayed

<nalaginrut>I do my experiment in REPL, and it doesn't work as expected

<nalaginrut>even I do it in my server, it doesn't work as expected

<nalaginrut>before 'syscall interrupt' bug fixed, it works

<mark_weaver>do you intend this to be a preemptive scheduler, or can it be cooperative?

<nalaginrut>the fix is fe51c7b

<nalaginrut>can be cooperative for current use, I just do dynamic info multicasting in my MUD game

<mark_weaver>fe51c7b is an important fix, which fixes other problems. we cannot revert it.

<nalaginrut>no, I don't want it revert

<nalaginrut>it fixed one of my bugs

<mark_weaver>if it can be cooperative, then I'd suggest that you avoid using signals. they are a mess anyway.

<nalaginrut>but another remain

<mark_weaver>(even outside of guile, signals are a mess)

<nalaginrut>but cooperative in MUD server is suck ;-P

<nalaginrut>users have to do some thing to trigger the info update

<mark_weaver>better to keep track of the time of the next scheduled switch, and then use that to set timeouts for various things you're waiting for.

<mark_weaver>for example, a timeout to 'select'

<nalaginrut>the problem is 'timer' can't work

<mark_weaver>'timer' ? I don't know what you mean

<nalaginrut>it has to be waited triggered

<nalaginrut>OK timeout

<nalaginrut>you mean timeout of 'select'?

<mark_weaver>right

<mark_weaver>and various other things too. e.g. lock primitives can take timeouts as well, and many other things.

<nalaginrut>well, do think it's a proper design? If I done this work, I would try to write the scheduler of my actor-model based on it

<mark_weaver>why don't you just use pthreads? why write your own scheduler?

<nalaginrut>I wrote my server with pthreads, now I want to try green-thread

<mark_weaver>well, if you want to write green threads on top of current Guile, you'll have to reimplement every primitive that can block.

<mark_weaver>every blocking primitive that you want to use in your program, anyway.

<mark_weaver>and at that point, having to manage the timeouts yourself is not a hardship.

<nalaginrut>I'll do it based on epoll only, so I'll set all ports as non-blocked

<nalaginrut>hmm...seems reasonable

<mark_weaver>but really, green threads is something that's best implemented within guile core, not on top of it.

<nalaginrut>yes, best in core

<mark_weaver>and it's a big job.

<mark_weaver>Having said that, I agree that green threads would be _great_ to have in core Guile.

<nalaginrut>because I put 'lightweight and fastest' on the aim of Artanis, so I have to do it

<nalaginrut>I know it's best in core, but I don't think this work could be done before 2015

<nalaginrut>I have to do something before it

<nalaginrut>our current aim is AOT, right?

<mark_weaver>to be honest, if the aim of Artanis is 'lightweight and fastest', then it's probably a mistake to base it on Scheme.

<nalaginrut>well, lightweight and fastest of Scheme

<nalaginrut>not for all

<nalaginrut>out of topic, is there any way to avoid parsing a whole word in SRE? now it's (~ #\\% #\\>), but I need something like (~ "%>")

<mark_weaver>nalaginrut: I don't know what you mean by "avoid parsing a whole word"

<mark_weaver>and I don't know what you mean by

<mark_weaver>'I need something like (~ "%>")',

<mark_weaver>because I don't know what you'd expect that to do.. (it's not legal SRE afaik)

<nalaginrut>the current implementation is (: ,startd-sign (=> disp-code (+ (~ #\\% #\\>))) ,end-sign)

<mark_weaver>okay, and what are you trying to change about it?

<nalaginrut>the problem is, if the code with the template contains % or > which are common in Scheme, it's failed to template parsing

<nalaginrut>maybe parse "%>" as a whole string can avoid this bug

<mark_weaver>there's no trivial way to say "anything not containing a given substring" with a RE.

<nalaginrut>alright, but any ideas about that?

<nalaginrut>I saw there's look-ahead in SRE, but I don't know how to use it

<mark_weaver>well, maybe you want something like (+ (or (~ #\\%) (: "%" (~ #\\>))))

<mark_weaver>but I'm not sure if that's quite right.

<mark_weaver>it won't handle '%' at the end of the match.

<mark_weaver>it's probably easier to search for '%>' and then handle the substrings between the matches separately.

<nalaginrut>there're a simple tests for my purpose, "<% (> 2 1) %>" ==> "(> 2 1)", and "<% "asdf%>" %> ==> "asdf%>"

<nalaginrut>for the first test, the current SRE will failed to hit it as a template string

<nalaginrut>for second, maybe there's some difficult

<nalaginrut>difficult for regexp

<mark_weaver>I don't really want to work on this, partly because I think SXML is far superior.

<nalaginrut>ok, never mind ;-)

<nalaginrut>maybe I should rewrite the template engine with LALR, I think regexp is so weak for that...

*zacts is building guile-2.0.9

<zacts>I really like the stuff the guile project is doing

*nalaginrut making a wip-lalr-tpl

<zacts>where does guile install itself by default

<zacts>I tried installing 2.0.9, but it's still showing I have 2.0.7 installed

<nalaginrut>zacts: hmm, IIRC the prefix of debian is /usr/local ?

<zacts>I'm using a debian based system..

<nalaginrut>the better way is specify prefix as /usr then overload the old version

<zacts>but it doesn't seem to be installing guile-2.0.9 to /usr/local/bin

<nalaginrut>hmm

<nalaginrut>did you check with 'which'?

<zacts>yep

<zacts>/usr/local/bin/guile

<zacts>but it is still 2.0.7 not 2.0.9

<zacts>let me try specifying a prefix with ./configure

<nalaginrut>maybe you need to uninstall the previous one first ;-)

<zacts>ok, let me try that

<zacts>same problem

<nalaginrut>oops

<nalaginrut>you specify --prefix=/usr , right?

<zacts>nalaginrut: no, I didn't do anything. let me try --prefix=/usr/local

<nalaginrut>no, you should try --prefix=/usr

<zacts>ok

<nalaginrut>since it's /usr/local in default under debian serial

<zacts>nalaginrut: thanks that worked!

<nalaginrut>zacts: no problem ;-P

*nalaginrut just purchased the order of HHKB pro2...

<zacts>what is that?

<zacts>oh, that looks cool!

<zacts>a keyboard

<nalaginrut>;-)

<nalaginrut>a keyboard for Emacs hacker

<zacts>cool

<gzg>nalaginrut: I have a "lite 2", which has served me well thus far -- though, I think I might spring forward for one of those funky looking ergonomical keyboards at some point. :^P

<nalaginrut>yup, that's cool too

<dsmith>zacts, I think you just installed your built-from-source guile on top of your Debian packaged guile. The next time that package is upgraded or removed it will overwrite yours.

<civodul>Hello Guilers!

<davexunit>good morning

<wingo>greets :)

<wingo>ok, pushed a fix for the loop compilation bug

<wingo>now i can compile eval and it works for more things

<wingo>though i haven't put it through its paces yet

<wingo>tight loops seem to run around twice as fast than the current vm

<wingo>eval is a bit slower, but i think that's because it has to call out to the old vm to call primitives

<civodul>compiling eval, nice!

<dje42>When writing docs in texinfo for specific procedures, is it better to write (@code{proc-name} @code{arg}) or @code{(proc-name arg)} ?

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

<sneek>dje42, nalaginrut says: this is a more completed version https://gist.github.com/NalaGinrut/6914993

<wingo>dje42: usually the former

<wingo>i think

<wingo>and often arg should go in @var{}

<dje42>thx.

<civodul>wingo: you mean the latter, no?

<civodul>that is @code{(foo @var{arg})}

<wingo>civodul: yes, i'm sorry!

<wingo>yes indeed

<wingo>got confused

<dje42>if a module is expected to normally be imported with a common symbol prefix, is that prefix used in the docs?

<dje42>It doesn't seem so (from reading guile docs), but I can imagine gdb users getting confused.

<wingo>probably not

<ijp>well, the point of a module system is that your users can give them any name they choose

<ijp>so, it seems silly to do it that way

<dje42>I don't like characterizing things that way, but ok.

<dje42>That would then argue for not even suggesting a convention for the prefix to import the module by.

<civodul>dje42: yeah, don't prefix all the symbols with 'gdb-', say

<civodul>choose simple and short names

<civodul>users can then use #:select or #:renamer as they see fit

<dje42>that's what I'm already doing ....

<civodul>ah sorry for stating the obvious then :-)

<dje42>It's the use of #:renamer that I'm wondering about.

<civodul>ah, ok

<civodul>well, there's no common prefix to recommend, IMO

<ijp>document under the names your module exports

<dje42>"works for me"

<ijp>for instance, I often export under different names than I use internally

<ijp>(define foo ...) (export (foo . bar)) then document as bar

<ijp>if you expect them to always import with a prefix, you might as well export them with that prefix in the first place

<stis>hmm we should really expose gmp's scan0 and scan1 for guile.

<ijp>what do they do?

<stis>ijp: I maintain am ordered set with the help of bignums bit patterns

<stis>then for moderate sized bnums and or etc are super fast

<ijp>that isn't what I asked

<stis>but to find the sequence numbers of the 1 one need scan1 and that is not included in interface

<stis>I could use bitvectors, but there is no set operations for them

<ijp>so they return the least significant 1 or 0

<stis>from an offset

<ijp>r6rs has bitwise-first-bit-set

<ijp>efficiency aside, we could implement these in scheme

<stis>oh, thanks!

<ijp>(possibly a not), a shift, then a first-bit-set, then an addition

<ijp>I really don't have a stake in this one though, it's mark you probably need to convince :)

<stis>yeah, some optimized vm ops (for fixnums) to do this has some benefits.

<stis>I'll ask for his opinion

<zacts>I got my guile and guix installed

<zacts>davexunit: ^

<davexunit>zacts: yay! :)

<davexunit>gotta go

<mark_weaver>stis: as ijp pointed out, we have procedures for finding the first set bit. He gave the R6RS one, and also SRFI-60 has 'first-set-bit' a.k.a. 'log2-binary-factors'.

<mark_weaver>and as he suggested, to start from somewhere, do a right shift before 'first-set-bit'.

<mark_weaver>to search for the first '0', do a 'not' first.

<mark_weaver>you could also mask out the low bits before 'first-set-bit'.

<stis>yeah, but it would be cool to use C versions of that algorithm e.g. mpz_scanX

<stis>even better of logior logand scan etc could have their won vm ops

<mark_weaver>logior and logand already do have their own VM ops.

<stis>cool, well then scan is missing

<mark_weaver>'first-set-bit' a.k.a. 'log2-binary-factors' uses mpz_scan1

<mark_weaver>see scm_srfi60_log2_binary_factors in srfi-60.c

<stis>then I'm satisfied. getting a vm op for that is probably premature optimization

<mark_weaver>that's good! :)

<stis>I'm developing the dynamic-functions code to make use of bitsets

<mark_weaver>I _do_ intend to add a bunch of arithmetic-related VM ops to the RTL VM, mostly for the R6RS fixnum and flonum ops.

<mark_weaver>but the 8-bit opcode is somewhat constraining, so we won't be able to include everything that we might like.

<mark_weaver>and that's probably best anyway. it's important to keep the VM as small as we can, so that it fits nicely in the cache.

<mark_weaver>also, 8-bit opcodes can typically be extracted with a shorter instruction sequence, which would be painful to give up.

<stis>we can add al this for the native version

<mark_weaver>especially since the opcode dispatch is repeated at the end of every VM instruction code segment.

<stis>and keep using funciton calls in rtl. But perhaps using a speedier function call mechanism can help as we discussed earlier.

<bubble>Is there someone who can give me an account on a Linux box ? I would like to hack on guile, but I do not have the money to buy another box.

*bubble has a slow machine

<dje42>how slow? I don't think you need a 2Ghz box (for example). How about dual boot? OTOH, if you're running windows I'm guessing there's a cygwin or mingw port of Guile.

<bubble>I am on a BSD, 1GHz

<dje42>And I'm guessing compiling Guile on BSD doesn't work?

<bubble>more or less, but it's meant for Linux

<dje42>in what sense?

<ijp>civodul: do we have a hydra build for bsd?

<dje42>[I don't use anything but linux, I'm just curious.]

<civodul>yes, FreeBSD

<civodul>so if that doesn't work there, it's a bug

<ijp>thought so

<bubble>Well, I try to compile my dependencies, I am not too much into Linux ATM

<bubble>I am just looking for a Linux box to hack on

<bubble>I just need a ssh account, the rest I can compile for myself

<dje42>have you thought about dual boot? [having one's own box has its benefits]

<bubble>What OS should I use as a BSD dude ?

<bubble>distro I mean

*bubble does not want to be rude

<civodul>bubble: Guile is known to work correctly on FreeBSD

<bubble>I am on OpenBSD

<civodul>it's probably much less tested on OpenBSD, NetBSD, etc.

<civodul>ok

<civodul>you can give it a try and report back

<ijp>taylanub: you run openbsd, right?

<dje42>Asking for the distro to use is like asking for a favorite programming language. :-) But I use redhat at home.

<bubble>As I said, I thought I would e.g. mess up Makefiles on BSD

<bubble>ok, fedora

<taylanub>ijp: Yes.

<ijp>taylanub: so what are the problems building guile there?

<taylanub>bubble: Since 5.2 you need a Boehm GC that supports rthreads.

<taylanub>It's in the git upstream I heard; otherwise I can provide patches for the latest release.

<dje42>Can linux mount a bsd file system? [that way you could, e.g. have the same home dir regardless of o/s]

<taylanub> http://taylanub.github.io/gc72d-obsd53-patches.pax.xz Here.

<dsmith>djcb, Used to be yes. Not sure about all these new filesystems.

<dsmith>s/djcb/dje42/

<dsmith>I used to run fbsd a debian on the same box with both being able to mount each others filesystems. But that was with ext2 and ffs.

<dje42>way back when I had to use xenix for work-work (yeah, *way* back when :-)), so I wrote a xenix f/s for linux

<dsmith>Yeah xenix!

<dsmith>djcb, Did yours have .obj files instead of .o ?

<dsmith>Arrgg!

<dsmith>silly tab completion!

<dje42>heh :)

<dje42>Can't remember.

<dsmith>Not sure about obsd, but netbsd has much more rigorous implementation of posix threads.

<dsmith>Guile used to have some issues there, iirc. Pretty sure they have been fixed though.

<dsmith>dje42, Please do try it.

<dsmith>wait

<dsmith>that's bubble

<taylanub>I'm using 2.0.9 on obsd 5.3 just fine with the patches above.

IRC channel logs

2013-10-12.log