When looking at established file formats, I'd start with zip for that usecase over tarballs. zip has compression and ability to access any file. A tarfule you have to uncompress first.
SquashFS or cramps or such have less tooling, which makes the usage for generating, inspecting, ... more complex.
You only have to decompress it first if it's compressed (commonly using gzip, which is shown with the .gz suffix).
Otherwise, you can randomly access any file in a .tar as long as:
- the file is seekable/range-addressible
- you scan through it and build the file index first, either at runtime or in advance.
Uncompressed .tar is a reasonable choice for this application because the tools to read/write tar files are very standard, the file format is simple and well-documented, and it incurs no computational overhead.
You've just constructed your own crappy in-memory zip file, here. If you have to build your own custom index, you're no longer using the standard tools. If you find yourself building indices of tar files, and you control the creation, give yourself a break and use a zip file instead. It has the index built in. Compression is not required when packing files into a zip, if you don't want it.
Yeah it's pretty common to use zip files as purely a container format, with no compression enabled. You can even construct them in such a way it's possible to memory map the contents directly out of the zip file, or read them over network via a small number of range requsts.
You can achieve the same with tar if you individually compress the files before adding them to the tar ball instead of compressing the tar ball itself.
I don’t see how that plus a small index of offsets would be notably more or less work to do from using a zip file.
Zip has a central directory you could just query, instead of having to construct one in-memory by scanning the entire archive. That's significantly less work.
I mean if they include a pre-made index with it. For example an uncompressed index at byte offset 0 in the tar ball that lists what is inside and their offsets. It would still be comparable amount of work to create software to do that with tar as to use a zip file, if fine grained compression levels etc is being used.
I suppose you are right about that. But it would still be a valid tar file that can be viewed and extracted with normal tools. Kind of similar to how a .docx file can be extracted as zip but still has additional structure to its contents.
I had need to embed noVNC into an app recently in Golang. Serving files via net/http from the zip file is practically a one-liner (then just a Gorilla websocket to take the place of websockify).
I second the idea to use a zip. In fact it's what a lot of vendors do because it is so ubiquitous, even Microsoft for example - the "open Microsoft Office XML document format" is just a zip file containing a bunch of folders and XML files.
Kinda ironic that standardebooks.org refuses non-English books but will happily promote a French ranking... I mean none of those books are actually available on standardebooks.org - at least not in their original French version.
And while you’re at it fix it so you can’t do a text selection of the game area. I’m having both zooming and selection happening and they make it unplayable.
Well, it's a string that will guarantee unique allocations (two identical strings are guaranteed to be allocated at the same address), which makes equality checks super fast (compare pointers directly). But pretty much just a string nonetheless...
Lisp symbols have various properties; the exact set depends on the dialect. The properties may be mutable (e.g. property list, value cell).
You can certainly associate such things with an integer: e.g. value_cell[42], plist[42].
But those associations are part of the "symbolness", not just the 42.
Integers are not suitable symbols in some ways: they have a security problem.
Real symbols can be used for sandboxing: if you don't already hold the symbol, you have no way to get it.
This won't happen for integers. Especially not reasonably small integers.
What do I mean that if you don't already have a symbol, you have no way to get it? If the symbol is interned, you can intern it, right?
Not if there is a symbol package system, and you don't have access to the package in which the symbol is interned.
Now you might say, since objects are typically represented as pointers, aren't those a kind of integer anyway? Yes they are, but they are different type which doesn't support arithmetic; we can restrict programs from calculating arbitrary pointers, but we can't restrict programs from calculating arbitrary integers.
Even if we have escape hatches for converting an integer to a pointer, or other security/safety bypassng mechanisms, those escape hatches have an API which is identified by symbols, which we can exclude from the sandbox.
I (and GP given their use of capitalised Symbol) was talking about Ruby symbols, which for the most part are more equivalent to their object_id than to their textual representation.
What I mean by "integer" is not "pointer", it's "natural number", in the sense that there exists only one `1` vs you can have multiple textual "foo" strings.
So it's more useful to think of symbols as natural numbers which you don't know nor care the actual value of, because as a human you only care about the label you have attached to it, but you do care about its numberness property of it conceptually existing only once.
String can be interned in Ruby, but it’s always possible for an equal string that is not interned to also exist. Hence interned strings can’t benefit from the same optimization than symbols.
You can first compare them by pointer, but on a mismatch you have to fallback to comparing content. Same for the hashcode, you have to hash the content.
I'm talking about as a user of the language, not as a language designer. I have an unpopular opinion about this, but symbols are error prone and these optimizations are ultimately not worth it.
Feels like a disassembly of a boilerplate app, as opposed to handcrafted, minimal assembly code.
For instance I’m pretty sure the autorelease pool is unnecessary as long as you don’t use the autorelease mechanism of Objective-C, which you’re most likely not going to do if you’re writing assembly in the first place.
> so it's almost certain that private APIs would get accessed
No it's not. Just like with ObjC or Swift, in ASM you have to be explicit about the APIs you want to call. I don't see how you would accidentally call a private API in ASM.
IMO the bigger risk is attempting to call a method that does not actually exist. ObjC or Swift would protect you from that, but ASM would not and may just crash at runtime.
What? That doesn’t make any sense. The only guard rails normal Obj-C has against calling private APIs is that they aren’t listed in the public headers, otherwise you can still easily call them. If you don’t explicitly make calls to private APIs from ASM, the won’t be called. I have no idea why you think “it’s almost certain that private APIs would get accessed.”
I wanted to use blender for quick pose reference yesterday and I was able to find several good ones and even one great one within 5min. They're around.
Because of a lack of features? It doesn't even have IK so I would argue Blender is in fact easier to use (as in, will get you to the result faster even if you need a bit more time to learn the interface).
This has pre-built poses, props and a bunch of other easy to use features. This is classic hacker-news ‘Less intuitive and more complicated X is better because I already know how to use X’
I must have spent a hundred hours in Blender over the years, and I'm still not competent enough to do even some of the most basic things on my own when I pick it up.
Blender is an amazing project, but I would not suggest it as an alternative to OP's tool if asked by someone who practices drawing and has zero Blender experience or interest.
reply