I'm working on a program that does a clang-format check of any newly submitted git files and shows a diff of what the user needs to change to match the correct format.
The issue here is that I've already run clang-format on the current git repo, and when I run it again (on the already clang-formatted file), it decides to continue to make changes. One of the examples is:
1294c1294
< // 3)
---
> //3)
clang-format can't seem to decide whether or not it wants a space here. Another example:
229,230c229
< * testCodeUnknown OBJECT IDENTIFIER ::=
< *{
---
> * testCodeUnknown OBJECT IDENTIFIER ::= {
This is within a comment, so it really doesn't matter, but it's making a mess of the 1600 files I have to check and diff when clang-format doesn't produce consistent results.
I am calling clang-format the same way both times, other than the fact that the actual format includes -i and the check pipes stdout to a temp file.
Is this expected behavior? Is there a way to get clang-format to make up its mind (do I have to explicitly set these values in the .clang-format file?)
Edit
As per this question (clang-format makes changes to an already formatted file), this is an idempotency bug in clang-format. I will further look into reproduction cases, but I need some help on figuring out what rule this is so I can potentially just not implement that rule as a workaround
Related
I would like to obtain the LaTeX code associated with this theory. Previous answers only provide links to the documentation. Let me describe what I did.
I went to the directory of Hales.thy and executed isabelle mkroot, followed by isabelle build -D ., which generated a file named document and a *.pdf file which was suspiciously (nearly) empty. Modifications of this command by adding Hales.thy as a parameter didn't succeed.
I would appreciate if someone could describe briefly the commands needed.
As a precaution, copy the file Hales.thy into a new directory that does not contain any other files and run isabelle mkroot again.
If I understand correctly, your theory contains sorry. In this case, for the build to succeed you need to enable the quick_and_dirty mode. For this, before the first occurrence of sorry in your theory file, you need to insert declare [[quick_and_dirty=true]].
Your theory contains raw text that is not suitably formatted. Try replacing the relevant lines with the following: text‹The case \<^text>‹t^2 = 1› corresponds to a product of intersecting lines which cannot be a group› and text‹The case \<^text>‹t = 0› corresponds to a circle which has been treated before›.
Once this is done, you should be able to use the ROOT file in the appendix below. As you can see, I have specified the theory file explicitly and also added the relevant imported sessions.
Appendix
session Hales = HOL +
options [document = pdf, document_output = "output"]
sessions
"HOL-Library"
"HOL-Algebra"
theories
"Hales"
document_files
"root.tex"
My gitignore file says nothing about podfiles. In fact, I can make it empty, and still get the same result - my 'Podfile' is being ignored. If i change it's name to something different, it sees it, but otherwise just ignores it. I'm not sure why.
There's a nifty little utility called check-ignore* that serves exactly this purpose. Example use:
git check-ignore -vn path/to/Podfile
It'll output the file, line number and pattern that makes git exclude the file.
* fun trivia: check-ignore was born right here at Stack Overflow. So go forth and thank Adam Spiers! (-:
say i have this line of code :
Object.Property.field;
Object.Property:FunctionName();
in all my sublime languages if i was to double click "Property" on either line, it would select just that word.
For some reason my lua/lua love2d syntax highlighting selects the whole line up to the ":"
How can I change this behavior, so it will only select the single word?
The reason this is occurring is because of a somewhat strange addition to the Lua Love plugin, which I assume you're using. You're using Sublime 2, so select Preferences -> Browse Packages... to open up your Packages folder, then open the Lua Love subfolder. There is a file called completions.py, which has this content:
#completions.py
import sublime
import sublime_plugin
import re
class LoveCompletions(sublime_plugin.EventListener):
ST = 3000 if sublime.version() == '' else int(sublime.version())
def on_query_completions(self, view, prefix, locations):
if self.ST < 3000 and ("lua" in view.scope_name(locations[0])):
seps = view.settings().get("word_separators")
seps = seps.replace('.', '')
view.settings().set("word_separators", seps)
Even if you don't know Python, the logic is pretty easy to follow. It sets the variable ST to Sublime's version, which is 3000+ if you're using ST3 (current build is 3061), and is 2221 (I think) for ST2. It then sets up an event listener (the process is always running in the background) checking to see if the Sublime version is less than 3000 (you're using ST2) and you have lua in your current scope (basically, your file is source.lua or source.lua.love, if you're using the plugin's language definition). If both of those are true, it removes the . character from your "word_separators" setting, which is defined in Preferences -> Settings-Default and can be overridden in Preferences -> Settings-User.
The word_separators setting controls what characters are considered to be word separators when double-clicking to select a word. Its default value is ./\\()\"'-:,.;<>~!##$%^&*|+=[]{}`~? so, for example, if you double-click on the foo part of foo-bar Sublime will only select foo, but if you double-click on the foo part of foo_bar Sublime will select the whole thing (since - is in word_separators). . is in word_separators by default, so double-clicking on foo in foo.bar will only select foo, which is expected behavior for most people, I would assume. However, this cute little plugin removes . from word_separators in Sublime Text 2, so in your case clicking on Property selects everything from the beginning of the "word" (the whitespace before Object) to the next word separator - the :, in the case of your second example.
OK, so we know what the problem is, how do we fix it? First, while you're in Packages/Lua Love, just delete completions.py altogether. There's no harm in doing so, and in fact it's actually causing harm by being there. Make sure you restart Sublime after deleting the file. Next, open Preferences -> Settings-User and add . back into the word_separators list, anywhere between the beginning and ending double-quotes. Save that file, go back to your source code, and double-clicking should once again behave normally.
Good luck!
EDIT
I submitted this pull request to delete the completions.py file from the plugin's Github repo, and it was just merged, so hopefully users in the future won't have to deal with this :)
I have a doubt about indicating a path in makefile and I'd like to have a clarification.
Suppose my structure is made this way:
/home/machinename/softwarefolder/mainfolder
--------------------------------------------> /subfolder1
--------------------------------------------> /subfolder2
This means that both subfolder1 and subfolder2 are at the same nesting level in /mainfolder.
Now I'm compiling something inside subfolder 2 (this means that I cd to that folder) that uses a configure file with a macro pointing to a path that, in my case, it's in subfolder1.
This configure file used by the program in subfolder2 to compile is generated automatically by the program itself after running ./configure
The automatically generated configure file has the macro defined this way
MACRO = ../subfolder1
Do the two dots (..) indicate, as in the cd command, "go back one step" (and, therefor, the configure file is pointing to the right folder)?
If the answer to the first question is "no", then why substituting the aforementioned macro with
MACRO = /home/machinename/softwarefolder/mainfolder/subfolder1
generates a "missing separator" error in compile-time?
Sorry for the probably trivial question and thanks for the help!
Make doesn't interpret the content of variables in any way, for the most part. The question of how the .. will be interpreted depends entirely on where the variable is used. If it's used in a place where a path like ../subfolder1 makes sense, then that's how it will be interpreted. If not, not.
Since you don't show how $(MACRO) is used, we can't help. But in general the answer to your question is "yes, it means go up to the parent directory".
As for your second question, there is no way I can envision that changing just that one line will result in a "missing separator" error. Maybe your editor "helpfully" made other changes to the file such as removing TABs and substituting spaces, or adding TABs? TAB characters are special in makefiles.
If you want help with the second question you must provide (a) the exact error you received (cut and paste is best), and (b) the exact text of the rule in the makefile at the line number specified in the error message.
I just caught myself doing something I do a lot, and wanted to generalize it, express it, share it and see who else is following this general practice, to find some other example situations where it might be relevant.
The general practice is getting something wrong first, on purpose, to establish that everything else is right before undertaking the current task.
What I was trying to do, specifically, was to find examples in our code base where the dojo TextArea widget was used. I knew (because I had it in front of me - existence proof) that the TextBox widget was present in at least one file. So I looked first for what I knew was there:
grep -r digit.form.TextBox | grep -v
svn
This wasn't right - I had made a common (for me) mistake of leaving off the star, so I fixed that:
grep -r digit.form.TextBox * | grep
-v svn
which found no results! Quick comparison with the file I was looking at showed me I had misspelled "dijit":
grep -r dijit.form.TextBox * | grep
-v svn
And now I got results. Cool; doing it wrong first on purpose meant my query was correct except for looking for the wrong thing, so now I could construct the right query:
grep -r dijit.form.TextArea * | grep
-v svn
and be confident that when it gave me no results, it was because there are no such files, and not because I had malformed the query.
I'll add three other examples as answers; please add any others you're aware of.
TDD
The red-green-refactor cycle of test-driven development may be the archetype of this practice. With red, demonstrate that the functionality doesn't exist; then make it exist and demonstrate that you've done so by witnessing the green bar.
http://support.microsoft.com/kb/275085
This VBA routine turns off the "subdatasheets" property for every table in your MS Access database. The user is instructed to make sure error-handling is set to "Break only on unhandled errors." The routine identifies tables needing the fix by the error that is thrown. I'm not sure this precisely fits your question, but it's always interesting to me that the error is being used in a non-error way.
Here's an example from VBA:
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo. [OR, Option Explicit isn't set, which is the post topic.]
I also use this trick, several times an hour at least.
arrange - assert - act - assert
I sometimes like, in my tests, to add a counter-assertion before the action to show that the action is actually responsible for producing the desired outcome demonstrated by the concluding assertion.
When in doubt of my spelling, and of my editor's spell-checking
We use many editors. Many of them highlight misspelled words as I type them - some do not. I rely on automatic spell checking, but I can't always remember whether the editor of the moment has that feature. So I'll enter, say, "circuitx" and hit space. If it highlights, I'll back up over the space and the "x" and type another space - and learn that I spelled circuit correctly - but if it doesn't, I'll copy the word and paste it into a known spell-checker to see whether I did.
I'm not sure it's the best way to act, as it does not prevent you from mispelling the final command, for example typing "TestArea" or something like that instead of "TextArea" (your finger just have to slip a little for such a mistake).
IMHO the best way is to run your "final" command, but on two sample files first : one containing the requested text, another that doesn't.
In other words, instead of running a "similar" command, run the real one, but over "similar" data.
(Not sure if this would be a good idea to try for real!)
For example, you might give the system to the users for testing and tell them the password to get started is "Apple".
You know the users are fully up and ready to test (everything is installed and connections to databases working) when they contact you and say the password doesn't work (it's actually "Orange").