1,544 karma · joined December 10, 2008
I'm a hacker from London who works on decentralised systems.
Feel free to contact me for help/advice or just for a friendly chat:
tav@espians.com
http://tav.espians.com
https://twitter.com/tav
All content produced by me on HN is dedicated to the Public Domain:
* http://creativecommons.org/publicdomain/zero/1.0/
Use it however you want :)
[ my public key: https://keybase.io/tav; my proof: https://keybase.io/tav/sigs/mWU8_7ohyVhbWe4CC4-BULZt9ko__aSLRFa1T-GJ5xc ]
Any chance you'll be adding something like the parse function? The ability to have domain-specific dialects was one of the best things about Rebol and would be great to see in a modern language.
And speaking of functions, could you make the "Function Reference" that's on the homepage, be available on a standalone page too? It's a very useful reference and would be great to access it easily. Thanks!
1. Use a postfix ?! instead of .await
2. Use a postfix ?? instead of .await?
3. Use the await keyword only in the "for await" construct
Then the common case becomes:
let resp = http::get(url)??.to_string()
Which, imo, is a bit easier to parse than: let resp = http::get(url).await?.to_string()
This would make it easier to follow the core logic in async code, the same way that ? made error handling so much cleaner in Rust.* Most developers didn't want to handle matters like global VAT reporting individually, so ideally the money would flow through a central entity which took care of that for them so that they only have to deal with a single source of income.
* The need to support ad-hoc transfer of funds between standalone accounts when maintainers approved transfers to other developers they are collaborating with.
Stripe Connect with managed accounts helps to solve some of these issues, e.g. by creating charges on the platform account and then creating individual transfers to connected accounts. But according to https://stripe.com/docs/connect/charges-transfers:
"This approach is only fully supported when both your platform and the connected account are in the U.S. If your platform or the connected account is outside of the U.S., you can only use this approach for less than 10% of your total volume."
So, is there some other method that's available? Because right now, I'm looking at handling the payouts myself and using Stripe to handle just the incoming payment processing. And it'd be great to use Stripe for both instead!
(P.S. Congrats on the new job!)
Because, unlike say Kickstarter/Patreon, where the money goes to a single entity/person, open source collaborations tend to be distributed and dynamic. So you effectively need to build a payments company and handle all of the headache that goes along with it.
But, having said that, I very much believe that something like this is needed — and thus why I'm still persevering with the project. Happy to chat further if cperciva/others are interested.
For those interested, here is the direct link to the new GFM spec: https://github.github.com/gfm/
[0] https://cloud.google.com/appengine/docs/flexible/
[1] https://cloud.google.com/appengine/docs/flexible/python/how-...
Note Title.
- [ ] Some subtask.
- [x] Another subtask.
You could then group subtasks within a single note and tick them off as you go without having to edit the note every time. Cheers and thank you for the fantastic new features![1] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...
Is there a list of TLDs which are supported somewhere? When I last looked (years ago), only Verisign provided registry locking and the other registries weren't showing any signs of coming out with similar products.
Thank you ever so much for the hard work done by yourself and the rest of the Rust developer community. It has been an absolute pleasure seeing the language evolve, and now that it's hit 1.0, I look forward to the incredible opportunities it makes possible.
It takes great courage to go against the grain in terms of the core language (e.g. abandoning GC, M:N scheduling, etc. as core parts of the language), but the end result promises some truly exciting times. Thank you again and thank you also to you and the others for commenting here on HN despite the heavy criticism at times and being ever so helpful for those of us on IRC. It's been a fantastic ride and I look forward to it getting even better.
At least with my banks, when they send me updated cards, only a handful of the digits actually change and most of those changes have tended to be in the last 4 digits — which Stripe lets you see, along with the updated expiry month/year.
At this point, it's just a matter of brute forcing the remaining permutations. Am I misunderstanding something or are there countermeasures to protect against such attacks?
In contrast, using MutationObserver results in correct behaviour on all modern browsers and relatively minimal delays — between 0.002ms and 0.007ms according to an OS X only micro-benchmark I did last month [2].
And, yes, it would be great if we could call a builtin instead of hacking on top of MutationObserver, but it isn't that ugly:
if MutationObserver
$div = root.document.createElement 'div'
observer = new MutationObserver tick
observer.observe $div, attributes: true
scheduleTick = ->
$div.setAttribute 'class', 'tick'
return
else
scheduleTick = ->
setTimeout tick, 0
return
In conclusion, I agree that a feature like setImmediate would be great. But given IE's broken implementation and a viable workaround in modern browsers, I see no need to rush it. I'd rather they focused on: new features like Object.observe; improving the performance of old features like Object.seal; and finalising some of the ES7 ideas like exposing the event loop![1] http://codeforhire.com/2013/09/21/setimmediate-and-messagech...
Also, any chance we could have strongly consistent auto-expiring keys in DynamoDB? Would make DynamoDB a very useful tool for synchronisation/lease management and other funky uses.
I also sent Werner an email asking if it would be suitable to use DynamoDB as a block device — you could then build a filesystem on top and benefit from DynamoDB features like replication, consistency, etc. Unfortunately, I fear the email must have slipped through his no-doubt-busy-inbox. If any of DynamoDB developers could shed any light on its suitability as a block device, that would be awesome! Thanks.
* https://blogs.akamai.com/2012/07/spdy-and-websocket-support-...