01:49 (join) tcoppi_
01:54 (quit) tcoppi: *.net *.split
01:54 (quit) dnolen: Quit: dnolen
01:59 (quit) jonrafkind: Ping timeout: 240 seconds
02:16 (nick) tcoppi_ -> tcoppi
04:19 (join) appaaaa
04:20 (quit) appaaaa: Client Quit
04:26 (join) masm
05:26 (quit) hanDerPeder: Ping timeout: 252 seconds
05:28 (join) hanDerPeder
06:35 (join) MayDaniel
07:17 (quit) MayDaniel: 
07:21 (join) b-man_
08:43 (join) MayDaniel
09:19 (quit) b-man_: Remote host closed the connection
10:13 (quit) lisppaste: Remote host closed the connection
10:23 (join) lisppaste
10:47 (quit) MayDaniel: 
10:48 (join) MayDaniel
11:25 clklein: Is there a way to tell raco make to compile with whatever handlers are installed by requiring errortrace?
11:35 clklein: Maybe I need to use compiler/cm?
11:40 samth: clklein, there's some way to do this, but i don't remember it
11:42 clklein: samth: requiring errortrace then using managed-compile-zo seems to be working
11:50 (join) b-man_
12:04 (quit) stamourv: Ping timeout: 265 seconds
12:19 (join) stamourv
12:26 (join) jonrafkind
12:40 (join) mceier
12:46 clklein: jeapostrophe: I'm finally getting back to experimenting using tries in apply-reduction-relation* and friends.
12:48 clklein: You recommended starting with your trie planet package, right?
12:48 (join) MayDaniel_
12:49 (quit) MayDaniel: Ping timeout: 240 seconds
12:55 samth: stamourv, http://www.ripton.net/blog/?p=59 (re PyPy)
12:59 (join) anRch
13:01 stamourv: samth: "I mentioned that PyPy was the fastest Python implementation for most of my Project Euler programs, but that it was very slow for a few of them."
13:02 stamourv: Project Euler: it cooks, it cleans, and it's a benchmark suite!
13:03 stamourv: but seriously, it would be nice to see the results for a known benchmark suite
13:07 (nick) MayDaniel_ -> MayDaniel
13:09 Lajla: I must get back at that site.
13:09 Lajla: It was fun.
13:09 Lajla: I was like for 1 hour or so 'Yeah, I totally own this' got to problem ten, and then I was bored.
13:09 Lajla: I especially liked that one you could basically solve by (apply lcm (range 1 21))
13:45 (join) sstrickl
14:07 jeapostrophe: clklein: yes
14:39 clklein: Lajla: That program's even shorter in the click-wheel language.
14:39 samth: jonrafkind, how did you generate that changelog?
14:39 clklein: just three clicks (you have to click past the click-wheel language compiler and the DrRacket reimplementation)
14:39 samth: it seems really short
14:40 Lajla: clklein, isn't that on number 283892373292
14:40 Lajla: I always tend to get 283892373292 and 3 apart
14:41 (join) IznastY
14:41 Lajla: clklein,  but I have to admit, I was actually a good boy and wrote my own implementation of lcm and gcd for the sake of not having to cut myself and sleeping bad at night for acing that problem using Scheme's awesomenity
14:42 clklein: :)
14:45 Lajla: I still feel I am missing something though: http://codepad.org/7PXuLWoq
14:52 Lajla: clklein, assist me in my quaeste for needless elegance, and I will make it worth your while, not to mention you get 300 xp, 2 skill points and the divine sword of Qae'ilim
14:53 clklein: Lajla: Eh, no number theory for me today
14:53 (join) _ryanc_
14:54 clklein: jeapostrophe: Why did zo `indirect' go away?
14:54 jeapostrophe: it isn't needed and isn't really in the zo format
14:55 Lajla: clklein, =(
14:55 Lajla: You don't know a more elegant way than that to express lcm variadically in gcd?
14:55 Lajla: Not to mention a more cost effective way than recurse it?
14:57 clklein: jeapostrophe: But my program was using it! I guess that's what I get for having any code not in the tree :)
14:57 Lajla: AH
14:57 Lajla: I think I have him
14:57 jeapostrophe: i consider the zo format unstable until it actually works :)
14:58 clklein: jeapostrophe: Do you say it's not needed because you can just check at every node if you've been there before?
14:58 jeapostrophe: naw, i put a placeholder for every symtab entry and call make-reader-graph at the end
14:58 jeapostrophe: and store those placeholders in a vector during parsing
14:59 clklein: But what if you're given a zo expression and need to do something with it?
14:59 jeapostrophe: to create the cycles when there is a symtab ref
14:59 jeapostrophe: i don't follow?
14:59 (quit) anRch: Quit: anRch
15:01 clklein: When you're writing almost any function on bytecode expressions (e.g., an interpreter), you need to detect the cycles.
15:01 jeapostrophe: yup
15:01 jeapostrophe: but there can be cycles all over the place
15:01 clklein: Before you needed to check only the indirect nodes; now you need to check every node
15:01 Lajla: clklein, http://codepad.org/xVb3Di3l
15:01 jeapostrophe: no
15:01 Lajla: And without your help too.
15:01 jeapostrophe: you need to check on any data
15:01 jeapostrophe: and data can be almost anywhere
15:01 Lajla: The student surpasses the master.
15:01 Lajla: Not that you ever taught me anything, but hey.
15:02 clklein: oh, I guess that's true. My program doesn't handle any data so I didn't notice :)
15:03 clklein: jeapostrophe: The restriction that only `closure' expressions begin cycles is still in place, though, right?
15:04 jeapostrophe: in "compiled code" yes. but that's not true in general
15:04 clklein: Which code isn't "compiled code?"
15:04 jeapostrophe: for example...
15:05 jeapostrophe: an app may have compiled code in the rator or rand positions
15:05 jeapostrophe: any cycle in those will start with a closure (although you may not be able to tell in your program)
15:05 jeapostrophe: but the rand may be a piece of data
15:06 jeapostrophe: like the cyclic list #1=(1 2 . #1#)
15:06 (quit) MayDaniel: 
15:06 clklein: Yea, I'm only talking about code cycles.
15:06 jeapostrophe: then yes, code cycles start in closures
15:07 (part) IznastY
15:08 clklein: The #1=(1 2 . #1#) probably become some make-reader-graph expression, no?
15:08 jeapostrophe: in fact the entire parsed zo is given to make-reader-graph
15:08 jeapostrophe: all the cycles are handled the same way
15:11 clklein: But if I write a program containing #1=(1 2 . #1#), the bytecode contains a call to make-reader-graph, not a cycle in the bytecode?
15:12 jeapostrophe: the actual zo is: CPT_QUOTE CPT_BYTES #"#1=(1 2 . #1#)"
15:12 jeapostrophe: zo-parse will return: #1=(1 2 . #1#)
15:13 clklein: oh
15:13 clklein: that surprises me
15:13 jeapostrophe: me too
15:13 clklein: which zo-parse struct represents that madness?
15:14 jonrafkind: samth, went through the git log
15:14 jeapostrophe: nothing. just allow you to give any data and we'll figure out if it is cyclic and if we need to encode it that way
15:14 jonrafkind: starting from revision da9b718bf80c3e678e1d9372c521d512e0b91747
15:20 clklein: jeapostrophe: Can you show me a program be compiled into a cycle that doesn't begin with a closure?
15:20 clklein: s/be/that will be/
15:20 jeapostrophe: no such a program is not allowed
15:21 clklein: so why does the zo parser bother to support this? Because it needs to detect it anyway, and constructing a cyclic expression isn't really much more work?
15:21 jeapostrophe: yup. in fact this is simpler to implement
15:22 jeapostrophe: plus we didn't realize other cycles weren't allowed when we started :)
15:22 clklein: heh
15:22 (join) blake_johnson
15:22 clklein: OK, one more question.
15:22 jeapostrophe: blake_johnson: we were just talking about you
15:22 clklein: blake_johnson: You're jsut in time.
15:22 jonrafkind: blake_johnson, you got my money?
15:22 blake_johnson: what's up?
15:23 clklein: So as far as the zo parser is concerned, it's NOT true that cycles always start at closures?
15:24 jeapostrophe: when we parse, yes
15:24 jeapostrophe: when we write, no we enforce that
15:24 clklein: You can't get one from the compiler, but you could hack your own bytecode to make one, and the parser wouldn't mind.
15:24 jeapostrophe: yes, in fact our writer used to :)
15:25 clklein: Interesting. This poses similar verification challenges to JVM subroutines.
15:25 clklein: Subroutines execute in their caller's stack frame, which means that they need to be reverified at each call site.
15:26 clklein: (because their safety depends on what's in the caller's frame)
15:28 clklein: JVM verifiers sometimes do crazy polyvariant flow analyses to cope with this
15:28 jeapostrophe: yikes
15:29 clklein: If cycles only point to closures, then it doesn't matter which bytecode contexts refer to the cycle target
15:29 clklein: because a closure's safety is independent of its context (since it doesn't capture anything, and it can't reach beyond its own frame)
15:30 clklein: last time I checked, the verifier relied on this: when it ran into code it had already verified, it stopped verifying
15:30 clklein: I don't think this strategy is sound with your lenient reader
15:31 jeapostrophe: if you implemented the verifier in racket with our structs, you'd have to handle cycles everywhere, and error if they were in the wrong spots
15:31 clklein: right
15:32 clklein: also right while the verifier's still implemented in C :-)
15:33 jeapostrophe: well the current C code doesn't enforce the cycle starting thing... it just replaces other cycle refs with #f
15:34 jeapostrophe: we changed that to error in the reader
15:34 jeapostrophe: not pushed yet though
15:35 (quit) blake_johnson: Quit: blake_johnson
15:37 (quit) jonrafkind: Read error: Connection reset by peer
15:37 clklein: The relevant verifier code begins at line 12,761 of src/racket/src/eval.c with the comment "All values are definitely ok, except pre-closed closures. Such a closure can refer back to itself, so we use a flag to track cycles."
15:39 clklein: so this "except pre-closed closures" caveat isn't enough
15:39 (quit) Lajla: Read error: Connection reset by peer
15:40 (join) Lajla
15:40 (quit) b-man_: Ping timeout: 264 seconds
15:41 clklein: Actually, I'm a little confused. Maybe all values except pre-closed closures are OK, and the problem is that there can be cycles in other expression forms.
15:43 clklein: jeapostrophe: so you think the verifier should check every expression to see if it's seen it before, and if it has, reject the program if the expression isn't a closure?
15:43 jeapostrophe: no, the reader will do that (now)
15:43 clklein: (i.e., instead of making the reader reject these)
15:43 jeapostrophe: but in principle the verifier should
15:43 jeapostrophe: it would be too complicated to even make the reader support arbitrary cycles (at least in c)
15:44 clklein: Did the reader's behavior change during our conversation, or did I not understand before?
15:44 clklein: I thought you said I could hack together bytecode with arbitrary cycles, and the reader would happily find them and make-reader-graph them?
15:45 clklein: Oh, is your code not what constructs the verifier's input?
15:46 jeapostrophe: there are two readers
15:46 jeapostrophe: the racket reader allows arbitrary cycles
15:46 jeapostrophe: the c reader does not
15:46 jeapostrophe: there is no racket verifier
15:47 jeapostrophe: the c verifier relies on no other cycles being present
15:47 clklein: Ahhh, I forgot that there are two readers. Sorry!
15:48 clklein: Is the goal to eventually phase out the C one?
15:49 jeapostrophe: that's my goal. but it is a bit impractical with bootstrapping and machine compilation because the vm needs to run racket to run our reader
15:49 jeapostrophe: maybe it could do something like startup where we construct the zo using the c macros directly
15:49 jeapostrophe: and that is the "compiler"
15:51 clklein: ah
15:54 jeapostrophe: did you know that is how the start up code gets made?
15:55 jeapostrophe: http://git.racket-lang.org/plt/blob_plain/HEAD:/src/racket/src/startup.rktl
15:55 (notice) rudybot: http://tinyurl.com/34d4kk5
15:55 clklein: I think I've seen some very weird looking files that use this language
15:56 clklein: Oh, startup.inc is what I was remembering. What's that?
15:56 (join) jao
15:56 jeapostrophe: it gets turned into cstartup.inc which is a zo as a byte string
15:56 clklein: generated from startup.rktl?
15:56 jeapostrophe: :)
15:58 (join) jonrafkind
16:04 (join) grettke
16:07 (join) MayDaniel
16:11 clklein: jeapostrophe: The McCarthy Magical Scheme System is broken :(
16:12 clklein: compile: unbound identifier in module
16:12 clklein: setup-plt: error: during making for <planet>/jaymccarthy/mmss.plt/1/1 (The McCarthy Magical Scheme System)
16:13 jonrafkind: that package looks quite old..
16:14 clklein: Yea, I suppose. PLAI is still the only Planet package I've ever managed to install.
16:14 jonrafkind: haha
16:16 clklein: wait, maybe I'm an idiot. I may still get to 2 packages.
16:17 clklein: yay, I am an idiot.
16:20 jeapostrophe: it is VERY old
16:20 jeapostrophe: i don't support it
16:20 jonrafkind: there should be a way to get rid of packages from planet
16:20 jonrafkind: or at least mark them unsupported
16:21 jeapostrophe: yup
16:21 clklein: Don't get rid of it! It actually loads.
16:21 jeapostrophe: the marking as unsupported is what i'd want
16:22 clklein: ah
16:27 (quit) mceier: Quit: leaving
16:36 samth: stamourv, http://svn.plt-scheme.org/
16:37 stamourv: thanks
16:38 (part) grettke
16:59 (quit) chturne: Quit: Leaving
17:37 (quit) _ryanc_: Quit: Leaving
17:40 jonrafkind: hm, I thought using contracts might get me line numbers when a violation occurs but it doenst seem like it
17:40 jonrafkind: is there no way to get accurate line information when an error occurs?
17:54 samth: errortrace
17:56 jonrafkind: ah yes that works, i had to disable some other stuff
18:15 jonrafkind: sstrickl, the docs for make-contract vs make-flat-contract aren't explicit about the difference between the two
18:17 samth: tewk, your match problem is now fixed
18:17 sstrickl: jonrafkind: "These functions build simple higher-order contracts, chaperone contracts, and flat contracts, respectively."
18:17 sstrickl: re: make-contract, make-chaperone-contract, and make-flat-contract (in the current git master)
18:18 jonrafkind: that is meaningless to someone not of the Contract Order
18:18 sstrickl: I think it's up to you to know what those technical terms mean, which are elaborated on in other parts of the docs.
18:18 sstrickl: search for "flat contract", for example
18:18 jonrafkind: ffffff
18:18 sstrickl: now, to be fair, they should be using deftech if possible.
18:18 jonrafkind: well can you add a margin-note or something
18:18 sstrickl: And I agree with you on that, which should add the links you want.
18:18 sstrickl: So I'll look at doing that now.
18:19 jonrafkind: http://docs.racket-lang.org/guide/contract-func.html?q=flat-contracts&q=define/c&q=contracts#(tech._flat._named._contract)
18:19 (notice) rudybot: http://tinyurl.com/37jw4oc
18:19 jonrafkind: i assume this is the right link
18:19 sstrickl: http://docs.racket-lang.org/reference/Data-structure_Contracts.html?q=flat%20contract&q=flat-contracts&q=define/c&q=contracts#(tech._flat._contract)
18:19 (notice) rudybot: http://tinyurl.com/35srgly
18:19 sstrickl: is where the tech link I'm planning on adding would go
18:21 jonrafkind: hm, i read this paragraph and I dont understand what 'flat'ness is
18:21 jonrafkind: a flat value can be given to a predicate
18:21 jonrafkind: as opposed to what?
18:21 sstrickl: Read the link I sent you
18:22 sstrickl: It's one sentence, but it should be clearer.  named-flat-contract isn't important in this discussion of what flat contracts are.
18:22 jonrafkind: so a regular contract needs extra arguments?
18:22 jonrafkind: but a flat contract only needs the value in question?
18:23 sstrickl: A flat contract is guaranteed to only check first-order properties of the given value and return the original value (i.e. no wrapping or such occurs)
18:24 sstrickl: by first-order properties, I mean things that can be checked immediately on the given value, that do not require wrapping or such to check later (such as operations on mutable values or procedure application)
18:24 jonrafkind: ok, something like that should probably go in the docs
18:33 sstrickl: jonrafkind: to do it properly will be more than a simple one-line fix, so I'll add a bug in the system for me to write said section.
18:33 jonrafkind: ok
18:33 jonrafkind: is there a "better" place to learn about contracts? some paper?
18:34 sstrickl: For the difference between flat and higher-order contracts, there's always Findler/Felleisen 2002
18:34 sstrickl: jonrafkind: http://www.ccs.neu.edu/scheme/pubs/icfp2002-ff.pdf
18:52 jonrafkind: "we would like to thank icfp reviewer #3 for renewing our faith on the reviewing process" -- :p
19:01 samth: jeapostrophe, we need a name for the web server
19:01 samth: right now I have to refer to it as "the PLT web server" or "the Racket web server"
19:28 (quit) sstrickl: Quit: sstrickl
19:34 (join) Fare
19:51 (quit) MayDaniel: 
20:52 (quit) jonrafkind: Ping timeout: 245 seconds
23:44 (quit) masm: Quit: Leaving.