I stumbled upon an issue when I recently switched to VSCode as editor.
I have several projects that have a full (medium-complex+) autotool
setup and they all work fine. However I discovered that the makefile plugin for VSCode in order to initialize itself (and finding all dependencies and targets) starts by running
make --dry-run --always-make
as first time initialization. This throws the makefile (or actually the
re-config) into an endless loop re-running "configure" (since the targets are never resolved to disk).
I have also confirmed this behavior with the smallest possible autoconf/automake
setup. I can also kind-of understand why this happens (and it seems make
have an internal way to discover this exact situation with the special
variable MAKE_RESTARTS that could possible be used to detect a cyclic
behavior)
Is there a known best-practice workaround ? or is it even a reasonable expectations that these two options in combination should work? (Good to have a second opinion before I go down the rabbit-hole of reminding myself of all the details I forgot about the magical land of autotools)?
Why some data on server-side are still stored in DBC files, not in SQL-DB? In particular - spells (spells.dbc). What for?
We have a lot of bugs in spells and it's very hard to understand what's wrong with spell, but it's harder to find it spell...
Spells, Talents, achievements, etc... Are mostly found in DBC files because that is the way Blizzard did it back in the day. It's true that in 2019 this is a pretty outdated way to work indeed. Databases are getting stronger and more versatile and having hard-coded data is proving to be hard to work with. Hell, DBCs aren't really that heavy anyways and the reason why we haven't made this change yet is that... We have no other reason other than it being a task that takes a bit of time and It is monotonous to do.
We are aware that Trinity core has already made this change but they have far more contributors than we do if that serves as an excuse!
Nonetheless, this is already in our to-do list if you check the issue tracker at the main repository.
While It's true that we can't really edit DBC files because we would lose all the progress when re-extracted or lost the files, however, we can modify spells in a C++ file called SpellMgr.
There we have a function called SpellMgr::LoadDbcDataCorrections().
The main problem while doing this change is that we have to modify the core to support this change, and the function above contains a lot of corrections. Would need intense testing to make sure nothing is screwed up in the process.
In here by altering bits you can remove or add certain properties to the desired spells instead of touching the hard coded dbc files.
If you want an example, in this link, I have changed an Archimonde spell to have no cast time.
NOTE:
In this line, the commentary about damage can be miss leading but that's because I made a mistake and I haven't finished this pull request yet as of 18/04/2019.
The work has been started, notably by Kaev. I think at least 3 DBCs are now useless server side (but probably still needed client side, they are called DataBaseClient for a reason) like item.dbc.
Also, the original philosophy (for ALL cores, not just AC) was that we would not touch DBC because we don't do custom modifications, so there was no interest in having them server side.
But we wanted to change this and started to make them available directly in the DB, if you wish to help with that, it would be nice!
Why?
Because when emulation started, dbc fields were 90% unknown. So, developers created a parser for them that just required few code changes to support new fields as soon as their functionality was discovered.
Now that we've discovered 90% of required dbc fields and we've also created some great conversion tools for DBC<->SQL, it's just a matter of "effort".
SQL conversion is useful to avoid using of client data on server (you can totally overwrite them if you don't want to go against EULA) or just extends/customize them.
Here you are the issue about DBC->SQL conversion: https://github.com/azerothcore/azerothcore-wotlk/issues/584
I've been developing a lot of small web development projects in various IDEs, and find myself laboriously typing in jslint configuration headers to silence JSLint. Its warnings and errors are all valid, and I want to keep JSLint in my work cycle, but I spin up 2-3 isolated environments a day, sometimes from generators in Yeoman, other times by hand. These all end up with gripes from JSLint that require the following in every .js file:
/*jslint browser:true*/
/*global require,yada,yada,yada*/
JSHint has a wonderful feature whereby you can declare all these in a parent folder using the body of the .jshintrc file. Does JSLint have something like this? It seems like such an obvious addition, but I can find nothing like this which will work across IDEs (Visual Studio, IntelliJ, Brackets, Sublime Text,...).
I found this for .NET, but I find Visual Studio heavy for projects I might only spend a couple hours on and then throw away (https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings).
Does someone have some insight on this?
Edit: (See my new answer below.)
I think the quick answer is that setting global settings for every file you JSLint is the job of your IDE or favorite text editor. That is, JSLint is essentially just a big javascript file. It doesn't care about file paths, etc, and won't look for a server-wide config.
I mean, you can change the options used when JSLint is called, but that essentially reduces to the same problem you have now.
So then the question is, if you don't like Visual Studio, what tools do you use? In VS, I've used this tool and liked it a good deal. I think that's different (as in not forked or related, but I could be wrong) than the one you found. In Sublime Text, there are two. I've been using Darren Deridder's, but I get the impression that it's the less popular of the two. Etc etc.
So this isn't a javascript/JSLint question so much as a JSLint wrapper question.
It should be said that JSLint's code is very clean, and it's easy to rig up your own process using Node or something similar. I've done it with JavaScript.NET, though I'd use Node if I was doing it again.
And I'd also suggest you consider keeping the file-by-file JSLint headers. I tend to do so, and it keeps your use "excuses" to a minimum, keeping your code tighter. It's way too easy to get a giant /*global ...*/ header line, for instance, if you have a lot of shared config info. It also means that when someone else uses a "shell" tool different than yours to JSLint your files, you know they're using pretty close to your intended accepted behaviors.
So the literal answer to your question is, "No, JSLint doesn't inherently support a box-wide config file." The longer answer is, "Tell us where you do like to work." ;^)
EDIT: Debated staying out of the usual 'Hint vs. 'Lint discussion, but I will quickly say I like how you're thinking. JSLint is more draconian, but JSLinted code means something more specific than code that's been JSHinted. I won't argue that more specific means better, per se, but I will say that I see JSLint's draconian-ness to be an advantage. It might not be the only way to do something, but there's nothing that Crockford's telling you that's a bad idea, and it's nice to get familiar with those conventions. In the parlance of my times, Crockfords's not wrong, Walter.
EDIT 2: So Brackets looks like it's come a long way since I last used it. Seems to have JSLint by default.
It looks like you can set global JSLint options using the jslint.options setting in your preferences file (and there might be/have been a goal to make that a more interactive UI eventually), like this...
{
"debug.showErrorsInStatusBar": false,
"styleActiveLine": true,
"jslint.options": { "sloppy":true, "white":true, "browser": true }
}
And it does allow settings at the top of the file to override these settings.
This really is approaching a golden age of text editors. I still fall back on VIm a lot, but mainly live VS and Sublime Text, with even jEdit, Coda, and PhpStorm for specific tasks. Looks like this might be my new Sublime for Node & html frontend dev. The quick CSS edit is wonderful, though bindings will complicate it. Thanks!
While the previous excepted answer is an excellent one (and many thanks to its author for making it even better over time!), the world has moved on from JSLint. I'd recommend to anyone reading this very old question that you seriously consider chucking JSLint out of your development cycle in favor of its very effective successor, ESLint. For an even better experience, I'd suggest taking a hard look at the ES7 vs. TypeScript paths, with TSLint being your best option for TypeScript linting.
However, for the development experience that trumps even these modern libraries, go directly for Prettier.js. With Prettier, your linting woes become irrelevant, since Prettier will rewrite your code in an opinionated manner every time it's run.
For the best results with Prettier, add the packages "lint-staged" and "husky" to your dev-dependencies, then add the following in your package.json:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,css,md}": [
"prettier --write",
"git add"
]
},
This will force Prettier's auto-linting behavior to run every time Git's commit command runs.
I can't tell you what a relief using Prettier has been for the front-end development teams and projects I am responsible for. We've gone from code reviews bleeding with linting correction comments to zero almost immediately. Feedback from the teams has been universally positive.
The only modification I've made has been to the tabs-vs.-spaces setting. I've modified my .prettierrc.json file to select tabs instead of spaces, because use of spaces at different widths causes dirty git merge histories. You can't control the indentation of 250+ developers spread over multiple hemispheres, some of whom drop in and out of the project before you even know their names. So, setting tabs as the default indentation allows all of the developers to operate with the indentation they're comfortable with without modifying lines in Git. Here's my .prettierrc.json file, with some other slight modifications:
{
"arrowParens": "always",
"bracketSpacing": false,
"singleQuote": true,
"useTabs": true,
"trailingComma": "none"
}
Issue solved, see answers for details.
I would like to run some code (with knitr) on a more powerful server and then maybe have the possibility of making small changes on my own laptop. Even copying across the entire folder, it seems that the cache is rebuilt when re-compiling locally, is there a way to avoid that and actually use the results in the cache?
Update: the problem arose from different versions of knitr on different machines.
In theory, yes -- if you do not change anything, the cache will be kept. In practice, you have to check carefully what the "small changes" are. The documentation page for cache has explained when the cache will be rebuilt, and you need to check if all three conditions are met.
I wonder if in addition to #Yihui's answer if the process of copying from one machine to another changes the datetimes on the files so that they look out of date even when nothing has changed.
Look at the dates on the files involved after copying. If you can figure out which files need to be newer than others then touching them may prevent the rebuilding.
Another option would be to just paste in the chached pieces directly so that they are not rerun (though that means you have to rerun and repaste manually if you change anything in those parts).
My team now has an SVN + Ankh setup in ASP.NET with trunk, branches, and tags. We switch branches and work on code, but many times there will be inexplicable conflicts in files after simple changes. Why is this? I suspect we simply don't understand enough of how this works. Are there any do's and don'ts, or how should we be approaching our daily changes and commits, without causing conflicts? Is there a basic pecking order of operations to perform to achieve SVN zen? Are we updating before committing or something? Any help is greatly appreciated.
Always update before commit. If you really work with branches don't use switch or only if you really undstand the switch command and how it works otherwise checkout a branch into a fresh working copy in other words create a new one.
Always branch, merge on the solution element, make sure you're fully up to date before merging (ankhsvn will warn about this), also make sure you have no modified files before merging.
Read up on svnbook for when to use normal merging and when to use reintegrate.
Finally, if a conflict does occur, make sure you have a good 3way merge tool to solve the conflict. AnkhSVN recognizes a lot of them automatically, but I really like source gear diffmerge