please regenerate this patch using 'svn diff'. You should be able to do a fresh checkout of BRL-CAD from svn, cd into the brlcad/ directory and execute "patch -p0 < /path/to/magic.patch" with no additional input or error.
Additionally, converting that number to ascii (big endian) produces "herz", not "hrt?", I'd think we want those to match up. Perhaps create a trivial C program to generate the ascii or verify... :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the corrections on posting patches and choice of a magic number
for the heart primitive. I earlier on asked how magic numbers were chosen
on the mailing list and I was told they were arbitrarily chosen and given a
number (brlcad-devel Digest,Vol 335,Issue 1, Message 6). I will do the
necessary corrections.
please regenerate this patch using 'svn diff'. You should be able to do a
fresh checkout of BRL-CAD from svn, cd into the brlcad/ directory and
execute "patch -p0 < /path/to/magic.patch" with no additional input or
error.
Additionally, converting that number to ascii (big endian) produces
"herz", not "hrt?", I'd think we want those to match up. Perhaps create a
trivial C program to generate the ascii or verify... :)
Issac, you misunderstand. The number itself IS arbitrary. The comment that follows the hexidecimal number, however, is not arbitrary. It should be the ascii representation of that hexidecimal number. 'hrt?' is not the ascii representation of 0x6865727.
Put 0x6865727 into any online hexidecimal-to-ascii converter to see what that is in ascii. Basically, I suggested the german word for "heart" on the mailing list in hex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is somewhat concerning... the word in German is "herz", not "her?", not ending in 0x27 and not ending in 0x3f... If you intend to implement something as complex as a primitive in BRL-CAD, you should be competent and confident in your ability to write solid C code.
Just a thought, but perhaps a good exercise would be to write a pair of (not cad related) programs, one to take an ascii string as an input and generate the byte hexcode of the output.. the second to take a string of byte hexcode, convert it to numbers, then print the ascii that represents? This would help you verify the "magic" number you propose and seeing the source code would help affirm our trust in your ability :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Erik, should I edit the magic number once more ? Your comment on the German word confuses me - I thought our language of communication is English. I am not versed with German . Should I proceed to editing the magic.c ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there's confusion because you changed the string. Basically, why "hrt?" instead of "herz"? The value IS arbitrary, but it's nice when it's clever or has some meaning behind it. The point was that the comment string needs to match the hex values and now they do, so yes -- proceed with editing magic.c -- and if you decide to change the hex value, just make sure the comment is updated to match.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issac, please combine all relevant file edits into a single patch file. If these were commits, they belong together so you'd commit them together. Reviewers should not have to apply multiple patch files in order to accept a single patch submission. It's your job to group changes together in a meaningful way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
magic.zip includes magic_h.patch and magic_c.patch.
magic_h.patch includes a magic number (0x6872743f) into the include/magic.h file for the heart primitive.
magic_c.patch includes a case for the heart primitive into the bu_identify_magic() function in the src/libbu/magic.c file.
magic_h.patch should be applied first to include/magic.h and magic_c.patch applied after to src/libbu/magic.c.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
they should be in a single patch file, not a collection of patch files in a tar. You should
A) verify that your source tree is up to date (svn update),
B) double check your modificatons to make sure they are what you want to submitted and follow the guidlines in /src/to/brlcad/HACKING,
C) generate a patch file using subversion (cd /path/to/brlcad ; svn diff > hrt_magic.patch), then
D) doublecheck the patch file you generated to make sure that it does what you intent and only what you intend.
If you want to verify your patch file, you can do a fresh checkout (in a tmp dir or something), cd into the brlcad/ dir, then run "patch -p0 < /path/to/hrt_magic.patch" and make sure that it applies cleanly and changes what you intend to change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hrt_magic.patch includes line edits of the include/magic_h and src/libbu/magic_c files respectively.Firstly,it includes a magic number (0x6872743f) into the include/magic.h file for the heart primitive and then includes a case for the heart primitive into the bu_identify_magic() function in the src/libbu/magic.c file.
hrt_magic.patch should be applied first to include/magic.h and then to src/libbu/magic.c.
This patch is still not generated from svn. If you do not do your edits in the subversion checkout and use svn diff to generate the patches, I cannot apply it cleanly. With this patch, I get this:
erik@precious ~/src/brlcad$ patch -p0 < ~/Downloads/hrt_magic.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
This patch (hrt_magic.patch) is generated from svn, adds a magic number (0x6872743f) to include/magic.h as well as a case for the heart primitive in src/libbu/magic.c.
Hope this one applies cleanly.
Awaiting feedback.
Izak
I have completely hacked the magic header file. I included an arbitrary but correct hexadecimal number for the heart primitive.
please regenerate this patch using 'svn diff'. You should be able to do a fresh checkout of BRL-CAD from svn, cd into the brlcad/ directory and execute "patch -p0 < /path/to/magic.patch" with no additional input or error.
Additionally, converting that number to ascii (big endian) produces "herz", not "hrt?", I'd think we want those to match up. Perhaps create a trivial C program to generate the ascii or verify... :)
Thanks for the corrections on posting patches and choice of a magic number
for the heart primitive. I earlier on asked how magic numbers were chosen
on the mailing list and I was told they were arbitrarily chosen and given a
number (brlcad-devel Digest,Vol 335,Issue 1, Message 6). I will do the
necessary corrections.
On Fri, Jun 28, 2013 at 3:43 PM, Erik Greenwald
erikgreenwald@users.sf.netwrote:
Related
Patches:
#203Issac, you misunderstand. The number itself IS arbitrary. The comment that follows the hexidecimal number, however, is not arbitrary. It should be the ascii representation of that hexidecimal number. 'hrt?' is not the ascii representation of 0x6865727.
Put 0x6865727 into any online hexidecimal-to-ascii converter to see what that is in ascii. Basically, I suggested the german word for "heart" on the mailing list in hex.
Sean, I have edited the magic number to 0x6872743f which is the ascii representation of hrt?. Does this one correctly hack the include/magic.h file ?
Last edit: Isaac Kamga 2013-06-28
Yes, but now there's a problem of completeness. New magic number types registered into magic.h should have a corresponding entry in the magic.c file.
This is somewhat concerning... the word in German is "herz", not "her?", not ending in 0x27 and not ending in 0x3f... If you intend to implement something as complex as a primitive in BRL-CAD, you should be competent and confident in your ability to write solid C code.
Just a thought, but perhaps a good exercise would be to write a pair of (not cad related) programs, one to take an ascii string as an input and generate the byte hexcode of the output.. the second to take a string of byte hexcode, convert it to numbers, then print the ascii that represents? This would help you verify the "magic" number you propose and seeing the source code would help affirm our trust in your ability :)
Hi Erik, should I edit the magic number once more ? Your comment on the German word confuses me - I thought our language of communication is English. I am not versed with German . Should I proceed to editing the magic.c ?
I think there's confusion because you changed the string. Basically, why "hrt?" instead of "herz"? The value IS arbitrary, but it's nice when it's clever or has some meaning behind it. The point was that the comment string needs to match the hex values and now they do, so yes -- proceed with editing magic.c -- and if you decide to change the hex value, just make sure the comment is updated to match.
magicdotc.patch includes a case RT_HRT_INTERNAL_MAGIC for the heart primitive by editing the bu_identify_magic() function in src/libbu/magic.c
Issac, please combine all relevant file edits into a single patch file. If these were commits, they belong together so you'd commit them together. Reviewers should not have to apply multiple patch files in order to accept a single patch submission. It's your job to group changes together in a meaningful way.
magic.zip includes magic_h.patch and magic_c.patch.
magic_h.patch includes a magic number (0x6872743f) into the include/magic.h file for the heart primitive.
magic_c.patch includes a case for the heart primitive into the bu_identify_magic() function in the src/libbu/magic.c file.
magic_h.patch should be applied first to include/magic.h and magic_c.patch applied after to src/libbu/magic.c.
they should be in a single patch file, not a collection of patch files in a tar. You should
A) verify that your source tree is up to date (svn update),
B) double check your modificatons to make sure they are what you want to submitted and follow the guidlines in /src/to/brlcad/HACKING,
C) generate a patch file using subversion (cd /path/to/brlcad ; svn diff > hrt_magic.patch), then
D) doublecheck the patch file you generated to make sure that it does what you intent and only what you intend.
If you want to verify your patch file, you can do a fresh checkout (in a tmp dir or something), cd into the brlcad/ dir, then run "patch -p0 < /path/to/hrt_magic.patch" and make sure that it applies cleanly and changes what you intend to change.
hrt_magic.patch includes line edits of the include/magic_h and src/libbu/magic_c files respectively.Firstly,it includes a magic number (0x6872743f) into the include/magic.h file for the heart primitive and then includes a case for the heart primitive into the bu_identify_magic() function in the src/libbu/magic.c file.
hrt_magic.patch should be applied first to include/magic.h and then to src/libbu/magic.c.
This patch is still not generated from svn. If you do not do your edits in the subversion checkout and use svn diff to generate the patches, I cannot apply it cleanly. With this patch, I get this:
erik@precious ~/src/brlcad$ patch -p0 < ~/Downloads/hrt_magic.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
Please use subversion to create the patches, as described in http://brlcad.org/wiki/Patches
This patch (hrt_magic.patch) is generated from svn, adds a magic number (0x6872743f) to include/magic.h as well as a case for the heart primitive in src/libbu/magic.c.
Hope this one applies cleanly.
Awaiting feedback.
Izak
Applied as r56212