Fork me on GitHub
#off-topic
<
2021-08-26
>
sova-soars-the-sora11:08:18

I noticed we sometimes mention emacs in here... I really enjoy Prelude for Emacs https://prelude.emacsredux.com/en/latest/

borkdude13:08:27

yep, me too!

βž• 1
borkdude13:08:32

been a user for years now

eyalch13:08:51

Speaking of editors/IDEs, does anybody use VS Code with the Calva extension?

borkdude13:08:57

@eyalch lots of people do, there's also the #calva channel

Nom Nom Mousse13:08:04

I have a piece of software that relies heavily on hashes. Does anyone know if there are JVM libs that let me create easily rememberable hashes like ubuntu version names or similar like "Trusty Tahir"? The hashing function does not need to be cryptographically secure, but should have a low probability of collisions.

p-himik13:08:27

Just as an idea, if you don't find a library. Get a list of nouns, like http://www.desiquintans.com/nounlist, and assign a number to each. With that particular list, you will cover hashes through 1 to 6775. On hash 6776, use two nouns. And so on - like a base-6775 numeration where each digit is a noun.

p-himik13:08:26

One thing to note - a hash can be any int, so 0 and negative values are correct.

πŸ‘ 3
tvaughan13:08:54

The word lists at https://www.eff.org/dice might be helpful for this approach too

Nom Nom Mousse14:08:21

Cool! I like the adjective-noun approach. Then I need a non-crappy hash-function that can give me a tuple of numbers. The first to be the index in the adjective-list and the second for the noun-list. I'd really like to avoid offensive or hurtful combinations like "irreproachable pogrom" or whatever so a library would be best.

noisesmith18:08:13

any number can be treated as a tuple if you split the bytes

noisesmith19:08:20

eg. split a 32 bit hash into 2 16 bit values:

(ins)user=> (hash "foo")
493551392
(ins)user=> (type *1)
java.lang.Integer
(ins)user=> (defn split-hash [o] (let [h (hash o)] [(bit-shift-right h 16) (bit-and h 0xffff)]))
#'user/split-hash
(ins)user=> (split-hash "foo")
[7530 65312]
(ins)user=> (defn unsplit-hash [[high low]] (+ (bit-shift-left high 16) low))
#'user/unsplit-hash
(ins)user=> (unsplit-hash (split-hash "foo"))
493551392

noisesmith19:08:14

so, given a corpus of N words, an algorithmically straightforward approach is to calculate byte-count (the largest number of bytes whose max value is less than N), split the hash into groups of bytes of length byte-count or less, then map each of those to a word

noisesmith19:08:01

I feel like I just had a flashback to TAOCP

Nom Nom Mousse06:08:31

Thanks for the above noisesmith πŸ™‚

Nom Nom Mousse06:08:40

I thought of the above, but I was not sure whether splitting them in two would make some combinations of words more likely. But if every number from 0 to 2^32 is equally likely that shouldn't happen.

mchampine19:12:02

An alternative to dice words is pgpwords - https://en.wikipedia.org/wiki/PGP_word_list I have implemented some pgpwords conversion utilities in Clojure here: https://github.com/mchampine/pgpwords You might find the long->words function useful. For example:

(long->words 653686720632)
;;=> ("printer" "component" "snowcap" "retrieval" "island")

πŸ™ 1
Nom Nom Mousse14:08:43

Any suggestions for a hash-function that can hash even large files quickly? Or am I better off hashing the size and created-date if I want speed?

solf14:08:27

One cool command to compare hashes:

openssl speed md4 md5 sha1 sha256

solf14:08:09

As for your question, it’s very use-case dependant, so only you can answer whether hashing is fast enough

βž• 3
p-himik14:08:25

You can't properly hash the data without reading it, so the top limit is always your disk's read speed. And creation date does not represent the data itself. If you're fine with more frequent hash collisions, you can probably get away with hashing the first N megabytes or a sample of uniformly distributed blocks of some size.

πŸ™ 9
valtteri18:08:57

I’ve been using Emacs Prelude for a couple of years. However during summer holidays I took a few days to make my own config from scratch and it was an enlightening experience! Now I have the feeling that I know how everything works. Also if something doesn’t work I know exactly where to look. My config is in a single init.el which is ~275 loc.

valtteri18:08:22

Also now I feel I’m more deeply rooted to my Emacs. 🌲 I expect that in ~20 years I will assimilate completely into it.

Drew Verlee19:08:04

I'm struggling to see why I would i should prefer using a css style sheet over using clojure (inline styles) to organize my styles. 1. a class has to do a lookup to get the style 2. fetching a style sheet is a blocking action 3. clojure > what ever css compos ability options are out there. 4. A style sheet can be cached, so it would save time if the styles, js and html updated independently, but i think this is fairly rare.

p-himik19:08:56

That's basically a question of vanilla CSS vs CSS-in-JS. Buckets of blood have been spilled during this debate.

noisesmith19:08:07

if you have people on your team that design web pages and css rules but don't write clojure, a stylesheet is probably better

p-himik19:08:09

There are many arguments. :) IMO it's better to just look the existing discussions online than to have another one here. It's, no joke, one of the most contentious topic in web development I've seen. Not trying to shoo anyone away, of course, but the amount of information and variations in approaches is staggering.

noisesmith19:08:40

understood. web programming "best practices" are in my experience a cess pool of garbage and irrational nonsense, but my hands on experience is that in the specific situation where someone writes html/css but not clojure, a style sheet saves a lot of problems

noisesmith19:08:59

or maybe more abstractly: in order to commit a working change to the app, who has to edit which files, and what is their expertise? your solution should probably aim to streamline that process.

Drew Verlee19:08:24

I have been reading the arguments, most seem to be complecting issues of organization and performance. inline vs stylesheets has caching implications. But from a organization standpoint I want to use clojure. That being said with the magic of macros you would write inline and generate stylesheets, I started thinking about how to do that this morning. While looking at the limitations of cljss. However i stopped and decided i need to justify classes in the first place. Given nothing seems to compare the two in terms of painting the screen, and logically the styles have to be pulled from the class style sheet. It would actually be slower So now it's both slower and harder to work that way, yet it's considered best practice? I assume the reason is closer to what noisesmith is saying. It allows for a separation of concerns such that a dedicated styles expert can work in their niche. A valid reason for many, not for most teams i have been on. πŸ™‚

p-himik19:08:35

Have you actually measured the performance of inline styles vs classes?

Drew Verlee19:08:17

In what context? I know it would be slower to paint if you had to fetch it. If were talking about loaded in-line vs loaded stylesheet i don't know. I can't find anything I trust. I'm thumping through Googles critical rending path documentation hopefully something is in there i can use.

Drew Verlee19:08:47

it might be browser specific, though i doubt it.

Drew Verlee19:08:49

Your question is the major thing i was wondering about though.

p-himik19:08:11

It will 100% be browser-specific, although the results might differ only in the absolute values. The engines are completely different in e.g. Chrome vs FF vs Safari.

p-himik19:08:31

Personally, I stopped caring about such minuscule performance impacts long ago. The time investment to figure it all out is simply not worth it when it comes to browsers - you have to run rather fast to maintain accurate knowledge.

p-himik19:08:14

Exactly. I have seen quite a few cases where an answer on SO or some article would include a performance test that you could reproduce yourself, and the test would give completely different results just a year or two after the initial run.

isak19:08:26

Here is a case that I think would favor classes: say you are doing server-rendered HTML, and you are returning a ton of elements. So either you add the inline style 1E9 times in the html, or you add a class (or do a nested selector)

Drew Verlee20:08:10

@U08JKUHA9 That's a fair point, but I would argue for composition over inheritance in most cases. does that make sense? But yea, that would be a case to consider for classes.

isak20:08:20

I use tailwind and find that more productive than either, but yea it is basically the same as inline styles

Drew Verlee20:08:47

I suppose i'm thinking of selectors in your example. Classes would still need to be attached. It's funny you should mention tailwind, i'm using it as an example of something I don't understand the utility of. From my perspective it would be about as reasonable as doing this: (defn add-2 [x] (+ x 2)) (defn add-3 [x] (+ x 3)) I feel it's a compromise to an argument where everyone forgot what they were yelling about. πŸ˜†

felipebarros20:08:38

@U0DJ4T5U1 At Gaiwan (Lambda Island) we are very close to releasing an open source library that allows you to write your CSS in Clojure (with Garden, like you probably expect to write it inline) and not only aggregates it and puts it into a regular CSS file, but namespaces the classes to avoid clashes (a major advantage of CSS in JS), allows you to encapsulate associated style and logic into named components and even to optionally leverage Girouette for a Tailwind like experience. It is pretty cool and we are already using it in production (the new Lambda Island website uses it). Soon! :)

πŸ’― 11
Drew Verlee20:08:58

@U6MEUHZBK That sounds really cool. It would be interesting to note how it compares to cljss or stylefy. Which are the two altneratives that go the direction of compiling clojure and extracting a stylesheet. For example, cljss requires their defstyles be given a hashamp, so you can't easily compose using clojure. The only way i can see around this is another macro with evals it's content. Another example, Stylefy uses local storage for caching, which actually makes me wonder where the browser normally does it? I assumed it would be local storage! Overall, i'm sure there are some cases i haven't through through in this argument.

isak20:08:18

@U0DJ4T5U1 If you were writing styles, would you litter your code would values like rgb(154,230,180)) , or would you assign that to a variable like green-300? That is one of the main benefits of tailwind, and a sensible structure for doing that. There are also a lot of things you can't do in inline styles, like only applying certain styles for certain screen widths and above, which comes up all the time if you are designing for mobile web.

Drew Verlee20:08:23

If i was re-using them and i wanted them to update together then i would use a variable. But i can declare variables in clojure.

isak20:08:30

Right, but then you are not disagreeing with tailwind in principle, you are just doing it a different way

Drew Verlee20:08:44

Fair enough, I'm saying it provides a layer of pre built indirection i don't see the value to. Would i quibble over it if it was already part of an application? Certainly not.

felipebarros20:08:46

A major advantage of Tailwind is to allow you not to worry about CSS selectors and the cascade and to write your styles right where you have your markup or your logic. Writing in Clojure with a "CSS in JS" like library you can have that for free and then CSS vs Tailwind becomes mostly about taste and verbosity (e.g. garden maps with regular variables or tailwind like classes).

πŸ’― 2
isak20:08:47

Yea the value just comes from how you can compose the variables together. For example, a.gray-300.hover:gray-900 - it isn't clear how you'd do the same with Clojure variables, esp. using inline styles

Drew Verlee20:08:33

Ideally you achieve it with clojure. e.g (def button-style {:color "blue"}) (assoc button-style :height "50px")

felipebarros20:08:38

or {:color (:blue palette) :height "50px"}

Drew Verlee20:08:14

i'm a bit of a borg when it comes to clojure though.

isak20:08:02

Here is a clojure version, but the ideas are the same: https://github.com/green-coder/girouette

isak20:08:12

It is about having a grammar / vocabulary

Drew Verlee20:08:18

Yea. I think that's a part of it I don't appreciate due to lack of use, it serves as a bit of a shared style guide?

βœ… 3
felipebarros20:08:11

You can have a map where you define the values your team should use and drink from that while writing regular garden. (def styleguide {:colors {:blue "blue"} :large-font "4rem" :small-font "0.8rem"}), etc. Once you are writing it in place (where your markup or components are being defined) and it doesn't clash (thus avoids the complexities of the cascade and selectors), the line between CSS and utility CSS gets much, much smaller.

3
Drew Verlee21:08:06

@U6MEUHZBK You seem to have a better handle on this then me. What's the reason to trouble compiling to css classes at all? I have to assume it's a performance issue with caching.

felipebarros21:08:05

This stack overflow answer does a better job of explaining that, but yes, caching, organization and avoiding duplication. Also, remember that styles can make the HTML (your vital load) much larger. https://stackoverflow.com/questions/8284365/external-css-vs-inline-style-performance-difference#8284398

Drew Verlee22:08:03

A rough draft on my CSS article where i tackle the issue and everything that i feel could touch it. https://drewverlee.github.io/posts-output/2021-8-26-css