Very often when searching (with google) for subjective things you'll find a closed stackoverflow link high up in the results. I know stackoverflow isn't appropiate for those questions but i still keep going to those results. I understand their position, it's just annoying. This is an example of something i found today: http://stackoverflow.com/questions/4674609/looking-for-a-ric...
All native Unix filesystems do this (well...at least since V7; I don't remember about V6 or before). It's so the root user (and the kernel, and applications running as root, e.g. logging) would have some amount of disk space to work with if needed. Much more important in the days when typical servers had less than 100MB of disk.
The default is (usually) 5%. In these more bountiful days of multi-terabyte disks I generally knock that down to 1%.
I don't think the choice is that binary (git OR dropbox). I've needed to use both mercurial and git for different jobs. From that experience i would say mercurial is just as powerful as git but more intuitive and easy to learn.
> A vector of bytes uses significantly more than one byte per byte.
There is still the option to use an array of bytes (the primitive data type, not the class Byte) if the performance of boxing/unboxing is a problem.
In fact, i don't understand how the vector example is relevant to generics at all. Even pre-generics the underlying storage for a Vector in java would be an Object array so the boxing/unboxing would still happen?
Ah, this threw me for a while too. So the answer appears to be: Suppose you have a generic function X(Y), where the "Y" is generic. Now suppose you want Y to be truly generic, and not just Java-style generic, which means that Y may be any size. That is, it may be a "byte", it may be "short", a "long", a 184-byte struct, a pointer, etc etc etc. The way most programming languages do functions, functions encode into themselves the sizes of what they are expecting, and the expectation for how they are going to receive parameters. Therefore, a single function can't take all those options, and at the very least you end up needing one per base size, plus one for spilling to the stack... and that's just to deal with the size issue, you still have signedness, various struct properties if you're passing structs, etc.
So one option is to "box" everything, which basically amounts to saying "I will take a pointer to everything", and in the case of Go, "I will take the pointer to that thing's type". (That's how interfaces work in Go.) Now everything is the same size (pointer-sized). But now everything's boxed. Alternatively, you can compile lots of functions, but now everything's compiled in separate copies of the function.
From the high-level language POV it all seems so simple. When converting it into actual assembly, which has to interact with the rest of the system, it gets more complicated, and the performance implications of even slight slowdowns to a function call can be catastrophic given how many of them we make.
Personally I'm still interested in the question of whether it's feasible to create a different calling convention into a generic function that deals with this directly. This might not be possible in C due to its age, or C++ due to its reverse-compatibility heritage, but I'm interested in whether we can write a sufficiently-generic (in the more general sense of the term) function calling system that it can work with Go better. Basically looking at types like a vtable and abstracting out all the calls that are size-dependent into vtable-lookups, which ought to be slower but only slightly slower than a direct call (given that it seems like everything can be resolved at compile time except the actual address). But I don't know. Interested to hear if anybody else has ever tried that or anything similar. (Assembler is a great deal more flexible than the structured programming we have laid on top of it, at least in theory.)
For what i've been using java for it's never really bothered me. When there is need to use primitives it's almost always in the form of a list where you can just use an array instead to avoid the boxing/unboxing.
The risk of null pointer exceptions when implicitly unboxing objects are more annoying..
Espion is similar to PhantomJS in that they're both headless browsers that you can inject JavaScript into.
Espion comes with a lot more. First there is the infrastructure: processing power, storage, connectivity and IP addresses that you don't have to provision, set up or manage. Second, Espion includes the features that surround extracting data from a site such as job scheduling, data quality monitoring, online debugging and problem resolution and data delivery.
PhantomJS is perfectly viable, but if you need the features I highlighted and use it, you'll have to build a lot yourself to get the job done.
KiwiIRC uses this protocol apparently. I asked the author about it and they said they have worked out special arrangements with some networks to implement it, and accept connections exclusively from Kiwi, I presume? After all, a password is required according to this spec:
https://kiwiirc.com/docs/webirc
That discussion escalated quickly.. What i got from the thread is that systemd will only work with glibc, intentionally? If that's the case then it's kind of sad. Since systemd will become the standard glibc will be the only alternative.
