Hacker News new | past | comments | ask | show | jobs | submit | funny_falcon's comments login

There is the trick: use enum for const. It works most of the time.

Yes, at least that's better than macros.

It seems meson is gaining traction and will overpass cmake in near future.

Another quite similar technique from OpenSmalltalk: https://clementbera.wordpress.com/2018/11/09/64-bits-immedia...


CRuby uses this technique on 64bit platforms for years.

Edit: the commit https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...


> CRuby uses this technique on 64bit platforms for years.

What do you mean by "this technique"?

The paper says that CRuby uses tagged objects but could benefit from the innovation being discussed here, a specific bit pattern used to tag floats. See the following quote:

> Therefore, implementations that represent floats as tagged pointers could benefit from it with minimal implementation effort. Such popular implementations include CPython [11], CRuby [32] and Google’s V8 [33].


In fact, CRuby successfully combined “Self Tagging” with pointer tagging. Here's the commit:

https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...


Seems legit.

Linked commit contains code for rotating tagged floats so bits 60..62 go to the least significant positions, and a comment about a range of unboxed floats between 1.7...e-77 and 1.7...e77, plus special casing 0.0.


I mean, CRuby does “Float Self Tagging” for years. Paper just has the mistake about CRuby.


Just correction: CRuby uses “Float Self-Tagging” for years.


This is your 4th comment claiming this: it's not true.

You're right that Ruby uses tags, ex. Objective-C does also and has for a while.

The innovation here is its a tag without the tag bits. That's why its self-tagging, not tagging.


In another comment, this user links a CRuby commit that they claim adds it. It seems legit.

Linked commit contains code for rotating tagged floats so bits 60..62 go to the least significant positions, and a comment about a range of unboxed floats between 1.7...e-77 and 1.7...e77, plus special casing 0.0

e.g. this excerpt:

    #if USE_FLONUM
    #define RUBY_BIT_ROTL(v, n) (((v) << (n)) | ((v) >> ((sizeof(v) * 8) - n)))
    #define RUBY_BIT_ROTR(v, n) (((v) >> (n)) | ((v) << ((sizeof(v) * 8) - n)))
    
    static inline double
    rb_float_value(VALUE v)
    {
      if (FLONUM_P(v)) {
 if (v == (VALUE)0x8000000000000002) {
     return 0.0;
 }
 else {
     union {
  double d;
  VALUE v;
     } t;

     VALUE b63 = (v >> 63);
     /* e: xx1... -> 011... */
     /*    xx0... -> 100... */
     /*      ^b63           */
     t.v = RUBY_BIT_ROTR(((b63 ^ 1) << 1) | b63 | (v & ~0x03), 3);
     return t.d;
 }
      }
      else {
 return ((struct RFloat *)v)->float_value;
      }
    }


But commits exists even this year: https://sourceforge.net/p/lush/activity/


Readability, reproducibility, and simple LRU.

Reproducibility matters for tests, they become simpler. Some other algorithms become simpler as well.

LRU is just a dict with preserving order: on access just delete and insert again.


Unfortunately, pocketpy moved to global reference to vm recently while changing implementation from C++ to C. Weird decision.


AFAIK, Signal doesn’t provide any way to prove its application were built from non-modified audited free open source code. Indeed there are evidences it behaves “a bit” differently.

So unless you’ve built application by yourself, you have no guarantee of it’s sequrity.


As a PostgreSQL smallish contributor I just can say: NO, DON'T DO THIS!!!!

Extensible type system is a worst thing that could happend with database end-user performance. Then one may not short-cut no single thing in query parsing and optimization: you must check type of any single operand, find correct operator implemenation, find correct index operator family/class and many more all through querying system catalog. And input/output of values are also goes through the functions, stored in system catalog. You may not even answer to "select 1" without consulting with system catalog.

There should be sane set of builtin types + struct/json like way of composition. That is like most DBs do except PostgreSQL. And I strongly believe it is right way.


> you must check type of any single operand, find correct operator implemenation, find correct index operator family/class and many more all through querying system catalog.

Not with static typing.

The problem with PG is that it's not fully statically typed internally. SQLite3 is worse still, naturally. But a statically typed SQL RDBMS should be possible.


What “Statically typed” would mean for SQL DB with extensible type system?


It means you can define new types, not that you can store values of arbitrary types in columns you already have.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: