We will continue now with a talk by Philip Iwals from NFCore and he will introduce how, how do we plan to use right now DSL2, next flow DSL2 in the NFCore organization. So, stage is yours, Phil. Thank you very much. Thank you for the introduction and thanks for the excellent overview, Evan and Pardo. It's really nice to see you guys. I've seen that talk a few times now, but it gets more polished every time. So it's good to see, see a kind of the features becoming more and more stable. It's great. And so this talk was originally scheduled to be harshal. And so he's put the slides together originally, and then kind of both been working on it and he asked if I could, I could give a talk but it's going to be a bit more kind of hopefully a bit more interactive than some of the earlier talks in the week. So please jump in with questions as soon as you have them. Maybe you said they will like interrupt me if there's any good ones. And I'm going to try and pull harshal in for a bit of help every now and then we'll see how we go. And I'll start with a quick kind of introduction to what we've done so far and kind of what the perfect, what the current state of play is for NFCore modules. So let's see if I can share my screen. So, yeah, so like I say, most of these slides were made by harshal originally, and then I've kind of tapped my name on at the end that really well by him. A little bit of history. I think I first heard about DSL to in November 18 2018 at the next low kind of meetup, which was made to great fanfare and a lot of excitement. One of the main arguments against using next row from other other communities was the lack of this kind of feature so it's kind of been highly anticipated for a long time and when Paolo announced it, it was really, really well met. So that was a talk by Paolo and kind of a demo and then there was a blog post in May of last year by Paolo kind of explaining the main features and giving some code snippets and explaining how this was going to work. We of course were discussing this within the NFCore community like from day one about how we were going to work with this, what we should do, what we should aim to do and kind of what kind of features we can build around this new syntax. And the obvious route to go was to try and create a central repository of software tool wrappers which could be shared across different NFCore pipelines or any next row pipelines. So try and maximize code reuse. And so in July of last year we started a new repository called NFCore Modules to try and kind of spearhead this. There was very little code added to that pipeline so that repository for quite a long time. There were several GitHub issues created though to discuss approaches within the community and both there and on Slack there's been a highlight so far of this effort has been a massive amount of discussion. Because once you start to really get into the details of how to implement this thing at scale across large numbers of developers in a very stable reproducible way. There's a lot to consider. And it gets very complicated very quickly. So there's lots of discussion and then we had a hackathon earlier this year in London at the quick organized by Harshal. And there was really one of the first times that being some kind of little efforts at some of the earlier hackathons like it's I Life Lab. But really the one in London was the first time we made significant impact and actually started writing real code. A lot of people started writing different wrappers for new tools so we actually had more than just FASQC in the Modules repository. Started a repository to kind of play around with a DSL2 pipeline which we called DSL2 pipeline test. And kind of tried to work out how this would work in reality. And we also started, well I started building mostly some new continuous integration GitHub actions kind of automation to try and help some of this. And missing from here is that we also started building some of the NFCore tools software so the helper tools. We started adding some new features into that which would also help developers work with this new system. That kind of trundled on for a bit, had a bit of a quiet period and then a couple of weeks ago we sort of thought maybe we should try and get this in shape before this hackathon so we could work on it. So the last two weeks have been pretty frantic activity on the NFCore modules. Harshal's done a lot of work along with other members of the core team especially to start work on converting the current NFCore template which is like our kind of central golden kind of reference point. Converting that from DSL1 to DSL2 and that work is ongoing on the branch on the NFCore tools repository, going really well. Okay, so that's kind of how we got here. Now I'm going to go into a few of the discussions that we've had to talk about the approaches we've decided to take and why that is. So we do have a question from the audience already that is fitting to this slide. So we have had already a lot of development in DSL2 and a question is, is the DSL2 syntax considered stable enough right now to start using it in production? Excellent question. So we've had kind of competing pressures for modules in DSL2 since it was announced with NextFlow. Of course we want to stay relevant. We want to move quickly enough that we are not left behind by other people and that people who want to use DSL2 won't kind of give up on NFCore. And we also of course want to use all of the powerful features that come with NFCore. And as you quite rightly pointed out, DSL2 has not been considered stable yet. And NFCore pipelines are the first thing I say in every introduction talk is that they are portable and reproducible. So stability is critical before we actually push anything into production here. So there's a kind of a powerful balance there. Yeah, we are going to release next week. There you go. We are there. You heard it from the man himself. So exactly. So as of next week, there'll be a stable release of NextFlow. We're going to hold parallel to that. And then after that's there, then we can start using DSL2 for real. So we're nearly there. Any more questions before I move on? So this is partly the work of this week actually. There's been a lot of discussion on Slack for those who've been kind of following it. And it's also covered in one of these issues on NFCore module repository. We've started tying down some of the best practices that we're going to ask people to adhere to when writing process definition process wrappers. So, right, how shall I button here if I get any of this wrong? Module file should only define inputs and outputs. I don't completely remember what that means. Can you help me out? We initially, I think, are going to try and keep the process definitions as simple as possible in terms of parameter, providing parameters. And so ideally we'll try and follow the NextFlow model, which is what I've envisaged. This is still sort of up for discussion, but I think we're going with a simple approach. So NextFlow, by definition, requires inputs and outputs. Sometimes not inputs and sometimes not outputs, but I think you get the drift. And so what we're going to do is we're just going to, for any tool, for example, FastQC, you'd only be providing FastQ files to FastQC. And you'd be taking zip files or HTML files as output. We won't be providing any other parameters within the process definition. And the main reason for that is that if we want these wrappers to be flexible and for other people to be able to reuse them, they should be able to provide their own parameters when they're running these module files. And this, at the moment, seems to be the most flexible way of doing that. And so the other point on that slide, which says that all the other parameters can be provided by a parameter string, which can then be used by the tool. So this is kind of what we're thinking at the moment in order to take this bit forward. Also, so threads and other stuff, which you can use standard NextFlow variables like tasks.CPUs. If the tool supports multi-threading, then you can provide that as a parameter for the tool because it just makes it easier than having to do that. And it's quite standard anyway. But yeah, all other parameters ideally should come into the module via a string of some sort. Thanks. So, yeah, I guess my way of rephrasing that would be we don't have hard code specific options for any tool other than the mandatory arguments and everything else which is optional. So yeah, fast PC options or trimming distances or adapters or anything like that should be put into that single parameter, which will be just a generic string. And then of course the pipeline, which uses the module, then that pipeline can have whatever parameters it wants. So it can still have all the same customization that we currently have with NF call pipelines. It's just that the module wrapper itself should be cut minimal. And yeah, stuff like tasks.CPUs because that's hard coded from from NextFlow that's always a bit. But when it's not that we can check for that in the code. Okay, and then the final one is a simple one that we should call our processes by a name, which should be all uppercase. This is purely aesthetic. It just helps when you're reading a pipeline, it just makes it a bit easier to kind of know what's a process and what's a NextFlow function, et cetera, or a variable. And so that's purely stylistic that just makes life a little bit easier to read. Okay, so extra stuff that should be in that process. Currently, for those of you who have dug around within NF call pipelines, you'll have seen that we have one process which calls every single tool used in the pipeline with a version command and writes all of these to one file. Sorry, multiple files, but those files are then used to kind of grab the versions from the software and put them into a multi QC report for reporting at the end of the pipeline. And now we are kind of instead of having all of those version commands within a single process, we're asking that each process does the version call itself into a file. And we'd also like to use some batch rejectors to clean those those version strings up as much as possible so we have a minimal file with just a version number for that tool. And then we'll collect those outputs and again still report on them in the same way. It's just that that part of the version reporting is delegated within the process actually doing the job. Modules should be minimal. So this is kind of simple we just, you know, don't try to chain too many things together within a single module. It's fine to have lots of modules which change together, but each module should be absolutely minimal where possible. Ideally that means a single tool doing a single thing. The exception is when we need Unix pipes for really heavy lifting. For example, using sam tools here to convert some to cram or to bam, where it was just kind of a bit unrealistic or as a large time penalty for creating intermediate files. So it should be minimal with some exceptions. This helps with a lot of stuff. It helps with simplicity of the code. It helps with maintenance and it also helps with the software package packaging inside the Docker containers. Okay, last one is a bit of a just mentioned because it's a shift from what we're currently doing within NF call. So most NF call pipelines that work with genomics data. There is a params dot single ends.  We want to shift this partly so that we don't have to handle programs everywhere. So now we still want to have an explicit variable defining whether the data should be treated as single end or pair them. But that should be passed in in the channel as a value with the input channel alongside each set of data. This has some really big advantages. For example, you will now be able to mix paired end and single end processing within a single workflow run. And we'll also tie into sort of more fine grained inputs in the future. And it is possible to infer whether data is single end or not by looking at the input channel, for example, looking at how many different files are supplied, whether it's one or whether it's two. But almost as possible, I would advise from years of experience that typos are easy to make within glob expressions. And other things quite easy to accidentally run paired end data as single end. We used to do this years and years ago and we opted for that explicit program instead because it just saved us from a lot of pain. So we're going to stick with that. We're going to say no inference of single end must be an explicit variable, but it should be passed in with input channel. Thanks Phil. So we have a question about this light in the audience. So what about multiple processes in one module? For example, should it be one module per SAMtool sub command or all sub command in the same module? Yeah, I'll show you. I'll show you the live demo at the end of this and we kind of look at what modules are there already. It should be one module per sub command. So SAMtools has multiple sub kind of folders, as one for view, as one for index and so on and so on, to keep them minimal. So we can organize the directory structure so that there's just SAMtools and then we have all the subcodes there. That's no problem so that we keep things organized. Does that answer the question? I hope that answers the question Maxim, otherwise just ask again. And we also have a question from Steve. Are there any guidelines about users of custom scripts inside modules? Good question. I don't think we have any guidelines on this yet. There definitely will be plenty of cases where we want custom scripts and I don't see any problem with including them there at this point. Maybe. So I have been thinking about this. So at the moment, because we're still trying to find our feet, I think we will reserve NFCOR modules or it makes sense to reserve NFCOR modules just for existing software that's out there. And so at the moment, during this hackathon, actually, we're trying to reimplement the Chipsy pipeline and SARIC actually in DSL2. And so part of that is also to identify problems in porting to DSL2 and to actually write some of these guidelines as well. But at the moment what I'm doing is in the pipeline repository what I've put is a modules folder and within that I've got another subfolder called local and another one called NFCOR. So all the stuff coming from NFCOR modules will be in the NFCOR folder and anything that is more customized and things that I need to keep locally in order to get the pipeline running I'll put in local. So it would be best to keep them there for now until we find our feet with all of this is what I would probably suggest. Yeah, that was something I meant to cover in the introduction and I completely forgot the policies for that. So the NFCOR modules is for common tools which are possible for other people to use in other pipelines. So what I expect NFCOR pipelines to have a mixture of processes from the centralized repository and also processes which are specific to just that pipeline, which are in this local folder. And of course, pipelines can carry on using scripts in the bin directory and everything as they do currently. And so that's kind of expected to have a mixture of both of these. But yeah, I am sure that in the future we're going to come across really obvious use cases where we want custom scripts within NFCOR modules, but we will have to figure out how to do that when we get there. We haven't encountered that yet. We don't have any guidelines for that yet. We'll be learning experience. Your question also reminded me of another common question we get so I'll just preempt that and answer it myself before anyone beats me to it. There are some workflows that Paolo described. So with the SL2 we can have module wrappers around specific tools as processes and we can also have these sub workflows. And it's quite easy to foresee a future where it might make sense to kind of start a module to provide those in a central repository as well. And we're aware of that and we're ignoring it for now. Again, that's another one of like, we'll tackle that when that becomes an issue where we really want to do it. I very much expect that to be something that happens, but we haven't really thought about that yet. And I would very much recommend that pipelines themselves in the local pipeline or do set up mini workflows very often the moment NFCOR pipelines are littered with minus minus skip this minus minus skip that the workflow scapes will make that much, much more elegant to use. If you want to use just salmon in the RNA seed pipeline, you'll be able to do workflow salmon if you want to use high sat star, etc. So you can imagine having these sub workflows within each pipeline working very elegantly and then having the default workflow which changes those together. And so sub workflows. Yes, definitely in pipelines certainly and probably in the future in modules, but we don't know how yet. Any more questions. Software dependencies. This is something where those of you have followed the discussion and of course about modules might be a bit confused to see what's on the slide because we've changed our minds a few times. Currently NFCOR pipelines we recommend that pipeline has a single environment file with all of the different software requirements and the single Docker wrapper where possible. This is an early decision. And the main reason was that a lot of people were using NFCOR pipelines especially at the start we're using singularity. And basically if the pipeline had kind of 20 different containers you had to have 20 different singularity images and the file size started to get quite large. However, that in some cases cause is issues. And that means it's more difficult to install software if they require different versions of Python things like this. And so really as a developer especially it's much easier to work with a single process a single doc file per process with shared modules which we're talking about here this is just mandatory there's no other way to do it we have to have a single dog a file per process. So that kind of forces our hand. So essentially we thought about having about recommending that we use other publicly available Docker files, for example by containers is a big one that hopefully will be a talk by beyond about by containers later in the week. And we're still thinking about that. And but for now, because we still want supports for condo, we recommend that every process has its own environment file, which will hopefully be very small just be the channel declaration and maybe a single tool in there with a pin version. And also a dog file alongside that which again looks like all the same. And of course dog files we have at the moment we should very very minimal just take the environment and build a condo environment within a Docker image. And then we will build those Docker images ourselves and using within the pipelines. It's still some outstanding questions about how we're actually going to do this, especially with versioning. We would really like some ideas on how to solve solve the versioning issue with Docker Docker files within within the pipeline code. But this is how we're going to start off at least and we will explore other approaches later on but for now this is the easiest and the most stable way to do it. We've used Docker Hub so far for everything within NFCore but we're probably going to use Docker GitHub Docker repository going forward with NFCore modules. It allows us to have multiple different images Docker images within a single repository which is really nice the automation works well. And we're kind of centralizing everything into GitHub which just simplifies much of the management. So for example if you want a new pipeline one of us in the admins has to go and create a Docker Hub repository for you as if we're using GitHub directly for everything it's a bit more streamlined. Okay so environment and Docker file probably went into too much detail there sorry but that's how we're expecting it to work. Yeah explicitly pin the software versions in the condo file. And there's a lot of questions and a lot of discussion about how versioning of NFCore modules will work. I'm going to talk about this more I think on the next slide where we talk about how we're going to pull modules into the workflow but effectively what we want to have is on the NFCore modules repository the shared repository. We'll try and track the latest versions of those tools. So if a release comes out that will be updated on the NFCore modules repository. A new Docker image will be built with a new version and the new pipeline code will be automatically tested against it. And that will be committed as a new a new commit to the NFCore modules repo.  And everyone benefits and it also keeps this very strong link between modules and your pipeline. I'll talk a bit more in a second about the details of how that will work. Okay. We need to document what we're doing in NFCore modules so people know what's there and how to use it. This is slightly up for grabs but the suggestion so far is that we write a YAML file just a structured text file which sits with each module and kind of describes what the module does.  We're not doing anything with this yet but the intention is in the future that we can use this for automatic documentation. Maybe some kind of validation and testing and things like that you can imagine. So we're kind of pretty much stolen much of the syntax from Conda YAML files here and we just kind of set this out very early on as a template so that we collect this information from Word Go release. GitHub actions. So this is we used to use Travis now we're using GitHub actions for everything for continuous integration testing. Just like all NFCore pipelines, every module should have its own CI with a minimal test data set. This is one of the main reasons actually from the early stage why we wanted to use modules is that we have kind of end to end testing of pipelines but we really wanted module like unit testing of the specific steps within a pipeline. So we actually run each individual step by itself and ideally actually check the outputs. Mostly at the time moment we just run the pipeline make sure it doesn't crash and then have to manually bet that the inputs and outputs look right before releases. But now we want to actually check and validate the file from each plus each module as it runs. Just like other pipelines where we have a test data sets repository, we've decided very recently that we think the test data should be on the modules repository. Ideally, if you just need some first few files or something you should share in between different modules so we don't load it unnecessarily. Okay, so this is roughly what the NFCore modules repository looks like currently the directory structure. We have the kind of basic stuff like the read me and get her workflows, and then we have a directory called software. This used to be called tools, and then how she pointed out that I keep calling everything tools and then of course, and it was very confusing. So he renamed it to software. Within software, then we have the names of the main tools which we're supporting. So here we've got PWA, we've got first you see we've got Sam tools. And then you can see in some cases we have sub directories nested under there, which is what I described earlier. So the different samples commands, for example, and these can be nested arbitrarily. Then the kind of the leaf leaf folders the end of those folders we have what looks like kind of a mini next way workflow almost have a main file which just contains that one process. We have the metafile which describes everything going on there and we have a test action.yml file, which is used for CI. I'm not actually sure if that quite how that's used currently. I think that might be wrong. And there's also missing environment and Docker files here, but you get the general picture of it here. Each of those folders should also have a test directory, which will contain actual an actual next play workflow, as well as all the input and output test data, which will be used to validate that unit. Right, importing this is where I said I was going to come back to a bit more detail. So Phil, now that we go to the previous slide again so we do have a question from Maxime, and it is how can we specify the version of a given program within an NFCore module. I'm about to tell you. So versioning and importing are one and the same thing, basically, or at least we're very closely tied together. This is probably the single issue that's had the most discussion so far and but I'm pretty confident we're coming to a conclusion now. If you look at that issue thread that's very long. It's a lot of discussion there. And we've gone through a lot of different suggestions and we've even tested out several of these. So if you go and look at that old DSL to pipeline test repository, someone dug it out earlier we actually deleted it from NFCore but I forgot that I still had my personal fork floating around. It's outdated. Don't look at it anymore. But in the early days we tried using Git sub modules. This makes quite a lot of sense. You just say, okay, we've got the modules repository. I just want to use that here. And then I'll be able to access any of those module wrappers. The downside are that when you clone the repository you need to clone with sub modules get clone minus sub modules recursive initialization, which is kind of a hassle doesn't happen by default with Git needs extra flags. It's just kind of liable to cause issues. The other problem is that then you can't have a sub module for parts of a repository. So you have to pull the entire NFCore modules repository, which could get very large and could be a bit problematic. The nail in the coffin for this one is that you can only import that repository once. And so that means you have the NFCore modules repository at a single commit across all of those different software wrappers and they're all locked to the same version. And that's important because you might want to have different versions of different tools running and we'll do that by taking different versions of NFCore modules repository. Hopefully that makes sense. Another suggestion was to have a library of modules. It's kind of very attractive given the possibilities here and where we could post modules on an existing library infrastructure. The team that came up with MPM node package manager. And of course, condo, which is a lot of people are very familiar with. We even got as far as making a condo channel called NFCore, which is that currently empty. We're now ready to have these tool wrappers. And we have a branch on tools which has a working implementation of using condo. And so basically using condo works. The downside of using condo is that it's complex adds a lot of complexity into the automation and to the management of the modules. So we're looking into how we could use by a condo utils to kind of manage some of this and really it was going to turn into a kind of a massive job to really make sure all of this works. It's entirely possible we go down this, this road in the future. If things start getting really big and unmanageable by ourselves. And it does have some advantages but for now we've decided to kind of put that on the shelf and come back to it later if we need to. One of the main arguments for using condo is dependency management. But it's an important concept here to remember is you're pulling in flat files from NFCore modules into your pipeline. And you pull those in and chunks so they should never really be cross dependencies certainly as for someone for running your pipeline. The person running your pipeline just grabs out flat file repository and runs it all in one go. So dependency interconnectivity should be fairly complex unless we start getting very complex with sub workplace. Okay, so what we ended up with was basically a homebrew solution using NFCore tools, Python package. And on now merge into the dev branch which will soon be released in version 1.10 is kind of a skeleton early version of a new suite of commands called NFCore modules. And I'm going to just quickly demo that. So hopefully you can all see my content. I'm just in an empty directory called demo. If I make a new, a new pipeline with NFCore create. I can just call it demo, demo pipeline. What this does is it takes the NFCore kind of template and just builds me a skeleton workflow to start from scratch. You can see it's made a folder here called NFCore demo. And if I look in here, I've got my main main.nf and my next row config and everything. This is a DSL one pipeline, but currently got that work going on I described with converting his template to DSL two. So what I can do now is also start to play around with these. But do NFCore minus minus help you'll see I have a new command here modules, which is not being heard before. And if I do NFCore modules help you see it comes with the same sub commands. And these three don't do anything yet. They'll just tell you it's not yet implemented, but these two do work to some degree. So as the two ones do they fetch the available modules, the NFCore modules repository and list them. And this one installs one of those into your pipeline, which basically just means it copies the relevant files. So if I do NFCore modules list. We will hopefully get a nice list. There we go. We have a different available tools. We've got Bowtie, we've got the Sam tools, different wrappers here, we've got FastQC and so on. I've got my pipeline here remember if I do NFCore modules install, I give it my pipeline directory and I say I want to install FastQC. I will check that it's a pipeline folder that I gave it or check that FastQC exists in NFCore modules repository. And if I go into here, I can do get status and you can see I've got a new folder here. It's just not been seen before. If I look in this folder, you can see it's copied all of the files for this wrapper. And so then I could use those within my pipeline. I've just import from module software FastQC. And this probably will need fiddling with a bit. I just realized that Hartrell said he had these tools within an NFCore subfolder. So I need to add that. But you can see the concept here. This Python script is very simple. It's just looking what's available on the GitHub repository and then copying those files and avoiding the test folders and stuff like that. What will come in and is more validation to check that will make sure that when you push changes to your pipeline that you haven't changed these files at all. You should match exactly to NFCore modules. If you want to change something, you should do it on the NFCore modules repository. And also to like update them and make sure that they're locked against specific git hashes of the NFCore modules repository. So eventually coming back to your question maximum about versioning tools. On NFCore modules, you'll have a history for each tool. So we'll start when it's first added that will have its own version with a commit hash of a code and of a Docker image. If it's updated, you'll have new commit hashes for that tool and new Docker images for that version. So we recommend always that you always just update all of your modules and just have them all of the latest commit of NFCore modules, which will then also have the latest versions of those software. But if for whatever reason you want to have a specific earlier version, you just pin that git hash for that wrapper and then you'll have that software version and that version of the tool. So it means that when you make your pipeline, you can be sure and confident that stays stable. It doesn't matter if people start updating NFCore modules. Firstly, you've copied those files out of NFCore modules that are contained within your pipeline and stable. And secondly, they're tied to a specific hash of the NFCore modules repository. Okay, any questions before I move on. Maybe put everyone to sleep or everyone's got a headache. Right, I'll move on. I think we're nearly at the end. Yeah, okay, so this is the end of it. Yeah, that is the end now. Okay. Cool, right. Haasual, did I miss anything? No, I think that's about where we are with DSL2 at the moment. If people do want to get involved, we're having a bit of a sprint at the moment, like I said, on Slack in the Hackathon channel for DSL2. So get involved. And yeah, thank you for listening. So thank you everybody. So now we can have a discussion question. There were a couple of questions that I didn't ask yet because they were not directly related to the slides, but you have now the chance of asking them yourself to any of the speakers today. So raise your hand here in Zoom if you have some questions, please. Do you think you could repeat the questions that I guess, Anna, which are written in the chat? Because there's a couple sat there at the moment. Yes, I can also repeat the questions. So a question to Paolo. Are there optional and or named inputs for modularized processes, like for outputs with emit, let's say I create a process for my tool, which has dozens of parameters, a lot of them optional. It could be nice if I could just call mine. Yeah, it's it's difficult to read because there's a bit of coding between the lines. So if that person could speak up themselves here or raise their hands, I can unmute them. They can probably ask themselves better. Yes, this is an open problem. Some ideas, but it's not going to be available in the coming release next week. But yes, this is something that need to be, need to be something next to have a better handling for optional input output. So not next week, but hopefully soon. Okay, perfect. I hope that this answers your questions. We had also another question before. I was wondering how difficult it would be to have multiple pipe connected script blocks per process task. Yeah, I think I'm going to go on that one. So the idea would here would be imagine that you had several processes that you wanted or several process definitions that you wanted to run at once. So at the moment, each next load task is submitted out to the infrastructure that you need to send it on. So for example, if you're going to send it out, who would each go on to a virtual machine on AWS batch or a node in your cluster. The idea would be that if you could link two of these files together, two of these processes together automatically, you would no longer need to transfer the output files to the input of the next process. There's some ideas on doing this. In some ways it would break cool could potentially break the pipeline across different infrastructure, because if you were doing this if that could only happen on some infrastructure. It would break some pipelines. So also other ways of having be able to imagine being able to stream the data from one process to another. And these are all open ideas as well and things that we will be working on, because as the, as the person asked the question, I said this would make things much faster. You wouldn't have to have intermediate files, you wouldn't have to necessarily write to disk. And you could really speed up a lot of the execution time. So it's a very good point, but something that we'll be working on for the next little bit. Okay, perfect. Thanks, Evan. We have another question from Rad. Any chance of using version tags as well as commit hashes for modules? Yeah, I can take that. It's not the first person to ask, it's come up quite a few times. We've thought about this and it's, it might happen. We have the software version tags in the environment file. And so we do have that available. The downside is, if someone wants to add some more functionality to the wrapper code itself, not leave the tool version unchanged, the change the process wrapper, then that process wrapper needs to have its own version as well. So then you're maintaining the software version, wrapper version and the Docker version. And I kind of felt that this was very complicated. So my gut feeling is that in the end, we're going to have a single identifier, which is going to be the git hash. That contains everything. It contains a wrapper. It contains a software container version contains everything. Whether we add some kind of helper functionality, which finds a software version and converts that into a git hash at a later date, that might be possible. But it's not going to be there straight away. For now, just use the git hash. I'm hoping to be honest, I would like to try and push everyone to use the latest version of all tools for the time. So really, I'm hoping that all this question of versioning is going to be a little bit mute because you'll just run NFCore modules update all and it will just update all your modules to the latest version. And you check it works and then, you know, one happy but of course there will be some circumstances where you're forced to use older versions of software and we need to make that possible. Perfect. Thank you, Phil. There is a similar question from Maxime. Could there be named inputs for processes as there is also now as also now named outputs exist? Maybe that's more a question for Evan or Paolo. Yeah, I think it's for Paolo there. Yeah, I fear that's for me. No, at least I think that we're confused even more. It's already quite start to be complicated. Maybe the syntax, I fear that that will open the possibility to have too many options. I don't know. So short question, I would say no. Long question. Maxime says, okay. Any more questions from our audience today. So Rad is commenting, I would argue against latest in favor of explicit versions and a way to have both version and hash similar to how you have tag and digest for Docker images. Yeah, exactly. I think we're agreeing. A Docker tag resolves against a digest. At the end of the day you always have a specific hash and it will be the same for NFCore modules. At the end of the day you will always have a specific hash and we might add kind of nice front functionality to make that easier to use in the future. But first we're going to start with the hash and go from there. I want to add a bit more about now optional and name it input parameter because this is actually is related to optional input. Now, because if you allow people to have a process in which the input are specified, not with the position but with the name, you can specify one. Imagine that you have a process with many inputs. And you specify just one with the name and then you omit the other. So maybe if we have a good way to specify the default value for and then and therefore the optional value for some inputs we could have also a way to manage name and parameter because they are linked to. So maybe in the future. Would a map go anywhere towards solving that? Yeah, the map is doing that the problem is that what is the value for something that you don't specify. Now we don't have no. We should also way to specify default value for a process input, but then we can be weird because I'm not sure that they have much sense. In the fall from now the full value you can have some specific cases but that is more an optional input my opinion. You should specify a default value for each input. Otherwise, when you specify, when you invoke the process each time you have specified the name and actual value the name that makes very verbose the composition of the pipeline I think. Or could the default value be initialized as false or not or something and unless. Can you repeat sorry. Could the default value for any given input be null or false or something unless it's overwritten being provided to the person. Yeah. A default to zero to say. I don't know. I think that will open. Create more confusion. A couple of people have chimed in on the chat here and I was thinking the same thing, we could potentially try and steal how Python does this. I guess other languages as well. But if no name is given you can just use the order of arguments and if names are specified and then use those. Maybe this is getting a bit in depth for this for this form. Yeah, we can take this on slack. Yeah, that could be an option, even though not sure how much will improve the experience with the language. It seems to implement this then is a big a big work so I prefer to focus on other stuff. Sorry, there's just hop on a question here about from Steve about how DSL to works with params. And whether basically will lose the ability to use params to kind of customize the way that script blocks run and things like that. Yeah, basically, the model in every the parents from the cooling model. So you can use params as any other script. The model received all the parents that are in the invoking script. But you can still override if you need when you invoke when you make the inclusion. There are some example in the documentation. And we will be making use of this quite a bit in NFC modules as we saw in my talk earlier. If you remember said params dot module name arguments. So we're using a regular prams there to to customize the script block already just in a kind of standardized way. And so, yeah, prams will continue to be a core feature of pipelines even with the SLP. All right, there seems not to be any more questions. So if there are no further questions I'd like to thank everybody who contributed to the session. It was very interesting to have this discussion and if people would like to contribute to us porting all our NFC pipelines to the SLP to join us now join us for the rest of the week. And yeah, this way you can make an impact on NFC.


You can plough it from around that couch over there with a warm-up shirt on it, man. Well, listen to all of you.  Nice thing. Otherwise, we'd be doing it over on that couch with a left-wing warm-up lying out on that couch. And it would be a mess. And it would be a mess. All of you here, though, I just wanted to say thank you for the way you worked together with him. I was fearful that something was going to come down here and it was going to have to do to it. It was about 60 seconds. Momentary delay. Sorry. This is a big phone. You better get it. When you were behind us, you gave us the lever before. Not out of the field. We gave it when we were working. Well, come in now, so I can't tell the story. All right. All right. All right, there you go. It takes one person to do it before it ends. Senator Warren said none. Y'all were getting together there. You could come in the last few minutes. I think you started getting some auspicious occasion. Congratulations. Good luck to you in the next couple of days. You did a wonderful job. We're behind you. I meant that. We're trying to get started. The Congressional House says, they have regarded them as an implicit quality to the Congress. They began a program allowing the modern descendants of the American town meetings to use the presidential libraries as a way to conclude their national conferences. Now Wilson started the first of those, and even this year, although the program has moved to other locations, it continues locating the archives truly public institutions. So in this year, We have great reason because of the bicentennial of the Constitution to reflect on our character. We have every reason to welcome this appointment on account of the well-being of Mr. D. S. Three years ago, on November the 8th of 1984, a very special ceremony occurred in this great dependent. It was a joyous celebration marking the enactment of the National Archives of Independence. The legislation marked the culmination of the dream of more than two decades to make the National Archives of the Independent Agency of the United States. Many thought it impossible. It was not a new incident that our solos from that day chose the same purpose as one of the great cultural institutions of the United States This first appointment with the law is a greatest significance because it will involve all of you at this moment. If I could just interject a word to all of you who work in this building, I want you to know that I have special funds for this place. You see behind me is the Constitution 200 years old. Mr. Wilson is more than qualified as you go into design books both by academic background and years of experience. He holds a doctorate in American history. He served as a historian and deputy director of the Eisenhower Library in LA. He has held the post associate director of the State Historian Society in Wisconsin. Since 1981, Mr. Wilson served as the director of the Gerald Ford and Wolverian years before the National Archives of the United States. He has said that he would like the archives to grow over the national cultural resources as pressured in the Smithsonian Library of Congress. And he has stated, here I quote, Many of us recognize that the archives could serve a larger audience, a history-minded public excited about the country's past. With that in mind, I'm conscious of the documents that are with us in this room. I'm going to read some articles from the Federation. The men inside the independence hall are working. Just a few years before, money and risen property and life itself were signing the Declaration of Independence. That very document. Now they face a certain question. Had they and their countrymen over-reached it? Could this wrong new republic survive like its face does? And survive producing the Constitution of the United States? That very document. Now a two-century Soviet revolution. Now it is 1860, with the shoulders of all men. Money and considering requires more management. It is now an oppressive. Like the men of 1787, like Lincoln and Lincoln. I, Don Wilson, will solemnly swear that I will support the movement of the Constitution of the United States. I will support the movement of the Constitution of the United States. Against all enemies for domestic. Against all enemies of armed domestic. But I will bear true faith and allegiance to the same. And I will bear true faith and allegiance to the same. And I take this obligation freely. And I take this obligation freely. Without any mental reservation or purpose of evasion. Without any mental reservation or purpose of evasion. And that I will well and faithfully discharge. That I will well and faithfully discharge. The duties of the office. No more John Legend. The duties of the office, which I'm about to enter, so help me God.


Hey everyone, this is Mike Kramer of Mock Capital. Today is Monday, November 27th. It's around 7 p.m. New York time. So today we'll be taking a look at some currencies and dollar pairs.  And then of course, we'll have J-PAL talking on Friday in a fireside chat. And you know, while it's important to remember that it may be the case that the Fed is getting closer to the end of its rate-hiking cycle, there are many other central banks that are already at the end of their rate-hiking cycle. And so we have to remember that all this stuff is always relative to how other parts of the world is functioning. And if, you know, the Fed may be getting close to the end of the rate-hiking cycle, but perhaps it is that the ECB is already done. And the market's gonna start thinking about, you know, the rate-cutting cycle that's likely to come some months down the road. And that may impact, you know, how currencies respond as the economic data continues to come in. Now, the big question is, is the dollar done rising? Is it gonna move lower now? Or is this the start of something bigger to the upside? I mean, certainly when we look at the dollar, we can see or it looks like there's a falling wedge pattern that's formed. More recently, we can also see that looking at the dollar on the daily charts, it is certainly at the very low end of what would be considered to be nearing oversold on the RSI. We'll look at it more on a shorter term basis. We can see that it's at this important level of resistance around 10310, which is a level that if we go back and look dates to this low back here, back on August 31st earlier this year. But what's also important that stands out here, is that again, if we take a look at this chart more longer term, and we were to draw it from, you know, a Fibonacci retracement level from bottom to top, we would see that to this point, we've retraced about 50% of the total move higher. So this is still sort of in that range of normal retracement level in terms of where the dollar is. And it doesn't really signal that the dollar is due for a significant collapse or that the dollar is due for a rebound. But again, what this is telling us is that right now, it would seem more likely than not that the dollar may be in a retracement period, rather than a period of complete breakdown and a move lower that would undercut the lows that we saw back in the middle of July. What's also important here is that if we were to break resistance around this 103 and a half level, it's likely to trigger a move higher in the dollar back to 10410 and potentially 10450 on the DXY. When we move over to the Euro versus the dollar, you can see the last time we spoke, we were talking about the Euro being at significant resistance around the 61.8% retracement level. That's pretty much where we are again as of right now. So again, this sort of goes with the idea that the dollar really isn't showing signs of completely breaking down at this point, but really more showing signs of what appears to be a retracement of an initial move lower in the Euro versus the dollar. And so again, we need to remember that for reasons why the dollar can continue to outperform, is especially if the ECB is done raising rates and their economy in Europe begins to show some signs of weakness, while the US economy still continues to do fairly well, this could actually result in the dollar continuing to strengthen further against the Euro. So until we really start seeing the Euro move beyond the 61.8% retracement level, call it around this 109.5 area, it's really hard to say that there's been a meaningful shift in the Euro. Again, what I would be looking for is a move above this level and then looking for the next level of resistance around 11050, while if this level continues to hold, it would set up a decline back to this 108.5 level with the potential for a break sending the Euro all the way back to 107. When we look at the same thing and the pound, the pound has actually continued to rally a little bit more since the last time we talked about it. We can see the pound is just about at a 50% retracement level. When we look at the pound, it almost looks like what the dollar index looks like, which has a falling wedge. The pound almost appears to have a rising wedge, which would be an indication that the pound is actually likely to move lower and potentially back to support around this 125.30 area. Again, while the next level of resistance for the pound probably wouldn't come until about 127.30, which would be the 61.8% retrace level. So right now we're at a resistance level, which marks around the 50% retracement level at this 126.35. The technical pattern would suggest a move lower in the pound with a dollar strengthening. Again, if you were to see the British economy show signs of struggling or slowing while the US economy remains strong, regardless of what the central banks may or may not be doing, it's going to be on a relative basis in terms of what the economic strength of these economies are and the likelihood of one central bank potentially continuing to hike or another central bank continuing even begin to cut. Now when we switch over to Japan, it's a little bit of a different story because the BOJ really hasn't done anything yet. And that's sort of the difference between what's happening in Japan and what's happening in the UK and the ECB and of course here in the US, because again, the Fed, the ECB and the BOE have all hiked rates aggressively. The BOJ has done nothing yet and that has led to this big weakening in the yen versus the dollar. And what it almost looks like is happening now is that the market is beginning to show some signs of a shift in terms of where the yen is going to be going, almost as if it's beginning to show signs of turning and showing signs of this moving down, which would be a sign of a yen that's strengthening versus a dollar. Now the reason why that would be again is because the BOJ hasn't hiked at all and all they've done is allow the 10-year rate to float a little bit higher up to approaching the 1% barrier. And really what this means is that the BOJ were to come out in December and begin to raise rates, that would likely result in rates across the whole curve moving higher and that would also likely result in the dollar weakening against the yen. Now this would probably result in the yen moving down to 145 or so, but we need to remember that the market is going to begin anticipating a BOJ rate hike campaign and that may already be starting to happen with the yen strengthening versus the dollar and beginning to show signs of what could be an impulsive move down, which could set up a decline back to this, like I said, 145 level, while if support were to hold at this 148.5 region, the upside is probably pretty limited right now to around 151.5. I think it's more likely than not, though, that of the ones that are of the currencies likely to really strengthen against the dollar, I think the yen is the one that's likely to see that. And I would be looking for a move, a further decline in the end, potentially heading towards this 145 area, at least over the very near term. And that's really where we are right now. I hope you have a great rest of your week and we'll be talking to you again soon, hopefully. Bye.


Hi, I'm Kalina Arvachieva and I'm a researcher at the European Trade Union Institute. For us, beyond growth means moving away from the paradigm of economic growth as a central objective of our economies and as a main indicator of their success. It means focusing instead on well-being, on social justice and equality and on participation, which is some of the main things that we are the ETI concerned with in the context of the world of work. As the organizations representing working people, trade unions have a key role to play in the post-growth movement. They are well placed, for example, to understand and to address the concerns of workers on the ground, but also to involve workers in the development of a post-growth vision that works for them. As a social movement that has been a powerful agent for social change, they can also generate worker support and political momentum behind making this vision a practical reality. Hello, I'm Kathie Wiese, I'm leading our economic transition team of the European Environmental Bureau. We are a large network of environmental organizations based in Brussels and within the economic transition team we try to change the economic system in a way to make it more sustainable from an environmental but also from a social justice perspective. We always think about the economic system as something unchangeable and fixed, but it doesn't really help to me the way the rules and social norms and stories shape our economic system where designed by people and that can also change for people. Care should be organized in a non-patriarchal and more democratic way, so that also means distributing unpaid and paid care-working activities more equally in our societies. And to just give you an example, FIDER-OF is actually quite a popular proposal to decouple work from growth, but from an economic perspective it wouldn't really change so much because care is actually a daily activity, so for people who are caring responsibilities a reduction of daily working hours would benefit them more than a day off. And that's for me, that's why it's so important to integrate families' ideas into our visions and policies so that we ensure a truly sustainable and socially just alternative response. My name is Kempers Vardak, I'm a Dutch member of the European Parliament for the Greens EFA Group and I mainly work on digitization and the impact it has on both our society and the environment. The digital world is still very much based on an extractive vision of our society. We're extracting raw materials from the ground to make sure we can build data centers. We're extracting knowledge from people to add into those data centers and then on top of that we use those data centers to further extract the already existing knowledge that is on the internet and use it often without our consent, without any regard for privacy of people to make money. And also that's the only goal. I imagine that we have a world where it's not only just a few big players that are in power that decide what you and I get to see online or that decide how we look at health or at education based on data, on metrics. No, actually everyone should have a say. Everyone should be able to decide what happens with their data, how the internet is organized and also to what extent we digitize. Hello, I'm Dirk Hollermanns, I'm Co-President of the Green European Foundation and I'm working on the future of the ecological welfare state and of course we already have a welfare state but this rests on an attractive economy, exploiting people in the global south and also destroying nature. So the challenge is to build a new what you could call well-being state that provides a good life for all while respecting the plenty boundaries. We have an enormous gap between the rich and the poor so we really need to tax reform and have actually you could say we cannot afford as the rich so we have to have a wealth tax and this gives of course the money to pay for a decent living for everyone and I think a quite interesting proposal for instance is a care income so people that want to take care of the neighborhood want to take care of their family that we provide them with a care income so they're not dependent on the markets to have some buying power. AFIG at the moment is focusing on post-growth and we just created a platform, the Beyond Growth platform with a group of 15 young people that are working on the topic and we're trying to push the political agenda especially our Green Family agenda to focus on post-growth and to understand how post-growth can be an alternative from the capitalist and society of an economic system based merely on growth to an alternative economic system that is instead based on people, based on environment, based on care. We need to work with the younger generation because this is their present and this will be their future and structuring an economic system that is for them and for the survival of us on this planet is the best and the most important thing we can do and we cannot do for them but we must do it with them.


Where was I before MIC? Drowning in mediocrity. I mean looking for good substance. I was looking for people to relate to. Just the average guy that's trying to learn how to trade and I found Ballin Alex. Before MIC I kind of bounced around from chat room to chat room and never really was able to make money. Before MIC oh man I was shooting in the dark. But until I found Alex and Ball their trading style kind of fit what I wanted to do. I was trading in other chat rooms you know struggling trader. I got in it in 2015 and just struggling really to be honest with you. MIC it helped me on the path definitely because I didn't know trading at all and so I learned all the strategies all the techniques everything about trading. As a community from the outside looking in it's fantastic and it just gets you pumped and why wouldn't somebody want to be part of that. MIC has cut through a lot of the mist a lot of the it simplified it for me really. About Alex Tosh do a great job about teaching the lines teaching different fundamentals technicals. You have this awesome awesome videos and able to talk on the phone with them day-to-day. Every time I hit an obstacle that I was stuck on they would help me with it. Yeah now I'm not shooting in the dark anymore. I have a consistent edge that I've been able to develop that works for me. It's kind of simplified my profit my process modern rocks you know the lines that he kind of suggests is what's kind of really helped me out and just kind of trading off of support and resistance. Well I joined MIC about a month ago and I watched almost all videos and I can say that it's much different from the chat rooms I was in before. MIC is a group of all aspiring traders both successful and unsuccessful that they really bring a lot of the training, technicals, fundamentals and they ultimately want to help each other out. The moderators and the head moderators and like big time traders from MIC are available for calls and for answering questions. I think this is the big advantage of being an MIC. It is incredible how quickly the money adds up if you just keep on doing the right things. MIC has helped me out a lot. I watch Vows videos about how to scout and go from line to line. MIC is very motivational and it's a community where they teach you that it's 95% mental and to work through all the obstacles and in listening to Bell and everything he's so transparent on everything that's positive and eliminating all the negativity. Everybody are so helpful. Everybody are trying to help you if you have a question they'll answer right away. I would tell you to join MIC. They've helped me out tremendously. They've actually given me specifics of how to trade. Learn from the best man, learn from everyone the whole community. We all got things to share. Everyone's in it together and we all want to see everyone succeed. Be very patient. Take your time. Learn the process. MIC is a great community that provides an interactive environment for not just the newer trader but traders of all levels that can learn and grow together. I would say that the most the most important thing is to be exposed to different ideas from different people, different big traders and to seek to create your own process and your own system out of this. It's a journey. It is a journey. It is not a quick fix. It's a journey. You're gonna get out of it what you put into it. You just keep trying and keep working hard and you'll figure it out eventually. It'll click for you. To join MIC because they're gonna get so much back from it. They're gonna benefit from the watch list and the community and everybody wants to help each other and rise up and so you don't get that with other club. With MIC you have the whole group rooting for you. I'm guilty of being part of every other service out there over the years. I've been trading almost four years. I've tried them all because every single one of them holds just that something back that keeps you coming back. MIC gives it to you right out of the gate. Don't give up. Just keep keep at it. It takes time, you know, over 10,000 hours to actually become a master so it just takes time and you'll eventually get there. MIC is definitely a great pathway because the community, everyone's there to help you and everyone is there to learn. It's a great environment because everyone's there to teach you. My advice is to find somebody that is their trading style, something that they can go with. Alex and Val, they have the simplicity. The first thing that I learn and I know I probably, you probably just asked this question, was cleaner the chart the better and that helps a lot. Hey traders, this is Tosh. I go by T Bradley 90 in the My Investing Club chat. Just wanted to reach out and say if you have any questions about MIC, joining MIC, maybe you're a member already. You have three ways to contact myself personally and through MIC. You can hit our social media. You can hit me through PMs in chat or you can contact us through my email at Tosh at myinvestingclub.com. That's T-O-S-H at myinvestingclub.com. I will get back to you in a timely manner and I'm saying this because I'm here to help and I don't want anybody to be afraid to reach out and ask any question that they have. We are here for you guys. Alright, see you guys.


Bismillahir Rahmanir Raheem ladies and gentlemen. Today we are talking about the statement of profit and loss account and other comprehensive income based on the question which we have discussed earlier. Now do remember one thing, name of the company should appear, the name of the statement should also appear and for the period it covers it should be appear and the fourth thing is the figures are rounded 2000. They are not up to last rupee in thousands. Revenue 22, 229,000 plus 8,800. How this 8,800 comes up? You know that 300 per month that you have taken for services charges, if you multiply it by 4, it becomes 1200. That means 1.2 million, okay? And it has passed for a year. So out of that 4 million will come into your income this year. So the rest you have 12. If you look at the next 4 years, you have to take that for current revenue and the rest will be called long term Deferred Revenue. So in this case, the 10 million you have taken out 12, the remaining 88 is the revenue of the service charges, its cost is revenue. So in this case, you have added that 8,800. In sales, you will see that the figure of depression will come in a total depression of 3 assets, building and plant and office furniture. When you add up all these figures, then your cost of sales will come. You have taken out gross profit, then as administrative expense adjusted for issue costs, remember that the issue of loan cost of a million was added to the trial balance. We have taken it out from there, and we have to minus this to the balance sheet for the cost of loan. Marketing expenses, financial charges and profit before tax. Let us look at the taxation. Current tax, because I told you that your taxable income will be 20 million this year, so that is 35 percent, and the different tax has a timing difference of 10 million, that is 35 percent. This rate changes almost every year, but in Pakistan, it is 35 percent and now it is 29 percent. Profit after tax, then other comprehensive income that is 1400 and gain on revaluation 2000, so your total comprehensive income for the year is 32700. Remember one thing here, as I said that these other comprehensive income, this statement can be prepared separately also, and then we take added here, we just put here one figure, there may be more than one figure, they are here too, so I just put it together. Now, statement of change in equity, there is nothing much in it, in fact if you look the opening balance previous year and then share capital, there is no revaluation previously, then retained earnings total and then total comprehensive income and there is a revaluation. So, simply balance at 30th June 2020 is 100 million, 2 million, 49 and the total is 151. This is equity. Now, in the balance sheet, we put all these heads, share capital, revaluation reserve, retained earnings and the total comes to the equity that is 151.205.


All right guys just a quick video and I was talking about you know if you guys are a bit sadistic you can watch Five-minute traders getting slaughtered here, and this is a nice capture pain belief Type trade you can see in five minutes. You can see basically it's it's drawn traders into the to the to the short side All right, so immediately it would have either taken out all the stops below looks like and then it's basically You know shot up to the to the high side price to pull back a little bit and then drawn in more traders So a lot of traders would be up here at the moment looking at You know getting in long And then all of a sudden Look at that scary candle a lot of thoughts would have put it been below There it was looking to trade the FMC bit of dovishness whatever it is and then you know They've moved and removed their stop loss if prices come up to here Yeah prices come up to here. What do you think the first thing they're going to try and do get out for break even so This is the capture pay phase. This is the pain phase. You're seeing it in real time And it happens on all time frames by the way, but you know this is you know This is just it's what I just can't trade the news or anything like that You know, I just wait for it to come out look at the long term This all this stuff is less likely to happen to you on higher time frame charts So, yeah, these guys You know moving removing their stop losses possibly adding into losing positions And now all of a sudden the pain the pain the pain they're seeing They're I guess they're they're a can't go from risking 1% to you know Now they're down maybe five ten fifteen percent wherever it is over leveraged, etc so a lot of pain going on right now and This this turns out to be on a four hour. All right, this turns out to be what? Nice trapping candle. Look at that outside candle. This is why these candles. I love trading these candles you can take advantage of of I guess Pain in real time. Yeah, so if depending on how this closes Yeah, I might get short if the risk reward is nice out So if this starts to come down too far Then I'm not gonna get in simply because the risk reward might not be worth it That's a 1.48 to 1 I'm not gonna jump in now I just have to have some patience and what I'll do is even if prices start to go You know lower and lower and lower. Let's say for example here. Yeah I'll wait for price to come back up to here if they do because I know that's a CPR zone I know for a fact that traders are caught in this position here, you know, they've got in long Now they're getting you know the pain phase So I'll wait for a bit of a pullback. Yeah Before getting in long it might be you know produce like some sort of double top and I'll be getting in again Right at this zone decent zone. It's only touched, you know once Yeah, it's a fresh on the supply So if it does come back up to here or anywhere near here to the supply zone Then I'll be getting in but if this starts to run away. Don't panic. Don't worry It's not, you know, our trade or anything like that. It is what it is My risk rewards. This doesn't represent good risk reward at the moment. Just be patient. You'll get we'll get the trades You know, we'll go down to a lower time frame and let's see if it can if it closes like this or down here then fine Like I said, we're not trying to jump in at the moment We'll just wait for a bit of a pullback if it can pull back anywhere around this level And I know that there's gonna be traders caught in this because you know it on the five minute 15 minute the one hour, etc So Maybe not the one hour because one hour trades wouldn't yeah, it would have been closing now, but it would have drawn in definitely You know the 30-minute traders and also be careful not to get drawn in yourself to the downside because it could easily And capture you if you know, I mean So don't jump in just just observe what's happening in real time. Yeah, don't have any emotion chill Relax and yeah, just watch the fireworks and let's now take advantage of this Situation if prices come back up to here. Yeah, I take it