00:00:42 <nsITobin> frg_Away: I don't have enough time in the day.. i need to cut leg quarters up into legs and thighs cause 1.25 a pound is better than 1.67 a pound when it's 8 cuts total.. also need to bag up this pork steak for cold storage.. but I also want to do php and poke at the suite code
00:05:45 <nsITobin> I am however trying a few combos to see which processor vs core combo gets me the fastest compile time while still leaving enough resources to do text editing chatting music etc ..
00:06:27 <nsITobin> on my VMs
00:06:31 <nsITobin> for efficiency
00:07:20 <nsITobin> that will leave enough time in between to do other tasks as well
00:08:08 <frg_Away> Between 8 and 16GB is the sweet spot. 8 full cores and high clock arre also liked.
00:08:18 <frg_Away> Disable hyperthreading
00:10:56 <nsITobin> I only got 6 cores with 2 threads each
00:11:52 <nsITobin> maybe I too will have an outdated server that outperforms most contemporary machines in raw compuational power like everyone else.. that is if I can stop spending resources on more screens
00:12:06 <nsITobin> MORE SCREENS
00:12:21 <frg_Away> highest count you can do. Hyperthreading might slow it down if the vm scheduler is not smart. vbox isn't. The context switches/saves kill the performance.
00:14:19 <nsITobin> VMWare on average is only SLIGHTLY slower maybe 5-10 min off compiling mozilla code from bare metal but bare metal has direct core access and all of em or at least 10 of em.. on windows.. on Linux vmware running windows.. its better.. kvm would be the fastest with a few tweaks i'd have to dig out of my brain but i wouldn't have half-way decent video acceleration
00:15:10 <nsITobin> vmware on linux is slightly faster than vmware on windows
00:15:18 <nsITobin> when running windows
00:15:24 <frg_Away> I never measured native vs. vbox
00:16:30 <nsITobin> need to setup chroots like I did before that helped on linux.. cause I don't need to run the full os for building
00:17:39 <nsITobin> let's hope the ol battle computer can survive this administration cause the likelyhood of a new machine has plumited
00:18:30 <frg_Away> how long is the actual compile time under Windows inclzuding packaging en-US
00:20:42 <nsITobin> for me it is around 40ish on windows vm the rust cycle is way slower than cpp
00:21:31 <nsITobin> but that may have improved since i switched to EL8 as a host
00:21:39 <nsITobin> less garbge in the way
00:21:48 <nsITobin> vs fedora 39
00:22:14 <nsITobin> This system was specifically built with el8 in mind it is no wonder it is thriving on it
00:22:19 <nsITobin> back in 2018
00:23:10 <frg_Away> Not that bad compared to my 27 or so
00:27:28 <nsITobin> oddly enough linux on a windows vmware host builds half the speed as windows bare metal
00:27:36 <nsITobin> regardless of the era of tree
00:27:40 <nsITobin> uxp sm central
00:28:06 <nsITobin> roughly speaking give or take five minutes
00:28:11 <nsITobin> in my experience as well
00:28:16 <frg_Away> io under Windows s*cks
00:28:38 <nsITobin> vmware musta found some hacks cause IO is more efficient inside a linux vm than the windows host
00:29:37 <frg_Away> Tried refs for sports but gave up after formatting. Blocking was so bad it filled up the disk fast.
00:30:14 <frg_Away> so ntfs it is for now
00:30:45 <nsITobin> be careful switching back and forth between 7 and after 7 regarding ntfs especially windows 10
00:31:07 <nsITobin> microsoft doesn't much care about forwards compat not that they did but they quit messing with it for a long time so it always worked
00:31:29 <frg_Away> no problem in the last 5 years.
00:31:46 <nsITobin> well maybe i should say.. drives formatted with newer windows
00:32:57 <nsITobin> save vista symlinks ntfs compat issues haven't been a thing since the 90s sucks it has cropped up more often in the past decade and microsoft tells no one
00:33:02 <frg_Away> I always cold boot Windows. Hibenation off via powercfg. Still no problem wrt formatting.
00:33:48 <frg_Away> Recycle bin might be reported corrupt if you remove it from a different verison  but that is self repaired
00:38:49 <nsITobin> yeah
00:38:54 <nsITobin> that's always fun
00:47:53 <frg_Away> gitlab wip synced with 2.53 and a nighty night to all
00:48:07 <nsITobin> rest well
13:40:01 <nsITobin> first test was 2 processors 4 cores each this test is 1 processor 8 cores
13:43:28 <nsITobin> also rhetorical political question: Why is trump trying to cut off basic infrastructure building supplies coming in when the ONE GOD DAMN THING HE IS HALF WAY GOOD AT IS BUILDING GOD DAMNED BUILDINGS
13:46:13 <nsITobin> but that's the maximum extent i am gonna allow it to be in my awareness.. got work to do
14:06:07 <frg_Away> nsITobin hi
14:20:08 <tomman> oh Google, please serve me a extra heavy dose of Recaptcha hell today because 1) you hate SeaMonkey, 2) you hate CGNAT, and 3) you hate me,  pretty please~?
14:21:41 <nsITobin> dpaste.org half the time doesn't even GENERATE the captcha
14:21:44 <nsITobin> even on edge
14:21:53 <nsITobin> its going off the rails
14:21:57 <nsITobin> WEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
14:22:18 <nsITobin> frg_Away: good morning
14:24:39 <nsITobin> just dealing with cats and chores aboot to get ready to either do this ftp thing or more likely the not-wiki thing either way its same basic work panel.. settings, sql will be copied to the other
14:26:04 <nsITobin> frg_Away: did you know classes extending other classes need compatible method signatures?
14:26:18 <nsITobin> I did but I just encountered it cause hadn't done it before
14:31:00 <frg_Away> nsITobin despite all the backports I seldom have time to actuall look at the stuff in detail so I stay at average programmer level at best.
14:31:10 <frg_Away> Don't like it.
14:32:01 <nsITobin> then again how close would you be looking if it was just business as useal with m-c chugging along
14:32:08 <nsITobin> .. bustages
14:32:32 <nsITobin> that's how close and not much different now except a time consuming slog instead of reactionary fixes
14:32:53 <nsITobin> its now a slog AND fixes
14:33:09 <nsITobin> either way its impressive if a bit hard to grasp in its entirety
14:33:19 <nsITobin> it's*
14:34:11 <nsITobin> took me a while to get a handle on what exactly you were doing .. now i want mq everywhere
14:34:15 <nsITobin> funny that frg_Away
14:34:15 <frg_Away> I have a good overall knowledge and usually know where to tinker but that is it about.
14:34:54 <frg_Away> yeah mq is a deal breaker when working with patches.
14:35:28 <frg_Away> Saves me / us countless hours. 2.53 would not exist otherwise I think.
14:35:48 <nsITobin> i think half my knowledge is simply osmosis from being in contact with it day in and day out.. still can't code C++ worth a crap but I am edging into xpcom components from again mere exposer
14:36:58 <nsITobin> I kinda imagine the codebase like a city
14:37:04 <nsITobin> it's large enough..
14:37:22 <nsITobin> over there is xpcom.. down town is dom.. etc
14:38:28 <nsITobin> spidermonkey is that highway system that is never finished and constantly changes its design midway through
14:38:48 <nsITobin> with three peers watching some contributor dig a hole
14:39:44 <nsITobin> that is a little .. too apt LOL
14:42:19 <nsITobin> no one goes to xpfe anymore.. barely even any homes still standing.. xpinstall wiped off the map.. yep its a city with suburbs and city like functions and people that work on it
14:42:37 <nsITobin> and live in it
14:46:34 <nsITobin> well seems in terms of cores vs cpus on vmware it doesn't matter not for the purposes of compiling mozilla code.. I already know I can build UXP on Windows 7 with only 12gbs of ram to keep enough practical headroom.. seamonkey and windows 10 do better at 16 gig .. in a vm setting -jN is kinda pointless cause why not use all the vm has..
14:48:24 <nsITobin> Linux on VMWare which again only really makes sense on windows host.. only requires 6gbs with MATE as a de to compile uxp.. again seamonkey needs 8gbs.. modern mozilla would like all of it of course.
14:49:45 <nsITobin> 12 might be better if rustc is having a bad day
14:49:54 <nsITobin> ... that's my basic analysis
14:55:24 <frg_Away> Under Windows the linker seems to like the most ram for libxul
16:26:30 <nsITobin> sorry had to go to the store again i needed more soda
16:27:50 <nsITobin> I am just gonna barely squeak by..
16:38:36 <frg_Away> pop makes the soda
16:39:20 <nsITobin> i mean resource wise that is why I was able to go get a couple of 2lts and I need the soda to turn into code
16:44:20 <frg_Away> I usually use coffee for this
16:44:48 <nsITobin> well i would too but i need it to be half cream and sugar ..
16:44:51 <nsITobin> LOL
16:45:05 <nsITobin> just give me a splash of coffee with my cream of sugar please
16:45:41 <nsITobin> i can only assume its my brain at fault..
16:45:51 <nsITobin> i mean really isn't everything
16:46:08 <nsITobin> but yeah i need raw brain fuel
16:46:28 <nsITobin> or a drug that poorly simulates it like caffine
16:47:19 <nsITobin> preferably both
16:48:03 <nsITobin> there is ZERO nutritional value in the artificially sweetened acid water i been drinking last several years
17:40:42 <nsITobin> frg_Away: any build system changes recently that I might run into?
17:42:09 <frg_Away> nsITobin nothing in 2.53
18:20:07 <nsITobin> frg_Away: seamonkey builds 2 minutes slower on windows 10 than uxp does on windows 7
18:20:30 <nsITobin> ~35 minutes
18:30:22 <frg_Away> Was longer here. Maybe Defender related.
18:53:49 <frg_Away> nsITobin did you remove all vctip.exe?
18:54:10 <nsITobin> defender doesn't exist in my windows installs
18:54:45 <nsITobin> hmm vctip
18:54:54 <nsITobin> oh that thing
18:55:01 <nsITobin> hmm can you disable it?
18:57:43 <nsITobin> I still maintain windows 7 is the best linux desktop environment I have tried yet
18:57:51 <frg_Away> don't think so. Phone home stuff. I just deleted all of them. Pop up now and then again after an update. Also if you don't use the ide kill everything in ServiceHub and under team tools there is a also a phone home dir.
18:58:27 <nsITobin> frg_Away: need to see if your current code can pick up buildtools automatically rather than a fully installed visual studio..
18:58:43 <nsITobin> i figure it should the fix i used to do it came from mozilla
18:59:27 <nsITobin> i mean unless you run the debugger you don't need the whole ide.. and my debugging skills are almost non-existant..
18:59:30 <frg_Away> yes wanted to check but so far no time. Have the offline install here. Also the VS2019 compiler in 2022 until 2022 is fixed.
18:59:50 <frg_Away> Did the same with 2.49 and VS2019.
19:00:00 <nsITobin> I did figure out how to tell the installer for 2022 to install 17.6 LTSC on winders 7
19:00:09 <nsITobin> must be a similar command for the 2019 installer
19:00:47 <frg_Away> did it with a with directive in 2.49
19:09:18 <nsITobin> and I have misplaced the installer
20:50:10 <IanN_Away> building on Windows sounds very complicated compared to building on Linux
20:50:58 <nsITobin> well mozbuild vs and dx days are partly over due to build system .. uhh upgrades we will call them
20:53:31 <nsITobin> the basic proceedure as long as artifiacts are available are to get 115, bootstrap it.. then get sm sources vs2019 and boot.. though all that is REALLY needed on winders is nasm and a few others at the CURRENT state of development.. I need to see if they can be made to fall back to mozillabuild paths cause if I can just produce a custom mozillabuild with updated deps then that makes it a lot easier on windows more akin to what everyone is used to.
20:54:48 <nsITobin> theoretically build deps for seamonkey on linux should be in every package manager but that does make it more .. well configure dep hunt than grab and build and maybe that's okay..
20:55:45 <nsITobin> rust cbindgen nasm and something else.. also on linux.. mac cross compile artifacts last i checked
20:55:57 <nsITobin> minimum in a MOZBUILD_STATE_DIR
20:56:01 <nsITobin> for seamonkey 253
20:59:35 <nsITobin> well ok rust would be where rust lives not in the statedir
21:01:08 <nsITobin> clang cbindgen nasm and node for some reason.. node isn't used in seamonkey compilation .. not yet anyway
21:01:19 <nsITobin> http://xr.thereisonlyxul.org/seamonkey-2.53/search?string=mozbuild_state_dir&find=&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=seamonkey-2.53
21:01:30 <nsITobin> ... where is the logo
21:05:13 <nsITobin> fixed
21:18:41 <IanN_Away> yay, logo is back :)
21:24:35 <frg_Away> nsITobin done
21:24:45 <frg_Away> see private room
22:34:39 <nsITobin> oh no
22:34:42 <nsITobin> OOOOH NO
22:34:44 <nsITobin> loadAsHtml5
22:34:52 <nsITobin> its a single flag
22:35:00 <nsITobin> it is*
22:35:25 <nsITobin> ima pref it see what happens .. FOR FUN
22:45:14 <grey_gandalf> hi all
22:45:25 <nsITobin> hello grey_gandalf
22:45:30 <frg_Away> hi
22:45:47 <grey_gandalf> anyone here expert in building from sources? I just tried and failed...
22:45:56 <grey_gandalf> but used to be able...
22:46:15 <grey_gandalf> wrote a mail, but I know the list is not very active... so maybe here
22:46:48 <grey_gandalf> definitely something changed, since "mach build" doesn't work for me. What's this new of "mach bootrap" ?
22:48:43 <nsITobin> when was the last time you successfully built?
23:09:02 <frg_Away> what platform compiler?
23:13:47 <grey_gandalf> last time was 2.53.18...
23:13:50 <grey_gandalf> FreeBSD
23:14:00 <grey_gandalf> but I think my issue is mach / python
23:15:32 <grey_gandalf> I usually just have a .mozconfig in the root and then do a "mach build"
23:18:38 <frg_Away> Maybe check Bug 1939376
23:19:29 <grey_gandalf> I have python 3.11
23:19:45 <grey_gandalf> "mach build" says to run "mach bootstrap" which I du but fails
23:22:10 <frg_Away> mach boostrap fails. Try mach create-mach-environment or use set MACH_USE_SYSTEM_PYTHON=1 before invoking mach.
23:22:54 <nsITobin> use 3.9 if you can get it.. seems to be smoother for me anyway
23:23:19 <frg_Away> 3.11 should work
23:23:51 <grey_gandalf> oh, I was setting MACH_USE_SYSTEM_PYTHON wrong. I have to setenv it before running mach
23:24:01 <grey_gandalf> let me try 3.11, although I still have 3.9 apparently
23:24:17 <frg_Away> yes before
23:24:34 <frg_Away> I use setenv for it
23:25:09 <grey_gandalf> I tried on the command line or inside .mozconfig....
23:25:35 <grey_gandalf> yay, confiure went on! retucilating splines (why that absurd status?)
23:25:43 <grey_gandalf> now the hard work begins
23:25:57 <nsITobin> remind me to make a patch to expand that to multiple random phrases
23:26:02 <nsITobin> grey_gandalf: The Sims is why
23:26:06 <nsITobin> for that
23:26:31 <frg_Away> We will probably never get mach bootstrap to work but for now we left it in and update it.
23:26:52 <nsITobin> SO yes I can basically kill html leaving xhtml perfectly fine.. with this terrible hack.. BUT it busts about:blank cause about:blank isn't valid xml
23:27:24 <nsITobin> grey_gandalf: alt solutions should come and if not the mozbuild situation shall improve.. one of those WILL happen
23:28:32 <nsITobin> frg_Away: if we are not using node for anything we should really patch out the dependancy until we need it
23:29:30 <frg_Away> nsITobin it is for linting. I leave it in but see that it is not needed for normal building.
23:31:40 <nsITobin> don't forget to clean the trap when you are done..
23:31:52 <grey_gandalf> nsITobin: thanks.. didn't play sims or such, so didn't know the jargon. I was left at the original SimCity on i386
23:32:31 <nsITobin> it triggers some people
23:32:34 <nsITobin> like legit
23:32:38 <nsITobin> that phrase
23:32:47 <grey_gandalf> mach created its configuration directory, must be a new thing... was not used before and is not needed in ArcticFox
23:33:13 <nsITobin> grey_gandalf: why do you think something tycho based would be a comparison to seamonkey lol
23:33:33 <nsITobin> we are talking about a difference of like 18 versions before the patch queue
23:34:20 <grey_gandalf> not much tycho based anymore...lilek 10 releases difference in ArcticFox nowadays
23:34:38 <nsITobin> ArcticFox is a Pale Moon 27 fork that started their own backport from mozilla march but they don't mess with the build system much
23:34:43 <frg_Away> can't say I like this but came with the backports. We try to get at least to full 102.
23:34:59 <grey_gandalf> but also, 2.53.18 didn't need it either, maybe 2.53.19 either.. don't remember, I think I was able to start building and broke inbetween
23:35:26 <nsITobin> grey_gandalf: consider this.. ArcticFox would not exist if not for me.
23:35:28 <nsITobin> ;)
23:35:31 <nsITobin> you're welcome
23:35:48 <nsITobin> there would be no tycho and Pale Moon 27 to fork
23:36:18 <nsITobin> not much different than cyberfox 38 anyway
23:37:16 <nsITobin> grey_gandalf: there were build system upheavials during 19
23:37:25 <nsITobin> seems largely settled now
23:37:40 <nsITobin> so once you get it back down it should be fine for you
23:37:57 <frg> Ah the memories from better times: https://ibb.co/n8t9TFY
23:38:16 <nsITobin> nice screenshot
23:38:30 <frg_Away> in a vbox
23:42:30 <nsITobin> so yeah the html5 parser is a god damned hack always was and still is even in mozilla-central.. i mean it being java codegened was a clue but yeah i just looked how it is hooked up .. it's trash
23:45:22 <grey_gandalf> true, matt forked PM 27... but my work is to continually axe things in everything which is core and build system. So really, it is more some sort of Firefox with PaleMoon inside than the otherway
23:45:34 <nsITobin> grey_gandalf: ahem.. please
23:46:10 <nsITobin> BUT
23:46:27 <grey_gandalf> I went down to compare very single file in the source and build tree, so I know the differences
23:46:56 <grey_gandalf> frg: yes, on OS/2! :) :)
23:47:26 <nsITobin> I am glad it continues to be useful.. Tycho was cut down by the very forces that push webstandards today.. Tycho could have been every bit the platform UXP became.. but that and conflict really cut Tycho short.. I put a lot of work into it for Pale Moon
23:48:54 <nsITobin> same sorts of conflict that tainted uxp and all that.. so glad something of that whole decade survives and has found its own path
23:49:03 <nsITobin> without all that trash implcitly attached
23:50:34 <grey_gandalf> if Tycho is like Gecko, the "core", then essentially litlte is left, but some stuff is still there. It improved *a lot*
23:51:23 <grey_gandalf> what I dislike that I bastardized the appearance a bit. UXP essentially.. I loved the old PM27 look and I kept it, but only partially. Somebody helping there would be so cool
23:51:32 <grey_gandalf> although I just always liked SeaMonkey
23:52:15 <grey_gandalf> Aurora was bearable, Quantum Terrible... and current Firefox seems made by rabid monkeys
23:54:25 <nsITobin> seamonkey isn't something you can force into a bunch of alien boxes .. you can't force its evolution you can't half-ass your way through it.. the suite is simply not that forgiving unlike later mozilla code .. project association code its self.. and believe me I have tried ;)
23:56:34 <grey_gandalf> But.. for me I don't like seamonkey to "change". It is interface is almost "perfect" except some missing details
23:56:51 <grey_gandalf> but well, the gecko inside needs update... HTML and JS
23:57:22 <nsITobin> grey_gandalf: you haven't git no mans land have you in your backports where rust and codegen start taking a primary role?
23:57:27 <nsITobin> hit*
23:58:25 <grey_gandalf> codegen is my nightmare in ArcticFox, I had to update it... backporting stuff untill... it worked again
23:58:32 <grey_gandalf> rust, please, stay way
23:59:05 <grey_gandalf> one of the workst decisions by mozilla... it sandboxed itself and gave way more space to chrome and derivatives
23:59:21 <nsITobin> it brings me a sense of unexpected joy that you are succeeding at your project based on stuff I did once.. Thank you.