Functions for asymmetric padding + dep bumps ghc7.6 + misc fixes

[mgsloan]

No description provided.

[byorgey]

No, it's not like doing padX under a rotation. In particular it only pads on one side. padX applies a nonuniform scale to the entire envelope.

[fryguybob]

Ah, ok. So a circle would become half a circle and half an ellipse for the other half. The absolute coordinate part still seems confusing. Some example use cases should make that clear.

[byorgey]

circle 1 # padR2 (r2 (1,0)):

square 2 # rotateBy (1/8) # padR2 (r2 (1,2)):

[byorgey]

Hmm, do those extensions seem too long to anyone else? e.g. in the circle example above, presumably the envelope should be extended by 1 unit, but it looks like 2 (the diameter of the circle).

[fryguybob]

I was thinking that it was:

...
| dot > 0   = s * env v'

for some scale factor s. That would be more of a "pad half". padXY is extending the envelope along a vector like using a diagram as a brush for stroking (is extruding a valid term in this context?). Yes it looks longer then I expect. I'm not sure why :(.

[fryguybob]

If I test directly I'm not seeing what is in the images in the last comment:

> let a = circle 1 :: D R2
> let b = a # padR2 (r2 (1,0))
> envelopeP (r2 (1,0)) b
P (R2 {unR2 = (2.0,0.0)})

[byorgey]

Hmm... I'll look into this more carefully when I get back next week. In the meantime, here's the full code I was using to test, in case anyone else wants to take a look:

{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE NoMonomorphismRestriction #-}

import Data.Maybe
import Diagrams.Backend.Cairo.CmdLine
import Diagrams.Prelude
import Diagrams.TwoD.Combinators

type DC = Diagram Cairo R2

runEnvelopeTest :: DC -> DC
runEnvelopeTest = lw 0.05 . sampleEnvelope2D 100

sampleEnvelope2D :: Int -> DC -> DC
sampleEnvelope2D n d = foldr (flip atop) (d # lc red) bs
    where b  = fromJust $ appEnvelope (envelope d)
          bs :: [DC]
          bs = [stroke $ mkLine (origin .+^ (s *^ v)) (perp v) | v <- vs, let s = b v]
          vs = map r2 [ (2 * cos t, 2 * sin t)
                      | i <- [0..n]
                      , let t = ((fromIntegral i) * 2.0 * pi) / (fromIntegral n)
                      ]
          mkLine a v = (moveTo a $ fromOffsets [v] # centerXY)
          perp (unr2 -> (x,y)) = r2 (-y,x) # scale 5

d = square 2 # rotateBy (1/8) # padR2 (r2 (1,2))

main = defaultMain (runEnvelopeTest $ d)

It's a bit ugly since I copy & pasted a bunch of it from some test code I had before. E.g. why all the mucking about with sin, cos, and a list comprehension in the definition of vs instead of just using iterateN (rotateBy ... to get a bunch of rotated versions of a starting vector? But anyway.

[byorgey]

Also, perhaps something like extrudeEnvelope would be a more descriptive name?

[byorgey]

Oh, sorry, I didn't see it was combined with the padR2 stuff. Anyway, I haven't forgotten about this and hope to take a closer look at some point in the nearish future.

[mgsloan]

Yeah, me either - been busy with work + moving + etc. Wish github had a
convenient UI for rebasing a branch and cherry-picking out commits into the
other topic branch! Didn't mean for these to go in with the padR2 stuff.

On Wed, Aug 29, 2012 at 8:56 PM, Brent Yorgey notifications@github.comwrote:

Oh, sorry, I didn't see it was combined with the padR2 stuff. Anyway, I
haven't forgotten about this and hope to take a closer look at some point
in the nearish future.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-8148727.

[byorgey]

Well, in any case, this is one reason why you shouldn't open pull requests from master. =) I just read some advice (which seems good) to use your master branch only to track the remote master, and topic branches for all development. Once you're happy with some changes, you make sure your master is up-to-date, possibly rebase your topic branch on top of it, and open a pull request from your topic branch. Once your changes have been merged you get them back into your master just by pulling, and you can then delete your topic branch. The added benefit is that if for some reason your changes get cherry-picked or rebased or otherwise munged before being merged into the remote master, all you have to do is pull into master and throw away your topic branch -- you don't have to do any munging yourself to back stuff out before pulling.

[mgsloan]

Superseded by: #60