Author Topic: Issue about saving the cbp project file (Read 18135 times)

ollydbg · « **on:** February 06, 2012, 01:50:51 am »

Steps to reproduce: (WinXP)
1, open a clean Codeblocks.cbp in a recent debugger branch nightly build.
2, change the command argument for src, like adding "-p=debugCC".
3, close this project.

Now, I can see that:
1, The EOL changing from CRLF to LF
2, There are many other changes like:

Code

Index: E:/code/cb/cb_trunk/src/CodeBlocks.cbp
===================================================================
--- E:/code/cb/cb_trunk/src/CodeBlocks.cbp	(revision 7781)
+++ E:/code/cb/cb_trunk/src/CodeBlocks.cbp	(working copy)
@@ -24,7 +24,7 @@
 				</Linker>
 			</Target>
 			<Target title="tinyXML">
-				<Option output="base\tinyxml\txml" prefix_auto="1" extension_auto="1" />
+				<Option output="base\tinyxml\libtxml" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option type="2" />
 				<Option compiler="gcc" />
@@ -60,7 +60,7 @@
 				</Compiler>
 			</Target>
 			<Target title="Squirrel">
-				<Option output="sdk\scripting\lib\squirrel" prefix_auto="1" extension_auto="1" />
+				<Option output="sdk\scripting\lib\libsquirrel" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option type="2" />
 				<Option compiler="gcc" />
@@ -74,7 +74,7 @@
 				</Linker>
 			</Target>
 			<Target title="Squirrel std lib">
-				<Option output="sdk\scripting\lib\sqstdlib" prefix_auto="1" extension_auto="1" />
+				<Option output="sdk\scripting\lib\libsqstdlib" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option external_deps="sdk\scripting\lib\libsquirrel.a;" />
 				<Option type="2" />
@@ -89,7 +89,7 @@
 				</Linker>
 			</Target>
 			<Target title="SqPlus">
-				<Option output="sdk\scripting\lib\sqplus" prefix_auto="1" extension_auto="1" />
+				<Option output="sdk\scripting\lib\libsqplus" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option external_deps="sdk\scripting\lib\libsquirrel.a;sdk\scripting\lib\libsqstdlib.a;" />
 				<Option type="2" />
@@ -104,7 +104,7 @@
 				</Linker>
 			</Target>
 			<Target title="scintilla">
-				<Option output="devel\wxscintilla_cb" prefix_auto="1" extension_auto="1" />
+				<Option output="devel\libwxscintilla_cb" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option type="2" />
 				<Option compiler="gcc" />
@@ -205,7 +205,7 @@
 				<Option external_deps="devel\libcodeblocks.a;" />
 				<Option type="0" />
 				<Option compiler="gcc" />
-				<Option parameters="--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen" />
+				<Option parameters="--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen -p=debugCC" />
 				<Option projectLinkerOptionsRelation="2" />
 				<Compiler>
 					<Add option="-DBUILDING_PLUGIN" />
@@ -316,7 +316,7 @@
 				</Linker>
 			</Target>
 			<Target title="Compiler depslib">
-				<Option output="plugins\compilergcc\depslib\depslib" prefix_auto="1" extension_auto="1" />
+				<Option output="plugins\compilergcc\depslib\libdepslib" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option type="2" />
 				<Option compiler="gcc" />

So, Can I have some methods to solve this?

Thank you.

MortenMacFly · « **Reply #1 on:** February 06, 2012, 09:52:50 am »

Quote from: ollydbg on February 06, 2012, 01:50:51 am

So, Can I have some methods to solve this?

A known annoyance: The prefix policy is not correctly applied when the project file is saved. IIRC this is not easily possible because it depends on the compiler settings and a the point where this is written, you don't have access to the compiler (I might be wrong though!!!).

However, it doesn't really matter as C::B will handle this later (on load) just fine.

oBFusCATed · « **Reply #2 on:** February 06, 2012, 10:20:02 am »

Quote from: MortenMacFly on February 06, 2012, 09:52:50 am

However, it doesn't really matter as C::B will handle this later (on load) just fine.

Hm, it matters a lot, because if you're not careful you'll do a useless commit.
Can you please give a better explanation, because I don't think I understood the reason for the bug?

MortenMacFly · « **Reply #3 on:** February 06, 2012, 10:43:15 am »

Quote from: oBFusCATed on February 06, 2012, 10:20:02 am

Can you please give a better explanation, because I don't think I understood the reason for the bug?

Have a look at:
ProjectLoader::ExportTargetAsProject(const wxString& filename, const wxString& onlyTarget, TiXmlElement* pExtensions)
While you do know the extension of the output file by its type, for the prefix you would need access to the compiler to query if and what prefix to apply to dynamic / static libraries.

It's simply not done, have a look at the code starting here:
if (target->GetTargetType() != ttCommandsOnly)

What's missing i something like:

Code

            if (prefixPolicy == tgfpPlatformDefault)
            {
                if (outputFileName.StartsWith(LIB_PREFIX_BY_COMPILER))
                    outputFileName = OUTPUT_FILE_NAME_WO_PREFIX;
            }

MortenMacFly · « **Reply #4 on:** February 06, 2012, 10:50:13 am »

Quote from: MortenMacFly on February 06, 2012, 10:43:15 am

Code

            if (prefixPolicy == tgfpPlatformDefault)
            {
                if (outputFileName.StartsWith(LIB_PREFIX_BY_COMPILER))
                    outputFileName = OUTPUT_FILE_NAME_WO_PREFIX;
            }

...a better quick hack:

Code

            if (   prefixPolicy == tgfpPlatformDefault
                && (   (!platform::windows && target->GetTargetType() == ttDynamicLib)
                    || (target->GetTargetType() == ttStaticLib) ) )
            {
                wxString compilerId = target->GetCompilerID();
                Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
                if (compiler)
                {
                    wxString compilerLibPrefix(compiler->GetSwitches()->libPrefix);
                    wxString outputFileNameWOPrefix;
                    if (outputFileName.StartsWith(compilerLibPrefix))
                        outputFileNameWOPrefix = outputFileName.Mid(compilerLibPrefix.Len());
                    if (!outputFileNameWOPrefix.IsEmpty())
                        outputFileName = outputFileNameWOPrefix;
                }
            }

NOT TESTED, NOT EVEN COMPILED!
...but something like this is needed.

EDIT: Fixed an obvious error, even in pseudo-code ;-)

MortenMacFly · « **Reply #5 on:** February 06, 2012, 10:58:30 am »

Quote from: MortenMacFly on February 06, 2012, 10:50:13 am

...a better quick hack:

Hey, this one should actually already work - can someone try? (I don't have access to Code::Blocks to try myself at the moment).

Edit: Aaaah - nope, something is missing. If I read it correctly, then outputFileName at that point included the full path... that won't work. However, you surely get the idea...

MortenMacFly · « **Reply #6 on:** February 06, 2012, 11:11:19 am »

...OK - another trial. Who will try this:

Code

            if (   (prefixPolicy == tgfpPlatformDefault)
                && (   (!platform::windows && target->GetTargetType() == ttDynamicLib)
                    || (target->GetTargetType() == ttStaticLib) ) )
            {
                wxString compilerId = target->GetCompilerID();
                Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
                if (compiler)
                {
                    wxFileName fname(outputFileName);
                    wxString outputFileNameFile(fname.GetFullName());

                    wxString compilerLibPrefix(compiler->GetSwitches().libPrefix);
                    wxString outputFileNameWOPrefix;
                    if (outputFileNameFile.StartsWith(compilerLibPrefix))
                    {
                        outputFileNameWOPrefix = outputFileNameFile.Mid(compilerLibPrefix.Len());
                        if (!outputFileNameWOPrefix.IsEmpty())
                        {
                            fname.SetFullName(outputFileNameWOPrefix);
                            outputFileName = fname.GetFullPath();
                        }
                    }
                }
            }

?

ollydbg · « **Reply #7 on:** February 06, 2012, 01:03:08 pm »

Quote from: MortenMacFly on February 06, 2012, 11:11:19 am

...OK - another trial. Who will try this:

Code

            if (   (prefixPolicy == tgfpPlatformDefault)
                && (   (!platform::windows && target->GetTargetType() == ttDynamicLib)
                    || (target->GetTargetType() == ttStaticLib) ) )
            {
                wxString compilerId = target->GetCompilerID();
                Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
                if (compiler)
                {
                    wxFileName fname(outputFileName);
                    wxString outputFileNameFile(fname.GetFullName());

                    wxString compilerLibPrefix(compiler->GetSwitches().libPrefix);
                    wxString outputFileNameWOPrefix;
                    if (outputFileNameFile.StartsWith(compilerLibPrefix))
                    {
                        outputFileNameWOPrefix = outputFileNameFile.Mid(compilerLibPrefix.Len());
                        if (!outputFileNameWOPrefix.IsEmpty())
                        {
                            fname.SetFullName(outputFileNameWOPrefix);
                            outputFileName = fname.GetFullPath();
                        }
                    }
                }
            }

?

I test it and the result looks like:

Code

 		<Build>
 			<Target title="exchndl">
 				<Option platforms="Windows;" />
-				<Option output="devel\exchndl" prefix_auto="1" extension_auto="1" />
+				<Option output="devel\exchndl.dll" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="devel" />
 				<Option type="3" />
 				<Option compiler="gcc" />
@@ -24,7 +24,7 @@
 				</Linker>
 			</Target>
 			<Target title="tinyXML">
-				<Option output="base\tinyxml\txml" prefix_auto="1" extension_auto="1" />
+				<Option output="base\tinyxml\txml.a" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="" />
 				<Option type="2" />
 				<Option compiler="gcc" />

MortenMacFly · « **Reply #8 on:** February 06, 2012, 01:05:55 pm »

Quote from: ollydbg on February 06, 2012, 01:03:08 pm

I test it and the result looks like:

Code

-				<Option output="devel\exchndl" prefix_auto="1" extension_auto="1" />
+				<Option output="devel\exchndl.dll" prefix_auto="1" extension_auto="1" />

Hmmm... that is weird. Did you remove the extension policy? The code snippet was intended to be added and not to replace something.

ollydbg · « **Reply #9 on:** February 06, 2012, 01:16:03 pm »

Quote from: MortenMacFly on February 06, 2012, 01:05:55 pm

Quote from: ollydbg on February 06, 2012, 01:03:08 pm
I test it and the result looks like:
Code
-				<Option output="devel\exchndl" prefix_auto="1" extension_auto="1" />
+				<Option output="devel\exchndl.dll" prefix_auto="1" extension_auto="1" />
Hmmm... that is weird. Did you remove the extension policy? The code snippet was intended to be added and not to replace something.

Oh, I removed the original code snippets in the if statement. I'm adding them and test again.
Do you mean like below:

Code

Index: E:/code/cb/cb_trunk/src/sdk/projectloader.cpp
===================================================================
--- E:/code/cb/cb_trunk/src/sdk/projectloader.cpp	(revision 7781)
+++ E:/code/cb/cb_trunk/src/sdk/projectloader.cpp	(working copy)
@@ -1163,8 +1163,29 @@
             target->GetTargetFilenameGenerationPolicy(prefixPolicy, extensionPolicy);
 
             wxString outputFileName = target->GetOutputFilename();
-            if (extensionPolicy == tgfpPlatformDefault)
+            if (   (prefixPolicy == tgfpPlatformDefault)
+                && (   (!platform::windows && target->GetTargetType() == ttDynamicLib)
+                    || (target->GetTargetType() == ttStaticLib) ) )
             {
+                wxString compilerId = target->GetCompilerID();
+                Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
+                if (compiler)
+                {
+                    wxFileName fname(outputFileName);
+                    wxString outputFileNameFile(fname.GetFullName());
+
+                    wxString compilerLibPrefix(compiler->GetSwitches().libPrefix);
+                    wxString outputFileNameWOPrefix;
+                    if (outputFileNameFile.StartsWith(compilerLibPrefix))
+                    {
+                        outputFileNameWOPrefix = outputFileNameFile.Mid(compilerLibPrefix.Len());
+                        if (!outputFileNameWOPrefix.IsEmpty())
+                        {
+                            fname.SetFullName(outputFileNameWOPrefix);
+                            outputFileName = fname.GetFullPath();
+                        }
+                    }
+                }
                 wxFileName fname(outputFileName);
                 fname.ClearExt();
                 outputFileName = fname.GetFullPath();

I tested but it still give the same diff files.

EDIT
Oh, I made a mistake:

Code

-            if (extensionPolicy == tgfpPlatformDefault)
+            if (   (prefixPolicy == tgfpPlatformDefault)

I should preserve a old policy (if statement).

ollydbg · « **Reply #10 on:** February 06, 2012, 01:31:39 pm »

Ok, it works OK now, with this patch:

Code

Index: E:/code/cb/cb_trunk/src/sdk/projectloader.cpp
===================================================================
--- E:/code/cb/cb_trunk/src/sdk/projectloader.cpp	(revision 7781)
+++ E:/code/cb/cb_trunk/src/sdk/projectloader.cpp	(working copy)
@@ -1169,7 +1169,31 @@
                 fname.ClearExt();
                 outputFileName = fname.GetFullPath();
             }
+            if (   (prefixPolicy == tgfpPlatformDefault)
+                && (   (!platform::windows && target->GetTargetType() == ttDynamicLib)
+                    || (target->GetTargetType() == ttStaticLib) ) )
+            {
+                wxString compilerId = target->GetCompilerID();
+                Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
+                if (compiler)
+                {
+                    wxFileName fname(outputFileName);
+                    wxString outputFileNameFile(fname.GetFullName());
 
+                    wxString compilerLibPrefix(compiler->GetSwitches().libPrefix);
+                    wxString outputFileNameWOPrefix;
+                    if (outputFileNameFile.StartsWith(compilerLibPrefix))
+                    {
+                        outputFileNameWOPrefix = outputFileNameFile.Mid(compilerLibPrefix.Len());
+                        if (!outputFileNameWOPrefix.IsEmpty())
+                        {
+                            fname.SetFullName(outputFileNameWOPrefix);
+                            outputFileName = fname.GetFullPath();
+                        }
+                    }
+                }
+            }
+
             TiXmlElement* outnode = AddElement(tgtnode, "Option", "output", outputFileName);
             outnode->SetAttribute("prefix_auto", prefixPolicy == tgfpPlatformDefault ? "1" : "0");
             outnode->SetAttribute("extension_auto", extensionPolicy == tgfpPlatformDefault ? "1" : "0");

MortenMacFly · « **Reply #11 on:** February 06, 2012, 01:59:12 pm »

Quote from: ollydbg on February 06, 2012, 01:31:39 pm

Ok, it works OK now, with this patch:

Good to know. Feel free t commit making oBFusCATed happy... hopefully... ;-)

ollydbg · « **Reply #12 on:** February 06, 2012, 02:16:05 pm »

Quote from: MortenMacFly on February 06, 2012, 01:59:12 pm

Quote from: ollydbg on February 06, 2012, 01:31:39 pm
Ok, it works OK now, with this patch:
Good to know. Feel free t commit making oBFusCATed happy... hopefully... ;-)

OK, done At revision: 7782.

ollydbg · « **Reply #13 on:** July 29, 2013, 10:52:50 am »

Hi, Morten, I need to bump this thread again, as I nowadays still find annoying issue about this:

Quote from: ollydbg on February 06, 2012, 01:50:51 am

Steps to reproduce: (WinXP)
1, open a clean Codeblocks.cbp in a recent debugger branch nightly build.
2, change the command argument for src, like adding "-p=debugCC".
3, close this project.

Now, I can see that:
1, The EOL changing from CRLF to LF

See, the cbp file was saved from CRLF to LF always. This always give me a warning if I commit to the git local repo. (git would say that: warning: LF will be replaced by CRLF in such cbp files in the repo.....)

I trace down and found that in the last stage of saving cbp file, we have such code:

Code

bool TinyXML::SaveDocument(const wxString& filename, TiXmlDocument* doc)
{
    if (!doc)
        return false;

    TiXmlPrinter printer;
    printer.SetIndent("\t");
    doc->Accept(&printer);

    return Manager::Get()->GetFileManager()->SaveUTF8(filename, printer.CStr(), printer.Size());
}

Here, we create a printer object, which has:

Code

class TiXmlPrinter : public TiXmlVisitor
{
public:
	TiXmlPrinter() : depth( 0 ), simpleTextPrint( false ),
					 buffer(), indent( "    " ), lineBreak( "\n" ) {}

Look, it always use lineBreak( "\n" ).

Can we fix it by setting the lineBreak by platform?
Thanks.

thomas · « **Reply #14 on:** July 29, 2013, 01:37:33 pm »

Look, if GIT is too stupid to handle files it shouldn't touch at all, then that's sad. In particular because GIT is a Linux revision control system, and these are Unix line endings. But frankly, it's GIT's problem, not ours. GIT has no reason to look into .cbp files at all, for all it knows, these are binary files, just like .conf files.

Please don't tamper with code that works fine only to make it worse just so some unimportant third party program doesn't complain. If users of this third party program are unhappy with its operation, they can either fix their settings so it properly ignores the files, or they can complain with the maintainer of that program.

There was a similar issue with people editing .conf files in a text editor and complaining that they were broken afterwards. Because, hey, if something looks like you could edit it, then it is totally necessary that you do. I was at some point tempted to rot13 encode config files only for that reason.

oBFusCATed · « **Reply #15 on:** July 29, 2013, 01:58:20 pm »

Quote from: thomas on July 29, 2013, 01:37:33 pm

Look, if GIT is too stupid to handle files it shouldn't touch at all, then that's sad. In particular because GIT is a Linux revision control system, and these are Unix line endings. But frankly, it's GIT's problem, not ours. GIT has no reason to look into .cbp files at all, for all it knows, these are binary files, just like .conf files.

You're too aggressive here! I guess there is some part of your brain that goes in rage-total-destruction-mode when someone mentions GIT

.cbp is not a binary file and this is a good feature! If we wanted people to know that it is a binary file we would have made it such!

Quote from: thomas on July 29, 2013, 01:37:33 pm

There was a similar issue with people editing .conf files in a text editor and complaining that they were broken afterwards. Because, hey, if something looks like you could edit it, then it is totally necessary that you do. I was at some point tempted to rot13 encode config files only for that reason.

But you haven't, because the cbp is better to be a text file.
If the user breaks its file by editing it, then it is totally his fault.
If C::B does something strange on invalid input then it's C::B's fault.

oBFusCATed · « **Reply #16 on:** July 29, 2013, 02:02:18 pm »

ollydbg:
I think there is a way to tell git that the file will be in UNIX EOL mode.
As far as I know git doesn't care much about the EOL. Currently at work I'm using it only Linux with a repo that is in EOL=CRLF and it works ok.
It print warnings but they are harmless.

Also git as far as I know never changes the files. If the file is create in EOL=LF then it is stored as such, if it is in EOL=CRLF then it is stored as such.
But I may be wrong here, because I've not delved too much into this problem...

thomas · « **Reply #17 on:** July 29, 2013, 02:19:21 pm »

Quote from: oBFusCATed on July 29, 2013, 01:58:20 pm

.cbp is not a binary file and this is a good feature!

On the contrary, cbp is a binary file. It is the file that Code::Blocks chooses to store its projects in, using an unspecified, proprietary, and entirely unknown format.
Only by coincidence, this format contains a structure that looks like XML, and only by coincidence there are human-readable strings and line breaks in it.

Users and tools are not meant to look at this file, interprete its contents, or even modify it (incidentially, the format was chosen so the Subversion diff viewer works just fine with cbp files as it is, but that doesn't change the fact that it's a binary file).

stahta01 · « **Reply #18 on:** July 29, 2013, 02:25:28 pm »

Quote from: oBFusCATed on July 29, 2013, 02:02:18 pm

ollydbg:
I think there is a way to tell git that the file will be in UNIX EOL mode.
As far as I know git doesn't care much about the EOL. Currently at work I'm using it only Linux with a repo that is in EOL=CRLF and it works ok.
It print warnings but they are harmless.

Also git as far as I know never changes the files. If the file is create in EOL=LF then it is stored as such, if it is in EOL=CRLF then it is stored as such.
But I may be wrong here, because I've not delved too much into this problem...

Info about Git EOL settings; there appears to be at least 3 different settings that are changeable.

http://git-scm.com/docs/gitattributes#_checking-out_and_checking-in

I know in SVN, the CB way works acceptable in how EOL is done.
Not, sure if adding a EOL for cbp files option to CB is a good idea or not.

Tim S.

oBFusCATed · « **Reply #19 on:** July 29, 2013, 02:41:47 pm »

Quote from: thomas on July 29, 2013, 02:19:21 pm

On the contrary, cbp is a binary file.

Of course it is not, at least in users or my perspective. It is a pure text/xml file. You can pretend it is not, but you've missed the moment to make it binary.
One example of a binary file in xml form is the files generated by visual studio. They are true binary and non-VCS friendly.

p.s. keep in mind that at the moment there is at lease one feature that has no ui and the users must edit the cbp

p.p.s. users want to look at the content of the file, in order to review patches others have pushed to the repos.

ollydbg · « **Reply #20 on:** July 29, 2013, 04:35:59 pm »

Thanks all the replies.
Here is my point:
1, cbp file should be a non-binary file, it makes version control system and code reviewer happy.
2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.
3, It is the same thing as Git, expect that Git print some warning message (maybe svn commit also print some warning, but I don't know), but it is harmless.
I can live with those warnings.

oBFusCATed · « **Reply #21 on:** July 29, 2013, 05:18:04 pm »

Quote from: ollydbg on July 29, 2013, 04:35:59 pm

2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.

If this is the case, our svn is set in a wrong way.

ollydbg · « **Reply #22 on:** July 29, 2013, 05:31:04 pm »

Quote from: oBFusCATed on July 29, 2013, 05:18:04 pm

Quote from: ollydbg on July 29, 2013, 04:35:59 pm
2, I just check the eol property of the cbp file in my svn repo, it was "native", which means if the file in the svn server is stored in LF, when it was checkout in Windows system, it use CRLF. When you modify the cbp under C::B, the cbp file was saved in LF, but I believe when I did a commit on the svn, it just did the correct conversion of EOL.
If this is the case, our svn is set in a wrong way.

This reveals another issue, if we modify the cbp file eol svn property to "LF" (see: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style), then when a patch containing a change on both a cbp and a cpp, what will the generated patch files' eol be? Mixed LF and CRLF (LF for patch hunks of cbp, and CRLF for patch hunks for cpps)?

stahta01 · « **Reply #23 on:** July 29, 2013, 05:56:33 pm »

Quote from: ollydbg on July 29, 2013, 05:31:04 pm

This reveals another issue, if we modify the cbp file eol svn property to "LF" (see: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style), then when a patch containing a change on both a cbp and a cpp, what will the generated patch files' eol be? Mixed LF and CRLF (LF for patch hunks of cbp, and CRLF for patch hunks for cpps)?

Not from me since I use "--extensions --ignore-eol-style" in creating my patches.

Tim S.

News:

Author Topic: Issue about saving the cbp project file (Read 18135 times)