Community
Participate
Working Groups
New Agent Controller log file contains hard-coded paths. For example, D:\cygwin\home\build\TPTP\4.2.0\TPTP-4.2.0-200605231055\agntctrl\src\transport\TPTPClientCompTL\fileServer.c does not exist on my machine: <CommonBaseEvent creationTime="2006-05-24T17:33:58.548000Z" globalInstanceId="AC66990CB2A540CAB3E1EF3D1D899B55" msg="File server started listening on port 10005" severity="10" version="1.0.1"> <sourceComponentId component="AgentController" componentIdType="TPTPComponent" executionEnvironment="D:\cygwin\home\build\TPTP\4.2.0\TPTP-4.2.0-200605231055\agntctrl\src\transport\TPTPClientCompTL\fileServer.c, line 177" instanceId="1004" location="ninjazx7.torolab.ibm.com" locationType="IPV4" processId="4448" subComponent="Client Compatibility TL" threadId="3392" componentType="Eclipse_TPTP"/> <situation categoryName="ReportSituation"> <situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ReportSituation" reasoningScope="INTERNAL" reportCategory="LOG"/> </situation> </CommonBaseEvent>
The file name information comes from the compiler and reflects the file location at the time the code was compiled. If you had built the source in your local space, you would see a file name path relative to that source. I don't expect the source file information to be particularly useful to an individual reading the log unless they are building their own source. If they pass the log msg on to us in a bug report, then that file name information is useful as we know exactly what build was used.
Looks like the compiler uses the file names for the __FILE__ macro in the same form as it is given them on the command line. We need to change the make files but don't have the resources to do that now. Retargeting to 4.3.
Retargeting to future. No resources for making this change in 4.3
Transferring ownership of new agemt controller issues with no specific target date to Mikhail for consideration in future releases.
Assign to Stanislav
*** Bug 203957 has been marked as a duplicate of this bug. ***
Created attachment 105698 [details] eliminate the hard-coded path from log Hi, I think we can simply eliminate the hard-coded path information and just leave the file name there. I have made a patch. Please check log_file_name.patch.
Alex and Igor, could you please help review this patch. Thanks.
It seems this is not enough to keep file names only. Not all files have unique names such as Connect2AC.c in ACTL and CCTL modules. I'd suggest to keep part of path like this: TPTP-4.2.0-200605231055\agntctrl\src\transport\TPTPClientCompTL\fileServer.c Information about build version might be useful.
(In reply to comment #9) > It seems this is not enough to keep file names only. > Not all files have unique names such as Connect2AC.c in ACTL and CCTL modules. Good point. > I'd suggest to keep part of path like this: > > TPTP-4.2.0-200605231055\agntctrl\src\transport\TPTPClientCompTL\fileServer.c > > Information about build version might be useful. Assuming the user installs the Agent Controller in a directory with the build information. Since the point of this defect was that paths are hard-coded to the build machine, we should only use path relative to the source tree. For example, transport\TPTPClientCompTL\fileServer.c.
Paul, could you clarify initial intention for bug fix. Probably, the way how we can better trim paths depends from usage of log information (I suppose it is used only for debugging). I would prefer not to trim at all. File path is exclusively intended for problem reports and used only by developers who support the code. Full path can provide information about build environment and allows to identify right sandbox for working. I don't see reasons to eliminate useful information for the sake of beauty. Alex.
(In reply to comment #11) > Paul, could you clarify initial intention for bug fix. > Probably, the way how we can better trim paths depends from usage of log > information (I suppose it is used only for debugging). > > I would prefer not to trim at all. File path is exclusively intended for > problem reports and used only by developers who support the code. Full path can > provide information about build environment and allows to identify right > sandbox for working. I don't see reasons to eliminate useful information for > the sake of beauty. > > Alex. > Agreed that this is a 'nice-to-have' defect to improve the user/consumer experience and given the latest resource changes we should probably not worry about this type of thing. I assumed that it would be <1 PH effort to split the path string after the last 'src' token and only log the last substring. If not, I am fine with returning it as WONTFIX.
> Agreed that this is a 'nice-to-have' defect to improve the user/consumer > experience and given the latest resource changes we should probably not worry > about this type of thing. I assumed that it would be <1 PH effort to split the > path string after the last 'src' token and only log the last substring. If > not, I am fine with returning it as WONTFIX. Yunan, please either split the path string after the last 'src' token or close it as WONTFIX. It is up to you depending from required efforts.
Created attachment 122381 [details] Split the path string after the last 'src' token and only log the last substring As Alexander suggested, this patch split the path string after the last '/src/'('\\src\\' on Windows) token and only log the last substring. It should be also note that the patch preconditon is '/src/'('\\src\\') token is included in path string. The filename handle process is encapsulated into a local function for better modularity purpose. Dear comitters, please help to review the patch. Thanks a lot. Thanks, Chengrui
Reviewed and approved.
Requesting Jonathan (more native experience) also review given the lateness of the release.
Hi Chengrui, the LIN define is not defined anywhere in the makefile for this component, and so src_token will always default to the Windows format. Please use either __linux__ or a define in the makefile. Otherwise, the patch is good.
Created attachment 124633 [details] Modified patch to split the path string after the last 'src' token Hi, Jonathan, I have replaced LIN with __linux__ in patch code. Thanks for your information.
Created attachment 126511 [details] Updated Patch - Bug 143547 Slightly updated the patch to use #ifdef _WIN32 (e.g. is windows), which is better than what I originally suggested.
Chengrui, I'm ready to check this in... am I correct in assuming the fix for this only includes the "Updated Patch - Bug 143547" patch, and does not include "eliminate the hard-coded path from log" patch? Let me know, thanks!
(In reply to comment #20) > Chengrui, I'm ready to check this in... am I correct in assuming the fix for > this only includes the "Updated Patch - Bug 143547" patch, and does not include > "eliminate the hard-coded path from log" patch? Let me know, thanks! > Hi, Jonathan, you are right. The "eliminate the hard-coded path from log" patch is out of date and should not be used. Thanks.
Thanks Chengrui, patch checked into HEAD.
Verified in TPTP-4.5.3-200903010100. Closing.
