13:37:43 <CaptainTobin> .
13:37:50 <CaptainTobin[m]> .
13:39:49 <CaptainTobin> i'd have more faith in matrix if i didn't send 10 lines last night and cclog doesn't even show I said it
13:54:54 <CaptainTobin> frg_Away: https://cdn.discordapp.com/attachments/1091572226748321833/1114913245489283152/image.png NOW I have vs and vs buildtools capability from the build system alone and the older method by assimilation and further refinement of franklindm's modified scripts from before they changed stuff
13:55:22 <CaptainTobin> and i have arch specific environment again and easy redist by a couple variables
13:56:08 <CaptainTobin> your work in that area has been key to understanding the not-as-well-done-as-I-did work they did
13:56:26 <CaptainTobin> so once again thank you
13:56:41 <frg_Away> IanN_Away seems to be related to the reosurce stuff: Error: $SRCDIR/comm/suite/installer/package-manifest.in:671: Missing file(s): bin/res/ImageDocument.css
13:57:08 <frg_Away> Oh wait there was a comm patch I probably didn't apply.
13:57:11 <CaptainTobin> did Mozilla change imagedocument?
13:57:22 <IanN_Away> frg_Away: yes
13:57:24 <CaptainTobin> yeah and you need to finish patching for it lol
13:57:26 <CaptainTobin> i guess
13:57:27 <CaptainTobin> eh?
13:57:44 <frg_Away> CaptainTobin Just testing something. Forgot a backport.
13:57:55 <frg_Away> pebkac
13:58:50 <frg_Away> CaptainTobin testing python 2 removal right now and forget to change my comm patch queue.
13:58:59 <CaptainTobin> ah
14:00:15 <CaptainTobin> i will look into python 3/4 porting of mozbuild and other build system crap after I have reduced mozconfigure to basic autoconf LIKE proceedural configure routines and strip mozbuild and the tree of old and insecure mozinfra support shit like taskcluster for the upteeth time now for me personally
14:01:08 <frg_Away> CaptinTobin using the x86 compiler will likely end with a link failure even if not using rust parts.
14:01:56 <CaptainTobin> i got mozconfigure to dump its final vars WITHOUT autohell being invoked which means I saw all mozconfigure set and you know what at esr52-base level it is very little at the pre-gre uxp level it is even less.. I can kill mozconfigure just a few levels above trivial i just need the time and energy to accomplish it
14:02:36 <CaptainTobin> frg_Away: it works perfectly
14:02:42 <CaptainTobin> but it will not STAY working perfectly
14:02:46 <CaptainTobin> and I am well aware of that
14:02:51 <CaptainTobin> i been aware of that for five years
14:02:54 <CaptainTobin> x86 needs to die
14:02:57 <CaptainTobin> period
14:03:17 <CaptainTobin> except in pure environments and pure x86 environemnents today are by nature special case
14:03:45 <CaptainTobin> and I am one person with a few people that still talk to them I don't have the resources to deal with every special case even if I wanted to right now
14:03:58 <CaptainTobin> and also x86 doesn't help my cause overall
14:04:01 <CaptainTobin> so...
14:04:02 <CaptainTobin> yeah
14:04:54 <CaptainTobin> if the moonies want to keep 32bit going fine with me as long as it doesn't interfear with my plans but I can't dump resources into aging architecutures no one else supports .. aside from classical mozilla its self lol
14:08:16 <CaptainTobin> but apps aside build system is my focus cause what I plan requires control and understanding of it and mozconfigure and mcp control of said build system is a hinderance so i will bypass and send the stuff into my directory early so I can control the build from a point of non-clobbitude
14:08:53 <CaptainTobin> kinda like subdir comm except i will provide a lot of the overarching command and control from my directory more like classic-comm
14:13:10 <Rahul_> Hi, how can I talk/write to IanN privately?
14:14:32 <frg_Away> You usually open a private chat room. In cZ you doubleclick on the name you want to talk with.
14:24:01 <CaptainTobin> basically regarding selecting the vs shit the old way with vs2022 it works as it did in 2015 on win64 for 32bit builds it will do vcvarsamd64_x86.bat
14:24:02 <CaptainTobin> REM Prefer cross-compiling 32-bit builds using the 64-bit toolchain if able to do so.
14:25:05 <CaptainTobin> now i dunno IF one can even compile using the str8 32bit toolchain especially in this configuration and pure win32 doesn't have enough ram or visual studio anymore i think
14:25:35 <frg_Away> CaptainTobin I now need about 5GB to link but that is with the rust crap.
14:25:46 <CaptainTobin> which is why we removed the distinction between 32bit built with 32bit or 32bit built with 64bit cause we only do it one way and have no idea if the otherway even works and it isn't desirable
14:26:07 <CaptainTobin> frg_Away: MCP split mozjs back out after 6 years
14:26:11 <frg_Away> Set my build VMs to 16GB memory. 8GB is borderline now.
14:26:31 <CaptainTobin> they seem or at least job seems bent on killing libevil that is a Tobin directive.
14:26:34 <CaptainTobin> make no mistake
14:26:52 <CaptainTobin> i can sqeek by with 6gbs of ram on linux
14:26:57 <CaptainTobin> i need 8 on windows
14:27:17 <CaptainTobin> i feel so bad for you having to deal with all the pervasive corrosion
14:27:21 <CaptainTobin> rust needs to be stopped
14:27:52 <CaptainTobin> but frg_Away this was the point
14:29:03 <CaptainTobin> or if it wasn't they sure managed it effectively .. taking browser codebases out of our hands by making it impossible to build on common hardware is another key
14:29:59 <CaptainTobin> chrome has been this from the moment it got pushed as Google's real entry into the browser market
14:30:48 <CaptainTobin> before that compiling chrome requirements wise wasn't much more than mozilla the hard part was that the environment setup was beyond most people's reach
14:30:52 <CaptainTobin> then it switched
14:31:26 <CaptainTobin> everyone became capabile of building yet the code has bloated up and been so horribly coopted it keeps it out of the hands of most
14:31:55 <CaptainTobin> Google created the perfect situation where anything is technically possible but achiving it is practically impossible almost all the time
14:32:17 <CaptainTobin> or if you slip by you become .. me.. or even worse.. them
14:32:51 <CaptainTobin> their way is the right way, the only way, and you don't matter.
14:33:13 <CaptainTobin> That is what the webapp agenda, google and co have done to all of us and I remain not pleased.
14:33:52 <Rahul_> frg_Away: Many thanks.
14:34:13 <CaptainTobin> always the thanks to the frgs and ians no matter how away they are
14:36:46 <frg_Away> Rahul_ happy to help
14:53:07 <CaptainTobin> frg_Away: you helped me as well cause it was nagging at me the 32bit compiler and I guess franklinkdm didn't retain an important piece of logic the logic that checks if the host is 64bit so even tho it likely works if i had released win32 without that logic i WOULD have been compiling with the 32bit 32bit compiler not the 64bit compiler to 32bit as intended. THANK YOU
14:53:16 <CaptainTobin> god that would have been embarrasing
14:53:18 <CaptainTobin> shit
14:54:09 <CaptainTobin> there are too many ducks tho .. where is my nes zapper
14:54:15 <CaptainTobin> the row is difficult
14:54:19 <CaptainTobin> shoot ducks!
14:58:24 <frg_Away> It's rabbit season!
14:59:38 <CaptainTobin> DUCK SEASON
15:00:00 <CaptainTobin> of course everyone knows it's really Tobin season.
15:00:38 <CaptainTobin> the real question is is this a comparison I want on public record lol
15:02:50 <CaptainTobin> Using the MSVC 2022 64-bit cross-compile toolchain.
15:11:07 <frg_Away> That would be duck season; tobin season; tobin season -> bang then.
15:11:46 * frg_Away unless you are a looney toons fans best to not trying to make sense of this.
15:11:47 <tomman> https://www.clockworkpi.com/uconsole
15:11:49 <tomman> "Your Browser Is No Longer Supported"
15:11:55 <tomman> I declare it Webshit Season, dudes
15:12:39 <tomman> > https://static.parastorage.com/services/wix-thunderbolt/dist/deprecation-en.v5.html
15:12:52 <tomman> oh, so apparently Wix websites require Google, cool, cool.
15:13:49 <tomman> ah, it's React
15:15:08 <CaptainTobin> actually frg_Away i think it wouldn't have mattered cause the build system is overriding most vars by rediscovering them its self so it IS using the correct compiler but assumptions may still have bit me in the ass best to verify behavior and i did now everything agrees but not everything matters everywhere it is defined .. will have to follow up but RESOLVED GOODENOUGH
15:17:00 <CaptainTobin> but i am also setting up my ancient msys environment for redist because it is needed for other BinOC things..
15:17:12 <CaptainTobin> the environment and tools
20:53:57 <tomman> just updated to the latest build
20:54:10 <tomman> and as warned, Redirector broke, AGAIN :D
20:54:16 <tomman> > for each (var re in this._list) {
20:54:21 <tomman> oh, it's that syntax again
20:56:08 <tomman> is it matter of killing the "each", right?
20:56:16 <tomman> (why am I feeling deja vu there...)
20:57:50 <tomman> https://lia.disi.unibo.it/materiale/JS/developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for_each...html although Mozilla has been suggesting to replace it with "for ... of")
20:59:54 <tomman> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of#difference_between_for...of_and_for...in
21:06:59 <mahdi[m]> Is there some trick to make Lemmy instances show correctly in SM?
21:14:29 <tomman> yep, changing a few for each(...) into for...or loops helps Redirect to live another day
21:14:38 <tomman> ...and my sessionStore.json went to hell again :/
23:01:02 <frg_Away> tomman when was redirector last updated? Has been taken out of Nightly even before 56.
23:02:18 <frg_Away> Plenty of examples in the depends bugs: Bug 1083470
23:03:42 <frg_Away> usually for of should work
23:27:42 <tomman> frg_Away: I'm using 2.9.3, the last version compatible with XUL browsers
23:27:59 <tomman> (I'm aware there are later versions, but none of them are compatible with our browsers)
23:28:40 <tomman> Ended turning all offending for each loops into for..or, so far everything works again
23:30:42 <frg_Away> tomman this was deprecated long ago so a bit of a bummer that the extension wasn't updated. Removal of expressions closures Bug 1083458 is the last thing I want/need to do additionally and then hopefully it quiets down.
23:31:51 <frg_Away> This is an awful syntax and at least I won't miss it.
23:32:06 <tomman> it was one rare case of Mozilla-isms, right?
23:32:30 <tomman> I'm just used to the "for (var foo in foos)" variety
23:32:42 <tomman> I didn't even knew the for..of variant
23:33:47 <frg_Away> tomman they do different things depending on the variables. I forgot already. Too much porting and not enough using the stuff.
23:34:34 <tomman> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of#difference_between_for...of_and_for...in
23:34:47 <tomman> > The for...in statement iterates over the enumerable string properties of an object, while the for...of statement iterates over values that the iterable object defines to be iterated over.
23:34:53 <tomman> I... don't really get it :D
23:35:20 <tomman> all I knew as a naive code monkey is "I have list of foos, I wanna loop through each foo"
23:36:38 <tomman> oh, the example on that segment tells the difference... and why I will never like JavaScript
23:36:57 <tomman> who would even want to loop through all that noise on a stupid array?!
23:37:05 <tomman> GAAAH!
23:38:05 <frg_Away> tomman the example is crap. It has its uses
23:40:57 <frg_Away> https://www.w3schools.com/js/js_loop_forin.asp