|
I'm too hoping for the same as before...
Decided to do it tomorrow so I will have the weekend to rest it out if needed...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
In Canada they are giving third doses to the immuno-compromised people to help them get the same level of protection that everyone else gets from two doses. So yes, your third dose will likely improve your protection. But I would only ever suggest that people get that dose if it is doctor prescribed.
|
|
|
|
|
"Your parcel from Covid 19 Home Testing Programme is due today between 11:18am ..."
That's impressive! They track deliveries to the minute - even Amazon can't do that accurately from 4 odd hours away.
Except it then goes on "... and 3:18pm."
Ah. So it's just a four hour window with a random start time, then ... 
They do give a "track your item" link, but that makes it worse with no actually relevant info added and the get-out clause: "If a delivery time is offered, we'll aim for it. If we can't ... we'll deliver as soon as possible."
So they make up a time, and then say it's ok if they don't make it. Why bother at all?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: So they make up a time, and then say it's ok if they don't make it. Why bother at all?
Because a manager said: "we need to give a 4 hour delivery window" - and the developer followed instructions! 
|
|
|
|
|
Mine says "...07:46 and and 11:46am."
|
|
|
|
|
for example, in MFC AppWizard generated demo exe, in resource.h file, these macros are called manifest constant.
any reason or history behind this?
diligent hands rule....
|
|
|
|
|
A typical practice in C programming is to define the fixed sizes of program elements in a header file used throughout the project source. Those #define'd values were called manifest constants. Historically Visual Studio's resource editor saved several values in the resource.h file: ID values for the next control, next menu item, etc. to be added. These were confusingly labeled as manifest constants, even though they weren't really used in that fashion.
Software Zen: delete this;
|
|
|
|
|
thanks for your insight!
diligent hands rule....
|
|
|
|
|
Hi,
The Resource Compiler[^] is an actual script/language compiler. So why would you not call a manifest constant anything else? I don't understand the question.
|
|
|
|
|
|
I'd like to see a large test panel being given two identical phones for trying out speed and 'smoothness' in ordinary usage situations, one changed to region France, the other not. I am sure that as many as 50% would be able to correctly identify the 'French' phone.
|
|
|
|
|
I'm manfully avoiding making a snarky remark based on the fact that I have a Samsung Galaxy S9+. 
Software Zen: delete this;
|
|
|
|
|
Everyone know the legendary speed of french people when confronted
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
This speed was significantly eclipsed in Afghanistan.
".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
|
|
|
|
|
Possibly FTL. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
If you have two cats in the same sunbeam, is that multibasking?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
If they were young, would they be littering?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Talk about solar [lack of] energy!
Software Zen: delete this;
|
|
|
|
|
Serial communication without a UART, all in bit banged software, is fun. But it can also get a little frustrating at times. By now I have reached 19200 baud with variable timing constants and even 38400 baud if I throw out the timing loops and replace them by a few carefully calculated NOPs. If I can squeeze a few more bus cycles out of the processor, even 76800 baud may be possible. Really not so bad for a processor from 1976.
That works like a charm with normal terminal emulation, but a simple XMODEM upload can get hairy. On one side you have some PC that sends one byte after with its UART and without any notable delay. And on the other side you have a tiny 8 bit processor without a UART, flow control or any such luxuries.
The problem is that you have to do something with the bytes you have received and be ready in time to catch the next start bit, or else the whole timing will be thrown off and the upload will fail.
So where can we buy ourselves the time to calculate memory addresses or checksums when the bytes come in without delay? It's the stop bits. They are not relevant data, nor do they add any noteworthy security or error detection. One serial clock pulse is not much time, but it will have to do. 52 microseconds at 19200 baud. AT my current clock frequency, that gives me time for about 20 instructions before I have to be ready to receive the next byte. No more, no less.
So, I optimized the hell out of my code and ... it got worse. Especially at lower baud rates (where I should actually have more time) I got more errors than before. I was too fast and that led to the still incoming stop bit to be mistaken for the next start bit. A single additional instruction in the serial input routine to detect this and the problems went away. Victory!
Still, I could now go for 38400 baud. Maybe 10 instructions between incoming bytes are also enough...
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Ah, those were the days. In many ways. UART's. Having to code in assembly with an without UART's. Serial I/O. Start/stop bits. Byte width. And to think I got paid for solving those problems. How times have changed.
|
|
|
|
|
Times have not changed so much. There are more jobs than ever for those of us who have not yet been turned into a homogenized, pasteurized and brain washed code monkey.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: ...homogenized, pasteurized and brain washed code monkey
How can I be of service? 
I've got JavaScript, React, Vue and/or NodeJS.
I mean, all code is JavaScript now, right?
|
|
|
|
|
I still have PISD (Post Interrupt Service Disorder) from writing bimodal interrupt handling. One of my MS-DOS projects ran under the DOS4GW DOS extender (same as DOOM), which let the body of the application run in protected mode. The extender would automatically switch from protected mode to real mode to handle an interrupt, and then back again. Unfortunately that was slow, so you could be bimodal instead. You installed both a real-mode and a protected mode interrupt service, and could therefore omit the expensive mode switched. Sharing data between the two was left up to the developer. My solution was to create the data areas in the real-mode code, and pass the address to them in the command line when the real-mode started up the protected mode code. I was handling three RS-232 ports running at 56K, along with three parallel ports outputting 100KB per second, on a 16 MHz 386SX processor.
The really neat trick was using the same C source code for both the real and protected mode interrupt services.
Software Zen: delete this;
|
|
|
|
|
Those were the days; assembly, optimizing, tight loops and lots of coffee and pizza.
How times have changed, now just get an inexpensive MCU and everything you need is there with little fuss.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
