@ilkkachu the idea of slurm is that you pass it a script to run. In the OP's original example, that script had a hardcoded header and the two run time parameters and they wanted the header to reflect what the parameters are. Since the header is in a comment and only read by slurm, this isn't possible.
With my wrapper script, they can make sure the header and the content changes based on the parameters. So instead of running "slurm slurm_script.sh" they can now run "make_slurm.sh foo bar > slurm_script.sh; slurm slurm_script.sh" or even "slurm <(make_slurm.sh foo bar)".
@ilkkachu I'd add what seems to be missing for you: there's a scheduler that runs some program. The comments in the job file concern the scheduler, you tell it things like number of CPU cores to allocate, max runtime of the job etc. The actual shell code inside the job file is the job itself normally: it sets up things if necessary and executes the worker (in my case, there's always an mpirun ./executable at the end that does the work that's being scheduled by slurm)
the scheduler and the worker don't even usually run on the same machine
@terdon @AndrasDeak, yes... and editing the file to embed the values works, if the values are fixed (like I said two times already). But that's not a really interesting case, IMO, it doesn't help in getting dynamic values in the job name. Dynamic values that would be provided by the job manager in whatever ways it provides, e.g. Parallel could give them as command line args, and Slurm seems to have e.g. sbatch -a which sets some SLURM_ARRAY_* envvars.
it does appear to show the array values in the job id, but it doesn't help with dynamically changing the job name.
(which is what I meant with not getting the point of the command line args, since to me, it would make sense that they might change dynamically. And for that, displaying it would need to be done by the manager)
Anyway if you're going to submit the jobs as independent ones, why not just run for x in foo bar; do sbatch --job-name="$x" somejob.sh "$x"; done, instead of modifying the file for every run? The SBATCH lines are an alternative way of passing args to sbatch, right?
@ilkkachu yeah, I was about to say. If you're going to pass the parameters as command line args then you could use the same slurm switches directly. If that's your point then yes, I agree.
I thought you were asking why these arguments in the header were necessary in the first place, when instead you're saying that it's an XY problem
@AndrasDeak mm, no. I get the point of having the header to pass some metadata to the manager. But I was assuming that the command line args would possibly be used to pass dynamically varying data, as in that you could tell the manager to "run this thing a hundred times, with the command line args set to one of the numbers between 1 and 100, one for each invocation". Or "...using this list of words, one for each".
And for that, it's the manager that needs to support embedding the data in the name, or where ever, if that's considered useful. Might be that in this context, it's not considered useful.
Following on the text-processing meta-question and the discussion around tools v. tags, I shall henceforth recommend Make (but won’t tag questions with make).
You can’t do it directly with wildcards, but a for loop can get you there:
for epub in ./*.epub; do ebook-convert "${epub}" "${epub%%.epub}.mobi"; done
Zsh supports a more elegant form of this loop.
Instead of a shell script, you can use Make; put this in a Makefile:
all: $(patsubst %.epub,%.mob...
@ilkkachu yeah, that's how I'd probably do it too. Unless I was in a situation where I need to keep separate scripts so I can easily repeat an experiment. I've written things like this when I was in academia, so that I could then have a folder with all the scripts needed for a project.
Hi folks. I have a question about scanning. It's too vague for the site, I think. It may not even be on-topic.
The other possibility, I suppose, is SuperUser.
If I scan at 200dpi the file is nice and small, but the words are a bit misshapen. Being the freak I am, this sometimes bothers me a little. At 600dpi, the words look good, but the file size is substantially larger.
But it occurred to me that a lot of the file size (even in "outline" mode) is probably bits that represent scans of the white area. I should have mentioned that these scans all all exclusively paper documents with the Roman alphabet on them, and not much else.
So it one could get rid of all the surplus white area scanning, the file might come down quite a bit. But I'm not sure how to do that.
@StephenKitt My B&W Fujitsu ScanSnap runs between 130 and 250 Kb for a single page. At least for the relatively unbusy documents I'm currently looking at. But a 200dpi one is 70Kb.
@ilkkachu JPGs aren't ideal for printing. And AFAIK you can't trivially stick them together like you can with PDFs.
@FaheemMitha I can tell you that the norm I've seen in scientific journals is that they require images at 300dpi and my experience with that has been that 300 is more than enough for it to be clear.
I installed a Linux VM in the virtual box, and inside it I installed the QEMU package and virtualized an AIX 7.2 image. The entire installation went correctly.
But when I try to install an Oracle inside the AIX VM that is virtualized by QEMU, I get a Segmentation fault message.
Start VM Qemu:
ppc...
hi, i had a question about wsl - i have wsl 1 installed, and am trying to update it to wsl 2. i've checked and i have sufficient base versions and so forth to update, and i'm following the instructions in the microsoft docs. i have run dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart, and it says operation completed successfully.
however, when i try to switch the default version for wsl to 2, it gives Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS. For information please visit https://aka.ms/wsl2-install
the link simply leads right back to the documentation instructions i'm following.
@HannahVernon yeah, I saw. I was just on mobile and hadn't realized the original you'd shown me was on another site. I was even wondering why it'd been closed! :)
Also, hey @AudenYoung, nice to see you 'round these parts!
