On Chrome, Android, when I bring the menu up, and scroll to the bottom, the Newsletter menu item is cut off (I know it is there as I can see it on Firefox Android).
Small defensive suggestion: I’d usually define both the enabled and disabled versions as statement-like macros:
#ifdef MGBALOG
#define mgbalog(level, format, ...) \
do { _mgbalog(level, format, ##__VA_ARGS__); } while (0)
#else
#define mgbalog(level, format, ...) \
do { } while (0)
#endif
For the exact usage shown here, "mgbalog(...);" will mostly work with the empty replacement-list version, since it just leaves a bare ";". So this is not a guaranteed bug.
The reason I prefer the "do { } while (0)" form is that it keeps the macro structurally equivalent to a single statement in both debug and release builds. With the empty disabled macro, this:
if (failed)
mgbalog(ERROR, "failed");
becomes:
if (failed)
;
That is valid C, but it can trigger empty-body / suspicious-semicolon warnings, for example GCC’s "-Wempty-body", which matters if the project builds with "-Wextra" or warnings-as-errors.
It also means the enabled case is already set up correctly if the macro later grows beyond a single function call. For example, if you later add another statement to the macro:
#define LOG(x) printf("log\n"); printf("%s\n", x)
if (failed)
LOG("failed");
else
recover();
then the expansion breaks because the "else" no longer attaches to the intended "if".
So in this specific case the empty macro is probably fine for ordinary "mgbalog(...);" calls, but wrapping both versions in "do { } while (0)" is the more conventional and future-proof C macro shape.
But this process, including sending smaller items first etc sounds like it would have taken longer than what the OP did? And the OP was trying to do it quickly to tie in with the beginning of the semester?
Forwarders work with batches: small batches (consolidate packages in a suitcase to travel as airline luggage) or large batches (up to a whole 40 feet container)... So, delay is a matter of luck - ask around if a batch is due to depart and available slots remain. Express remains the province of traditional players - though I've managed to find a forwarder to urgently ship a small blister of drugs, but such service isn't guaranteed.
I saw similar engraved and then inked onto wooden boards at a restaurant, sadly, despite the error handling, 3 out of 4 I tried were not scannable, the 1 I did manage to scan to me to a reviews site for the restaurant (where a lot of reviews said they struggled to make the QR work - likely not the feedback the restaurant wanted)! I guess it kept me entertained whilst waiting for the bill.
There was a tweet a while back where I guy was riding a train in China and took a photo of the QR code for his seat. He mentioned that you can use the QR code to order food and drinks delivered directly to you.
About 5 minutes later there was another tweet from him where:
- someone saw the original tweet (Guy 2)
- scanned the QR code
- ordered the OP a drink
- added a note to the order saying it was from Guy 2
yea - as nice as they can look, many scanners expect very high contrast and a clear, unbroken bright border around the whole thing (many stylized ones I see lack a border). lacking either will mean many failures.
The last time I used anything similar to this was circa 1995 at secondary school, using Windows 3.11 computers, that has been set up so you could only launch a small number of authorised applications.
One of those was Word.
In Word you could write macros and use shell to launch other applications.
Suddenly the locked down computer that exposed a handful of applications could run anything (well anything a Windows 3.11 machine in 1995 could run).
It was quite exciting at the time, I don't feel like I have hit the same sort of issues since. Ocassionally I see people say that some touch screen information displays (in shops/shopping centres etc) have ways to escape from kiosk mode (locked to an app) so you can use them for anything, I guess that is similar.
On the PS2 there was a very small memory area, called the scratchpad, that was very quick to access, the rough idea on the PS2 was to DMA data in and out of the scratch pad, and then do work in the data, without creating contention with everything else going on at the same time.
In general most developers struggled to do much with it, it was just too small (combined with the fiddlyness of using it).
PS2 programmer's were very used to thinking in this way as it's how the rendering had to be done. There is a couple of vector units, and one of them is connected to the GPU, so the general structure most developers followed was to have 4 buffers in the VU memory (I think it only had 16kb of memory or something pretty small), but essentially in parallel you'd have:
1. New data being DMAd in from main memory to VU memory (into say buffer 1/4).
2. Previous data in buffer 3/4 being transformed, lit, coloured, etc and output into buffer 4/4.
3. Data from buffer 2/4 being sent/rendered by the GPU.
Then once the above had finished it would flip, so you'd alternate like:
Data in: B1 (main memory to VU)
Data out: B2 (VU to GPU)
Data process from: B3 (VU processing)
Data process to: B4 (VU processing)
Data in: B3
Data out: B4
Data process from: B1
Data process to: B2
The VU has two pipelines running in parallel (float and integer), and every instruction had an exact number of cycles to process, if you read a result before it is ready you stall the pipeline, so you had to painstakingly interleave and order your instructions to process three verts at a time and be very clever about register pressure etc.
There is obviously some clever syncing logic to allow all of this to work, allowing the DMA to wait until the VU kicks off the next GPU batch etc.
It was complex to get your head around, set up all the moving parts and debug when it goes wrong. When it goes wrong it pretty much just hangs, so you had to write a lot of validators. On PS2 you basically spend the frame building up a huge DMA list, and then at the end of the frame kick it off and it renders everything, so the DMA will transfer VU programs to the VU, upload data to the VU, wait for it to process and upload next batch, at the end upload next program, upload settings to GPU registers, bacially everything. Once that DMA is kicked off no more CPU code is involved in rendering the frame, so you have a MB or so of pure memory transfer instructions firing off, if any of them are wrong you are in a world of pain.
Then throw in, just to keep things interesting, the fact that anything you write to memory is likely stuck in caches, and DMA doesn't seem caches, so extra care has to be taken to make sure caches are flushed before using DMA.
It was a magical, horrible, wonderful, painful, joyous, impossible, satisfying, sickening, amazing time.
Well, if you were traveling at light speed you could move anywhere in the universe instantly. If you are an observer on earth, watching an object move away from you at the speed of light, then it will take a very long time to traverse the tiniest regions of the universe.
even in a vaccum, light speed travel from the travelers POV still takes time, and said traveler would perceive time passing exactly as occurring in that local space.
But yes you're totally correct, the observer on earth would in this time see only the briefest part of my journey's trail due to light from my journey taking "exponentially" longer to travel back to the observer.
Actually, in special relativity, if you could somehow travel at light speed, your own proper time wouldn’t pass at all. The journey would be instant from your perspective. You’d experience zero time between departure and arrival.
That’s not just "relativistically instant", that’s literally instant in your frame. The time dilation becomes total at light speed, and length contraction collapses the entire distance in the direction of travel to zero.
Now, it’s true we can’t really assign a rest frame to a photon, so this is a thought experiment. But if you extrapolate the math, the conclusion holds: no time passes for something traveling at light speed.
> if i am not writing or editing a file, just doing nothing, then why FS breaks?
For a few reasons, but the most common is that when you write a file, you 'fwrite' operation doesn't typically immediately write blocks to the disk, instead it gets written to caches that will be written to disk in due course. Changes to the disk, tables with crucial data, etc again are just updated in memory, and written to the disk at a 'sensible' time. It's possible that you aren't actively performing operations to modify the disk, but various previous changes are sitting in memory waiting to be synced. If you kill the power then these changes aren't flushed so you can end up with corruption/filesystem problems. The main reason things work this way is for performance.
reply