.

.

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

frg_Away: cdn.discordapp.com/attachments/1091…21833/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

and i have arch specific environment again and easy redist by a couple variables

your work in that area has been key to understanding the not-as-well-done-as-I-did work they did

so once again thank you

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

Oh wait there was a comm patch I probably didn't apply.

did Mozilla change imagedocument?

frg_Away: yes

yeah and you need to finish patching for it lol

i guess

eh?

CaptainTobin Just testing something. Forgot a backport.

pebkac

CaptainTobin testing python 2 removal right now and forget to change my comm patch queue.

ah

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

CaptinTobin using the x86 compiler will likely end with a link failure even if not using rust parts.

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

frg_Away: it works perfectly

but it will not STAY working perfectly

and I am well aware of that

i been aware of that for five years

x86 needs to die

period

except in pure environments and pure x86 environemnents today are by nature special case

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

and also x86 doesn't help my cause overall

so...

yeah

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

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

kinda like subdir comm except i will provide a lot of the overarching command and control from my directory more like classic-comm

Hi, how can I talk/write to IanN privately?

You usually open a private chat room. In cZ you doubleclick on the name you want to talk with.

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

REM Prefer cross-compiling 32-bit builds using the 64-bit toolchain if able to do so.

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

CaptainTobin I now need about 5GB to link but that is with the rust crap.

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

frg_Away: MCP split mozjs back out after 6 years

Set my build VMs to 16GB memory. 8GB is borderline now.

they seem or at least job seems bent on killing libevil that is a Tobin directive.

make no mistake

i can sqeek by with 6gbs of ram on linux

i need 8 on windows

i feel so bad for you having to deal with all the pervasive corrosion

rust needs to be stopped

but frg_Away this was the point

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

chrome has been this from the moment it got pushed as Google's real entry into the browser market

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

then it switched

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

Google created the perfect situation where anything is technically possible but achiving it is practically impossible almost all the time

or if you slip by you become .. me.. or even worse.. them

their way is the right way, the only way, and you don't matter.

That is what the webapp agenda, google and co have done to all of us and I remain not pleased.

frg_Away: Many thanks.

always the thanks to the frgs and ians no matter how away they are

Rahul_ happy to help

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

god that would have been embarrasing

shit

there are too many ducks tho .. where is my nes zapper

the row is difficult

shoot ducks!

It's rabbit season!

DUCK SEASON

of course everyone knows it's really Tobin season.

the real question is is this a comparison I want on public record lol

Using the MSVC 2022 64-bit cross-compile toolchain.

That would be duck season; tobin season; tobin season -> bang then.

"Your Browser Is No Longer Supported"

I declare it Webshit Season, dudes

> static.parastorage.com/services/wix…derbolt/dist/deprecation-en.v5.html

oh, so apparently Wix websites require Google, cool, cool.

ah, it's React

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

but i am also setting up my ancient msys environment for redist because it is needed for other BinOC things..

the environment and tools

just updated to the latest build

and as warned, Redirector broke, AGAIN :D

> for each (var re in this._list) {

oh, it's that syntax again

is it matter of killing the "each", right?

(why am I feeling deja vu there...)

lia.disi.unibo.it/materiale/JS/deve…eference/Statements/for_each...html although Mozilla has been suggesting to replace it with "for ... of")

Is there some trick to make Lemmy instances show correctly in SM?

yep, changing a few for each(...) into for...or loops helps Redirect to live another day

...and my sessionStore.json went to hell again :/

tomman when was redirector last updated? Has been taken out of Nightly even before 56.

Plenty of examples in the depends bugs: Bug 1083470

usually for of should work

frg_Away: I'm using 2.9.3, the last version compatible with XUL browsers

(I'm aware there are later versions, but none of them are compatible with our browsers)

Ended turning all offending for each loops into for..or, so far everything works again

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.

This is an awful syntax and at least I won't miss it.

it was one rare case of Mozilla-isms, right?

I'm just used to the "for (var foo in foos)" variety

I didn't even knew the for..of variant

tomman they do different things depending on the variables. I forgot already. Too much porting and not enough using the stuff.

> 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.

I... don't really get it :D

all I knew as a naive code monkey is "I have list of foos, I wanna loop through each foo"

oh, the example on that segment tells the difference... and why I will never like JavaScript

who would even want to loop through all that noise on a stupid array?!

GAAAH!

tomman the example is crap. It has its uses