how to add the lang folder to the baseLanguage.

Hi,
my current page structure is like this:
[lang]
 - about.astro
 - news.astro
 - contact.astro
 - index.astro
index.astro (homepage default lang or redirect to user locale)

So except for the homepage in baseLanguage I always add the [lang] to every URL.
How can I do this?
(in my setup the HeadHrefLangs & LanguageSelector won't work.)
I would like not to have a structure like this:
[lang]
 - about.astro
 - news.astro
 - contact.astro
 - index.astro
about.astro
news.astro
contact.astro
index.astro

Thanks!

Hey, thanks for reporting the issue!
This is a concern I've had since the beginning and haven't figured out a way to automate it yet!
I've thought about generating the language files during build time but there are some limitations with Astro's integration API. I'll have to take some time in finding my way around them.
I'll try working on it this weekend and post my progress here 🙂

Alright, I've thought about this and I think I have a solution I can work with.
IMO, the best Developer Experience is not to have to think about this at all by having a folder structure as you would in any non localized Astro project like so:
pages
|-- about.astro
|-- news.astro
|-- contact.astro
└-- index.astro

Also, you shouldn't think about switching the language with i18next.changeLanguage(i18next.options.supportedLngs[0]);.
👉 astro-i18next would do the heavy lifting on both language files and language switching logic.
This would be possible using a CLI command that generates the code for you:
astro-i18next generate

☝ This command, would produce:
pages
├-- [lang]
|    |-- about.astro
|    |-- news.astro
|    |-- contact.astro
|    └-- index.astro
|-- about.astro
|-- news.astro
|-- contact.astro
└-- index.astro

This would be possible in 2 steps:

Create the astro-i18next generate command, responsible of going through the pages folder and generating the [lang] folder with the language switch logic. Now that I think of it, it may be easier (best?) to generate each supported locale in a different folder instead of the dynamic routes for starters.
--> code injection and astro files creation is easily done using the @astrojs/compiler

Call the astro-i18next generate command during build time to have localized pages and all language switching logic included with the build.

👉 I've started implementing this, and will work on it further next weekend.

Sounds good!
But what if the structure is deeper like with a blog collection?
pages
├-- news
|    |-- [...slug].astro
|    |-- index.astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

Then the getStaticPaths for a news item or a dynamic page can get more complicated.
I use NetlifyCms where all translations are stored in a single mdx file but not all fields are translated.
So on every [lang] route, I merge the language to access all the fields.
How would the astro-i18next generate know what to do?
[lang] route
export async function getStaticPaths () {
const allNews= await Astro.glob("../../../../data/news/*.mdx");

  let params = [];

  return await Promise.all(
    locales
      .filter((locale) => locale !== i18next.options.supportedLngs[0])
      .map(async (lang) => {
        const news = getTranslation(allNews, lang)
        const total = news?.length;
        news.map((newsItem, index) => {
          params.push({
            params: { lang: lang, slug: newsItem.slug },
            props: { content: newsItem},
          });
        });
        return params;
      })
  );
}

original route
export async function getStaticPaths () {
const allNews= await Astro.glob("../../../data/news/*.mdx");

  let params = [];

  return await Promise.all(
    locales
      .filter((locale) => locale == i18next.options.supportedLngs[0])
      .map(async (lang) => {
        const news = getTranslation(allNews, lang)
        const total = news?.length;
        news.map((newsItem, index) => {
          params.push({
            params: {slug: newsItem.slug },
            props: { content: newsItem},
          });
        });
        return params;
      })
  );
}

Thanks!

Sounds good! But what if the structure is deeper like with a blog collection?
[...]
How would the astro-i18next generate know what to do?

That's the catch when trying to have a dynamic route for languages! So, first, the easiest thing to do is to discard using getStaticPaths to declare localized routes.
Instead, astro-i18next generate would generate each declared locale in its own folder. For example, let's say we have 3 languages (fr, es, en), english being the default language:
# base pages translated using the `t()` function / `<Trans />` component
pages
├-- news
|    |-- [...slug].astro
|    |-- [page].astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

astro-i18next generate would generate the following at build time:
pages
├-- fr
|    ├-- news
|    |    |-- [...slug].astro
|    |    └-- [page].astro
|    |-- about.astro
|    |-- [...page].astro
|    |-- contact.astro
|    └-- index.astro
├-- es
|    ├-- news
|    |    |-- [...slug].astro
|    |    └-- [page].astro
|    |-- about.astro
|    |-- [...page].astro
|    |-- contact.astro
|    └-- index.astro
├-- news
|    |-- [...slug].astro
|    └-- [page].astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

And would add the following lines to the pages' frontmatter so as not to touch to the getStaticPaths logic:
---
import i18next from "i18next";

i18next.changeLanguage(<language code goes here>);

[...]
---

I think that in terms of DX, this is the best. Apart from having to replace the text with translation keys, you wouldn't have to do anything else.
And eventually, this also unlocks some other cool features, like what if we'd like to translate the routes? astro-i18next generate could also replace the file names for each language.
Anyways, haven't worked out the details yet, hopefully I can get something working this weekend 🤞

As the github-actions bot said, 1.0.0-beta.4 was just released with the first version of the npx astro-i18next generate command.
I had a blast working on this, learned a lot! Thanks for your feedback @preetamslot, I've added you as a contributor in the README.md. Hope you don't mind 🙂


Delete EBS volume & S3 bucket after job finishes

Create new input option (to be passed via GUI) that deletes S3 and EBS volume when job finishes.

Now included: if user provides --deleteaws through additional command line, EBS & S3 will be deleted


fix(android): force-override no ANSI also for format

As far as I understand, this should not be necessary because with_ansi(false) should propagate to all sub-components of tracing_subscriber. Unfortunately, that doesn't seem to be the case as we are still getting italic field names in spans, even with with_ansi(false).

Doesn't fix it :(


ng serve tsconfig target override

Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [X] feature request

Command (mark with an x)
- [ ] new
- [ ] build
- [X] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Desired functionality

It would be really helpful to have a way to override the tsconfig.json setting, either with a CLI flag or angular.json, so that ng serve would output ES2017 while ng build uses the configured value of ES5.
The primary reason for this is that stepping through async/await code in the debugger would be way easier than as-is with the ES5 equivalent that TypeScript generates.
Mention any other details that might be useful

Created this new issue in response to @mgechev closing my original less descriptive one (#6864) with a note to open a new one if the concern were still relevant.

You can create 2 tsconfigs, one which is used for serve and one which is used for build.

Ah, that's perfect, thanks!


[Bug]: rm -rf breaks builtin commands

What went wrong?
rm -rf a directory works, however ls and cd don't work afterward

Tested using master branch as of the time of this post. Appears to be resolved.


Optimize higress official website&doc style

How could it be?
Replace Docsite with Docusaurus.
Other related information
website&doc repo: https://github.com/higress-group/higress-group.github.io
Docusaurus: https://www.docusaurus.cn/

I can work on this when I have some time.

I will do it, pls assign to me :)


Reinitialize index on "Object not found" error.

Fixes #4007
Users have occasionally been reporting "Object not found" errors when updating the index. This PR changes cargo to detect this error, and delete the index and attempt one more time to update it.  Our best theory is that the git repo is getting corrupted or out-of-sync somehow.
Other options
We talked about having cargo generate a ZIP file of the corrupt repo and ask the user to upload it to the issue tracker, but I feel like that isn't going to be too useful (there will be an object missing in the repo, which is unlikely to tell us how to got lost).
We could also implement some tricks to make the fetch process more atomic (by renaming the git directory before starting the fetch), but I'm uncertain if the added complexity is justified.
Another option (which I personally like) is to use net.git-fetch-with-cli by default if git is found in PATH.  It is faster and more reliable and handles authentication better, and I suspect the vast majority of developer and CI systems have git installed.  This kinda sweeps the problems of libgit2 under the rug, and would mean a huge amount of code would no longer be exercised by most users, leaving the few without git to be more likely to suffer obscure bugs.
Testing
Note that I was unable to create a local test to reproduce this, but I was able to reproduce against GitHub.  I took my index repo and removed the most recent pack file, and then ran cargo fetch. This resulted in the exact same error users are reporting. I believe I cannot repro locally because the network update code is significantly different from the file:// update code (there's all sorts of negotiation that happens over the protocol).  Unless anyone has ideas on how to repro this in an automated fashion, I'm out of ideas.
Other corruption
In testing, I noticed there are a few other ways the "Object not found" error can happen, but this does not address them. Both cases involved deleting pack files:

After deleting the oldest pack file in an index, running an update, the index fetch succeeds. But then, when the RemoteRegistry attempts to load the config.json file, it can't find it (it fails here).

After deleting the newest pack file of a git dependency in the db directory, the fetch succeeds, but then the call to reset of the checkout fails (around here).

Fixing these I think will be require a bit of work, since retry loops will need to be added. I'm not too eager to do that since nobody has reported an error with either of these cases (the error stack is slightly different).

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

As an aside, I did a little performance testing of libgit2 vs git-cli. Some sample times (I tried all tests twice, and got reproducible times):
Fresh fetch
    with-cli: 32s
    libgit2: 37s

Fetch with very old index
    with-cli: 32s
    libgit2: 39s

incremental (about 1 day old)
    with-cli: 2s
    libgit2: 4s

Oh, I forgot to mention, for my repro against GitHub, running with net.git-fetch-with-cli works correctly.  The CLI appears to re-download the entire index when it detects the corruption.

Thanks for the investigation here! This was actually a much smaller change than I thought that it was going to be. I also think it's a good find that the CLI is basically redownloading the whole index like we are, and I also think it's nice that you were able to deterministically reproduce. I agree that getting zip/tarballs isn't too useful since I mainly just wanted to confirm that the CLI fixed it and/or poke around libgit2 a bit more.
I'm still hesitant to use the CLI by default for the reasons you pointed out. It may still come to that eventually but if we can I'd like to hold out for as long as possible.
@bors: r+

:pushpin: Commit 3bbb44c76a336f61da3c9bf73496e6567d59d05e has been approved by alexcrichton

:hourglass: Testing commit 3bbb44c76a336f61da3c9bf73496e6567d59d05e with merge 76c01613e3a6799f10d909383fcde2f0f0b08519...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 76c01613e3a6799f10d909383fcde2f0f0b08519 to master...


Problems in running the SCF for large system

I am trying to get the HF for a system with ~300 atoms; this has around ~5000 basis functions. I am running this calculation on 32 processors with 300GB of memory. Still, it is failing and showing a segmentation fault error.
Am I missing anything for input when handling a large system?
**** Input file***
mol = gto.Mole()
mol.atom = 'mymolecule.xyz'
mol.basis = '6-31G'
mol.max_memory = 300000
mol.build()
mf = scf.RHF(mol).density_fit()
mf.kernel()
@sunqm

@JangidBhavnesh, PySCF's max memory setting isn't exact (or at least that used to be the case). I would suggest setting the max memory to 275GB or even 250GB for your system to give you some cushion in case PySCF uses slightly more than your limit. If you could post a snippet of the log that shows the error, that would be helpful.

Here is the last print before it gave this error
/var/spool/slurm/d/job10901452/slurm_script: line 23: 1284079 Segmentation fault      (core dumped)
******** <class 'pyscf.df.df_jk.density_fit..DensityFitting'> ********
method = DensityFitting-RHF
initial guess = minao
damping factor = 0
level_shift factor = 0
DIIS = <class 'pyscf.scf.diis.CDIIS'>
diis_start_cycle = 1
diis_space = 8
SCF conv_tol = 1e-09
SCF conv_tol_grad = None
SCF max_cycles = 50
direct_scf = True
direct_scf_tol = 1e-13
max_memory 300000 MB (current use 120 MB)
Set gradient conv threshold to 3.16228e-05
Initial guess from minao.
******** <class 'pyscf.df.df.DF'> ********
auxbasis = None
max_memory = 300000
_cderi_to_save = /usr/home/tmp7xhcb4ky
Default auxbasis def2-svp-jkfit is used for H STO-3G
Default auxbasis def2-svp-jkfit is used for C STO-3G
Default auxbasis def2-svp-jkfit is used for O STO-3G
Default auxbasis def2-svp-jkfit is used for N STO-3G
Default auxbasis def2-svp-jkfit is used for Ca STO-3G
Default auxbasis def2-svp-jkfit is used for S STO-3G
num shells = 25022, num cGTOs = 75726
size of aux basis 75726
CPU time for 2c2e    225.83 sec, wall time     19.41 sec

@JangidBhavnesh, could you try running the job again with the smaller value of max memory and see if the problem persists?

What is rational for using smaller memory?
Although, with smaller value it did crash at same point, except it took longer to reach that point.
So error still persist!

@JangidBhavnesh the rationale for using smaller memory is that PySCF's max_memory is not a hard limit to the amount of memory it will use and at times PySCF will use more than that amount. What smaller value did you use? Do you have exclusive access to the node you're using or are you sharing it with other users?

How much memory do you have in your machine or node?

@JangidBhavnesh the rationale for using smaller memory is that PySCF's max_memory is not a hard limit to the amount of memory it will use and at times PySCF will use more than that amount. What smaller value did you use? Do you have exclusive access to the node you're using or are you sharing it with other users?

I have tried with 100 GB and I'm using shared node.


Not possible to integrate LK Südliche Weinstraße

Hey,
i don´t know why, but it´s not possible to integrate LK Südliche Weinstraße. Other counties are working without any problems...
Maybe u can take a look :) Landau and Rheinland-Pfalz are shown on the MMM. I also tried out other counties and they are working...
{
module: "MMM-RKI-Covid19",
position: "top_bar",
config:{
reloadInterval: 60601000,
tableClass: "small",
counties: [
'SK Landau i.d.Pfalz',
'LK Südliche Weinstraße',
],
states: [
'Rheinland-Pfalz',
]
}
},

Yes, I´m using the current version. You used exactly my config? i can´t understand this issue...

Yes, that's strange. I used exactly your configuration for the test. I chose a different position only for the screenshot ("top_right").

Just an idea: Is your config file UTF8 encoded?
You can test this with the following command file -bi config.js in your config folder.
The result should be this: text/plain; charset=utf-8.

the result is iso-8859-1

Okay, that's the problem :fireworks: Make a backup of your config file and then try this:
iconv -f iso-8859-1 -t utf-8 config.js

ok, i tried it out but it´s still iso-...

iconv sometimes don't works like I want ^^ Okay, next try:

make backup:
cp conig.js config.bak

Convert and override the config.js
iconv -f iso-8859-1 -t utf-8 config.bak > config.js

Test again:
file -bi config.js

ok, that finally worked. thx a lot for your time!

You're welcome! :slightly_smiling_face:
Did the conversion only work or does the module work now and shows your 'Landkreis'? Sometimes the umlauts gets broken when converting, then you just have to open the config file and rewrite the umlauts.
When everything works fine, you can close the ticket. Enjoy this sunny Sunday!

Also the Landkreis Südliche Weinstraße works now, so my issue is solved!!


fix CphTest with number arguments

This pull request fixes an issue when using CphTest with arguments.
Running CphTest 1 gives the following error:
E5108: Error executing lua Vim:E484: Can't open file inputinput1
stack traceback:
        [C]: in function 'readfile'
        ...ack/packer/start/cphelper.nvim/lua/cphelper/run_test.lua:15: in function 'run_test'
        ...acker/start/cphelper.nvim/lua/cphelper/process_tests.lua:30: in function 'iterate_cases'
        ...acker/start/cphelper.nvim/lua/cphelper/process_tests.lua:102: in function 'process_retests'
        ...acker/start/cphelper.nvim/lua/cphelper/process_tests.lua:94: in function 'process'
        [string ":lua"]:1: in main chunk
Press ENTER or type command to continue

It seems like the case variable was already the complete filename, so by prepending "input", we ended up with inputinput1 as filename, which doesn't exist. I just removed the prepending part of the code.

This doesn't make sense though - the command CphTest passes its arguments as-it-is to process_tests.process, which passes them as-it-is to iterate_cases

If i print the case_numbers table in iterate_cases I get { "1" }

If I print case before this line
https://github.com/p00f/cphelper.nvim/blob/4bc91f27a29dad0eaeda6c3470924f6e1174f4aa/lua/cphelper/process_tests.lua#L30
I get only 1

Ah understood

Thanks!