|
Sapozhnik posted:or does any sort of io at all really
|
#
?
Nov 3, 2017 02:07
|
|
|
|
| # ? May 18, 2024 02:51 |
|
|
that's your fault for using Linux
|
|
#
?
Nov 3, 2017 02:12
|
|
|
IoCompletionPorts are the best part about windows.
|
|
#
?
Nov 3, 2017 02:38
|
|
|
the Macintosh operating system supported async I/O pervasively when released in 1984: you set a pointer in your I/O parameter block and your call to perform some I/O would return immediately and your event loop could keep running, your function pointer would be called (at interrupt time) as soon as the I/O was complete or an error occurred you could actually get decent throughput this way, though it was obviously more complex to program unfortunately tons of developers learned C on time-shared UNIX systems in school and brought that brain damage with when they tried to program for the Mac, complaining both about both the lack of performance with synchronous I/O and the complexity of doing anything else
|
|
#
?
Nov 3, 2017 05:20
|
|
|
Barbarians Led By Bill Gates has a whole chapter about Gates's flip-out when he found out that Mac apps couldn't be auto-translated to Windows because of that
|
|
#
?
Nov 3, 2017 06:13
|
|
|
first thing I’ve heard about it that makes me want to read it I still love Hertzfield’s story about Gates’ wonder at the smoothness of the mouse pointer on Lisa & Macintosh, and his assumption it couldn’t be done without a hardware cursor (the 6522 Versatile Interface Adapter is a magical chip, even the Apple II could do a smooth mouse cursor with one on the mouse card)
|
|
#
?
Nov 4, 2017 02:13
|
|
|
holy poo poo "mouse card" how far we have come
|
|
#
?
Nov 4, 2017 02:16
|
|
|
eschaton posted:the Macintosh operating system supported async I/O pervasively when released in 1984: you set a pointer in your I/O parameter block and your call to perform some I/O would return immediately and your event loop could keep running, your function pointer would be called (at interrupt time) as soon as the I/O was complete or an error occurred less glad that what replaced it is "no async at all" 
|
|
#
?
Nov 4, 2017 03:38
|
|
|
Come to Javascript where it's not just callback-based async, it's done with convention, no convention, promises and not, and now syntax sugar, so you can have a surprise every time you open up a codebase.
|
|
#
?
Nov 4, 2017 04:32
|
|
|
Maluco Marinero posted:Come to Javascript where it's not just callback-based async, it's done with convention, no convention, promises and not, and now syntax sugar, so you can have a surprise every time you open up a codebase. yeah, the language supports cool stuff like async await. there's no reason to use inferior runtimes like .net anymore.
|
|
#
?
Nov 4, 2017 04:37
|
|
|
e: nvm
VikingofRock fucked around with this message at 04:41 on Nov 4, 2017 |
|
#
?
Nov 4, 2017 04:38
|
|
|
loving listen you remember soundcards like soundblaster etc? there used to be mouse cards apparently
|
|
#
?
Nov 4, 2017 04:39
|
|
|
VikingofRock posted:I still don't really get the difference between futures and promises in C++ i don't get why c++ is even a thing still
|
|
#
?
Nov 4, 2017 04:39
|
|
|
akadajet posted:i don't get why c++ is even a thing still Well that post was particularly stupid because I looked it up and promise is a function which returns a future and I misremembered it. But you quoted it too fast!
|
|
#
?
Nov 4, 2017 04:42
|
|
|
VikingofRock posted:Well that post was particularly stupid because I looked it up and promise is a function which returns a future and I misremembered it. But you quoted it too fast! the stupid thing is c++, not your post
|
|
#
?
Nov 4, 2017 04:44
|
|
|
There's promise, future, async, and packaged_task and I always need to look them up before using them because I can never keep them straight
|
|
#
?
Nov 4, 2017 04:45
|
|
|
Maluco Marinero posted:so you can have a surprise every time you open up a different file in the same codebase. Turns out all the different async options fight with each other. You know, intermittently.
|
|
#
?
Nov 4, 2017 05:27
|
|
|
Powaqoatse posted:loving listen yeah, there was this thing called a “bus mouse” for IBM PC clone users who had more slots to spare than serial ports Lisa and Macintosh had the hardware to run a mouse built in, of course, as did the Apple //c and IIgs, and Apple made a mouse card for earlier Apple II systems that was basically just a VIA to handle counting the quadrature inputs and generating a VBL interrupt, and a ROM with the driver in it that knew how to turn that into screen coordinates
|
|
#
?
Nov 4, 2017 07:01
|
|
|
isnt it very easy in js to convert a method that takes a callback to a method that returns a promise, and if you have async/await support you can just await the promise?
|
|
#
?
Nov 4, 2017 07:06
|
|
|
it's easy to translate between asynchrony models if you understand both clearly & have had enough sleep, also easy to screw up massively
Gazpacho fucked around with this message at 07:11 on Nov 4, 2017 |
|
#
?
Nov 4, 2017 07:09
|
|
|
in my current soon to be former job i had to develop a script to make some WebRTC calls which could be callback based or promise based depending on the browser, but in any case the code needed to be promise-structured for maintainability even if the browser didn't support promises. so i ended up pulling a very small promise/A+ library and wrapping all the WebRTC results in A+ promises
|
|
#
?
Nov 4, 2017 07:19
|
|
|
fleshweasel posted:isnt it very easy in js to convert a method that takes a callback to a method that returns a promise, and if you have async/await support you can just await the promise? it’s straightforward to work with them if you know the in and the out, but when you’re working with several libraries all with their own stance on async, and you’re trying to pull it all together into code that is readable and user friendly, it all feels like mixing oil and water. ecosystem, integration and large scale applications are where JavaScript is just a crapshoot. it’s why Typescript exists, to ease some of this because of how permissive the errors flow on beyond the actual mistake if they get into the runtime.
|
|
#
?
Nov 4, 2017 07:38
|
|
|
eschaton posted:yeah, there was this thing called a “bus mouse” for IBM PC clone users who had more slots to spare than serial ports lol pure madness. Amigas handled mice fine too i wonder how well a mouse worked in GeOS on the c64. I only had joysticks at the time and moving a cursor around with a joystick was pretty bad so i never used it much
|
|
#
?
Nov 4, 2017 07:48
|
|
|
VikingofRock posted:There's promise, future, async, and packaged_task and I always need to look them up before using them because I can never keep them straight I always found the first three easy enough You promise to eventually provide a value You can get a value in the future You can ask someone else to do the work asynchronously with you... I had to look up packaged task 
|
|
#
?
Nov 4, 2017 09:11
|
|
|
Gazpacho posted:in my current soon to be former job i had to develop a script to make some WebRTC calls which could be callback based or promise based depending on the browser  how the gently caress did that happen, webrtc got standardized way after the standard Promise object did (it's IE, isn't it. It's always IE)
|
|
#
?
Nov 4, 2017 16:16
|
|
|
Sapozhnik posted:
|
|
#
?
Nov 4, 2017 19:08
|
|
|
Sapozhnik posted:
google bought webrtc from some other company, copy/pasted it into chrome wholesale and put a "webkit" prefix before it. they then had their dev evangelist teams push it heavily and rushed it through standardization. no browsers bothered with es6 promises at that time because they were easily polyfilled. so sure, it was standardized later, but the implementation order was the reverse.
|
|
#
?
Nov 4, 2017 19:59
|
|
|
Gazpacho posted:Barbarians Led By Bill Gates has a whole chapter about Gates's flip-out when he found out that Mac apps couldn't be auto-translated to Windows because of that ty again for the recommendation, it’s interesting if very obviously biased and somewhat amateurishly written and typeset
|
|
#
?
Nov 4, 2017 20:06
|
|
|
Suspicious Dish posted:google bought webrtc from some other company, copy/pasted it into chrome wholesale and put a "webkit" prefix before it. they then had their dev evangelist teams push it heavily and rushed it through standardization. no browsers bothered with es6 promises at that time because they were easily polyfilled. so sure, it was standardized later, but the implementation order was the reverse. webrtc is trash so microsoft had to create objectrtc and since google is the de facto web monopoly nobody else implemented it
|
|
#
?
Nov 4, 2017 22:02
|
|
|
Suspicious Dish posted:google bought webrtc from some other company, copy/pasted it into chrome wholesale and put a "webkit" prefix before it. they then had their dev evangelist teams push it heavily and rushed it through standardization. no browsers bothered with es6 promises at that time because they were easily polyfilled. so sure, it was standardized later, but the implementation order was the reverse. it was all strategically important for google though, to accelerate their introducing/deprecating cycle for chat systems from almost 2 years down to a planned 36 minutes by 2019
|
|
#
?
Nov 5, 2017 12:10
|
|
|
Malcolm XML posted:webrtc is trash so microsoft had to create objectrtc and since google is the de facto web monopoly nobody else implemented it
|
|
#
?
Nov 6, 2017 03:30
|
|
|
Ralith posted:what's wrong with webrtc it gave us chatroulette
|
|
#
?
Nov 6, 2017 03:34
|
|
|
webassembly
|
|
#
?
Nov 16, 2017 02:49
|
|
|
can wasm do things js can not do?
|
|
#
?
Nov 16, 2017 07:33
|
|
|
akadajet posted:it gave us chatroulette
|
|
#
?
Nov 16, 2017 07:51
|
|
|
i meant to make a bigger effortpost but just wanted to prime the posting gears by writing "webassembly" *cough* webassembly, for those who don't know, is the next jesus savior to the modern web after flexbox (which now everybody hates in favor of css grids) and react (which now everybody hates in favor of vue.js). the promise is high: a generic bytecode vm that any language can target. in reality, webassembly shares more in common with asm.js than it does java or python. basically, it's a winamp skin for asm.js: instead of your instructions being represented in javascript form, they get represented in bytecode form. that is practically the only difference. the execution model and type system is still the same: you get a giant gently caress-off array full of floats and ints, and anything else is bolted on top of that. what people don't know is that 90% of what you do in webassembly is actually provided by a bunch of javascript support runtime code in emscripten. like, that unity tanks demo? that relies on this 8,000 piece of poo poo desktopgl-to-webgl wrapper because nobody has any good ideas on the web https://github.com/kripken/emscripten/blob/incoming/src/library_gl.js choice quote: // When user GL code wants to render from client-side memory, we need to upload the vertex data to a temp VBO // for rendering. Maintain a set of temp VBOs that are created-on-demand to appropriate sizes, and never destroyed. // Also, for best performance the VBOs are double-buffered, i.e. every second frame we switch the set of VBOs we // upload to, so that rendering from the previous frame is not disturbed by uploading from new data to it, which // could cause a GPU-CPU pipeline stall. if you know anything about opengl you know what a horrible idea this is. thanks, emscripten. ok but onto the actual topic of today. recently, there's a proposal for "opaque reference types" because they originally started bolting on their javascript gc before they realized that nobody loving wants that. i read through it, struggle to understand it, and so i post some issues on the issue tracker, hoping that the people that are much smarter than i am that made the proposal have an answer today i want to share with you one of those issues i filed. host bindings allow someone to reference, say, a DOMElement in webassembly and call things on it. the way this works is that there's a shitton of "tables", one for each type you want to call, and there's an allocation strategy for how these tables get filled up. here's a quote from the spec: For freeing slots, no explicit mechanism is provided. But the assumption is that global containing a pending free slot can be set prior to function return, which will get released on the next allocation. NOTE: This does have the side-effect of holding a reference to the last returned value of each type until the module is re-entered through a path that triggers the actual free. spot the very obvious problem with this issue, besides the NOTE provided. hint: the pending free slot isn't "top of stack" or similar, it's pointing to one slot index.
|
|
#
?
Nov 16, 2017 08:27
|
|
|
Suspicious Dish posted:basically, it's a winamp skin for asm.js lmbo
|
|
#
?
Nov 16, 2017 13:38
|
|
|
Shinku ABOOKEN posted:can wasm do things js can not do?
|
|
#
?
Nov 16, 2017 13:47
|
|
|
mystes posted:Blah blah blah turing completeness. But in reality it will make it a lot more practical to replace desktop applications for a lot of stuff. yes but what mechanisms does it have that javascript lacks? can you do x in wasm but not in javascript? what do you gain from wasm that you can’t gain by transpiling?
|
|
#
?
Nov 16, 2017 13:57
|
|
|
|
| # ? May 18, 2024 02:51 |
|
|
Shinku ABOOKEN posted:yes but what mechanisms does it have that javascript lacks? can you do x in wasm but not in javascript? what do you gain from wasm that you can’t gain by transpiling? i would hope one less layer of translation but from what suspicious dish says it doesnt sound like it lol
|
|
#
?
Nov 16, 2017 14:01
|
|