#jsmess 2016-11-02,Wed

↑back Search

Time Nickname Message
00:15 🔗 db48x this is torture
00:15 🔗 db48x it takes minutes to step over each statement
00:15 🔗 taisel hi
00:16 🔗 SketchCow whut
00:24 🔗 SketchCow bai is going to come back and all he's going to see is Alon Zakai's Z etched into the wall
00:24 🔗 SketchCow "Was he... was he here"
00:24 🔗 db48x :)
00:24 🔗 db48x taisel: hey, how have you been?
00:25 🔗 taisel not much
00:25 🔗 taisel ok I guess
00:25 🔗 taisel doing other stuff
00:25 🔗 db48x same here :)
00:25 🔗 taisel is wasm still in perpetual committee hell?
00:25 🔗 db48x seems to have made some progress
00:26 🔗 SketchCow mmmmmmm
00:26 🔗 SketchCow I mean, it works
00:26 🔗 SketchCow And we're going to force the issue!
00:26 🔗 taisel meanwhile the first few years of JS they fucking hit the "do it live" button
00:26 🔗 taisel and said screw superficial incompatibility
00:26 🔗 SketchCow The first few years of JS were super broke though
00:26 🔗 taisel truuuu
00:26 🔗 taisel 'member document.all
00:26 🔗 SketchCow And nobody had seen it at all
00:27 🔗 taisel and the IE5.5 box model
00:27 🔗 taisel people also forgot older IEs leaked RAM with normal valid js
00:28 🔗 taisel as they never collected cyclic references that got dereferenced by actual events and handles that are active
00:29 🔗 taisel you had to manually iterate through child objects manually nulling their properties before setting the object itself to null
00:30 🔗 taisel well, the top reference to null that is
00:30 🔗 taisel "manually de-cyclic" them
00:30 🔗 * db48x nods
00:31 🔗 taisel meanwhile obj-c during that era gave up and made people use strong vs. weak by hand
00:31 🔗 taisel better than breaking with memory leaks because it was implied shit would be cleaned up like it should
00:35 🔗 taisel I like how people are complaining overwatch has a cpu bottleneck
00:35 🔗 taisel meanwhile my rx 480 bottlenecks my rig
00:35 🔗 taisel got that recently
00:35 🔗 SketchCow Summary is, WebAssembly is coming along fine and we have a beautifully working test case even in current state
00:35 🔗 taisel nice
00:36 🔗 taisel I see a problem with future devs targeting MVP
00:36 🔗 taisel which doesn't contain threading, last I heard
00:37 🔗 taisel that was "post-mvp" last I checked
00:37 🔗 taisel like how people wrote for IE6 for years
00:37 🔗 taisel even when it went down in usage.
00:37 🔗 taisel WASM needs proper threading out the door imo.
00:38 🔗 taisel they need to stop this fascination with running wasm in js
00:38 🔗 taisel it was meant to be a clean break
00:38 🔗 taisel that whole wasm-in-js thing was the reason threading wasn't mvp
00:39 🔗 taisel I wish it was wasm instructions instead of FFI calls
00:39 🔗 taisel the example code for locks uses calls to the Atomics object in userland js
00:39 🔗 SketchCow This is a lot of anger
00:39 🔗 SketchCow Have you tried the new compile?
00:40 🔗 taisel last I checked this was the final proposal
00:40 🔗 taisel for FFI'ing threading
00:40 🔗 SketchCow I just mean we got it going
00:40 🔗 taisel yea
00:40 🔗 taisel asm.js uses FFIs
00:40 🔗 SketchCow baicoianu.com/~bai/emularity/pacman.html and all
00:41 🔗 taisel when you use pthread libs for asm.js they use FFIs to userland js under the hood
00:41 🔗 taisel and that incurs a very high cost
00:41 🔗 taisel and that's what's specified for threading in wasm officially last I checked
00:42 🔗 taisel that removes a lot of tight multi-threading cases from being viable
00:42 🔗 taisel due to the overhead
00:43 🔗 taisel your pthread calls almost all FFI out
00:45 🔗 taisel anyhow bbl
00:45 🔗 taisel quit poof
00:45 🔗 taisel woops
00:45 🔗 taisel forgot the /
00:45 🔗 taisel lmao
00:45 🔗 taisel has quit IRC (Quit: poof poof)
00:46 🔗 DFJustin yeah the js interpreter seems to be slow as heck so I'm not sure why they're bothering
00:46 🔗 SketchCow That's a lotta anger
01:04 🔗 SketchCow So, while we're waiting for bai to come back and swim upstream, I had a question for db48x and DFJustin
01:04 🔗 SketchCow How hard is it, do we think, to set up a load where we go either:
01:04 🔗 SketchCow - Boot using this image, then swap and have this image loaded
01:05 🔗 SketchCow - boot an apple 2 so the first two disk images are in S6D1 and S6D2
01:44 🔗 Swizzle has joined #jsmess
02:09 🔗 logchfoo2 starts logging #jsmess at Wed Nov 02 02:09:03 2016
02:09 🔗 logchfoo2 has joined #jsmess
02:25 🔗 Swizzle has quit IRC (Quit: Leaving)
02:36 🔗 db48x booting with two disks is trivial
02:37 🔗 db48x but not very well documented (I've got to double check what goes in the per-system json file and what goes in the per-item metadata)
02:39 🔗 bai aaaand I'm back. had to go fix some electrical problems at my mother in law's house. exposed wire, throwing sparks, the whole lot
02:39 🔗 SketchCow You won't believe
02:39 🔗 bai I caught up on what azakai had to said, he did answer my question
02:39 🔗 bai basically "the direct to wasm path is unfinished and fraught with peril"
02:40 🔗 bai so the working versions we have are as good as it gets right now, but there's a possibility for it to get even better when they fix that
02:40 🔗 SketchCow Right
02:40 🔗 SketchCow And he suggested trying -O3 and -Os
02:40 🔗 SketchCow If you want to
02:41 🔗 bai yeah I think we're using -O3 by default
02:41 🔗 bai might be worth trying -Os too, I guess that optimizes for size
02:42 🔗 SketchCow Well, double check, I guess
02:50 🔗 SketchCow So, I'd say:
02:50 🔗 SketchCow - Move off copies of crashy pacman to a semi-perm URL for eval by the browser teams
02:51 🔗 SketchCow - Build a800 with preppie please
02:52 🔗 bai if you could get me the command we use to build a800 that would be a great help. I couldn't find it with -listsource
02:52 🔗 SketchCow atari400
02:52 🔗 bai I'll put some builds up at a more permanent location tonight
02:53 🔗 SketchCow Maybe a2600 too
02:53 🔗 SketchCow Because these are so glitchy
02:55 🔗 bai building atari400 now, if you could drop me some rom urlz I'll get it up when this finishes
02:57 🔗 bai playing tempest2k with a gamepad while it compiles
02:58 🔗 bai first time I've ever actually been able to tolerate it long enough to get past the first wave
02:58 🔗 SketchCow All BIOS:
02:58 🔗 SketchCow https://archive.org/details/emularity_bios_v1
02:58 🔗 SketchCow https://archive.org/download/Preppie_1982_Adventure_International_US/Preppie_1982_Adventure_International_US_kfile.atr (Preppie)
02:59 🔗 SketchCow https://archive.org/download/atari_2600_pitfall_1983_cce_c-813/atari_2600_pitfall_1983_cce_c-813.bin (A2600)
02:59 🔗 SketchCow If it doesn't let you
03:00 🔗 SketchCow Let me know
03:01 🔗 bai for a800 do I use -cart or mount it as a disk?
03:01 🔗 SketchCow Disk
03:04 🔗 bai ah, -flop1
03:09 🔗 bai http://baicoianu.com/~bai/emularity/a800.html
03:10 🔗 bai dunno if input is working
03:10 🔗 SketchCow Checking.
03:11 🔗 SketchCow It sounds great.
03:11 🔗 bai yeah
03:12 🔗 SketchCow I do hear very very occasional crackle
03:12 🔗 SketchCow VERY occasional
03:12 🔗 bai me too, but they're well below the threshold for insanity
03:13 🔗 SketchCow This is why I choose this program for tests
03:13 🔗 SketchCow The music never stops
03:13 🔗 bai haha
03:13 🔗 SketchCow (F1 starts the game, by the way)
03:13 🔗 bai oh, f1, of course!
03:13 🔗 SketchCow Normally we have a popup with the mappings
03:14 🔗 SketchCow Also, I can't tell if that crackling's built in
03:17 🔗 SketchCow So, definitely building with O3?
03:18 🔗 bai /home/bai/mnt/emsdk_portable/emscripten/incoming/emcc -O3 -s USE_SDL=2 -s USE_SDL_TTF=2 -s BINARYEN=1 -D__unix__=1 -DPOSIX=1 --memory-init-file 0 -s ALLOW_MEMORY_GROWTH=0 -s TOTAL_MEMORY=268435456 -s DISABLE_EXCEPTION_CATCHING=2 -s EXCEPTION_CATCHING_WHITELIST='["__ZN15running_machine17start_all_devicesEv","__ZN12cli_frontend7executeEiPPc"]' -s EXPORTED_FUNCTIONS="['_main', '_malloc', '__Z14js_get_machinev', '__Z9js_get_uiv', '__Z12js_get_soundv', '__ZN15mame_ui_man
03:18 🔗 SketchCow I'd say:
03:18 🔗 SketchCow - Drop that list to alon in an e-mail for opinion
03:18 🔗 SketchCow - build a2600
03:19 🔗 SketchCow - We're done for now unless you want to do more, but other than putting up a perm URL for the developers to determine why we crash them
03:19 🔗 SketchCow I mean, it's obvious we're a bear
03:19 🔗 SketchCow I don't want you spending time chasing down waterfalls that then turn out to be 3 bugfix releases away from certain death
03:20 🔗 bai yeah, sounds like it's not worth spending more time on the pure-wasm builds until we get the knod
03:21 🔗 bai this has been a good exercise for me too, forcing me to learn how to compile and run all these systems I've been putting off learning
03:22 🔗 bai next target, dosbox!
03:23 🔗 SketchCow I'm trying to think if there's anything else that needs your attention more
03:23 🔗 SketchCow Well, I guess prettying these loads would be nice.
03:24 🔗 SketchCow Set them to black backgrounds, make the resolution correct
03:25 🔗 SketchCow Example: Pacman is 224x288
03:25 🔗 SketchCow Traditionally, we set that to Twice 288 (576)
03:27 🔗 SketchCow Atari 800 is 336x225, but I'd double it to 672*450
03:27 🔗 SketchCow Sonic should be driver "genesis", and resolution 512x448
03:28 🔗 SketchCow And jaguar is 360x240, doubled to 720x480
03:35 🔗 SketchCow DFJustin: Does Dreamcast work at all
03:37 🔗 SketchCow Archiving libbgfx.a...
03:37 🔗 SketchCow make: *** [asmjs] Error 2
03:45 🔗 bai sonic is using genesis now. I'll fix the resolutions
03:54 🔗 db48x noo
03:55 🔗 db48x I got it all figured out, and now browserfs is throwing some exception
03:59 🔗 bai derf
04:17 🔗 SketchCow So, pacman is HUGE now
04:18 🔗 bai did I over-double it?
04:18 🔗 SketchCow Well, maybe some other screen thing
04:18 🔗 SketchCow Again, don't overthink
04:18 🔗 SketchCow Just wanted it decent for us showing people / the devs
04:19 🔗 bai JSMAMELoader.nativeResolution(448, 576),
04:19 🔗 bai oh, it changes when I go fullscreen or resize
04:20 🔗 bai I bet this is related to the percent-based sizing in the example code I copied
04:20 🔗 db48x yea, you quadrupled it
04:20 🔗 db48x set the native resolution to the actual native resolution, since you use setScale(2)
04:22 🔗 bai oh dur, yeah didn't notice the setScale. I just copied one of the examples
04:23 🔗 db48x :)
04:25 🔗 db48x for some reason my source map for BrowserFS isn't working
04:26 🔗 db48x I had it all set up at some point
04:27 🔗 bai hmm, wonder if the source map and the js file are out of sync
04:46 🔗 db48x it couldn't find the files referred to by the source map
04:47 🔗 db48x hrm
04:47 🔗 db48x TypeError: Cannot read property 'isDir' of undefined at BFSEmscriptenFS.createNode
05:05 🔗 db48x it's trying to do this.FS.isDir, but this.FS is undefined
05:05 🔗 db48x no idea what's going on there
05:06 🔗 bai that's with modularize?
05:13 🔗 DFJustin I don't think dreamcast does much besides the bios menus
05:16 🔗 DFJustin hmm I have got some screenshots of it running chu chu rocket
05:38 🔗 bai tried an em-dosbox build. weird errors
05:38 🔗 bai warning: Output contains some very large functions (7327 lines in sh), consider building source files with -Os or -Oz, and/or trying OUTLINING_LIMIT to break them up (see settings.js; note that the parameter there affects AST nodes, while we measure lines here, so the two may not match up)
05:38 🔗 bai bad subtract types ["assign", true, ["sub", ["name", "h"], ["binary", ">>", ["binary", "+", ["name", "j"], ["binary", "<<", ["name", "m"], ["num", 3]]], ["num", 3]]], ["call", ["name", "Y"], [["unary-prefix", "+", ["sub", ["name", "h"], ["binary", ">>", ["binary", "+", ["name", "j"], ["binary", "<<", ["name", "n"], ["num", 3]]], ["num", 3]]]]]]]
05:43 🔗 yipdw sexpy
05:55 🔗 SketchCow Well, productive day.
05:58 🔗 SketchCow Glad we stopped you waiting more time, bai
06:00 🔗 bai eh, wouldn't call it a waste, now I know how to build a version of llvm with wasm32 and wasm64 output targets
06:00 🔗 bai so I can probably give some feedback ad they implement that, there may be some changes needed to other project makefiles
08:09 🔗 yipdw has quit IRC (Remote host closed the connection)
08:10 🔗 yipdw has joined #jsmess
10:33 🔗 SketchCow ha ha
10:33 🔗 SketchCow So many people discovering this whole project today because of the dumb tweet
15:21 🔗 db48x hah, jvilk saves the day
17:41 🔗 SketchCow ?
17:45 🔗 db48x I sent him an email last night asking about the error I was getting from BrowserFS, and he pointed out that I was doing something dumb
17:46 🔗 bai hah, he's good at that
17:46 🔗 bai which dumb thing was it?
17:46 🔗 db48x bai: when you construct an EmscriptenFS, it looks for the global FS, PATH, and ERRORNO_CODES
17:47 🔗 db48x since I modularized the emulator, they're not globals any more and I have to pass them in specifically
17:47 🔗 bai ah right, yeah
17:47 🔗 db48x var BFS = new BrowserFS.EmscriptenFS(this._module.FS, this._module.PATH, this._module.ERRNO_CODES);
18:02 🔗 SketchCow What are you working on, db48x
18:03 🔗 db48x supporting a modularized emscripten build
18:03 🔗 db48x unfortunately it requires some tweaks to the code generated by emscripten, which means it may not be feasible
18:07 🔗 SketchCow I've been thinking a lot about double-loading.
18:07 🔗 db48x loading multiple disks?
18:07 🔗 bai yeah, I think I had an experimental modification to emscripten which let you specify which symbols to export, so you could make module.FS, module.ENV, module.PATH, and module.ERRORNO_CODES accessible member variables rather than being internal scope
18:08 🔗 SketchCow So, a short-term fix for the non-booting apple disks
18:08 🔗 db48x loading two disk images, one into flop1 and the other into flop2 is easy
18:10 🔗 db48x bai: I just did this:
18:10 🔗 db48x sed -e '/Module\["FS_unlink"\] = FS.unlink;/a Module["FS"]=FS;Module["PATH"]=PATH;Module["ERRNO_CODES"]=ERRNO_CODES;' <"mame${system}.js" >"mame${system}.module.js"
18:11 🔗 db48x bbiab, lunching
18:13 🔗 bai db48x: yeah, that's pretty much exactly what I did too, but I was trying to think of a way that could work generally and be applied upstream, so my solution was that there was a parameter you could pass in, like exportVars: ['FS', 'PATH', 'ERRNO_CODES'], and then the compiled code would basically do, if (exportVars) { exportVars.forEach(v => Module[v] = ...); }
18:13 🔗 bai where ... is me forgetting how I did that variable expansion
19:55 🔗 SketchCow Do we think we could define flop1 and flop2's contents as is, like in a json?
19:56 🔗 SketchCow I'd like to load one image in and then the current item's image in the second floppy.
19:56 🔗 SketchCow This would.... solve a lot.
20:10 🔗 DFJustin you could kludge it with the extra parameters thing
20:15 🔗 SketchCow {
20:15 🔗 SketchCow "name": "Apple IIe Enhanced",
20:15 🔗 SketchCow "js_filename": "mameapple2e.js.gz",
20:15 🔗 SketchCow "bios_filenames": ["apple2e.zip"],
20:15 🔗 SketchCow "peripherals": ["flop1"],
20:15 🔗 SketchCow "native_resolution": [560,384],
20:15 🔗 SketchCow "extra_args": ["-sl1","memexp","-sl6","diskii","-sl4","\"\""],
20:15 🔗 SketchCow "driver": "apple2ee"
20:15 🔗 SketchCow }
20:15 🔗 SketchCow Oh, I see. Set peripheral to flop2, extra args to the image
20:15 🔗 SketchCow Can we do this without putting the same boot disk in each item?
20:57 🔗 db48x no, because then emularity won't know to download the extra file
20:57 🔗 SketchCow OK
20:58 🔗 SketchCow So boot disk in each it is. :)
23:05 🔗 Swizzle has joined #jsmess
23:27 🔗 Swizzle has quit IRC (Read error: Operation timed out)
irclogger-viewer