As I did not understand how to proceed in the above problem, I tried another task from the Deuces page, 2.1.5, https://brlcad.org/wiki/Deuces#Debug_and_fix_a_bug_converting_cylinders
When I ran this dbupgrade -r cylinder.g
it gave Usage: bin/dbupgrade [-f] input.g output.g
If I run it with bin/dbupgrade -r cylinder.g output.g
it gave _GLOBAL not supported in version 4 databases, not converted
0 objects failed to convert
How do I reproduce the bug mentioned in the task?
Could someone help me in reproducing this bug?
Did you run the "l" command in mged before and after?
Yes i did, but the dbupgarde itself failed. So I dont think I reproduced the bug correctly
where's the dbupgrade failure message?
what you pasted doesn't show one
Wait let me run it once again and tell you what output I got exactly
First I entered "dbupgrade -r cylinder.g " as was given in the task
Usage: bin/dbupgrade [-f] input.g output.g
This was the output
Then i entered : "bin/dbupgrade -r cylinder.g output10.g"
This was the output: "_GLOBAL not supported in version 4 databases, not converted, 0 objects failed to convert"
yes... that all expected
the first time, the usage was wrong.
the second time, it worked .... "0 objects failed to convert"
the message about _GLOBAL is just informative as the -r flag is downgrading the database to a previous format that does not support _GLOBAL
Sean said:
the second time, it worked .... "0 objects failed to convert"
OMG sorry, I did not read it correctly. I did not focus on the 0 :P
reproduced the bug, Thanks
So in this, What does dbupgrade do?
typically it upgrades BRL-CAD format geometry data files from v4 format to v5 format. With the -r flag, it does the reverse and downgrades a v5 format file into v4 format.
Ohk
WHen I do l rhc
what code is going to run?
you can follow it from src/mged/setup.c - the mged_cmdtab translates the string into the first function to call
Ohh cool
specifically, the 'l' command translates into ged_list() which is in src/libged/list/list.c
just in case you had trouble following the logic there. setup.c registers a function callback, so when user types "l" it'll call that function.
Could someone help me with using a debugger for src code, like I know how to use it for small programs which are in 1 file.
Maybe you could send a link which explains this
I want to log a variable for debugging, How do i do that? (bu_log works only for strings afaik)
Ignore the above msg.
I think I have solved this bug, there was a small mistake with the management of rhc_c
variable. The l rhc
command works fine now, Should i test this in any other way?
Could anyone tell me how I could test the fix I've made or if l rhc
has passed its sufficient?
@Vikram Atreya did you figure out that bu_log() is the same as printf()?
If the "l" output is identical, that's a pretty good indication that you fixed the issue. The only testing required would be a try a couple different rhc parameters to make sure the before/after looks the same.
Sean said:
Vikram Atreya did you figure out that bu_log() is the same as printf()?
Yeah I did :)
Sean said:
If the "l" output is identical, that's a pretty good indication that you fixed the issue. The only testing required would be a try a couple different rhc parameters to make sure the before/after looks the same.
Will do
@Vikram Atreya let me know when you have a patch to review and I'll take a look at it.
Cool
I created a ticket for the patch , #562
Wow, seriously good find @Vikram Atreya... That was a pretty obscure well-hidden bug!
Your fix looks right to me. The old import4/export4 code is what serializes data to/from disk. It was writing it out in one position, but then reading it back from a different (wrong) position from the serialized bytes.
You'll be credited with this fix in our next public release. Well done, again!
Sean said:
You'll be credited with this fix in our next public release. Well done, again!
Thank you :grinning_face_with_smiling_eyes:
U gave me 2 bugs which I could try solving back in Nov I think, I gave up on the first one :P as i dint have a lot of time back then. Also i would like to apply for GSoC this year. So based on that could you give me something to work upon?
certainly. what kind of coding interests you?
Umm what do you mean by kind? like debugging, new code etc?
there are all different kinds of coding, like low-level logic, or networking, or high performance optimization, or multithreading, or graphics, or interesting algorithms, or high level GUI work, or ....
if you're unsure, that's an answer too and we can find something relatively self-contained.
did you have ideas on what you intended to propose for gsoc?
do you have strong feelings on C vs C++ vs Python vs ...
I like interesting algorithms for sure, dont have any idea regarding high level GUI and multithreading
Sean said:
do you have strong feelings on C vs C++ vs Python vs ...
Nothing like that, I am fine with all 3 languages
Sean said:
did you have ideas on what you intended to propose for gsoc?
Not yet
any particular technology like opengl, opencl, pthreading, intel tbb,
...
Sean said:
any particular technology like opengl, opencl, pthreading, intel tbb,
...
I dont know any of them now, but im learning openGL as part of a course in college this semester.
Vikram Atreya said:
I like interesting algorithms for sure, dont have any idea regarding high level GUI and multithreading
That's good to know -- I suggest leaning on your strengths and what you know for starters.
BRL-CAD can be complex and intimidating enough as it is to learn what is what and where things are to add new unknown technologies into the mix also (at least for GSoC -- on your own, do whatever you love).
@Vikram Atreya I suggest starting by reading over our previous GSoC years and see if any of those projects sound really interesting to you. they're all on the wiki at https://brlcad.org/wiki/Google_Summer_of_Code/YEAR where YEAR is 2019, 2018, 2017, etc.
Sean said:
Vikram Atreya I suggest starting by reading over our previous GSoC years and see if any of those projects sound really interesting to you. they're all on the wiki at https://brlcad.org/wiki/Google_Summer_of_Code/YEAR where YEAR is 2019, 2018, 2017, etc.
Sure, I will get back if i find something interesting
picking up where someone else left off, or redoing their work if it wasn't successful, is always of interest in order to not start anew
https://brlcad.org/wiki/
is not opening
Now its working
Last updated: Jan 09 2025 at 00:46 UTC