IRC channel logs

<dsmith-work>mark_weaver: There were a few places with "dsmith" hardcoded in the path, and also my sqlite module was (database sqlite) now just (sqlite)

<mark_weaver>yay! sneek is back!

<mark_weaver>sneek: botsnack

<sneek>:)

<fbs>sneek: sandwich

<dsmith-work>mark_weaver: It was really nice that I didn't need to mess with the database. He's using the same binary sqlite file on a different endian system.

<mark_weaver>indeed, that would have been a pain.

<dsmith-work>OR maybe not?

<dsmith-work>arm is le ?

<fbs>need to finish my irc bot

<dsmith-work>me too

<fbs>does yours do ssl?

<dsmith-work>nope

<fbs>hmm might work on that one day

<dsmith-work>I need to redo it in pure scheme. Get away from that funky C++ bobot

<dsmith-work>unknown_lamer: No offense..

<fbs>my think is somewhat pure scheme

<fbs>its a mess, but no c in it

<dsmith-work>The kill-the-bot cron job is NOT currently running.

<dsmith-work>Lets see how memory fat he gets.

<dsmith-work>mark_weaver: So. I'm liking this thing. The R Pi.

<dsmith-work>It's so Debian inside I'm right at home.

<dsmith-work>Makes me want more of em.

<fbs>rpi is quite nice, need to get me one for this sumer

<mark_weaver>yeah, it's a nice little device :)

<cky>fbs: In my Copious Free Time(tm) I intend to write a bot too, that uses guile-gnutls bindings (thanks civodul). :-)

<cky>fbs: Re "does yours do ssl?".

***sneek_ is now known as sneek

*nalaginrut is handling local-eval black-magic for template...

<wingo>moin

<wingo>nalaginrut: another use for local-eval, neat :)

<wingo>similar to the lilypond use, in the end...

<nalaginrut>wingo: I've heard that local-eval is evil, I wish this use won't be so evil ;-D

<nalaginrut>but it looks cool~

<wingo>meh, sometimes evil is appropriate ;)

<nalaginrut>and if guile-100's template implementation is better than mine, I'll use it ;-P

<nalaginrut>besides, working on blog-engine makes my Artanis better now~

<wingo>so many things to do

<wingo>i think i haven't taken many photos in recent years because i was waiting to rewrite my photo gallery in scheme

<wingo>that's terrible :P

<nalaginrut>wingo: yes, that's I stopped update my blog, I want to write a perfect blog for myself

<wingo>haha

<wingo>the perfect is the enemy of the good

<nalaginrut>s/that's/that's why

<nalaginrut>hmm...there would be some guy jump out to blame it~so I'm not afraid of~

<nalaginrut>I'll put the demo to my VPS today, but I have no time for CSS this week

<nalaginrut>anyway, the bare page looks good

<nalaginrut>maybe I saw too many garish page nowadays...

<janneke>good morning

*janneke hears lilypond and wakes up ;-)

<wingo>:)

<civodul>Hello Guilers.0.9!

<wingo>moin :)

<wingo>civodul: so what's next? :) you have any plans?

*wingo was going to finish RTL debugging support

<civodul>wingo: no concrete plans!

<civodul>i'd like to spend some more time on Guix in the coming weeks

<wingo>cool

<civodul>but i think that getting the RTL VM into shape would be great

<DerGuteMoritz>what's the RTL VM?

<wingo>i think i can do it within a month or so

<civodul>woow, great

<wingo>depends on how much time the garden takes ;)

<DerGuteMoritz>RTL is a terrible German TV station, I hope it's not related :-)

<civodul>the garden?

<civodul>a real garden? :-)

<wingo>DerGuteMoritz: it's a new virtual machine for guile -- register-based instead of stack-based

<DerGuteMoritz>first of all, it's GNU/garden!

<DerGuteMoritz>wingo: ah, nice

<wingo>and which uses ELF as the object format so we can put read-only shareable things into other sections

<wingo>much closer to proper native compialtion

<civodul>that's going to rock

<wingo>i think we'll actually use DWARF, even...

<DerGuteMoritz>sounds exciting

<DerGuteMoritz>will this be guile 2.2?

<civodul>DWARF may be a can of worm no?

<wingo>civodul: i already have a full parser

<civodul>full?

<wingo>in the "dltools" project

<wingo>full.

<civodul>ah right

*civodul wrote a stabs parser ten years ago

<wingo>and yes, i have some dirt i am trying to turn into peas and tomatoes

<civodul>and it's a pain

<civodul>nice

<wingo>late spring this year, lots of work to do...

*nalaginrut is waiting for registerVM...

<wingo>DerGuteMoritz: yes i think it will be the main 2.2 feature

<DerGuteMoritz>cool

<nalaginrut>civodul: what stabs parser? debug info?

<wingo>speeds up VM code by varying amounts, but about 40% overall i think

<wingo>then we can look at generating native code (woo)

<civodul>nalaginrut: yes, like DWARF, but not as expressive

<nalaginrut>when rtl branch released, AOT is kickoff~

<wingo>we could add aot incrementally -- it can be another section in the elf files, with proper linking to the constant sections, etc...

<nalaginrut>civodul: ha~I wrote similar thing when I was doing OS homework, to backtrack the kernel function...

<nalaginrut>wingo: anyway, I think it's possible to implement external AOT compiler, taking advantage of bytecode

<wingo>probably, yes

<wingo>but tough to get nice debugging with an external compiler

<nalaginrut>hmm..

<wingo>i think the compiler is actually a small portion of what we need -- the runtime is harder

<nalaginrut>my thought is dump ASM to the tmp files, then call 'as', and we may provide multi-platform native code, in principle...

<nalaginrut>but if we're going to write assembler...

<wingo>much better to write an assembler in scheme

<wingo>it's not that hard, there's lots of existing work out there to borrow

<nalaginrut>I think implement assembler is not so hard, but it's hard to provide many platform, no?

<nalaginrut>too many work IMO

<wingo>that's the thing, we don't have to

<wingo>because we'll always have the interpreter

<wingo>it's easy to do x86-32 x86-64 and arm, and that covers the majority of things

<nalaginrut>I said so because I'm an embedded system fan...

<nalaginrut>ok, since there's arm

<wingo>add mips, sh4, and ppc and that's pretty much all of them

<DerGuteMoritz>nalaginrut: how many RPM do you make?

<DerGuteMoritz>*badum-tsh*

<wingo>is this a fan joke

<wingo>oh it is

<wingo>ha ha :P

<DerGuteMoritz>:-D

<nalaginrut>DerGuteMoritz: no, I'm not familiar in "how to make RPM package", but I'll take some time to learn, as the plan, we should have a repo for all latest Guile things

<nalaginrut>though Guile is standard package of current distro, its update so slow

<DerGuteMoritz>wait, no, this pun is getting out of control

<wingo>you lost your bearings?

<nalaginrut>wingo: oh~yeah~that's the plan, let's do it~

<wingo>*rimshot*

<DerGuteMoritz>:-D :-D

<nalaginrut>add AVR, reference Marc Finley's picobit design, hey! I'm serious, who said joke huh?

<nalaginrut>when Guile-5.0 released, it's a system language~

<wingo>i wish we had a better type system...

<wingo>heresy

<nalaginrut>wingo: ah~so you agreed system-language

<wingo>nalaginrut: not sure exactly what "system language" means

<wingo>like, can you do GC in a systems programming language?

<wingo>rust seems to think not

<wingo>good day lloda

<lloda>helloo!

<lloda>what do you think about the vector/array changes I proposed

<wingo>haven't had a chance to look at them

<lloda>what jumped at me is that the implementation is already like this

<lloda>all the types that are used as SCM_I_ARRAY_V are base=0, lbnd=0, inc=1

<lloda>it's only the interface that is inconsistent

<lloda>and lets you use xxx-ref, etc with objects that are actually arrays

<wingo>hummmm, i will have to page all that in to review it

<wingo>you are usually right in these things but i would like to understand it all before commenting :)

<lloda>right, I'd like a second opinion, or a third.

<lloda>but there are many bugs and if we just patch them, it will only make everything more spaghettiish

<wingo>i agree that we need consistency above all, especially in the arrays code

<lloda>ok, i'll send a patch set, so the proposal can be tested. I'm already halfway done.

<wingo>super

<DerGuteMoritz>in case anyone of you guys is interested in a European Scheme hacking event in the near future: https://wiki.call-cc.org/event/chicken-spring-cologne-2013

<civodul>there's ELS also in June: http://www-sop.inria.fr/members/Manuel.Serrano/conferences/els13.html

<civodul>the more schemers, the merrier :-)

<fbs>cky: maybe we can team up and write a bot

<DerGuteMoritz>civodul: I was considering going there, too, hmmM!

<wleslie>you work @ inria?

<wleslie>that sounds neat

*civodul does

<civodul>DerGuteMoritz: would be cool :-)

<dsmith>sneek, botsnack

<sneek>:)

<civodul>anyone tried or knows about https://github.com/nizmic/nwm ?

<civodul>is it the one that started for the potluck?

<davexunit>this years potluck? there are commits dating 3 years back.

<civodul>ah, so it must be a different one

<civodul>:-)

<the-sun>civodul: I once tried a window manager written in common lisp. It turned out I didn't care much about the way my windows were managed :)

<the-sun>I thought I would want to customize it like in Emacs or something...

<the-sun>It might be useful for some special purpose PCs though.

<civodul>well, similar for me, i use Ratpoison

<civodul>dunno

<davexunit>I've been hearing about scwm lately. I need to try it.

<add^_>davexunit: Has there been something done on that for a couple of years?

<civodul>ask dsmith :-)

<add^_>:-P

<add^_>I remember using that for a while

<add^_>But I didn't know if there's been something done on it since then

<dsmith>davexunit, I've been slowly debitrotting it to work with modern guile.

<dsmith>It's useable at this point. The C code is almost all together (need to look into delimited continuations).

<dsmith>There is an ancient gtk interface that needs updating to new gnome-guile. But that's not required to use it.

<dsmith>I personally don't use it much. Maybe I should. Start dogfooding it.

<dsmith>It does NOT work with 1.8

<dsmith>Well, I haven't checked. I'd be *very* surprised if it does!

<davexunit>dsmith: cool. I will hopefully remember to try it out this weekend when I have a chance.

<davexunit>I haven't used any alternative window managers lately. I've been sticking with mutter.

<fbs>o0

<nalaginrut_> http://deuslux.org/index.scm

<nalaginrut_>hmm...need some CSS...

<DerGuteMoritz>are you using the PHP deployment model?

<DerGuteMoritz>i.e. is index.scm an actual script that's executed to produce the page? or does it only look like it?

<davexunit>nalaginrut_: artanis is an interesting project.

<nalaginrut_>DerGuteMoritz: no, it's all Scheme

<nalaginrut_>davexunit: ah~thanks ;-P

<DerGuteMoritz>nalaginrut_: I mean keeping your code in the web root

<nalaginrut_>DerGuteMoritz: and index.scm is not a real script file, it's route and dynamically generated articles as HTML

<DerGuteMoritz>ah so it's just a name, I see :-)

<DerGuteMoritz>that's reassuring

<davexunit>nalaginrut_: I do rails development so it's very cool seeing a sinatra-like framework written with scheme.

<nalaginrut_>DerGuteMoritz: I use *.scm to indicate it's Scheme, however, I have to use *.scm to redirect the request with Nginx

<DerGuteMoritz>aha, mhmh

<DerGuteMoritz>implementation details leaking through the URI :-P

<DerGuteMoritz>but it's just a deployment detail, so all is well :-)

<nalaginrut_>since 80 port is running other guys PHP

<nalaginrut_>but all *.scm will redirect to port 1234 which is running artanis

<nalaginrut_>davexunit: yes, that's my aim, the sinatra like framework

<nalaginrut_>anyway, sinatra is so easy to try, I like that

<nalaginrut_>DerGuteMoritz: there's some work to do with the session, hmm...artanis is long term plan in my pocket

<nalaginrut_>and Colt is the name of blog-engine based on Artanis, I wish it could be something like Habari

<nalaginrut_>DerGuteMoritz: is there anyway to hide 'sid'?

<DerGuteMoritz>nalaginrut_: cookies?

*nalaginrut_ get the achievement that build Guile-2.0.9 & Guile-dbi & Artanis & many prerequisites on centOS-6.4

<nalaginrut_>DerGuteMoritz: cookies is not so safe

<nalaginrut_>DerGuteMoritz: you see, now sid is passed with query-string

<dsmith-work>unknown_lamer: To get bobot++ to compile, I ended up s/(SCMFunc)/(void*)(SCMFunc)/ in source/Interp.C Not sure if that's the right thing.

<nalaginrut_>I don't know what's the better way for session

<unknown_lamer>hrm, is that in darcs master?

<dsmith-work>YEs

<unknown_lamer>weird, I could have sworn I fixed that type for guile 2.x

<unknown_lamer>O

<unknown_lamer>I'd like to pretend I never thought c++ was a good idea ;

***nalaginrut_ is now known as nalaginrut

*nalaginrut will run blog.scm with daemonize

<dsmith-work>The compiler error message was "invalid conversion from ‘scm_unused_struct* (*)()’ to ‘void*’"

<dsmith-work>You want a void*? I'll give you a void*! There. Hows that!

<cky>C++ is a great idea! Well, when used with a Scheme implementation that is written in C++, that is. ;-)

<DerGuteMoritz>nalaginrut: how is a query string safe as opposed to a cookie?

<DerGuteMoritz>I'd even argue the other way around, session IDs in query strings can accidentally leak

<DerGuteMoritz>e.g. when a user copies a URL with a session query string from the location bar and sends it to another party they will share the session

<nalaginrut>DerGuteMoritz: yes, that's the problem I'm anxious

<DerGuteMoritz>well this can't happen with cookies

<DerGuteMoritz>so why do you say they're not safe?

<nalaginrut>DerGuteMoritz: well, all around of me saying cookie is not safe

<nalaginrut>actually, the whole world

<DerGuteMoritz>then better ask them for rationale

<DerGuteMoritz>virtually all web applications do cookie based sessions

<ArneBab>can guile run scheme code passed via stdin?

<nalaginrut>then told me use session, and you told me use session

<nalaginrut>hmm..

<ArneBab>the simplest case would be `cat code.scm | guile`

<dsmith-work>ArneBab: You can, but you get all the banners and prompts. Simpler to just "guile code.scm"

<ArneBab>dsmith-work: I can’t do that: I get the code from another program. My current workaround is to write it to a temporary file, but I don’t like that…

*dsmith-work notes there are a *lot* of new faces in the crowd

<nalaginrut>dsmith-work: yes

<dsmith-work>Howdy folks, and welcome to #guile!

<nalaginrut>ArneBab: there's no such thing, maybe feature request ;-P

<ArneBab>:) thanks!

<ArneBab>nalaginrut: echo "(display 1)" | guile -- seems to work

<nalaginrut>ArneBab: yes it does, but seem contains some redundant info

<dsmith-work>Like I said, the banners and prompts.

<ArneBab>yes

<ArneBab>where would I make the feature request?

<cky>echo "(display 1)" | guile -s /dev/stdin

<cky>;-)

<DerGuteMoritz>ArneBab: are you n linux?

<ArneBab>that works? cool!

<ArneBab>yes

<DerGuteMoritz>right, then what cky said :-)

<cky>DerGuteMoritz: Surely most Unix-like platforms provide /dev/stdin too? :-)

<ArneBab>I need that to make wisp.py actually work as it should:

<ArneBab>echo "display 1

<ArneBab>> newline" | ./wisp.py - | guile -s /dev/stdin

<ArneBab>1

<ArneBab>thanks cky!

<DerGuteMoritz>cky: probably, I don't know for sure though!

<nalaginrut>ArneBab: echo "(display 213)" | guile -c '(primitive-eval (read))'

<DerGuteMoritz>also I was gonna suggest /proc/self/fd/0 which I think really is a Linuxism

<dsmith-work>nalaginrut: But only for one expression

<DerGuteMoritz>but /dev/stdin is much better, of course

<nalaginrut>echo "(display 213)" | guile -s /dev/stdin

<ArneBab>yes, primitive-eval seems to only take the first expression

<nalaginrut>alright~but maybe we could add a argument for that

<dsmith-work>Well, it's (read) that only reads one expression

<ArneBab>nalaginrut: I expected guile to take stdin when it gets the - argument

<ArneBab>echo "(display 123)" | guile -

<DerGuteMoritz>ArneBab: what if you wanted to read a file named - then though :-P :-)

<ArneBab>DerGuteMoritz: then you would use -s -

<nalaginrut>ArneBab: I thought it has

<ArneBab>guile: Unrecognized switch `-'

<dsmith-work>It shouldn't to hard to non display the banners and prompts in stdin is a pipe. Or not a tty.

<ArneBab>that would be nice

<DerGuteMoritz>ArneBab: ok! :-)

<dsmith-work>ArneBab: Submit a bug to the list.

<dsmith-work>sneek: bugs?

<sneek>Someone once said bugs is send mail to bug-guile@gnu.org. Check status at http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guile

<ArneBab>essenitally making `guile -` a crossplatform way to say `guile -s /dev/stdin`

<ArneBab>on it

<ArneBab>bug report sent

<bitdiddle>trying to autogen the stable-2.0 branch on debian, getting this - https://gist.github.com/bdionne/5364839 - is this obvious to anyone?

<cky> https://launchpad.net/ubuntu/+source/libgc <-- Ubuntu has 7.2d of libgc. I'll try backporting this to my Debian system and see how this goes. :-)

<cky>I should actually try tweaking the Debian guile-2.0 packages and see if I can make it build 2.0.9.

<ArneBab>result of the discussion here right now: https://bitbucket.org/ArneBab/wisp/src/e715e9013cadf03d6ce4d8d907302490a33a5a01/Readme.txt?at=default#cl-35

<ArneBab>which means this here allows using indentation sensitive multiline code with scheme directly from bash:

<ArneBab>while IFS= read in ; do echo "$in" ; done | ./wisp.py - | guile -s /dev/stdin

<ArneBab>(you need wisp for that: hg clone https://ArneBab@bitbucket.org/ArneBab/wisp)

<ArneBab>then enter something like this:

<ArneBab>define : show arg

<ArneBab> display arg

<ArneBab> newline

<ArneBab>show 1

<ArneBab>thanks again cky!

<ArneBab>that’s no real interactive commandline interface, but it’s much closer than I ever was :)

<ijp>afternoon

<ArneBab>got to go. cu!

<ijp>I have been having problems with running the tests on master, more specifically: threads.test is trying to murder my cpu

<ijp>naturally, it only decides to do this when I am not using strace :)

<ijp>taylanub: I strongly recommend against maintaining a "registry" in your bytestructures code

<ijp>instead, it would be preferable to bind them to variables, and use the module system, since that is what it is there for

<taylanub>ijp: Indeed, I've been thinking the same; there's no justification for my separate namespace.

<taylanub>At least in the procedural implementation. I'm not sure about the syntactic one; how do I make my macros define and reference phase 1+ variables ?..

<taylanub>I can think of multiple dirty ways but not a clean one. Anyway, I'll polish the procedural one first.

<taylanub>ijp: Another issue bothering me is, should we allow different non-compound descriptor-types, or only have a generic "simple" type whose instances hold 1) size, 2) scm->bytevector, 3) bytevector->scm ?

<taylanub>With the separate types, you could do (pseudo-code):

<taylanub>(define-bytestructure-descriptor-type int #:options (signed? size endianness) #:to-scm (lambda (int-descriptor-instance) (check options to decide what to do)) #:from-scm ...)

<taylanub>(define uint8-descriptor (bytestructure-descriptor '(int #f 1 big-endian)))

<taylanub>With the singular simple type that'd be:

<taylanub>(define uint8-descriptor (bytestructure-descriptor #:size 1 #:to-scm bytevector-uint8-ref #:from-scm ...))

<wingo>heya mark_weaver

<mark_weaver>hi wingo!

<mark_weaver>wingo: btw, I had a question about merging the ports stuff to master

<mark_weaver>wingo: at first, I started to keep 'encoding_mode' in the private port structure, but I see that it's referenced in quite a few places in the tree now.

<mark_weaver>I can't decide whether it should be public in 2.2. what do you think?

<wingo>good question

<wingo>my instinct is to hide as much as possible

<wingo>so that we can make changes more easily

<wingo>we can always add accessors

<mark_weaver>yeah, I tend to agree.. okay

<wingo>wdyt?

<mark_weaver>sounds good

<wingo>cool

<mark_weaver>wingo: in master, I want to add source location tracking for identifiers

<wingo>mark_weaver: that would be lovely :)

<wingo>want to send a plan to the list?

<mark_weaver>first I have to figure out what the plan is :)

<mark_weaver>but yes, I wil

<mark_weaver>*will

<mark_weaver>also, I wonder if it will be possible in master to eliminate some of silly limits we have, such as limits on the size of literal lists and vectors.

<mark_weaver>well, just something to keep in the back of your mind

<wingo>i think most of those limit-related issues are fixed with the rtl vm

<wingo>but i am definitely thinking about it, yes :)

<mark_weaver>I looked into raising those limits in stable-2.0, and found myself wanting a variant of the list opcode that let me specify the final cdr.

<mark_weaver>okay, good enough :)

<wingo>there is no list opcode in rtl, only cons

<wingo>it should perform better, however

<mark_weaver>okay. I wonder: with elf, can we avoid building the literals piece by piece, by rather let the dynamic linker link it all together?

<wingo>it already does that :)

<mark_weaver>ah, good!

<wingo>well, you have to link things at runtime

<wingo>but they are just relocations

<wingo>they happen to be processed by guile instead of by ld.so

<mark_weaver>right, that's what I meant by having the dynamic linker do it.

<wingo>but they don't cons

<mark_weaver>oh, okay, well, either way.