1.  

      Very positive and productive. Thanks for sharing material that drives everybody forward.

      1.  

        TL,DR - some of the links are inaccurate.

        There’s nothing particularly compelling in those links.

        • Some screen sharing and screen recording apps aren’t yet/won’t be ported to Wayland.
          This was equally true for other windowing system transitions - some apps weren’t ported from NeWS or SunView either. It doesn’t mean that Wayland is unsuitable for general use.
        • Wayland breaks global menus in Gnome
          This is a GTK issue. GTK4 removed support for a feature that is required by global menus. Wayland isn’t responsible for the development practices of the GNOME project.
        • Wayland broke global menus with KDE platformplugin.
          This issue has been resolved.
        • Wayland breaks global menus with non-KDE Qt platformplugins.
          This may have been fixed in 5.11.
        • Wayland breaks AppImages that don’t ship a special Wayland Qt plugin
          This is another 5.11 issue, it may have been fixed.
        • A Youtube video from someone who prefers X11
      1.  

        This reminds me of the Derek Sivers talk Weird, or just different?.

        1. 2

          The lesson I take away from this is that language designers should avoid making changes that break backward compatibility. This is definitely true for C#; there have been few breaking changes and some compiler bugs have remained unfixed because they would break backward compatibility.

          1. 4

            I don’t think that’s the lesson the article teaches us, which is that not fixing mistakes due to “backward compatibility” can have unexpected, incredibly broad long-term effects.

            I’d say that 80% of the languages today that carry C’s bug didn’t copy it because of fAmiLiaRiTy, but because they were completely unaware that it was a mistake in C in the first place.

            1. 2

              I don’t think that’s the lesson the article teaches us, which is that not fixing mistakes due to “backward compatibility” can have unexpected, incredibly broad long-term effects.

              I agree that backward compatibility can have unexpected long-term effects.
              Where we disagree is that I think backward compatibility is often required for mainstream success.
              It’s difficult to introduce a new language and people are often reluctant to learn something different.
              I think the following quote accurately expresses this issue.
              “It was clear from talking to customers that they all needed GC, JIT, dynamic linkage, threading, etc, but these things always came wrapped in languages that scared them.” – James Gosling
              C-style syntax is problematic but I don’t think that C++, Java, or C# would have succeeded without reusing it.

              1. 1

                What’s missing is a grown-up, educated-by-past-mistakes and well-implemented process between

                our compatibility approach is to never ever change anything and totally ignore how even Java gave up on that (Rust)

                and

                wAt iS cOmPaTiIbiLiTy? cAn I gO bAcK eAtiNg CrAyOns iN tHe cOrNer? (PHP)

                We have all the tools required to pull this of, we just have to stop LARPing “language development in the 1960ies”.

          1. 1

            Work:
            Application support.

            Personal:
            I’m reading TLPI and and porting some apps to IPv6.

            1. 7

              This article begins with the usual tired old comparison between traditional engineering and software engineering.

              He proceeds by describing Standard ML as the first engineered programming language because it has a formal semantics. I think he’s mistaken, there were formal semantics created for both PL/I (VDM) and Algol 68(a Van Wijngaarden grammar) in the 1970s.

              Traditional programming language “design” does not address the question of the meaning of the language. In an engineering sense, traditional programming languages are not designed at all. A list of reasonable-sounding features is outlined in English, and the compiler writer then turned loose to try and produce something vaguely corresponding to the text.

              This ignores the reason why most language designers have used a written specification instead of a formal semantics.

              People want specifications they can read.

              Language specifications have a broad audience:

              • End users
              • Authors of reference works
              • Implementers
              • Enthusiasts who want to modify the specification

              Most people can’t read a formal semantics but written specifications are much widely accessible.

              Defining a language with a formal semantics is giving up on large-scale understanding of the language.

              1. 3

                Saturday:
                Chores, daemon programming, and reading The Linux Programming Interface.

                Sunday:
                Meeting my girlfriend for sushi.

                1. 2

                  How are you enjoying TLPI?

                  1. 2

                    It has a lot of helpful information and most of the content isn’t Linux specific.

                  2. 1

                    Girlfriend? Noice! Sushi?? Double noice! TPI??? Triple noice!

                  1. 2

                    Work:
                    Application support, application support, application support.

                    Personal:
                    I’m porting an application from a discontinued commercial Unix to MacOS.

                    1. 2

                      Which UNIX? Just curious. I’ve worked with most of them :)

                      1. 2

                        The program was written for IRIX and uses a few proprietary system calls.
                        I have gotten it to compile but there are a few parts that I haven’t figured out how to port yet.

                        1. 2

                          Interesting!

                          IRIX was SVR3.2 or SVR4 depending on which major version you’re running, so I could see where porting from there to Mac OS X (FreeBSD userland atop the Mach Micro-kernel) could be tricky in places.

                          Maybe consider putting some details here. I or somebody else may be able to help (Unless you’re in it for the personal challenge in which case feel free to disregard :)

                          1. 1

                            Maybe consider putting some details here. I or somebody else may be able to help (Unless you’re in it for the personal challenge in which case feel free to disregard :)

                            Here are the system calls and constants that I haven’t ported yet.

                            • HZ - this is a constant in values.h. I think it has a value of either 100 or 256 but am not sure which.
                              It’s also quite possible that the value doesn’t make sense 25 years later.
                            • schedctl(NDPRI,0,NDPHIMAX); - a comment indicates this raises the priority of the process.
                              I’m planning to ignore this for now; it will probably run fast enough.
                            • sginap() - this seems equivalent to sleep.
                              The calls to this function are all after schedctrl has been called.
                              I’m planning to ignore these calls or replace them with sleep().
                            • syssgi calls with SGI_SETTIMETRIM and SGI_GETTIMETRIM as arguments.
                              I’m not sure if equivalent code is needed on current OSes.
                              My plan is to check the source to Apple’s NTP client and see what it does.
                            • _daemonize() - this seems like an enhanced version of the BSD daemon() function.
                              I’m planning to copy some code from the Stevens book - daemon{} is deprecated on macOS.
                            1. 2

                              syssgi calls with SGI_SETTIMETRIM and SGI_GETTIMETRIM as arguments. I’m not sure if equivalent code is needed on current OSes. My plan is to check the source to Apple’s NTP client and see what it does.

                              One of IRIX’s claim to fame is that it had real time disk IO and graphics capabilities. When I worked at a research lab in the 90s it’s all the scientists used for their VR work.

                              Sounds like you’ve got this well in hand. I’d ignore most of it and then just tweak the timing using standard interfaces like sleep()

                              HZ was the only one among these I couldn’t find any references to online.

                    1. 17

                      Yes.

                      Some people may argue that “C++ replaced most of the dangerous techniques with much better ones in the recent years”, but that’s

                      a) not true (it added more stuff, it didn’t remove the old ways), and

                      b) missing the point (C++’ unlimited growth is one of the core criticisms of C++).


                      The interesting take away from this article (and many similar ones), is that C++ has an extreme selection bias – it only seems to be able to attract people who are unable to see its problems.

                      Many languages have something like this – in the end it’s often a matter of preference– but C++ seems to be the most extreme case of this.

                      1. 9

                        [C++] only seems to be able to attract people who are unable to see its problems.

                        I love C++. Yet I wholeheartedly agree with your criticisms, and have many more myself (e.g. it’s still impossible to build a compile-time safe Option). I believe Rust is objectively superior in almost every way.

                        But that doesn’t mean we should all ignore the great things done with C++, nor the value of lessons learned from its widespread use. I don’t think C++ is “plain bad” at all. It has its place for good reason. Soon Rust should replace it everywhere, also for good reason.

                        1. 5

                          It always struck me as sort of a hoarder’s language, in that no idea, no matter how terrible, has ever been discarded, so the surface area of the language is huge, and this leads to innumerable mutually incompatible dialects.

                          1. 3

                            I currently use C++ because the specialized graphics libraries I need are only available in C++. I’m proficient in it because I was paid to write C++ code professionally for over 10 years. None of this proves that I am “unable to see its problems”, as @soc puts it. Yes, I know about Rust, but there’s the high learning curve, the low productivity, and the difficulty or impossibility of interfacing to C++ template libraries (depending on the library). Reimplementing the libraries I need to use in Rust is not an option. More generally, I think that C++‘s huge library ecosystem is a big factor in why people continue to use it. It’s not ignorance or blindness to the language’s problems.

                            I’ve looked at Zig and I like the fact that you can directly include a C header file. Makes it very easy to migrate from C to Zig. If someone created a decent language with the same level of integration with C++, I’d be very interested.

                            1. 1

                              a) not true (it added more stuff, it didn’t remove the old ways), and

                              This is equally true of other languages with an ISO standard.
                              Member countries vote on whether a standard should be accepted; standards that are too incompatible with existing code won’t be accepted.
                              The COBOL80 standard is an example of a standard that was rejected.
                              Another factor is that deprecating or removing functionality from a standard is often ineffective; if it’s widely used then compilers and runtime libraries will continue to support it.

                              1. 6

                                This is equally true of other languages with an ISO standard.

                                Yes, but this doesn’t detract anything from the problem statement.

                                Another factor is that deprecating or removing functionality from a standard is often ineffective; if it’s widely used then compilers and runtime libraries will continue to support it.

                                But that’s a problem C++ created itself: by basically never fixing, cleaning or removing any existing feature, the community only attracts people that don’t care about that.

                                Same why languages with bad documentation can’t seem to improve it – because they literally can’t attract people who care about good documentation.

                                One example of a large language which managed to do much better is C#.

                            1. 3

                              Work:
                              Application support, application support, and application support.

                              Personal:
                              Hacking on the code of a old network daemon; it originally ran on SunOS 3.5.
                              I’m beginning to understand why so many applications are riddled with ifdefs.
                              There are some significant gaps in POSIX.

                              1. 1

                                If I may be permitted a moment of self-indulgence, this feels like a cautionary tale for my Mu project. I chose to implement it in x86 in hopes that it would be easy to try out. However, I’m starting to have some regrets about using 32-bit x86. It’s more aesthetically pleasing and efficient (no REX bytes all over the place, pointers take less space) but support for it is slowly fading from mainstream OSs.

                                When I started Mu I planned eventually to have my own OS, which would make this moot. (Hopefully Intel won’t ever stop supporting 32-bit. Right? Right?) However, over the last 3 years I’m slowly gaining an appreciation for just how much work and sheer learning that’s going to take.

                                1. 2

                                  (Hopefully Intel won’t ever stop supporting 32-bit. Right? Right?)

                                  Intel still supports real mode; 32-bit support will live as long as the architecture survives.
                                  x64 doesn’t support running 16-bit apps under emulation and there are a lot of dusty decks out there.

                                1. 1

                                  Here are the systems I use at work.

                                  • I document issues, workarounds, and processes for technical support in our knowledge base.
                                  • Developer documentation for the apps I write is in a special purpose wiki.
                                    This includes libraries used, internals, user information, etc.
                                  • I have a OneNote notebook that supports my work on our document management system.
                                    It’s shared with the rest of the DMS support team.
                                  • I write up DMS processes in Word documents in our DMS.
                                  • Install instructions for my applications are Word documents stored in our DMS.
                                  1. 3

                                    Here are my comments about this library.

                                    • byte_array::randomize
                                      Whether or not this is a CSPRNG depends on the value of MONOCYPHER_HAS_ARC4RANDOM.
                                      This behavior is confusing and likely to cause issues.
                                      I would recommend using #error to fail the build if MONOCYPHER_HAS_ARC4RANDOM isn’t defined.
                                    • byte_array::fill
                                      What’s special about the value 0?
                                      I would add a comment here.
                                    • hash - this should use a static_assert to check the size.
                                      Also, why permit values under 32 if they aren’t recommended?
                                      I would prefer to use static_assert to require that size is either 32 or 64.
                                    • argon2i - this should use a static assert to ensure that the size is either 32 or 64.
                                    • key - the constructor should take and validate a length parameter.
                                      This makes it obvious to the reader how many bytes will be read.
                                    • public_key - see last comment
                                    • signing_key - see last comment
                                    1. 1

                                      Thanks for the comments. Responding to the first two:

                                      • The alternative, std::random_device, is also a CSPRNG when such is available on the platform, per the C++ standard. It’s still possible you might get low-entropy randomness if running on a platform without such support (embedded systems?) but there’s no way for me to tell. I called this out in the README.
                                      • 0 is special because that’s what the wipe method fills with, so there’s no need to zero it twice.
                                    1. 11

                                      This article is a very nice read. I will be using it as an answer to the many people asking me why kak?

                                      I have switched almost a year ago and I cannot imagine myself going back to any other editors I have used before.

                                      1. 12

                                        And I will steal this paragraph, closest to my heart:

                                        If that doesn’t sound anything special, it means that it makes sense. Unfortunately, the field of text editors on UNIX systems has over the years turned into an archipelago, in which every editor aims at being an island. Job management, shell, terminal emulation, window multiplexing… Text editors have turned into closed ecosystems (or Integrated Development Environments) that provide many (sometimes cardboard-looking) features unrelated to editing, which new comers have to buy into, or be left out in the cold.

                                        1. 6

                                          Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

                                          1. 11

                                            Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

                                            There’s nothing unusual about the Kakoune project having their own data structures; it’s common for C++ projects to contain functionality that’s also in the standard library.
                                            I would say that this reflects more on the language then on the Kakoune project.

                                            1. 9

                                              There are various places where the internal diff algorithm is used, such as in the terminal output code (on the builtin-terminal-ui branch that replaces ncurses with a custom backend), when we reload a buffer or pipe part of a buffer through an external filter, the diff algorithm allows Kakoune to know what actually changed.

                                              Kakoune replaces some of the standard library utilities with its own for various reasons, HashMap is used instead of std::unordered_map to provide slightly different semantics (iteration order matches insertion order for example) and better performance (HashMap uses open addressing), RefPtr is used instead of shared_ptr because we use an intrusive ref count and we share the implementation with SafePtr (a pointer type that makes an object assert at destruction if any pointers to it remain alive).

                                              1. 1

                                                I think you are mixing two concepts, but I can understand you wrong.

                                            2. 6

                                              In Dutch, kak is slang for poop / shit. So I find your statement funny, why kak.

                                              1. 3

                                                Well, it is usual abbreviation of the program. My bad, as it is very similar in Czech (and some other Slavic langs). So better, Why Kakoune?

                                              2. 5

                                                Thanks!

                                                Are you aware of the article (written by the creator of the project himself) titled “Why Kakoune?”, though? I didn’t expect that my article could be seen as an argument for the editor, it’s an interesting angle.

                                                1. 1

                                                  I was not aware of it, thanks for sharing. Even if it is much more “why”, it is also much longer :-). And programmers love to steal in my experience :-).

                                              1. 1

                                                This is an interesting read or listen, thanks for posting it.

                                                1. 3

                                                  Wow, I like this part:

                                                  There’s a famous site called Project Euler, where users write code to solve mathy problems such as “In a modified version of the board game Monopoly, on what three squares is a player most likely to land?” My former programming-contest coach advocated against using it to practice, because “It’s not really programming, and it’s not really math.”

                                                  I’m not going to begrudge anyone if they want to do it, but I took a look at Project Euler after seeing so many people do it, and was uninterested. Maybe because I did a lot of discrete math in high school or something …

                                                  Likewise I own “Elements of Programming” and also found little use for it. It’s not math and it’s not programming – great description.


                                                  However I definitely respect the STL and C++, and I happen to be doing more template programming than I’ve done in 20+ years right now – to write a pretty type safe garbage collector! This is the kind of thing where C++ really shines – where you need low level control, and you also want types and abstraction.

                                                  To me it looks like C++ and Rust are the only languages where you can do such a thing, and C++ came 25-30 years earlier. Alexandrescu proposed that “writing a garbage collector” in a language is a critical test for whether a language is a “systems language” or not, and there is some truth to that.

                                                  1. 2

                                                    To me it looks like C++ and Rust are the only languages where you can do such a thing, and C++ came 25-30 years earlier. Alexandrescu proposed that “writing a garbage collector” in a language is a critical test for whether a language is a “systems language” or not, and there is some truth to that.

                                                    I’d add Ada and Common Lisp to the list, also.

                                                    In any case, I agree with you and the article author about “Elements of Programming.” I skimmed through it several years ago, and didn’t understand what the author was going for. There’s been a strong tie between math and computer science going back to before electronic computers even existed, but it seemed the author ignored all of it and came up with his own version using C++ template meta-programming to illustrate everything.

                                                    1. 1

                                                      Citations?

                                                      1. 4

                                                        Ada has generics, classes, and equivalents for the low-level functionality of C++.
                                                        Address arithmetic, for example, can be done with System.Address.
                                                        There is some low-level functionality that is absent from C or C++; you can specify the bit-order within bit fields. Some of Stepanov’s early work on generic programming was done with Ada.

                                                        Edited to add the following text.
                                                        Henry Baker wrote a 1993 paper on an Ada 83 garbage collector.

                                                        History of T discusses a garbage collector written in Pre-Scheme, a Scheme subset.

                                                        Edited again to add a Lisp example.

                                                        How to define new intrinsics in SBCL is an example of low-level support in a recent Lisp.

                                                        1. 1

                                                          Thanks, although I probably didn’t make clear what I was talking about. I’m not just talking about low-level control in high level languages, although that is relevant – I’m talking static types and metaprogramming and how they help you write a garbage collector.

                                                          I should have linked this previous comment where I linked to a paper by the authors/inventors of the Immix garbage collection algorithm. They implemented Immix and Rust and (surprisingly) found that its type system actually helped.

                                                          https://lobste.rs/s/9duro8/rune_programming_language#c_2f90p3

                                                          This is kind of a paradox because the essential nature of the garbage collector is to enforce a homogeneous view of memory on top of a heterogeneously-typed heap.

                                                          If you want a quick demo, look at figure 1. It’s an abstraction over a pointer.


                                                          I am finding the same thing in C++. I can implement an abstract type with storage that is a single pointer, and that is extremely helpful. v8 and SpiderMonkey do the same thing with Rooted<T>, Handle<T>, etc.

                                                          https://old.reddit.com/r/ProgrammingLanguages/comments/ivyaw8/clawing_our_way_back_to_precision_spidermonkey/

                                                          Apparently Rust goes even further, and you can even (paradoxically) use lifetimes to help with a GC, although I don’t have experience with that.


                                                          I looked at the Cheney algorithm in es shell and in femtolisp in C, and if you compare it with mine in C++, it looks VERY different. For one, you don’t have to push and pop variables to maintain precise stack roots – I just use a pointer-like type Local<T>. (I don’t think Ada can do this – looks like it has basic C-style address arithmetic) Again this is what all the JS VMs that we use do.

                                                          And I also like these types:

                                                          https://github.com/oilshell/oil/blob/master/mycpp/gc_heap.cc#L13

                                                          You can sorta do that in C, although the inheritance helps too. The explicit reinterpret_cast vs. static_cast in C++ helps a lot too.


                                                          Cool trick I just learned with offsetof and constexpr: https://old.reddit.com/r/cpp_questions/comments/iz84pb/how_to_portably_calculate_field_offset_bitmasks/

                                                          Key point: the layout depends on compiler flags, so you can’t just generate field bitmasks. Introspection with the compiler is useful!


                                                          I should probably write a blog post like “C++ features that help you write a garbage collector”:

                                                          • pointer-like types, and templates
                                                          • inheritance (e.g. from Obj, for object headers) – although I needed to use C-style macros for a different reason
                                                          • more precise casting
                                                          • offsetof and constexpr

                                                          Though the part in the History of T and locality of copying collection is pretty interesting (BFS vs DFS)! I’ll have to look into that more as it’s an issue I’ve been wonderiing about.

                                                        2. 1

                                                          I’m not sure what you want a citation for? Are you asking for garbage collectors written in Ada and Common Lisp?

                                                          I don’t know of any off hand, but my intention was to point out that Ada and Common Lisp are two other languages offering high level abstractions but also low level control. I suppose I should have quoted the sentence above that paragraph.

                                                          1. 1

                                                            See my sibling response: https://lobste.rs/s/bqnhbo/book_review_elements_programmnig#c_l7fnoh

                                                            The Rust paper is basically what I was talking about; the same is true in C++ but not other languages

                                                    1. 4

                                                      I have never understood the complaint of “yes/no are true/false is surprising!”. Do people not learn the tools they use before they use them?

                                                      1. 29

                                                        No? People don’t read the words you put in front of them, why would you expect someone using yaml for the first time to write a country code to know that “no” is one of the accepted booleans

                                                        There’s so many rules of yaml, it was impossible to read all of them concisely for years

                                                        1. 5

                                                          “I’m writing Python|Java|JavaScript|Go|InsertLangHere, I know my job. Why do I need to learn YAML first, it’s just like JSON”

                                                          1. 20

                                                            That’s just a snarky way of admitting it was a confusing mistake to make “yes” and “no” booleans. It was confusing enough that YAML 1.2 backtracked and booleans are now just “true” or “false”: https://yaml.org/spec/1.2/spec.html#id2803629

                                                            I also just generally disagree with the idea that everybody should learn every detail about every tool they use. Especially ridiculous for YAML when it claims to be a “human friendly data serialization standard”. Sorry, but having to memorize a 100 page spec first or getting bit by confusing, counterintuitive errors isn’t “human friendly”.

                                                            1. 3

                                                              People want a JSON replacement, but the YAML spec is as big as the XML spec.

                                                              They are not prepared to spend that much effort on it, rightfully so in my opinion.

                                                            2. 1

                                                              s/No/false

                                                              1. 1

                                                                I’m just confused why “people don’t read the words you put in front of them” leads to an indictment of YAML, and not the people who refuse to read.

                                                                1. 8

                                                                  Because, in practice, people not reading (or remembering) stuff is an unavoidable property of the environment in which technologies like YAML must operate.

                                                              2. 9

                                                                Sure, most people do. But then a year later, somebody (who’s not thinking about quirks of YAML) comes along and sees the country code list, adds a couple of entries, and somewhere else completely disconnected there’s an explosion because there’s a false in their list of strings, and the error message will almost certainly have nothing at all to do with “you need to quote ‘no’ in your yaml config”.

                                                                1. 7

                                                                  Do people not learn the tools they use before they use them?

                                                                  Good designs are intuitive and can be used without a lot of understanding.
                                                                  Users should fall into the pit of success; it should be easy to succeed and hard for them to fail.
                                                                  If a technology requires a lot of study there are a few possible explanations:

                                                                  • It uses a completely different model, e.g. APL, Prolog, or Haskell.
                                                                  • The domain is essentially complex.
                                                                  • The design has some rough edges.
                                                                    Every design has a few issues but they shouldn’t be a regular occurrence.

                                                                  I’d say YAML falls into the last category.

                                                                  1. 3

                                                                    What would be the best document to learn YAML? Something more thorough than a tutorial but less comprehensive than a spec?

                                                                    1. 3

                                                                      https://learnxinyminutes.com/docs/yaml/

                                                                      Edit: Hmm, it doesn’t point out the yes/no thing. Disappointing.

                                                                  1. 3

                                                                    No one likes YAML but it survives. I am definitely amused at such cryptic languages which thrives despite being kludgy.

                                                                    1. 9

                                                                      No one likes YAML but it survives. I am definitely amused at such cryptic languages which thrives despite being kludgy.

                                                                      “Good things come to an end, bad things have to be stopped.” ― Kim Newman

                                                                    1. 1

                                                                      I’m slogging away in the trenches of application support.
                                                                      I have 3 pressing issues to work on:

                                                                      • Resolve or find a workaround to a recurring issue with an application you have heard of.
                                                                        This is my top priority; some of the users have equity.
                                                                      • Resolve another issue with another application.
                                                                      • Write a script to install an update for a poorly written Excel add-in.
                                                                        We have a platinum-level support contract with the vendor - support is rare, expensive, and difficult to obtain.
                                                                      1. 3

                                                                        Finish reading The Last Astronaut by David Wellington. I recently learned how to write a naive multi-armed bandit algorithm in Python. I’m going to write it again in a different language to get a better understanding of it.

                                                                        1. 2

                                                                          Thanks for mentioning this book. I started reading it and am really enjoying it.

                                                                        1. 4

                                                                          it turns out there’s a Phd bachelor thesis on this topic.

                                                                          Edited to correct error per child post

                                                                          1. 3

                                                                            Looks like a bachelor’s thesis, not a Ph.D thesis.

                                                                            Pretty big difference there.

                                                                            1. 1

                                                                              You’re right, my mistake.

                                                                            2. 3

                                                                              Fascinating! At some point I read one of the previous explanations cited in this paper. I’m delighted to see Robertson went one step further and algebraically derived the constant optimal post-Newton iteration, producing optimal constants for 64 and 128 bit floats.