Re: [racket-dev] Racket backend for my Python visualizer

[John Clements]

On Aug 25, 2012, at 4:28 PM, Philip Guo wrote:

> [Cc'ed Frank (Lingfeng), who is the student doing the actual implementation. 
> Frank, please chime in with thoughts too …]


Okay, I just pushed a version of Racket (f107c4d2658) that includes an 
"external interface" for the stepper, in 
plt/collects/stepper/external-interface.rkt.  There's also an example of how 
you might use it, at 
plt/collects/stepper/examples/external-interface-exampler.rkt.

The basic idea is that you give it a file path or a string, and a handler 
procedure that will be called on each breakpoint, and it annotates and runs it, 
calling your function on each breakpoint.

The information passed to the handler is not terribly well-documented; let me 
give you a bit of background.

The first argument is a "mark list"; these correspond to continuation frames, 
which are a lot like stack frames except that they're at expression-level 
granularity. Each frame contains a source expression, a label, and a list of 
local bindings. There are functions in plt/collects/stepper/private/marks that 
can extract the information from these marks. This value can be #f, for an 
'expr-finished-break (see descriptions below).

The second argument tells what kind of breakpoint it is.

KINDS OF BREAKPOINTS:

'normal-break : occurs before an expression's evaluation. The "before"
  steps.

'result-exp-break : occurs before an expression's evaluation that is the
  "after" of some other step. E.G., the rhs of a cond, the body of
  a procedure, etc.

'result-value-break : occurs when a value is returned. Also corresponds
  to an "after" step.

'normal-break/values : occurs before an expression's evaluation, when
  that expression has intermediate values. For instance, an "if"'s
  reduction occurs after its test value has been evaluated, so the
  "before" step for the "if" must already know about the test value.

'expr-finished-break : occurs when a top-level expression is complete.

'double-break : occurs as part of the evaluation of a let or local,
  after the evaluation of all the binding rhses. Called a double-break
  because it must generate two steps.

The third argument is either false or a list of values; the result-value-break, 
normal-break/values, and expr-finished-break have lists of values here.



When you try running this on a program bigger than (+ 3 4), you're going to 
notice several things:

1) There are going to be a LOT of breakpoints. Thousands and thousands of them, 
for fairly small programs. I'm guessing that you're going to want to cut down 
the number of these quite substantially. The first and easiest thing to do 
would be to filter out the 'result-exp and 'result-value breaks. 

2) There are also lots and lots of breakpoints that occur during the evaluation 
of code that was inserted as part of macro expansion. The most obvious clue 
here is that these frames have line and column values of #f, but you can also 
test this directly by applying 'syntax-source' to the source expression 
referred to by the mark.

3) You're going to be interested in the bindings in the breakpoints, because 
those are what will allow you to extract the bindings and heap values that you 
need to build your heap representation.

4) In the presence of mutation, you're going to want to construct that 
representation before the handler returns, because subsequent program 
evaluation will mess up that heap. Actually, that kind of goes without saying, 
doesn't it? :)

5) Some programs are going to break. In particular, the stepper's annotation is 
well-tested only for programs written in the student languages, and I'm 
assuming that your visualization tool will operate on top-level programs 
starting with "#lang racket". Let me know when you find programs that don't 
work.

Also, in writing the last paragraph, I realize that I may have made an 
unwarranted assumption when I assumed that you'd be operating on top-level, 
"#lang" programs.  It may well be that you're actually interested in student 
language programs, which would be good in the sense that the stepper's 
annotation is more robust for these programs, and a bit of extra work in the 
sense that I'd have to doctor the annotation to take this into account.


I sincerely hope that you're able to make progress on this: I've seen that 
python visualizer output, and I would *love* to have something like that 
running for Racket programs.

All the best, 

John Clements

(cc: racket-dev)



> 
> See below ...
> 
> On Sat, Aug 25, 2012 at 4:10 PM, John Clements  
> wrote:
> 
> On Aug 25, 2012, at 2:22 PM, Philip Guo wrote:
> 
> > Great timing :) We're pretty stuck googling around for the right way to 
> > implement what we need. Basically we want something like this, except for 
> > Racket:
> > http://docs.python.org/library/bdb.html
> >
> > The Online Python Tutor backend runs a Python script under bdb, which 
> > enables it to single-step through execution one line at a time and dump out 
> > the complete sta

Re: [racket-dev] number-of-bindings tooltip: thanks!

[Robby Findler]

I've moved the tooltips so they are in a less annoying place now. I
think it can still be a bit better, but at least now it isn't as
annoying (I think).

Robby

On Mon, Aug 27, 2012 at 7:01 PM, Robby Findler
 wrote:
> Thanks.
>
> I've been using it for a little while now and I actually really hate it. :)
>
> I need to move it so it doesn't overlap with the (at least not as often).
>
> Robby
>
>
> On Monday, August 27, 2012, John Clements wrote:
>>
>> I see that you've added a tooltip on check-syntax hover that shows how
>> many uses a variable has. Thanks!
>>
>> John
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] number-of-bindings tooltip: thanks!

[Robby Findler]

Thanks.

I've been using it for a little while now and I actually really hate it. :)

I need to move it so it doesn't overlap with the (at least not as often).

Robby

On Monday, August 27, 2012, John Clements wrote:

> I see that you've added a tooltip on check-syntax hover that shows how
> many uses a variable has. Thanks!
>
> John
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] number-of-bindings tooltip: thanks!

[John Clements]

I see that you've added a tooltip on check-syntax hover that shows how many 
uses a variable has. Thanks!

John



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] errors from `force`

[Sam Tobin-Hochstadt]

Since I've made the Typed Racket tests run in parallel, there have
been intermittent errors in DrDr, like this:

  http://drdr.racket-lang.org/25278/collects/tests/typed-racket/run.rkt

I'm not sure exactly what could be causing this -- I don't think
promises should ever fail to `force`.  Might there be something I'm
doing wrong, or is this a bug in promises?
-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Robby Findler]

Oh, okay. And so if you have a function that accepts a struct, does some
work with it, and then returns a new version of it (and you wanted to
optimize the body of the function), then you could get away with doing
something like 'struct-copy' to make the final version that gets returned.

Robby

On Monday, August 27, 2012, Vincent St-Amour wrote:

> I don't think it would be necessary.
>
> For the optimization to trigger, the only thing a step in the chain can
> do with its argument is use its components. Anything else (e.g. checking
> whether it's a substruct) would require the argument to be boxed, and
> would prevent the optimization from happening.
>
> Each step of the chain is very limited in what it can do to its
> argument, which works fine for complex numbers (most operations on them
> only use the components), but I'm not sure it would work well for
> structs.
>
> Vincent
>
>
> At Mon, 27 Aug 2012 10:15:04 -0500,
> Robby Findler wrote:
> >
> > Would you need a "and is not a substruct?" predicate to make such things
> work?
> >
> > Robby
> >
> > On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour 
> > >
> wrote:
> > > TR's complex number optimizations eliminate repeated boxing and
> unboxing
> > > in chains of operations that each consume and produce complex numbers.
> > >
> > > Similar optimizations for structs would eliminate structs for
> > > intermediate results in chains of operations that each consume and
> > > produce that same (single) kind of struct.
> > >
> > > If your code has such chains of operations, then these optimizations
> > > could apply.
> > >
> > > Do you have code that you think would benefit that I could look at?
> > >
> > > Vincent
> > >
> > >
> > > At Sat, 18 Aug 2012 12:40:21 -0600,
> > > Neil Toronto wrote:
> > >>
> > >> Is TR's optimizer eventually going to unbox structs in the same way it
> > >> unboxes rectangular flonums?
> > >>
> > >> I have a design choice right now: how to represent probabilities.
> Floats
> > >> are good because of their speed, but because of floating-point
> > >> limitations, *four different representations* are typically used. (For
> > >> the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions
> > >> that accept any one of these representations, denoted by this type:
> > >>
> > >>(define-type Probability
> > >>  (U probability 1-probability log-probability log-1-probability))
> > >>
> > >> The types are simply struct types that tag Float.
> > >>
> > >> Of course, manually boxing flonums ruins any chance of the compiler
> > >> emitting code that keeps the flonums unboxed. If TR's optimizer
> unboxed
> > >> structs, though, everything could be speedy.
> > >>
> > >> FWIW, by "eventually," I mean "within the next n years", where "n" is
> a
> > >> smallish number.
> > >>
> > >> Neil ⊥
> > >> _
> > >>   Racket Developers list:
> > >>   http://lists.racket-lang.org/dev
> > >
> > > _
> > >   Racket Developers list:
> > >   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Ray Racine]

FWIW, the Scala folks have done something along these lines, Value Classes,
originally aka Inline Classes.

https://docs.google.com/document/d/10TQKgMiJTbVtkdRG53wsLYwWM2MkhtmdV25-NZvLLMA/edit?hl=en_US&pli=1


On Mon, Aug 27, 2012 at 12:58 PM, Neil Toronto wrote:

> On 08/27/2012 09:11 AM, Vincent St-Amour wrote:
>
>> TR's complex number optimizations eliminate repeated boxing and unboxing
>> in chains of operations that each consume and produce complex numbers.
>>
>> Similar optimizations for structs would eliminate structs for
>> intermediate results in chains of operations that each consume and
>> produce that same (single) kind of struct.
>>
>> If your code has such chains of operations, then these optimizations
>> could apply.
>>
>> Do you have code that you think would benefit that I could look at?
>>
>
> Not yet. I've given up on a union of different probability representation
> types for now.
>
> For arrays, I could. An array is just a function with a finite,
> rectangular domain (a "shape"). Think of the type like this:
>
>   (struct: (A) array ([shape : (Vectorof Index)]
>   [proc : ((Vectorof Index) -> A)]))
>
> (This is a bit simplified.) So
>
>   (array-exp (array-abs arr))
>
> doesn't actually compute (log (abs x)) for any `x', it just creates an
> array that would if you asked it for an element. IOW, it's equivalent to
>
>   (array-map (compose exp abs) arr)
>
> which itself is equivalent to
>
>   (array (array-shape arr) (compose exp abs (array-proc arr)))
>
> If I made functions like `array-exp' and `array-map' into macros, and if
> array structs were unboxed, Racket's optimizer could inline the
> compositions. I imagine this eventual lovely outcome:
>
>   (let ([proc  (array-proc arr)])
> (array (array-shape arr)
>(lambda (x) (unsafe-flexp (unsafe-flabs (proc x))
>
> There are also FlArray and FCArray, which are subtypes of Array that store
> their elements (unboxed in flvectors and fcvectors). FlArray-specific
> operations are currently about 5x faster than Array's. But Array's ops
> don't allocate stores for intermediate results, so with the right
> optimizations, Array's could be the faster ones.
>
> If you want to have a look right now, checkout
>
>   
> https://github.com/ntoronto/**racket.git
>
> and try this program:
>
> #lang typed/racket
>
> (require math/array)
>
> (define arr (array [[1.2 4.0] [3.2 -1.8]]))
> (inline-array-map exp (inline-array-map abs arr))
>
>
>
> Neil ⊥
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Neil Toronto]

On 08/27/2012 09:11 AM, Vincent St-Amour wrote:

TR's complex number optimizations eliminate repeated boxing and unboxing
in chains of operations that each consume and produce complex numbers.

Similar optimizations for structs would eliminate structs for
intermediate results in chains of operations that each consume and
produce that same (single) kind of struct.

If your code has such chains of operations, then these optimizations
could apply.

Do you have code that you think would benefit that I could look at?


Not yet. I've given up on a union of different probability 
representation types for now.


For arrays, I could. An array is just a function with a finite, 
rectangular domain (a "shape"). Think of the type like this:


  (struct: (A) array ([shape : (Vectorof Index)]
  [proc : ((Vectorof Index) -> A)]))

(This is a bit simplified.) So

  (array-exp (array-abs arr))

doesn't actually compute (log (abs x)) for any `x', it just creates an 
array that would if you asked it for an element. IOW, it's equivalent to


  (array-map (compose exp abs) arr)

which itself is equivalent to

  (array (array-shape arr) (compose exp abs (array-proc arr)))

If I made functions like `array-exp' and `array-map' into macros, and if 
array structs were unboxed, Racket's optimizer could inline the 
compositions. I imagine this eventual lovely outcome:


  (let ([proc  (array-proc arr)])
(array (array-shape arr)
   (lambda (x) (unsafe-flexp (unsafe-flabs (proc x))

There are also FlArray and FCArray, which are subtypes of Array that 
store their elements (unboxed in flvectors and fcvectors). 
FlArray-specific operations are currently about 5x faster than Array's. 
But Array's ops don't allocate stores for intermediate results, so with 
the right optimizations, Array's could be the faster ones.


If you want to have a look right now, checkout

  https://github.com/ntoronto/racket.git

and try this program:

#lang typed/racket

(require math/array)

(define arr (array [[1.2 4.0] [3.2 -1.8]]))
(inline-array-map exp (inline-array-map abs arr))


Neil ⊥

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Vincent St-Amour]

I don't think it would be necessary.

For the optimization to trigger, the only thing a step in the chain can
do with its argument is use its components. Anything else (e.g. checking
whether it's a substruct) would require the argument to be boxed, and
would prevent the optimization from happening.

Each step of the chain is very limited in what it can do to its
argument, which works fine for complex numbers (most operations on them
only use the components), but I'm not sure it would work well for
structs.

Vincent


At Mon, 27 Aug 2012 10:15:04 -0500,
Robby Findler wrote:
> 
> Would you need a "and is not a substruct?" predicate to make such things work?
> 
> Robby
> 
> On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour  
> wrote:
> > TR's complex number optimizations eliminate repeated boxing and unboxing
> > in chains of operations that each consume and produce complex numbers.
> >
> > Similar optimizations for structs would eliminate structs for
> > intermediate results in chains of operations that each consume and
> > produce that same (single) kind of struct.
> >
> > If your code has such chains of operations, then these optimizations
> > could apply.
> >
> > Do you have code that you think would benefit that I could look at?
> >
> > Vincent
> >
> >
> > At Sat, 18 Aug 2012 12:40:21 -0600,
> > Neil Toronto wrote:
> >>
> >> Is TR's optimizer eventually going to unbox structs in the same way it
> >> unboxes rectangular flonums?
> >>
> >> I have a design choice right now: how to represent probabilities. Floats
> >> are good because of their speed, but because of floating-point
> >> limitations, *four different representations* are typically used. (For
> >> the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions
> >> that accept any one of these representations, denoted by this type:
> >>
> >>(define-type Probability
> >>  (U probability 1-probability log-probability log-1-probability))
> >>
> >> The types are simply struct types that tag Float.
> >>
> >> Of course, manually boxing flonums ruins any chance of the compiler
> >> emitting code that keeps the flonums unboxed. If TR's optimizer unboxed
> >> structs, though, everything could be speedy.
> >>
> >> FWIW, by "eventually," I mean "within the next n years", where "n" is a
> >> smallish number.
> >>
> >> Neil ⊥
> >> _
> >>   Racket Developers list:
> >>   http://lists.racket-lang.org/dev
> >
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Robby Findler]

Would you need a "and is not a substruct?" predicate to make such things work?

Robby

On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour  wrote:
> TR's complex number optimizations eliminate repeated boxing and unboxing
> in chains of operations that each consume and produce complex numbers.
>
> Similar optimizations for structs would eliminate structs for
> intermediate results in chains of operations that each consume and
> produce that same (single) kind of struct.
>
> If your code has such chains of operations, then these optimizations
> could apply.
>
> Do you have code that you think would benefit that I could look at?
>
> Vincent
>
>
> At Sat, 18 Aug 2012 12:40:21 -0600,
> Neil Toronto wrote:
>>
>> Is TR's optimizer eventually going to unbox structs in the same way it
>> unboxes rectangular flonums?
>>
>> I have a design choice right now: how to represent probabilities. Floats
>> are good because of their speed, but because of floating-point
>> limitations, *four different representations* are typically used. (For
>> the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions
>> that accept any one of these representations, denoted by this type:
>>
>>(define-type Probability
>>  (U probability 1-probability log-probability log-1-probability))
>>
>> The types are simply struct types that tag Float.
>>
>> Of course, manually boxing flonums ruins any chance of the compiler
>> emitting code that keeps the flonums unboxed. If TR's optimizer unboxed
>> structs, though, everything could be speedy.
>>
>> FWIW, by "eventually," I mean "within the next n years", where "n" is a
>> smallish number.
>>
>> Neil ⊥
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] TR's optimizer eventually going to unbox structs?

[Vincent St-Amour]

TR's complex number optimizations eliminate repeated boxing and unboxing
in chains of operations that each consume and produce complex numbers.

Similar optimizations for structs would eliminate structs for
intermediate results in chains of operations that each consume and
produce that same (single) kind of struct.

If your code has such chains of operations, then these optimizations
could apply.

Do you have code that you think would benefit that I could look at?

Vincent


At Sat, 18 Aug 2012 12:40:21 -0600,
Neil Toronto wrote:
> 
> Is TR's optimizer eventually going to unbox structs in the same way it 
> unboxes rectangular flonums?
> 
> I have a design choice right now: how to represent probabilities. Floats 
> are good because of their speed, but because of floating-point 
> limitations, *four different representations* are typically used. (For 
> the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions 
> that accept any one of these representations, denoted by this type:
> 
>(define-type Probability
>  (U probability 1-probability log-probability log-1-probability))
> 
> The types are simply struct types that tag Float.
> 
> Of course, manually boxing flonums ruins any chance of the compiler 
> emitting code that keeps the flonums unboxed. If TR's optimizer unboxed 
> structs, though, everything could be speedy.
> 
> FWIW, by "eventually," I mean "within the next n years", where "n" is a 
> smallish number.
> 
> Neil ⊥
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev