[GEM-dev] pix_write Pull request

[Jack]

Le 08/12/2011 12:06, Jack a écrit :
> Le 07/12/2011 23:49, Jack a écrit :
>> Le 07/12/2011 16:22, IOhannes m zmoelnig a écrit :
>>> -----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.
>>
>> I had the opportunity to work on this topic this evening.
>> Here the abstraction.
>> ++
>>
>> Jack
>>
>>
>>> fgmasdr
>>> IOhannes
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk7fhKsACgkQkX2Xpv6ydvQ1/ACgkwleMOvDnuSRWWhm2TpdBsB/
>>> NlMAoJk57ECdplFAcbmBxWC8W1T9dJj/
>>> =ew7K
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>>
>>> _______________________________________________
>>> GEM-dev mailing list
>>> GEM-dev at iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
> Some improvement in the help patch.
> ++
>
> Jack
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev

Hello,


A version most based on [pix_writer] logic.
++

Jack


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20111210/efec2811/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save_pix.zip
Type: application/zip
Size: 1176 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20111210/efec2811/attachment.zip>