|
You might also look into OneNote's OCR capabilities. It should make your job really simple.
|
|
|
|
|
|
Learning Selenium for a new job that starts on the 23rd...
0) When you call driver.Quit , it's supposed to kill the driver process (running in windows), but it doesn't. This statement is true for both chrome and firefox. I had to write code to kill the associated processes for both the driver and the browser. What's worse, the chrome driver (of which multiple are spawned) will throw a Access Denied exception when you try to kill the chromedriver process, so you have to eat exceptions thrown by the Process.Kill() method top avoid failing the test simply because you're killing their freakin' process spawnage. (Firefox does not exhibit this problem, FWIW).
1) Selenium does not like element IDs that contain hyphens, so instead of doing By.Id() , I have to do By.CssSelector() to find an element by ID. Lesson - always use ByCssSelector for finding by ID.
I came up with a TestBase class that handles the process cleanup, a TestMaster class (derived from TestBase ) that contains the browser-agnostic test methods, and finally, two browse-specific test classes that inherit from TestMaster .
The test method in TestMaster simply navigates to my own home page, makes sure the title is correct, and then finds/clicks a menu item, and checks to see if a specific section exists. Simple, but a decent exercise. This means I can test for pretty much any browser that is configured in the BaseTest class - I'm running Win7 with Firefox and Chrome installed in a VM, so I don't have Edge, but I could add Opera and Brave if there are drivers for them.
I suppose that despite its quirks, Selenium is a decent automation test tool. I think I'm going to see if the @Marc-Clifton Fluent Web API Integration Testing[^] can be wrangled into this stuff...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Just curious, is this a new job within the same organization, or a completely new organization?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Completely new. At my current job, they keep making noise about doing unit and automated ui testing, but once again, our alarming lack of personnel and complete lack of ability to do proper agile/scrum, capped off by over-the-top security restrictions prevents the team from adopting any tools to perform that kind of testing. It’s maddening.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yeah, I've been there, done that, for DHS/CBP.
"Work smarter, not harder!" Oh, and you're not allow to write script for anything...
|
|
|
|
|
#realJSOP wrote: I think I'm going to see if
Well dang, that'd be cool. Let me know how the wrangling goes.
And yes, Selenium, when I've played around with it, is temperamental.
|
|
|
|
|
This one: The Lounge[^]
Everything went as expected, except that one thing I can't fix myself and I don't know who can
Apparently, someone deleted some DNS records so I can't hook up my custom domain name anymore.
It worked for DEV, TEST and another PROD service, but not the one they use first thing Monday morning.
The person I had on stand-by has access to pretty much all systems, except DNS.
Other people who weren't on stand-by and who might've helped went straight to voicemail.
Sent out an email to IT support saying these DNS records have to be added.
Let's hope they'll make it before 9AM Monday morning (yeah, right)
|
|
|
|
|
|
|
It was you! couldn't remember who it was, thanks for that book...
|
|
|
|
|
Two points (I didn't read the book, just looking at Amazon page):
1. Multiplatform Assembly Programming - such thing doesn't exist. I am a bit skeptic when an author promises to learn me non-existent thing.
2. Many reviews are talking about "retro programming", which looks like a hobby and not something that can help in real work.
Again, this opinion is based only on the book review.
|
|
|
|
|
11917640 Member wrote: Multiplatform Assembly Programming - such thing doesn't exist.
I'd disagree. There are a lot of aspects of assembler language programming that are largely independent of the target architecture.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I hate to be difficult, but it seems like C (or - fight me - even C++) is a better fit for this.
I mean, sure there are some instances, like doing SIMD where dropping to assembly might be a win, but that's going to be platform specific code, otherwise there's no point.
Seems to me that dropping to assembly within one of those, while generating most of the bytecode you otherwise need using C is far more "cross-platformable"
I didn't read the book, so is there a reason the approach I just outlined is insufficient?
To err is human. Fortune favors the monsters.
|
|
|
|
|
You are an embedded person (nearly said guy!) the only times I have used assembly is when I needed real speed reading a port.
|
|
|
|
|
I've been an embedded engineer for my whole career and the only time I dropped into assembly language in the last 20 years has been to use a specific assembly language instruction in the TI DSP I was writing code for. It was a 'saturate' instruction. It took a 40bit accumulator value and limited it to a 16bit value. Other than that it's been C/C++ for me for at least 2 decades.
|
|
|
|
|
I fear you misunderstood my point. I was merely suggesting that there are aspects of assembler programming that are largely independent of the target platform/instruction set.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I think I understand your point, it's just that it still seems more suitable to me to use C or C++, only dropping to asm for platform specific things. Despite assembly being somewhat similar across different platforms, sometimes, there are enough differences that it can get hairy fast. C does a lot of the heavy lifting in terms of papering over different machine word sizes, alignment issues, and other things that assembly just doesn't.
So while you're not wrong, it still seems better to me to use something like C, and then drop to asm within that if absolutely necessary.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Please do not compare C/C++ to assembly language. One ALWAYS sits on the back of the other -- that is the only comparison. I am sitting here wondering how and when it became acceptable to program hardware with ANY compiled language!!
I know all of the assembly languages in the books. ALL have enough similarities with one another that it is quite possible to learn them all. My main point is that you cannot compare assembly language to a compiled language for several glaring reasons -- no matter how hard you try. This isn't about who shouts the loudest (not saying you were shouting ).
modified 26-Oct-22 21:01pm.
|
|
|
|
|
Far from comparing them, I'm contrasting them. C and C++ can do multiplatform code in a way that ASM cannot.
Bert Novilla wrote: I am sitting here wondering how and when it became acceptable to program hardware with ANY compiled language!!
If you're not joking, I cannot take you seriously from a professional perspective. Sorry.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I don't get the whole multi-platform comparison at all. Granted, I understand the way things are done commercially -- I have been there, too. But... today's programmers actually believe a compiler can be optimized to write better (or as good as) code than the average ASM programmer. Of course, no one ever proves it. The better way to "do software" is to hire dedicated teams for EACH platform, with the best assembly programmer running the show. When that happens you do each of the platforms a real solid -- and NOT make one slow, bloated "tool" that takes forever to compile and fits all platforms poorly.
I think I actually object to the phrase "dropping down to asm" because I see it as exactly the opposite. A couple of decades ago we wouldn't be having this conversation (with me in the minority LOL).
Again, HOW is it considered "standard practice" to program the slowest link in the data chain with a compiled language?
modified 26-Oct-22 21:01pm.
|
|
|
|
|
Here's what I haven't been able to get someone with your position to do for me:
Generate a string of optimized, non-SIMD instructions that I can't produce vicariously with C or C++
If you can do that I will reconsider my position.
The reason we wouldn't have been having this conversation 20 years ago is C and C++ compilers were garbage.
They are worlds apart than what we work with today. I used to lean toward your position. When compilers changed, so did I.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Be specific. What are "strings of non-SIMD instructions not produced vicariously with C or C++", and why not just ask the question you really want the answer to? I can probably tell you, and it will be the truth. I also have no idea what optimized means, other than I routinely re-work all code until it can't be beaten by any compiler -- size or speed. Heck, it's usually written that way the first time!!! To me, SSE (or MMX... another type of SIMD) is simply part of the package I use every day, and not some mysterious, far-off concept that "maybe" the compiler has intrinsic macros for.
We can leave it here, agree we each have our good points (I believe we do), or you can explain your question better and I will accept and win your challenge, whatever it is. I just know the difference between ASM and all compiled languages, and the compiler I use to create is a gift from God, the same one we all have and decide whether or not to make good use of. You're not beating that with a man-made anything.
One might even write a "Photoshop" in 1 MB using pure assembly! And it would take forever. But, a team...
modified 26-Oct-22 21:01pm.
|
|
|
|
|
The following code bit bangs an 8-bit parallel bus using C++. It does so in a way that is extremely timing sensitive. It is something you would probably code in asm. Currently it only works on the ESP32 because I haven't coded for the hardware registers to flip GPIO on and off for platforms other than that - the timing is so sensitive that the generic API just isn't fast enough.
My point is though, this has to generate very specific bytecode for it to be fast enough to work. I had to run it through godbolt.org
It does. If you're not very familiar with C++ it won't look like it, with "if" statements all over the place and what not.
They are compiled out.
htcw_tft_io/tft_parallel8.hpp at master · codewitch-honey-crisis/htcw_tft_io · GitHub[^]
To err is human. Fortune favors the monsters.
|
|
|
|
|
I read your most recent comment in my email but it's flagged as spam for some reason here on the forum so I'll respond here instead if you don't mind.
You asked me what optimized means. That's fair. Let me see if I can clarify. Since it's situational, we'd have to take it on a case by case basis. Consider that if you produce a string of assembly, and my compiler produces a similar but different string, if it's not different but for some instructions that make it faster in at least half the situations we can think of I'll concede. Does that make sense?
The reason I excluded SIMD is because in practice it's the one area where I tend to "drop to" asm pretty frequently, because currently the compiler has narrow cases where it can find opportunities to produce SIMD regardless of how I structure my code. It's a good reason to context switch to asm from within C or C++. Those reasons exist and I'm not arguing otherwise. But I hope that clarifies why I added that qualification.
The code I posted in my second reply might clarify my position some.
To err is human. Fortune favors the monsters.
|
|
|
|
|