Support explicit relative paths using common /./ notation

Output of restic version
restic 0.16.4 (v0.16.4-0-g3786536dc) compiled with go1.21.8 on linux/amd64
What should restic do differently? Which functionality do you think we should add?
Add support for explicit relative path designations (specifying the intended root of path) using common /some/path/./another/path notation to anchor the portion of the path to be stored.
Backups and exclude/includes should be able to be specified with the new "root" of the path starting after the /./ part.  So the path above becomes /another/path for all storage/referencing purposes, including: parent use/detection, include/excludes, etc.
This is a simpler, and already known method of accomplishing the indication of relative path intent.
(See also: #2714, #2246, #2993, #3131, #3200, and possibly others)
The forced absolute path design that restic currently uses to identify backups actually causes several problems, and there are several tickets (some of which are listed above) already trying to solve or abate them.
What are you trying to do? What problem would this solve?
In my current use case, I have backups that were done via zfs snapshots, and I'd like to "move"/convert them into restic instead.
However, since each snapshot appears within zfs under its own unique snapshot directory, restic resists being informed that those are actually the same files, just from another point in time, and clutters the snapshot listing with path information that is completely irrelevant, as well as breaking restic's parent and file-change detection and forcing all files to be completely rescanned.  It may also result in restic being less efficient at storing those changes (this is just a guess).
Example command:
restic backup -x --time "2024-01-01 02:00:00" --host argon  \\
/mnt/backups/.zfs/snapshot/20240101-020000/argon/root/./ \\
/mnt/backups/.zfs/snapshot/20240101-020000/argon/./boot \\
/mnt/backups/.zfs/snapshot/20240101-020000/argon/./usr/ \\
/mnt/backups/.zfs/snapshot/20240101-020000/argon/./var/

Admittedly, this can be worked around by using bind mounts to position the directories to be backed up in a manner that restic can no longer mistakenly infer that they are different sources, but that requires root privileges and is overly convoluted when this capability should (I think) be provided within restic.  And the bind mount workaround still does not allow the paths to actually be stored/referenced at the actual root of the filesystem if that is what is desired.
Did restic help you today? Did it make you happy in any way?
I massively appreciate restic being able to reduce the overall storage needs for backups of often changing but otherwise relatively very similar files like mbox mail files, where one message deleted near the beginning of the file causes the entire rest of the file to be rewritten (and thus changed as far as zfs is concerned) even though the actual total data changed may have only been a few kb deleted.

Take a look at #4026 which proposes to change the absolute path model and is under consideration.

@damoclark I did see that ticket while I was looking for workarounds, but that doesn't address the issue that it would still store useless (and wrong for the purposes of restore) path information.  It also seems like a more significant undertaking, because it re-architects what restic uses to identify backups, so this proposal seems like a much less impactful change.

but that doesn't address the issue that it would still store useless (and wrong for the purposes of restore) path information.

It does address the issue you describe, using the -C semantics of tar, such that all backups snapshots are relative.  The path information, while in your case might have no use, is not necessarily useless to everyone.  In #4026, storing of the path where the backup took place might still be recorded in the metadata of the snapshot, but would not be used in any restores, unless --inplace #4575 were used for instance.

Add support for explicit relative path designations (specifying the intended root of path) using common /some/path/./another/path notation to anchor the portion of the path to be stored.
Backups and exclude/includes should be able to be specified with the new "root" of the path starting after the /./

A novel approach, but I don't think it is a good idea encoding special meaning within paths using the current directory . period.  It is not uncommon to build paths in shell scripts using command line args or shell variables for instance, that may include a period when invoked manually (e.g. ./path/to/somewhere).  This may lead to unintended invocation of this special meaning.  The -C semantics of tar are already a pretty well established solution to this exact problem, and are explicit.

It also seems like a more significant undertaking, because it re-architects what restic uses to identify backups, so this proposal seems like a much less impactful change.

Unfortunately, I think re-architecting this part of restic is necessary.  If done well, impact can be minimised.  In fact, I actually think it will make restic easier and more intuitive to use.  And yes, it will be a substantial undertaking.  An interim solution might be worthwhile, but the challenge with half measures, such as the one you suggest is that they might appear simple, but risk breaking other things, such as parent matching.  These ideas are discussed in #4026.  Mucking around with the absolute paths under the current model, in my view, is risky.
I appreciate the need for a quick fix for your use case.  I have similar requirements, although mine are for backing up LVM and APFS snapshots, rather than ZFS, and for storing backup archives.
I propose that the sooner the present model that relies upon absolute paths for identifying backup-sets is replaced, the sooner and easier a great number of existing issues and limitations of restic can be resolved.  The evidence to me suggests it's worth the trouble.
In the meantime, there are some clever hacks you can use to work around your zfs issue, using symbolic links.  They are barbaric, but they work if you are interested. :)

The path information, while in your case might have no use, is not necessarily useless to everyone.

I never claimed it was never useful.  I said in my case it wasn't useful since it was wrong in my specific situation.  Which is why I'm looking for a way to override the default assumption that the path things are stored at now (backup/snapshot creation time) is meaningful in the future, which is often correct, but sometimes not.

It is not uncommon to build paths in shell scripts using command line args or shell variables for instance, that may include a period when invoked manually (e.g. ./path/to/somewhere). This may lead to unintended invocation of this special meaning.

You are correct.  If it is desired to protect against this "unintended" use, by all means, add a --use-relative flag that enables this behavior.  I was just trying to avoid adding flags since there seems to be a cultural resistance in this project to the addition of flags because it is seen as complicating usage for "normal" users.

The -C semantics of tar are already a pretty well established solution to this exact problem, and are explicit.

Perhaps.  But those semantics do not actually handle the example I've given in this ticket.  If you'll note, I've specified different relative roots in the paths to be backed up in my example, which -C does not handle, since you can only change to one directory.

Unfortunately, I think re-architecting this part of restic is necessary.

I don't know that I'd go so far as necessary, but I do agree that it seems like a good addition.  But your proposal also does not completely solve my use case.  Introducing labels does not alleviate the problem that useless and distracting "wrong" paths are being stored as an intrinsic part of the backup, and there is no mechanism to correct them.
But I also note that your proposed re-architecture ticket has been around for about 18 months without anyone showing any indication of being willing to take it on.  In fact, you noted yourself in https://github.com/restic/restic/issues/4026#issuecomment-1968029584 that it doesn't look like it will be implemented anytime soon.  Whereas the change I've proposed is much simpler, and I might even be willing to take a stab at making a PR for it, assuming there was some indication from the maintainers that it might be accepted.

In the meantime, there are some clever hacks you can use to work around your zfs issue, using symbolic links. They are barbaric, but they work if you are interested. :)

I don't see how symbolic links could help, since restic resolves paths to absolute, which would undo any symbolic links.  I already mentioned the only reasonable workaround I see for this in the OP, which is using bind mounts.  I do agree that having to use bind mounts is pretty barbaric (as well as an incomplete solution).  Can you explain how symlinks can help?

Hi Evan,

Which is why I'm looking for a way to override the default assumption that the path things are stored at now (backup/snapshot creation time) is meaningful in the future, which is often correct, but sometimes not.

I understand now what you are saying.

The -C semantics of tar are already a pretty well established solution to this exact problem, and are explicit.

Perhaps. But those semantics do not actually handle the example I've given in this ticket.

Actually, they do if I have understood your requirements correctly.
You want:
/mnt/backups/.zfs/snapshot/20240101-020000/argon/root/ to map to path /
/mnt/backups/.zfs/snapshot/20240101-020000/argon/boot/ to start at /boot
/mnt/backups/.zfs/snapshot/20240101-020000/argon/usr/ to map to /usr and
/mnt/backups/.zfs/snapshot/20240101-020000/argon/var/ to map to /var
Hope I understand this correctly.

If you'll note, I've specified different relative roots in the paths to be backed up in my example, which -C does not handle, since you can only change to one directory.

This is incorrect.  -C can be provided multiple times using tar, and it is proposed to do the same for restic.  So your requirements would be satisfied as follows:
restic backup -x --time "2024-01-01 02:00:00" --host argon \
-C /mnt/backups/.zfs/snapshot/20240101-020000/argon/root/  . \
-C /mnt/backups/.zfs/snapshot/20240101-020000/argon/  boot \
-C /mnt/backups/.zfs/snapshot/20240101-020000/argon/  usr \
-C /mnt/backups/.zfs/snapshot/20240101-020000/argon/  var

Again, based on my correct interpretation of your requirements. :)

Unfortunately, I think re-architecting this part of restic is necessary.

I don't know that I'd go so far as necessary, but I do agree that it seems like a good addition.

Strong words, I know. :). My confidence in making such a bold statement is based on my observations in the forums and the github issues over an extended period of time.  The current model confuses people, generates lots of questions, tricky feature requests, and workarounds, taking up maintainers' time that I think could be better spent.
That is why I think a change to the underlying model is necessary.

But your proposal also does not completely solve my use case. Introducing labels does not alleviate the problem that useless and distracting "wrong" paths are being stored as an intrinsic part of the backup, and there is no mechanism to correct them.

You need to read #4026 more thoroughly as its a discussion, with evolving ideas based on contributions from others.  I actually prefer to use 'name' rather than label - naming backup-sets.

But I also note that your proposed re-architecture ticket has been around for about 18 months without anyone showing any indication of being willing to take it on. In fact, you noted yourself in https://github.com/restic/restic/issues/4026#issuecomment-1968029584 that it doesn't look like it will be implemented anytime soon.

Yes.  As you can tell, I was disappointed by that revelation.  But I'm not doing all the work and I fully respect that.

Whereas the change I've proposed is much simpler, and I might even be willing to take a stab at making a PR for it, assuming there was some indication from the maintainers that it might be accepted.

Go for it.  I see you have referenced https://github.com/restic/restic/pull/3200.  Have a good read, as it would be a great place to start.   I was disappointed that Alex closed that PR.  Also, have a good read of #4026 and Michael's comments in particular.
Cracking this nut, if it can be done in the short-term would benefit many (including me).  My only concern is that some users could get themselves in a 'bit of a pickle' by 'fudging' the paths of a snapshot without decoupling it's implicit meaning as a backup set identifier, especially if they don't know what they are doing, or make a mistake.

I don't see how symbolic links could help, since restic resolves paths to absolute, which would undo any symbolic links. I already mentioned the only reasonable workaround I see for this in the OP, which is using bind mounts. I do agree that having to use bind mounts is pretty barbaric (as well as an incomplete solution). Can you explain how symlinks can help?

I made a mistake here.  You are correct that symbolic links won't help you with zfs.  The symbolic links have helped me with APFS, because its a single volume that I am backing up (Macintosh HD - Data) and I don't need to reassemble different mount points.  Essentially, for each APFS snapshot, I create a symbolic link /Volumes/Time Machine -> /Volumes/.timemachine/<UUID>/<timestamp>.backup/<timestamp>.backup/Macintosh HD - Data and put this in a loop.
This way, the absolute path is always /Volumes/Time Machine for each time machine snapshot, and restic snapshot thereof.
I think you are correct RE bind mounts for zfs.
D.

This is incorrect. -C can be provided multiple times using tar, and it is [proposed] to do the same for restic.

I was not aware that -C could be specified multiple times for tar.  But even if that is the case, I would guess that tar -C would also end up storing files more than once if any of the -C destinations ended up overlapping, whereas restic would not.  tar has the ability to concatenate archives, whereas restic does not (yet) have the ability to merge backups, so it doesn't seem entirely similar.
However after already having had a cursory look at how restic processes paths to be backed up (as a single list of paths), it would seem significantly more complicated to have to change all the internals to be able to handle a more complicated data structure, whereas it would seem that my suggested method could still be done with the same simple list of paths, since both items (actual and wanted path) are communicated within each individual path.

I was not aware that -C could be specified multiple times for tar. But even if that is the case, ...

No 'ifs'.  Its a fact.  Try it for yourself.  BSD & GNU tar alike.

I would guess that tar -C would also end up storing files more than once if any of the -C destinations ended up overlapping, whereas I think restic would not?

I have already done the research on this, in terms of how tar behaves and how restic could better implement it - it's in #4026.  I'm not going to restate things here.

tar has the ability to concatenate archives, whereas restic does not (yet) have the ability to merge backups, so it doesn't seem entirely similar.

This is not a convincing argument to me.  What is identical is the concept.  That is what's important.  Those who are already familiar with the concept will be able to easy apply it to restic.  It's also a simple concept, so those who aren't will learn a new concept.

whereas it would seem that my suggested method could still be done with the same simple list of paths, since both items (actual and wanted path) are communicated within each individual path.

I strongly advise you not to pursue your proposed approach of using the . directory as a separator for translating paths.  Don't get me wrong - it's a clever idea.
And naturally, it's your call as the PR initiator, and it's the Restic team's call as to whether they accept it.  But...
Without turning into a computer science lecture, you are creating a semantic overload.
Encoding special meaning in the paths can only cause unintended grief for users down the road.  I have already provided a concrete example in the way of concatenating user-provided path segments. So I'm not just speculating.  Part of the issues with the current model of the paths being used to match parent snapshots is that the paths have been endowed with a special meaning beyond their literal meaning of being a path to 'what' is being backed up.  The path can change, while the 'what' may not.
It is why, for instance, databases use arbitrary incremental numbers as primary keys (i.e. surrogate versus natural keys).
The . character is not just a separator for your path mapping, it is also a legitimate directory in and of itself.  At some point, these two legitimate meanings will collide, and it will only cause issues for the user. : is no good either (as in docker volume mapping or PATH env), because it has special meaning in windows.
Furthermore, with the tar syntax -C it is not just a 1-1 mapping of paths for the creation of the tar archive VFS.  You can do the following:
tar cv -C /home fred margot barry

say, if you only wanted to backup those three home directories, relative to /home.
The concept is:  tar cv -C <set VFS root path here> <backup> <stuff> <relative> <to> <here> ... -C <now VFS root is here> ...
We teach this simple concept to users who don't already know it in the doco, and these semantics become very powerful, without the potential aforementioned problems.
This problem has already been solved - let's stand on the shoulders of giants. :)

However after already having had a cursory look at how restic processes paths to be backed up (as a single list of paths), it would seem significantly more complicated to have to change all the internals to be able to handle a more complicated data structure

I think you are arguing that your solution is much quicker and easier to implement, than #4026.  If I have misunderstood, disregard my response below and help me understand.
I am not contesting that your short-term solution wouldn't be easier, not withstanding the challenges of retrospectively enabling path mapping and/or relative paths under a model that is heavily reliant on absolute paths.  And in a way that doesn't compound the issues of semantic overload.  That is where I don't think your short-term solution is necessarily easier, and will require careful work.
This is why I have been advocating for changing the model earlier, rather than later.  By doing so, these problems (and many others) become much easier to solve.  Or at least I think they will be.  Again, I am guided by those who are very familiar with the code-base here.
Very happy to have intellectual discussion and debate on these ideas with you.  But with sincerity, I would prefer it if you do the readings I suggested earlier first.  This way, we have a common starting point for discussing new ideas going forward.
Damien.

This discussion completely mixes two only partially related issues. #4026 primarily addresses how to identify backup sets (something similar can already be achieved using backup --tag something-unique --group-by tags), but that is not what this issue seems to be about. The discussion here instead duplicates a lot of what has already been discussed in https://github.com/restic/restic/issues/2092 and #555, which primarily address where files end up within a snapshot.
/mnt/backups/.zfs/snapshot/20240101-020000/argon/root/./
/mnt/backups/.zfs/snapshot/20240101-020000/argon/./boot

That won't behave as you'd expect. The root subvolume normally contains an empty boot folder as mountpoint. As a consequence the resulting snapshot would contain /boot (from root) and /boot-1 (from ./boot). Restic has no idea whether files with colliding names should be overwritten or not (duplicate filenames will never be valid within a restic snapshot). As it's a backup program, the heuristic is to just keep everything. The incredibly ugly part there is that restic has to enumerate all files in root/./ to know whether /./boot will collide or not.

You are correct that that could potentially happen, and if it is desired to protect against this "unintended" use, by all means, add a --use-relative flag that enables this behavior. I was just trying to avoid adding flags since there seems to be a cultural resistance in this project to the addition of flags because it is seen as complicating usage for "normal" users.

There is a resistance to blindly adding flags without first discussing whether it is actually necessary; things should just work without requiring users to assemble the right magic combination of options. More flags that interact with each other in surprising ways don't help anyone. Although, the file layout issue will likely require some additional options.

At some point, these two legitimate meanings will collide, and it will only cause issues for the user. : is no good either (as in docker volume mapping or PATH env), because it has special meaning in windows.

: is also a perfectly valid character in filenames on unix.

But I also note that your proposed re-architecture ticket has been around for about 18 months without anyone showing any indication of being willing to take it on. In fact, you noted yourself in #4026 (comment) that it doesn't look like it will be implemented anytime soon.

Yes. As you can tell, I was disappointed by that revelation. But I'm not doing all the work and I fully respect that.

I can only take a look at so many things at a time, which also means that I can't get involved in every discussion as otherwise I wouldn't get anything done.

it would seem significantly more complicated to have to change all the internals to be able to handle a more complicated data structure

The usual rule of thumb is that a more complicated implementation is ok if that simplifies the interface (all within certain limits obviously).

And naturally, it's your call as the PR initiator, and it's the Restic team's call as to whether they accept it. But...

I won't have time to have a closer look at this and the related issues before the development cycle for restic 0.18.0 starts. Probably anything you start working on now won't match the outcome of the corresponding discussions.

Yes. As you can tell, I was disappointed by that revelation. But I'm not doing all the work and I fully respect that.

I can only take a look at so many things at a time, which also means that I can't get involved in every discussion as otherwise I wouldn't get anything done.

Important things first.
My comment wasn't a criticism.  It is okay that I am disappointed - you don't owe me, or anyone else anything.   You have to make decisions and they can't always please everyone.
And I take your point RE discussion.  I'm making my reply deliberately brief. :)

This discussion completely mixes two only partially related issues. https://github.com/restic/restic/issues/4026 primarily addresses how to identify backup sets (something similar can already be achieved using backup --tag something-unique --group-by tags)

Not entirely Michael.  In fact, this point was discussed at length in the issue.  But let's leave for a more appropriate time...

I won't have time to have a closer look at this and the related issues before the development cycle for restic 0.18.0 starts.

No problem.  Appreciate the clarity.

/mnt/backups/.zfs/snapshot/20240101-020000/argon/root/./
/mnt/backups/.zfs/snapshot/20240101-020000/argon/./boot

That won't behave as you'd expect. The root subvolume normally contains an empty boot folder as mountpoint. As a consequence the resulting snapshot would contain /boot (from root) and /boot-1 (from ./boot).

This important point slipped by me, due to my lack of experience with ZFS.  Thanks for this Michael.  There are proposed ideas in #4026 and elsewhere to address this - at a later time.

The discussion here instead duplicates a lot of what has already been discussed in https://github.com/restic/restic/issues/2092 and https://github.com/restic/restic/issues/555, which primarily address where files end up within a snapshot.

Thanks for this.  I totally missed #555.  And especially that rsync already partially adopts what Evan was proposing by applying special meaning to . directory in path translation.  While this doesn't change my position, I do acknowledge that it has been implemented in a widely used technology.  I have skimmed over that section of the rsync man page many times in the past and never paid attention to what it actually does.  It may have baffled some people in the past when it was unintentionally applied.

The usual rule of thumb is that a more complicated implementation is ok if that simplifies the interface (all within certain limits obviously).

I share your philosophy.

This important point slipped by me, due to my lack of experience with ZFS. Thanks for this Michael. There are proposed ideas in #4026 and elsewhere to address this - at a later time.

That is actually unrelated to ZFS. Using Linux, you can only mount a volume over a folder. That is to mount a volume at some path you have to use mkdir -p /some/path && mount /dev/something /some/path. Therefore the root volume snapshot will contain an empty folder at /some/path.

That is actually unrelated to ZFS. Using Linux, you can only mount a volume over a folder. That is to mount a volume at some path you have to use mkdir -p /some/path && mount /dev/something /some/path. Therefore the root volume snapshot will contain an empty folder at /some/path.

Yes, I understand this.  My misunderstanding was with how ZFS was arranging its mounted snapshots.  What you describe is an important problem to solve for restic going forward, but it has been solved by others already. This provides some guidance on how to approach it within the model of restic.  GNU and BSD tar approaches are a good place to start as discussed in #4026.
I have great respect for the work you and your team do on Restic.  Backup technologies are high-stakes complicated beasts, especially when they are multi-platform (including the black sheep Windows juggernaut).


fix(compress): num.toFixed() and num.toPrecision()

Description:
The code snippet  from StackOverflow is for handling toPrecision instead of toFixed

BREAKING CHANGE:

Related issue (if exists):

fix #6957

The num_to_precision cannot handle JS toPrecision. It will return unexpected results.
assert.sameValue((10).toPrecision(1), "1e+1");
assert.sameValue((11).toPrecision(1), "1e+1");
assert.sameValue((17).toPrecision(1), "2e+1");
assert.sameValue((19).toPrecision(1), "2e+1");
assert.sameValue((20).toPrecision(1), "2e+1");

after minify:
assert.sameValue("10", "1e+1");
assert.sameValue("11", "1e+1");
assert.sameValue("17", "2e+1");
assert.sameValue("19", "2e+1");
assert.sameValue("20", "2e+1");

Do you mean it's not possible at all?

Do you mean it's not possible at all?

No, we can calculate the result step by step according to the ECMA262 specification.

There are two test case files from test262.
I don't know if there is a license issue. Is it OK to include them?

I think it's fine


fix(model): error 500 in cluster list when area change

Cherry picked in 2.15.3 by @laurent-laporte-pro


Make the hyperstart package follow upstream changes and fix ctl panic

The first commit is to fix the hyperstart package as upstream has renamed a payload name, breaking the compilation.

Note that travis fails because it got gets the current hyperstart package, which doesn't have the fix.

@dlespiau Fix the hyperstart upstream support with PR #74. Please rebase this one on top of it and Travis should be happy.

Superseded by #76


sse3: added impl for x_mm_deinterleave{even,odd}_{epi{16,32},ps,pd}

sse3: added impl for x_mm_deinterleave{even,odd}_{epi{16,32},ps,pd}

I have also refactored code for mm256_hadd_epi16 to use x_mm_deinterleave* operations. Please review it, if it is fine, I will refactor other such functions as well.

I have refactored code for mm256_hadd_epi16 to use x_mm_deinterleave* operations. Please review it, if it is fine, I will refactor other such functions as well.

The idea is sound, but instead of extracting the individual 128-bit vectors it would be much better to create simde_mm256_deinterleave{even,odd}_* functions which operate on the entire 256-bit vector.  That will be a lot faster on hardware that supports 256-bit vectors.
Then the code you have here could basically be the fallback for when 256-bit vectors aren't natively supported but 128-bit vectors are.
Let me clean up #275 a bit and merge it, that would be a good foundation for this.  Meanwhile why don't you start converting the 128-bit horizontal operations (_mm_h{add,sub}_{ps,pd,epi16,epi32} and _mm_h{add,sub}s_epi16 to use this?

I will complete this and other similar functions, after I finish implementing, simde_mm256_deinterleave{even,odd}_*. I have made all the suggested changes so far.


Tooltip not appearing after updating Docusaurus to version 3.4.0

Description:
I encountered an issue where the tooltips for terms are not appearing after updating Docusaurus to version 3.4.0. The problem seems to be related to this update, as rolling back to Docusaurus version 3.3.2 resolved the issue.
Steps to Reproduce:

Update Docusaurus to version 3.4.0.
Install and configure the Docusaurus Terminology Plugin.
Build and run the site.
Hover over any term that should display a tooltip.

Expected Behavior:
The tooltip should appear when hovering over a term.
Actual Behavior:
The tooltip does not appear after updating to Docusaurus version 3.4.0.
Workaround:
Rolling back to Docusaurus version 3.3.2 resolves the issue, and the tooltips appear as expected.
Environment:

Docusaurus version: 3.4.0
Node version: 22.0.0
npm version: 10.5.1
Operating System: macOS

Additional Context:
This issue might be linked to changes in the Docusaurus 3.4.0 update.
Relevant Configuration:
Here is the relevant part of the docusaurus.config.ts file:
[
  '@grnet/docusaurus-terminology',
  {
    termsDir: './docs/terms',
    docsDir: './docs/',
    glossaryFilepath: './docs/glossary.md',
  },
],

Did you manage to fix it or just rolled back until it's resolved?

Did you manage to fix it or just rolled back until it's resolved?

Hi @adriaandh,
I didn't manage to solve it due to limited time, so I just rolled back for now.


Update Person Class

Closes #39

Looks ok. Will merge PR since CI fails solely due to code coverage. @meatyturtle please help review before we merge, thanks

looks great, thank you! you are the cornerstone of this team shane


Better nginx log handling

It looks like nginx logs are written to the filesystem, which could fill up the disk on a busy dyno and also hides nginx logs from heroku logs.
What about sending the logs to stdout/stderr? See http://www.12factor.net/logs

using a named pipe has been reverted in #175 because it caused too many issues

This is also a cool idea: https://github.com/nginxinc/docker-nginx/blob/e9202a4795d84a85499fcd6cda58ddde4cf4079d/Dockerfile#L15
... haven't tested on Heroku though.


Add support for ed25519 keys

Can't use ed25519 to encrypt, so would have to convert ot X25519. Still store the original ed25519 key.

Some quick untested LLM generated code:

https://www.perplexity.ai/search/write-some-go-code-to-convert-fPu4eaD2TimSKd9I7vU7fA
https://claude.site/artifacts/d90daa01-e959-44d7-b1a6-018c764fefa2

Seems like the entire process is different, needing a key exchange or private key of sorts. Maybe the LLMs are not explaining well.

It looks like you need the encrypter's private key and the decrypter's public key. If we don't ever need the encrypter's keys again to decrypt, we can just generate ephemeral keypairs at encryption time.

But it does look like you need some shared secret to do the decryption, and the whole point of RSA is that you don't need that

Or could do every keypair combo, but that would convert having n shared secret values to n*(n-1)/2 secret values which isn't terrible but it's a lot of work for someone who can simply just generate an RSA key and stick it in their github and ~/.ssh folder

Closing as not planned for now


dict.iteritems() are no longer supported in Python 3.0

The dict.iterkeys(), dict.iteritems() and dict.itervalues() methods are no longer supported in Python 3.0.
Instead use dict.keys(), dict.items() and dict.values().
https://docs.python.org/release/3.0.1/whatsnew/3.0.html#views-and-iterators-instead-of-lists

This should be resolved as of 5c501edcbc28d1e42c8a928a783066519eba6a31, tests now include Python 3.4 and 3.5 where applicable also.
This isn't on PyPI yet, but probably will be sometime this week or next.


Add documentation about echo to the notification docs.

While configuring the database notifications with Laravel Echo I couldn't find the part about uncommenting the code in the filament config.

Notifications can be used outside the Filament admin panel as well. The documentation you're looking for is under the admin package: https://filamentphp.com/docs/2.x/admin/notifications#echo.


README.md, docs/DevEnv.md: update links to point to new ngrok CI tunnel

Signed-off-by: Bill Robinson<EMAIL_ADDRESS>

@jojimt these are the only two spots that referenced the ngrok tunnel.  No code changes in this PR.


Fix forwarding filtering in search selector

fixes #1888
The toString() function was missing on the "artificial models" returned by the forwarding service, so they could not be correctly filtered by the search selector.

Looks fine, but what's going on with the tests?

I don't know, I'm looking into it

I just missed a rename of the function, should work now. Interesting to note, however, that the prod test failed with the correct output of the error because it could not compile the code, while the dev setup only failed internally and did not output any error except the timeout in the wait-on - something to keep in mind for situations like these.


Error with dependencies in requirements.txt

First of all, thank you for huge and interesting work!
I've found some error with versions of dependensies in requirements.txt file:

If I recall correctly, I ignored this and installed transformers==4.28.0 after installing detoxify==0.5.1 and it worked fine.
For simplicity, I removed detoxify from the dependencies and added a note about the detoxify requirement in the only script of this codebase that requires it.


fix layout tag

small fixes of missing attributes in the  system

androidx.constraintlayout.core.dsl.DslTest > testOnKeyPosition01 FAILED
    org.junit.ComparisonFailure at DslTest.java:155
androidx.constraintlayout.core.dsl.DslTest > testOnKeyPositions0 FAILED
    org.junit.ComparisonFailure at DslTest.java:211
androidx.constraintlayout.core.dsl.DslTest > testOnSwipe01 FAILED
    org.junit.ComparisonFailure at DslTest.java:91
androidx.constraintlayout.core.dsl.DslTest > testOnSwipe02 FAILED
    org.junit.ComparisonFailure at DslTest.java:118
androidx.constraintlayout.core.dsl.DslTest > testTransition01 FAILED
    org.junit.ComparisonFailure at DslTest.java:54
androidx.constraintlayout.core.dsl.DslTest > testTransition02 FAILED
    org.junit.ComparisonFailure at DslTest.java:70
    ```

Not related to this PR.
It was updated by Shane


google places javadoc not found 404 & how to use API-KEY undocumented

the javadocs linked for this library are not found:
https://cloud.google.com/java/docs/reference/google-maps-places/latest/overview
also https://developers.google.com/maps/documentation/places/web-service/get-api-key says that you can use an api key, but don't understand how to use an API key in the context of the library

Hi @mh-trimble, thanks for reporting this. I asked around internally and I believe the reference documentation for maps libraries are in the process of being migrated to the new URL (something like: developers.google.com/maps/reference/documentation/{places|routing|address}/...) and should be up in the next few weeks. Apologies that the transition hasn't been smooth. Can you point us to the place where you found https://cloud.google.com/java/docs/reference/google-maps-places/latest/overview?
Also, regarding API-Keys: I believe our client libraries don't have the best built-in support for Api-Keys (as of now). I think we have a way to enable it and are looking into ways to make this better.
CC: @blakeli0 @alicejli if you have a way enable ApiKeys now for client libraries and any updates regarding ApiKeys in general.

Here is the link to the "javadocs" in the readme
https://github.com/googleapis/google-cloud-java/blob/aa25967b6482694f8ad41011c023a87bc31686e8/java-maps-places/README.md?plain=1#L191

I agree it's not straightforward to set up API Keys at this moment, and it is not documented either. I created a separate issue to track the effort of documentation.


docs: fix typo error

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
Summary
(describe what this merge request does)
Implementation highlights
(describe how the merge request does for feature changes, share the RFC link if it has)
Test checklist

[ ] add new test cases
[ ] all code changes are covered by unit tests
[ ] end-to-end tests

[ ] deploy web console with CloudFront + S3 + API gateway
[ ] deploy web console within VPC
[ ] deploy ingestion server

[ ] with MSK sink
[ ] with KDS sink
[ ] with S3 sink

[ ] deploy data processing
[ ] deploy data modeling

[ ] new Redshift Serverless
[ ] provisioned Redshift
[ ] Athena

[ ] deploy with reporting

Is it a breaking change

[ ] add parameters without default value in stack
[ ] introduce new service permission in stack
[ ] introduce new top level stack module

Miscellaneous

[ ] introduce new symbol link source file(s) to be shared among infra code, web console frontend, and web console backend

Let's fix v1.1.x first. Then we can batch merge them back to main branch.


Add option to specify the S3 data is encrypted

The data might be encrypted, so you'll have to specify 'has_encrypted_data'='true' in the TBLPROPERTIES.  I don't want too many of these recent issues I've created for creating the Athena tables, but some common situations are reasonable to handle.

cloudtrail-partititioner should deal with this


Release lock by name

Hello,
Thanks for your work with this library!
Just started learning it and have a question - I wasn't able to find mechanism how to unlock manually.
Is there available some functionality for releasing locks the same way there is for extending them?
Example what I mean:
LockManager.releaseActiveLock();
// LockExtender.extendActiveLock(Duration.ofMinutes(5), ZERO); <- similar to this
and
@Autowired LockProvider lockProvider;
lockProvider.releaseLock(name);
To be more clear why I need it:
I will listen to RabbitMQ message of type ReleaseLock(String name), and process this event by releasing a lock with corresponding name.
Thank you in advance!

Hi, the SimpleLock has unlock method. It should not be complicated to store the lock in a Map with name as a key.

Hi,
Thanks for response, but could you please provide some minimal example? I don't understand at which point and how I should store Map of SimpleLocks, and will I still be able to declare locks using @SchedulerLock annotation?

Hi, I do not understand why would you use the annotation and release the lock externally. Either the task is running and you should not release the lock, or it finished, and then you do not need to keep it.
But anyways, your use-case is not supported.

Hi,
So my use case is pretty straight forward. I'm using "shedlock-provider-jdbc-template". My batch jobs are implemented in event driven model instead of regular batch processing model (some random internet reference for similar idea https://pismo.io/blog/from-batch-jobs-to-an-event-driven-model/). That's why "Either the task is running and you should not release the lock, or it finished, and then you do not need to keep it" doesn't work in my case and I need to externally release the lock afterwards.
In my application batch job entry point is either from rest API or through scheduler, where I just publish amqp events to evenly distribute load and allow application to process everything at its own pace, because I will have plenty of different heavy jobs.
I need to lock process for the time being until it is fully processed or lockAtMostFor expired, because I don't want to spam more events until current job is finished. So shedlock works perfectly fine for making sure that job is triggered only once in clustered environment and as batch process state as whole (in progress/finished). So in cases, when I finish processing earlier (or it was failed), I would like to release lock by listening to amqp Unlock(name: String) event.
Example (Kotlin and Spring):
@SchedulerLock(name = "import_large_dataset_for_provider_id123", lockAtLeastFor = "1H", lockAtMostFor = "1H")
fun startImport(request: ImportRequest) {
val message = ImportCommand(
uuid = UUID.randomUUID(),
provider = "id123",
page = request.page,
maxPage = request.maxPage,
pageLimit = request.pageLimit
)
messagePublisher.publishMessage(message = message)
}
So if someone encounters similar needs as I do, when you require to externally unlock shedlock, I have implemented this as workaround (as I understood I don't have to clear cache, because I don't add or delete any locks, just changing "lock_until" column):
@Component
class LockManager(
private val jdbcTemplate: JdbcTemplate
) {
fun unlock(name: String) {
    val sql = "UPDATE shedlock SET lock_until=? WHERE name=?"
    val lockUntil = Date.from(Instant.now())
    val params = arrayOf<Any>(lockUntil, name)
    val types = intArrayOf(Types.TIMESTAMP, Types.VARCHAR)
    jdbcTemplate.update(sql, params, types)
}

}
So if you decide to implement some kind out of the box solution for this, it would be really cool. Anyways, thanks for help and have a great day!

no follow-up?


webpack-hot-middleware Overlay gives vague errors for tslint

If I make a mistake like not putting a newline after each line of code or a space before the start of comment, it gives me a vague error "Module build failed: Error: Compilation failed due to tslint errors." instead of the detailed error that tslint provides. Anyone know how to fix this?

you need to fix tslints error to fix this problem


add check atoms are provided to node

Can you put that inside the _post_init_ method?

converted back to draft to add cp2k_node test in the future


Double-double-underscore methods not documented

This class defines a __call__ method and is intended to be directly called by users, but the documentation for the __call__ method is omitted from the class documentation as though the method were private or absent.
Perhaps there's a flag we're not yet passing, or perhaps the class doc string should be the place to document a class' implementation of double-double-underscore methods like __call__, __iter__, and the like?

@hsaliak: this would be nice to have for GA but I think I can live with it landing soon after - do you feel similarly?

@nathanielmanistaatgoogle I think we can all live with this landing soon after. Moving it out.

There's now a simple PR that fixes this open, so, might as well stuff it back onto GA track.

Fixed in #7355. Will be fixed on master on upmerge.


v0.0.4 - CLI -v | --version results in error

In version 0.0.4, running the framework with '-v' or '--version' does not show version information but an error message as:
version.sh: line 36: CONFIG_MAP["VERSION"]: unbound variable # #

This issue was introduced in v0.0.4 when Application and Framework were separated, but loader/version.sh was not adjusted. This should be fixed in the next release.
The original, 0.0.4 code in version.sh was:
printf "\n%s version %s\n\n" "${CONFIG_MAP["APP_SCRIPT"]}" "${CONFIG_MAP["VERSION"]}"
The new code, after 0.0.4 is:
if [[ "${CONFIG_MAP["APP_SCRIPT"]}" == "skb-framework" ]]; then
printf "\n%s version %s\n\n" "${CONFIG_MAP["APP_SCRIPT"]}" "${CONFIG_MAP["FW_VERSION"]}"
else
printf "\n%s version %s\n\n" "${CONFIG_MAP["APP_SCRIPT"]}" "${CONFIG_MAP["APP_VERSION"]}"
fi
/sven


Force extra property checks if object is explicitly casted or at-least give us a StrictPropertyCheck/Exact type

TypeScript Version: 3.1.1

Search Terms: extra property checks, explicit cast, exact type
Code
interface Switch {
   on: boolean;
}
const a = <Switch>{on: false, blah: 123}; // no error, ¯\_(ツ)_/¯
const b: Switch = {on: false, blah: 123}; // error, may only specify known propery and blah is extra

Expected behavior:
Explicit cast should force extra property checks like the object literal does. I feel like TS team thinks this is intentional and may be a big breaking change.
Alternatively please give us an exact type if possible e.g StrictPropertyCheck<T> so we can do something like const b = <StrictPropertyCheck<SwitchState>>{...}
This stackoverflow thread has some magic vodoo for forcing extra property checks for functions that take arguments. https://stackoverflow.com/questions/54775790/forcing-excess-property-checking-on-variable-passed-to-typescript-function
type StrictPropertyCheck<T, TExpected, TError> = Exclude<keyof T, keyof TExpected> extends never ? {} : TError;

interface Animal {
    speciesName: string
    legCount: number,
}

function serializeBasicAnimalData<T extends Animal>(a: T & StrictPropertyCheck<T, Animal, "Only allowed properties of Animal">) {
    // something
}

Would be nice if we could have a similar mapped type that worked for objects.
Actual behavior:
No error
Playground Link:
https://typescript-play.js.org/#code/JYOwLgpgTgZghgYwgAgJIGED2BbADpkCcAHgGUw5IA+ZAbwChknmBnCyALmXMogG5GzJggIxgAcy4MhM5ABMI8AK4AbMD0gB+Lhv7IA9PrTIA7nHDzFcVevYowmZACMUbKMARgVAT2QIAFhAIANYQcshw4nCgbNx2yLhQmLjQYMAQLIKyTJB4KrzayAAUbLw6dgCUyAC8NObeArIAvlnMSrhyZcWlkACqHV0ACnBQaXAqZHZUVbXIAG6YwHICLfQI+SwsyFh4BERgk7w0wHkQ2PtbGDj4hCS6NNLMuEpOKh7IPRDlvAKtIiBuJSeTBQIpVR6yMD+YAsAB0nxqyAA8k4AFZBMCwuCbCQgIq0JoRLa6AA0yChMNh-zE4lhCmUal0FUazFWQmer3e4ggYD8ogkYLorSEUB5SigICF2Rk9OsjLsUkJ2LivBJwtZrTZbQGkBKdn6nU4yGGo2A40O1HB6qYKPRnixOPEeIpcM+ZM+Bt4zM19FW9FAkFgiBQpBMwDAAV0UuYBC4TkwmBUEHMK3oaw2xLDEf8Oxu+2QEAAHpAQHItrm9ncs5GptGmBy3ghkNzedSBVbpaKwOLJRDpZYGbYumRq-57rQDEYAOqYVThFzIEAeFDAGDk6FbEwg0LhLP+We8ou4RvhvzY3kOTDW-ux5DwFQsCBq-vZV5wfxcACMACYAMxkwxF0caAkigMkAHqAB0AH0ikAEYYKmg-RwKYABaSw4HCEQFGvIQmmfbIWjwtNfTTf5YjgRER3DGsjloW970fMk3w-ZAf1-Jo+EnICCygUCIJg+DEOQ5A1gIWInB0Uco2qOgGPGJjnHyVj2M47iQJBMlsDgXwCB8D4UgQVdfGCEBMBMSVEmSaBfHMedlOQGEC2LKA4CAA
Related Issues:
#9312, #28464

Sounds like #7481, though it's hard to tell because the example doesn't require a type assertion.

I'm not sure I understand #7481
As per the typescript play example I would like someway of telling TS to give me stricter property checks that flow through form interface to concrete implementation.
i.e
interface IComponent<State> {
      state: State;
      config: {
          defaultState?: State; // some way to say I want this strict e.g StrictPropertyCheck<State>
          template?: (state: State) => any;
      }
      update: (stateUpdate: Partial<State>) => void;
}

class Component<State> implements IComponent<State> {
    public state: State;

    constructor() {
        this.state = Object.assign({} as State, this.config.defaultState);
    }

    public get config() {
        return {
            defaultState: {} as State,
        }
    }

    update(stateUpdate: Partial<State>) {
        Object.assign(this.state, stateUpdate);
    }
}

interface SwitchState {
    on: boolean;
}

class SwitchComponent extends Component<SwitchState> {
    public get config() {
        return {
            defaultState: {
                on: false,
                blah: 123, // no error, ¯\_(ツ)_/¯  - dead code - I want TS to throw error for extra properties
            },
        }
    }
}

There's already a way to do that, though - put a return type annotation on config().
#7481 covers the pros and cons of various options here

Oh cool, that worked. The question is why is the type not inferred from the base interface. Why do I have to tell TS again ?


Convert 16-bit integer to string

Fixes #23 and also

refactor on Int8ToString - changed to macro, added fastMode, refactored with some optimizations, updated string.Int8ToString.spec.asm

All tests passed:

string.Int8ToString.spec.asm:

string.Int16ToString.spec.asm


Support compose v2..v3? versions

There is some v2 support now in lib compose upstream:
https://github.com/docker/libcompose/pull/292
we need to support all versions

Closed by https://github.com/skippbox/kompose/commit/91d981858f595243a7ea2b699d0fd064a6dff682


[WIP] datapath: Remove rev-NAT xlation from bpf_lxc ingress

test-me-please

Coverage decreased (-0.01%) to 46.763% when pulling 17d25af40e987273cebf46a06cb20c2b9d4bd354 on pr/brb/no-rev-nat-bpf-lxc-ingress into e92fd24cf5adbd7ee7acee9d243e3fc82caf3b7d on master.

test-me-please

test-me-please


Entire .git folder is distributed via Dat

This is the case for both the client and the portal:

rotonde-client instance: dat://fab5c8f60ac249ccb22e2abf650a8f7f15907aff05c4a5f3140be6abdf5c60bf/.git/
rotonde-portal instance: dat://809b8c277bbdaa05d47ade6aab2f10345b9999208f0ff73ac8eff24c0988011e/.git/

Before submitting a fix (adding the .git to the .datignore files in both repositories) I just wanted to make sure that this wasn't being done for a reason? Because Dat depends on it, for example.

i dont think dat needs .git/, it has its own versioning outside of seeding folders, you could have plain dat.json and hand-edited portal.json and it would be enough to partake in write-only rotonde (bots for example)

Thanks for the information @noformnocontent, can you see those .git folders that I linked by the way? It would appear to me as though you can only see them on your own sites 🤔

hm, no, i can see .DS_Store though what version are you on?
maybe .git/ (and .svn/ and such) included in ignore-presets of beaker itself?

I think Beaker is preventing access to the .git directory if you're not the site owner.
Even so, is it worth adding .git to the .datignore file?
I'm on the latest version (as of now). The additions of .DS* to the ignore files doesn't work retrospectively on Dat it would appear.

Seems like dat is supposed to ignore dot files and folders. So not sure how the .DS_Store managed to get in there.

...perhaps through dat sync or dat share; some testing may be needed before submitting a PR to them.


ODC-7443: Integrate metrics tab for Pipeline and Repository with Summary API

In Average duration card y-axis values and cursor pointing is not proper.

/retest

/test images

/retest

/retest

/retest

/lgtm

/retest

/retest


Updating netKAN to cope with the new Redist scheme.

Uh… I think I will need some assistance on this one.
TL;DR:
 > git fetch --tags --progress https://github.com/KSP-CKAN/NetKAN.git +refs/pull/*:refs/remotes/origin/pr/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from https://github.com/KSP-CKAN/NetKAN.git

#rebuild

Can you please tell us what this file is for? Installing files directly in GameData is prone to conflicts depending on the details.

Scale_Redist.dll is a interface that Add'Ons in need to get called by TweakScale on scaling events needs to import.
Until the moment, each client Add'Ons had their own copy of Scale_Redist. dll on the same folder their DLLs. But this is triggering an Add'On Binder Error fest on KSP >= 1.8 .
It was found that installing Scale_Redist.dll on GameData as 999_Scale_Redist.dll insteading of every Add'On having their own copy had solved the issue.

Thanks!


Add support for HTML / Vue component

After a few days used, I think XO is great, But most of our projects use Vue.
So i need to compatible with Vue component.

Why don't you just extend the xo config in your project?
//package.json
{
	devDependencies: {
		"eslint-plugin-html": "*"
	},
	"xo": {
		"plugins": [
			"html"
		]
	}
}

You could create a shareable config for Vue, ala https://github.com/sindresorhus/eslint-config-xo-react

If i want xo support vue by default, without config, what should I do?

@gucong3000 I'm not interested in having support for Vue by default in XO. That's a slippery slope. Then everyone will want support for their framework. You can easily do something like https://github.com/sindresorhus/eslint-config-xo-react and just have it in the extends XO package.json config.

It is a very cool thing that xo can use without config. It is not easy for some pople in our trem to config package.json. that is why I like xo

If you create a Vue config, all you need in your package.json is:
"xo": {
	"extends": ["vue-config-name"]
}

Yes, it is so easy to you and me, but for most front-end developer, there is to much tools need to study. In our work flow, we have 6 linter: eclint, stylelint, eslint, jshint, jscc, csslint. we have 3 build tool: webpack, gulp, grunt. they are  all need config.


Malformed YAML produced by rtyaml

Line breaks "\n" at end of line in a quoted text block failed to create proceeding "\ " at beginning of next line when dumped to file. See below example (text has been edited to protect the innocent).
  standard_key: NIST SP 800-53 Revision 4
- control-text: "The organization:\n(a) Authorizes connections from the information\
    \ security requirements, and the nature of the information communicated; and\n\
    (b) Reviews and updates Interconnection Security Agreements [FedRAMP Assignment:\
    \ at least annually and on input from FedRAMP].\nTable \a13\b‑3 CA-3 Authorized\
    \ Agreement\nName and Date of Interconnection Agreement\nN/A\nN/A\nN/A\nN/A\n\
    CA-3"

After further testing, we think the issue is with a different YAML library.


Re-enable assert_invalid and assert_malformed

Here: https://github.com/dylibso/chicory/pull/34/files#diff-fadb7963eded2e2c77d87d70b45f81ab8b4ea0cffff5a68695cead4732c5f6b1R122-R128
we are disabling those tests to have fewer exclusions and concentrate on the happy path.
We should re-enable those assertions and pass them as well.

Completed in #440


Sending an empty input in the Python console should repeat the last command

Often times we wish to execute the last command again. Right now, we need to press up to navigate to the last command then press Enter. If we support repeating the last command directly, it would be more effective. One interesting aspect of this issue is pressing up to navigate to the last command sometimes lags a bit, like half a second or so, making the entire process a bit anonying

This shouldn't be the default if it is added. Possible solutions:

make a non-default setting for the behavior
reduce the delay for up-enter so it's not as much of a blocker

This shouldn't be the default if it is added. Possible solutions:
* make a non-default setting for the behavior

* reduce the delay for up-enter so it's not as much of a blocker

Yeah a non-default settings is a good idea. The delay, though, iirc, is a bug or something (at least not an intended behavior). I will create an issue for it if I see fit

I agree that this shouldn't be default behavior. I feel like this would be pretty surprising for anyone that is familiar with other interpreters.
I'd rather we try and address whatever the delay is. I'm not seeing any locally, but none of my user profiles have a large amount of console history.
Might need some clearer repro steps before we can address the issue (assuming it's not already addressed).

I tested and found the lag is only observable when I run a debug build in CLion. Dev builds are snappy, and even if I just run the debug build directly, it shows up very quickly. There might be some issues with CLion. I am closing this because the underlying issue seems non-existent.


Explicit config binding

Currently, any subconfigs in the app's Config class are bound automatically by ConfigModule via reflection, by discovering which sub-Configs are on the app Config. While this is convenient, there are a few important consequences

It's difficult for a developer not intimately familiar with Guice and reflection to trace where a Config is bound, unless they had prior knowledge that the ConfigModule bound it all automatically
In testing, we are inconsistent about how configs are bound. Many tests do not install ConfigModule, and developers end up unknowingly relying the implicit binding of the config. This can and has caused confusion, and makes it difficult/impractical to enable https://github.com/square/misk/issues/784.
All subconfigs are available for injection, whether that is intended by the module design or not. For example, HibernateModule is meant to be qualified with an annotation, so it's unlikely that a top-level DataSourceClustersConfig/DataSourceConfig should be made injectable unqualified

I'd like us to start explicitly binding sub-configs, making it the responsibility of the Module consuming the config object to choose to whether to bind it or not. Guice is magical enough. Misk should not make it more magical, but rather be an examplar of what is the best way to use Guice.
Before:
override func configure() {
  install(ConfigModule.create("my-app", myAppConfig)
  install(MiskWebModule())
  install(KubernetesClusterModule())
}

After:
override func configure() {
  install(ConfigModule.create("my-app", myAppConfig)
  install(MiskWebModule(myAppConfig.web_config))
  install(KubernetesClusterModule(myAppConfig.kubernetes_cluster_config))
}

The downside to the explicit config binding approach is of course that there will need to be additional code added to each config.

what does installing the ConfigModule bind in the after?

This is what ConfigModule would look like after:
class ConfigModule<T : Config>(
  private val configClass: Class<T>,
  private val appName: String,
  private val config: T
) : KAbstractModule() {
  @Suppress("UNCHECKED_CAST")
  override fun configure() {
    bind<String>().annotatedWith<AppName>().toInstance(appName)
    bind(configClass).toInstance(config)
  }
}

It's possible we might not need it anymore, and we can just have it be AppNameModule(appName).

This is what ConfigModule would look like after:
class ConfigModule<T : Config>(
  private val configClass: Class<T>,
  private val appName: String,
  private val config: T
) : KAbstractModule() {
  @Suppress("UNCHECKED_CAST")
  override fun configure() {
    bind<String>().annotatedWith<AppName>().toInstance(appName)
    bind(configClass).toInstance(config)
  }
}

It's possible we might not need it anymore, and we can just have it be AppNameModule(appName).

yea I'd much rather move the AppName binding out, seems like a weird spot for it.
in the spirit of being more clear about the config, maybe we don't bind it?

What's the proposal for dealing with skim (which bundles together all of the modules required by applications, many of which require configuration)?  Since only the application knows the top-level config and the placement of the sub-configs, seems like either the application is forced to install all of the required modules explicitly (error prone) or we need to create a SkimConfig sub-config which contains sub-sub-configs for all required modules, and have the application pass this in to the SkimModule constructor.

I'd propose we add a SkimConfig. It'd be a good config parallel to SkimModule regardless.

For the purpose of the config dashboard tab, is there an way that Misk could aggregate all of the different configs for display if each sub-config is going to be bound on its own (ie. SkimConfig)? Currently it displays each of the raw config files from the filesystem (common, staging, poduction...) as well as a flattened version which is the Effective Config but there is no way right now to include and display bound configs from outside of Misk (like the database or Vitess ones applied by Skim).

is there an way that Misk could aggregate all of the different configs for display if each sub-config is going to be bound on its own (ie. SkimConfig)?

How do I look at this config tab? If it shows the full merged config, that's the top-level config, which we should still be able to bind.

But, there is no way right now to include and display bound configs from outside of Misk (like the database or Vitess ones applied by Skim)

Could you elaborate here? I'm not understanding this statement.

How do I look at this config tab?

Any deployed service's Misk Admin Dashboard: http://service.url.com/_admin/config/

Could you elaborate here?

The Effective Config displayed on the dashboard is generated here: https://github.com/square/misk/blob/fa7c583866260f1067f95f7a9af42912bfa20dfe/misk/src/main/kotlin/misk/config/ConfigAdminAction.kt
It's done by mapping over all of the local config files so the Effective Config unfortunately is a misleading name at this point because it doesn't include any config that Skim adds.


Support download folder as archive in JupyterLite

JupyerLite provides an in-browser version of JupyterLab supported by an in-browser WASM based Python environment. Notebooks can be uploaded to JupyterLite and saved to browser storage, along with edited notebooks and data files etc. Being able to easily export notebooks as a zip archive from the in-browser environment would be really useful.
Currently, using the jupyter-archive extension to download a folder as an archive file in Chrome pops up a browser status message to the effect of download.html File wasn't available on site and no archive file is downloaded.

Some comments for interested contributors:

this is not easy to achieve. Despite what it looks like for the end user, the architecture of jupyterlite does not execute any server. Therefore extensions like this one that are doing actions in the server are not easy to integrate in jupyterlite.
from the previous comment there are two ways to address this:

the better: create a jupyterlite extension that run a mocked jupyter server in a web worker using a pyodide interpreter (independent of any kernel web worker)
the hack: implement the server logic in new jupyterlite plugin - but I'd prefer to avoid this to not increase the maintenance burden.

Whatever the path, I want to emphasize that it won't be easy as it will require knowledge of storage management in the jupyterlite.


days_until_expiration reported as string by the /certs, but defined as uint64

Title: days_until_expiration reported as string by the /certs, but defined as uint64
Description:
days_until_expiration is reported as string by the /certs admin endpoint, but defined as uint64.
https://github.com/envoyproxy/envoy/blob/ab3ef829094144e41a812509c6f069b2bb9b88e8/api/envoy/admin/v3/certs.proto#L61
Repro steps:
$ mkcert localhost

Created a new certificate valid for the following names 📜
 - "localhost"

The certificate is at "./localhost.pem" and the key at "./localhost-key.pem" ✅

It will expire on 8 December 2025 🗓

$ docker run --rm -d -v $(pwd):/etc/envoy -p 9901:9901 -p 10000:10000 envoyproxy/envoy:dev-ab3ef829094144e41a812509c6f069b2bb9b88e8
603b3031d936a86902b7d335f4a699528ae9d6f10192aa19c6d58aef6f143a0b

$ cat go.mod
module envoy-admin-certs

go 1.20

require github.com/envoyproxy/go-control-plane v0.11.1
$ go mod tidy
$ cat main.go
package main

import (
        "encoding/json"
        "fmt"
        "io"
        "log"
        "net/http"

        adminv3 "github.com/envoyproxy/go-control-plane/envoy/admin/v3"
)

func main() {
        resp, err := http.Get("http://localhost:9901/certs")
        if err != nil {
                log.Fatal(err)
        }
        defer resp.Body.Close()

        body, err := io.ReadAll(resp.Body)
        if err != nil {
                log.Fatal(err)
        }

        var certificates adminv3.Certificates
        if err := json.Unmarshal(body, &certificates); err != nil {
                log.Fatal(err)
        }

        fmt.Printf("%+v\n", certificates)
}
$ go run main.go
2023/09/08 17:49:02 json: cannot unmarshal string into Go struct field CertificateDetails.certificates.cert_chain.days_until_expiration of type uint64
exit status 1

Admin and Stats Output:
$ curl -s http://localhost:9901/certs | jq '.certificates[].cert_chain[] | {days_until_expiration}'
{
  "days_until_expiration": "821"
}

Config:
$ cat envoy.yaml
admin:
  address:
    socket_address:
      protocol: TCP
      address: <IP_ADDRESS>
      port_value: 9901
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: <IP_ADDRESS>
        port_value: 10000
    filter_chains:
    - transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            tls_certificates:
            - certificate_chain: {filename: "/etc/envoy/localhost.pem"}
              private_key: {filename: "/etc/envoy/localhost-key.pem"}
            alpn_protocols: ["h2,http/1.1"]
      filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_admin
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: local_admin
    connect_timeout: 5s
    type: STATIC
    per_connection_buffer_limit_bytes: 32768 # 32 KiB
    load_assignment:
      cluster_name: local_admin
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <IP_ADDRESS>
                port_value: 9901

I found that a protobuf field of type uint64 is encoded as string in json according to the proto3 json mapping guide:
https://protobuf.dev/programming-guides/proto3/#json


Proxy failed

Hello, I am a nativ file compiled from your source code. When I use it in my project, I use global mode,If you enable disabling yourself, you can successfully proxy, otherwise you cannot.
If the following code is added, the proxy will succeed; otherwise, the proxy will fail
String selfName = getApplicationContext().getPackageName();
try {
builder.addDisallowedApplication(selfName);
} catch (NameNotFoundException e) {
e.printStackTrace();
}

Bypass VPN application itself is required because the upstream sockets are not marked as protected.

绕过 VPN 应用程序本身是必需的，因为上游套接字未标记为受保护。

ok


identity_license: prevent send on closed channel

I've occasionally been seeing the following panic when running identity_license:
panic: send on closed channel

goroutine 51 [running]:
github.com/google/licenseclassifier/tools/identify_license/backend.(*ClassifierBackend).ClassifyLicenses.func1.1(0xc0043a1910, 0xc003466900)
        licenseclassifier/tools/identify_license/backend/backend.go:82 +0x4e
github.com/google/licenseclassifier/tools/identify_license/backend.(*ClassifierBackend).ClassifyLicenses.func1(0x7ffeefbff9b9, 0x13)
        licenseclassifier/tools/identify_license/backend/backend.go:87 +0xb8
created by github.com/google/licenseclassifier/tools/identify_license/backend.(*ClassifierBackend).ClassifyLicenses
        licenseclassifier/tools/identify_license/backend/backend.go:92 +0x1ea

The commit message explains this issue and the fix:
The analyze function calls Done on the waitgroup and then opens up
a new slot by writing into the `task` channel. If this is the last
goroutine running, this can cause an issue: there is a goroutine
running that is waiting for the waitgroup to yield. After this it
closes the `task` channel. If it gets closed before the
`analyze` goroutine manages to send true into the channel, a panic
can occur.

The channel send and `wg.Done()` call could be re-ordeded, but also
there is no strict need to close the channel in this instance, as
there is no receiver for it after this point.

Happy to adjust to something else if there are different opinions on how to deal with this.

Bill,
Can you take a look?

While I agree with your analysis regarding the fact that the close is unnecessary, the fact is that you had to make that argument rather than swap the order of wg.Done() and the channel send. That suggests that swapping the order is simpler and more reasonable for future maintainers to understand and follow.

I was very much in two minds about it, so no issue with that.

A similar argument could be made for not closing the errs channel. Closing one channel but not the other naturally invites questions and potential confusion.

Not that it matters much, but the errs channel very much has to be closed to allow the loop over it to finish up. The code operates on these channels in different ways, so you'd hope it wouldn't cause too much confusion. Still, happy with the proposed change.

Yes, my bad on that comment about the errs channel. Without the close on the channel, the range loop would never complete.
FYI, my current thinking with this code would be to limit the number of goroutines being created to the constant figure. If there were a large number of files, creating an equally large number of goroutines, the vast majority of which are blocking uselessly is just wasteful. That would eliminate the tasks channel entirely.
Thanks for identifying this bug and fixing it!

Sorry about the closing/reopening, haven't done a GitHub review in a while.


Drop loop kwarg from async_timeout.timeout

async_timeout 4.0.0 drops the loop= kwarg and will fail if its passed

Hi, would it be possible to merge this pull request ? It is filling the logs on restart for home assistant.
Thanks

@Cinntax any chance we could get this pulled in?

Apologies for holding everything up- @bdraco @tech165 @bbrendon @camrun91 . Let me get a new release of this on pypi so it can be put into HA.

@Cinntax Thanks for your help.  Do you think this issue is causing the periodic disconnects/re-connects?

@Cinntax Thanks, greatly appreciated :)
@raspman I did not have any connections problems on my side, just warnings in the logs.  So I'm guessing this won't solve your issues.

I'm not sure about that.  I can tell you that this warning comes at almost the exact same time as Envisalink disconnects and gives an error.  It appears based on this there is a correlation.  The disconnect is very short (3 minutes and it's back up.)
https://github.com/home-assistant/core/issues/62686
021-12-23 00:34:53 ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting...
2021-12-23 00:35:23 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.
Stack (most recent call last):
File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/homeassistant/homeassistant/main.py", line 331, in
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/main.py", line 318, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
self._run_once()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
handle._run()
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 83, in reconnect
await self.connect()
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
report(
File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
_LOGGER.warning(msg, stack_info=True)
Stack (most recent call last):
File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/homeassistant/homeassistant/main.py", line 331, in
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/main.py", line 318, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
self._run_once()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
handle._run()
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 83, in reconnect
await self.connect()
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
report(
File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
_LOGGER.warning(msg, stack_info=True)

Just an FYI- I haven’t been able to push a new version to pypi yet- they seem to be having an outage. So I’ll keep an eye on it- and deploy version 4.2 ASAP.

Looks like everything is back up again- so version 4.2 has been released and can be used in HA!

How do you update this in HA?  Does this resolve the disconnect issue?  I just updated to 12.6 and still getting:
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:74
First occurred: 11:52:49 AM (1 occurrences)
Last logged: 11:52:49 AM
Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.

@tech165 I'm in agreement with you at this point.  I've tried HA 202.11, because at least one person reported no more errors with this version, and I'm still getting (errors) disconnects, even without the warning I believe the above is supposed to fix:  2021-12-23 00:35:23 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.
In other words, even without this warning, I'm still getting the disconnects. I was hopefully there would be a solution to this, but after experiencing this for about a month, I'm thinking Envisalink won't be working with HA the way I need it to.

@tech165 I'm in agreement with you at this point.  I've tried HA 202.11, because at least one person reported no more errors with this version, and I'm still getting (errors) disconnects, even without the warning I believe the above is supposed to fix:  2021-12-23 00:35:23 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.
In other words, even without this warning, I'm still getting the disconnects. I was hopefully there would be a solution to this, but after experiencing this for about a month, I'm thinking Envisalink won't be working with HA the way I need it to.

Adding that in case the fix has been implemented, I am actually still getting the error. I am running all the latest versions on Home Assistant
2022-01-13 13:21:35 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.
Stack (most recent call last):
  File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 331, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 318, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
    handle._run()
  File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
    async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
  File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
    _LOGGER.warning(msg, stack_info=True)
Stack (most recent call last):
  File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 331, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 318, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
    handle._run()
  File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
    async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
  File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
    _LOGGER.warning(msg, stack_info=True)


Pull request for dl+remote

Allow download to configure other people remote
setup remote when downloading pull request

Looks like the local_branch_name must be the same as remote to have git push working without any param

@sileht you got a conflict, just ping me when you're good i'll +1 or go ahead with no-review-needed.


Issue96 update

Summary: Fixes a bug in the update function caused by UUID handling
TODO: Fix Namespace handling
Related issue:
Closes #96
Suggested reviewer(s):
Reviewer checklist:

[ ] The headers of all files contain a reference to the repository license
[ ] 100% test coverage of new code - meaning:

[ ] The overall test coverage increased or remained the same as before
[ ] Every function is accompanied with a test suite
[ ] Tests are both positive (testing that the function work as intended with valid data) and negative (testing that the function behaves as expected with invalid data, e.g., that correct exceptions are thrown)
[ ] Functions with optional arguments have separate tests for all options

[ ] Examples are supported by doctests
[ ] All tests are passing
[ ] All names (e.g., files, classes, functions, variables) are explicit
[ ] Documentation (as docstrings) is complete and understandable

The checklist is based on the S-ENDA conventions and definition of done (see General Conventions). The above points are not necessarily relevant to all contributions. In that case, please add a short explanation to help the reviewer.

Need to discuss namespace handling with @mortenwh

Need to handle search in CSW (For update and delete) with Namespace:UUID.

PropertyIsIn is not implemented it seems, so we create namespace+:+UUID from incoming request, since we can only do exact matches with PropertyEqualsTo

See my comment in #96 - PropertyIsEqualTo should be used as before. Old registrations should be updated.

See my comment in #96 - PropertyIsEqualTo should be used as before. Old registrations should be updated.

Yes. This is now implemented, with namespace-handling


Fix #41 and add Force to overwrite existing file

Fixes https://github.com/aaronparker/LatestUpdate/issues/41 and adds the -Force param to overwrite already existing downloaded files.

The "Multiple URLs will be handled" edit simply puts the $update.URL into a foreach block.

No idea why the comparison show so many differences while there hasn't been changed that much as you can see here: https://github.com/f0nt4/LatestUpdate/blob/patch-1/LatestUpdate/Public/Save-LatestUpdate.ps1


Added integration tests

In order to properly patch #96, we need support for integration tests. Otherwise, iterating and reproducing edge cases will significantly slow down development. This PR adds support for that by adding in Selenium and setting up a basic integration test.
In this PR:

Added Selenium download/setup scripts
Added integration tests
Added documentation for testing and integration tests

/cc @wlaurance

Hmm, the tests seem to be failing but I am out of time for tonight. I will take another look tomorrow.

Alright, tests are good now. We needed to start an X11 server in Travis CI.

This PR had some spaces lurking in it. This has been fixed.

OK cool. I see this is a dependency of #110. I will merge/release tomorrow (well today, in the morning)

I can also merge/release. All I need is a :+1: or "looks good to me" =P
But releasing for me right now isn't so great either (in case something breaks in 1 or 2 hours).

:+1: =P


Use 'terraform-python-testing' (tftest) package for testing Terraform install

Replaces terratest files in the tests directory with a python script and a requirements.txt file.
The python script test_terraform_install.py performs the init, plan and apply Terraform commands.  The Terraform output is verified.
The lambda is also invoked.  Given that the lambda's event is difficult to manufacture and we don't want to actually perform the functions in the lambda, the test creates a bad event and checks the resulting exception to verify that the lambda ran and detected the error.

I forgot to add notes in the README regarding testing, but I'm wondering if the Makefile is sufficiently clear.

Looks great, no further suggestions or questions. Will hold approval until the terratest version is ready for comparison.

This is a PR on a non-master branch.  So it could be approved for this branch.  The idea is to preserve it whether it's used or not.


Registering an EventListener

I have read this manual https://neo4j.com/docs/ogm-manual/current/reference/ on Neo4j official page and I think it could be extended a little bit. I have needed an UUID so it was quite useful.
In the part 3.10.3. Registering an EventListener an example was given:
`class AddUuidPreSaveEventListener implements EventListener {
void onPreSave(Event event) {
    DomainEntity entity = (DomainEntity) event.getObject():
    if (entity.getId() == null) {
        entity.setUUID(UUID.randomUUID());
    }
}
void onPostSave(Event event) {
}
void onPreDelete(Event event) {
}
void onPostDelete(Event event) {

}`
I think it is not obvious that I should implement UUID serialization before. I would offer to write
entity.setUUID(UUID.randomUUID().toString()); so that people can copy and paste it directly.

If there is any need, we would change the documentation but in general the example is ok. For custom ids a org.neo4j.ogm.id.IdStrategy should be used now.


Replace override with with in Post View Composer

[x] I've read the guidelines for Contributing to Roots Projects
[x] This request isn't a duplicate of an existing issue
[x] I've read the docs and followed them (if applicable)
[x] This is not a personal support request that should be posted on the Roots Discourse community

Description
Replace override with with in Post View Composer.
Shouldn't the default Post View Composer just come with a with method instead of a override to be less restrictive see:
https://github.com/roots/sage/blob/24ac51d510acf81a716e5fdd0cd0ae0b0256bdd3/app/View/Composers/Post.php#L25?
Especially because the View Composer uses the wildcard in the partials partials.content-* in
https://github.com/roots/sage/blob/24ac51d510acf81a716e5fdd0cd0ae0b0256bdd3/app/View/Composers/Post.php#L17
and therefore does not allow to override the i.e. title that has been defined in Post at all.
If you want to set the title of a partial template, say partial.content-foo by using a custom View Composer say Foo which implements the override method, the overriding will not have any effect.
This is because the override has already been set in Post
Steps to reproduce

Create a View Composer with the name of your choice
Create a override method in your custom View Composer that returns a custom title in a template that is located in partials/ and starts with content-
Check if the title has been overridden in frontend

Expected behavior:
The title should be overridden, and should reflect the output coming from your custom View Composer (see 1.) )
Actual behavior:
The title comes from the Post View Composer.
Versions
Sage 10.0.0-alpha.1
Additional information
Not really a "bug", i would say. But confusing though...

Why is it closed? Exactly used the issue template... 😕

closed it by myself because its a duplicate of #2524


Turn SearchType variable into an int

not that it matters much but heh

Coverage remained the same at 24.323% when pulling a249114b6dc017ed5531a7ca0aa35fecfea6f612 on Kiloutre:patch-31 into 199d2b3b85abc52ffd2071ae894319d426b73e14 on NyaaPantsu:dev.

Coverage increased (+9.2%) to 33.478% when pulling b1db0a8c17d7ef8586bb3e2492de2a76870a30a6 on Kiloutre:patch-31 into 199d2b3b85abc52ffd2071ae894319d426b73e14 on NyaaPantsu:dev.

Coverage remained the same at 33.478% when pulling 638d97cfda2924ac1fc1481803d36681f7da5458 on Kiloutre:patch-31 into c49fba015cfdc03acc511d966062362e977238d1 on NyaaPantsu:dev.


Error "Invalid rust file" if any non rust file is in the src folder

I don't think it's reasonable that build should fail in these cases:

case 1: when using with cxx crate, there are normally c++ files in the src directory or any subdirectories.
case 2: sometimes MacOS creates a hidden .DS_Store file in the source folder.

It can be quickly fixed by adding a file extension check in generator_lib.rs:visit_dirs(dir,cb) function:
            if path.is_dir() {
                visit_dirs(&path, cb)?;
            } else if path.ends_with(".rs"){
                cb(&entry);
            }

Hi there, thanks for the suggestion.
I'm not currently with my pc. Could you please create a pr so I update the repository?


CSS absolute paths

Problem
Using CSS absolute paths, eg. background-image: url(images/loginBackground.jpg); is pretty common, both on the web and within Cordova.
However, when running CHCP, absolute paths will no longer work as the content and index.html is moved to a deeply nested folder location.
I'm wondering, would it be possible for CHCP to intercept or otherwise mirror the latest version of an asset to the root of the absolute path? Got any other ideas for how to work around relative paths?

I can't intercept these on the native side, but it might be possible by running some local web server in the app, that will do the mirroring. But feels a bit hacky...
Other hack can be to read all css/html files when they are being installed and modify paths in them if they are absolute. But again, it's a hackish way that adds complexity and additional layer of probable errors.

Thanks for your comments. I agree that both potential solutions are overly-hackish.
Anyway, solved this by reapplying paths dynamically at runtime in javascript. You might want to add a note about it in the documentation, as this was pretty confusing to debug. Closing issue.


I found a progress bar problem!

barContainer, _ := multibar.New()
	go barContainer.Listen()
	barProgress1 := barContainer.MakeBar(10, "总任务")
	wg := &sync.WaitGroup{}
	wg.Add(1)
	go func() {
		for i := 0; i <= 10; i++ {
			barProgress1(i)
			time.Sleep(time.Millisecond * 15)
		}
		wg.Done()
	}()
	wg.Wait()

result
总任务 100% [====================================================================] 179ms

// time.Sleep(time.Millisecond * 15)

result
总任务  90% [================================================>--------------] 43ms

I assume that this is a race between the terminal being updated and the termination of your main().
I don't have any plans on making any updates to this package at this time (too busy with other things). Any PRs submitted, I'll try to review them.
Cheers.

Thanks.