minus7

Just stopping adding features limitlessly would go a long way

But why post here then

Absolutely, isalnum et al are probably never going to be a bottleneck. I was curious whether it even made a difference at all, after all, the naive implementation doesn't really do a lot.

And I fully agree with you that this glibc code is awful. As evidenced by the Plan 9 implementation, table lookups can be done simple as well, and probably perform just the same.

I was wondering whether there was a significant performance improvement of the table lookup glibc does over the naive implementation musl has.

The answer is a pretty big yes. Glibc's isalnum is about 6-7 times faster than musl's.

Benchmark code: https://paste.sr.ht/~minus/18b44cfe58789bc1fb69494130e859a11...

Proprietary renderer (not even source-available; Linux binaries linked against god knows what version of libc, libstdc++, etc) ontop of WebKit? No thanks.

Edit: I mean, sure, you could use it in your proprietary Electron app to make it more lightweight. At least on Windows, macOS and some Linuxes, the rest of users is left out then, but those free software enthusiasts are unlikely to use your software anyway.

That's not quite true: the compositor needs to support it. There's a protocol [1] for it that's supported by a redshift with a patch [2]. It also works out the box for any wlroots-based [3] compositors, like sway [4].

[1] https://github.com/swaywm/wlr-protocols/blob/master/unstable...

[2] https://github.com/minus7/redshift/tree/wayland

[3] https://github.com/swaywm/wlroots

[4] https://github.com/swaywm/sway

This is a nice high-level API for (more) reliably handling networking, taking a fair amount of load off developers having to implement it themselves. Of course it would be nice to have an API like that available as cross-platform library.

Oh right, I was wrongly thinking you'd have to memcmp the whole size of the filter. It's simply too warm today for thinking. Did you look into Cuckoo filters as well?

Would be nice if they made a bloom filter for anyone to use. On second thought, you can do that yourself based on the SHA-1 hashes of passwords they offer for download.

Edit: On third thought, a bloom filter for 502M entries and a false positive rate of 0.1% ends up as a 800MiB large filter. Binary-searching the whole dump is surely faster.

Is it really so hard to write a native GUI for three OSes if you must?

Couldn't you theoretically run traffic over pseudo-TCP. I.e. you send packets that look like TCP (IP packet type TCP + TCP header), but bypass the kernel's TCP stack and put arbitrary, packet-based data in it, like UDP. Theoretically speaking.

One thing to keep in mind when using materialized views is that a refresh will recompute the complete view and discard the old one. If at a certain size you might want to make sure your database server doesn't drown in rebuilds.

The alternative to building a materialized view may be to build an index with a tsvector instead, though the that might not work since the document is not trivial; it certainly would have a problem with tags, though those can be treated separately. The huge advantage of an index is that it's automatically refreshed for you.

Realistically though, you'll probably never run into performance problems building a materialized view due to too many submitted recipes. ;)

I'm puzzled as to why one would ever force smooth scrolling with JavaScript. Browsers have that by default, and when people turn it off you can most certainly be sure it's on purpose.

Or at least a WebM. But not a fucking 2.8 MiB large GIF.

Please, Google, I don't care about related articles while I'm reading this one, bugger off.

Actually it can work quite well without language-level support. Python's gevent library [0] shows that. It "simply" monkey-patches the standard library's IO functions to implicitly switch to another "greenlet" when blocking IO is performed. On the user side you don't really see anything of that (no "await" or similar). Admittedly, that hides possible points of context switches, but is still far less dangerous with regard to race conditions than OS threads. Unfortunately, gevent seems to be shunned quite a bit and I haven't seen other languages do similar things.

[0] http://www.gevent.org/

Oh, lovely. I'll have to check out Kotlin's coroutines in more detail. So far I haven't seen many coroutine/green thread implementations I like. In fact the only one I like is Python's gevent since it's very non-intrusive and often works with existing libraries without modification, whereas Python's async/await or C# (I think) require every part to be aware of the coro (and unwind the stack when suspending)

> * operator overloading, mostly for math like matrices, vectors, complex numbers

Kotlin has infix functions which help there without treading the dangerous territory of ambiguousness

Lombok addresses one pain point of Java (constructors/getters/setters), Kotlin addresses more. Lombok also does a bit of magic, so should be used with care. E.g. @AllArgsConstructor is a dangerous one if you change the order of fields, especially if you don't have IDE support for Lombok.

Oh Vert.x, I despise it. We jumped on that in 2014 (Vert.x 2) and it's still haunting us. Half-broken build with an outdated Gradle plugin (should've stuck with the official build system), doesn't integrate with the major part of the Java ecosystem due to being callback-based (exceptions can hardly be used, nor can anything that blocks on IO) and tooling for managing tasks doesn't exist either (e.g. running a couple of IO-tasks in order requires you to nest the callbacks if you don't write your own tooling).

I assume Vert.x 3 is doing a better job there, but the fundamental problem remains: callbacks don't work well with exceptions. Maybe Kotlin helps wrapping this nicer, I don't know. All I know is that I'll be more careful when selecting a framework for productive use now. And maybe that I won't be using Vert.x again.

Sounds like it'd be a fun game

And this is why you offer local image/file uploads on your platform/forum. You simply can't rely on a free this party service to stay alive forever, especially something unprofitable as image hosting

The bigger problem, when personally archiving websites and whatnot, is managing that data, i.e. organizing storage and making it searchable. https://camlistore.org/ seems to be the right software for that, though I haven't tried it yet.

I can't shed the feeling that CORS is just piling more crap onto crap; this seems just way too complex. On one hand, I'm somewhat glad that I don't work on web things and don't have to deal with it, and on the other hand I'm scared of the many web developers are not (sufficiently) aware of the range of possible vulnerabilities and thus not protecting them.

Reloading the page helps; the state is stored.

I wanted to see it in graph form, so a wrote I did pretty much the same but printed a dot code and piped that into dot. It was a disaster: A huge, unreadable mess. Try yourself if you're feeling adventurous:

    import json
    
    with open('base.560.json') as f:
        base = json.load(f)
    
    with open('names.560.json') as f:
        names = json.load(f)
    
    print('digraph {')
    
    for elnum, name in names.items():
        print(f'e{elnum} [label="{name}"];')
    
    for elnum, body in base.items():
        for el1, el2 in body.get('parents', ()):
            print(f'e{el1} -> e{elnum};')
            print(f'e{el2} -> e{elnum};')
    
    print('}')

    # python3.6 code.py | dot -Tpng dot.png

I noticed that too; it takes like 10 seconds to generate a "pixelized" (it's still vector graphics, isn't it?) map that I can't imagine taking more than a couple milliseconds to rasterize.

> Don't be a free user.

Now that's just rude. Not even the linked article [0] manages to convince otherwise. In fact, it even shows the opposite standpoint:

> If your free software project suddenly gets popular, you gain resources: testers, developers and people willing to pitch in. If your free website takes off, you lose resources.

If you don't want users to use it for free, don't offer it for free, but don't insult your users.

[0] https://blog.pinboard.in/2011/12/don_t_be_a_free_user/

If you take a look at the code on Github you quickly realize it's complete bullshit, a bit of hardcoded data [1] and one file of backend code that looks like it was copied from somewhere [2].

[1] https://github.com/tdrach/Sciview/blob/master/public/javascr...

[2] https://github.com/tdrach/Sciview/blob/master/routes/api/v1/...

I'm not sure what you mean. If you don't know what the encoding of the input file is you have a problem. As far as I know there are libraries to guess the encoding, but it cannot be determined completely accurate.