00:33:17 <tomman> https://github.com/axios/axios/issues/5038 meanwhile in the land of moving sands...
00:33:19 <tomman> Brave men test in production
00:33:21 <tomman> Hipster kids don't even bother
00:34:28 <tomman> Remember kids: if your webapp does not break in production at your next pageload, You Are Not Scale™
01:10:56 <NewTobinParadigm> http://personal.mattatobin.com/image/capture/22c96601-f3f0-43b4-aae9-4e45706431c8.jpg
01:11:02 <NewTobinParadigm> there much more complete
01:25:37 <NewTobinParadigm> tomman: I have done the in-place code change and had it error out
01:25:44 <NewTobinParadigm> i prefer test domains
01:25:59 <NewTobinParadigm> tho there will always be that ONE tidbit i missed and will have to patch quickly
12:25:08 <tomman> https://www.t-mobile.com/unsupported_firefox_incognito oh wow, if you're in USA and that's your telco, DROP IT ASAP
12:28:20 <tomman> https://news.ycombinator.com/item?id=33271033
15:34:01 <tomman> well, SteamDB went all in with Google WebComponents® and named capture groups
15:34:38 <tomman> also an annoying and offensive "Update your browser" button to Browsehappy
15:56:53 <ja> czech?
15:56:59 <ja> speak czech?
15:58:19 <tomman> Spanish here~
15:58:37 <tomman> but this is an English-speaking channel by convention
16:01:27 <njsg> ja: as far as I know, nobody speaks czech here, but it's always possible there *is* somebody
16:01:40 <njsg> if possible try to say in english
16:03:02 <ja> :D vole nejsou jeste slabsi pecky ted sechodi fakt tezce spat
16:03:29 <ja> esperando :D
16:04:21 * njsg goes check how does google translate mistranslate that
16:22:51 <ja> HAVE ANYWHERE IN CHAT WHO WORKING AT PROBLEM E MAIL DEFFENCE AGAINT SPANISH MONKEYS?
16:25:25 <NewTobinParadigm> hey frg_Away so yeah as far as eventually syncing as many pseudo-isolated components and modules.. indeed I beleieve that if we do share swaths but NOT the exact same platform my stuff may poke the same code slightly differently revealing stuff that would potentally go unnoticed for years so I think it is of tramendous benefit to all conserned
16:26:47 <NewTobinParadigm> i believe there can never be just one upstream ;)
16:37:04 <ja> I know the problem is system ip adres delete and contruct new system if this real ?
16:37:05 <ja> or we have choice only creating new game cat with rat?
16:42:33 <NewTobinParadigm> I also want to try and finally after over 10 years to complete mailnews incomplete linkage aka xpcom component not libxul
16:43:17 <NewTobinParadigm> if i get those into components then i COULD revive the xulrunner and xulapp package concept.. with an xpinstall inspired twist of course
16:44:10 <NewTobinParadigm> that was the post-netscape mozilla dream after all
17:26:02 <ja> line 3 working for?
17:30:15 <NewTobinParadigm> frg_Away: https://code.binaryoutcast.com/projects/aura-central/src/TRUNK/components/weave
17:30:55 <NewTobinParadigm> prep for when I offered to port over pure weave
17:35:26 <NewTobinParadigm> IanN_Away: you may know the answer to this.. do js components take priority over cpp components if they are intersecting the same job.. like the about redirector.. if we have the regular about redirector and a js about redirector if the js one defines an about page already defined in the cpp one which gets priority.. i would think js componments always take priority between cpp and js xpcom because the contracts are registered well after it
17:35:26 <NewTobinParadigm> already knows about the cpp component ones.. now i guess between multiples in the same type all cpp or all js it would depend on i guess the luck of the draw registration wise
17:43:03 <NewTobinParadigm> as evidnced when my restructruing physically changed the order of compilation causing issues earlier this year
17:43:17 <NewTobinParadigm> frg_Away: are your devtools still jetpack based?
17:44:12 <frg_Away> NewTobinParadigm Still at work. Will play catch up soon
17:44:20 <NewTobinParadigm> understood
17:44:21 <NewTobinParadigm> sorry dude
17:44:47 <frg_Away> np. Just wanted to let you know taht the conversation is not one sided :)
17:45:19 <NewTobinParadigm> frg_Away: that alone levels you up several places this year above others
17:45:53 <NewTobinParadigm> a lot of people even before the fall had just started ignoring others wholesale
18:00:23 <ja> where i can read and write .dll and . lib
18:00:44 <NewTobinParadigm> ja: maybe you should ask questions with the proper context
18:00:55 <NewTobinParadigm> that way others can know whatcha talkin about
18:05:21 <ja> i am sorry i must go sleeep new information dont have zitra and was big kokot :D
18:07:03 <ja> thx very much and the plane is learning and learning
19:43:10 <frg_Away> NewTobinParadigm Never tried to register duplicate components. Lots if changes in this and the second registration might even fail. This is basically all gone in the central code with only doing static registrations but we don't plan to backport this code. But if it works then my bet would be on the last registration too. I just wouldn't bet much :)
19:46:24 <NewTobinParadigm> I am not sure of the benefit to static registration or what static registration even means other than i guess because extensions are out of the picture they only ever need to load shit from gre or app never from profile so why scan everything for all the chrome.manifests
19:47:15 <NewTobinParadigm> that and whatever they are using to encode it.. json or yaml or w/e is more broadly readable by current day tools than chrome.manifest or jar.mn entries
19:48:10 <NewTobinParadigm> UNLESS you are talking about how for cpp xpcom components they are now codegenning most of the simpler factories
19:48:15 <NewTobinParadigm> is that what you mean frg_Away
19:49:21 <NewTobinParadigm> I mean I kinda like the idea of the whole codegen of repeditive simple shit but if i were to pull something like that I don't think I'd use Mozilla's codegen or i would heavily modify it to not be ridiculous
19:49:53 <frg_Away> I didn't follow the latest mozilla code drama and dumbification here but yes I think this is it. Components need to be all knows at compile time. Someone more familiar with central code might correct me.
19:49:55 <NewTobinParadigm> something I can invoke manually as well and use the codegen as a template generator to create a more complex component
19:50:35 <NewTobinParadigm> i like the concept but i am almost sure i hate the impl
19:50:40 <NewTobinParadigm> no surprise there then lol
19:51:32 <NewTobinParadigm> Well after this sec release i will sit down and run some tests to find out the ACTUAL behavior of competeing components
19:51:37 <NewTobinParadigm> cause that SHOULD be documented
19:51:52 <frg_Away> For weave wonder if it is possible to build a second independent set of services api so that suite or any other single application the source tree can use this instead of the standard weave.
19:52:55 <frg_Away> Is there anything sec releated to be backported? Latest bugs seem to be 99% sec "regressions" for later code. I have identified one so far which might apply.
19:53:58 <NewTobinParadigm> the issue I ran into with gre restructring involved an embedding component which is supposed to be there for embedders but normal xulapps get a places interface.. when I moved shit around it changed the build order and thus the order the factories were compiled in and so suddenly shit was busted and i couldn't figure out why but i eventually found that component.. which btw didn't function and hasn't since nsGlobalHistory was killed a long long
19:53:58 <NewTobinParadigm> time ago.. it is only happenstance that Mozilla devs never had an issue with the colliding interfaces
19:54:46 <NewTobinParadigm> I dunno
19:55:35 <NewTobinParadigm> if there are any likely canidates for fifty-two based platforms they will be showing up in the UXP and subsiquently my repo in the next few days
19:56:38 <NewTobinParadigm> but i figured .. why release a sec update when there could be more sec updates in a few days
19:56:40 <NewTobinParadigm> get em all
19:57:15 <NewTobinParadigm> with just a mail client and low usership i can play more fast and loose with releases and even sec updates .. that won't be the case once Borealis is launched
19:57:42 <NewTobinParadigm> then it is monthly release with the only out being no sec updates and no feature updates
19:57:49 <NewTobinParadigm> again
19:58:31 <frg_Away> wrt static registration Bug 1770237
20:01:02 <NewTobinParadigm> more than likely my strat would be simpler factory codegen and move js component registration to the same file that but in the end it would be outputting the same chrome.manifest files and essentually the same xpcom bincomp factory
20:02:07 <NewTobinParadigm> hey if i ever accomplish it you can take it ;)
20:02:24 <frg_Away> manifests are gone and you have a components.conf. https://hg.mozilla.org/comm-central/rev/142345e84687
20:02:40 <NewTobinParadigm> i'd also likely match the manifest format mozilla choose but the impl would be to match what would be without
20:02:48 <NewTobinParadigm> why .conf
20:03:03 <frg_Away> So I don't think you could do anything in add-ons any longer with it.
20:03:53 <NewTobinParadigm> see i would use such a file as a build file.. i don't want to replace chrome.manfiest with anything except json perhaps.. or just go back to contents.rdf
20:04:52 <NewTobinParadigm> i am so tempted to re-rdf as much as i can just so i can say fuck you to everyone who ruined everything for the past decade lol
20:05:57 <frg_Away> Well IanN and me are ripping it out mostly. So we are the enemy :)
20:06:48 <frg_Away> Frankly this mostly ancient. It works but a lost art. Later stuff does not apply well here.
20:11:52 <frg_Away> as for mailnews. Ours is at a mix of 56 to about 65 with some de-rdf work and bits taken here and there plus later stuff when we like it. We mostly picked the functional changes and not the ui ones. IanN and me are still keeping TB there building to do a-b tests. Still mork and the old address db format. I think we might switch over to maildir from mbox one day and even to the new address db...
20:11:53 <frg_Away> ...but the js protocoal implementations would need to  mature a few release more. Say 20 to 50 :D
20:14:10 <njsg> there is a recent thread in the news.eternal-september.org support group where it seems Tb might be not always authenticating
20:14:21 <njsg> I wonder if that's the new js implementation?
20:14:39 <njsg> (or has the same been observed with SM M&N?)
20:15:01 <NewTobinParadigm> i would accept mailnews not using rdf if it meant we could share a common impl
20:15:19 <frg_Away> probably but might happen with the old implementation too if "weird" server.
20:15:31 <NewTobinParadigm> besides, i could always hack in my own whateverstorageformat to rdf datasource if i really needed to
20:15:36 <NewTobinParadigm> or just ifdef it
20:15:38 <NewTobinParadigm> llol
20:16:42 <NewTobinParadigm> i mean i don't LIKE the idea of dropping the historical formats but i have to balance that shit with the reality
20:17:29 <frg_Away> What I dislike about js here is that you add another layer of abstraction and loose any coding warning during complie time.  For frontend go for it but for a critical backend lets just say I am not a happy camper.
20:17:35 <njsg> news://news.eternal-september.org:119/m2lepbw2g5.fsf⊙rn hm, Ray says "known for years", so maybe it's not the new implementation
20:17:49 <NewTobinParadigm> besides, a specific component even as big as mailnews not doing rdf is fine because it has no impact on some of the stuff i might do rdf with
20:18:11 <NewTobinParadigm> frg_Away: I completely agree with you
20:19:06 <NewTobinParadigm> i have the feeling if you stick to purely mozilla bits in xpcom components and support code.. i think it is learnable.. but the stuff rewritten after say 2014 that is harder to redo in pure xpcom
20:20:35 <NewTobinParadigm> I think my approch will be that while js components are great for simple small things or as an interum solution (kinda like self hosted js) but a cpp impl should eventually replace it
20:21:09 <NewTobinParadigm> on the other hand i think most components on the application side should be js registered
20:21:19 <NewTobinParadigm> and implimented if possible
20:22:06 <NewTobinParadigm> but that simply follows my agenda of wanting to ease the recreation of the xulrunner dream
21:01:36 <frg_Away> Naturally all should be done in Rust so that I have an excuse to leave IT.
21:27:59 <NewTobinParadigm> LOL
21:28:03 <NewTobinParadigm> SAME
21:35:01 <tomman> Rust: when oil is not enough™