[01:29] *** john__ has joined #jsmess [01:29] *** john__ is now known as JohnTalen [01:30] The last of the errors: [vice in emscripten] https://pastebin.com/WAd8YN7L [01:31] JohnTalen: sweet [01:31] The status hasn't changed since aug9th. I've just been really sick since then. [01:32] that sucks [01:32] yeah. I've been trying Yoga and Meditation combined with essential oils. It helps. Things are definitely changing. been better lately. [01:33] I have found you can't do meditation without Yoga or you will get very nervous. suprisingly! too much Ying energy. [01:34] hmm [01:40] It's nice to have emscripten spit out more than one error at a time though! [01:40] :) [02:09] I've noticed this particular job. Nothing is as ever as it appears. [02:09] not the first, second or 15th time around. [02:29] or the 100th. [02:34] okay, so an hour later and I can't get rid of unresolved symbol. SDL_WaitEvent. I'm #include "SDL.h" and if I uncomment SDL_WaitEvent the error goes away so I THINK I know my target. I'm at a loss. [02:38] on a lighter note I'm generating a x64.js. :) [02:38] -rw-r--r-- 1 john users 4134928 Nov 16 21:35 x64.js [02:41] are you doing -lSDL at link time [02:46] yes [02:46] -lwatt -linet -lnet -lbsd -lsocket -lnsl -lintl -lbsd -lm -lGL -lSDLmain -lSDL [02:46] I'm rereading through the documentation and make files more closely. [02:47] it's getting the SDL lib too. Otherwise I would have gotten 'cannot find library'. [03:02] starting from ground one. [03:04] wow, shoulda kept notes. i have an incompatible ar. [03:05] nevermind. saved a great script file. [03:15] tried it from scratch. same exact errors. [03:18] hm, they are warnings! gonna try it in the browser. [03:22] just think I had it all these months and it was just warnings. [03:22] still doesn't work but I might be missing something. [03:24] anyone else want this? [03:24] I get no errors in the browser. no results either. [03:28] I suppose I'll get github what I have. [03:28] s/get/just [03:30] 2 hours [03:36] what does it mean dearest browser warriors when s are greyed out? [03:44] since a non protected efnet ip is food for wolves I will call it a night. I will try it from windows tomorrow (i've been using linux/firefox) [03:44] *** JohnTalen has quit IRC (Quit: leaving) [04:27] "I'm using DosBox to run Dbase IV - created a new database in there, and it shows up when I restart DosBox - is persistent. However, I have no idea how to locate the .dbf file for import to Excel after closing DosBox. Any ideas how I can pull this out of the virtual machine environment?" [04:30] we'd need to offer up some browserf-based inspector for inspecting the stored files [04:30] browserfs* [04:30] certainly doable [05:03] yea, it's one of the things we planned on doing, if we ever got the time and/or money [05:20] Huzzah [05:43] bai: https://ia801501.us.archive.org/BookReader/BookReaderImages.php?zip=/19/items/20thcenturytimemachineimages/20thcenturytimemachineimages_jp2.zip&file=20thcenturytimemachineimages_jp2/20thcenturytimemachineimages_0063.jp2&scale=4&rotate=0 [05:51] oh cool, didn't see the photographer this year but I must have just been too busy to see him [06:16] Yeah, I was doing a metadata search, and one of the texts in the photo set triggered the OCR match! [09:18] *** bwn has quit IRC (Read error: Operation timed out) [09:25] *** bwn has joined #jsmess [12:45] *** db48x has quit IRC (Read error: Connection reset by peer) [12:45] *** db48x has joined #jsmess [15:48] *** JohnTalen has joined #jsmess [15:50] Okay so vice.js is a mess. I'll put it on github. But I got it to a point where the .js file is created. However it simply does not run and there are no errors. [15:51] However, I'm looking at another c64 emulator WITHOUT 1541 but with prg load support.Then, I may be able to use the 1541 from another emulator transplanted inside it. [15:58] *** SketchCow has quit IRC (Remote host closed the connection) [16:07] JohnTalen: which github repository? [16:19] db48x: I have yet to put it up. the creation scripts are most valuable aspect of this. [16:20] i think I'm going to start fresh. either some odd c64 emulator or the latest version of vice. [16:21] i'm not sure why the demo doesn't run. it like a stall without errors. [16:21] does anyone want my tar.gz? [16:22] one trick is to open the debugger and set it to stop on all exceptions, even if they're caught [16:23] ok [16:23] i'll try. [16:29] well, i have an error loading failed for script file. pretty generic. [16:30] ha. [16:30] because i renamed it to .txt this morning so i can test under windows. smh! [16:31] :) [16:31] Successfully compiled asm.js code (loaded from cache in 363ms) [16:31] The character encoding of the HTML document was not declared. [16:31] uncaught exception: could not load memory initializer x64.js.mem [16:31] That last one i don't get. [16:31] ah [16:32] the compiler should have produced a .mem file [16:32] which it needs to load [16:32] oh okay. i believe i have it. [16:32] it contains all of the static initializers [16:35] still getting the error despite putting the .mem in the same dir as the .js. [16:35] do you see a network request for it? [16:36] network panel has nothing in it if that is what you mean. [16:37] reload the page while the network panel is open [16:38] (by default it doesn't record anything until you look at it, so that it's not always slowing everything down) [16:39] ah here we go. [16:39] I put the html file in the same dir as the hardcoded directory where js/mem is. [16:40] this is something I can chew on. [16:40] missing function: file_system_get_vdrive [16:40] that sounds correct [16:41] does it get a 404 error or something when it requests the mem file? [16:42] no [16:43] odd [16:43] https://pastebin.com/X4ktT26V [16:46] i take it this a a code issue and not a configuration issue? [16:46] that's progress of a sort :) [16:46] yes indeed! [16:46] yes, you can see that it called your compiled main() (the callMain in the stack trace), and then couldn't find any functions named file_system_get_vdrive [16:47] yes. [16:47] great. [16:48] okay. found it commented out with my initials! [16:48] presumably the linker thought that it would be supplied by a library [16:48] aha! [16:49] i expect more of these. [16:51] You see this project has lot's of duplicate functions. [16:51] that's fun [16:51] always! :) [17:08] what sucks is I'll have to redo all this but with the latest version of vice. [17:08] should go by quite a bit quicker though. [17:10] yea, it's almost always that way with a port [17:10] yay, onto the next function. [17:10] they keep working on it while you're porting it! [17:10] i see you guys got windows 95 to work. [17:11] I gave that a shot with an emu I was working on. But it was severly broke. [17:11] :) [17:11] I think he said it was still stuck in 16-bit color mode [17:12] although that's an improvement from what we had the last time [17:13] thats the thing with windows 95, the video drivers specific to that card were always necessary to avoid hang ups. [17:13] so it's a one for one to the emu i'd imagine to this day. [17:14] I have to say vice is the best of most c64 emulators i've seen. luckily this .js shell project exists. [17:15] i grew up on c64. hands down the best gaming maching. [17:15] machine [17:15] c1541.c is a 2 char file lol!! smh! [17:17] hah [17:17] haha! holy shit. [17:17] there was a .kab file. I stopped drinking years ago. I swear! [17:17] did it draw something in the canvas? [17:18] heh [17:18] nope still going through missing functions. [17:42] it's going to be a long day. [17:43] it would be nice is the unresolved symbol would give you at least a module name. at least! [17:43] s/is/if [17:53] attempt to catch it on a full compile [17:57] no such luck. [17:57] now I'll just tighten the search from the link. [18:03] is there a way to get more information than just this: "warning: unresolved symbol: network_connected" [18:03] ? [18:05] it jumps to the debugger. but it doesn't highlight or get anything more specific than the entire js module. smart. [18:06] _network_connected@file:///home/john/emularity/x64.js:1:1521324 [18:06] the browser debugger is useless unless you compile with -g [18:06] thats about as detailed as it gets. [18:06] ah ok! [18:06] good to know. [18:06] thanks DFJustin! [18:08] DFJustin: each module, or just the emcc linkage? [18:09] C doesn't have module names [18:11] JohnTalen: you probably want to add the -g to CFLAGS when you run configure [18:12] so emconfigure ./configure CFLAGS="-g" [18:13] ^ [18:14] i think i have a hacker on my system. [18:14] need to reboot. [18:14] thanks db48x. [18:14] :q [18:14] *** JohnTalen has quit IRC (Quit: leaving) [18:14] o_O [18:48] *** SketchCow has joined #jsmess [18:49] Well, that was refreshing [18:49] Did I miss anything [18:50] SketchCow: some progress on vice [19:37] *** JohnTalen has joined #jsmess [19:37] so the -g helped a bit! [19:37] I get: function _network_connected() { [19:37] Module['printErr']('missing function: network_connected'); abort(-1); [19:38] I suppose I have to trace up to the nearest module. [19:38] ah found it. [19:38] machine_trigger_reset! beaut! [19:39] hm, it appears to have network.h. [19:39] i'll have to look at the makefile. [19:44] makefile appears okay. it contains network.h. [19:45] aparently the order is not preserved in ths js. not suprising. [19:51] the order of definitions generally doesn't matter in js [20:09] As you can see I'm thumping the podium [20:09] for #TedNelsonMail [20:46] missing function is going to be an issue with the link stage, not the includes [20:46] if it wasn't included it wouldn't even compile [21:03] DFJustin: yes, there may be in issue with the Makefiles. i'm still reconfiguring and looking at it. [21:03] DFJustin: I've seem emscripten just emit a warning at link time [21:04] db48x: yes. and more than one of them which is a god send. [21:13] I mean if it wasn't #included it wouldn't compile [21:14] emscripten is very loosey goosey about linking [21:27] DFJustin: ok. thank you. [21:28] there are duplicate functions. some shells, some differences. [21:29] managing them isn't typical terra firma. [21:34] or it is terra firma, but by a glutton for punishment. :D [21:35] it's interesting that emscripten generates shell function in the js when it can't find the function. [22:54] so you see, the emtpy shell functions that emcc generates create a placeholder that prevents errors in the compile. [22:55] at least, that is how I see it. [23:01] I think there is a fault with one of the makefile. I shall see. [23:01] s [23:02] sounds like a tricky problem [23:04] i think , oddly enough $(x64_SOURCES) is missing from the x64 dependencies list. flat out not there. i'll have to do some surgery. [23:05] heh [23:08] it's tricky because I didn't write it. :) [23:27] ah closer. It looks like network_connected include wasn't set so it just spit out shells. [23:46] lmfao. [23:46] enabling thrices the number of unresolved symbols. :/ :D [23:50] finally starting to get cozy with this environment. [23:52] yay! [23:52] getting further. [23:52] time to get down and dirty with my own mf ifdefs. [23:52] word. [23:53] ;p~ [23:59] does anyone know if Module.canvas.exitPointerLock is depcrated?