IRC channel logs

2013-09-08.log

back to list of logs

<aidalgol>ijp, ma man!
*aidalgol makes douchy hand gestures.
*ijp turns baseball cap around
<ijp>yo!
*aidalgol turns his cap around before his IQ drops any further.
<brendyn>be kind
<aidalgol>brendyn: huh?
<brendyn>Mocking stupid people
<aidalgol>oh...
<aidalgol>er, sorry
<aidalgol>ijp: You're been busy.
<ijp>there is more, it just hasn't been committed for one reason or another
*aidalgol is trying to understand object properties.
<aidalgol>Ah, got it.
<aidalgol>brain mechanics just clicked
<aidalgol>ijp: Why do you pick a random character from a string, instead of generating a random number and printing it in hex?
<ijp>there was a good reason, but I've forgotten it
<aidalgol>performance?
<aidalgol>ijp: You forgot the copyright notices at the top of the files.
<ijp>gpl right?
<aidalgol>yep
<aidalgol>I'm doing it now.
<aidalgol>What's in (ice-9 documentation)?
<ijp>the object-documentation function
<ijp>and a few other things like that
<aidalgol>I didn't know there was such a module. Is it documented anywhere?
<aidalgol>If not, that would be really ironic.
<ijp>no it isn't :(
<ijp>actually, there was no good reason to include it in admin.scm
<aidalgol>Oh, it's not used?
<ijp>wait a minute
<ijp>ah, nvm, my reasoning is bullcrap
<ijp>aidalgol: well, there are two parallel object property systems
<ijp>one for procedures, and one that for everything
<ijp>and since I sent a mail this morning arguing to get rid of the first one, I made sure to be using the latter one
<ijp>aidalgol: strictly, I could have used (object-property obj 'documenation) and gotten rid of the use-modules
<aidalgol>Would that have been better?
<ijp>not in any real way
<aidalgol>I'd rather not use admin for my bot (instance), so can we make help.scm not depend on admin.scm?
<ijp>well, you can load help without loading the admin commands
<ijp>plugins are explicitly loaded with the use-plugins! function
<aidalgol>Won't it error though when calling admin-command? ?
<ijp>aidalgol: if you remove the file, yes
<ijp>if you just don't (use-plugin! bot 'admin) no
<aidalgol>oh, cool.
*ijp facepalms
<aidalgol>what?
<ijp>aidalgol: you used M-x legalese didn't you
<aidalgol>Nope.
<aidalgol>Why?
<ijp>ah, then copypaste
<aidalgol>yes
<aidalgol>Why?
<ijp>"Copyright (C) 2011 Aidan Gauland"
<aidalgol>Oops...
<ijp>wrong year, wrong person
<ijp>lol
<ijp>I'll fix it
<aidalgol>Actually, isn't the year supposed to refer to the whole program
<aidalgol>Wait, no, it says "This file is part of ..."...
<aidalgol>*facepalms*
<ijp>I'll merge in your changes from master while I'm at it
<aidalgol>good idea.
<aidalgol>ijp: Pushed?
<ijp>yes
<aidalgol>There's supposed to be a space between the year and the name.
*aidalgol ducks.
<ijp>aidalgol: is it okay with you if I make username and realname keyword arguments and default them to the same as nick?
<aidalgol>Seems reasonable.
<aidalgol>I'll try to get an instance up and running this week.
<nalaginrut>sneek: later tell mark_weaver I asked some guys, but seems no convincing answer. The more reasonable guessing maybe: Their upstream manufacture factories may not have enough qualities for you need, and they can't finish the orders before National holiday. Usually, reseller don't store products, but tell their upstream send products to customers directly, it's the lowest cost way.
<sneek>Got it.
<nalaginrut>sneek: later tell mark_weaver but I wonder if you demanded a big quality. If little or just one, that's none sense anyway. ;-)
<sneek>Got it.
<ijp>sneek: later tell aidalgol https://gist.github.com/ijp/6483912
<sneek>Will do.
<ijp>and yea ijp did bring forth documentations unto the lands
<taylanub>I've grown so accustomed to `blah-ref' and `blah-set!' it actually feels awkward to use (set! (blah foo) blurp).
<taylanub>I would've preferred object properties to take two arguments to set the value.
<ijp>they do
<taylanub>Not on my 2.0.9.x build ..
<ijp>wait, two arguments?
<ijp>one argument
<taylanub>(obj-property obj new-value)
<ijp>no wait, I'm being an idiot
<taylanub>Instead of (set! (obj-property obj) new-value)
<taylanub>But anyway, if both were supported, we'd have some code using one style and some code the other, so I'll just succumb. :P
<ijp>taylanub: (object-property obj key) and (set-object-property! obj key value)
<ijp>technically legacy
<taylanub>Oh ..
<taylanub>By the way on this build I get: (define foo (make-object-property)) (set! (foo 'test) 0) (gc) (foo 'test) => 0 Has that changed on master ?
<ijp>well, I get the same on master, but I wouldn't rely on it
<ijp>taylanub: here, go amuse yourself with that https://gist.github.com/ijp/6408630
<ijp>(non-sequitur)
<taylanub>I'm not sure if the fold version of a recursive procedure is necessarily clearer. :P
<ijp>you don't like the left fold turned into a right fold?
<ijp>taylanub: actually, the left fold version of list->number is really clean
<ijp>(define (list->number ls) (fold (lambda (n o) (+ n (* 10 o))) 0 ls))
<ijp>but left fold isn't universal in the same sense right fold is
<ijp>taylanub: http://shift-reset.com/blog/2013/1/28/Tail%20as%20a%20Fold/
<ijp>I should probably finish that blog post about de bruijn indices
<mark_weaver>hi guilers!
<sneek>Welcome back mark_weaver, you have 2 messages.
<sneek>mark_weaver, nalaginrut says: I asked some guys, but seems no convincing answer. The more reasonable guessing maybe: Their upstream manufacture factories may not have enough qualities for you need, and they can't finish the orders before National holiday. Usually, reseller don't store products, but tell their upstream send products to customers directly, it's the lowest cost way.
<sneek>mark_weaver, nalaginrut says: but I wonder if you demanded a big quality. If little or just one, that's none sense anyway. ;-)
<ijp>hey mark_weaver
<mark_weaver>nalaginrut: I only want one :)
<mark_weaver>hi ijp!
<mark_weaver>taylanub: it won't work if you use a symbol like 'test' that's already used somewhere else in the system. you need to use a symbol that's not used anywhere else.
<mark_weaver>or else the symbol won't actually be freed by the GC.
<wingo>heya mark_weaver :)
<mark_weaver>hey wingo! I saw your note about stacks (thanks for pointing that out :)
<wingo>did it sound sensible to you?
<mark_weaver>the problem with mmap'ing a big region for stacks is that it forces you to trade off between handling large numbers of threads well (e.g. termite scheme, which I'd like to see Guile support at some point), and programs that need a large stack from time to time.
<wingo>ah
<wingo>so i would map a big stack per kernel thread
<wingo>and if we do user-space threading, copy them onto the big ol' stack as needed (when the partial continuation is reinstated)
<wingo>that's what go seems to do
<mark_weaver>how big would you propose making these stacks?
<wingo>I would make the kernel thread stacks a few hundred MB on 64-bit systems; maybe 64 MB or so on 32-bit systems
<taylanub>mark_weaver: Haha, didn't think there would be a reference to the symbol `test' somewhere, indeed I get #f when using the symbol `blahblah' instead.
<wingo>enough to be useful for a recursive implementation of map
<mark_weaver>wingo: it's still a fixed-sized stack. you're just making that fixed size bigger.
<wingo>depends...
<mark_weaver>I see no reason why the stack has to be fixed at all. IMO, it should be unlimited, just like any other allocation.
<wingo>do we catch stack overflows or do we force all other processes out to swap?
<wingo>another way of thinking of it: you could map a region as big as the memory that a machine has
<taylanub>ijp: I don't see left fold implemented as right fold in that gist ..
<wingo>at least on 64-bit machines
<mark_weaver>wingo: mapping a lot of memory has a cost also.
<wingo>mark_weaver: there you are wrong i think :)
<ijp>taylanub: well, it's the exact same idea as for list->number
<taylanub>Oh, let me see then ..
<wingo>what cost would it have?
<wingo>nothing measurable, I don't think...
<mark_weaver>wingo: the virtual->physical address map has to be populated by the kernel.
<mark_weaver>I outlined an idea here that you never responded to.
<wingo>it can be populated as a range, and page structures allocated to fill it in as needed
<wingo>i probably didn't see it
<wingo>what was it?
<taylanub>ijp: BTW isn't fold-right (non-tail-)recursive ?
<ijp>yes
<mark_weaver>well, to do segmented stacks: every place where you switch stacks, put an entry in to the same data structure that's to register dynamic winds, that handles switching the stack pointer to the next/prev segment.
<mark_weaver>and also a procedure frame as well, I guess.
<taylanub>(Oh, I thought for a moment that the original definitions of `filter' and `list->number' were tail-recursive.)
<ijp>taylanub: list->number is
<taylanub>Oh OK, so for that case this is not meant to be something practical, right ?
<ijp>define practical
<wingo>yeah i don't like that so much :/ makes returning multiple values much harder
<taylanub>ijp: Well, implementing left fold as right fold inherently loses the iterative nature of left fold, doesn't it ? :P
<ijp>the advantage of foldr is that you essentially get a free inductive proof
<ijp>and correctness is an inherently practical virtue
<mark_weaver>wingo: well, you could assume that all the values will fit into one segment. and make the segments big enough that this would be a reasonable assumption.
<ijp>but no, it won't be tail recursive
<taylanub>OK, interesting.
<wingo>mark_weaver: i'm not sure that we can make any assumption in that regard; not currently anyway
<mark_weaver>the special procedure frame would have some VM code associated with it, that would handle not only moving the SP, but also copying over the values.
<wingo>buf..
<ijp>taylanub: implementing tail as a fold was purely for my own personal amusement
<ijp>head is trivial
<mark_weaver>wingo: I'm accepting that the number of return values have a (large) fixed maximum size. you're suggesting that the entire stack have a (large) fixed maximum size.
<wingo>they are similar restrictions
<wingo>in practice having more stack than you have physical memory is not a restriction
<mark_weaver>so you're suggesting that every posix thread have a stack size as large as physical memory?
<wingo>on a 64-bit system, sure, why not
<wingo>or something like that anyway
<wingo>dunno
<wingo>in java systems you configure the system with a certain heap size
<wingo>in racket as well
<wingo>i always thought that was silly
<wingo>but i came to appreciate the reliability implications that has
<wingo>dunno
<wingo>at some point it's a ulimit
<mark_weaver>well, first of all, it doesn't solve the problem on 32-bit systems. and second, again, the virtual->physical address map has entries for every page.
<wingo>you could configure the system to take its stack size from the rlimits of the current process
<wingo>are you sure you would have to have an entry for every page? that is not clear to me
<wingo>i think there would be other implementation possibilities
<wingo>in the kernel
<wingo>and in the mmu
<wingo>you wouldn't need to tell the mmu anything at all
<wingo>and if we use rlimits, then we solve the problem neatly on 32-bit systems as well
<wingo>while also allowing users to select a different size
<wingo>and preserving maximum efficiency for the normal case
<mark_weaver>IMO, users shouldn't have to select a size at all. it should be just like allocating any other memory.
<wingo>well let's talk about this later, i have some other things to do atm
<mark_weaver>okay
<ijp>has anyone else been having trouble running geiser on master?
<ijp>or has geiser grown a dependency on emacs > 24.1 when I wasn't looking
<ijp>I see no logic to when it drops me into a nested repl
<mark_weaver>I haven't tried geiser with master. Maybe jao knows?
<ijp>okay, I'm not having any trouble (that I can see) from the version on marmalade
<ijp>I don't think it was a build issue, because I've had trouble with clean builds of it
<ijp>but dunno
<ijp>now to figure out what's been wrong with my .guile
<ijp>actually, nvm, I know what that one i
<ijp>horrible error message though
<ijp> http://paste.lisp.org/display/138848
<mark_weaver>Yeah, that error message is not so helpful :-(
<mark_weaver>do you know what the underlying cause was?
<ijp>you get a little more information if I run guile in batch
<ijp> http://paste.lisp.org/display/138849
<ijp>I expect the ?????????????????? is because of my locale setting
<mark_weaver>Ah, I was going to ask about that.
<ijp>I though the problem might have been the extension, but since it used the right one for (utils) I don't think so
<mark_weaver>well, if you can get to the bottom of this, then we can try to improve the error message.
<ijp>and it finds other files in the same directory
<ijp>I'll try removing the cache first, just in case something's stale
<ijp>apparently that did it
<ijp>so, probably something magical we'll never know
<ijp>sigh
<mark_weaver>did you change any macros that might have required some other modules to recompile?
<ijp>I haven't touched those files in months
<mark_weaver>things have been changing in master. maybe something that would have caused some kind of ABI compatibility, dunno.
<ijp>probably
<mark_weaver>if this happened with stable-2.0, I'd have been more worried.
<mark_weaver>but this kind of thing is to be expected in master.
<mark_weaver>(especially now with the new VM getting gradually integrated)
<ijp>still, I don't get why guile is more helpful when ran in batch than interactively
<ijp>the errors are the same, but we don't get a nested repl, or a backtrace
<ijp>well, actually, the first is explained by it being a meta command
<ijp>I think
<ijp>I suppose the thing to do is change the error in load-thunk-from-memory to mention which file it failed on
<mark_weaver>yeah, the error reporting during meta commands is very poor, and probably for no good reason.
<mark_weaver>sounds reasonable
*mark_weaver looks
<mark_weaver>hmm. 'load_thunk_from_memory' is just passed a region of memory. It's not obvious to me how to determine what file it's in.
<ijp>yeah, I see taht
<ijp>gah, dunno
<mark_weaver>in your second paste, the innermost frame is: 0 [primitive-load-path "ijputils/common" ...]
<mark_weaver>why no ".scm" in that filename?
<ijp>it's a .sls
<ijp>anyway, I don't have an example that I can put in a bug report anymore, so I'll just need to be vigilant
<mark_weaver>I see, nvm.
<mark_weaver>I definitely think we need to get much more serious about good error messages.
<ijp>yes
<mark_weaver>Error messages shouldn't be merely an after thought. It should be in the forefront of our minds at every step in the process of design and implementation.
<mark_weaver>e.g., in several of the macros that implement SRFI-9, we pass down the original form as an additional operand to many of the helper macros, so that they have enough information to generate a good error message.
<mark_weaver>(mostly in srfi-9/gnu.scm)
<mark_weaver>it would be nice if that code were more readable though. I had a lot of trouble implementing the error checking done in those macros. It's actually what prompted me to import 'ck' into Guile.
<mark_weaver>(you wouldn't have wanted to see the code I wrote without the help with 'ck' :)
<ijp>hehe
<ijp>better error messages are the big reason racket pushes syntax parse
<mark_weaver>I really need to take a closer look at syntax parse.
<mark_weaver>cky: I just noticed that RacketCon overlaps with GNU's 30th anniversary hackathon.
<wingo>yes there have been abi incompatible things happening in master
<mark_weaver>especially in light of the Snowden revelations, this is the main reason I'm planning to dump my Intel-based box in favor of a Yeeloong again: http://article.gmane.org/gmane.os.openbsd.misc/125749/match=intel+advannced+management+technology
<mark_weaver>the new YeeLoong 8133, while out of my price range, looks fairly reasonable as a modern dev machine.
<mark_weaver> http://teknohog.godsong.org/hardware/naga/
<nalaginrut>hmm...Yeeloong as dev machine?
<mark_weaver>why not?
<nalaginrut>seems 900M per CPU
<mark_weaver>personally, I'd rather sacrifice a little speed than accept the near certainty that NSA has a back door into my machine.
*nalaginrut uses i5 2.5G 4 cores and blame its speed everyday...
<nalaginrut>alright, I see
<mark_weaver>also, you shouldn't assume that speed is proportional to clock rate. in practice, the CPU spends a lot of time waiting for other things like memory accesses.
<nalaginrut>anyway, you may enjoy SSD
<nalaginrut>I have no SSD
<mark_weaver>yeah, an SSD would be nice. Alas, I'm still using rotating disks.
<nalaginrut>but 900M sounds too low
<nalaginrut>I wonder if you could endure compiling Guile ;-D
<mark_weaver>I almost never need to recompile all the .go files. In practice, I only need to recompile the C files, and a few .go files here and there.
<mark_weaver>on the rare occasions that I need to do a full recompile, I can leave it going while I do something else.
<mark_weaver>anyway, I used a Yeeloong 8101B as my main dev machine for a few years, and it seems that's where I'm headed again, thanks to the NSA.
<dsmith>mark_weaver, Oi! That is scary
<mark_weaver>yep
<mark_weaver>at the time that post was written, it was probably dismissed by many as paranoia. now we know better.
<dsmith>Then again, if you control your network, you can probably circumvent some of that backdoor stuff
<mark_weaver>I dunno, that hasn't worked very well for protecting computers from viruses. In practice, we do a lot of web browsing and so on. lots of opportunities for hostile data to come in.
<mark_weaver>also, even if we do a great job protecting our network at home, what about when we're not at home?
<mark_weaver>and then there's the fact that most of us use laptops with integrated wireless.
<mark_weaver>I hate hate hate having to waste time worrying about this stuff, but alas that's a pipe dream.
<mark_weaver>*grump*
*ijp hands mark_weaver a lollipop to distract him
<mark_weaver>heh :)
<taylanub>On security: http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html I can't evaluate whether the suspicions in that post are sound, but it sounds interesting.
<mark_weaver>taylanub: very interesting, thanks!
<mark_weaver>Given the increasingly intimate integration between us and our computers, which is likely to become direct physical integration into our minds at some point, I simply cannot accept the prospect of a single entity having root control over almost all computers in the world, which seems to be the NSA's goal.
<mark_weaver>that future is too frightening to contemplate.
<ijp>the temptation of google glass is really problematic for me, because it's a childhood dream come to life
<mark_weaver>fighting this might well become my primary focus.
<mark_weaver>ijp: yeah, I can sympathize. even more alluring to me: one of the google founders (I forget which) once suggested the idea of something integrated into your brain, such that you'd merely have to think of something you wanted to know, and it would automatically do a web search and whisper the results into your ear.
<mark_weaver>I thought about this some more, and realized that eventually, we should be able to access the knowledge of the internet as effortlessly as we access our own memories.
<mark_weaver>people with such capabilities would be vastly more fit, from an evolutionary perspective, than those naysayers who refuse to integrate such tech into their heads.
<mark_weaver>but obviously it would be a disaster if the tech is vulnerable to hacking from the outside.
<mark_weaver>it seems to me that's where we're headed, ready or not, and we better damn well make sure we're more secure than we are now.
<mark_weaver>( so far we're not doing too well )-:
<taylanub>I see the Google Glasses as nothing but another input/output device, whose hardware/drivers should be open, so I can just install my favorite OS on it. :D
<foeniks>I am currently looking into the guile languages feature
<foeniks>interesting stuff
<mark_weaver>taylanub: Granted, Google Glass isn't a whole lot worse than the ubiquitous mobile phones everywhere with their integrated cameras.
<mark_weaver>foeniks: feel free to ask any questions you might have about that! (nevermind out OT conversation :)
<mark_weaver>s/out/our/
<foeniks>basically I have so far looked at the brainfuck and at elisp language included with the guile sources (git repo)
<foeniks>now I kind of wonder how to get started while developing. I have started writing a lexer (inspired by the elisp implementation)
<foeniks>and set up a spec.scm so I can switch to my toy language in the repl
<foeniks>it does some lexing
<foeniks>for debugging purposes I just loaded the parser module directly since I would not get backtraces from the Repl
<foeniks>I.e.
<foeniks>,L my-toy-lang
<foeniks>my-toy-lang@(guile-user)> something-unparsable@$!#
<foeniks>I wonder what you use as an approach here
<mark_weaver>well, I suspect it doesn't make sense to switch the REPL over to your new language until it's basically working.
<ijp>well, you could just use the identity function for a parser
<ijp>and evaluator, and printer
<mark_weaver>maybe someone else here can give better advice (wingo?), but I'd start by testing your lexer and parser manually.
*wingo agrees with both mark_weaver and ijp
*ijp pokes wingo to make sure this isn't an autoreply
<wingo>hehe
<mark_weaver>:)
<ijp>well, the identity parser would fail, IIRC
<mark_weaver>the reader takes a port and an environment, so yeah, an identity function wouldn't work :)
<ijp>you'd probably want to read as much as possible from the lexer, and return it as a list
<ijp>which is fine, as long as you remember you'll need to "return" with C-d
<mark_weaver>ijp: well, that would lead to lexing the entire file before parsing begins, and it might not be desirable to have to C-d each expression at the REPL.
<mark_weaver>another option is to read only a single top-level form, which is what Scheme does anyway.
<ijp>yes, this is a problem the lua parser has
<ijp>but if you wanted to test a lexer at the repl (including whitespace) this is one way
<foeniks>thanks for the input
<foeniks>I think one top-level-form at a time is the way to go
<mark_weaver>foeniks: you're welcome! feel free to ask more questions as they arise, and happy hacking!
<ijp>foeniks: just make sure you don't read ahead too much
<ijp>otherwise it'll work fine at the repl, but can fail really easily if used programmatically
<mark_weaver>yeah, it's best to read just one character at a time, and make lexing/parsing decisions as soon as possible based on what you have read so far.
<mark_weaver>s/decisions/reductions/
<mark_weaver>although I guess in a language with a line-oriented syntax, reading a line at a time might be okay too.
<foeniks>I wanted to implement some clojure-ish lisp dialect
<foeniks>at least syntax wise
<foeniks>don't know how far I will go with the lazyness and protocols, etc.
<foeniks>therefore I think that it is not especially line-oriented
<mark_weaver>sounds nice! I've long wanted some of the Clojure data structures for Guile.
<mark_weaver>foeniks: if you implemented things in such a way that some of the functionality was available to Scheme programs (or any other language supported by Guile), that would be even better :)
<mark_weaver>foeniks: yeah, character-at-a-time is probably the way to go there.
<foeniks>My first intuition was actually to be character at a time and have a combined lexer/parser
<mark_weaver>yeah, for Lisp-like syntax, I think that makes sense.
<foeniks>but guile-elisp seems to separate the two so now I follow the approach of the elisp parser
<foeniks>yet I wonder if that has real benefits
<ijp>which reminds me, I should finally get around to rebasing lua
<mark_weaver>Lisp parsing is so trivial that to my mind, it seems silly to separate it from lexing. I certainly wouldn't feel compelled to emulate Guile's elisp implementation. Guile's Scheme reader does not separate them, fwiw.
<mark_weaver>(admittedly, Guile's Scheme reader is implemented in C, but that seems orthogonal)
<mark_weaver>foeniks: I wonder if this would be suitable for you: http://www.nongnu.org/guile-reader/doc/guile-reader.html
<ijp>you could also try out the PEG stuff
<cky>mark_weaver: When you put it that way, I might just have to unregister from RacketCon. :-P
<mark_weaver>cky: hehe :)
<cky>mark_weaver: Seriously though, who could pass up a 30th anniversary celebration?
<cky>At least I don't have to change my flight schedule. That's always a bonus.
<mark_weaver>cky: so you weren't planning to make a presentation this time?
<cky>mark_weaver: It's not set in stone yet. The registration process was just at the stage of "are you interested in presenting something?", no questions were asked as yet about what I planned to present.
<mark_weaver> https://www.gnu.org/gnu30/
<mark_weaver>foeniks: fwiw, Guile Reader was written by Ludovic Courtès, co-maintainer of Guile.
<foeniks>there should be an s-expression diff for git
<mark_weaver>heh, that would be nice :0
<stis>evening guilers!
<ijp>foeniks: stamourv has an sdiff for racket, dunno how easy it would be to port
<stis>ijp: if it's a good tool I could try to do it!
<stis>else guile contarct guile-syntax-parse and racker-matcher-for-guile should be valuable to do the translation for yourself
<stis>look in compat/racket
<ijp>I don't expect there would be a lot of macrology involved
<stis>ijp: true, but to code syntax-parse and contracts I needed to wrap quite many ideoms which one could reuse
<stis>may was of the functional form!
<stis>may -> many
<cky>mark_weaver: I was thinking, remember that discussion about SRFI 45 and multiple values? While it's too hard to make SRFI 45 handle multiple values without breaking backward compatibility, there's no reason why SRFI 41's embedded promises can't support multiple values. I was thinking about this because Racket's streams are documented to support multiple values.
<cky>And given it's fairly trivial to support this for our SRFI 41 streams, there doesn't seem to be a reason not to.
<ijp>how would srfi 41 benefit from this?
<foeniks>is there any guile-preferred way of assertions?
<ijp>does it use mv a lot internally?
<foeniks>another question, is peek-char followed by read-char preferrable or read-char and occasionally unread-char
<ijp>I'm not 100% positive unread-char works on all ports
<ijp>hmm, the manual doesn't note any problems, so you might be fine
<mark_weaver>foeniks: peek-char followed by read-char is preferable, I think.
<mark_weaver>it should be more efficient
<mark_weaver>cky: maybe worth considering, though there's a price to pay (an extra cons per stream element), and I wonder what the use cases are.
<mark_weaver>it also seems a bit unnatural to me for streams to contain more than one value per element.
<mark_weaver>what I mean is: if you need more than one value per stream element, it seems more natural to explicitly make the stream elements be lists or vectors.
<mark_weaver>for memoization of procedures (the job of promises), it seems more natural that it would automatically handle multiple values.
<mark_weaver>to justify this position a bit more: 'cons' does not allow its first argument to return multiple values, so I don't expect 'stream-cons' to support it either. on the other hand, with promises I expect to be able to delay any expression, regardless of how many values it returns.
<cky>mark_weaver: Fair enough. I don't really have a strong opinion either way, just noticing that Racket supported it.
<cky>Certainly the status quo is fine with me.
<mark_weaver>okay. I don't have a strong opinion either way either.. just talking :)
<cky>:-)
<bananagram>ERROR: Syntax error:
<bananagram>unknown location: source expression failed to match any pattern in form if
<bananagram>I can't figure out this error
<bananagram>does anyone recognice it?
<ijp>it means you have a broken (if ...) somewhere
<mark_weaver>bananagram: it suggests that you used 'if' alone as a bare expression somewhere.
<ijp>or it could be used alone^^
<bananagram>oh, that makes sense
<mark_weaver>bananagram: i.e. not as the first element of a parenthesized expression.
<bananagram>thanks
<mark_weaver>bananagram: you're welcome.
<mark_weaver>that reminds me that I really need to implement source location information for bare symbols.
<dsmith>mark_weaver, Aye, 'Twould be a great grand coolness.
<bananagram>I have an IRC script with one colossal function, and somewhere in that function is a broken if
<bananagram>ugh
<ijp>please tell me you haven't written another guile irc bot
<bananagram>I have
<mark_weaver>bananagram: well, for starters, search for [^(]if
*ijp counts to 20 slowly
<mark_weaver>i.e. any 'if' that's not immediately preceded by a (
<dsmith>ijp, It's the very next thing to do after writing your own toy scheme.
<mark_weaver>haha
<ijp>dsmith: yes, it seems to be that way
<bananagram>what's wrong with that?
<ijp>bananagram: surely you didn't write this colossal function all at once? what was the last part you changed
<dsmith>or maybe it's the other way around....
<mark_weaver>ijp is almost single-handedly responsible for helping me avoid the temptation to write my own scheme implementation :)
<mark_weaver>bananagram: it's a bit crude, but you can do a binary search, where you comment out parts of the procedure to narrow down the source of the error.
<bananagram>ijp: the hook that it uses
<bananagram>it used a crappier hook for a long time
<ijp>bananagram: because if we had a community jar where you put $5 in every time you wrote a scheme, we could all have a great summer in the carribean
<dsmith>lol
<bananagram>no, writing scripts
<bananagram>for IRC
<dsmith>bananagram, everyone seems to be writing a bot lately
<ijp>there is nothing inherently wrong with it
<mark_weaver>bananagram: if you show me the procedure, I'll see if I can spot it. to help me motivate to implement bare-symbol source tracking :)
<ijp>since aidalgol roped me into helping with his one, I'm also guilty of it
<bananagram>mark_weaver: it's a bit embarrassing, I'd rather not
<bananagram>for reasons
<mark_weaver>bananagram: okay, well, binary search then :)
<ijp>this is also a good time to learn the source control lesson :)
<bananagram>what's that?
<mark_weaver>bananagram: here's a tip: "#;" comments out the immediately following S-expression.
<bananagram>mark_weaver: thanks
<bananagram>that's great
<ijp>bananagram: have you heard of svn, git or mercurial?
<mark_weaver>bananagram: if you keep your source code in version control with frequent commits, then it's not hard to find the commit where the problem was introduced.
<mark_weaver>bananagram: 'git' has a special command specifically for this, called "git bisect"
<bananagram>ijp, yeah, I tried to make a script repository on git but it didn't work
<cky>bananagram: "git init".
<mark_weaver> https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
<dsmith>Though it shouldn't be *that* difficult to locate an offending "if".
<ijp>bananagram: well, don't get too distracted, fix this problem first
<bananagram>yeah
<ijp>dsmith: my first thought was a macro and use of . that went awry
<dsmith>Yeah
<mark_weaver>bananagram: one possibility is that you put an 'if' expression where a 'cond' clause belongs.
<mark_weaver>e.g. (cond (<cond> <e> ...) (if foo bar))
<bananagram>I think I found it
<bananagram>when and unless were defined too late
<bananagram>that didn't give me any trouble before
<mark_weaver>bananagram: what version of guile are you using?
<mark_weaver>'when' and 'unless' are defined by default in recent versions of Guile.
<bananagram>2
<bananagram>hm
<mark_weaver>2.0.?
<bananagram>2.0.9, but I'm not sure about the plugin
<bananagram>it's probably the same
<ijp>plugin?
<mark_weaver>'when' and 'unless' have been defined by default since Guile 2.0.5
<bananagram>the IRC plugin in the client
<bananagram>well, thanks
<bananagram>now it's giving me a wrong number of arguments error
<bananagram>progress!
<mark_weaver>indeed :)
<ijp>can you run in interactively?
<ijp>then you'll get some nice repl commands to poke around with
<mark_weaver>hmm, it wouldn't be too hard to check 'cond' clauses for bare macros in the place where the condition belongs.
<bananagram>yeah
<mark_weaver>(and to produce a better error message in that case)
<mark_weaver>macros that don't support identifier syntax, that is.
<mark_weaver>although it seems a bit ad-hoc. hmm. maybe just go for the real solution.
<mark_weaver>okay, I have a plan: (1) add source location information to syntax-objects, (2) add a variant of read that produces syntax objects in place of symbols, with the source information.
<mark_weaver>(3) use that 'read' variant in all the right places where Guile loads source code.
<bananagram>ijp: so what is wrong with writing IRC bots in scheme?
<mark_weaver>bananagram: if I may speak for him: one of ijp's pet peeves is reinventing the wheel.
<mark_weaver>I'm reasonably sure he doesn't have anything against writing IRC bots in Scheme, in general.
<bananagram>oh, that makes sense
<bananagram>I haven't reinvented much, just written for the API
<ijp>are you using bobot, or something?
<bananagram>no
<mark_weaver>speaking for myself, I can see benefits to writing a pure-Scheme bot, without using a C++ library.
<mark_weaver>it's not like it's a ridiculously large job, afaict.
<ijp>I think dsmith still has problems with memory leaks
<mark_weaver>yes, he does.
<mark_weaver>hmm, the tricky part here is that syntax-objects include a 'module' field, which implicitly assumes that a module has already been assigned to the identifier. this 'module' field is something that Guile added to the upstream psyntax a long time ago.
<mark_weaver>the upstream 'psyntax' was designed to allow syntax-objects to include source tracking information, but it's going to be non-trivial to get that back thanks to this new 'module' field.
<ijp>weird
<mark_weaver>well, "non-trivial" might be too strong. but there's a lot of code in the current psyntax that will have to be updated to deal with syntax objects that have no included 'module'.
<mark_weaver>at this point, it might actually be simpler to make a separate record type for tracking the source information.
<shanecelis>How do I install guile 2.2?
<mark_weaver>guile 2.2 doesn't exist yet :)
<shanecelis>yeah, that's what I thought.
<mark_weaver>but if you mean the git master branch that will eventually become 2.2: get the 'master' branch of the git repository and build it.
<mark_weaver>(personally, I wouldn't recommend installing it in any of the standard system paths yet)
<shanecelis>I wanted to try guile-wm, but it seems to require 2.2.
<mark_weaver>shanecelis: that's fixed now.
<mark_weaver>shanecelis: I take that back. it's fixed in guile-xcb.. maybe not yet in guile-wm.
*shanecelis pulls from github
<shanecelis>mark_weaver: ah, so it is. Cool. You've tried guile-wm, then?
<mark_weaver>not yet, but I want to soon.
<mark_weaver>but I built guile-xcb.
<mark_weaver>I'll need to modify guile-wm to be more keyboard oriented and use tiling by default (more like ratpoison), but it seems very promising. it might very well become my window manager of choice at some point :)
<shanecelis>yeah, it looks cool. I'm trying to try it out. :)
<mark_weaver>and your emacsy-webkit might well become my browser of choice, for that matter :)
<shanecelis>EMACS IN ALL THE THINGS
<mark_weaver>at least for cases were emacs-w3m is insufficient.
<mark_weaver>:)
<mark_weaver>amen to that!
<davexunit>guile-wm seems cool. I enjoyed using stumpwm.
*shanecelis builds guile-xcb successfully
<davexunit>though, I haven't taken the time to build up a config that does roughly the same things the gnome does.
<ijp>I've never been picky about wms, because I have very simple needs
<ijp>fullscreen and two half-screen, cover about 95% of my needs
<mark_weaver>the main killer features of GNOME 3 that I like are the notification manager and the IM-integration. but I think I'd prefer to reimplement those things in something like guile-wm.
<mark_weaver>other than that, like ijp, I'm happy with full-screen and half-screen tilings for the most part.
<davexunit>same.
<mark_weaver>for at least the last 15 years or so I've flip-flopped between fancy desktop environments and very simple ones. I've been in "fancy desktop" mode for the last couple of years, but I think I'm due for another flip to simplicity, partly because the recent Snowden revelations are making my paranoid about my computer security again.
<shanecelis>ok, I've kind of got guile-wm working.
<shanecelis>Kind of... :/