00:04 (join) dented42
00:09 (join) ormaaj
00:11 (quit) mithos28: Quit: mithos28
00:16 (quit) dented42: Quit: Computer has gone to sleep.
00:21 (join) dented42
00:23 (join) mithos28
00:34 asumu: Oh, I didn't know someone had made a Racket binding for Z3 https://github.com/sid0/z3.rkt
00:38 jonrafkind: you gonna use it?
00:40 (quit) deu5: Quit: Leaving
00:41 (quit) spiderweb: Quit: ERC Version 5.3 (IRC client for Emacs)
00:45 mithos28: is there a stardard library function of the type ((HashTable a b) (b -> c) -> (HashTable a c))
00:46 mithos28: doing the obvious thing, not (lambda (x y) (hash))
00:48 jonrafkind: errr hash-map?
00:48 jonrafkind: oh i guess that just returns a list
00:48 mithos28: hash-map has the type ((HashTable a b) (a b -> c) -> (Listof c))
00:49 jonrafkind: thats sort of strange, i would have expected hash-map to return a new hash
00:49 jonrafkind: even though it has the word 'map' in it
00:49 jonrafkind: well it should be trivial to write anyway, right?
00:49 mithos28: yeah, already did that
01:05 mithos28: https://gist.github.com/4057763
01:05 mithos28: That is saying I need more type annotations
01:05 mithos28: Where do I need to put them?
01:07 jonrafkind: lol what an error message..
01:07 mithos28: I mean its better than showing you the expansion of for*/hash
01:08 mithos28: The 'best' part about filing TR bugs is that there is a good chance that I will be the one who finally fixes it
01:09 jonrafkind: this error is like 'bad syntax'
01:10 jonrafkind: i dunno i dont see what other type annotations you could possibly add here
01:10 jonrafkind: maybe the type of the values expression?
01:11 mithos28: nope
01:11 mithos28: Bug time it is
01:11 jonrafkind: (: (values v x) (Values Number Number))
01:11 jonrafkind: it says this is a syntax error but i dont see why
01:12 mithos28: you want ann not :
01:12 mithos28: : is for definition of bindings not expressions
01:12 jonrafkind: ah
01:13 mithos28: what is the easiest way to rewrite this? for/fold?
01:14 jonrafkind: yea i guess, (hash-set old-hash v x)
01:14 jonrafkind: heh you can't even do 'raco expand r.rkt' because the type error happens during expansion
01:14 jonrafkind: how do you debug such things?
01:14 jonrafkind: print the module out before tr deals with it?
01:15 mithos28: by debug, you mean with my TR developer hat on?
01:15 jonrafkind: yea i guess
01:15 mithos28: I would hack in a debug print statement when TR gets the module
01:15 jonrafkind: i mean assuming there is an issue with for*/hash:
01:16 mithos28: or use typed/racket/no-check
01:16 jonrafkind: aha
01:19 (quit) mceier: Quit: leaving
01:22 (join) untrusted
01:48 mithos28: so even a simple for/hash: doesn't work in TR
01:49 jonrafkind: there aren't any uses of it in the tree?
01:50 mithos28: doesn't look like it
01:50 mithos28: rudybot: init typed/racket
01:50 rudybot: mithos28: your typed/racket sandbox is ready
01:50 mithos28: rudybot: eval (for/hash: : (HashTable Symbol Symbol)
01:50 rudybot: mithos28: error: #<undefined>:1:0: read: expected a `)' to close `('
01:50 mithos28: ((v : Symbol '(a b c)))
01:50 mithos28: (values v v))
01:51 jonrafkind: ;; for/hash{,eq,eqv}:, for/vector:, for/flvector:, for/and:, for/first: and
01:51 jonrafkind: ;; for/last:'s expansions can't currently be handled by the typechecker.
01:51 jonrafkind: base-env/prims.rkt
01:51 jonrafkind: its funny that the docs dont mention that
01:51 jonrafkind: and funnier that they are provided
01:51 mithos28: funny is one word
01:52 jonrafkind: i could also see 'anger that boils with the heat of 1000 suns'
01:54 mithos28: So the solution is make-immutable-hash and for/list:
01:59 mithos28: and now I'm running into the fact that hashtables are assumed to be mutable
02:10 (quit) Enoria: Quit: Leaving
02:11 (quit) untrusted: Remote host closed the connection
02:22 (join) mceier
02:25 (quit) Nisstyre-laptop: Remote host closed the connection
02:25 (quit) jonrafkind: Ping timeout: 268 seconds
02:36 (quit) scott_: Quit: Leaving
02:37 jaimef: can raco be used to make executables for say web-server/insta lang?
02:38 (join) jonrafkind
02:38 (quit) jonrafkind: Changing host
02:38 (join) jonrafkind
02:50 (join) niels1
03:00 (join) hkBst
03:01 (quit) hkBst: Changing host
03:01 (join) hkBst
03:14 (quit) mithos28: Quit: mithos28
03:28 (quit) Kaylin: Read error: Connection reset by peer
04:03 (quit) karswell: 
04:07 (quit) jonrafkind: Ping timeout: 252 seconds
04:32 (join) asvil
04:34 (join) noelw
04:57 (quit) mario-goulart: Remote host closed the connection
04:58 (join) mario-goulart
05:01 (quit) Demosthenex: Ping timeout: 260 seconds
05:02 (join) Demosthenex
05:07 (quit) Shvillr: Read error: Connection reset by peer
05:08 (join) Shvillr
05:15 (quit) Demosthenex: Ping timeout: 268 seconds
05:16 (join) Demosthenex
05:18 (join) bitonic
05:23 (join) masm
05:27 (quit) Demosthenex: Ping timeout: 252 seconds
05:29 (join) Demosthenex
05:33 (quit) Demosthenex: Ping timeout: 268 seconds
05:35 (join) Demosthenex
05:44 (quit) Demosthenex: Read error: Operation timed out
05:54 (join) Demosthenex
05:56 (quit) bitonic: Remote host closed the connection
05:57 (join) bitonic
05:59 (quit) Demosthenex: Ping timeout: 246 seconds
06:00 (join) Demosthenex
06:04 (join) ambrosebs
06:06 (quit) Demosthenex: Ping timeout: 240 seconds
06:08 (join) mye_
06:09 (join) Demosthenex
06:10 (quit) mye: Ping timeout: 246 seconds
06:10 (nick) mye_ -> mye
06:14 (quit) Demosthenex: Ping timeout: 276 seconds
06:14 (join) Demosthenex
06:19 (quit) Demosthenex: Ping timeout: 246 seconds
06:20 (join) Demosthenex
06:21 (join) jsj
06:23 (join) ewemoa
06:25 ewemoa: i'd like drracket to reread a file that it already has open -- is that doable without opening a new tab / window first, closing the tab / window that already has the file open and then opening the file in the new tab / window?
06:25 noelw: There is a revert command on the file menu, iirc
06:26 ewemoa: noelw: aha -- tyvm -- that seems to work
06:26 noelw: Great!
06:26 (quit) Demosthenex: Ping timeout: 252 seconds
06:27 ewemoa was fooled by the naming :)
06:28 (join) Demosthenex
06:31 (join) MightyFoo
06:32 (nick) MightyFoo -> tim-brown
06:38 (quit) ambrosebs: Ping timeout: 276 seconds
06:46 (join) jeapostrophe
06:46 (quit) jeapostrophe: Changing host
06:46 (join) jeapostrophe
06:53 (quit) Demosthenex: Ping timeout: 260 seconds
06:57 (join) ambrosebs
07:06 (join) Demosthenex
07:08 (join) MightyFoo
07:08 (nick) MightyFoo -> tim-brown
07:17 (quit) Demosthenex: Ping timeout: 245 seconds
07:18 (join) Demosthenex
07:23 (quit) cdidd: Remote host closed the connection
07:45 (quit) ambrosebs: Ping timeout: 260 seconds
08:00 (join) ambrosebs
08:05 (join) nathanpc
08:08 (join) RacketCommitBot
08:08 RacketCommitBot: [racket] plt pushed 1 new commit to master: http://git.io/C0Ci2g
08:08 RacketCommitBot: racket/master 4c3ee9c Matthew Flatt: fix for Win64 build...
08:08 (part) RacketCommitBot
08:16 (join) mizu_no_oto
08:18 ewemoa: splash or trickle or something else?
08:33 (quit) ambrosebs: Ping timeout: 246 seconds
08:42 (join) RacketCommitBot
08:42 RacketCommitBot: [racket] plt pushed 1 new commit to master: http://git.io/2ZTtKw
08:42 RacketCommitBot: racket/master a4d440a Robby Findler: fix redex docs and disable running test-docs-complete.rkt directly...
08:42 (part) RacketCommitBot
08:55 (quit) DT`: Ping timeout: 255 seconds
08:56 (quit) acarrico: Ping timeout: 246 seconds
08:56 (quit) mizu_no_oto: Quit: Computer has gone to sleep.
09:02 (join) DT`
09:03 (join) ambrosebs
09:13 (join) acarrico
09:29 (quit) ewemoa: Quit: Leaving.
09:30 greghendershott: Hi, all. `with-syntax*' doesn't seem to allow ellipses in its pattern-variable form: https://gist.github.com/4059716 Is this an undocumented but intended limitation of with-syntax*, or, is it a bug I should report?
09:34 (join) mizu_no_oto
09:44 (join) mmc1
09:48 (join) RacketCommitBot
09:48 RacketCommitBot: [racket] plt pushed 3 new commits to master: http://git.io/VqpMjQ
09:48 RacketCommitBot: racket/master 483148e Matthew Flatt: repair to `custodian-shutdown-all'...
09:48 RacketCommitBot: racket/master 34f05a5 Matthew Flatt: add `planet2' to distribution
09:48 RacketCommitBot: racket/master 623265d Matthew Flatt: fix demod for submodules
09:48 (part) RacketCommitBot
09:52 samth: greghendershott: bug
09:53 greghendershott: OK I'll do a PR.
10:03 (quit) mceier: Quit: leaving
10:03 (join) mceier
10:05 (quit) Demosthenex: Ping timeout: 255 seconds
10:06 (join) Demosthenex
10:09 (quit) acarrico: Ping timeout: 246 seconds
10:09 (quit) niels1: Quit: WeeChat 0.3.8
10:09 (join) dyoo
10:14 (quit) Demosthenex: Ping timeout: 268 seconds
10:16 (join) Demosthenex
10:20 (quit) jeapostrophe: Read error: Operation timed out
10:23 (quit) ambrosebs: Ping timeout: 246 seconds
10:25 (join) acarrico
10:26 (quit) dyoo: Quit: dyoo
10:28 (quit) Demosthenex: Ping timeout: 246 seconds
10:30 (join) Demosthenex
10:36 (quit) Demosthenex: Ping timeout: 246 seconds
10:38 (quit) bjz: Quit: Leaving...
10:38 (join) bjz
10:38 (quit) bjz: Client Quit
10:42 (join) Demosthenex
10:50 (join) mye
10:53 (quit) Demosthenex: Ping timeout: 240 seconds
10:55 (join) Demosthenex
10:59 (quit) mceier: Quit: leaving
11:00 (quit) Demosthenex: Ping timeout: 245 seconds
11:01 (join) Demosthenex
11:03 (join) deu5
11:03 (join) dyoo
11:11 (quit) noelw: Quit: noelw
11:12 (quit) Demosthenex: Ping timeout: 276 seconds
11:13 (join) Demosthenex
11:17 (join) MayDaniel
11:18 (quit) hkBst: Quit: Konversation terminated!
11:20 (quit) Demosthenex: Ping timeout: 260 seconds
11:20 (join) Demosthenex
11:30 dyoo: greghendershott: followed up on your gist.  try: (require (for-syntax racket/syntax))
11:31 greghendershott: dyoo: Thank you. Literally this second I was replying to Ryan's email re my PR where he also suggested that. :)
11:34 dyoo: greghendershott: no problem.  Make this a point in your macro tutorial, by the way.  It's something that people hit from time to time.
11:34 (quit) mizu_no_oto: Quit: ["Textual IRC Client: www.textualapp.com"]
11:35 greghendershott: dyoo: Definitely, yes.
11:42 (join) jeapostrophe
11:43 (quit) dented42: Quit: Computer has gone to sleep.
11:50 (join) wibble37
11:50 (quit) jeapostrophe: Ping timeout: 245 seconds
11:54 (join) mithos28
12:00 (quit) dyoo: Quit: dyoo
12:06 (join) anRch
12:08 (join) dyoo
12:09 (join) mceier
12:13 asumu: dyoo, greghendershott: when I forget to (require (for-syntax syntax/parse)) the weird error message always gets me.
12:13 asumu: (by now I just pattern match on the error...)
12:20 jaimef: can you raco exe webserver/insta?
12:24 samth: jaimef: that should work
12:26 (join) cdidd
12:26 tim-brown: night all
12:26 (quit) asvil: Ping timeout: 240 seconds
12:30 (quit) Demosthenex: Ping timeout: 252 seconds
12:32 (join) Demosthenex
12:33 (quit) deu5: Remote host closed the connection
12:35 (join) Nisstyre-laptop
12:36 dyoo: is there a link to documentation to old versions of Racket?  Say, Racket 5.1?
12:41 samth: dyoo: it's somewhere on the download site
12:42 jaimef: https://gist.github.com/4060774
12:48 asumu: jaimef: http://lists.racket-lang.org/users/archive/2012-November/054847.html
12:49 asumu: It's a bug in 5.3.1, if you use the workaround Matthew lists at the bottom it should work.
12:49 asumu: The next release should have the bug fix.
12:49 jaimef: thanks
12:51 jaimef: works. /me dances
12:52 (part) wibble37: "Killed buffer"
13:01 (join) dented42
13:04 (quit) Nisstyre-laptop: Ping timeout: 240 seconds
13:04 (quit) anRch: Quit: anRch
13:08 dyoo: question: is the following expression a no-op, or does it do anything useful?  (parameterize-break #t (void))
13:08 dyoo: (context: I'm reading DrRacket's code for indentation to figure out what it does)
13:19 dyoo: answer to myself: ah, ok.   The intent is to allow the currently running thread to be breaked if we're in a long-running computation.
13:26 (quit) bitonic: Ping timeout: 264 seconds
13:29 (join) ambrosebs
13:31 (join) Nisstyre-laptop
13:35 (join) mizu_no_oto
13:38 (quit) mye: Quit: mye
13:45 (join) nilyaK
13:45 (quit) shriphani: Read error: Connection reset by peer
13:47 (quit) dented42: Ping timeout: 265 seconds
13:57 (quit) nilyaK: Quit: Leaving.
13:59 dyoo: anyone know why splay trees are used in for holding onto the token structure in DrRacket?
13:59 (join) mye
14:01 (join) scott__
14:02 (join) jonrafkind
14:03 (join) jeapostrophe
14:04 (join) RacketCommitBot
14:04 RacketCommitBot: [racket] plt pushed 15 new commits to master: http://git.io/fRcYRg
14:04 RacketCommitBot: racket/master 5c2fef8 Jay McCarthy: Clarify some Planet 2 documentation re: comments
14:04 RacketCommitBot: racket/master 2265a0a Jay McCarthy: Fixing typos in Planet 2 docs
14:04 RacketCommitBot: racket/master 74c9871 Jay McCarthy: Fixing typos in Planet 2 docs
14:04 (part) RacketCommitBot
14:09 (join) dented42
14:16 (quit) ambrosebs: Ping timeout: 276 seconds
14:18 jaimef: does making binaries tend to result in fast execution time? or is it merely for deployment/packaging purposes?
14:18 (quit) Nisstyre-laptop: Quit: Leaving
14:20 (quit) mye: Quit: mye
14:20 samth: jaimef: the latter
14:22 jaimef: ok
14:24 (join) anRch
14:27 (join) mye
14:30 (quit) anRch: Read error: Connection reset by peer
14:32 (join) anRch
14:41 jaimef notes OS threads listed as supported
14:45 (join) Nisstyre
14:55 (quit) anRch: Read error: Connection reset by peer
14:55 (join) anRch
14:55 jonrafkind: asumu, whats the difference between xephyr and xnest
14:57 (quit) anRch: Read error: Connection reset by peer
14:58 (quit) mye: Quit: mye
14:58 asumu: jonrafkind: Xephyr supports additional features AFAIK.
14:59 jonrafkind: mmk
15:01 (join) nilyaK
15:06 bartbes: Xephyr is the more up-to-date one
15:06 (join) anRch
15:06 bartbes: supposedly
15:06 bartbes: I wish Xephyr did GLX, though
15:17 (join) Blkt
15:17 (quit) anRch: Quit: anRch
15:18 (quit) acarrico: Ping timeout: 264 seconds
15:18 Blkt: good evening everyone
15:19 asumu: Blkt: good evening
15:20 Blkt: :)
15:30 (join) deu5
15:33 (join) acarrico
15:35 (quit) mizu_no_oto: Quit: ["Textual IRC Client: www.textualapp.com"]
15:46 (quit) nilyaK: Ping timeout: 268 seconds
15:51 samth: jeapostrophe: 'raco pkg update' should probably not run 'raco setup' when there are no updates
15:51 jeapostrophe: yes
15:51 samth: jeapostrophe: also, how do you want bug reports like that for P2? irc, email, bugs, smoke signals?
15:52 samth: carrier pidgeon?
15:52 jeapostrophe: email is convenient. prs is too much
15:52 samth: ok
15:52 jeapostrophe: also, weren't you going to send a longer design issue email?
15:55 samth: jeapostrophe: yes, thanks for reminding me
15:55 samth: started on that but didn't finish
15:55 samth: also on the setup issue, you might want to run setup with --no-user
15:56 samth: esp. on 'install'
15:56 asumu: samth: #lang carrier-pidgeon
15:56 jeapostrophe: why is that?
15:56 asumu: First #%module-begin calls out to Google's carrier pidgeon API...
15:57 samth: jeapostrophe: just to avoid doing a bunch of unneeded work
15:57 jeapostrophe: but if the user code is already built, it's just comparing timestamps
16:10 (join) mizu_no_oto
16:14 (quit) dsantiago: Quit: Computer has gone to sleep.
16:29 (quit) chrxn: Remote host closed the connection
16:32 (join) chrxn
16:33 samth: jeapostrophe: design issue sent
16:34 jeapostrophe: i'll read it
16:34 samth: jeapostrophe: also, this blog post (which you may have already seen) is interested reading: http://www.yesodweb.com/blog/2012/11/solving-cabal-hell
16:35 samth: jeapostrophe: also, is there an updated location for the planet2 docs?
16:35 jeapostrophe: i update it every time i make a change to the docs and will until pre. has them
16:36 samth: the same place from the original mail?
16:37 jeapostrophe: ya
16:38 jeapostrophe: re the large design point. my second system from august/july 2011 had that ability totally within rackett
16:38 jeapostrophe: it could be layered atop planet2 and maybe after a bit of development we could find a nicer way to integrate it
16:39 jeapostrophe: in any case, i think the idea is good and would like to support it, but don't think the layer that is the current planet2 would need to change and so i don't want to block planet2 not being beta by it
16:39 jeapostrophe: (my goal is that planet2 replaces planet1 and planet3 is an optional layer atop planet2, where planet3 does stuff like localized deps.)
16:40 (join) mye
16:43 samth: jeapostrophe: the part that would be important in what's in planet2 is specifying the *source* to get dependencies from in the metadata file
16:45 jeapostrophe: something bad about that is that it disallows taking over abandonned code without changing third parties
16:45 jeapostrophe: or having local, private forks
16:45 jeapostrophe: etc
16:48 (join) dsantiago
16:52 (quit) acarrico: Ping timeout: 264 seconds
16:54 samth: jeapostrophe: you don't want to always specify the source
16:54 samth: or even usually specify it
16:54 samth: but you want to be able to specify it
16:54 samth: jeapostrophe: also, i get lots of errors from the PNS web interface when i click "details" on various forms
16:55 jeapostrophe: on the upload form there is a "details" link that will eventually go to the racket documentation, but it isn't on there yet, so the link is dead
16:55 jeapostrophe: that's one error
16:56 jeapostrophe: but there are "lots"?
16:57 samth: the same link appears on a couple forms
16:57 samth: another issue i just ran into
16:57 samth: i ran 'raco pkg install --link gcstats'
16:57 samth: and that creates a collection root link
16:58 samth: but since there's no gcstats/gcstats directory, the appropriate `require` fails
16:58 samth: jeapostrophe: ^
16:59 jeapostrophe: i don't understand what you think the error is
16:59 jeapostrophe: packages are collection roots in planet2
17:00 samth: so i need to create another level of directory hierarchy here: https://github.com/samth/gcstats ?
17:00 (quit) MayDaniel: Read error: Connection reset by peer
17:01 jeapostrophe: yes
17:01 (quit) dented42: Quit: Computer has gone to sleep.
17:01 samth: ah
17:01 samth: that's somewhat unfortunate
17:01 samth: could there be a way to specify that it's a single-collection package?
17:04 jeapostrophe: i thought about that, but couldn't think of a good way to specify what the name of the collection would be without having planet2 details inside of racket... it makes it slightly "internally" linked
17:06 samth: jeapostrophe: it could be part of the metadata.rktd file
17:06 samth: or, better, it could just be the name of the package
17:06 jeapostrophe: that's what i mean by internal linking
17:07 jeapostrophe: now code does "(require package-name/file)" rather than the package name never appearing in racket code
17:08 (join) acarrico
17:08 samth: jeapostrophe: i would instead see it as specifying that these names are the same
17:08 samth: you can always create another package that provides the same collection
17:09 jeapostrophe: but you can't have two packages with different names that are the same single-collection package
17:09 jeapostrophe: so then it goes in the metadata
17:09 jeapostrophe: and then when i'm looking for conflicts... i have to read all the metadata files
17:09 jeapostrophe: it's messy
17:11 samth: so then don't allow single collection packages to have the collection have a different name than the package
17:11 samth: jeapostrophe: also, it would be nice to allow '-' in tag names
17:11 jeapostrophe: but i would want that, so that you could take over someone's package
17:11 jeapostrophe: samth: i'll do the - thing sortly
17:12 samth: jeapostrophe: you could take over someone's package, but not by using a single-collection package
17:13 samth: jeapostrophe: also, what does the red * mean on the package list page?
17:13 jeapostrophe: it was updated within the last 48 hours
17:14 samth: ah, cool
17:15 (join) dented42
17:21 (quit) mye: Quit: mye
17:25 (join) mye
17:28 (join) Kaylin
17:32 (quit) mizu_no_oto: Quit: Computer has gone to sleep.
17:45 (quit) pavelpenev: Remote host closed the connection
17:48 (join) pavelpenev
17:48 (quit) pavelpenev: Remote host closed the connection
17:51 (join) pavelpenev
17:58 (join) bjz
18:02 (quit) dented42: Quit: Computer has gone to sleep.
18:16 (quit) mye: Quit: mye
18:20 (quit) mithos28: *.net *.split
18:20 (quit) Draggor: *.net *.split
18:20 (quit) jschuster: *.net *.split
18:20 (quit) otterdam: *.net *.split
18:29 (join) mithos28
18:29 (join) Draggor
18:29 (join) jschuster
18:29 (join) otterdam
18:31 (join) mammoth
18:31 mammoth: hello guys
18:31 asumu: mammoth: hi
18:32 mammoth: does anyone know how racket's immutable facilities compare to clojure?
18:32 mammoth: comparison of datatypes, multicore performance etc?
18:34 asumu: mammoth: are you specifically asking about immutable data structures or persistent ones?
18:35 asumu: Racket comes with most things you'd expect: vectors, hashtables, sets, lists, streams, and so on.
18:35 mammoth: I do mean immutable. That is how well it creates things like cheap copies, and lazy evaluation.
18:36 samth: mammoth: racket does not have as extensive a library of immutable data structures built in
18:36 samth: and none of them use multiple cores automatically
18:39 (quit) Shviller: Ping timeout: 246 seconds
18:40 (join) Shviller
18:40 mammoth: I am seriously split about using clojure vs racket. Racket has mutability, is easier to use, you are not stuck to JVM. However it's syntax is arhaic and has less immutable datatypes, as you pointed out. Clojure has sleaker syntax and better performance. However you are stuck to JVM, no mutability and Rick Hickey, while a brilliant man, strikes me as a sort of a dictator
18:41 jonrafkind: lol archaic syntax..
18:41 samth: mammoth: i think the syntaxes are pretty similar
18:41 (nick) scott__ -> scott_
18:41 jonrafkind: what does "stuck to the jvm" mean, its not like racket is not stuck to the racket vm
18:41 (join) scott_
18:42 mammoth: yes but JVM is a poor fit to lisp like language since e.g. it has small stack.
18:42 (quit) jeapostrophe: Ping timeout: 248 seconds
18:42 mammoth: syntaxes are pretty similar but clojure is 25% more readable and a bit cleaned up.
18:43 scott_: clojure doesn't have tail call elimination, you have to use explicit loop/recur
18:43 mammoth: scott_: hence "poor fit"
18:44 (join) dented42
18:45 mammoth: I don't want to step on anyone's toes, that's just how I see it at this point.
18:46 jonrafkind: do you have any real examples of needing tail call elimination?
18:47 mammoth: not really
18:47 asumu: If you're writing an application that very specifically needs a performant, persistent, immutable data structure (e.g., persistent vectors) then you'd be better off with Clojure or using Racket but writing your own persistent vector library.
18:47 jonrafkind: but you still think you need it?
18:47 scott_: there's a lot of features you don't necessarily need, but I think that makes functional programming easier
18:47 bremner: jonrafkind: I certainly have examples the blow the default stack on the JVM
18:47 asumu: But unless you have a specific need for a certain data structure, I suggest trying Racket.
18:48 jonrafkind: bremner, ok but the question is do you really need the recursive version vs just making it an explicit loop
18:48 bremner: of course, clojure has it's own explicit tail recursion thing
18:48 jonrafkind: even with tail call elimination you have to make an explicit accumulator sometimes, which is just as annoying as making an explicit loop
18:49 (join) initWithStyle
18:51 initWithStyle: Is there any way to get drRacket to display fonts in a higher resolution for the new retina macbook pros?
18:51 samth: jonrafkind: http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html
18:51 jonrafkind: that is the worst example ever
18:51 asumu: initWithStyle: Not yet, but it's a known bug.
18:51 initWithStyle: ok, thanks
18:52 jonrafkind: the other bad example is the one matthias uses about lists
18:52 samth: jonrafkind: i'll be sure to let guy and matthias know your feelings
18:53 (quit) dented42: Quit: Computer has gone to sleep.
18:54 jonrafkind: ok, let me know if they can come up with better examples
18:56 (quit) initWithStyle: Ping timeout: 245 seconds
19:00 (join) dented42
19:00 (join) jeapostrophe
19:00 (quit) jeapostrophe: Changing host
19:00 (join) jeapostrophe
19:00 (join) DT``
19:01 (quit) dsantiago: Quit: Computer has gone to sleep.
19:03 (quit) DT`: Ping timeout: 246 seconds
19:06 (quit) Kaylin: Read error: Connection reset by peer
19:20 (join) Fare
19:29 mammoth: is there any plans to close the gap with datastructures in racket?
19:29 samth: mammoth: yes
19:30 mammoth: and multicore thing?
19:30 samth: for example, see https://github.com/takikawa/tr-pfds
19:30 samth: yes, see places and futures in Racket
19:31 mammoth: thanks
19:32 mammoth: another annoyance with racket is that it is not one language but rather group of languages which is anoying. I believe I complained already about drawing libraries not being supported in typed racket.
19:34 mammoth: I see why you made it that way, but it serously fragments the language. Lisp is enough fragmented as it is.
19:35 (quit) masm: Quit: Leaving.
19:37 (quit) jonrafkind: Ping timeout: 265 seconds
19:42 dyoo: I spent all day debugging an rb tree.  And it's still broken.  Why is programming so hard?  :)
19:42 chandler: Because your type system is not expressive enough?
19:42 chandler: If it was, you'd have spent all day trying to get it to typecheck. :-)
19:43 dyoo: :)
19:43 asumu: mammoth: I don't really see that as a problem in practice. Say Typed Racket was the only language. Then tons of people would stop using Racket because it's typed. Ditto if we didn't have Typed Racket.
19:43 mammoth: asumu: Yes but can you get all relevant stuff work on both?
19:43 dyoo: no such luck: purely semantic issue on my end.  My rbtree is not balancing.
19:44 mammoth: asumu: since typed is more rigid, should every lib be made for it
19:44 mammoth: ?
19:44 mammoth: asumu: so it would work on both?
19:45 asumu: mammoth: There are more than 500k lines of code in the Racket standard libraries, so making them all work with a type system all at once is pretty hard.
19:45 chandler: dyoo: Oh, so you need dependent types *and* a theorem prover. :-)
19:45 asumu: (not that we aren't working on it ;))
19:45 dyoo: uh, yeah. that's my problem right there…  *sigh*  Ok, I'm having dinner, then will take a fresh look at this again and pull out CLRS
19:46 asumu: Also, maybe Typed Racket was a bad example. How could Scribble not be a separate language?
19:46 chandler: dyoo: Sorry, that was tongue-in-cheek.
19:47 dyoo: no problem or offense taken!  I'm just slightly despondent because programming is hard.  :)
19:47 (quit) scott_: Quit: Leaving
19:47 dyoo: talk to you later!
19:47 (quit) dyoo: Quit: dyoo
19:47 jaimef: I love this racket
19:47 mammoth: asumu: maybe not all but I found it rather annoying that it doesn't have, say drawing.
19:48 asumu: mammoth: racket/draw is not trivial to support because it's object-oriented. This should change in the future though.
19:49 asumu: In the meantime, you could just write a module around racket/draw and export that to TR if you really need it there.
19:51 (quit) snorble_: Ping timeout: 264 seconds
19:51 mammoth: asumu: can't typed racket be made optionally dynamic, so it can suport all that stuff? Please don't get annoyed with me, I am just trying to show you how this thing looks like from user/adopter perspective.
19:51 asumu: mammoth: if it's optionally dynamic it's just Racket though.
19:51 chandler: What do you mean by "optionally dynamic" that's different than how it is now?
19:52 asumu: Note that you can already import libraries from untyped code as long as there's a type for it.
19:52 asumu: mammoth: also, if my tone made me sound annoyed, I apologize. IRC doesn't do a good job with tone. :)
19:53 chandler: asumu: I think the guide could use a few examples of that, unless there's one I can't find at the moment.
19:53 mammoth: asumu: what I would really want would be racket with type hinting, but it is obvious that this can never be. You have a very friedly community, though :)
19:54 asumu: chandler: the TR Reference does provide an example for `require/typed`, but you're right that there really ought to be a guide example.
19:55 mammoth: seriously, though. You guys are awesome even if I have some problems with the language
19:55 chandler: asumu: Oh, there it is.
19:56 (join) dsantiago
19:57 asumu: mammoth: Thanks, and we also take feedback seriously so it's good to hear criticism.
19:58 mammoth: asumu: basically I love LISP as an idea, but evey one that I encountered so far has some fatal flaw which prevents me from commiting seriously. Racket's seems to be multiple languages thing. Which is a shambe because I WANT to use this stuff.
19:59 mammoth: *every
19:59 mammoth: *shame
20:00 mammoth: C# and Java are crappy languages but they are streamlined as hell and have less self-imposed flaws.
20:00 (join) jonrafkind
20:01 chandler: I don't see how the "multiple languages thing" is a problem if you're just using Racket.
20:01 chandler: Can you elaborate?
20:02 mammoth: chandler: I am used to some degree of static typing (thought I like it to be optional)
20:02 mammoth: maybe I am strange.
20:03 mammoth: but whatever. Maybe I shoud just write a wrapper for racket draw and quit complaining :)
20:03 mammoth: thanks for bearing with me :)
20:04 chandler: It's not strange at all. I think (and samth et al can feel free to correct me) Typed Racket is still a work in progress to some degree, and clearly not everything has been typed yet.
20:04 chandler: Personally, I find that contract checking at module boundaries helps a *lot* in plain Racket.
20:05 mammoth: still performance is kind of a problem.
20:05 chandler: Depends on what you're comparing it to, I guess.
20:05 mammoth: for plain racket I mean
20:06 mammoth: another reason for types
20:07 chandler: Depends on what you're doing. I don't think we'd get any performance benefit out of it here.
20:07 (join) Kaylin
20:08 chandler: (I would like some way to disable contract checking for our modules, so I can deploy with contract checking turned off for some nontrivial contracts.)
20:11 (quit) jsj: Ping timeout: 260 seconds
20:14 jaimef: is racket used in production by anyone?
20:15 chandler: Yes.
20:15 jaimef: webservices?
20:16 chandler: I'm not using it for that. I'm pretty sure neilv is, though he's not here at the moment.
20:18 (quit) dented42: Quit: Computer has gone to sleep.
20:20 (join) dented42
20:22 Fare: mammoth, what's wrong with Racket?
20:22 Fare: (according to you)
20:23 Fare: chandler, the goal of typed racket is NOT to ever get "everything typed"
20:25 chandler: Fare: Sorry, that was bad wording on my part.
20:25 chandler: I meant as far as having typed interfaces for modules like "racket/draw".
20:25 Fare: oh, ok.
20:26 chandler: (Which mammoth was asking about specifically.)
20:26 Fare: Also interesting will be when it can type fixnums.
20:39 noam: Question: How much memory does one 'place' consume using Racket's places? are they cheap similarly to go-routines in Go in that regard? And does it make sense to create big amounts of places?
20:41 chandler: They're not cheap, and it doesn't make sense to create a lot of them.
20:41 chandler: Places are basically separate VMs, so there's quite a bit of overhead.
20:41 asumu: My guess is threads in Racket are closer.
20:41 chandler: Racket threads are cheap, user-level threads that you can create many of, though they all run within a single OS thread.
20:42 noam: i see
20:42 noam: had too much high hopes
20:43 bremner: fwiw, I found racket futures more robus than the equivalent in clojure in some simple tests.
20:43 bremner: robust even
20:46 (quit) dented42: Quit: Computer has gone to sleep.
20:46 Shambles_: noam: I'm not sure what hopes were dashed, but I'm pretty sure the problem isn't Racket's concurrency support.  Some combination of threads ('green threads'), futures (futures/promises, 'real' threads), and places (message-passing 'real' threads) aught to solve your problem.
20:48 Shambles_: noam: If you want to spread out processing to multiple cores you probably want places.  If you're trying to avoid blocking for long periods on I/O you probably want threads.  I'm not sure there's any other use for some flavor of concurrency.  Having large numbers of real/fake threads just for bragging rights isn't something I've ever understood.
20:51 noam: Hmm I need to learn about each of them some more I guess to see what I want. For starters: are futures always better then threads since they can run in parallel, or are sometimes threads better?
20:52 Shambles_: noam: "thread" is something of a vague concept.  In practice multiple threads may run on the same core by 'chopping up' the work into smaller pieces and swapping between doing them rapidly, which is exactly how multitasking worked when we all just had a single core processor.
20:52 Shambles_: noam: It's also possible for threads to be run on separate cores.
20:53 asumu: noam: threads are more general. Futures can block on some kinds of computations. It really depends on if you want concurrency, parallelism, or both.
20:53 noam: racket threads? from the docs i understood they run only on a single core
20:54 noam: (or just from concurrency in other words)
20:54 Shambles_: noam: Most people that are thread-obsessed seem to want everything to act like Erlang.  Erlang's threads are "green threads", the kind that run on the same core.  So when they brag about having written a Hello World app that runs *90,000 threads* /on one machine with only 1GB RAM, it's really not that impressive (or practical).
20:54 Blkt: good night everyone
20:54 (quit) Blkt: Remote host closed the connection
20:55 asumu: noam: also, the Guide is fairly clear about futures vs. threads http://pre.racket-lang.org/docs/html/guide/performance.html?q=future#(part._effective-futures)
20:56 Shambles_: noam: Racket has both kinds.  The "thread" module has green/fake mulithreading that runs on one core.  This is sufficient for breaking up long I/O tasks.  Both "futures" and "places" are real multithreading that runs on separate cores.
20:57 Shambles_: noam: If you're trying to not have your program 'hang' when reading/writing a big file or something, use what Racket calls threads.  Racket futures are like most languages, and will work well with a functional design, but if you start involving mutation, they can have race conditions.  Racket places can't have race conditions (in the normal sense of the word).
20:58 Shambles_: noam: Places restrict what you can pass in the messages sent to a place to being immutable.  That's how they differ from futures.
20:59 (join) dented42
20:59 noam: alright
21:02 Shambles_: noam: If you want to spawn some god awful number of threads for Erlang-style bragging rights Racket threads is what you want.  If you're going to use real multithreading you shouldn't spawn many more threads than you have cores.  If memory serves the ideal number tends to be 1 or 2 more (real/kernel) threads than cores.
21:03 noam: the thing about running many kinds of small tasks is that you don't have to decide how to divide the work between them, unlike say places that you don't want to have too many of them so you want to limit yourself. but i guess threads/futures are the tools for this kind of thing
21:04 Shambles_: noam: The reason is a real/kernel thread's stack takes up a fair amount of RAM, so when you start spawning them, it uses up memory rapidly.  It also causes increased context switching.  That slows everything down, since swapping kernel threads in and out of a core (because you don't have enough cores for each to have their own) takes time.
21:07 Shambles_: noam: I'm skeptical that a program is well designed when you don't think about how to divide up the work, but yes, real/fake threads can allow you to avoid making that decision.  If the thing you' re trying to avoid thinking about is I/O, you don't need, or want, real threads.  Fake threads tend to have less overall overhead (use less RAM and waste less time context switching).
21:07 noam: what i have in mind is a system with 1 OS thread per core that runs many "small threads" on top of each OS thread
21:07 Shambles_: noam: If the thing you're trying to avoid thinking about is processing... well, good luck with that.  Any solution that performs well is going to have to minimize communication between threads, which requires thinking about it.
21:08 noam: i'm not sure how that maps to racket features
21:08 Shambles_: You'd have several "place"s (~1 per core), each with several "thread"s.
21:09 Shambles_: Though admittedly I'm not sure what would require that kind of structure.
21:09 noam: that actually makes lots of sense now
21:09 (quit) Fare: Read error: Operation timed out
21:10 noam: me neither actually. i'm just trying to figure out how racket's concurrency/parallelism stuff compares to other languages
21:10 noam: also thanks for explaining so much stuff
21:12 Shambles_: noam: I think it's about the same.  The major flavors are: shared state concurrency (also known as "doing it wrong"), green threads / coroutines which are essentially generators (i.e. the procedure does a operation, returns, then gets called again and does another operation, returns...)...
21:13 Shambles_: noam: ... futures/promises/'declarative multithreading' which is essentially functions running asynchronously, and message-passing concurrency which is essentially a object running in a separate thread.
21:14 (quit) walter|r: Read error: Connection reset by peer
21:14 (quit) walter: Read error: Connection reset by peer
21:14 Shambles_: noam: Most languages either come with support for those things built-in, or have it as some sort of library.  So long as you avoid using shared state concurrency, and think about what you need to achieve to pick the right construct, it's just a matter of figuring out what they're calling it.
21:15 (join) walter
21:15 (join) walter|r
21:15 Shambles_: I forgot to list some of the other names for message passing concurrency.  "actor"s and "agent"s are common alternative names for it.  Racket is all that I know of that calls them "places"
21:16 noam: alright i might be back with more specific questions later
21:16 noam: thanks again
21:16 Shambles_: noam: Hope it helps.
21:23 (join) jackhammer2022
21:23 (join) Fare
21:26 Fare: can you move green threads between OS threads?
21:29 Shambles_: Fare: Someone else might correct me (hopefully, if I tell you wrong), but I suspect the answer is no, not with any pre-packaged functionality.  You can serialize /most/ things and pass them into a future or place, to cook your own solution, I guess.
21:30 Shambles_: Fare: One thing to keep in mind though, is when working with OS threads you aren't in (direct) control of the scheduling and core it ends up on.  All you can control is the priority, if you can control that, so, basically, there's probably not a good excuse to migrate green threads between kernel threads.
21:31 Fare: load balancing could be a good excuse
21:31 Fare: or doing work while one worker is busy
21:32 jaimef looks for network services written in λ to study
21:32 Shambles_: Fare: If the kernel isn't able to choose which core to run a thread on intelligently, all bets are off about the effects of moving work between OS threads.
21:32 jaimef: so is it m to n?
21:33 Fare: what if you trust the kernel, but you just don't trust your green threads to be supernice?
21:33 Shambles_: Fare: It's the kernel's job to do load balancing on the processor.  Things tend to go poorly when you try to 'outsmart' your kernel.  Your process doesn't have the information the kernel does to make good decisions, nor does it usually have the access to act on such information.
21:33 Fare: jaimef, that's what I was asking, basically.
21:34 Fare: no, not "outsmart" the kernel -- rather, schedule inactive threads on available workers rather than leave them waiting for "the" worker.
21:34 (quit) deu5: Quit: Leaving
21:35 jaimef: yeah we did that in netbsd for a long time before admitting it was hard to do properly
21:35 Shambles_: Fare: A green thread is very much like a generator.  It's, essentially, a procedure that does a little work, returns, then picks up where it left off and does a little more work before returning the next time it's called.  As far as the kernel is concerned, it's no different than calling any other procedure.  The kernel should be able to decide what core to run a (kernel) thread on, based on the load it's 'causing'.
21:35 Fare: my process knows that M green threads are alive. If I can't migrate threads, and they are all one one OS threads, I lose.
21:37 Shambles_: Fare: Since your program is in control of how many threads (green or otherwise) it's spawning, shouldn't it be able to avoid spawning more threads than it should?  And even if it doesn't, resulting in 'lopsided' loads, shouldn't your OS's kernel be able to move it to the core with the least load so overall the system stays fairly balanced?
21:38 Fare: Shambles_, it has spawned the correct number of threads; but as the load varies, it finds that they all are waiting on one OS thread
21:38 Fare: The OS isn't clever enough to move green threads
21:38 Shambles_: Fare: It doesn't have to be.
21:39 Fare: well, it currently is
21:40 Shambles_: Fare: Kernels are used to the situation where there are more threads (including processes, which are just threads with memory protection boundaries) than cores.  Thus it has to 'swap out' what's running on a core periodically, to try to keep things 'fair' (i.e. all processes of the same priority get roughly the same time to run on the processor).
21:41 Shambles_: Fare: So let's say one of your kernel threads starts using more processor time, because it spawned too many green threads, or suddenly those green threads are doing more work than they were before, or whatnot.  The next time your kernel thread (containing those green threads) gets a time slice to run on a core, it can change which core that thread runs on to one with a list of typically-lighter processes.
21:42 Fare: Shambles_, exactly -- but that supposes green threads can migrate -- so, can they?
21:43 Shambles_: Fare: Basically, it's a bad idea to try to do "somebody else"s job.  The kernel's job is spreading out the workload between cores, and enforcing security and quota limits.  It should know how to do those things.  If it does a bad job, all bets of doing it better in your program are off anyway, because it could cause nose goblins when running your program.
21:43 (quit) jackhammer2022: Read error: Connection reset by peer
21:43 (quit) jeapostrophe: Ping timeout: 276 seconds
21:43 Shambles_: Fare: No, it doesn't suppose green threads can migrate.  It supposes the kernel knows about how to spread a list of processes to round-robin between on the cores intelligently.  No green thread migrating necessary.
21:44 (join) ewemoa
21:44 Shambles_: Fare: Though if you absolutely insisted on migrating a green thread, one way to do it would be serialize what was going to run, and send it to a different place to run.  However, again, this assumes your places know about the load being placed on each core, which is something I suspect they have no way of knowing.
21:44 (join) jackhammer2022
21:45 Fare: Shambles_, you're talking about M:N kernel-supported threads. I'm talking about racket green threads and racket os threads, different thing.
21:45 Fare: and the M:N thing is bunk
21:45 Shambles_: Fare: No, no I'm not.
21:47 Shambles_: Fare: I'm only assuming the kernel supports traditional thread, not kernel threads /and/ green threads.  There are systems that support both, though what is meant by a 'green thread' can vary.  I could write a program to run on a Commodore 64 that supports 'green threads', and there isn't even exactly a 'kernel' on a C64.
21:48 Shambles_: Fare: The kernel doesn't have to know anything about green threads for green threads to work.  They're usually implemented the same way generators are.  If you've ever written a procedure that accepts a "where I left off" argument, or used a 'static' mutable variable, you have some idea of how green threads work.
21:49 Fare: Shambles_, we're talking past each other.
21:49 Shambles_: Fare: Environments that have M:N threads in kernel support usually (as far as I know) support them only for C, and the additional support amounts to using kernel level information to migrate the green threads around.  Actually, I'm not sure of any popular environments that still support M:N threading.  I think one of the BSD's does.
21:50 (join) dnolen
21:51 Shambles_: Fare: The short answer is, as far as I know, no, Racket is incapable of controlling a combination of its own kernel and green threads.  It trusts the programmer to spawn green threads intelligently, and trusts the kernel to schedule kernel threads fairly.
21:53 Shambles_: Fare: Since you can serialize most things in Racket, if you wanted to move work between kernel threads you could do so by sending it to a different "place", but I have no idea how you would know you need to do this.  Knowing this needed to be done would assume knowledge of the total load caused by the place, and the loads of all other cores, and what loads the other processes were causing on those cores.
21:54 Shambles_: Once you found a underutilized core you had a place running on, then you could send your green thread to that place.  Of course the malicious kernel might decide to move the place that /was/ running on that core to a different core, leaving the load imbalanced again.
21:54 Fare: You don't get it, do you?
21:55 Fare: I'm supposing that the kernel has 1:1 OS threads, just like it does on all modern OSes
21:55 Fare: so the kernel by assumption CANNOT move green threads
21:55 (quit) cataska: Quit: leaving
21:56 Fare: but the user runtime can
21:56 Fare: and yes, the OS threads can be moved by the kernel, but we don't F*ING care.
21:56 Shambles_: Fare: Possibly not.  I understand the notion that a single thread can vary in its load.  I understand there are multiple cores.  I understand you can (theoretically) send a green thread between kernel threads.  However, I don't understand why you don't trust the kernel to adjust the list of processes it's usually cycling through on a core when the load of a particular process changes such that the load is imbalanced.  That's
21:56 Fare: the kernel is clever, so when he sees both threads are active, and one core is idle, it'll move its OS thread
21:57 Fare: the only question is: KEEP THE DAMN OS THREADS ACTIVE.
21:57 Fare: and relatively balanced.
21:57 Shambles_: Fare: But you can't force the OS threads to stay active.  That's the kernel's decision.
21:57 Fare: so we don't have some green threads starved while others are idle
21:57 Fare: YES YOU CAN
21:57 Fare: just give it work
21:58 Fare: if the kernel has nothing else to do, it will activate the thread
21:58 Fare: the kernel is your friend, not your enemy
21:58 Shambles_: Fare: As for keeping them balanced, you either need to avoid spawning more (or heavier) threads on one "place" than another, or migrate them via seralizing.  However, the issue with migrating via serializing is knowing when to do it.  You'd need to know when your green threads were getting 'heavier' than you expected.
21:59 Fare: exactly.
22:00 (join) mizu_no_oto
22:00 Shambles_: Fare: Kernel level support for green threads is uncommon, and generally limited to a C interface.  Anything interpreted/bytecode-compiled is unlikely to be able to use it.  I guess some languages might allow you to ask things like "what's this thread's current load", and you could monitor all your 'places' and try to shuffle green threads manually that way, but I'd be surprised if anybody bothers.
22:01 (join) cataska
22:01 Shambles_: I remember Linux was considering it, and if memory serves, it got shot down.  I'm also pretty sure one of the distros had a patch that added it, and I know /one/ of the BSD's had M:N threading, but was debating removing it.
22:02 Fare: with enforced linear types / regions, you could move threads to other places without any copying, by just changing the owner.
22:02 Fare: Shambles_, a lot of people bother, at the granularity of machines in distributed systems.
22:02 Fare: Shambles_, variants of the same algorithms could be recycled for green threads in a process
22:03 (join) scott_
22:03 (quit) scott_: Changing host
22:03 (join) scott_
22:03 Shambles_: Fare: I'm not sure fancy type systems are that important here.  If all the data involved is immutable or converted to a immutable representation it can be passed about.  The big problem is knowing when the green thread shuffling needs to occur.  Ideally the kernel would tell you, but unless it knows about how the innards of your interpreter work, it'd be hard for it to do it itself.
22:04 Fare: fancy type systems ensure you can pass out without copy and without check.
22:04 Fare: knowing when the shuffling needs occur is trivial in many cases.
22:05 Fare: just gather statistics.
22:05 (quit) mizu_no_oto: Client Quit
22:05 Fare: and assume the future looks like the past.
22:05 Shambles_: Distributed computing and multithreading are worlds apart.  You can do distributed computing without any multithreading support in the kernel (though, admittedly, I can't think of any examples), but a system that supports multithreading has to have quite a bit added to support distributed computing.  You need to be able to serialize everything, syncronize everything, and pass it about over a (usually unreliable) network.
22:05 Fare: anyway
22:05 Shambles_: In distributed computing you'd still need to do the copying.
22:06 Fare: I wonder if Redex is a good platform to experiment with a linear lisp
22:07 Shambles_: It also makes it extremely critical to have thought about all this stuff ahead of time.  If you think lock contention is bad, just wait until you have to synchronize over a network.  It's really, really important to try to divide work up so communication is minimized, and that should mean that the workloads are pretty predictable, thus not needing migration typically.
22:19 Fare: yup
22:26 Shambles_: I looked up what OS's support M:N threading.  For now, it's just Windows 7.  Both FreeBSD and NetBSD used to support it, then removed support.
22:28 Shambles_: There's also a abandoned patch for Linux (it was never accepted as a part of the standard Linux kernel) http://moais.imag.fr/membres/vincent.danjean/linux-activations.html
22:28 Shambles_: It's not likely something you'll need in the wild.
22:29 (quit) nathanpc: Quit: Computer has gone to sleep.
22:29 (quit) mithos28: Quit: mithos28
22:30 (join) mithos28
22:30 (quit) dented42: Ping timeout: 260 seconds
22:32 (join) dented42
22:36 (quit) dented42: Ping timeout: 264 seconds
22:50 (join) mizu_no_oto
22:51 (quit) mizu_no_oto: Client Quit
22:53 Shambles_: And apparently it's being abandoned in Windows 8: http://social.msdn.microsoft.com/Forums/en-US/parallelcppnative/thread/afee813b-0dd9-498c-98c1-c996169099f6
22:53 rudybot: http://tinyurl.com/a799hbe
22:54 Shambles_: I guess there's no widely available OS left where the kernel will give you much help in knowing when to migrate a green thread.
22:58 jonrafkind: their forum is so hard to read.. would it kill them to hire a good web designer
22:59 Shambles_: I think their web designers are busy redesigning their user interfaces to look like a mashup of Windows 3.0 and a website, judging from Windows 8.
23:00 jonrafkind: i hope the exiting of the top windows8 guy signals the beginning of the end for M$
23:02 Kaylin: *imagines having to answer linux questions on some distro she's never heard of for her father over the phone*
23:03 mithos28: Kaylin: Just remote desktop in
23:03 Shambles_: I used to want that.  I saw a lot of companies I liked go down because of the Wintel monopolies.  I don't really feel that way any more.  It's not that they're a lot nicer now, it's just that it wouldn't do any good.  There's not much left to save.  MS dieing now, or at least becoming relatively unimportant like IBM's fall from grace, wouldn't bring back Commodore, or NeXT (though they kind of live on in Apple), or businesses
23:03 offby1: who isn't the IT department for all their relatives?
23:03 offby1 doesn't see any raised hands
23:03 mithos28: me
23:03 jonrafkind: my dad is the IT guy
23:04 Shambles_: I'm pretty much IT for my family and their friends.
23:04 Shambles_: Unless Dad gets a wild hair and decides to Dell himself, like he did last time...
23:04 ozzloy: i got my mom that new chromebook
23:04 ozzloy: haven't had to do tech support since
23:05 Kaylin: pmuch, like last time I had to answer a question, I just gave him instructions on how to let me connect to his router so I could configure it.
23:05 ozzloy: though it's only been a week
23:05 ozzloy: heh, that's a good solution
23:06 Shambles_: I wonder if any of the new stuff is actually improving tech any.  Apparently Android is sort of object-capability-ish.  I'd still like to see that on the desktop, but I'm not sure it'll ever happen.
23:06 mithos28: Apple is trying to make it happen
23:06 Shambles_: FreeBSD has it now, but I wonder if any programs will be written to use it.
23:07 mithos28: They are having issues because they don't have capabilities corresponding to what apps need
23:07 ozzloy: object-capability-ish?
23:07 mithos28: http://en.wikipedia.org/wiki/Capability-based_security
23:07 Shambles_: ozzloy: The really short, inadequate, version is "programs have permissions, not just users".  So if your program gets exploited, it can't do very much harm.
23:08 ozzloy: oh, so selinux
23:08 Shambles_: ozzloy: The fun bits are how it gets those permissions without annoying the living @#$% out of you, like Java programs asking permissions with popups do.
23:08 jonrafkind: i guess the next security revolution will be a vm per program
23:08 jonrafkind: where the vm is really light-weight
23:08 mithos28: Or NACL
23:09 jonrafkind: well thats basically what it is
23:09 jonrafkind: nacl would be great if other browsers supported it..
23:09 Shambles_: ozzloy: Not exactly.  The slightly longer but still inadequate version is a program has permissions it always starts with, called a "installation endowment", which does things like let it read its own files (e.g. levels in a video game), and it has permissions granted by "powerboxes" which are GUI elements built into the OS, like the file open dialog, which grant one time read/write access to something.
23:10 Shambles_: ozzloy: I think selinux just has the "always on" permission concept, but even that would be better than what we have now, where if I run a music player it can format my hard drive, because I can format my hard drive.
23:11 ozzloy: so dynamic set of permissions
23:12 Shambles_: ozzloy: Combination of static and dynamic permissions, per process, not just per user, yeah.
23:12 ozzloy: cool
23:13 ozzloy: jonrafkind, is that "M$" a bit tongue-in-cheek?
23:13 Shambles_: Very.  *Almost* makes things unexploitable.  You could still do some harm by breaking into a database server, since the database server has to be able to read the credit card numbers it stores.  Similarly, you could read/destroy stuff on a file server.  But all this stuff like web browser exploits would just stop.
23:13 Shambles_: Worst you could do with them is crash them.
23:13 mithos28: ozzloy: M$ is a standard acronym for microsoft
23:14 ozzloy: i don't like them either
23:14 ozzloy: but
23:15 jonrafkind: its just easier to type than microsoft
23:15 jonrafkind: also fuck you microsoft!
23:15 jonrafkind: i mean M$!
23:16 ozzloy: ok, ok
23:16 jonrafkind: but to be fair i like to say lunix too
23:16 jonrafkind: which apparently is the number 1 way to troll #python
23:16 Shambles_: :P
23:16 ozzloy: lunix?
23:17 Shambles_: You're doing it wrong.
23:17 Shambles_: You should complain about how significant whitespace makes it impossible to properly shotgun format your code.
23:17 jonrafkind: lunix and red hate
23:17 jonrafkind: Shambles_, :p i was kicked out of the channel for saying 'lunix' once
23:17 mithos28: jonrafkind: couldn't you just complain about a real problem in the language? Like that it is defined by the implementation
23:18 jonrafkind: yea but the point is they are uptight and have no sense of humor
23:18 Shambles_: jonrafkind: I :P at thee. ;)  Guess I've gotten old enough to complain about a lot of tech.  There's just some problems that are more like a good friend's bad habits, and there are some like a terrorist attaching a car bomb to my car.
23:18 Shambles_: jonrafkind: Which is another way of saying I'm biased.
23:19 (join) dented42
23:19 (join) mizu_no_oto
23:19 jonrafkind: actually most language channels on freenode are pretty terrible
23:19 jonrafkind: this is about the only reasonable one
23:19 offby1: largely due to my presence
23:19 ewemoa hears a trickle...or was that splash?
23:19 rudybot: and mine
23:19 ozzloy: hey
23:20 mithos28: rudybot: Who is the puppet master?
23:20 rudybot: mithos28: so I could write kick ass documentation and put in an invariant part saying "Obama is a puppet, wake up sheeple"?
23:20 ozzloy: has anyone here compiled racket on an ARM system, like for example the one in the new chromebook?
23:20 mithos28: ozzloy: Somone attempted it on the mailing list at some point IIRC
23:20 jonrafkind: last time i tried to compile racket for arm I got some compile error
23:20 jonrafkind: but that was.. ~2 years ago
23:20 ozzloy: ic
23:20 Shambles_: I guess I've had better luck here than elsewhere, though admittedly the Clojure people have been mostly nice.  The C++ channel tends to be a lot like the /reputation/ of the Lisp channel...
23:21 ozzloy: Shambles_, C++ channel is condescendling and unfriendly to newbies?
23:21 jonrafkind: Shambles_, have you ever been to #c?
23:21 asumu: ozzloy: there's a blog post about someone who got it working on a phone IIRC...
23:21 mithos28: in august someone tried to get it working on android
23:21 ozzloy: asumu, oh, wedekind?
23:21 Shambles_: Which I can live with, most of the time.  I try really hard to avoid C++.
23:21 asumu: ozzloy: yeah, him.
23:22 ozzloy: i used to follow his hornetseye project.  i was surprised to see him in the racket mailing list
23:22 ozzloy: i stopped following it about a month ago.  too high traffic
23:22 Shambles_: jonrafkind: I think so, years ago.  I actually didn't have much trouble learning C.  I'm not sure I can claim to have really ever learned C++.  I think, perhaps, I'm better off having tried not to learn most of it. :P
23:24 Shambles_: ozzloy: That's close.  More "is openly hostile and vicious to newbies".  I mean there's an example of where someone gave a Lisp noob code to delete all his files, so it's kind of a extreme example of 'unfriendly'. :P
23:24 Shambles_: ozzloy: Admittedly it doesn't seem to usually be that bad, but I haven't been back there in ages.
23:25 ozzloy: Shambles_, i've found #lisp to be quite friendly, though i know the reputation to be that of condescending assholes
23:25 ozzloy: (is this a pg-13 channel?)
23:25 offby1: not any more
23:26 jonrafkind: 13 in dog years
23:26 Shambles_: ozzloy: From what I read, the problem children on #lisp were fairly small in number, but quite ... noticeable, rather like our own Shen aficionado.
23:27 ozzloy: hey, whoever is in charge of the racketcon video playlist, it's in reverse order
23:27 ozzloy: Shambles_, oh that guy!
23:27 ozzloy: good times good times
23:27 jonrafkind: which playlist, the one from this topic?
23:27 jonrafkind: i think thats sam's hangout thing
23:27 ozzloy: jonrafkind, yes
23:27 jonrafkind: i made another set of videos
23:27 ozzloy: link?
23:28 jonrafkind: http://www.youtube.com/user/racketlang with better sound
23:28 ozzloy: "racket sux! shen is the best!"  "go to #shen then"  "no! i'll keep telling you how bad racket is and how great shen is!"
23:29 ozzloy: jonrafkind, thanks
23:29 jonrafkind: ive never seen anyone talk about shen in here..
23:29 Shambles_: I remember asking about the Realm of Racket book here recently.  It looks like it's not being canceled, and they even put up a video on the site recently.  I hope it comes out soon.
23:29 mithos28: jonrafkind: it was a couple of months ago
23:30 Shambles_: jonrafkind: You never saw the guy always harping on Racket's documentation, saying Shen was the best language ever, and they wanted to have Mark Tarver's man-babies.
23:30 jonrafkind: i missed out
23:30 ozzloy: babies with chest hair
23:30 ozzloy: and biceps
23:31 ozzloy: kind of disturbing babies, really
23:31 Shambles_: But they will be well documented disturbing babies! ;P
23:31 ozzloy: lulz
23:32 jonrafkind: oh shen is that crazy language with the absurd license
23:32 jonrafkind: i remember people talking about it on hn
23:33 ozzloy: "By ‘copyright holder‘ we understand Dr Mark Tarver, or, in the event of his decease, the committee appointed under the terms of his will to administer his intellectual estate."
23:33 ozzloy: i like this license already
23:34 Shambles_: I think the idea is kind of neat.  It's a Lisp, but the main unusual feature is having a dependent type system built in.  The syntax isn't horrifically offensive (to me anyway) like most stuff with fancy type systems, and the documentation appears to have been written by humans rather than alien mathematicians on LSD.
23:34 Shambles_: It still needs to be hosted on something with reasonable I/O facilities to be used for much though.
23:35 jonrafkind: ive had enough of dependant type systems from agda
23:36 Fare: What's the name of this trivial isomorphism of (terminating) expressions as (true) propositions, traces as proofs?
23:36 mithos28: curry-howard
23:36 Fare: uncurry-drawoh ?
23:36 Shambles_: I find only 3 type systems acceptable.  Dynamic type checking (because it's non-obnoxious), C-like type checking (because it's not too annoying, but helps generate speedy code), and whole-hog make-your-brains-explode dependent type checking.  I don't want some halfass "annoy the hell out of you but still allow you to have bugs" type system.
23:37 ozzloy: drawoh?  did you typo that name backwards, or is that an actual thign?
23:37 Fare: no, it's NOT curry-howard. Or maybe it is, but then an unusual variant.
23:37 mithos28: Shambles_: How do you feel about TR?
23:37 jonrafkind: Shambles_, if I can't statically type "hello world" within 5 seconds I will definitely give up on the language
23:38 Fare: expressions as types of traces? interesting.
23:38 Shambles_: mithos28: I haven't messed with it much, but what I saw of it it was more toward the C-like end than the Haskell make-me-froth-at-the-mouth style.  I might just not have gotten deep enough into it to get frothy though.
23:40 (join) jeapostrophe
23:40 (quit) jeapostrophe: Changing host
23:40 (join) jeapostrophe
23:40 Shambles_: Upsides it has over every Haskell experience I've had is the syntax is non-offensive, and the documentation was comprehensible by someone other than the person that wrote it (and perhaps alien mathematicians on LSD).
23:41 ozzloy: Shambles_, ever use forth, or some other concatenative language?
23:43 Shambles_: ozzloy: Yes.  Actually I like Forth-likes.  In general I do not like complex syntax.  Forth has one major problem though, IMO.  It's a pain to debug.  Usually when something goes wrong, you just get to see the mangled stack.  This is usually long after whatever caused the stack to get mangled.  It's less history-like than most other languages.
23:43 Shambles_: ozzloy: Of course what I really want is a mashup of Light Table's live evaluation and those time-machine debuggers. ;)
23:45 Shambles_: I really love the macro debugger in Racket.  Clojure needs something like that really bad.  It also proves that macros don't have to result in migranes, which would be news to anybody used to C++ template metaprogramming.
23:46 ozzloy: i've not used a concatenative language
23:46 mithos28: Shambles_: I'm not sure what macros you are using, but for me the macro debugger is unusable
23:46 ozzloy: i'm thinking i'll start with factor or forth
23:46 ozzloy: do you know either of those?
23:46 ozzloy: er... sorry
23:46 ozzloy: can you compare factor and forth?
23:46 Shambles_: mithos28: Nothing really fancy.  I like being able to watch it as it expands, and step back and forth through the expansion steps.
23:48 (quit) jeapostrophe: Ping timeout: 245 seconds
23:48 Shambles_: ozzloy: My first experience with a Forth-like was MUF, a obscure and ancient version used for progamming TinyMUCK MUCK's.  Then I messed around with writing a non-Turing-complete crappy little interpreter thing for use as a calculator in LSL (very unpleasant, because of LSL).  I've also messed around with Joy.
23:50 Shambles_: My impression of Factor is only from passing knoweledge, but it seems to be to Forth as Clojure is to Common Lisp.  Nice I/O facilities, very 'practical', with a focus on nice (rather Lisp-like) macros.  There's a lot of Forth's, so I don't know what to contrast it with.  I mean, Chuck Moore's latest Forth is ColorForth, which is probably not what you have in mind as another alternative.
23:50 Shambles_: Joy isn't very practical.  It's very 'clean', and minimal, without much in the way of I/O facilities standard, rather like early Scheme standards.
23:51 jonrafkind: did you see r7rs, i was kind of surprised it doesnt say anything about hash tables, or many other datastructures
23:52 offby1: maybe you were looking at the "small language
23:52 offby1: "
23:52 jonrafkind: yea, small
23:52 offby1: maybe a dingo ate your baby
23:52 jonrafkind: but who would use such a language? i mean it barely specifies anything
23:52 Shambles_: I've seen a draft of the language, not library, part, I think.  I know people have been angry since R5RS.  I'm not sure how to feel about it.
23:52 jonrafkind: i dont understand the point of these ultra minimal specifications
23:53 offby1: maybe jcowan would answer.
23:53 jonrafkind: is he omniscient?
23:53 offby1: well, he's on one of those them-thar committees
23:53 ozzloy: Shambles_, thanks!
23:54 jonrafkind: i was just making a joke about how hes not in the channel
23:54 ozzloy: Shambles_, that's the impression i got too
23:54 offby1: actually now that I think about it, he might indeed be omniscient
23:54 jonrafkind: thats a good skill to have
23:54 offby1: yep
23:54 jonrafkind: it would help when filling out your taxes
23:54 offby1: handy at the race track, e.g.
23:54 Shambles_: I'm not a big fan of huge languages.  I prefer the basic concepts to not be all that much more complicated than, say, C, and hopefully less of a minefield (e.g. sequence points).  C++ is a good example where the language bothers me by being both too big, and without particularly good excuses for being that way.  On the other hand, it really is awfully handy to have higher level data structures (Python convinced me of this), a
23:54 offby1: probably useful for dating.
23:55 offby1: Shambles_: you might look at "go"
23:55 jonrafkind: i wonder why an omniscient being would exist
23:55 jonrafkind: ill have to re-read dune book 4
23:55 ozzloy: Shambles_, i also like minimal languages
23:56 jonrafkind: also i didnt notice what was different between r7rs small and r5rs, but i guess i didnt do a very hard comparison
23:56 Shambles_: offby1: I've looked it it.  I tend to be more interested in odd, but practical, different ways of expressing computation.  For instance, Lucid and Prolog.  I haven't seen anything in Go that I feel like I miss from say, C or Python.
23:57 ozzloy: if i was omniscient, i would definitely apply it first to taxes
23:57 ozzloy: taxes? done.
23:58 Fare: Factor is pretty neat. Also, it's strongly typed as far as stack manipulation goes.
23:58 (quit) Nisstyre: Ping timeout: 252 seconds
23:58 Shambles_: jonrafkind: There's a lot of things.  I think now they're even trying to standardize a module system?  R7RS is, from what I can tell, trying to standardize 'real' Scheme, as in what Scheme implementations actually include so they can be used to do something other than process text files, as opposed to "the scheme we wish it was".
23:58 (quit) Fare: Quit: Leaving
23:58 jonrafkind: oh thats true, `library' is there now
23:59 jonrafkind: also there is still no syntax-case in r7rs
23:59 Shambles_: jonrafkind: And this upsets people that wish Scheme was more of a executable mathematical notation for programs, or something.  I'm not sure exactly where this desire comes from.  It's claimed that by doing what they've done in R6RS and later, it's making it too hard to implement, but most of the stuff they're adding are things you'd need anyway.
23:59 jonrafkind: right