In other news today...



  • @dkf said in In other news today...:

    @acrow said in In other news today...:

    [GCC] follows the C specification pretty well.

    It depends on whether you ask it to be strict about it or not. It's usual mode of operation implements an extension to C with some very useful extra features in it (and some weird bits that suck). It's fairly close to compliant if you avoid the extensions (and nobody really wants the really stupid stuff in the C spec like trigraphs).

    Either way, GCC is an absolute paragon compared to some manufacturers' own C-compilers.

    Granted, those compilers are usually written for architectures that don't lend themselves well to C.
    8bit memory paging etc..


  • Fake News

    Back to actual news: there was a moose on the loose:


  • Fake News

    Meanwhile, in a village in Wales there are goats on the roads:


  • Discourse touched me in a no-no place

    @acrow said in In other news today...:

    Either way, GCC is an absolute paragon compared to some manufacturers' own C-compilers.

    Fortunately for us, the manufacturer compiler that we sometimes use is armcc, which is mostly very similar to gcc (and in fact that's the one we use most because then we don't need to screw around with license servers). They both produce pretty decent code for our hardware; armcc makes slightly tighter code, but not enough to make a material difference for most of our code. (Only the firmware needs to be built with it right now IIRC.)



  • @Tsaukpaetra said in In other news today...:

    Now where am I going to get a computer willing to stay online for 50 days straight that can monitor the output of a joystick....

    Easy, a Linux one 🤟



  • @acrow said in In other news today...:

    That 51 days sounded familiar. 32bit milliseconds counter rollover period is 49.7 days though. A 24h additional buffer?

    E_BUFFER_OVERFLOW



  • @Tsaukpaetra said in In other news today...:

    Now where am I going to get a computer willing to stay online for 50 days straight that can monitor the output of a joystick....

    What would happen if you set the bios date backwards, boot, then update the system time?


  • Notification Spam Recipient

    @dcon said in In other news today...:

    @Tsaukpaetra said in In other news today...:

    Now where am I going to get a computer willing to stay online for 50 days straight that can monitor the output of a joystick....

    What would happen if you set the bios date backwards, boot, then update the system time?

    Nothing? There is no such thing on an Arduino for most instances.



  • @JBert said in In other news today...:

    Back to actual news: there was a moose on the loose:

    "Moose are large animals and can become aggressive and dangerous when they wander into populated areas," Fish and Game spokesman James Brower told the East Idaho News.

    I've heard they even bite people's sisters!



  • @JBert that's right near where I grew up. Several of my siblings went to college there.



  • @dcon said in In other news today...:

    What would happen if you set the bios date backwards, boot, then update the system time?

    You'd hear satanic lyrics?



  • @Mason_Wheeler said in In other news today...:

    @JBert said in In other news today...:

    Back to actual news: there was a moose on the loose:

    "Moose are large animals and can become aggressive and dangerous when they wander into populated areas," Fish and Game spokesman James Brower told the East Idaho News.

    I've heard they even bite people's sisters!

    Mynd you, møøse bites Kan be pretti nasti...


  • Considered Harmful

    @HardwareGeek said in In other news today...:

    @dcon said in In other news today...:

    What would happen if you set the bios date backwards, boot, then update the system time?

    You'd hear satanic lyrics?

    If you play Windows installation disk backwards, you can also hear satanic messages.

    But worse, if you play it the right wayit might install Windows :eek:

    🍹




  • @jinpa said in In other news today...:

    🤣



  • @jinpa said in In other news today...:

    Should paint a victory marking on the cruiser.


  • ♿ (Parody)



  • @boomzilla said in In other news today...:

    So I guess I can say, at least we aren't NJ? 🤷♀



  • @jinpa This is almost better for Venezuela's reputation than if they had succeeded. Did they really want to publish a statement saying "Look, everyone, we sank an unarmed ship with 32 civilians on it that was doing nothing!"



  • @boomzilla I laughed, but then remembered the countless lines of Fortran I indirectly rely on...


  • Fake News

    @anonymous234 said in In other news today...:

    @jinpa This is almost better for Venezuela's reputation than if they had succeeded. Did they really want to publish a statement saying "Look, everyone, we sank an unarmed ship with 32 civilians on it that was doing nothing!"

    Doing nothing? This site translated a statement which was allegedly made by the Venezuelan president or his office:

    [...] the government in Caracas alleged that the Resolute collided with the Naiguata in an "act of aggression and piracy." Further, the government speculated that it could not rule out that Resolute “was transporting mercenaries to attack military bases in Venezuela, unloading them out there on the high seas.”

    If there were only civilians on board then surely all the mercenaries must have dropped off. :half-trolleybus-tl:



  • @JBert said in In other news today...:

    @anonymous234 said in In other news today...:

    @jinpa This is almost better for Venezuela's reputation than if they had succeeded. Did they really want to publish a statement saying "Look, everyone, we sank an unarmed ship with 32 civilians on it that was doing nothing!"

    Doing nothing? This site translated a statement which was allegedly made by the Venezuelan president or his office:

    [...] the government in Caracas alleged that the Resolute collided with the Naiguata in an "act of aggression and piracy." Further, the government speculated that it could not rule out that Resolute “was transporting mercenaries to attack military bases in Venezuela, unloading them out there on the high seas.”

    If there were only civilians on board then surely all the mercenaries must have dropped off. :half-trolleybus-tl:

    If a small, armed coast guard ship can't outmanoeuvre a cruise tub, it bloody well deserves to be rammed by them.



  • @Carnage It didn't "get rammed by them"; they rammed the cruise ship, mistakenly thinking that that would cause damage to the cruise ship rather than to their patrol ship. And then when that didn't work, they did it a few more times, until finally their ship broke and started sinking.



  • @Mason_Wheeler said in In other news today...:

    It didn't "get rammed by them"; they rammed the cruise ship

    Of course, but the Venezuelans claim the big, lumbering ship rammed their small, maneuverable patrol boat, and the entire world should laugh right in Maduro's stupid face for making such an obvious lie. But if it were true, the boat would have deserved to be rammed, because it would mean they were too incompetent to get out of the way.



  • @Mason_Wheeler said in In other news today...:

    @Carnage It didn't "get rammed by them"; they rammed the cruise ship, mistakenly thinking that that would cause damage to the cruise ship rather than to their patrol ship. And then when that didn't work, they did it a few more times, until finally their ship broke and started sinking.

    Well, yes obviously. But the retard in chief in Venezuela claimed that the cruise ship rammed their innocent patrol boat. A cruise ship ramming a patrol boat, with the stern end no less, is ridiculous. The entire crew of the patrol boat would have to be asleep for something as lumbering as cruise ship to manage to ram them. More so with anything other than the bow.
    And an unarmed cruse ship engaging in piracy? With mercenaries that were off to Venezuela to cause mischief? It's just an incoherent rambling.



  • @HardwareGeek Why haven't cruise ships adopted traffic cameras yet? You'd think a car dash-cam with a memory card would be a minimal cost, versus all the benefits, like getting footage of the sinking.

    ...Now that I think about it, having cameras on the masts and chimneys, providing a good view of the ship and surroundings, might lower costs, since they reduce the need for manual walking around to check if stuff is still standing. Plus, added chance of noticing small boats and other hazards around the ship.



  • @PleegWat said in In other news today...:

    @acrow said in In other news today...:

    @TimeBandit That 51 days sounded familiar. 32bit milliseconds counter rollover period is 49.7 days though. A 24h additional buffer?

    Tip of the day:
    If you're working on an embedded system, and you need to know if a period of time has passed (e.g. 1000ms), the correct way is to compare like this: if ((currentTicks - oldTicks) > 1000)

    If you write it as if (currentTicks > (oldTicks + 1000)), then you're going to get shot in the foot at rollover time. Which is likely to be after several days (or 47.9), so you're not going to catch it in testing.

    With an important addition: if it's C or C++, the variables must be unsigned.

    Though the code this is pulled from does not apply it to timestamps, it still applies:

    /*
     * Sequence number comparison operators.
     */
    #define SEQ_LT(a, b)            ((int)((a) - (b)) <  0)
    #define SEQ_LE(a, b)            ((int)((a) - (b)) <= 0)
    #define SEQ_GT(a, b)            ((int)((a) - (b)) >  0)
    #define SEQ_GE(a, b)            ((int)((a) - (b)) >= 0)
    

    Not really. The variables must be unsigned in the first place, otherwise it will be promptly rewritten to a < b, a <= b, a > b and a >= b by the compiler, because signed overflow is Undefined Behaviour™. And then the int cast is also not defined, though I think it is implementation defined rather than undefined so it will work as long as the platform is 2's-complement (the reverse conversion must be done modulo, but not this one, so cast to unsigned and back may actually change the value on some weird platforms).



  • @acrow said in In other news today...:

    @HardwareGeek Why haven't cruise ships adopted traffic cameras yet? You'd think a car dash-cam with a memory card would be a minimal cost, versus all the benefits, like getting footage of the sinking.

    Probably because until now, no one was dumb enough to get in a situation where this footage was useful?

    ...Now that I think about it, having cameras on the masts and chimneys, providing a good view of the ship and surroundings, might lower costs, since they reduce the need for manual walking around to check if stuff is still standing. Plus, added chance of noticing small boats and other hazards around the ship.

    More realistically, I guess that having electrical/electronic equipment working 24/7 in a marine environment isn't that easy, so it would probably turn out to be very costly, more than having someone just walk around (especially since you still need someone watching those cameras to notice problems, so yes it needs less crew, but it still needs some). Also I'm pretty sure that large ships with very limited crew such as container ships or tankers must have that already. Also also, you probably don't want fiddly electronic systems on board when the crew in charge is made of drunken Ukrainian sailors.



  • @acrow said in In other news today...:

    @HardwareGeek Why haven't cruise ships adopted traffic cameras yet? You'd think a car dash-cam with a memory card would be a minimal cost, versus all the benefits, like getting footage of the sinking.

    ...Now that I think about it, having cameras on the masts and chimneys, providing a good view of the ship and surroundings, might lower costs, since they reduce the need for manual walking around to check if stuff is still standing. Plus, added chance of noticing small boats and other hazards around the ship.

    I'm pretty sure they DO have cameras, if for nothing else, then for docking. An the over the radio communication is recorded and logged. I'd be surprised if they didn't send all recordings over to head quarters as soon as they could so that Venezuelan authorities didn't remove any and all evidence.



  • @remi said in In other news today...:

    Probably because until now, no one was dumb enough to get in a situation where this footage was useful?

    Page 3:

    18655 ships involved, 16539 casualties, 253 ships lost [...]

    Edit: P.S.
    Also look at Page 20, Figure 11. I'd think some footage would be nice to have.



  • @acrow said in In other news today...:

    If I remember my C rules right (and they do apply to C++ too, mind) they both get implicitly converted to long signed.

    So I went to check the §8/11 and it gets worse. If signed long can contain all values of uint32_t, i.e. if long is 64-bit, it will get converted to signed long, but if not, it will get converted to unsigned. So the result is actually platform-dependent!



  • @acrow That's an impressive number (I haven't read your link, nor am I going to because :kneeling_warthog: , so I'm just picking up your numbers), although if one wanted to go down that rabbit hole, one might ask how many of those incidents would actually have been either prevented, or better explained, by having cameras. You still need people to watch them, which means a minimal standard of sailorship that I'm guessing many of the affected ships didn't have, and for many incidents I'm guessing no one needs the additional information that a dashcam could provide to explain them.

    Anyway, I guess the true answer is that modern well-equipped ships have cameras (I browsed a couple of sailing magazines a few years ago and it's impressive the amount of gizmos available to people ready to buy them!) (also, in my professional world there are some very high-tech ships that have high health and safety standards and given how detailed even the slightest incident reports are, I'm betting that they do have a lot of cameras around), and that most of the ships on the sea are neither modern, nor well-equipped and that their owners/operators find it easier and cheaper to just have meat sacks that can be replaced in any port walking around rather than a true crew that knows how to operate things.



  • @Bulb Well, not setting the length of int in stone is one of the biggest failings of C. One that got fixed already, too (by the introduction of int32_t et.al.). The problem only exists anymore because of old/bad tutorials.



  • @Bulb said in In other news today...:

    @PleegWat said in In other news today...:

    @acrow said in In other news today...:

    @TimeBandit That 51 days sounded familiar. 32bit milliseconds counter rollover period is 49.7 days though. A 24h additional buffer?

    Tip of the day:
    If you're working on an embedded system, and you need to know if a period of time has passed (e.g. 1000ms), the correct way is to compare like this: if ((currentTicks - oldTicks) > 1000)

    If you write it as if (currentTicks > (oldTicks + 1000)), then you're going to get shot in the foot at rollover time. Which is likely to be after several days (or 47.9), so you're not going to catch it in testing.

    With an important addition: if it's C or C++, the variables must be unsigned.

    If you can get them as such, yes. Unfortunately, the interface for reading the tick count is rarely your own code. Best to use the same type as the API, since it's usually a custom type (tick_t etc..). If it breaks due to e.g. platform change, then your code gets fixed along withthe API when the type is redefined.

    Not really. The variables must be unsigned in the first place, otherwise it will be promptly rewritten to a < b, a <= b, a > b and a >= b by the compiler

    Why would it rewrite it like that? If it's undefined behavior, then isn't that even more reason for the compiler to do exactly as written.


  • Java Dev

    @Bulb said in In other news today...:

    @PleegWat said in In other news today...:

    @acrow said in In other news today...:

    @TimeBandit That 51 days sounded familiar. 32bit milliseconds counter rollover period is 49.7 days though. A 24h additional buffer?

    Tip of the day:
    If you're working on an embedded system, and you need to know if a period of time has passed (e.g. 1000ms), the correct way is to compare like this: if ((currentTicks - oldTicks) > 1000)

    If you write it as if (currentTicks > (oldTicks + 1000)), then you're going to get shot in the foot at rollover time. Which is likely to be after several days (or 47.9), so you're not going to catch it in testing.

    With an important addition: if it's C or C++, the variables must be unsigned.

    Though the code this is pulled from does not apply it to timestamps, it still applies:

    /*
     * Sequence number comparison operators.
     */
    #define SEQ_LT(a, b)            ((int)((a) - (b)) <  0)
    #define SEQ_LE(a, b)            ((int)((a) - (b)) <= 0)
    #define SEQ_GT(a, b)            ((int)((a) - (b)) >  0)
    #define SEQ_GE(a, b)            ((int)((a) - (b)) >= 0)
    

    Not really. The variables must be unsigned in the first place, otherwise it will be promptly rewritten to a < b, a <= b, a > b and a >= b by the compiler, because signed overflow is Undefined Behaviour™. And then the int cast is also not defined, though I think it is implementation defined rather than undefined so it will work as long as the platform is 2's-complement (the reverse conversion must be done modulo, but not this one, so cast to unsigned and back may actually change the value on some weird platforms).

    True, and in that case the input is always unsigned. Strictly, it should probably write unsigned comparisons relative to 0xF0000000.

    @acrow said in In other news today...:

    Why would it rewrite it like that? If it's undefined behavior, then isn't that even more reason for the compiler to do exactly as written.

    Simplifying arithmetic.



  • @PleegWat said in In other news today...:

    @acrow said in In other news today...:

    Why would it rewrite it like that? If it's undefined behavior, then isn't that even more reason for the compiler to do exactly as written.

    Simplifying arithmetic.

    :sideways_owl: Assuming that a and b were variables with runtime-assigned value, and are of the same type, and a literal x is not, then ((a - b) > x) has 1 runtime type-conversion, whereas (a > (b + x)) has 2. Further, assuming that addition and substraction have equivalent runtime cost, I really don't see the simplification.


  • Java Dev

    @acrow When X is 0, then a > b is simpler than (a - b) > 0. Though with x86 setting flags on the subtraction no explicit compare may be needed so it wouldn't make a difference, there may be an expectation that one simplification allows another.



  • @acrow said in In other news today...:

    Not really. The variables must be unsigned in the first place, otherwise it will be promptly rewritten to a < b, a <= b, a > b and a >= b by the compiler

    Why would it rewrite it like that? If it's undefined behavior, then isn't that even more reason for the compiler to do exactly as written.

    Because it would be simpler. That's the reason things are Undefined Behaviour. So the compiler can rewrite them. And it often does to make the calculation shorter or to save some precious registers.

    @acrow said in In other news today...:

    Unfortunately, the interface for reading the tick count is rarely your own code.

    The cast from signed to unsigned is defined to be modulo. So you can cast the value and do everything in unsigned, where things are defined to be calculated modulo and you can take care of stuff.



  • @acrow said in In other news today...:

    :sideways_owl: Assuming that a and b were variables with runtime-assigned value, and are of the same type, and a literal x is not, then ((a - b) > x) has 1 runtime type-conversion, whereas (a > (b + x)) has 2. Further, assuming that addition and substraction have equivalent runtime cost, I really don't see the simplification.

    There will be generally no runtime conversion either way, but the form will depend on the value of the constant. For some one form will be used, for some the other and for some it will reduce to simple true or false.

    @PleegWat said in In other news today...:

    @acrow When X is 0, then a > b is simpler than (a - b) > 0. Though with x86 setting flags on the subtraction no explicit compare may be needed so it wouldn't make a difference, there may be an expectation that one simplification allows another.

    Actually I am not sure (signed)((unsigned)a - (unsigned)b) > 0 can even be done with a single test instruction and jump, but if yes, it will be checking different flags than simple signed a - b.



  • @Bulb said in In other news today...:

    @acrow said in In other news today...:

    Unfortunately, the interface for reading the tick count is rarely your own code.

    The cast from signed to unsigned is defined to be modulo. So you can cast the value and do everything in unsigned, where things are defined to be calculated modulo and you can take care of stuff.

    Not quite. The casting will screw the tick count comparison around the modulo point. Which leads to 2 possible scenarios:
    a) The writer of the API is aware of this, and returns unsigned values that roll over naturally.
    b) The writer of the API is unaware, and just returns some ticker that, most likely, rolls over naturally as 2's complement.

    In case of a, the problem never existed. In case of b, you'll have to reinterpret the value instead of casting.



  • @acrow Cast from signed→unsigned is required by specification to be 2's complement (i.e. modulo), so as long as it does indeed roll over as 2's complement, the cast is just fine. It is only a problem if the counter rolls over in some other way.



  • @PleegWat I'm aware. But the whole conversation started from counting time. That is, trying to figure out whether a certain number of timer ticks have passed. So I assumed a non-zero literal (x).





  • In other news a few days ago...

    Why would it take so long? Did they throw away the unfucked versions immediately after cropping and stretching them in order to "guarantee visual quality and consistency"?


    Filed under: Matching the visual quality of the older seasons to the writing of the new ones



  • @hungrier I just wish all those streaming services could just remove / not render the black bars above and below the movies for 16:9.

    Because when the black bars are mandatory / baked-in it looks really stupid on a 21:9 screen.

    34a1b09e-f286-43a1-9b8d-25ecfc120184-image.png

    Also, erm, the choice of subtitles for this one is weird:

    41f56799-6305-422e-b20f-25e9854adb31-image.png



  • @Rhywden Embedded letterboxing on a digital video stream is :trwtf:. It might make sense if the thing was on DVD, where the standard was restricted to a certain set of resolutions, but this is digital video, on their own streaming platform with their own software. They can literally do anything and have an incentive to give you a good viewing experience, but instead they go out of their way to distort the video in the case of the Simpsons, or add giant borders in your example



  • @hungrier Netflix actually does it right in several instances.



  • @Rhywden I've only got a pedestrian 16:9 display but from what I've seen on Netflix, everything goes all the way to either the vertical or horizontal edge depending on the content


  • ♿ (Parody)


  • Considered Harmful

    @boomzilla 451 OK :sadface:


Log in to reply