0309|21:06:46 <+tomman> "moar Javascript solves everything" -- a Googler <--- "I had a problem and I thought of using javascript, now I have two problems"? :-P (no, wait, that's regex)

so three problems

"[[:digit:]]\+ problems\?"

(.*)

basically my regex skills are (.*) and (something|else|other)

\1\1

nsITobin: my regex and sed skills aren't much, but are enough to create confusing expressions

I can do that with my face njsg

no regex needed

I wonder if I ought to s@regex@&p@ above, along with soaren'toain'to

my brain, njsg my brain..

I do admit it does have a resemblance of Lovecraftian horror in a way.

i think that too

so the next mozilla logo after they get tired of their surrender slash money flag logo is gonna just be Cthulhu

str8 up

all the AI and telemetry and ads

njsg: think of it

too sleepy and low on caffeine to think

well you don't have to think of it.. its already there.. in your nightmares

it's*

njsg: i accomplished the hg copy and rename stuff :) Quite proud of my self over this tivial accomplishment.

trivial

i dunno if anyone is aware of this.. but working.. is hard LOL

i needed more sleep

ah, it's only DST, you'll be OK tomorrow ;-)

hi nsITobin therube

helo Frank

Mat

sup the frg_Away also hello therube

so the other day, before you'd mentioned it, i came across a picture of T with a vap pipe, & i was kind of wonder if you were still vaping. & per your post the other day, that's a yes.

I do still vape

entire ecosystems were built powered by nicotine and caffine..

because I built them.

this country partly runs on nicotine and caffine

we need the coffee or soda to keep us active and alert and the nicotine to calm our active and alert asses down

the issue with managed additictions is you HAVE to manage them.

so i am pretty sure I can accomplish the mechanical work of converting js xpcom components and jsms to esmodules.. but the bulk of them won't be testable

on central

well i suppose that isn't technically true registered xpcom esmodules can be tested in isolation but its tricky

yeah there is no way I can do this right now save some simple bits for xpcom js components to esm .. if the jsm loader was working I would just go js component to jsm to esmodule but the jump direct is a lot harder than what I already did to make aboutredirector work again

but the patches up on bug 1952288 are updated and with a part 4

nsITobin will move them into the patch queue and rebase

xul references patch will complain because of the minor realignment excluding --enable-updater cause its default on as ian rightly pointed out

you know the most beneficial thing we can make seamonkey on central do.. be a big Get Involved advertisement.

someone grabs runs it and all it does is tell them how to get involved in seamonkey development

i did manage the devtools hg copy and rename and edit

that patch was updated as well last night 1952319

ugh

more ugh

so resource uri is dead

moz-src i would guess is not exposed to the web

not dead dead yet but dead soon

no doesn't look like its any different.. so why the hell are they doing it

or rather did it

they added a whole mozbuild directive for it and everything

+Only privileged (system principal / "chrome" privileged) code can load

+or link to `moz-src` URLs.

yep there it is

+The intention is that in future we make it possible to have more fine-grained

+restrictions for `moz-src` URLs with non-empty "host" portions

+(e.g. `moz-src://about/` for content only accessible to about: pages), but this

+has not yet been implemented.

why fix the resource uri when you can spawn half a dozen new ones..

ffs

gitlab wip updated. Synced with 2.53

which mozilla version switched to 2022 do you know off hand frg_Away

it was after 115

nsITobin Bug 1881382

115 is when 2022 support was added 126 was when 2019 was dropped

Yes toolchain was added in 115

i need to go back to 103 convert xpcom components to jsms.. then fast forward to before 126 to convert jsms into esmodules.. THAT is how you are gonna get those patches and I need to do it SOON before 115 build deps are gone cause

well cause mozilla

after that.. see about xbl to xul webcomps .. once THAT is mastered the rest is just normal ass depercations and api refactors.. nothing ANYONE couldn't eventually handle if desired..

then the entire breadth of mozilla's patch history is far more open if these mass shinanagans of core tech are sorted

... or so goes the theory ;)

nsITobin huge task I am still not sure if it can be mastered without a team working on it full time.

I am working on munch now :) bbl

jsm to esm is actually fairly str8 forward.. xpcom to jsm is .. less so

yeah I nuked one of these goldenkrust.com/golden-krust-jamaic…n-patties-near-me/mild-beef-patties

least it has more filling than a hot pocket and a fraction of the price

if i could build 68-91 i'd just do it to it.. but I can't olest I been able is esr102 aside from seamonkey and anything 3.6 to 52 and also seamonkey xpfe

greetings FrankLion

what's up?

nsITobin: Hi, how are you?

Not bad.. been doing some central patches but I think I am gonna switch over to server and php while I think about attempting big tedious and impossible tasks..

FrankLion: feel free to Get Involved! :P

Well, it's good you're making progress though. Creating anything has always been far harder than destroying stuff, as parts of the world are now discovering.

gitlab wip updated. cZ problem fixed

cool

what was the issue?

bad comment in patch from a few hours ago.

Same for 2.53 but IanN already updated it there.

nsITobin you forgot to set r? fro thew new central patches

gitlab central updated

nsITobin didn't built central. please check.

I'll get it.. sorry i was prepping pork steak with bbq sauce

one would think I wouldn't miss such things .. just lack of the habit i guess

have to form em

nsITobin devtools patch is also set to new not assigned. If you can't set I can. just holler.

I have always been spairing with my bugedit privs

likely the reason I still have them :P

devtools integration in 2.53 is meh also. ratty did an intial patch but it was non standard. Correct would have been to add the devtools menu as overlay or so but that clashes with other things. I looked at it briefly 2 years or so ago but never found the time to properly fix it. Half of the items are dead now because of it. Something for the future.

devtools cc bug set to assigned and build conf fix and revamp patches set r? to ian

ratty would probably done it in a week. sigh.

frg_Away: later devtools has menu items added dynamically

yes not sure if it was the case already or overlay.

Pale Moon has the key to that

can't remember if I got em hooked back up or if it was janek or justoff.. one of us did..

real question was was it done in tycho or uxp..

there is a l-devtools-patchwork.patch in wip comm. Did this as a start then long ago. If you want it be my guest.

had to be uxp.. tycho is still using hardcoded menu items

Problem was that CustomizableUI.js clashed with NoScript. If present assumed that it was Firefox not suite. Baaadddd design.

was a stub anyway

well NoScript is known to cause issues.

and a fixup by me

plenty enough to do it to seamonkey

*closes rpmo*

i wrote this?

anyway yeah but it may require a patch to the mozilla side

nsITobin: will be bug 1952757 be of use

too many bes

checking

basically only needed to add the pre string

might make the central changes easier though

now for my impression of an LLM.. It looks like a patch adding a package display version to init.configure.

so what is this variable used for?

what does it affect just what the version is in zip and installer filenames?

As the name implies only the packaging. You could also use the display version and alter it by removing the spaces

nsITobin: yeah, for naming in packaging zips and installers

can't you exploit installer prettynames for that?

I thought of adding some scripting to do this but was just easier/faster to use a different version string.

doesn't MOZ_PKG_VERSION would should be MOZ_APP_PACKAGE_VERSION least according to my instincts need to be propigated into the packager in toolkit?

or MOZ_APP_VERSION_PACKAGE

nsITobin I didn't think we discussed it much. MOZ_APP_PACKAGE_VERSION might be better but the man needs to approve it :) I am a bit indifferent either way.

and now for soemthing sleepy different. nn

feel free to ignore my tendancy to get that nitty gritty it practically doesn't matter

it is a handy skill but I know it can get annoying

since currently MOZ_PKG_VERSION is a seamonkey thing I would certainly conform this to central as both a part five on the build revamp bug but part five would have to stay as a TOP cause it needs an m-c part.

oh this is 253

do it for both

sorry I am confusing my self..

so this bug is going to 253 and for backport sake it needs to be adapted for the central queue as well but obviously won't get into upstream

is that correct IanN_Away?

nsITobin: yes

shouldn't be an issue .. that's askin for trouble LOL