time | 2017-10-21 |
---|---|
23:10 | <joepie91> earendel: proper infinite scroll is *far* more complicated than that |
23:54 | <earendel> <joepie91>..in practice, nobody is going to care about related posts beyond the first 5 // how can u always fap to the same videos on your favorite porn site |
time | 2017-10-22 |
---|---|
00:04 | <earendel> joepie91: another reason you have to love the search results on npmjs.org |
time | 2017-10-28 |
---|---|
01:34 | <earendel> <joepie91>but yeah, the answer to "what HTTP methods exist" basically depends on "which specs have you chosen" -- there exist as many as you like |
time | 2017-11-01 |
---|---|
18:09 | <earendel> joepie91: are you familliar sockets? tcp sockets in particular? |
18:20 | <joepie91> earendel: I know about sockets, yes |
18:20 | <joepie91> !ask @ earendel |
21:55 | <earendel> joepie91: ThePendulum: BabyGirlCake99: jaawerth: gde33: cantelope: #Node.js: excellences & grey emincences: balrogs and other past winged demons: awake! please help e getting this simple (but not working:) irc-proxy done .. https://github.com/hagb4rd/ea-irc-proxy.git |
time | 2017-11-02 |
---|---|
11:40 | <joepie91> earendel: blockchains are completely unsuitable for the majority of usecases |
11:40 | <earendel> joepie91: pff |
time | 2017-11-08 |
---|---|
20:24 | <joepie91> earendel: unicode, not utf8 :P |
time | 2017-11-19 |
---|---|
21:41 | <joepie91> earendel: likely because it's proprietary |
21:48 | <earendel> joepie91: i stumbled upon this "explanation" .. it may not at all make sense, but for sure leads deeper into some rabbit hole: "let and const declarations define variables that are scoped to the running execution context’s LexicalEnvironment. The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated. A |
21:51 | <joepie91> earendel: I don't think that has anything to do with typeof? the explanation is correct |
21:51 | <joepie91> earendel: that is, a let/const-defined variable exists (ie. shadows other scopes) in the entire scope from the moment that scope is entered, but it may only be accessed once your code has passed the statement that actually defines it |
21:52 | <earendel> joepie91: well i kinda agree with you. the explanation is not really justifying the behaviour |
21:52 | <joepie91> earendel: one sec |
21:52 | <earendel> joepie91: sure. |
21:53 | <joepie91> earendel: https://gist.github.com/anonymous/ac933325399391b4d09746963a2056d3 |
21:54 | <joepie91> earendel: reason: `foo` is defined in two scopes, the function scope and the if scope... the moment the code hits line 5 it 'enters' the if scope, but while that scope will *eventually* shadow the `foo` in the function scope, `foo` is not yet defined within the if scope and therefore using it is disallowed |
21:54 | <joepie91> earendel: so between line 5 and 7 it is disallowed to access `foo` |
21:55 | <joepie91> earendel: I'm unsure what the rationale behind this decision is, but I suspect it's something like "preventing accidental use of a variable from the wrong scope when switching around the order of code" |
21:59 | <earendel> n> typeof(basdsafdf) // joepie91: sure.. yet typeof was the only operator/expression you could use on undeclared variables without causing a throw .. anyway.. it really doesn't make any sense! and i mean from the perspective of language design any sense to change this when somewhere in the same fucking scope somebody uses a let or a const, which are both not hoisted but screw the behavior of typeof .. right?! |
time | 2017-11-20 |
---|---|
07:26 | <earendel> ::logs joepie91 earendel |