5 ms·

Raphael.js 2.0 beta release is out - GitHub

52 points by bai 16y ago

lamby 16y ago
Which is really and genuinely great, except the author is still releasing the code in essentially impossible-to-review code drops: https://github.com/DmitryBaranovskiy/raphael/commit/164c349e13326ce41eca13cb4318b5be52c8f002 https://github.com/DmitryBaranovskiy/raphael/commit/164c349e...
- bai 16y ago
  Yeah. I wish he knew about "Commit early, commit often"...
  - fredoliveira 16y ago
    He does. Also, he doesn't like contributions that much because most of the contributions he gets are (his words) "bad". Dmitry is ultra talented, but some of his opinions are bound to shock a few developers. If interested, see this interview with him on The Changelog: http://thechangelog.com/post/631899187/episode-0-2-5-rapha-ljs-with-dmitry-baranovskiy http://thechangelog.com/post/631899187/episode-0-2-5-rapha-l...
    - bai 16y ago
      Thanks!
- danjwilson 16y ago
  It's also difficult to contribute. Because of the one-commit-per-release strategy, Pull Requests aren't accepted (though the changes normally end up in the next release).
  - netnichols 16y ago
    I've had a one-line bug-fix pull request rejected with the answer of something like "that's fixed in version 2". Well, I'm glad it's fixed in v2, but now I have to maintain my own fork until v2 is released and is stable enough for production use. I have massive respect for Dmitry's pure abilities and the library as a whole, but trying to contribute is pretty frustrating.
- julian37 16y ago
  Also, a ChangeLog would be great. Or, for that matter, per-version documentation.
pedrokost 16y ago
round = function (num) { return +num + (~~num === num) * .5; }; What does ~~num do?
- weego 16y ago
  it will round toward zero
- teamonkey 16y ago
  ~ is bitwise NOT. For a number it returns the ones complement: ~N = -(N+1) So ~~num I think would return the original value. The only reason I can see would be to coerce it into some kind of number type.
- grayrest 16y ago
  Bitwise operations coerce the value to a int32. If a value cannot be reasonably coerced to an int (e.g. 'foo'), you get zero. It's basically the same as parseInt(x,10) but is generally faster, you don't need to remember the radix, and you don't get NaN. The downside is that trying to coerce numbers outside int32 will give incorrect answers. The other way to write it is 0|num which has the advantage of only applying one bitwise op. These tend to crop up most often in graphics oriented libraries.
  - euroclydon 16y ago
    Thanks. Anything quicker than parseFloat?
    - grayrest 16y ago
      You'd have to bench it, but the only thing I could think of that'd be faster is the standard +num coercion that's also used in the code snippet. Unfortunately, that does generate NaNs. Edit: Double checked the spec (it's quite readable) and the main difference is that + will coerce ignoring whitespace while parseFloat will ignore leading whitespace and parse leading digits. E.g. var x = '1.23foo'; parseFloat(x) is 1.23; +x is NaN. Neither looks like it should be faster than the other.
kreek 16y ago
There's a list of changes on the Google group. http://groups.google.com/group/raphaeljs/browse_thread/thread/f76614f79da88478 http://groups.google.com/group/raphaeljs/browse_thread/threa... • New transformation API and implementation, dramatically faster and flexible (full support for matrix transformations) • New animation API extension • Fix for subpixel rendering in IE • New arrowhead attributes • Improved getBBox calculation • Fix for HSB and HSL • Added viewBox support • New built-in event system • and lots of tiny bug fixes

52 points by bai 16y ago

lamby 16y ago

Which is really and genuinely great, except the author is still releasing the code in essentially impossible-to-review code drops: https://github.com/DmitryBaranovskiy/raphael/commit/164c349e13326ce41eca13cb4318b5be52c8f002 https://github.com/DmitryBaranovskiy/raphael/commit/164c349e...

bai 16y ago
Yeah. I wish he knew about "Commit early, commit often"...
- fredoliveira 16y ago
  He does. Also, he doesn't like contributions that much because most of the contributions he gets are (his words) "bad". Dmitry is ultra talented, but some of his opinions are bound to shock a few developers. If interested, see this interview with him on The Changelog: http://thechangelog.com/post/631899187/episode-0-2-5-rapha-ljs-with-dmitry-baranovskiy http://thechangelog.com/post/631899187/episode-0-2-5-rapha-l...
  - bai 16y ago
    Thanks!
danjwilson 16y ago
It's also difficult to contribute. Because of the one-commit-per-release strategy, Pull Requests aren't accepted (though the changes normally end up in the next release).
- netnichols 16y ago
  I've had a one-line bug-fix pull request rejected with the answer of something like "that's fixed in version 2". Well, I'm glad it's fixed in v2, but now I have to maintain my own fork until v2 is released and is stable enough for production use. I have massive respect for Dmitry's pure abilities and the library as a whole, but trying to contribute is pretty frustrating.
julian37 16y ago
Also, a ChangeLog would be great. Or, for that matter, per-version documentation.

pedrokost 16y ago

round = function (num) { return +num + (~~num === num) * .5; }; What does ~~num do?

weego 16y ago
it will round toward zero
teamonkey 16y ago
~ is bitwise NOT. For a number it returns the ones complement: ~N = -(N+1) So ~~num I think would return the original value. The only reason I can see would be to coerce it into some kind of number type.
grayrest 16y ago
Bitwise operations coerce the value to a int32. If a value cannot be reasonably coerced to an int (e.g. 'foo'), you get zero. It's basically the same as parseInt(x,10) but is generally faster, you don't need to remember the radix, and you don't get NaN. The downside is that trying to coerce numbers outside int32 will give incorrect answers. The other way to write it is 0|num which has the advantage of only applying one bitwise op. These tend to crop up most often in graphics oriented libraries.
- euroclydon 16y ago
  Thanks. Anything quicker than parseFloat?
  - grayrest 16y ago
    You'd have to bench it, but the only thing I could think of that'd be faster is the standard +num coercion that's also used in the code snippet. Unfortunately, that does generate NaNs. Edit: Double checked the spec (it's quite readable) and the main difference is that + will coerce ignoring whitespace while parseFloat will ignore leading whitespace and parse leading digits. E.g. var x = '1.23foo'; parseFloat(x) is 1.23; +x is NaN. Neither looks like it should be faster than the other.

kreek 16y ago

There's a list of changes on the Google group. http://groups.google.com/group/raphaeljs/browse_thread/thread/f76614f79da88478 http://groups.google.com/group/raphaeljs/browse_thread/threa... • New transformation API and implementation, dramatically faster and flexible (full support for matrix transformations) • New animation API extension • Fix for subpixel rendering in IE • New arrowhead attributes • Improved getBBox calculation • Fix for HSB and HSL • Added viewBox support • New built-in event system • and lots of tiny bug fixes