OK. Well hello everyone for more multi-arch, I'll try and be more exciting this time round. So fortunately for me, Philip has just covered all the really boring technical stuff, so we don't need to do that again. I will try and talk about some slightly more less hardcore aspects of the problem. So there's a couple of things here, there's basically where we're at, what's going on. Philip's covered some of that, I've got a few more things to say, but also particularly if people have problems with their packages and would like to ask questions, this is an opportunity to do that. Unfortunately several of the clever people who know the answers have left, so please don't ask questions that are too difficult. It's quite late in the day and it's kind of stuffy. So first thing, simple point. As has been explained, the interpreter runtime stuff is a little bit tricky. It's not actually broken, it's just some combinations of things you can't install. At least it's not broken for most purposes. So someone said how link, I don't know, app, get, no, okay. Somebody typed a page in the wiki in. So there is a multi-arched python in Ubuntu, it's been there for a while, it basically works. I think, Docher, you said you hadn't uploaded that to Debian or microphones, microphones. Well, I did do the multi-arching of Python because we need Python to build or to cross-build our base system. When cross-building you have two possibilities to build the base system. The first one is to use a staged build, just avoiding to build the Python stuff and modules and packages. The second approach is to make Python ready to cross-build extensions, not just the Python interpreter itself, but to cross-build extensions. That was the thing that was chosen. However, the DPKG maintainer did complain about the approach. So, what you have in Debian is exactly the same as in Ubuntu, but with the multi-arched attributes removed from the binary packages. I think the other problem is that at least some of the Python multi-archification in Ubuntu relies on build depends on colon any, which don't work yet in Debian. I'm still hoping to try to carve out some time to work with Bill Demon's Enters in Debian to finish that off. If I don't manage that, then hopefully it will be relatively shortly afterwards. You mean it's in deep package, but the one-a-build thing goes wrong? One-a-build will just reject any such thing and declare it uninstallable. I can't remember whether quite all of the us-build bits of that is, but it's all very, very, very close. It's just not quite there. Okay. Cool. So, Pearl, Niko, Tini did some fine work to basically work out how to rearrange the Pearl packages to have multi-arch support. That's not actually loaded anywhere yet, apart from my bootstrap archive. And I guess it's not even uploaded in Ubuntu either, is it? In Ubuntu, we did a reword it after we were able to build Pearl natively. Okay. I'm not sure if Pearl already has support to build extensions for... Cross-build extensions, yes. I managed to cross-build some extensions. The make-maker thing that does that is very stupid, so it needs quite a good kicking, but I did get it to build a couple of examples.  No, so I haven't tried that. I think that would be worth a shot, because if anything... A lot of stuff still uses make-maker, but there'd be things moving over to module build. Right, okay. And that explicitly has cross-support? I have no idea. So make-maker just doesn't really understand the concept, so it's a bit of a manual. But it wasn't... For simple modules, I think it's okay, but it probably breaks anything more complicated. So the Pearl stuff, so it was doing the Pearl multi-arching that we realized there's this transitive dependency thing that we weren't quite sure what to do about. So we all kind of went... So I used that Pearl for the ARM64 bootstrap. It turned out that you could cross-build Pearl, or you could multi-arch Pearl, but I couldn't get a multi-arch Pearl to cross-build. Well, it did, but lots of things were in the wrong places. It's kind of hacky, but, you know, as Doco says, you could use that to get started, and then you could just build one natively again at which point it comes out better. TCL, we've done... I started... Is that all right? Just having the headers and the libraries in the multi-arch locations, not being able to build ticker extensions or cross-build ticker extensions. OK. So we have the... because of the config script thing. Yes. But we have links to the config script. There's a little shim. Where's Dimitri gone? Is this all what's needed? Yeah, I think so, apparently. OK. So the set of programs which are mostly old, which predate package config, so package config just works in multi-arch. You tell it, ask it where stuff's installed. It tells you where stuff's installed. But old-fashioneder things tend to have a shell script you run in userlib tclconfig.sure, right?  Yeah, exactly, which all just give you the path of the thing I was built with, not like the path of things I need to build for now, which is the question you were trying to ask it.  And so some modification apparently works OK for most TCL stuff by just installing the multiple versions in the multi-arch locations, and then everything calls what it believes to be the canonical script, which looks up what architect you asked for and gives you the answers from the appropriate thing. But mostly we should probably just move all these things to use package config. That's the right way to do it. But some hackery with shell wrappers seems to get us a reasonable way with other things that have crappy scripts. So far as I know, that works for, including for building TCL, things which build depend on TCL. But I have no idea what the status is for Java, Mono and Ruby. Does anyone in this room know? Of course, the Ruby man. So Ruby 2 comes with multi-arch support upstream. King. That should work. I'm managing the final bits to make sure that you can co-install two different architectures of the Ruby interpreter itself. Actually, the binary is already co-installable.  And then when that's done, maybe that can be back ported for Ruby 192. Okay. So that sounds like progress. Does Java has JNI, doesn't it? So I guess those things would need to be, are you saying? Right. I think you're saying that the OpenJDK does look in multi-arch locations for JNI things, but upstream Oracle doesn't. So that won't work. So yeah, so we're making progress. We have this general problem of transitive dependencies to do something about to make everything work properly. But it's coming along. Pils, a bit of a blocker because that's part of the base system. We really do need that fixed. So the moment there isn't even anywhere to file bugs about it, there's basically a very long thread on the pearl list about what fun this has been. So at the moment, the version experimental is part of the 5.18 transition. That should happen soon. I'm not quite sure when soon is. Is Niko here, or is he? 5.18 transitions should be in a week or two or something. Right, really soon. Okay. So then we'll upload our slightly broken multi-arch pearl for people to experiment with and see what all bugs are about. One thing I'll say is that for once we would be able to be ahead and have been to the 5.18 transition is I think probably going to be a bit for our next release, so we'll have to hold it off for a while. Go ahead. How cool are we? So one thing that's interesting about pearl is that we've had to split it into two pieces. Pearl was carefully one thing so that when you upgraded it whilst doing stuff, installing core stuff, you couldn't end up with a broken one. But now we've got two parts. So if we managed to upgrade one or not, the other things could go wrong during pre-installed scripts that use pearl and other. So there's potential for breakage. I don't think we'll get to find out until we try it, really. Okay. Let's discuss that and reason about it before we upload it. I'd rather not have the central mechanism. Put it in experimental, right, so that we can try stuff. No, experimental is not useful for getting user testing. Okay. If you're trying to find bugs in your stuff, experimental, effectively, you only get, that's only useful for having a coordinated group of people to test things. What you need is you need eyeballs on a problem. Don't upload it experimental and ask for eyeballs. You need to talk to people and the upload to experimental is irrelevant. But I'm saying it shouldn't go to unstable at all until we've actually thought through and reasoned about the maintainer scripts and not just counted on people to find bugs in them for us. Okay. Yeah, it's definitely not going to unstable before they also looked at properly. I just thought it's easier to test if it's in experimental because you can just get it and then you can try stuff. Yeah, but then you found there was a problem. Well, sure, but you know, you should think about it first and make sure that it works before you upload it anywhere. We thought about it a reasonable amount and believe it will work. I'm happy to put it somewhere else if it's too broken for experimental. I'm going to test it that much before uploading it. Sure. My point is just that not that it's too broken for experimental but that uploading it to experimental is not a good safety net to rely on and that if you haven't thought about it enough that you're happy uploading it to unstable we should think about it some more. Okay. Please do that, people. And people like Steve who knows what he's talking about. So there's the whole chain of arch-independent all-dependent things which we've covered so I wrote all that up. There's a nice wiki page now which I don't think Philip mentioned which basically covers the discussion so far and Colin has a nice shiny piece of paper which was produced during lunchtime. We'll get to argue about it a bit more. But it's pretty esoteric stuff so unless you've been taking interest in this you probably just want to wait for someone to provide you with an answer. One thing we have discovered is a helmet wrote a nice handy little script to work out just how many instances are there of something which is arch any depending on something which is arch all depending on something which is arch any and it isn't just a false positive. So there were 640 packages in unstable with that property. We're down to 500 excluding my view. Okay. Because that was about 100. Down to 540 packages with some false positives excluded. So a reasonable number and from the languages we expect including and node as Colin says it's possible that in fact in Pearl this isn't really a problem. But that will be quite a lot of packages to just make arch any and have 13 copies off. I think from the discussion with Helmut at lunchtime I think my feeling is that Helmut's proposal to basically propagate up the architecture proposal is basically right. The refinement that this stuff I was thinking about would introduce is we think probably doing something with multi-arch lod and having additional things that look a bit like how you're handling arch all additional worlds where you have to have the same set of architectures but you can have multiple demands. So this is for the Perlin, Python scripts in the same package problem. But I don't think any of this should be a blocker to going ahead with Helmut's idea and it seems basically right to me. So the main problem with that actually is somebody doing some deep package work. We're always short of enthusiastic people to go and hack on deep package and argue with Guillem. And he's not here for us to argue with him in person, which is a pity. We'll see how that goes. Sorry? No. Sorry. So other aspects, the multi-arch cross spec has existed for a long time and the docs are all full of this isn't specified and don't do that and don't move your headers and this only covers library transitions. That was true. It's really quite out of date now. Actually we've been using the multi-arch cross spec for ages in Ubuntu. It seems to work. It doesn't seem to have caused any real problems. So basically unless anyone has any massive objections I think we should just declare that part of the spec. No fundamental objections. It seems very solid. All of the dependency level stuff is working just fine. The one thing I'd say is that it's very easy for people to miss the kiss where their headers are not in fact as multi-arch as they look. Particularly with, let's say, where headers happen to depend on the endianness of your build machine but you only test on AMD64 and i386, you won't notice that it's really multi-arch or if they depend on it being Linux and then suddenly FreeBSD differs. So I think it would be helpful to have some kind of checker script that can best look at an archive and check whether the allegedly multi-arch same things in it are in fact multi-arch. Someone asked that very question outside saying how do I check whether my package is actually which ones really differ between architectures? I don't know. I mean I don't think it's desperately hard but I'm not sure I wasn't really certain such a thing. Jackup will script, sorry. Jackup has these kind of scripts but I don't know where you can find them. I'm not sure how a maintainer can use those so I think we need to find that out and write it down for people. As a maintainer of D-Dub deviannet, I came to this idea during the stepcon and I will investigate whether I can just pull in two architectures into D-Dub and then do comparisons that way. Okay, cool. I've got the issue of what is arch and depth. Yes, welcome to that in a minute. That's another item further down the list, is what is the definition of matching. It would be terribly useful if perhaps a package tracking system told me that had just scanned our development packages and said these are all identical. I think this should be marked multi-arch same. Well, I mean you can't just do it straight away because you ideally want all of your dependencies to be multi-arched first because you cannot multi-arch this library dev and then you can't co-install it because its dependencies are not co-installable. That's not true. Yeah, it just doesn't do anything. Things don't have to be multi-arched in tree order. You don't have to start from the bottom. Okay, that's not an issue then. But the other bit that I did hit was that you have to deal with a fallout where things and configure scripts don't look at the multi-arch locations. If you move stuff to multi-arch locations, you should ideally look at your reverse build dependencies and make sure they don't start looking into embedded copies of libraries because there wasn't one found in this system location. That's quite important advice. If things build depend on your stuff, then you need to check that that stuff still builds preferably correctly because we know that there are problems, especially if you've got one of these stupid config script things which is very likely to give the wrong answers without some work. What else do we have? So there's this thing about arch all build dependencies being assumed to be MA foreign. So again, this was done at Ubuntu a while ago because it turns out that whilst you can't do this for dependencies, you can do this for build dependencies and just say, if it's arch all, I can assume it's foreign, which means that every maintainer doesn't have to put a one line, this package is MA foreign, i.e. I can just use it as a tool and it should work. Now, the fix we're about to do for the transitive problem makes this go away, so we don't need to. But in the meantime, given that there might be a fair amount of meantime, again, this is stalled on are the deep package maintainers going to complain. Has Steve gotten around to actually presenting it to the deep package maintainers? Well, I asked on the list actually a while back this very question. Sorry, who? I did. As you haven't. Oh. And I don't think I got an answer. Okay. Well, I can re-ask maybe. But just to give the two line summary of why this is okay for build dependencies and not for dependencies, it's because the only place this ever comes up in build dependencies is when you are trying to cross compile, and that was never possible previously in the packaging system anyway. Therefore, we're not breaking anything that previously worked by assuming all architecture, all dependencies are actually multi-arch foreign, and we can just get on with it, and if it doesn't work, then we do something different. In fact, it's a good enabler because we don't have to worry about breaking compatibility by thinking an architecture, all package satisfies a dependency that it really doesn't. Yes, because the docs at the moment, I think, tell developers not to multi-arch their dev packages, which is actually a bit unhelpful and we should fix that. The docs are wikis, right? Yeah, I know, I know. That's why I asked this question today. Is anyone going to complain if we... Do you think we should combine the two specs into a spec, or should we just leave it? Mike, back again. Sorry, with regards to combining the specs, the existing spec that you're referring to is... it was written as the implementation spec, which is this is how we put together the package managers to do what we want to do, and multi-arch cross, I believe, primarily documents, this is how you want to put together your packages, and I think we should have documentation of this is how you should put together your packages, and I don't think merging the specs, the two as they exist is a sensible thing to do. Okay, well, I was thinking of trying to, as you say, have one thing which is a specification, as opposed to a discussion and implementation and explanation that are different things. So my only objection to having dev packages being multi-arched foreign is that we'll have to remove those headers again after the fact. So we need to put careful thought into that to come up with an Indian tag that enables us to remove them later on. What do you mean remove them? No, remove. But multi-arched foreign headers don't make any sense on dev packages. They don't provide the boundary. I think that this is talking about architecture all, which is not for dev packages. Oh, there might be a small handful. Right. He said something about templates. So regarding the specs, it's mostly indeed true that multi-arched costs more of a high two, however it also has some... It's got some spurious stuff about tool chains which I think are just taken out because that was kind of irrelevant really. There's that, but it also has an extension to multi-arched spec in terms of the behaviour of, it depends on colon any, and I think that should be folded back in because it's pretty confusing to have them separate. So, yes. Maybe it would be a good idea to comb through the multi-arched cross file again and really take out the stuff that is usable as a spec as it is where we have actual implementation experience. Put that in a separate document and I don't know if it should be a DEP or whatever. It was started as a discussion document and it's acquired bits of actual spec as things have firmed up, but it's not really a very good document as it stands. I guess I should have a look at those doing that. We could have an action. I'll never get actions out of my boffs. Turns out I can't talk and write. I don't know. I know, I know. Turns out... Yes.  So, we should have some multi-arched related goals. The goal last time was make the libraries co-installable and get rid of I32 Libs. Dash Dev co-installable and... All Dash Dev packages? Yes, all. It's a good goal. Okay, our goal is supposed to be... I like achievable bills. I would like to see some means for some QA criterion for cost-buildable packages. Currently it's very difficult to look at the result of a cost-build demon and decide is it intended to fail? Is it intended to build? I would like to have us to add some attributes maybe to the control file. This is the package which is supposed to cost-build and maybe something like this is a package which the maintainer has checked that it does cost-build correctly. Is that really something that should go in the control file? I think you're right that we should have QA and include the concept of is expected to work, is not expected to work, has never been tested. Well, maybe we can add more jobs to Jenkins to see that they just fetch the package and cross-build it and if it succeeds it should succeed and not regress. Yeah, if it ever built once before then it should carry on working. Just throw away the results. I mean, we don't care about the cross-build results. We proposed a field about the package being cross-buildable like maintainer saying it should cross-build and then it being a bug if it's not or at least having a flag like you said in an email that Wogan I wrote to a devian devil in the beginning of the year and there were some reasons of some people who don't remember now why that's not a good idea so if you look up that thread you can maybe respond and say why you think it's a good idea. We have the access test you'd field already in the package file and currently it's only used for auto package test but we can add comma cross-buildable which is a test. Yeah, might work. So yeah, I don't know if somebody needs to think about that really. Yes, it would definitely be useful if maintainers had better. My idea was that we'd run a cross-build demon and put the output of that into the package tracking system to say your package does or doesn't cross-build and basically if it had never done it before it wouldn't be a failure for it to not work now but if it ever had worked then we'd moan that it used to work and now it's broken. Philip wants to talk. So yeah, okay, that would be good. Any more suggested goals, Steve? Well actually I was going to respond to this question of tracking what builds and what doesn't. I think the goal is everything should be buildable and we get as far as we can with that as long as people are caring about cross-building so like when somebody is actively doing a bootstrap they worry about these things and it's always going to regress in between and I don't think it's reasonable or realistic to require Debian maintainers to for instance regard those as release critical bugs because they're not release critical for Debian but I think all of this worrying about documenting what does or doesn't cross-build is actually to a certain degree it's wasted effort when you don't actually need to get it cross-built right now and right then and there and when you do, the fact that it was a failure or not that you knew about is not the point the point is you now have this thing that you need to get cross-building OK, fair enough I think it's actually, the idea was that by running some QA that people get told about we're quite likely to keep it in a good state because of course without any QA or CI it's quite likely to get broken again I think one thing I would say is that it's useful to know whether a package when you're in that position of trying to bootstrap something it's useful to know whether something ever built before because then you have some notion of whether the problem might be tractable or not if you're just staring at a C of 600 build failures it's quite hard to see what's sensible to work on first and similarly the information that the maintainer thinks this works because it's in the control fire is actually quite important you know I think I've fixed it if it's broken then you'll like it to get a better response then no, this is never going to be cross-build but I'm not interested get lost well I don't think that's a reasonable response from a maintainer and that's why NMUs exist and such and such although some things are a bit scary some things are difficult to cross-compile and I guess I take Colin's point that it's useful to have that information but I don't think it belongs in the control file I think it's just something we should be running QA outside to document this for our own purposes rather than pushing it on the maintainer I agree with that there seems to be two aspects of it there's what do we want to force developers to do and what are we ready to take on as stuff that we need to do as NMUs or whatever when we're trying to cross-build and this is very important to if we start doing partial archers which is the next stage so if we ever end up with stuff that's in a partial arch that's only ever cross-built then is it like me, MinGW guy the only responsible person for actually doing all the patching work or can we force DDs to do the cross-build stuff for some stuff if it's ever been done before so that's what's nice about having something in the control file because that means that the the maintainer of the package is sort of committing in a sense to keeping the package cross-buildable the low threshold NMU wiki page is DDs committing to something and that's very simple so it's just a list of people so we could just do that and say will you help do you undertake we do already have a long tradition of low threshold NMUs being permitted across the archive for porting work and this is just a kind of porting work so yeah the acceptance across compiling is increasing slowly and we may find of course once everyone's got really fast arm machines there'll be less of it again we'll see how things go and it's fair to say at the moment we only really care for a fairly base system but it will be nice to spread that further of the I think the Ubuntu particularly would quite like to have a nice dev system for the phone dev thing so if everything in that tree cross-built nicely that would be cool can we agree on a target for cross-builds so I think it doesn't make sense to well to choose ten different targets for cross-builds but maybe as a first goal well agree on one or two targets which we want to you mean target architectures well supposedly something which well the majority of developers can actually run so for example armhf there aren't very many if you made it work it should work everywhere shouldn't it how often is it but how can you test that yes okay well in practice maybe we'd only test for a target and that's what people get told about so yeah armhf is a good one at the moment I'm happy with that but in general if you fixed it to cross it should just cross for everything modulo I don't know strange java dependencies that are broken for some architectures or whatever okay so yes just to get through things we'll come back to release goals possibly but Mingyu presents an interesting case because our current assumption about what is a different package is a different file sorry is it's libc but just the small subset of headers which are different between architectures but as soon as you go no no Mingyu is an architecture as well that has a completely different libc it's not a posix libc so in fact the set of headers that change just got much bigger so the question becomes what is your definition of the same now it's actually fairly easy to fix in the case of Mingyu you just go okay well all the c headers change between some of our architectures so we'll put them all in the multi arch locations except for maybe the three there are actually the same between windows and linux I don't know how crazy is that how violently do we object because it's also the same for the linux non super embedded people I suspect and android exactly yes which is another useful so maybe we should start to actually put all the c library stuff out of user include pretty much and then we can have a wider range of architectures supported well for starters I would just declare a MingW libc def package arch all and that puts its stuff into the sub tier so I don't see a reason for for it not to be parallel and leave all the linux stuff there and hope that nothing accidentally includes that Steven can respond about that's pretty much what's happening just now there's already a MingW cross compiler in the archive with the c library it uses the old style user triplet stuff and it only uses that so it never picks anything up from user include so that works fine if you're doing the equivalent of bare metal builds that only target the c library on windows if you start to extend things so I've got there are users who'd like to have libraries other libraries for GTK yeah like GTK for windows and they're even in Debian packages that need other stuff like for this Python needs zlib and whenever we get around to packaging and when mono's gonna need a whole stack of stuff and so we either duplicate all the packaging which is what fedora have done or we try to do a multi arch stuff and because we're saying that arch independent stuff can go into just user include that means that the MingW GCC has to look there as well to pick stuff up like nothing that's driven by package config but zlib for instance has its headers in user include so this GCC MingW needs to look in there which means you can't have anything in there that's going to confuse other stuff so basically he has to move out if we go down that route because you then get configure scripts that look around for stuff and they pick up stuff that's in user include that they can use to build but they won't actually it won't match anything when they're running I think well to move gilipsy to the multi arch include you would have to do it first and then do a test rebuild of the whole archive see how much break you get and I think we we can't stop with gilipsy because there are many linux specific headers then in usr include in other packages gilipsy will be the worst one there will be a bunch of incend configure scripts in the dawn of time that do stupid things and it will be hell for a bit it would probably be helpful to do some kind of test rebuild against a test archive with gilipsy and file a bunch of bugs so that we don't have everything so that we don't have 2,000 packages instantly failing to build and then it's becoming impossible to do anything for a while it might be nice to stay at that a little bit I mean the case for moving lipsy headers is of course good but Ming W partial architecture in itself is currently still blocked by d-package not having a Ming W triplet and that's the bugs been open for a long time ago and I don't know how to push a consensus on it considering there are people who would want to do the port and cross build a lot of packages which are useful that's relatively trivial amount of work compared to the lipsy so my feeling is that there is general support for that so I think we should probably kick a bit harder to push people here as it maintain there is an open bug to include Ming W triplet into the arch table and the arch table so we'll have to try and push that I think a bit more complaining it's a trivial patch I'm not quite sure what the objection would be it's not that trivial it tends to be quite picky on having triplets upstream first and stuff like that so it double checks everything and I think there's some disagreement on the naming of the ports I'm not sure it's thought nowadays is that fixed even it's probably easy to add in all the people who do the port agreed on a triplet but the rest of the world seems seems that it's inconsistent what's been done before on Linux yeah there's a sort of disagreement between what should be done but things are a bit too late now because everybody uses what's already been done and there's another new fact that's just broken out between Ming W 32 besides the point okay so alright we'll see how that goes I'd just like to get to the actual questions from people at the bottom of this thing can someone explain what it is they were asking there's a Ben over there so for several architectures we have kernels built for 64 bits that the userland is all those two bits the kernel that's used is or maybe actually 64 bit essentially belongs to a different architecture so if you currently if you install the headers package for this or the dev package for building after your modules that's although for example you have a dev package for a m64 kernel image you're actually installing this on your I8386 system right and that sort of works with the assumption that you that GCC is actually or it'll be GCC-4.7 because we do specify the compiler version I would rather like to get rid of the pseudo native the foreign kernel packages so you can just install the you make your system multiarch and install the kernel from the from the foreign architecture package now I'm actually installing the kernel itself works but the headers package, the dev package doesn't work because that has a dependency on a particular compiler version right, so the problem is that we're getting our dev headers package we don't care about libc the kernel libc dev that package right the linux headers package which is what you do for building after your modules that package, right okay I don't know so do you know how to fix this well I've just been trying doing and what seems to maybe work but it's kind of disgusting is to change the dependency on the compiler to say for example it depends on GCC-4.7-936 or GCC-4.7-AMB64 this is assumed of course that the compiler is not actually multiarch, it's multilib but it does sort of work in a multiarch installation need a microphone to be able to work I don't know what for example DAC or Brittany might think of that Brittany I'm pretty sure it doesn't handle at the moment I thought that was disliked back at the moment but maybe Steve can okay so after you can think about that we have two minutes for one more question so I'd just like to bring that up is this you asking about so help never mind that we'll come back to that I follow up question on that Ben can you comment on whether the foreign interface to the GNU-C compiler would address that need it would mean that the package has the target architecture in the name to depend on so you might get a cross compiler but you may get the native compiler so you would say it depends on GCC-4.7-1.6 yes would that address your need yes I think it would so that might happen after we have cross compilers in the archive so yes so Antoni so is this about whether we want we need or is it useful to have triplet-interpreter in-path like most of the interpreter language you run the interpreter against a configure script with metadata to generate a make file stuff so is that the way to go for enabling cross building of C extension so at the moment we put triplet on the front if the output is if it operates on foreign architecture stuff is that the right definition if the target is the file architecture so you're thinking about having triplet Ruby I don't know triplet Ruby sounds wrong to me because it's not really a cross compiler I think but I'm not sure I quite understand what you're achieving I don't know sorry there's one question I'd like to squeeze in I think the answer is no so the thing I did with Python is you need the Python interpreter for the build machine to build extensions for the host and what I'm doing is well using this interpreter but prepending the module path for the host specific modules so the interpreter for the built things it's the interpreter for the host and does the right thing so that's ugly but you can compare notes one last thing in the five seconds we have remaining should we enable i386 on Jesse MB64 extensions by default i386 is a foreign architecture so they've tested it in Ubuntu and not too many things went wrong but our time is over well hands up should we enable i386 by default on MB64 any nos right well there you are sounds like a yes we decided something genius thank you very much for sitting here sweating and listening to all this tedium I suggest we all go and do something else for a bit


so guys i am back with another Diablo 4 video people and today we're gonna check out everything we need to know you need to know about the season of the malignant which is season one for diablo 4 which starts the 20th of july basically 13 days away people let's go how's it going guys my name is dpj and if you do enjoy the video leaving a like really helps out if you like what you see and want to see more be sure to subscribe so it starts guys july 25 i cannot wait this is going to be pretty cool and if you haven't seen anything on this in regards to what's coming i'll have you covered right here today guys you got any questions i need answering hopefully within this video we answer them okay so this is actually the first time i'm looking at this as well i'm recording this basically not long after these details have been dropped but i'm dropping it the next day because youtube's going to be absolutely crowned for everybody covering this but i also know as well guys as european folks and uk folks that this will be new information too so let's go delve into the corruption battle and new boss wield new power earn rewards 13 days 16 hours it's going to be a lot lower than that by the time you see the video but hey guys let's go a diablo emerges a new form of lily's corruption has spread throughout sanctuary creating malignant monsters that roam the land overtaken with this infectious turmoil minds are lost and killing out random only you can fight back and harness the power of this twisted corruption to uncover the source of the malignance and put it to an end now if you haven't seen the trailer guys let's check it out oh shit he's asking for my date of birth let's just lie here and say i'm just i don't know 50 odd does it really matter actually 70 or 71 2 3 continue there we go guys there we go now we'll make this big i've got this into the videos i can hear it let's go people because although a great evil is receding from sanctuary i'm so excited for this i'm so excited i'm seeing a lot of people complain about basically having started to create a character it makes me laugh it makes me laugh i mean i love that idea i really do i love that idea everyone's starting afresh what we like to see people is he looking cool though i'm guessing he is the quest giver this kind of animation is incredible really is man he's got a fan of snap that chick he's got a fan of snap i need get out of here here we go the upload for season of the malignant starts 20th of july 2023 okay so let's go and check out some of this information we have down here season features discover what lies ahead in the first yablo for season okay so strand against the malignant new quest line sanctuary has been corrupted overtaken with an infectious turmoil creating abominations that go through but who is to blame for this new wave of corruption partner with commoned a former priest of the cathedral of light to discover the source and stop the spread of the malignant at all costs new power wield malignant hearts okay so defeat these powerful corrupted enemies to harness their malignant hearts with over 30 new malignant powers to wield the might of the malignant is yours for the taking and that sounds cool people look how cool that picture looks bad ass people okay so new boss battle fight the corruption scored a malignant turner turn also to search for the catalyst of corruption make your stand against varshan the consumed and uncover the secrets of the malignant badass people pursue new options and new gear with six new unique items to discover and seven new legendary aspects to earn along the season journey there are more powerful options to harness for every class but oh yes this is what i like this is what we like to see my focus yes it is okay so season journey and three about pass earn three rewards unlock rewards by progressing through chapters of the season journey and tiers three season pass available across all season around characters okay so season journey complete chapters of this season journal uh two every wars including new legendary aspects a mastery title and a scroll of amnesia which provides a free skill tree and paragon border reset wow plus earn favor toward the battle pass along the way favor i'm guessing is the xp which will come to i'm guessing no doubt season blessings use the small ruin ashes you earn in the battle pass to upgrade all your seasonal characters with increased xp gains better chances for more rare materials and when salvaging items and more seasonal title show off the only thing more frightening than the malignant is you with the oldish monster title cool clothing and weapon transmogs collect a weapon transmog for each of the diablo five classes no diabolos five classes sorry not diabolos five and artisans clothing that's designed to be mixed and matched with other armor sets to create a unique look for your character pretty cool i'm not sure about what he's wearing up there in that picture guys no i'm not premium battle pass get more with premium earn your way through 90 tiers and unlock premium rewards with a walking armor sets mounts and mount armor platinum and much more so you can actually earn platinum that's pretty cool now that looks bad ass that arm looks bad ass the cold arm armor set this arm was forged for the sole purpose of resisting the malignant spreading across the lands cool okay so the warded mustang mount that's badass expand your stable expand your stable so with two versions of the new warded mustang mount now that looks cool as heck okay so we also have the coda and bond my armor wow add on your new steed with my armor we're inspired by the malignant's taking over sanctuary that looks badass that looks badass man weapon skin mount trophies emards platinum some more okay so the scythe necromancer looks pretty good so i'm using nice shield there don't use a shield though um oh yeah pretty cool 660 platinum is that what we can earn what can you buy with that though from the store probably not much okay so explore a range of cosmetics to earn along the premium battle pass collect a weapon transmog for all 19 weapon types two emards for each class to let you threaten your enemy or find a little time to play around with malignant heart cages two headstones even let you die in style add on your horse with five new mount trophies okay pretty cool okay on a warpath emo accelerated battle pass okay so show everyone you're ready for battle when you slam your bannadan signaling to enemies that you're ready for a fight this emo is only included in the accelerated battle pass that's why this will give you xp does it i don't know i don't know what does it do what's it do nothing it's gonna slam my banner down and show show the enemies that i'm ready to fight and i'm gonna buy the accelerated battle pass for that i'm not sure about that people i'm not sure about that people okay so compare battle passes uh three battle pass premium and accelerated obviously best value that's what they want you to uh so i don't want you to buy not that but what we got there i don't know people i hope it says the price of these as well so 20 smoldering ashes in all three 63 tiers on the premium track including armor transmog weapons skins emotes and more they are on the premium and the accelerated so uh is the cordial armor set for each class and base plus awoken versions rewarded mustan mines that is two the cordial boarding mal armor that is two get 20 tier skips doesn't really bother me i like to play and earn my shit on the warpath best value my ass premium is people i'm on premium i love the game i'll pay for a battle pass take my money okay so what do we have here frequently asked questions okay so how do i access the seasonal content do i need a battle pass to play once the season starts log on to the game create a new seasonal character and enjoy if you have not completed a companion yet you will need to complete it on one character to gain access to seasonal content the free battle pass is automatically available to all seasonal characters get the premium or accelerate battle pass to earn additional rewards okay so what happens to my character progression after the season ends okay so it's interesting the character and progress on that character is transferred to the eternal realm you can play this character whenever you want in the eternal realm specific season only features will no longer be accessible in the eternal realm for example at the end of season one malignant hearts will disappear and be unslotted from jewellery at the end of the season infested sockets will become normal sockets learn more here so let's click that let's click that malignant's runs rampant in the first season of the apple of thought okay so there's quite a bit of info here which i think we need to go through do we yes i think we do okay so let's actually go through the other questions first okay so how can i progress through the battle pass what is a favor your progress really i knew i knew a new favor was that shit your progress through the battle pass by earning favor you earn favor by just playing the game ex killing monsters completing campaigns and side quests or completing objectives in your season journey you can also progress through the battle pass by buying tier skips each cost 200 platinum no thanks what are small doing ashes is actually what i'm interested in small doing ashes is a currency used in the battle pass to earn specific bonuses known as season blessings for all the current season players earn small doing ashes by progressing the battle pass by collecting small doing ashes you can apply bonuses to your seasonal characters these bonuses last for the season and only apply to seasonal characters okay what are tier skips on my life no one asked that nobody asked that did anyone ask that tier skips are currently uh that were applied immediately to obtain 148 in the battle pass nobody asked that not like i pre-purchased the digital deluxe or ultimate edition which came with a battle pass how do i redeem it for season one if you pre-purchase a battle pass the battle pass button in the season section will be replaced by an option to activate either your premium or accelerated battle pass okay cool so back to that link which was this question right here the character and progress on that character is transferred to the eternal realm you can play this character whenever you want in the eternal realm specific season only features will no longer be accessible in the eternal realm for example at the end of season one malignant hearts will disappear and be unslotted from jewelry at the end of the season infested sockets will become normal learn more let's go okay so well met wonder corruption has been fallen sanctuary in the season of malignant the first season of the ablot 4 yes we know what this we know we get new aspects that's what we're good okay so that's the codex season of the malignant theme that's pretty cool i like to look at that a deviant form of lily sinister machinations is that what that says he sounds like that has given birth to a new threat malignant monsters these decaying abominations realm sanctuary in a frenzy mindlessly attacking anyone in range without hesitation wonderers will investigate the mysterious malay in the new questline with the help of colmord a former priest under cathedral light who also trains you to capture the malignant hearts fueling these foul beasts and convert them into a build all dream powers the malignancy that's taken hold of the burning house armies cannot remain unchecked you must sniff it out at the source before all of sanctuary becomes it's full okay so we've seen that transmute malignance into vengeance that's pretty why it's badass looking people okay so to keep up with the relentless animosity of malignant monsters you need to turn their hearts against them slain partly corrupted enemies a type of malignant monster will drop a malignant heart these can be captured by performing a ritual the cage of binding an item acquired during the season of well during the season's questline partly corrupted enemies are an unruly sort and won't go down easily trying to capture the heart will cause a partly corrupted enemy to be reborn as a fully corrupted enemy if defeated these amorganizations of rot will drop a version of the malignant heart that can be placed into special infested sockets in your jewelry in place of a normal gem that's cool the first season will introduce 32 malignant hearts across four categories that provide new unique bonuses as you encounter more medicine malignant creatures so too will the strength of their malignant hearts grow there's much more to share on the season's theme and we cannot wait to do so in the future okay cool one of the best places to acquire malignant hearts are in the new malignant tunnels highly replayable dungeons teaming with fearsome foals to eradicate skull this dank system of tunnels for the catalyst of malignant monsters and go toe to toe against varsha and the consumed the newest boss battle if you dare okay so how seasonal character works okay so we're seeing on the screen now okay so yes we can see all this we get all this we get all that people okay so we've seen the malignant beginning the 20th of july we wanted to take a moment to equip you with everything you need to know about seasons to participate in seasons a new character must be made on the seasonal realm you do not need to purchase a battle pass or add any add-ons to play the seasonal content but you must have completed the campaign on either the eternal or seasonal realm with at least one character once you have completed the campaign any seasonal character will start the game with the option to skip the campaign your map available immediately or previously discovered all to live unlocked and the corresponding renown for them or previously discovered areas on the map reviewed and a corresponding renown for them okay once the season has ended the character you made and its progression will be transferred to the eternal realm all items you collected into including your seasonal stash will be transferred to you can take this character into sanctuary and if you please but season specific features such as malignant hearts will no longer be accessible that makes sense our beliefs behind seasons seasons provide us with an opportunity to introduce innovative uh gameplay mechanics in sanctuary for a limited time because seasons reset we can create crazy fun season themes and their vacuum without needing to worry about balancing yeah it with the mechanics introduced in the past or future seasons we can start will be start from a strong eternal realm baseline and build on top of it seasons are also a place for players to explore in tinker we encourage you to try a new class or different builds for a class you've gone well grown fond of our seasons are a chance to get creative while demolishing demons additional seasons present an equal playing field our seasons are designed for new characters to conquer the nightmarish challenges brought by a season's theme and to progress through the seasonal journey together okay so earn rewards with the season journey and battle pass okay so cool so what we are seeing here okay so yes yes i would actually need to pause the video and take a quick look at this but i kind of get what we're seeing here i don't want to waste much more of your time this video has been going on long enough i'm not too sure about that okay so that's cool as you hunt down malignant monsters for their building enhancing hearts and partner with common to discover the source of the corruption your early wars from the season journey and battle pass the season journey is broken into chapters and tests to complete as you progress through the journey your every was befitting sanctuaries defender such as new legendary aspects a mastery title a scroll of amnesia which provides a free skill tree and power gone board reset so that's pretty cool don't question that bomb it's gonna well not too much the the skill tree but a power gone board reset i mean i do it man unslide if i hopefully this is one button to just reset the whole thing you gotta go through every single node man it's long the journey also provides favor to resource you to climb through the battle past years which is also a naturally by playing the game whether it be killing demons completing quests and more so here's a snippet of the actual battle pass pretty cool looking good looking like quite simple to be honest basic okay so the season malignant battle pass begins july 20th we know this and host 90 tears we know this 23 three tears and 463 premium tears okay so we know all this too we've read all about all that we know about all that we know about everything stop trying to make us purchase the the crazy editions but you ain't doing it we ain't doing it people no we're not and i think no it's not okay so a queer hellish new looks from the shop okay so yes that looks pretty cool i'm not gonna lie i'm not gonna lie we're dying up the heat for the shopping new equipment arm accessories yes i bet you are but yeah that does look cool and there we have it guys and that is it that is it and we've gone through the patch notes already i did that in a video which would have been posted earlier today but yes guys there we have it the season of the malignant is be honest people not long whatsoever and i cannot wait but there we have it guys everything you need to know about this new season for the ablo 4 guys if you enjoyed the video leave a like it really helps out if you like what you see want to see more be sure to subscribe and hopefully my b.o.t for people i will see you on that next one


this week on all hands magazine online witness the non-profit honor flight network bring veterans together to visit their service memorials in Washington DC as thanks for their dedication and sacrifice what we're gonna do is we're gonna ask carrot them off here down the side and off to the left hold them over here at the restroom area as we get them regrouped ready to go out to the buses honor flight is a volunteer opportunity to come here to the airport and salute meet and greet the veterans of all branches of the military and we escort them to the bus and we talk to them and they tell us some stories and we just basically support them and thank them for their service wonderful flight and they've treated us beautifully like kings and queens what do you look forward to a good time a good visit and to take pictures to bring home I live in an independent living place and they all were congratulating me for going and they've heard about the flight so and they have fun have fun I want to have fun I'm Rose Marie Philip I'm 88 years old God's been good to me I made it this year and I'm a World War two veteran I was in the US Navy as a way to watch honor flight in its entirety go to www.ah.mil and be sure to check back often as a new magazine content is uploaded frequently from the defense media activity I'm petty officer Amara Timberlake


This is a story about how following through with your gut feeling and intuition could save a life or prevent permanent regrets. If this is something you can relate to, please watch until the end. A colleague of ours shared how following and disregarding his intuition forever changed his life. Hi, Psych2Goers. Thanks for joining us today. Today, I want to try something new and give you guys both a listicle story and a personal story of a team member which will be at the end of the video. Please leave in the comments below on which one you related to more. Number 1. Childhood Bonding. Growing up with my grandparents and relatives during my father's business trips allowed me to form a deep and special bond with them. These interactions shaped my upbringing and self-development in profound ways. Number 2. The Gift of Intuition. Through spending extensive time with my loved ones, I developed a unique intuition or sixth sense. I could feel their emotions, mental state, and even their health, regardless of the distance between us. Number 3. Distress Energy. Whenever I felt sick or encountered issues, my grandmother would sense my distressed energy, even though my family had migrated to a different continent. Her intuitive connection prompted her to check on me, ensuring my well-being. Number 4. Dreams as Warning Signs. As I grew older, I started experiencing dreams that partially foresaw the future. These dreams became my warning signs, guiding me through life's uncertainties. Number 5. Preventing Grim Outcomes. In some instances, my dreams helped me prevent or delay certain grim outcomes by heeding the messages they conveyed. I was able to take necessary actions to change the course of events. Number 6. Notifying the Inevitable. However, there were times when my dreams simply notified me of the inevitable. Ignoring these messages only led to regret later on, emphasizing the importance of listening to my intuition. Number 7. Emotional Connection. Beyond predicting events, my intuitive connection allowed me to deeply understand and empathize with my loved ones. I could sense their emotions, providing comfort and support during challenging times. Number 8. Cherishing Moments. The gift of intuition taught me to cherish every moment with my loved ones. It reminded me of the fragility of life and the importance of expressing love and appreciation while we still have the chance. Number 9. Trusting the Intuition. Over time, I learned to trust my intuition and embrace its guidance. It became a powerful tool in navigating relationships, making decisions and finding my purpose in life. Number 10. A Lasting Legacy. The intuitive connection I share with my loved ones, even after their passing, continues to shape my life. Their presence lives on through the lessons they taught me and the bond we formed, reminding me of the power of love and connection. In conclusion, the intuitive connection I developed with my loved ones has been a profound and transformative experience. Through dreams and epiphanies, I have learned to trust my intuition, cherish moments, and navigate life's challenges with a deeper understanding of the connections that transcend time and distance. My grandmother was always the closest to me. We had a special bond, and honestly, I still feel that bond and miss her deeply. Before she passed away, I urged my father to go visit her or let me go because I could feel like she didn't have much time left. Father insisted he would go first, and I reluctantly agreed. Grandmother also knew. She insisted that at some point, I must come see her one more time, as if she knew she didn't have long to live. Then one day, I woke up in the middle of the night, feeling very sad. I called father to check the situation, and he informed me my grandma had already passed away. I only followed through my intuition halfway. I used it to assist my father in spending the last moments with her, yet my father denied me the opportunity to have much final needed moments with my grandmother. Now I will forever live with those regrets, wondering the what ifs. In retrospect, if someone doesn't intend on following their intuition completely, then they might as well not follow it at all. For me, it only deepened the pain and the regrets. Fast forward a few years, my other grandmother became afflicted with Alzheimer's, dementia, ischemic strokes. This time, I followed through with my intuition, again through messages I received during my REM sleep. I took time off and spent the last two years of her life with regular visits, so I could make peace with that. And now that my grandfather is dying, I will once again take that time off to be there during his last moments, however long we have. During our busy lives, we often forget what's really important to us and what our actual priorities are. But it's always important to identify them and follow through. Events and possessions, those come and go. But once our loved ones are gone, they are gone forever. If you've learned anything from this, please keep that in mind and make your choices accordingly. We must treasure the people we love while they're still around and learn from our experiences and trust our intuition and instincts so that we can do the best we can to avoid future regrets.  Get your very own Sai. The lovable plushie is here to brighten your days. It embodies the spirit of psych to go, and it serves as a reminder to prioritize your mental well being. Its green leaf symbolizes growth, renewal, and the importance of self care. Whether it's for yourself or as a thoughtful gift for a loved one, Sai is ready to be your snuggly friend through all of life's ups and downs. Buy your Sai plushie today, link is listed in the description box.


Microsoft released the SharePoint framework in early 2017 after initially introducing it to the world in concept at their May 2016 event. One set of questions I seem to keep going back to is explaining the what the SharePoint framework is and why did Microsoft create it. And I thought about it and I finally realized that there really isn't some definitive body of work that answers the most basic questions about the SharePoint framework. You know those questions, the ones that refer to as the 5Ws or sometimes the 5W in the 1H, is the classic what, why, when, how, where and who. Have you ever wanted to know how the SharePoint framework works? How do your components get added to the page? And what's with that extra manifest file? In this episode, I'm gonna answer all these questions. Hey, I'm Andrew Connell. In this piece of my series, it's gonna take a different direction than the rest of the other episodes. In the other episodes in the series, there have been much more of a high level look at things more from a decision maker perspective. I wrote them for developers and development market managers and I tried to stay out of like a lot of the detailed technical stuff. But in this episode, I wanna get my hands dirty and I wanna take you into the depths of the SharePoint framework. And while this episode is really for you, it may be more so for me. The points I'm gonna cover address questions that I answer over and over. And so with this episode, I can now point to a reference that I don't have anywhere else. So let's get started. The most important thing to know about the SharePoint framework is that it's a 100% client-side technology. And this means that it only runs in the browser. So when you build solutions, they're only client-side, they're not server-side. And with that being said, you can implement a scenario where your SharePoint framework components call server-side components that you've deployed, such as a REST API. But that the API doesn't have anything to do with your SharePoint framework component. And as I covered in my other episode on who and where can use the SharePoint framework, SharePoint has specific places that are carved out that you can use the SPFX to customize. These include web part zones, the top and bottom placeholder for extensions, field customizers and command sets for the different types of extensions. When a page is requested, SharePoint first creates the page source for the page and the structure of the page before sending it to the client. Some components are loaded asynchronously in the browser, such as parts of the suite bar that we have at the very top of Microsoft 365. But when it comes to the SharePoint framework, SharePoint first determines, are there any SPFX components that have been added to the requested page? And if so, SharePoint's gonna load the SPFX runtime on that page. Otherwise, it doesn't load it. So as I've said previously, SPFX is entirely client-side. And if there aren't any components on the page, it doesn't need to add the runtime to the page and add the unnecessary bloat of the payload in all those JavaScript libraries. So what happens when the SPFX runtime actually loads? Ah, now we get to the real business of this post. Let's start getting low level. Now, when I said that SharePoint detects that there's any SharePoint framework components on the requested page, it loads the runtime, right? But what does that really mean? The SPFX runtime is just a bunch of JavaScript when the page loads. It gets a list of all the components that should be on the page. And once it has that list, it needs to know everything about that component. Specifically, it needs to know about that component's dependencies, including the JavaScript bundle that represents that component. This information is spread across two manifest files, one that contains a list of all the components that are available in SharePoint. We'll call this the SPFX master manifest. And while the component has its own manifest that defines its own dependencies, I'm gonna call that the SPFX component manifest. So let's look at this first manifest file. The SPFX master manifest file contains a list of all the components that could be on the page. And this is a collection of all the components that are installed to the tenant app catalog and the current site collections app catalog. Think of this list as just an array of name value pairs. Each entry is for the SPFX component ID and it points to the URL of the component's manifest file. Think of it like the snippet that I'm showing you here. It's not real, but it basically conveys the concept that I'm trying to portray. The manifest acts like a directory for SharePoint framework. Once it has this list, it then moves on to the next step to get all the components on the page. Now that the SPFX runtime has a directory of everything it can be on the page, it then uses this list to figure out what to load. The SPFX runtime then starts working through all the components that should be on the page. It finds them in the directory and it uses the information it gets to load the dependencies for that component. This is where things start to get a little interesting. Let's take our custom web part, for example. Let's assume that our web part leverages the popular jQuery data tables plugin. Not only will the SPFX runtime need to load the data tables plugin library, but it also needs to load jQuery. Our web part in any other SPFX components that we may be using, such as the at Microsoft SP HTTP component and certainly the at Microsoft SP web part base packages. Many of the SPFX packages have already been added to your project when you ran the Yeoman SharePoint Generator. Now take a look at your package.json file and you're gonna see these things are listed out for your web part.  These are all needed by your component, but you also have additional components as well. You may have installed the jQuery data tables, jQuery library and the data tables plugin using the npm install command. So in that case, your package json might have those listed in there as well under the list of dependencies.  You know that you shouldn't be putting jQuery in the data tables plugin inside your resulting components bundle. You went to your projects config.json file to add these as external dependencies. This tells the SharePoint framework, the bundling process of the SharePoint framework, don't suck these files into the resulting bundle. Instead, you wanna tell the SharePoint framework to make sure that it downloads the jQuery and the data tables plugin libraries in a specific order before my web part is actually gonna be loaded. Pull them from a CDN. The order that these libraries are loaded on the page is absolutely critical. If your web part bundle is loaded before jQuery or the data tables plugin is added on the page, things are gonna break because there's assumption that they're already on the page. The SPFX bundling process takes this into account for you. The SPFX bundling process takes this into account for you. Now the SharePoint framework documentation, it addresses how the bundling process works, but most of it only focuses on the creation of a bundle. The other thing the bundling process does is it generates the SPFX component manifest file as well. Take a look. After you run the gulp task, gulp bundle, you're gonna see two files in your distribution folder. There's a JavaScript file that's the actual bundle of your project, and then there's the manifest.json file that's the components manifest. Within this file, you're gonna find this object called loader config. Now loader config contains three properties. It's got the entry module ID, which is the name of the JavaScript module that contains the main SPFX component. The internal module base URL, that's the base URL where any non-absolute URLs are listed in the manifest are gonna be located. So like in this example, they're all in localhost. And then also a script resources section. And that's a name value collection of all the libraries and all the components that the SharePoint framework components need to run. Now that last property, the script resources, that's the interesting one. This contains a list that's sorted in reverse order of everything that must be loaded for the component to work. So for my web part to work, the one that used the data tables jQuery library, it's gonna be listed here. Notice that the last few listed are components. These are the SPFX runtime out of the box components that you should already be on the page. But also notice how the bundle that contains our SharePoint framework web part is listed at the top. It comes after the data tables plugin, which comes after the jQuery library. So what the SPFX runtime is doing is it's using something called a module loader on the page to handle the process of loading all the necessary libraries. Let me talk a little bit about module loaders for a second because SharePoint framework, they change module loaders over time that it uses to load these different modules. Initially, the SharePoint framework was using the popular module loader system, system.js. But when they released the SharePoint framework 1.10, the release notes state that they were moving to another library called require.js, which is also very popular. This doesn't really matter to you. We don't really care about this. I mentioned them just in case you wanna go read up on how these things actually work. And you know what the SharePoint team is using. While Microsoft hasn't stated it, I expected only SharePoint online is gonna switch over to require.js, while SharePoint Server 2016 and SharePoint Server 2019 are gonna continue to use system.js because they're not making any changes to the SharePoint framework and on-prem deployments. Now, the module loader is smart enough to know that the dependency has already been loaded on the page from another components dependency tree.  But how are components added to the page? Once the components modules or the JavaScript files are loaded on the page, how is it then added to the page? When the SharePoint framework loads the final module, it creates an instance of the object that's defined in the property entry module ID. And it calls one of the expected methods that you can define. For instance, to add HTML to the page for a web part, you can implement the render method on the base web part class. The object your web parts class is derived from, called base client-side web part, it provides a property DOM element that's a reference to the div that SharePoint has added to the page where your component should go based on where the user specified it was loaded. Okay, so now that you understand how they get on the page, you might wonder how the hosted workbench and the debugging extensions are gonna be impacted by this. So let's first talk a little bit about the hosted workbench. When you navigate to the hosted workbench that's located at whatever your SharePoint site is slash underscore layout slash workbench.aspx, if you haven't spun up your local developer web server by running gulp serve, you get this dialogue message that says that the web part's not gonna appear in the toolbox. So make sure that gulp serve is running in a web part project. The reason you get this is because the workbench is asking for an additional manifest file. Not only does it get the manifest file from SharePoint to list everything that's available, but it also requests a manifest file from the local host colon 4321 slash temp slash manifest.js. And you can see that in the console when you're actually debugging your solution. This file contains the same manifest details that the SharePoint framework runtime gets in this SPFX master manifest, but only the components that you're developing in your project are listed in that manifest. So when you started the local workbench, the local development server using the gulp serve command, the SPFX workbench merges the collection of manifest that it receives from your web server and the one that the SharePoint framework has in their master manifest into one giant collection and it presents it to you in the toolbox, which is giving you the list of all the components that you can put on a page. Now, this is great for testing web parts, right? We see how that works, but what about extensions? Well, unfortunately, the SPFX hosted workbench can't debug extensions. To debug extensions, you need a real SharePoint page. And in the case of a field customizer or a command set, you actually need a real SharePoint list or a SharePoint library. But to test a component on a real SharePoint page, you've got to tell SharePoint that that's what you want to do. And this is done by using a specially crafted URL that includes parameters to tell SharePoint to do a couple of different things. It says, if the SharePoint framework isn't already loaded on the page, then load it on the page. Because if there was no SharePoint framework components already on the page, SharePoint wasn't going to add the extra payload of all the JavaScript for the SharePoint framework to the page and make you download it if it wasn't going to use it. It then also tells it says the SharePoint runtime should also load the manifest.js file from your local development server. And then it also says what component should load in anything that's unique about that specific component. Thankfully, SharePoint framework extension projects will create this URL for you based on the values that you set in the serve.json file. Now let's take a look at this URL. And I've broken it up to make it a little bit more readable here. You're gonna notice a few properties in the URL. Load SPFX equals true tells SharePoint to load the SharePoint framework runtime if it isn't already loaded on the page, which would be the case if the page you're using to test your extension has no other SPFX components on it. The property debug manifest file tells the SharePoint framework runtime where to load the manifest file from. That's my local machine. And then the custom actions property is a JSON object that URL encoded that contains the details about the component. So in this example that you're looking at, you can see that we are telling the SharePoint framework runtime to load the component that starts with the ID of FCA is listed in the debug manifest file on the page. Now, the remaining information is specific to the component. So like in this case, it tells the SharePoint framework that this is an application customizer and that it sets its public properties. And when it's a field customizer, it'll also contain the internal name of the field or the site column that the customizer should override for testing. And you'll notice this when you use the URL, you're presented with this warning that you see here. This is presented by SharePoint when the SharePoint framework is asked to load a manifest from an untrusted location, like local host, such as your local web server. Think about it. This would be a fantastic opportunity for a phishing attack to get some random script loaded in your corporate intranet because once it's loaded, it'll run under your context and thus have all the permissions that you have the user that's running it. Makes sense, right? Or not? If it doesn't, leave a comment. I definitely, I'll jump back and I'll respond to you and clear it up for you. So my goal in this episode was to answer the question of how does the SharePoint framework work? So by now you should have a really strong grasp on how the SharePoint framework works, how components are added to the page, and how you debug extensions on modern pages. Let me know what you thought of this video or if you've got any questions by leaving a comment down below this video. And if you liked this, please be sure to hit that big thumbs up button. And if you're new here, make sure you subscribe. Don't forget to check out the description below the video for links and resources that I mentioned throughout the video. Thanks for watching and I'll see you in the next video.