>4. Program authors are forced to explicitly document ahead of time all situations in which their program code might be modified in the future
Can you point me to a resource that explains this in more detail? I think I've gotten the gist of how Ethereum works, and have gone through a tutorial of Solidity, but I'm unclear how versioning will work in Ethereum (even though I do have some guesses for how it could be implemented).
How would I deploy a new version of my contract? Would I have to implement a mechanism for basically hot loading new code?
If you want your contract to be updateable, you can have the contract store an address of a contract which is the part you might want to change. Then, to update the contract, you upload the new version of the contract ( or contract component) , and make the address that the first contract stores point to the new one.
Uh...
Users interact directly with contract A.
Contract A stores a address which currently points to contract B, and uses whatever contract it currently points to to accomplish whatever it needs to do for users.
To update the part of Contract A, upload an updated contract C, and send A a message to tell it to change the address it stores to point to contract C instead.
Contract A only changes where the address points if whatever conditions it was designed to use for that are met.
And, of course, you don't have to use this "point to another contract" thing.
That's just if you need part of the contract to be updateable under some conditions, which you might not need.
Yeah, that's pretty much it: By default, contracts can't be updated, but you can create a network of multiple contracts to allow some of your code to update. Myself, I think this is "cheating" and destroys the value proposition of ethereum... a better approach (and what I hope to do) is to keep my main contract(s) alive for all eternity and just add new features with "accessory contracts" but it's easy to fail with this if the original contract has problems.
>Now, go ahead and name some non-gaming uses of CV1. I bet you can't come up with anything compelling
False. I own a DK2, which I regularly show to other non-gamers. It always blows their mind and they immediately start considering possible applications in their fields (film, medicine, architecture, dataviz, installation art, etc). I've even gotten people to introduce it to their coworkers and bosses to consider using it in some capacity.
Hi, can I shoot you a few quick questions over email about the process of applying for OPT extension while employed at your own company? Would really appreciate some advice on this.
you're claiming that if if it was meant to be a critique it's ineffective yet you found yourself realizing "how much [you were] thinking about this silly little thing"
The cadence of your post implies to me that you're exposing some sort of hypocrisy on my part.
My entire point was that I had gotten all riled up about something being dumb, but that something had caused me to think in a way atypical of dumb things.
"The discovery of the alphabet will create forgetfulness in the learner’s souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. You give your disciples not truth but only the semblance of truth; they will be heroes of many things, and will have learned nothing; they will appear to be omniscient and will generally know nothing." -- Socrates, in Plato's "Phaedrus"
This is not the 'evolutionary perspective' as you claim it is. This is just your perspective dressed in evolutionary terminology so that the reader will believe that if you accept human evolution, you MUST accept this conclusion. But the fact that you came up with a possible evolutionary past and thought of a constraint that could've pushed us to develop the adaptive behavior of procrastination doesn't in any way imply that this is actually the way things happened. Procrastination might've been a fitness-maximizing adaptation (or even just a spandrel [1]) for so many other equally convincing reasons.
It's really strange that while for molecular & morphological phenotypes we use rigorous methods to measure evolutionary relatedness so we can determine possible sequences of evolutionary adaptations that led to them, when it comes to behavioral phenotypes people think that conceivability arguments coupled with very inconclusive evidence are sufficient to demonstrate that some evolutionary story is true.
Great list. I didn't know about De Landa's work, looks really interesting. In the same spirit, and for something more recent, I'd recommend Lanier's You Are Not a Gadget. I also find Erik Davis' Techgnosis to be a criminally well-written book.
That's not entirely true -- there are some applications of the Epoc that can actually perform detections which cannot solely be attributed to facial muscle movement. [1] Of course, the signal-to-noise ratio is much lower than that of research-grade devices, so a lot of preprocessing is required.
> The Dial Tim application works on similar principles to P300-spellerbrain-computer interfaces: the phone flashes a
sequence of photos of contacts from the address book and a P300 neural signal is elicited when the flashed photo matches the
person whom the user wishes to dial.
This is just as I've said above, one brain signal is used over time.
Woah, awesome! I know it's just a POC, but it's great to see people using Emokit -- I'm disappointed that I didn't have enough time to dedicate to doing anything with it when I started it. Let me know if you run into any issues.
Thanks! I also did some basic rhythm detection: https://github.com/agermanidis/emokit/blob/master/python/uti..., and added a simulation option so folks that want to contribute to the library but don't actually have it (I suspect that there are exactly zero of them, but anyway) can still test it on sample data.
Oh very cool -- I wrote some super basic stuff for this, but it didn't work well at all, and I never had any time to improve it. Is your stuff merged into the qdot branch yet? If not, you should definitely send a pull request, as I think it'd work well with what he's been working on.
Can you point me to a resource that explains this in more detail? I think I've gotten the gist of how Ethereum works, and have gone through a tutorial of Solidity, but I'm unclear how versioning will work in Ethereum (even though I do have some guesses for how it could be implemented).
How would I deploy a new version of my contract? Would I have to implement a mechanism for basically hot loading new code?