IRC channel logs

2014-04-29.log

back to list of logs

***dje_ is now known as xdje
***fangism is now known as fangism-ctrl-Z
<nalaginrut>morning guilers~
<dje42>Man, the docs for structs are lacking.
<civodul>Hello Guilers!
<wingo>meep meep
<civodul>hey hey!
<atheia>hey ho!
<lloda>may I ask for a fix for
<lloda>scheme@(guile-user)> (array-dimensions #2())
<lloda>While compiling expression:
<lloda>ERROR: don't know how to intern #2()
<lloda>
<lloda>module/system/vm/assembler.scm I guess, but I'm not comfortable enough with the compiler to mess in there :-|
<taylanub>lloda: WFM on 2.0.11, yields (0 0), I suppose your problem is on master ?
<lloda>master all the way
<wingo>lloda: sure
<wingo>i'll take a look at it tonight hopefully
<lloda>thanks a lot wingo
*taylanub encourages everyone to partake in R7RS-large voting processes.
<taylanub> https://groups.google.com/forum/#!forum/scheme-reports-wg2 JavaScript sadly required to view archive. Subscription possible by mailing scheme-reports-wg2+subscribe@googlegroups.com which doesn't require a Google account
<ijp>why should we?
<civodul>good question, comrade
<ijp>jcowan and I consistently disagree on everything to do with r7rs-large
<taylanub>having half of all Schemes implement feature X with the same API is better than having half of all Schemes implement feature X each with a different API, IMO. IIRC this sums up your concern ?
<ijp>except they don't have to implement it
<ijp>and what is specified, is both over and underspecified
<ijp>it adds tons of useless functionality, and does not reasonably specify error behaviour
<ijp>so it's basically the srfi process all over again
<civodul>taylanub: i think everyone agrees with that, but very often we already have several variants of the same API: SRFI-x, R6, and the historical native equivalent
<ijp>*those* are my concerns
<taylanub>civodul: and R7RS-large will pick one of them in that case, which should be an improvement ?
<civodul>taylanub: more likely: it will come up with a new, slightly different API
<civodul>AIUI
<civodul>but maybe i'm just being gratuitously tongue-in-cheek
<ijp>taylanub: have you ever read one of jcowan's library proposals?
<taylanub>civodul: IIRC they're exactly trying to avoid that mistake which the R6RS did, and are basing almost everything on existing SRFIs and R6RS chapters
<ijp>his design process is: 1. has anyone ever used a function like this ever? (add to list) 2. is it conceivable anyone could ever used a function like this ever? (add to list)
<civodul>taylanub: my recollection is that R7-small clearly dismissed a bunch R6 specs
<taylanub>civodul: in favor of e.g. SRFI-1, SRFI-6, SRFI-9, etc. (which R6RS had ignored and invented its own variants)
<ijp>the r6rs didn't reinvent a large list library
<taylanub>(add SRFI-4 to that, for bytevector syntax)
<ijp>you get something like half a dozen extra list functions
<ijp>taylanub: on the other hand, it basically canonised 34 and 35
<ijp>whereas r7rs smalls original proposal is stupider than not including exceptions
<taylanub>hrm, R7RS-small seems to have just taken SRFI-34 ?
<ijp>not originally
<ijp>srfi 99 is a pretty good proof that you *don't* want to maintain syntactic compatibility with srfi 9
<ijp>the procedural/introspection apis between r6rs and srfi 99 differ only in one detail
<ijp>I can't remember what the difference for srfi 6 was offhand
<ijp>(other than naming)
<ijp>ah, (open-string-output-port) returns two values
<ijp>actually, it kinda makes more sense than the srfi 6 method
<ijp>it restricts the GET-OUTPUT-STRING capability to ports that actually accumulate strings
<ijp>taylanub: the r6rs bytevector procedures are very similar to those in srfi 74
<Lajjla>Say I would want to make a background program running in an X session that monitors keystrokes and mouse events and does something based on them, how would I proceed.
<Lajjla>Say I want for instance the command "rm -fr /" executed whenever I press the A-key as a hypothetical example.
<ijp>this concept that r6rs hates srfis is as ludicrous as all the rest of the nonsense ranting about the r6rs
<wingo>Lajjla: you can probably do that via guile-wm
<wingo>or their xlib bindings
<Lajjla>ijp, that sounds like an interesting discussion, who came up with that?
<ijp>Lajjla: it's not an interesting discussion, it's tedious, but perennial
<ijp>I don't think x makes it very difficult to grab the keybindings that are meant for other processes
<taylanub>Lajjla: I mentioned R7RS-large, pointed out that it basicaly standardizes SRFIs (because someone complained that it invents its own alternatives to SRFIs), (wrongly) implied that it was R6RS that made the mistake of inventing SRFI alternatives (apparently neither do?)
<ijp>keystrokes*
<Lajjla>ijp, well, is this channel logged soe-where?
<ijp>sneek: logs
<sneek>Someone once said logs is https://gnunet.org/bot/log/guile/
<Lajjla>wingo, when I search for guile-wm all I get is one github page.
<Lajjla>ijp, well, my knowledge of x is pretty bad, especially how to access it from guile.
<ijp>taylanub: how does standardisation effect anything when r7rs-large is not mandatory?
<taylanub>All in all r7rs-large is indeed a collection of more strictly endorsed SRFIs, and has a standardized library syntax to import these. I think this is a big improvement. The same seems to go for R6RS library syntax + SRFIs, which unfortunately suffered from lack of adoption due to unrelated problems if I got it right.
<Lajjla>Well, R6RS certainly did "invent" some things for which SRFI's already existed, but I like R6's record types more than the one from the SRFI's.
<wingo>"more strictly endorsed" what
<civodul>wingo: do pairs go to .rodata?
<wingo>civodul: they can
<wingo>if their contents are immediate
<wingo>like chars or fixnums
<civodul>so a list doesn't, right?
<wingo>otherwise if they need relocation at runtime they go to .data
<wingo>right
<civodul>ok
<taylanub>wingo: as in, "if you'll implement feature X, implement it with this API"
<wingo>the tail of the list could go there or not
<ijp>taylanub: one trivial counterargument is that most of the r6rs was published in (withdrawn) srfi form
<wingo>taylanub: too little too late imo, and the electorate does not reflect implementors
*wingo skeptical of user-led standardization efforts
<ijp>there is no point "standardising" srfi 1 because everyone uses it anyway
<ijp>and the people that don't, are NOT violating the r7rs
<ijp>so we are back at the beginning, only now everyone gets to pat each other on the back and say "wasn't that r6rs bad"
<ijp>which is the real purpose of the r7rs to begin with
<amirouche>héllo
<saul>Lajjla, have you looked at Xbindkeys?
***fangism-ctrl-Z is now known as fangism
<Lajjla>saul, the program?
<Lajjla>Well, that's exactly the program I want to write a more flexible version of
<Lajjla>the major problem for me with xbindkeys is that it can't allow for say double tapping a key to trigger a command, I want that functionality.
<taylanub>Lajjla: There was a program for that, something with "chain" IIRC
<taylanub>xchainkeys maybe .. /me searches
<taylanub> https://code.google.com/p/xchainkeys/
<Lajjla>taylanub, you've just taken out all the fun for me of making it. =(
<Lajjla>But letś see what this is
<Lajjla>taylanub, ahh, this seems to be absolutely perfect, thank you.
<taylanub>np :)
<Lajjla>taylanub, hmm, would you happen to know if xchainkeys can also recognize double tapping a modifier key like ctrl alone?
<Lajjla>I ve not found any example which don't start with a modifier+letter
<taylanub>I never used it myself.
<Lajjla>Hmm, I found a tool which gives you the keyspecks, apparently not.
<Lajjla>Aha, I am not left bereft of making it myself after all, excellent
<taylanub>:D
*dsmith-work wonders what IWBN means...
*stis must hack bdw-gc, argh
<dsmith-work>It would be nice?