Unseen delays in changing div class . . - classname

I know a lot of questions must start with "This is odd" , but, ummm, this is odd.
I have some code which takes a while to run. So I've created a 'spinner' in CSS.
It's initiated, within a function, like this
document.getElementById("spinner").className = "spinner";
The I run the main function, which ends like this :
document.getElementById("spinner").className = "spinner_hidden";
It doesn't work, the spinner never shows . . . BUT! If I add an 'alert' after the first line (the class-change to show the spinner), it works!
As a test, I've tried deleting the last line, then the spinner shows, (but doesn't get cleared of course) so I know that the first line is working ok.
I've tried adding a JS delay instead of the alert, but no dice.
Can anyone help me with this oddity? Many Thanks.


Ho-hum . . . no response.
This may seem like a trivial question, but I think it's a nice demonstration of the impenetrable peculiarities of JS program-flow.
I’ve tried everything I can think of to fix this. That includes forcing the functions involved to ‘async’ (and to ‘sync’) - inserting a whole variety of ‘wait’ or ‘sleep’ routines – I’ve even tried putting the class changes into ‘for’ loops so that they have to be executed in the correct order.
Nothing works.
JS insists on executing the last line before its due time.
Good luck to all who attempt to use JS to do things in the order that the programmer is requiring . . .

Related

Cypress Assertions contradictions?

So i think this is one area that I run into issues with, and despite Cypress's amazing documentation assertions sort of feel lacking (but maybe thats because they use Chai assertions and I should be looking there? but even then i've run into confusion).
Anyways, it seems like when I am asserting on some items within cypress I return into conflicting results and I can't seem to pinpoint any reason why.
A few examples specifically:
Why does should(‘contain’,'{Some Text}) search child elements but should(‘have.text/value’,{Some Text}) does not? Or at least thats how it appears? I can't find any documentation that states this
In the example above I noticed this when having a cy.get on an angular dropdown toggle with a <span> within it (that contains the text).
Another oddity is have.text vs have.value. I've noticed sometimes works when the other doesn't. For example input fields only have.value works but not contains or have.text. Is there any reason for this?
I guess im trying to figure out if there is some cheat sheet/guide to when to use each one because it's mostly been trial and error for me (But i'd like to know "why" one works and the other doesn't).
Thanks!

When cola.js fails, what's a fast way to find out what went wrong?

When cola.js fails, how do you find out what went wrong?
I don't have a minimal reproducible example, because that will likely take hours of debugging to make, and if I had it, then it wouldn't be an example of what I'm asking about. I'm hoping to hear of a way to quickly find out what's gone wrong. Presumably it's some bad data in my graph. But how can I tell what the bad data is?
The screenshot below illustrates a typical situation where something has gone wrong. Various NaNs are reported, there are a bunch of Uncaught TypeErrors, and an Assertion fails. There are a whole lot of local variables, all named with a single letter. Clicking and looking at them shows that a NaN got into a coordinate somewhere, as suggested by the previous error messages. It looks like sometime earlier, something got a null when it needed some sort of list-like data structure. How can I quickly find out what was the bad data that got into the graph?
I'm using cola.v3.min.js.
Details
I'm looking for a general approach to finding this kind of error, but here's the specific data that produced the errors in this example. Each line is the argument passed to cy.add() (as suggested by Stepan T.—and printing out everything passed to cy.add() might turn out to be the first step of the answer!).
{"group":"nodes","data":{"id":1,"label":"Workspace","parent":[]},"position":{"x":45,"y":0}}
{"group":"nodes","data":{"id":2,"label":"Target(121)","parent":[1]},"position":{"x":5,"y":0}}
{"group":"nodes","data":{"id":3,"label":"WantFullySourced","parent":[]},"position":{"x":50,"y":0}}
{"group":"nodes","data":{"id":4,"label":"Brick(120)","parent":[1]},"position":{"x":10,"y":0}}
{"group":"nodes","data":{"id":5,"label":"Avail","parent":[]},"position":{"x":55,"y":0}}
{"group":"nodes","data":{"id":6,"label":"Brick(1)","parent":[1]},"position":{"x":15,"y":0}}
{"group":"nodes","data":{"id":7,"label":"Avail","parent":[]},"position":{"x":60,"y":0}}
{"group":"nodes","data":{"id":8,"label":"Brick(2)","parent":[1]},"position":{"x":20,"y":0}}
{"group":"nodes","data":{"id":9,"label":"Avail","parent":[]},"position":{"x":65,"y":0}}
{"group":"nodes","data":{"id":10,"label":"Brick(3)","parent":[1]},"position":{"x":25,"y":0}}
{"group":"nodes","data":{"id":11,"label":"Avail","parent":[]},"position":{"x":70,"y":0}}
{"group":"nodes","data":{"id":12,"label":"Brick(4)","parent":[1]},"position":{"x":30,"y":0}}
{"group":"nodes","data":{"id":13,"label":"Avail","parent":[]},"position":{"x":75,"y":0}}
{"group":"nodes","data":{"id":14,"label":"Brick(5)","parent":[1]},"position":{"x":35,"y":0}}
{"group":"nodes","data":{"id":15,"label":"Avail","parent":[]},"position":{"x":80,"y":0}}
{"group":"nodes","data":{"id":16,"label":"NumericalRelationScout","parent":[1]},"position":{"x":40,"y":0}}
{"group":"nodes","data":{"id":17,"label":"OperandView","parent":[1]},"position":{"x":0,"y":0}}
{"group":"edges","data":{"id":"2.member_of.1.members","source":2,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"4.member_of.1.members","source":4,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"6.member_of.1.members","source":6,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"8.member_of.1.members","source":8,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"10.member_of.1.members","source":10,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"12.member_of.1.members","source":12,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"14.member_of.1.members","source":14,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"16.member_of.1.members","source":16,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"17.member_of.1.members","source":17,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"3.taggees.2.tags","source":3,"source_port_label":"taggees","target":2,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"2.support_from.3.support_to","source":2,"source_port_label":"support_from","target":3,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"3.support_from.2.support_to","source":3,"source_port_label":"support_from","target":2,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"5.taggees.4.tags","source":5,"source_port_label":"taggees","target":4,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"4.support_from.5.support_to","source":4,"source_port_label":"support_from","target":5,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"7.taggees.6.tags","source":7,"source_port_label":"taggees","target":6,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"6.support_from.7.support_to","source":6,"source_port_label":"support_from","target":7,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"9.taggees.8.tags","source":9,"source_port_label":"taggees","target":8,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"8.support_from.9.support_to","source":8,"source_port_label":"support_from","target":9,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"11.taggees.10.tags","source":11,"source_port_label":"taggees","target":10,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"10.support_from.11.support_to","source":10,"source_port_label":"support_from","target":11,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"13.taggees.12.tags","source":13,"source_port_label":"taggees","target":12,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"12.support_from.13.support_to","source":12,"source_port_label":"support_from","target":13,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"15.taggees.14.tags","source":15,"source_port_label":"taggees","target":14,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"14.support_from.15.support_to","source":14,"source_port_label":"support_from","target":15,"target_port_label":"support_to","weight":2}}
The object passed to cy.layout() had a circular structure, so JSON.stringify() wouldn't print it. Adding the getCircularReplacer() function recommended here seemed to crash the browser. But manually removing elements from the layout object exposed the error: in a relative alignment constraint (documented under API here), I had an offset of '0' where I needed a 0, i.e. a string where a number was needed.
OK, happily that problem is now fixed. That still leaves the original question: is there a faster way to find errors like that? (The static-typing advocates are surely cackling by now.)

Trouble with greasemonkey script to refresh page

I'm downloading data from an online database using the imacros plugin for firefox. It works perfectly, except when the page times out. I've moved to downloading very small chunks of data since then the website times out much less frequently, but it still times out occasionally.
The problem is there's no way to code if statements directly into the imacros macro, so I wanted to have a greasemonkey script running along side it that will refresh the page if it timesout. The website only times out in one place for me, and when it does it shows the following:
can't open file
I never learned Java or Javascript and all of my programming experience deals with numerical methods, but I've been been piecing together code and adapting it to try and solve my problem.
The following is my base code:
var RefreshTime = '20';
var str1 = document.body.innerHTML
var str2 = "can't open file"
if (str1.search(str2) > 0) {
if (StRefTime > 0) setTimeout("location.reload(true);",RefreshTime*1000);
}
Since the browser I'm running this in is currently being used exclusively for this script I just have #include *
Basically what this is meant to do is refresh the page every 20 seconds as long "can't open file" is found the webpage. This works perfectly on other websites when I test it, but doesn't work at all on the website I need it to. It might be worth noting that when I refresh, firefox asks me to confirm resending post data - but imacros does have a function that I tested and works on this site to automatically confirm whenever the dialog is displayed.
After doing some reading I found that other people had similar problems, and I think the root of the cause is that if the page is arrived at through AJAX then greasemonkey misses it.
To address this I tried to implement the suggested solutions to those people, but I've been unsuccessful. For example I've tried putting the code I listed above into the solution given here: Run Greasemonkey script on the same page, multiple times? , for example
var RefreshTime = '20';
var str1 = document.body.innerHTML
var str2 = "can't open file"
function highlightGoodComments (jNode) {
//***** YOUR CODE HERE *****
if (/str2/i.test (jNode.text () ) ) {
if (str1.search(str2) > 0) {
if (RefreshTime > 0) setTimeout("location.reload(true);",RefreshTime*1000);
}
}
But this doesn't work either, and I've tried a couple variations of it (for example getting rid of str2 and just putting "open file" and things like that) and I've also tried and failed to make the following work https://gist.github.com/BrockA/2625891. I also tried wrapping all of my initial code in a setInterval loop with the hope that it would just check constantly for "can't open file" even without any page loading, but that didn't work either.
Unfortunately the website I'm running my script on is hidden behind a paywall, and it's hard to test my code since it times out somewhat randomly so there's no way to check if my code works outside of just waiting a long time and seeing if it failed. I know nothing about AJAX, so I'm not sure how to confirm that that is what's happening, but I still believe it to be so since my problem seemed similar to other people's - and when I enable this macro it does seem to interfere with other parts of the website but not the parts that my script works on.
I was hoping somebody could help me out, since I'm pretty stuck here and already in over my head. Even if you can't help, having some sort of AJAX website where I could test code without waiting several hours would be helpful to me trying to figure this out myself, if anybody knows of one. Thank you for reading through this, I really do appreciate any help anybody can offer.

The question is very long so I didn't bother to really read it. Since I don't use GreasMonkey I can tell you the iMacros solution.
Check if html element exists with iMacros and javascript
Here is a model how to built JS iMacros script and include if clause. You can make a testing macro that tests is t here "can't open" web page.
Also you can try to use
SET !TIMEOUT_PAGE 120
command to increase the time of page loading to 120 seconds. Try some of these if it can help.

Performance on highlighting words/lines in Vim

I have a set of small functions in VimL highlight a line (or a word) depending on certain conditions.
You should consider the workings of the functions to act similar as the spelling (:set spell), underlining when the conditions are met.
I have found, however, that when the number of highlighted lines exceed about 75, there is a significant lag when moving. Either from side to side or up or down.
I had some convenient AutoCommands that I was enabling by default, (for example, to echo why the line is highlighted) but even with all of them disabled, as soon as I call the function that highlights everything, I can tell there is a huge lag.
This is what I am using to highlight a word:
call matchadd('MyCheck', '^\%'. line . 'l\_.\{-}\zs\k\+\k\#!\%>' . column . 'c')
And this is what I use to highlight the whole line
call matchadd('MyCheck', '\%' . line . 'l\n\#!')
The 75 number I use as a reference for determining a lag is just a reference, it is a bit of a sweet spot for me, but just to demonstrate that most anything beyond gets increasingly worse.
I also use the SpellBad highlighting for MyCheck, but seriously doubt that this causes any problems.
Is there something I could do differently to avoid the lag? Is matchadd the best option?
EDIT:
Just to make sure it is not any of my functions or code doing something weird, I opened a 500 line file and did this:
highlight link MyCheck SpellBad
for line in range(line('$'))
call matchadd('MyCheck', '\%' . line . 'l\n\#!')
endfor
Which basically highlights every single line on the file. Everything clearly got impossibly slow.

Unsetting cursorline has a drastic (positive) effect in performance.
I did :set nocursorline and now my movements (regardless of highlighting) are snappy as before.

Using Everything search with Emacs/Anything under Windows

So I've started to use Anything with Emacs. You can use 'locate' with anything, but you can also use VoidTools' 'Everything' (which is actually the default for 'Windows-NT' systems.
It took a little bit of prodding, but I have command line Everything working on my system. I get results back from it while using anything-locate or anything-for-files.
Everything works fine except I get the dreaded ^M (control-M) at the end of the lines that es returns to me. That means when I use anything to open the file, it doesn't work.
Anyone have any help on how to fix values that es returns, or alternately, strip off the ^M before trying to open the file?

Ah-ha, in the end, it was my fault.
Be careful when messing around with the process-coding-system-alist, and make sure that it's something that really needs to be done. I modified this in the past thus:
(setq process-coding-system-alist (cons '("bash" . (raw-text-unix . raw-text-dos))
process-coding-system-alist))
And I don't need to do that anymore. It meant that the files being passed up from Everything were being interpreted Unix style, and the CR/^M were showing up. By commenting out this line, I solved my own problem.

Resources