IRC channel logs


back to list of logs

<galex-713>Can Guile be used in a C# program?
<galex-713>to extend it
<galex-713>Also, do you think one day Guile could compile to java or C# virtual machine?
<amz3>héllo :)
<amz3>I'm trying to redirect output log done by my program using (format #t "foo")
<amz3>I exec my program using `guile -L . hypermove-worker.scm > output.log'
<amz3>the problem is that when I try to `tail -f output.log' in another terminal I get nothing
<amz3>sorry I get something, but the output is dealayed
<amz3>good enough for now
<amz3>this is approaching a 0.1 release
<amz3>it still has loose ends, but... but... but... it's scheme at it finest :P
<mayuresh>hello! :)
<mayuresh>hi :)
<mayuresh>a quick question. can i use guile-2.0 while learning from 'sicp'?
<ecraven>ah, good times... Godly Plate of the Whale
<nalaginrut>it's real morning to me (but too early)
<mark_weaver>amz3: writes to a file are delayed because they are buffered by default. either use 'force-output' to explicitly flush the write buffer, or use 'setvbuf' to set your desired buffering mode explicitly.
<amz3>thx mark
<amz3>ACTION sent a mail to guile-user
<fhmgufs>Is there an formatted input method? I mean something like scanf in C.
<mark_weaver>fhmgufs: not anything like scanf, but see 'string-tokenize', 'string->number', etc.
<mark_weaver>'match' may be useful as well
<mark_weaver>in combination with the other procedures
<fhmgufs>What I want to do is reading a string like "Hello, I am fhmgufs" and getting "fhmgufs" as a value.
<fhmgufs>match seems to be useful here.
<wingo>see also string-match, which is a different thing
<fhmgufs>wingo: Actually that was what I found useful :). I thought that was meant.
<civodul>wingo: are you looking at test-decoding-error in ports.test?
<mark_weaver>... continuing the discussion from #guix ...
<mark_weaver>wingo: from reading that, I agree that the port position should not be advanced when the error-handling-mode is raise
<wingo>civodul: i haven't seen the error, i was looking at refactoring the code and noticed a thing that didn't seem right to me
<civodul>this thing in ports.test checks the pointer position in the presence of errors
<civodul>that's why i was mentioning it
<mark_weaver>wingo: for the 'ignore' and 'replace' error-handling-modes, iirc, unicode specifies how many bytes should be read
<wingo>civodul: yep
<mark_weaver>for utf-8
<mark_weaver>let me see if I can find it
<wingo>mark_weaver: yeah. and for iconv we have our byte-at-a-time shenanigans
<wingo>but i think we do the correct thing already re: choosing how many bytes to advance
<wingo>there is a comment in the source indicating the relevant unicode section
<wingo>i read that the other day
<mark_weaver>wingo: okay, I wasn't sure if you were going to rewrite some of that
<mark_weaver>ah, good
<wingo>my question was more about whether to advance the pointer at all in the error case
<wingo>i have a status mail to send soon
<wingo>i managed to get a loop of 1e7 peek-char's on a utf-8 or latin1 stream to 900ms, with peek-char in scheme; vs about 380ms with peek-char in c
<wingo>a somewhat frustrating difference, some possibilities to whittle away at it
<wingo>faster than 2.0 though
<mark_weaver>wingo: the text is not quite as clear as one might hope for, but given that they explictly say "bytes are ignored" for the other two cases, I think it's reasonably safe to assume that no bytes should be ignored in the 'error' case.
<wingo>mark_weaver: yeah i agree. thanks for taking a look!
<mark_weaver>thanks for asking!
<wingo>well, hacks for tomorrow. sleepytime!
<mark_weaver>sleep well!
<paroneayea>heya hiyas
<janneke>paroneayea: hey
<paroneayea>hi janneke