So this is weird...I have a $scope variable in my controller assigned to a string.
I have since changed that string.
It is serving up the original string that is long gone.
I know, I know: clear your browser cache. Did that. It's still there. I tried Firefox and Safari. You know what? I didn't have Opera installed, so I downloaded and installed Opera, and the old string even showed up in Opera, which my computer -- a 2015 MacBook Pro running the latest version of OSX El Capitan.
I know, I know: flush the Apache cache, even though it's disabled on a Mac and I never enabled it. Fine. I ran htcacheclean -r -p on the directory in the code, and I'm still getting the old code.
I know, I know: make sure you didn't accidentally point to the wrong directory. Uhmm....thing is, there's only one copy of this code on the entire drive. Plus, even though the new $scope variable source code changes are being ignored, I can make changes to the functions in the exact same file but it's definitely honoring those changes.
For the record, here's the code that's not changing:
$scope.credits = '<div class="credits" id="show_cred">';
$scope.credits += '<marquee behavior="scroll" direction="up">';
When I load up the page, it's showing that the string is:
<div class="credits">
And that's it. No ID. No "marquee." (And yes, I do have the corresponding closing tags later in the string, and they do get rendered...well, except the closing "marquee" tag because, well, that's a new line that it's refusing to acknowledge.) I went so far as to change that entire $scope.credits variable to be nothing but this:
$scope.credits = '';
....but the old variable still renders.
I tried merging those two lines into a single line, but nope.
In the same controller file -- again, the same file -- it actually does reflect modifications I make to functions, but not variables.
This...is the most bizarre situation I've seen in all my years as a web dev. This is definitely not browser-based. It's definitely not Apache's cache (unless I'm lied to and that it is enabled on a Mac and that the htcacheclean command is a placebo).
What do you all make of this?
Well, I did come up with a solution, and it's something I should have done from the beginning.
Instead of having a buttload of HTML assigned to a scope variable, I put it in the view itself and attached it to an ng-if directive. That fixed my problem in that the site now does what I intended it to do.
However, it doesn't actually answer the question as to how in the world the variable's old value was set in stone.
Related
I'm trying to write a custom filesystem for Tcl using the Tclapi (it's work related, won't go into details), but I'm stuck trying to figure out why this is not working.
In this code segment I'm getting the original/native Tcl_Filesystem, copying over all its contents (function pointers) to my_fs, and then calling Tcl_FSRegister on my_fs. Very simple, thought it should work.
// global scope
const Tcl_Filesystem *ori_fs;
Tcl_Filesystem *my_fs;
...
// in Init
// Get the original Tcl_Filesystem.
Tcl_Obj *root_obj = Tcl_NewStringObj("/", -1);
Tcl_IncrRefCount(root_obj);
ori_fs = Tcl_FSGetFileSystemForPath(root_obj);
Tcl_DecrRefCount(root_obj);
// create a duplicate of the original Tcl_Filesystem struct.
my_fs = malloc(sizeof(Tcl_Filesystem));
memmove(my_fs, ori_fs, ori_fs->structureLength);
int ret = Tcl_FSRegister((ClientData)1, my_fs);
if (ret == TCL_ERROR) {
...
When I ran
load <path to .so>/my_fs[info sharedlibextension]
# sanity check
puts [pwd]
set fp [open test.txt]
however, I get this
<my current directory>
while executing
"open test.txt"
invoked from within
"set fp [open test.txt]"
(file "test.tcl" line 3)
Notice how "puts [pwd]" works but not "open test.txt" ?
Replacing "my_fs" with "ori_fs" in the call to Tcl_FSRegister seems to work...
I've already spent far too much time trying to figure this out. I would appreciate if anyone could help me with this!
The native filesystem is special. In particular, there's some places where its identity is used directly: for example, it's the only FS that can have temporary files made on it, it's assumed to own the roots, and it is handled specially in path management. (Well, according to where in the source code there are direct references to the Tcl internal variable tclNativeFilesystem, which isn't something you can cheat at. It's also possibly in read-only memory, so you can't hack around this.)
For most sane uses of a Tcl virtual filesystem, this doesn't matter. Temp files have to be native because you may well be passing them to the OS (e.g., for loading libraries or running programs that were inside the VFS; with these, they have to be copied out or the OS will think “what are you talking about?!”) and you put the things that you are mounting somewhere other than the native root. So long as you're not trying to use a VFS as a security measure (not recommended; there are safe interpreters for that as they offer a stronger sandboxing solution) it shouldn't be a problem as you can just make your code know that it needs to work below a particular location to get things done. (FWIW, it's a bad idea to cd anyway, except in response to user requests, since it changes the meaning of user-supplied relative paths, so good code handles “make everything relative to a defined location” from the start.)
I am doing a post(someUrl).body(RawFileBody("100_msg.json")).asJSON.
However I keep getting an error file 100_msgs.json doesn't exist.
I am passing a -bdf parameter that is pointing to a folder that contains the said json, but the same result. (At some point, I definitely saw something work, but not anymore)
I am using IntelliJ IDEA and configured a gradle to invoke Gatling. Am new to Scala, so debugging this seems a herculean task. Any pointers ?
Oops my bad. I had a space in the file name.
I have stage server which I use it with Xmanager. In the stage sever,after whatever I choose using the mouse,a "^C" will appear automatically after $.For example ,I choose "system/" with mouse,and a "^C" soon appears in the command line.
It never happened before until yesterday I tried "Shift+Ctrl+V" which means "copy" after I choosing the command line which I wanted to copy, but it didn't work although I tried several times.And then the problem I described existed.
It's really confusing,and I don't whether "^C" has any bad effect.
How to resolve this problem?Anyone knows why it happened?
The reason causing this problem is that I opened youdao dictionary simultaneously with its function of catching words on the screen on. Just close it and the problem won't happen again. I don't know why maybe it has something to do with the software's compatibility.
On OS X, I generated a set of ctags for the system includes using the following command:
ctags -f c -h ".h" -R --c-kinds=+p --fields=+iaS --extra=+q /usr/include
This was run inside of a ~/.vim/ctags/ directory, where I put all of the ctags I generate for system-wide header files (I also have stuff for ROS and CPP that I load conditionally, but that's neither here nor there).
Anyway. The ctags file is set correctly in my .vimrc, and vim can definitely see the ctags, but for some reason the autocomplete popup will only display results from #included header files if I write out the entire symbol and then start backspacing. As an example, if I #include <string.h> in a project, and then I want to call strlen(), and I start to type str in to the active vim buffer, I will only get results for symbols that are currently in the vim buffer. But, if I type out strlen and then start backspacing one or two characters and hit <C-n>, the popup menu will be populated with matches from any other included header files.
EDIT: Turns out, if I just hit "s" then <C-n>, it works as well. So the problem seems to be that it only works if the popup menu is launched manually. Which makes me think that it's a plugin problem (see below)
Additional information:
completeopt is set to completeopt=menuone,menu,preview,longest
I have OmniCppComplete, which I suppose could be interfering with the behavior. It is currently not being conditionally loaded for C++ files only. If you want me to edit and post my OmniCppComplete settings from my .vimrc, just ask.
I also have AutoComplPop installed, but I haven't done anything to configure it, so it's running with its default settings. Haven't really researched the plugin, so no idea if some of it's behavior could be interfering with the results.
I have AutoTag and TagBar installed, but those should only be fiddling with the current directory's local tagfile.
I'm honestly pretty new to Vim, and I just have no idea where to start debugging this issue, whether it be with a random plugin or with my .vimrc settings.
Vim has many specific completion mechanisms.
<C-n> and <C-p> use many sources defined by the complete option. By default, they will provide completion using the current and all loaded and unloaded buffers, tags and included files. While you can usually get quite useful suggestions with these, it is a bit of a "catch-all" solution: it is not reliable at all if you work on reasonably large projects.
<C-x><C-]> uses only tags so it may be a little more useful to you.
And there are many more, see :h ins-completion.
Omni completion is smarter: it typically runs a custom filetype-specific script that tries hard to provide meaningful completion. It is triggered by <C-x><C-o> and you can read about it in :h ft-c-omni. Omni completion is often a better choice when working with code.
Because you have two overlaping "auto"-completion plugins it's hard to say what completion mechanism is at work. You should disable those plugins and play around with the different completion mechanisms available to you.
I have not mastered this yet, but I do think the following observation may be of help.
Vim's default auto complete which can be quite noisy, often gets in the way of what you call with <C-x><C-o>. Specifically, I found myself calling up my tags based completions with <C-x><C-o> only to have them replaced with continued typing with Vim's default suggestions using my open buffers.
The suggestion of shutting off one of the plugins makes sense. In my case the key was how to shut down Vim's default behavior. I have seen several people (and to which I now include myself), set the length of the expression to a high number before triggering Vim's default. For me that is:
let g:deoplete#auto_complete_start_length = 99
... this way you eliminate the default layer of completions that comes and goes regardless of the commands you intended to inform your work.
This still feels like a hack but it helps keep my work focused on the tag-based completions.
FYI: I use NVIM on a Mac.
I had some lua code with the following line:
JSON = loadfile("JSON.lua")()
The file JSON.lua is in the same directory as the lua code that line came from. This code worked for me for a while, and then, without my changing either the lua source, or the JSON.lua, or permission of any of the files, or the directory from where I was running the lua code, I started getting a nil error on that line. (I simply recall NO relevant changes that could have any impact on the lua code.)
Adding an assert revealed that the error was caused by the file not being found. Playing with file permissions, restarting my machine didn't resolve the issue, and pulling back code that I had checked in and was working perfectly did not resolve the error.
I resolved the error by changing the line above to provide the absolute path to that JSON.lua file.
Is there anything explaining why the code without the absolute path could have worked for a while and then stopped working?
Note: This behavior of working and then not working happened to me twice over a week. I am puzzled and though I have now found a fix, I am really curious as to the explanation for that intermittent behavior.
Lua uses package.path, whose default value comes from the environment variable LUA_PATH if it is set, as the list of directories to search. You can put . of the front of this list to load files from the current directory, or you can put your files in a path on the list.
A late answer on this, as I found exactly the same problem.
First, contrary to the previous answer, loadfile doesn't use the package.path search path. It only looks in the specified directory. And if you don't specify a directory, it only look in the 'current directory'. I can't explain exactly why it stopped working for you, but probably your Lua code is somehow being run with a different 'current directory' than previous.
There are two possible fixes: One is to specify an absolute path to loadfile.
JSON = loadfile("c:\\my_folder\\JSON.lua")()
The alternative fix depends on the particular library you're using, which I suspect is Jeffrey Friedl's Lua JSON lilbrary. Because this supports the newer Lua module mechanism, you can just load the module with require, which does support the package.path search path.
JSON = require("JSON")