libera/#sicl - IRC Chatlog
Search
10:58:48
mfiano
I'm just thinking about my protocol redesign. There are some modules that have both an "internal" and "external" protocol. The former is a superset of the latter intended to be consumed by other modules internal to the codebase, while the latter is the outer/user API. I go back and forth on this or just using un-exported symbols for the internal code. The reason why, is it becomes confusing for the
10:58:50
mfiano
user, and must be documented that one package is not to be used. I'm curious what you think about this.
11:20:12
jackdaniel
mfiano: after some times I've found the most natural and flexible the following arrangament: there are two package: foo and foo-internals; the application is fully implemented in the latter
11:20:35
jackdaniel
foo-internals USEs foo, and deciding what is an external protocol is just a matter of changing what foo exports
11:21:15
jackdaniel
that way whole implementation has access to itself without infridging another package internal symbols
11:21:39
mfiano
That is essentially what I was referring to what I do above, except I never USE, instead using PLN.
11:23:22
jackdaniel
because when you decide that some other symbol should be moved to the "external" interface, then you'd need to change the code in internals to add the "short" package prefix
11:38:47
hayley
Tangetically related, I did some tests with Java concurrent compacting collectors, and got some interesting results. But apparently I can't publish my results without breaking the EULA of the no-cost Azul JVM (as there is a DeWitt clause).
11:43:12
jackdaniel
I think that each benchmark when comparing various implementations of the same api should put an empty bar for versions with this clause with [*] saying "xxx is too afraid that to compete" :)
11:43:21
hayley
Seems I can't find any complicated software engineering projects myself which don't get legally hairy. [n=2]
11:46:05
hayley
This EULA also states that "the existence of the Product" is "Proprietary Information", and I cannot publish proprietary information. So I may have already broken the EULA. Oops.
11:47:39
jackdaniel
there is a certain thing regarding nda's - when the /thing/ becomes public by other means you are free to discuss it regardless of the nda
11:48:19
jackdaniel
(not sure how it applies to "proprietary information" from eula's, but it seems natural that the same would apply)
11:49:34
hayley
Right, that was mentioned too. But the /thing/ would probably take a few more decades to become public, if it ever does.
11:54:41
hayley
Well, here is a procedure if anyone wants to replicate my results at home: 1. Download recent ABCL and OpenJDK and Azul JVMs 2. Run ABCL and load Hunchentoot 3. Start an EASY-ACCEPTOR 4. Run your favourite web throughput testing tool to find the maximum throughput of each JVM 5. Run your favourite latency testing tool to get a latency histogram for some load (I used 75% of the maximum) 6. Be somewhat enlightened by the histograms
11:55:46
jackdaniel
so it is doubtful whether fbi comes in if you share the keypoints of the enlightenment
11:59:09
hayley
Right. All I really need to say is whether the concurrent sometimes-compacting generational GC is comparable in throughput to the non-concurrent sometimes-compacting generational GC. And indeed it is.
12:01:18
jackdaniel
looking at how many technology startups thrive gives an impression that bullshit sells, so I doubt that it will cause that. they will pivot to: concurrent sometimes-compacting generational gc, but with blockchain
12:02:58
hayley
Is this crap even legally enforceable? I mean, if I do publish the results a bad benchmark, it could plausibly be a case of slander, but you get the right to sue me without any license agreement. So anything more is absurd.
12:11:53
hayley
Comparing OpenJDK 11 and 16, it seemed that improvements to compilers had a larger effect on throughput than adding more barriers for concurrent GC.