Oh wow, thank you for the clarification. I completely didn't even consider to audit for that in the ZIP source (though the ALL CAPS maybe should have been my hint). I'll update the post with this and another small thing another player found.
Zildjian cymbals are not any more prone to breaking than other manufacturers'. Whether they sound good to you is another story. :) It's hard to make that judgment about a product line so big and varied anyway.
These days I'm playing Sabians, mostly AAX. Not out of brand loyalty, just cause they all sound pretty good for what I do (loud, fast rock). But I've had a handful of Zildjians that I really enjoyed (wish I still had the 24" A Ping Ride that I broke in high school), some Paistes, a Meinl here, a Byzance there...
Are you an IRC shitposter? Isn't it hard to experiment with Toilet/Figlet fonts and flags? Well _not anymore._ Presenting Tuilet: a front-end to Toilet written by us, for us.
> Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?)
tuple_size/1 is a guard, and guards are built-in. The compiler itself uses them. Unlike regular functions, you are allowed to use guards in a function head, like:
def foo(my_tuple) when tuple_size(my_tuple) == 3 do ...
Ahh, that's it. I said in a sibling comment that I had no idea why it was like that. But reading this made me realize that at one point I did know why! Completely forgot this bit of knowledge in the last year of not using the language.
Oh yeah, FWIW a "built-in" function or macro just means it's a part of the Kernel module, which is automatically required+imported in Elixir modules. So it's not orphaned, it's just in the one special module that gets brought in by default.
> ...listing any given prefix is essentially constant time: I can take any given string, in a bucket with 100 billion objects, and say “give me the next 1000 keys alphabetically that come after this random string”.
I'm not sure we agree on the definition of "constant time" here. Just because you get 1000 keys in one network call doesn't imply anything about the complexity of the backend!
The technical implementation is indeed impressive that it operates more-or-less within constant time, but probably very few use cases actually fit that narrow window, so this technical strength is moot when it comes to actual usage.
Since each request is dependent upon the position received in the last request, 1000 arbitrary keys on your 3rd or 1000th attempt doesn't really help unless you found your needle in the haystack in that request (and in that case the rest of that 1000 key listing was wasted.)
You’re assuming you’re paginating through all objects from start to finish.
A request to list objects under “foo/“ is a request to list all objects starting with “foo/“, which is constant time irregardless of the number of keys before. Same applies for “foo/bar-“, or any other list request for any given prefix. There are no directories on s3.
> Don’t do it. Really, don’t do it. Anyone that has been giving tech talks for a while now knows not to do it. Don’t do it.
A few years ago, I found myself in San Francisco right on time to see Larry Wall give a talk announcing the release of Perl 6, and showing off some of its (abundant) features.
Larry Wall did the entire presentation in Vim, including live coding.
It's not that no one can pull this off, it's just that most of us aren't them :)
> It's not that no one can pull this off, it's just that most of us aren't them :
Having just done a talk at FOSDEM 2024 the main reason not to do a demo is that the slots in most devrooms are really short. In the monitoring devroom talks were in 30 minute slots, which included audio setup, talk, questions. Live demos can really enhance a presentation to developers but trying squeeze them into an already short slot can muddy the message. I would rather point the audience to examples they can run themselves.
On a related point, I find recorded demos pretty horrible. The pleasure in demos is seeing the presenter work fluently with technology and the audience at the same time: "the achieve of, the mastery of the thing!" as Gerard Manley Hopkins memorably phrased it. [0] It's showmanship and existence proof combined--and the most powerful rhetorical device to make technical points. The best ones are legend. [1]
In the Python world, James Powell is famous for breezing through a combination of vim (the editor) and wat (the tutorial by absurd) with a lot of custom command line tools and even examples that feel at the same time immoral, hilarious, and perfectly crafted. There’s a reason his GitHub handle and his company are called “Don’t use this code.”
He’s switched to analytical SQL lately, which is less prone to comedy but still very virtuoso.
> It's not that no one can pull this off, it's just that most of us aren't them :)
The issue is that live demos require INSANE amounts of prep.
You have to go over it. Then you go over it again. Then you go over it again with a stopwatch. Then you go over it again. Then you kill the network and go over it again. Then you go over it again with a stopwatch. Then you go over it with a friend with a stopwatch. Then you go over it again. Then you go over it with a friend but you use the stopwatch with no network. Then you go over it again. Repeat until you feel like you're in Groundhog Day. Then go over it one more time.
By the time you give the demo in front of people, you should be so damn bored with giving it that the only reason you want to give the talk is to see the audience reaction.
In my experience (I gave a demo as part of a talk today! It went great!), you want your code to be reliable (obviously... a 1 in 5 failure rate will bite you back on demo day), require as little thinking as possible (that can be worked around with increased automation, but if you automate all the things, you might as well be showing a recording), and rehearse things extensively (this applies to every part of a talk anyway).
Also rehearse on a specific commit/build. I've seen so many cases where a feature or two were added since rehearsal and about was introduced into the demo path. If you do want to fix something for the demo run through your rehearsal another few times on the new commit.
Some of his live demos take my breath away. I have to make notes to myself like "click the 'upload' button" so I don't forget during a presentation. It's like my brain switches to a mode where simple tasks are impossible
Yeah, there's a certain demo gods category who can usually make it work. But it's also sort of showing off. And I'm also somewhat unconvinced about how much demos add to a presentation a lot of the time.
Larry is a genius and perl6 (now raku) does indeed abound with features. The idea aiui was to minimize the need for external dependencies in most code bases and to bring together all the features into "v1" rather than suffer from bolt on features and shoehorned syntax down the road.
K&R C has no concept of THEN. That's a peculiarity of the ZIP source code, defined as a pure no-op:
https://github.com/ChristopherDrum/pez/blob/main/zip/infocom...