> On Jan. 24, 2011, 6:42 a.m., Oz Linden wrote:
> > If the file is generated, what is it doing checked into the source tree at 
> > all?  This sounds to me like an invitation to future errors.
> > 
> > Is there some reason why we should not just delete the checked in version 
> > and have it generated every time it's needed?

These files were generated, but the generation is a manual process and needs to 
take place on both the server and the viewer to ensure compatibility because 
this is part of a protocol definition. This is an area where we could end up 
breaking compatibility if we're not very careful, so please make only the 
changes needed to make it compile and make no semantic changes.


- Kent


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/100/#review246
-----------------------------------------------------------


On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/100/
> -----------------------------------------------------------
> 
> (Updated Jan. 22, 2011, 7:40 a.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> -------
> 
> For the reason for this change, see 
> https://jira.secondlife.com/browse/VWR-24487 and 
> https://jira.secondlife.com/browse/VWR-24522
> 
> What I did:
> In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant 
> pointers to constants by search/replace. Then I tried to compile and added 
> const qualifiers in dependent code as needed to stop the compiler complaining.
> 
> Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files 
> have been generated from the message template. Because this generation might 
> not have been a one-off thing, I changed the generating code, too, so it 
> won't override this change here when the generation happens the next time. 
> However, that part of the code is not called by Viewer, although the relevant 
> function — dump_prehash_files() — ends up in the Viewer binary. That function 
> probably gets called by the simulator, when one runs the latter with 
> -prehash. (See 
> https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532
>  )
> 
> 
> This addresses bug VWR-24487.
>     http://jira.secondlife.com/browse/VWR-24487
> 
> 
> Diffs
> -----
> 
>   doc/contributions.txt fc7e5dcf3059 
>   indra/llmessage/message.cpp fc7e5dcf3059 
>   indra/llmessage/message_prehash.h fc7e5dcf3059 
>   indra/llmessage/message_prehash.cpp fc7e5dcf3059 
>   indra/llprimitive/llprimitive.h fc7e5dcf3059 
>   indra/llprimitive/llprimitive.cpp fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.h fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 
>   indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 
>   indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 
> 
> Diff: http://codereview.secondlife.com/r/100/diff
> 
> 
> Testing
> -------
> 
> Compiled (standalone, 64bit Linux) with and without LL_TESTS.
> Started the viewer, logged in, walked and flew around a bit. Everything seems 
> to work.
> 
> 
> Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in 
> indra/llui/tests/llurlentry_stub.cpp and 
> indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually 
> are never dereferenced, even when not NULL, so that using NULL pointers 
> instead of place holder data won't change what code paths gets tested. Both 
> tests binaries executed without crashes and all the contained tests passed.
> 
> Locally invoked start_messaging_system() with b_dump_prehash_file == true 
> instead of FALSE, to see what would be generated after my change to 
> dump_prehash_files().
> The message_prehash.(h|cpp) generated by that had the correct type qualifiers 
> and formatting, but some lines were removed or added compared to the modified 
> files from the source tree. That probably means that the files aren't fully 
> synchronized with the message template file in the source tree. Because the 
> "added" constants are spread all over the file, while the "removed" ones were 
> at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree 
> are actually more up-to-date than the message template file in the source 
> tree.
> 
> 
> Thanks,
> 
> Boroondas
> 
>

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to