-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-12-07 15:36, Antoine Villeret wrote:
hi Iohannes,
i made a pull request directly on github
did you received it ? I think not... because I clone the sourceforge repos
and push it on a new github repo
it could have worked if I'd made a fork instead of a clone, isn't it ?
is there any way to do a fork from sourceforge repos ?
right, probably there is no way to do a proper pull request :-)
anyhow, I wrote some lines of code to add relative path support to pix_write
those are in the branch pix_write of my github repos :
https://github.com/avilleret/Gem
i don't know if this code is in the right Gem coding style but it was a
good opportunity for me to put my hands deep in the code...
ok, some comments:
- - you should not base your branches on top of each other but rather fork
them all from master (e.g. when merging in "pix_write", i don't want to
incidentally merge in "vertexarray")
- - try to avoid committing pd-patches and C++ code within the same
commit. conflicts in C++-code can usually easily be resolved, whereas
conflicts in Pd-patches are usually impossible to resolve (but for the
most trivial cases)
- - while the Gem code is full of bad examples, i try to gradually move
from C-type arrays/strings (e.g. "char*") to C++ STL-types (e.g.
"std::string")
- - members should be intialized via "member initialization" when possible.
e.g. use
foo::foo(void) : m_x(0), m_y(0) {}
rather than
foo::foo(void) { m_x=0; m_y=0; }
maybe it's time to wrap that up into a CodingStyle.txt file :-)
oh, and i would like to replace [pix_write] and [pix_writer] with
abstractions based on [pix_buffer] rather sooner than later.