00:18 (join) jonrafkind
01:40 (quit) jao: Ping timeout: 265 seconds
01:42 (join) rbarraud_
01:42 (quit) rbarraud: Ping timeout: 255 seconds
02:39 (nick) lajla -> Lajla
03:15 (quit) jonrafkind: Ping timeout: 240 seconds
10:45 (topic) -: Racket -- http://racket-lang.org/ (logs at http://racket-lang.org/irc-logs/ )
10:45 (names) -: gabot eli mceier Lajla masm vu3rdd writer flintf objorn mao offby1 adadglgmut jay-mccarthy emma tonyg martinhex mario-goulart bremner alexsuraci clklein rudybot rapacity tewk_ klutometis tcoppi samth_away stamourv rotty callen lisppaste mattmight spacebat chandler @ChanServ
10:50 (quit) vu3rdd: Remote host closed the connection
10:53 (topic) -: Racket -- http://racket-lang.org/ (logs at http://racket-lang.org/irc-logs/ )
10:53 (names) -: gabot eli mceier Lajla masm writer flintf objorn mao offby1 adadglgmut jay-mccarthy emma tonyg martinhex mario-goulart bremner alexsuraci clklein rudybot rapacity tewk_ klutometis tcoppi samth_away stamourv rotty callen lisppaste mattmight spacebat chandler @ChanServ
10:53 (notice) hubbard.freenode.net: [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
11:18 (nick) samth_away -> samth
11:21 (join) carleastlund
11:29 (join) anRch
11:39 (join) sstrickl
11:40 jay-mccarthy: sstrickl: hey i just emailed you
11:40 sstrickl: jay-mccarthy: I thought I'd already started my IRC client, so your email alerted me to the fact that I somehow hadn't :)
11:40 jay-mccarthy: :)
11:40 jay-mccarthy: i'm only on page 7 so tell me if the answer is "keep reading"
11:41 jay-mccarthy: first, are/can object/class contracts be upper / low / tight bounds?
11:41 jay-mccarthy: so can the object in figure 8 provide other things that just don't have contracts?
11:42 jay-mccarthy: this is relevant in particular to code like in figure 7 where the server may offer other fields/methods and adding logging shouldn't hide those
11:42 sstrickl: one sec, let me pull up the paper so I can dereference
11:43 sstrickl: Oh, you can think of class contracts as "translucent", as opposed to our current function contracts, which are "opaque"
11:43 sstrickl: that is, they contract the portions they mention, and leave the rest alone.
11:44 sstrickl: so right, adding logging doesn't suddenly remove everything else a service might offer except for those things mentioned by the mixin/contract, for example.
11:44 sstrickl: (as asumu and I have discovered recently, there may be uses for "translucent" function contracts, and there might also be cases where people really do want opaque class contracts, though I don't offer them yet.)
11:44 jay-mccarthy: is possible to be opaque even if that isn't the default?
11:45 jay-mccarthy: ah
11:45 jay-mccarthy: okay
11:45 jay-mccarthy: next question
11:45 jay-mccarthy: it seems really weird that in Figure 8 and 5, the contract on 'this' is 'any/c'
11:46 jay-mccarthy: shouldn't that be another object contract, and in fig 8, shouldn't it be a "recursive" contract?
11:46 sstrickl: That just means there's no preconditions on the object when you're running empty? or push.
11:46 jay-mccarthy: it seems weird to bake in and rely on the fact that the contract won't get eval'd if the value doesn't get past 'send'
11:47 sstrickl: Well, you know it's an object of that class (or a subclass) just because you're putting the contract on a particular class.
11:47 sstrickl: Sure, you could always do an object contract and/or recursive contract there.
11:47 jay-mccarthy: that's what i think is weird
11:47 sstrickl: I mean, you're not restricted from it.
11:47 jay-mccarthy: any/c doesn't mean any in this case it means this-class/c
11:48 jay-mccarthy: i might just be saying i want an alias to any/c that has a different name.... it is just really jarring for me :)
11:48 sstrickl: Well, you can't even get to these particular implementations of the method(s) anyway without sending a method to an instance of this class.  The contracts don't affect all classes, they affect this class!
11:48 sstrickl: But fine, that seems reasonable :)
11:49 sstrickl: if we set up this/this% correctly for method contracts, you could do (is-a/c this%) :D
11:49 sstrickl: (well, I mean you could do that for ->dm, I think, in our current system, but... okay, I'm going too far afield.)
11:49 jay-mccarthy: interesting
11:49 sstrickl: Yes, I see what you're saying, and I'll think about it.
11:50 sstrickl: Seems reasonable :)
11:50 jay-mccarthy: i'm thinking particularly from a contracts as docs perspective
11:50 sstrickl: oh, of course, you could always just do (is-a/c pstack%) for that position
11:50 sstrickl: Sure.
11:50 sstrickl: for figure 5, for example
11:50 jay-mccarthy: seeing any/c there can give the wrong idea, as if the method can't rely on anything in particular about 'this' when really it automatically knows a lot
11:51 jay-mccarthy: but in the case of the range of a mixin, there is not already a name for the class you would is-a/c
11:51 sstrickl: Right.  I just saw that more as enumerating things that we want to know above and beyond what we know by this because of getting this particular method implementation, but you make a good point re: any/c possibly being misleading.
11:51 sstrickl: True.
11:52 jay-mccarthy: even though any/c amounts to being (is-a/c this%) [if that existed]
11:52 jay-mccarthy: nothing bad will happen, i understand, but it is nice to be verbose
11:52 sstrickl: I hear you.
11:52 jay-mccarthy: cool
11:52 jay-mccarthy: i will keep reading
11:53 sstrickl: Thanks for the feedback so far!
11:55 jay-mccarthy: one final thing i was thinking of this morning.... i really want a purely functional object system with convenient updating and contracts
11:56 jay-mccarthy: once you're done with RaTeX you should do that
11:58 clklein: RaTeX?
11:58 jay-mccarthy: It feels so wrong to use SLaTeX with Racket code, someone should do a search&replace
11:58 jay-mccarthy: \scheme{...} ugh
11:58 samth: just add \def\racket\scheme
11:58 jay-mccarthy: i'm not confident enough to use Scribble yet for all my papers
11:59 clklein: I'd go once step further and say it feels wrong to use LaTeX at all.
11:59 jay-mccarthy: :)
11:59 samth: when you have type system support in redex, call me :)
11:59 clklein: That seems pretty orthogonal to me.
12:00 samth: well, how else would you render math in scribble?
12:00 jay-mccarthy: i agree. if i convert fully to scribble i would intend to only render redex as well
12:01 samth: well, there's still a lot in latex that'll be hard to do in redex
12:02 jay-mccarthy: ya like type judgements, which i presume you were referring
12:02 clklein: Is it that hard to use LaTeX just to generate the figures?
12:02 samth: well, that, but also a lot of typesetting trickery
12:02 jay-mccarthy: redex is not kind to rendering infix math either
12:02 samth: well, it's hard to abstract over math in scribble files
12:03 jay-mccarthy: btw, neil wrote a great macro where you put some latex in @{...} and it gives it to latex (at compile time), gets the figure, and puts it in as an image
12:03 jay-mccarthy: works well with slideshow too
12:03 samth: put it on planet!
12:04 jay-mccarthy: i'll ping him about it
12:05 jay-mccarthy: sstrickl: one of the main reasons i've never used the class systems is because there were no good contracts. reading this paper makes me want to actually try
12:06 jay-mccarthy: [they were too fast before, this will be more at my pace]
12:14 sstrickl: jay-mccarthy: excellent!
12:17 jay-mccarthy: how are contracts for interfaces coming?
12:24 (join) jonrafkind
12:28 (quit) anRch: Quit: anRch
12:28 sstrickl: jay-mccarthy: currently I've been working on contracts for mutable values (as you've seen), but I already know how I plan on doing interface contracts, just haven't started coding that up yet.
12:28 jay-mccarthy: cool
12:29 jay-mccarthy: objects and mutable values seem related :)
12:29 sstrickl: they are, but since we controlled (at the Racket level) all the operations on objects, we could do proxying in a more ad-hoc fashion; now that we have actually struct chaperones/proxies, I hope to make the object contracts more efficient :)
12:30 jay-mccarthy nods
12:30 jay-mccarthy: have you seen anything you find cool from TGS?
12:31 sstrickl: expand TGS for me, as I'm not catching it at the moment?
12:31 jay-mccarthy: tokyo game show :)
12:31 sstrickl: Oh, haha, I haven't even looked at it yet. I am out of the loop.
12:31 sstrickl: Have you?
12:32 sstrickl: Is there enough bullet hell to satisfy Jay?
12:32 jay-mccarthy: Radiant Silvergun (Treasure shmup for the Saturn) is getting an HD XBLA release
12:32 jay-mccarthy: way exctied
12:32 jay-mccarthy: i have way too many shmups though
12:32 clklein: How long as the class system had interfaces?
12:33 jay-mccarthy: as long as i remember
12:33 sstrickl: clklein: thousands of years ago...
12:33 clklein: :)
12:34 sstrickl: well, at least since after class100, I dunno about whether class100 had them also
12:34 sstrickl: jay-mccarthy: Yeah, I saw other friends of mine mentioning RS also
12:34 clklein: I could have sworn that Robby told me we don't have them just a few months ago.
12:35 sstrickl: That's... odd.  Did you ask something more specific, so that perhaps there's some other part of your query he was answering 'no' to?
12:35 carleastlund: We've definitely had interfaces for years.
12:36 (join) anRch
12:36 clklein: I must be misremembering this conversation because I think he would have noticed that
12:36 carleastlund: They're used in DrScheme, so he must know about them.
12:37 clklein: Yea, I think he's read some of that code.
13:04 (quit) anRch: Quit: anRch
13:40 (join) vu3rdd
13:49 jonrafkind: if a class is instantiated like (new foo [parent blah]) then the foo class is guaranteed to have a `parent' field somewhere in its heirarchy, right?
13:49 jonrafkind: so if foo is declared as (lambda (%) (class % ...)) then I should be able to do (inherit-field parent) there?
13:50 sstrickl: not necessarily -- it could just be an initialization argument, not an init-field, so it may not exist after initialization is over.
13:50 jonrafkind: how can I get that field in my class? i want to pass a different argument to the subclass in (super-new)
13:50 jonrafkind: s/field/argument
13:51 jonrafkind: s/subclass/superclass :p
13:51 sstrickl: then declare an (init parent) in the mixin you're declaring, then pass a different value as the parent arg in super-new
13:51 jonrafkind: ok I tried (init-field parent) and it wasnt working
13:51 jonrafkind: so (init) and (init-field) are different, right?
13:51 sstrickl: well, that won't work if the field parent already exists
13:51 sstrickl: right
13:52 sstrickl: (init-field foo) says "take an initialization argument foo, and also define a field foo which is initialized with that argument"
13:52 sstrickl: short-hand for the slightly more complicated way of doing it otherwise.
14:24 (join) anRch
14:46 (quit) vu3rdd: Remote host closed the connection
14:48 (join) Fare
14:54 (join) b-man_
15:06 (join) tewk
15:06 (quit) tewk_: Ping timeout: 272 seconds
15:30 (quit) anRch: Quit: anRch
15:35 (quit) mceier: Quit: leaving
16:07 jonrafkind: can you add a horizontal-pane% to a canvas% ?
16:21 jay-mccarthy: sstrickl: big bug!
16:22 sstrickl: jay-mccarthy: hm?
16:24 jay-mccarthy: emailed
16:27 sstrickl: hmmm... I suppose you haven't been able to find a smaller case that triggers that yet, have you?
16:27 jay-mccarthy: i tried and it didn't happen
16:27 (join) blake_johnson
16:32 sstrickl: jay-mccarthy: well, I don't even see why #:flat? #t vs. not would even make a difference there, as that's an error from the contract itself -- it didn't receive a vector, it's not that it's returning void, so hmm, still thinking.
16:32 Fare: jay-mccarthy, hi! How are you?
16:32 jay-mccarthy: no the problem is that the flat projection is okay and the other projection replaces the value in the struct with a void
16:32 Fare: how's the family?
16:33 jay-mccarthy: Fare: great :) recent birthdays!
16:33 jay-mccarthy: blake_johnson: ping
16:33 blake_johnson: hello
16:34 jay-mccarthy: blake_johnson: can you try to just req the structs, create a real lam, run struct->list on it, and then try to match on it
16:34 blake_johnson: k
16:37 blake_johnson: seems to work fine
16:37 sstrickl: jay-mccarthy: The only way I can see to create the error I see there is to apply the projection to the void value; the #<void> being printed out is coming directly from the application of the projection to the value .
16:38 sstrickl: jay-mccarthy: it's not coming from any way from the result of the projection.
16:38 jay-mccarthy: why does #:flat? make it work?
16:38 jay-mccarthy: if we are actually putting in a void?
16:38 sstrickl: I'm not sure why, because the flat-contract version of vectorof runs the exact same check-vectorof on the value
16:39 blake_johnson: wait, I still had the #:flat in there
16:39 jay-mccarthy: they have different projections actually
16:39 sstrickl: Yes, they have different projections, but the vector? check happens in check-vectorof, which they both call.
16:42 blake_johnson: jay-mccarthy: still works fine without #:flat
16:44 jay-mccarthy: sstrickl: so you think we're getting a void in some how?
16:45 sstrickl: jay-mccarthy: Yeah, I really don't see how that's happening otherwise.
16:56 jay-mccarthy: but how could it get in one way but not the other?
16:58 sstrickl: Well, in one case it's creating a flat-contract, and in the other a chaperone-contract, so maybe some contract in which that is contained is changing its behavior whether it gets a flat or non-flat contract?
16:59 jay-mccarthy: you mean because it is in a struct/c?
16:59 sstrickl: Well, it's in a (struct ...) form inside provide/contract
16:59 sstrickl: so let me look there
17:00 sstrickl: (at least I think that's what define-form-struct* is doing
17:00 sstrickl: )
17:06 sstrickl: if it were in a struct/c, it'd just fail if it got a non-flat contract
17:17 jay-mccarthy: i still don't believe you but i haven't been able to make a smaller program
17:32 blake_johnson: sstrickl: we got you
17:32 blake_johnson: open our tests/compiler/zo-exs.rkt
17:33 blake_johnson: add this:
17:33 blake_johnson: (roundtrip
17:33 blake_johnson: (compilation-top 0
17:33 blake_johnson: (prefix 0 empty empty)
17:33 blake_johnson: (lam 'name empty 0 empty #f #() empty 0 #f)))
17:33 blake_johnson: go to compiler/zo-structs.rkt
17:34 blake_johnson: change the #;(provide ...) in define-form-struct* to (provide
17:34 blake_johnson: and you'll see that the test passes without contracts
17:34 blake_johnson: but fails with contracts
17:34 blake_johnson: thus it must be the contract's fault
17:34 blake_johnson: did you follow that? are we wrong?
17:35 blake_johnson: that was jay typing btw
17:37 sstrickl: or it means that you're not actually using the value in such a way that you're detecting the vectorness of it or not :)
17:37 jay-mccarthy: did you run it?
17:37 sstrickl: but yes, obviously that looks more problematic, but I'm still wondering if provide/contract is doing the wrong thing with it
17:37 sstrickl: gimme a sec, I just got back from getting food :P
17:38 sstrickl: jay-mccarthy: you're so impatient :D
17:38 jay-mccarthy: in one case you see a #void in the other you see #()
17:38 sstrickl: okay, one sec
17:38 jay-mccarthy: i'm horrible, i know
17:45 sstrickl: hmmm...
17:46 sstrickl: jay-mccarthy: I'm going to keep poking at this, but I'm also going to try and eat my food while it's still warm, so I'll be in and out; will let you know if I uncover anything interesting.
17:46 jay-mccarthy: k
17:46 jay-mccarthy: thx
17:53 (nick) samth -> samth_away
17:56 sstrickl: jay-mccarthy: if y'all could try paring down on zo-structs.rkt and something that uses it until you find a much smaller testcase that still exhibits the same behavior, it'd be appreciated
17:56 sstrickl: jay-mccarthy: I'm still working on seeing if I can figure it out from the evidence we have at the moment.
17:56 jay-mccarthy: we've tried a few things with no success but blake_johnson can keep trying
18:00 sstrickl: Okay.  I'm currently working on printf debugging in the contract, and I'm not seeing anything I don't expect.
18:01 jay-mccarthy: you can obvs comment out all the other tests in that file
18:01 sstrickl: Right
18:01 sstrickl: Hmm, fascinating.
18:02 (join) jao
18:04 jay-mccarthy: i gtg, let me know if you find anything out
18:04 jay-mccarthy: thx again <3
18:14 sstrickl: Okay, will do!
18:30 (quit) b-man_: Ping timeout: 265 seconds
18:32 (join) b-man_
18:36 (quit) sstrickl: Ping timeout: 265 seconds
18:37 (quit) jonrafkind: Ping timeout: 265 seconds
18:41 (join) sstrickl
18:52 (quit) carleastlund: Quit: carleastlund
18:52 (join) jonrafkind
18:58 (quit) sstrickl: Quit: sstrickl
19:47 (quit) objorn: Ping timeout: 240 seconds
20:30 (join) sstrickl
20:31 (join) sstrickl_
20:31 (quit) sstrickl: Read error: Connection reset by peer
20:31 (nick) sstrickl_ -> sstrickl
20:32 (quit) sstrickl: Client Quit
20:33 (join) sstrickl
20:35 (quit) jonrafkind: Ping timeout: 265 seconds
20:44 (quit) masm: Quit: Leaving.
20:51 (join) klutomet1s
20:51 (join) mao_
20:52 (quit) mao: Write error: Broken pipe
20:52 (quit) klutometis: Write error: Broken pipe
21:03 (quit) stamourv: Ping timeout: 507 seconds
21:22 (quit) flintf: Ping timeout: 252 seconds
21:22 (join) flintf
21:35 (quit) b-man_: Ping timeout: 276 seconds
21:46 (join) flintf_
21:47 (quit) flintf: Write error: Broken pipe
21:48 (join) rbarraud__
22:56 (quit) rbarraud__: Ping timeout: 276 seconds
22:58 (quit) writer: Quit: writer
23:13 (part) blake_johnson
23:57 (join) jonrafkind