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 ?
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...
cheers
antoine
-----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.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-07 16:22, IOhannes m zmoelnig wrote:
maybe it's time to wrap that up into a CodingStyle.txt file :-)
http://pd-gem.git.sourceforge.net/git/gitweb.cgi?p=pd-gem/Gem;a=blob;f=doc/C...
fmasr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-07 16:22, IOhannes m zmoelnig wrote:
ok, some comments:
- - ah, and the code should be cross-platform; simply including files available on your system is a straight way to disaster :-)
fgmasdr IOhannes
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
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@iem.at http://lists.puredata.info/listinfo/gem-dev
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Some improvement in the help patch. ++
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Some improvement in the help patch. ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hello,
A version most based on [pix_writer] logic. ++
Jack
On 12/10/2011 07:14 PM, Jack wrote:
A version most based on [pix_writer] logic. ++
do you think you could create a 100% compatible version using [pix_buffer]? i don't want to add yet another pix-writing object, but rather have the already existing ones collapsed into a single one.
mfadr IOhannes
PS: [pix_buffer] now takes [enumProps(, [setProps( and [clearProps( messages
Le 11/12/2011 14:01, IOhannes zmölnig a écrit :
On 12/10/2011 07:14 PM, Jack wrote:
A version most based on [pix_writer] logic. ++
do you think you could create a 100% compatible version using [pix_buffer]? i don't want to add yet another pix-writing object, but rather have the already existing ones collapsed into a single one.
mfadr IOhannes
PS: [pix_buffer] now takes [enumProps(, [setProps( and [clearProps( messages
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I don't know if it is enough. It should be 100% compatible with [pix_writer]. Is it possible to use an other format like gif with 'setProps' ? ++
Jack
hello, i just noticed that tiff should be tif, and jpeg should be jpg.
what about a pix_write compatible abstraction? ;-)
c
I don't know if it is enough. It should be 100% compatible with [pix_writer]. Is it possible to use an other format like gif with 'setProps' ? ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 12/11/2011 08:06 PM, cyrille henry wrote:
hello, i just noticed that tiff should be tif, and jpeg should be jpg.
true.
i added some of jacks ideas to my rough implementation and pushed to sourceforge. see abstractions/pix_writer.pd
what about a pix_write compatible abstraction? ;-)
see abstractions/pix_write.pd
ghamdr IOhannes
Le 11/12/2011 20:31, IOhannes zmölnig a écrit :
On 12/11/2011 08:06 PM, cyrille henry wrote:
hello, i just noticed that tiff should be tif, and jpeg should be jpg.
Yes !
true.
i added some of jacks ideas to my rough implementation and pushed to sourceforge. see abstractions/pix_writer.pd
OK, seems perfect ;) This open the possibility to use setProps to change future enhancement.
what about a pix_write compatible abstraction? ;-)
see abstractions/pix_write.pd
Seems good too. ++
Jack
ghamdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Antoine Villeret -
cyrille henry -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Jack