Rustup

also more ABI compat tests

@bors r+

:pushpin: Commit 1944cc221a3eb0fad5739b9dec73f6af817bb616 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 1944cc221a3eb0fad5739b9dec73f6af817bb616 with merge 2d6e41d47586a5edb3a301f4c37d4f8fff7ee4a9...

@bors r-

:pushpin: Commit 26972ccf946de71aeab858cc59957d3f9063c9f2 has been approved by RalfJung
It is now in the queue for this repository.

@bors r+

:pushpin: Commit 533e0a468852fbd1b67e311f3e8bb5aa2047eba7 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 533e0a468852fbd1b67e311f3e8bb5aa2047eba7 with merge b31c92ad158b9b6ac0e18c0e4a352e68571a5095...

:broken_heart: Test failed - checks-actions

Ah, we're running into https://github.com/rust-lang/rust/issues/115404
@bors r+

:pushpin: Commit 7c7219cec183e9f4442b97836495eab4a6e01121 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 7c7219cec183e9f4442b97836495eab4a6e01121 with merge ecff95699d80f106c0c47a45de5f6367f7f0adfa...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing ecff95699d80f106c0c47a45de5f6367f7f0adfa to master...


Rem densel1

Codecov Report

Merging #276 (1242dee) into breaking-02 (9280e6f) will decrease coverage by 0.62%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           breaking-02     #276      +/-   ##
===============================================
- Coverage        71.91%   71.29%   -0.63%
===============================================
  Files               14       14
  Lines             1948     1937      -11
===============================================
- Hits              1401     1381      -20
- Misses             547      556       +9

Impacted Files
Coverage Δ

src/norm_oracles.jl
95.45% <ø> (-0.42%)
:arrow_down:

src/utils.jl
54.24% <0.00%> (-1.65%)
:arrow_down:

src/blended_cg.jl
50.13% <0.00%> (-0.80%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9280e6f...1242dee. Read the comment docs.


Create Pyramids Generator

https://github.com/airlab-unibas/airlab/blob/1b92e99c8a0761569586e5a572f88ec19a3ae404/airlab/utils/image.py#L317
Is it possible to turn the iterator returned by this function into a generator to perhaps save some memory, curious on your thoughts. Awesome package!

Hi, that is a great idea. Thanks


What happens if a resource fails? Azure QnA Bot

I'm following the following lab: https://github.com/Microsoft/computerscience/blob/master/Labs/AI and Machine Learning/Azure Bot Service/Azure Bot Service.md
And on the step "Creating a QnA Service" I actually get a failure:

I actually don't know how to proceed now.

Should we add in information about what to do if they run into failures?

I'm running this lab on a student account.

Probably, but also, this has been migrated to Learn!


Refine is_fpu_used logic to handle eager fpu.

Hi, Ning,
This refines detection of guest fpu usage. Old haxm seems to rely on guest setting CR0.TS and trapping exception 7.
I know there is a patch for forcefully turning on fpu save/restore. I do not have any preference to either solution. I just uploaded mine in case you want a friendly version towards non-fpu usage guests.
Haitao

This is indeed a nicely crafted patch that honors the original HAXM design and fixes vcpu->is_fpu_used. However, we still prefer the existing solution (#85), which is to unconditionally save/restore FPU state at every VM exit/entry, after considering both code complexity and performance.

The unconditional approach is definitely simpler :)
The unconditional approach does not depend on guest behavior, and therefore is compatible with all guest OSes.
Performance-wise, the unconditional approach should be more or less the same as the conditional approach:
i. Note that once is_fpu_used is set, it's never reset. Therefore, for a guest that does use FPU/MMX/SSE instructions, after the first use of such an instruction is detected by HAXM (is_fpu_used = 1), which usually happens very early during the lifetime of guest, both approaches will behave like the unconditional approach, and will have the same FXSAVE/FXRSTOR overhead.
ii. While reviewing PR #85, I actually thought about minimizing FXSAVE/FXRSTOR calls by only saving the guest FPU state when it's dirty. That would require properly clearing is_fpu_used and trapping #NM / CR0.TS = 1 for every "session" of guest execution (i.e. between every VM entry and exit), essentially implementing something similar to Linux's lazy FPU mode. However, Linux itself has dropped lazy FPU mode in favor of eager FPU mode, mainly because the former doesn't really offer better performance, especially on recent hardware. See commit messages here and here. Therefore, we thought we should also take the eager/unconditional approach.

I agree and I prefer the simple fix too. I believe it is not a perf issue on modern CPUs for eager save/restore. Going further to runtime "eager save, lazy restore" is far too complex. Some time being simple is the king, even by paying a little bit for that.
However, I think I have shown where HAXM has done wrong by this fix. Be it simple or complex, hypervisor should not make assumptions on guests behavior. It is not about which way to go. It is about doing things right. :)

I think I have shown where HAXM has done wrong by this fix. Be it simple or complex, hypervisor should not make assumptions on guests behavior. It is not about which way to go. It is about doing things right. :)

True :) Closing this PR now.


Migration Handling: New Attributes

After a (Light / Heavyweight) migration, the Data Model might get:
Attributes Removed:
This is currently supported, and no further action is required.
Attributes Renamed:
If we are to support backwards compatibility, the app needs a mechanism to map the "Remote Attribute Name" into the "Local and New" attribute name. We'll add support for this, in Issue #480.
Attribute Addition:
The first client that gets 'New Attributes' will work without further issues. But if there are (still) clients using the old data model, any changes they get over the "New Attributes" will, expectedly, fail.
In this particular case, the Ghost Data is expected to be updated, nevertheless. Let's implement a mechanism that:

Detects that a migration has occurred
Goes through the Ghost Data, and attempts to populate the "Newly Created Fields" (that were already being in use by other clients)

Hi @jleandroperez,
Nice to see all the improvements and continued development on the framework!
Keep up the great work!
Regards,
Patrick

Thanks for the feedback @prvnl!! Hope you're doing (more than) great sir!

Just one thought: Rather than detecting migrations (not completely sure if this is possible in the extend you'd need), what about saving the failing changes (those that cause the applyDiff for a member that doesn't exist warning) in some queue and once the attribute gets available (which you could check upon every cold launch, for example), try to replay them?
But, then again, I have no idea of how the internals of Simperium work, so that's probably not very useful. ;-)

@danielr the remote state (should be saved) within the ghostData field.
Perhaps migrations could be detected by means of NSStoreModelVersionIdentifiersKey (that, as far as the documentation tells, should live within the NSPersistentStore's metadata.
On migration we could just fire a process that (perhaps) would detect added fields, and replay the remote changes.
This definitely requires a bit of R&D, but at first glance, seems achievable!. Thanks for your feedback!


search page

search\templates\search\search_new.html
http://localhost:8001/search/
major remake: search results w/filters + new search
NB. modeled on 'typical' library search interfaces
5 screen elements

(1) search input w/advanced options in expanding div 'dropdown'
(2) result facet filters
(3) results in scrolling table of result 'cards'

click card, some detail in lower right (5); geometry focused in map (4)
click link to go to Place Portal

(4) map shows geometry of all initially

click marker, list scrolls to result

(5) detail preview (?); more detail than card, less than Place Portal

Things yet to be addressed:

[ ] I've adjusted the code to save the search term as an additional FeatureCollection property in localStorage: it might be a good idea to save the checkbox states too, so that revisiting will load the same feature set.
[ ] Clicking on the empty search box triggers a search (should it wait for at least 3 characters, [Enter], and/or a click on the magnifying glass?).
[ ] Clearing or otherwise editing the contents of the search box does not clear the results.
[ ] There ought to be a +/- map zoom control.
[ ] Should there be a temporal control to filter results?
[ ] There is as yet no portal page (e.g. http://localhost:8001/places/13208854/portal), but I've coded the links.

sounds good
also good
first though is existing results needn't clear until a new result set arrives
sure
no need right now; let's revisit later
I've been working on the way to navigate to the portal page with all the relevant pids; it is highly likely this work would step on what you've done, there is overlap. I suggest you take this to a wrapped-for-now stage, and issue a PR. I would then have to ensure the links in the result divs return all the detail required for the portal page. So I could do the "on top of" your PR branch, verify it all works, and merge back to staging when it does.

TODO

[ ] Temporal control to filter results


Would you please provide a gl-matrix.d.ts file because I want to use glMatrix.js in TypeScript?

Hi,
Would you please provide a gl-matrix.d.ts file because I want to use glMatrix in TypeScript?
Thank you.

I just added a pull request to DefinitelyTyped that contains all 2.3.0 definitions, with a different (stronger) typing approach than the previous definitions. I hope it is more along the lines of the author's intention: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/10166

It appears that the version on the DT repository is incorrect. It does not include the module "gl-matrix" so TypeScript emits a "can't find module" error. I have corrected what I needed to to get it working. There may be other things that are omitted, but it is a start.
gl-matrix.d.ts.tar.gz


on run :Prettier command weird characters added at the beginning of the file

"^[[5 q" added to the beginning of the file:

the problem was this snippet to change the cursor style in my .zshrc, has nothing to do with vim-prettier, going to close the issue

i my case running prettier was add >4;m[>4;2m syntax in place of cursor.
Fixed it by adding below lines in my .vimrc
let &t_TI = ""
let &t_TE = ""


docs: update README.md to add missing service account role

Fixes #39

Thanks for the fix, @kweinmeister! I added some additional updates based on changes in the setup


[YUNIKORN-374] Use same GRPC version in the core and the scheduler-interface

Hey @yangwwei,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 6a7ad820-e735-11ea-b1e9-0f855a8df5b8

Hey @yangwwei,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 08bb1820-e73a-11ea-b1e9-0f855a8df5b8

This change is looking at the GPRC version why are we making changes to the prometheus version also? The prometheus changes are handled under YUNIKORN-375. Can we split these two as per the jiras?

hi @wilfred-s sure. Let me split the changes. Now the change only include the gRPC version update. Pls take another look.

Hey @yangwwei,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: ed4c4850-e754-11ea-b1e9-0f855a8df5b8

Hey @yangwwei,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: bee6a370-e808-11ea-a3ad-29627dfdd765


add notifications for users of amber

This just works if the user checked the remember my choice for decrypting nip44
I havent found a way to open amber when amethyst is in background. Seems to be a limitation since android 10

This account-switching business in a singleton is probably not a good idea.
I am a little worried the cachedDecryptedContent will leak between accounts. Maybe we should break the signer into the singleton/service part and the cached part, which should be per account.


[WiP] Moving engine subsystems to API library.

when do we use hungarian notation vs lowerCamelCase?
Hungarian notation for private/protected members, camelCase for local variables and public memebers.


[mongo-cxx-driver] Do not delete the third_party include folder when building with mnmlstc

Building with the mnmlstc feature enabled, which is default for non-windows builds, will delete the third_party/mnmlstc folder which is required

+1. I was going to do the same pull request.

Thanks @lsparey!


Jsc/tags report

Closes #515
And correct auth on wrong action.

But not any of the OTHER roles. Jeremy requested we create this so non-admins can discover the tags the team has. He objected to the typeahead tags box. Thought it should either be a drop down multi select or create this report.

@jSylvestre is right. Tags are a drop down pick-list already.


Update Branding to DCS

Story
As a user I want to know what to call the site at git.door43.org so that I can reference it easily.
Notes
The site at git.door43.org is called the Door43 Content Service.  The abbreviation is DCS.  Everywhere that is appropriate we need to refer to the site and code as DCS.  Sometimes the long version, Door43 Content Service, may be used.
These locations need updated:

[x] New DCS logo should be used
[x] Home page should refer to itself correctly.
[x] About page should be the same as Home page.

The README in this repo needs to refer to itself correctly.

DCS svg.zip

Is there a small square logo that we can use in the upper left when logged in and for the favicon?

@jag3773 ^^^

Favicon from @Thajny

Note, there is a new Wiki page to use DCS everywhere on git.door43.org, but won't be used until this update is put into production, as it uses a new URL for the "About DCS" at the top:
https://git.door43.org/Door43/pages/wiki/Welcome-to-Door43-Content-Service!
This one should be edited for future changes, and it is the one that is similar to the "Home" page when not logged in.

@Thajny, @richmahn,  Have you considered the issue of favicon size and compatibility? This S.O. post is a good place to start: https://stackoverflow.com/a/23734416/4650008.

Actually have an .svg file from @Thajny but github won't let me upload. It's in at https://team43.slack.com/?redir=%2Farchives%2FG1T8J0CET%2Fp1496843800134565

@phillip-hopper Shouldn't this then be an issue with upstream gitea as well? Don't think they do anything more than a 30x30 favicon.png file.

@phillip-hopper Actually their icon, https://try.gitea.io/img/favicon.png is 143x143. @Thajny can we get a bigger resolution at least? That is why I asked for a 200x200, but 143x143 would be fine.

@richmahn Maybe our target audience is such that this won't matter, I'm not sure. It may be a good idea to consider the nuances of how the site will appear on different devices, beyond just the page layout.

@phillip-hopper Understandable. I think we should at least keep it to why Gitea decided on 143x143 (not sure why the magic number), as maybe that at least handles different devices and lets the image tags and browser tab resize as needed.

@richmahn & @Thajny, this is the list of icons from youtube.com, just so we are all on the same page:
<link rel="shortcut icon" href="https://s.ytimg.com/yts/img/favicon-vflz7uhzw.ico" type="image/x-icon">
<link rel="icon" href="/yts/img/favicon_32-vfl8NGn4k.png" sizes="32x32">
<link rel="icon" href="/yts/img/favicon_48-vfl1s0rGh.png" sizes="48x48">
<link rel="icon" href="/yts/img/favicon_96-vfldSA3ca.png" sizes="96x96">
<link rel="icon" href="/yts/img/favicon_144-vflWmzoXw.png" sizes="144x144">

143x143 like Gitea has:

@phillip-hopper I'm more for making this change in upstream so we don't have conflicts in the header here. Then we just change the favicon_42.png or whatever, which is less likely to changein upstream.


Add minecraft:dimension_bound entity component

Using by the fishing_bobber and creaking. No properties, just a basic component that prevents a mob from changing dimensions

I added documentation for this in my Pull Request and am just waiting for it to be reviewed.


peek_messages

From my testing it looks like peek_messages method is returning max 250 queue message. It would be nice if this was added to the documentation under max_message_count.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ec48c175-0e94-dbfd-e3b2-6ab2639ab89a
Version Independent ID: 8bfacb3c-7a43-6bb3-c39b-ab6b751d83ac
Content: azure.servicebus.ServiceBusReceiver class
Content Source: docs-ref-autogen/azure-servicebus/azure.servicebus.ServiceBusReceiver.yml
GitHub Login: @lmazuel
Microsoft Alias: lmazuel

Hey, @daniwk. Thanks for the feedback! I'll tag some people who may be able to help.

Thanks for this @daniwk. I've reached out to the service team to see if there is a hard coded value for this on the service side. It could very well be possible that this value fluctuates based on a number of factors such as message size, network  etc. Were you always testing with the same messages or number of messages ?

Just wanted to update: Im waiting to confirm with the service team if this indeed the behavior from their end. I can repro this on python as well as dotnet. Thank you :)

Hi @daniwk, wanted to give you an update on this. The limit of 250 messages for peek is by the service and not the SDK. I've asked the SDK team to update the documentation on their side to reflect that limit. In the meantime we've updated the API docs to point to that documentation and also add some clarity around max_message_count. Thank you 🙂


Investigate allocation patterns and consider changing an allocator

This umbrella issue is about taking a closer look at how many allocations our driver performs. While investigating with https://github.com/psarna/trace_alloc, one obvious conclusion was that https://github.com/scylladb/scylla-rust-driver/issues/408 is going to help, because current load balancing is responsible for ~40% of all allocations in certain workloads.
However, we should investigate more and perhaps recommend using a different allocator for our driver, or even go one step further and start using https://crates.io/crates/jemallocator or a similar crate in order to pull in an allocator that better suits our needs.
As a very simple test, I ran our benchmarks (https://github.com/psarna/rust-driver-benchmarks, fork of https://github.com/cvybhu/rust-driver-benchmarks) example with and without jemalloc (provided externally by the LD_PRELOAD trick, LD_PRELOAD=/usr/lib64/libjemalloc.so.2  ./target/release/basic -d -n <IP_ADDRESS> -t 10000000), and the results are as follows:

with the default allocator, it takes > 30 seconds to finish 10M inserts
with jemalloc, it takes ~23 seconds

While a fair part of the allocations is our load balancing, which may significantly change after #408, after it's resolved we should get back to this topic and figure out if our allocation patterns aren't a very good fit for jemalloc, which is adapted to serving lots of small allocations and to items with fixed size.
Bonus: running a binary which uses jemalloc with MALLOC_CONF=stats_print:true env variable prints lots of valuable stats. It can also be combined with LD_PRELOAD, as in MALLOC_CONF=stats_print:true LD_PRELOAD=/usr/lib64/libjemalloc.so.2  ./target/release/basic -d -n <IP_ADDRESS> -t 10000000

I don't think you can have a per-crate allocator. AFAIK allocators are set globally, so in the end the developers of binary crates should be allowed to choose. We can give recommendations in the readme, though.


fix [IDP] : Updated the what's supported for git providers in IDP

Harness Developer Pull Request
Updated the what's supported for git providers in IDP
What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6594eb2389d89957ed20c06f--harness-developer.netlify.app


✨ Support RTL languages

@damianpumar
"
OH! In that case, it'd work just fine 👌. The main problem with the unmatched text direction is the (somewhat) unpredicted cursor. Like having the last character at the beginning of the sentence, for example. With that being out of the equation now, we get a more reliable cursor and span selection should work as expected.
Also the snap feature is really great 💥
"


weaver: Multiple files web page.

Hi guys, I'm thinking of using weaver for an html to pdf conversion. The html file I'm going to convert is not hosted in a webserver so I was planning on sending it to the server using the convertByFileHandler.

You have two options (out of the top of my head):-

Inline all your assets: I'm unsure if there's an 'automated' way out there to do this, but the resulting file size might be huge because of the base64 images
Save the page as MHTML: on Chrome, you might have to enable this feature on chrome://flags/, but once you save the page as MHTML, you should be able to convert it to PDF by passing an additional ?ext=mhtml parameter

Let me know if that helps.


[NO_ISSUE] Change log level from error to debug inside ImportDMNResolverUtil

Currently, the ImportDMNResolverUtil#resolveImportDMN(Import, Collection<T>, Function<T, QName>) log an error message if a matching imported model can't be found in the given Collection.
Unfortunately, the DMNValidatorImpl#processDMNResourcesAndValidate(DMNMessageManager, List<DMNResource>) (indirectly) invokes it with an empty collection, always leading to misleading "error" message logged.
That message logging has been introduced recently, but the actual behavior did not change, so setting it to "debug" has not any backward/behavior impact.

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

for pull request and downstream checks

Push a new commit to the PR. An empty commit would be enough.

for a full downstream build

for github actions job: add the label run_fdb

for Jenkins PR check only

If you are an ASF committer for KIE podling, login to Jenkins (https://ci-builds.apache.org/job/KIE/job/drools/), go to the specific PR job, and click on Build Now button.

kogito-runtimes failure unrelated
apache_incubator-kie-kogito-runtimes/jbpm/jbpm-tests/src/test/java/org/jbpm/bpmn2/StandaloneBPMNProcessTest.java:405 | expected: 2 but was: 1


Welcome email for new users and groups

Do we have copy for this?
Technical implementation is roughly:

Add Queue.classMethod('Email', 'sendUserWelcome', ...) to the createUser and createGroup processes
Either re-use existing mail templates or create specific ones

Anything else?

We do have copy: https://docs.google.com/document/d/1HvSdxt6NJ0vcVrbmcirbd37daFFGvfqKGf5eOvb9J7Q/edit#heading=h.ile4piggjpuq
And yes that’s about it.

On Jul 9, 2024, at 6:38 PM, Tom Watson @.***> wrote:
Do we have copy for this?
Technical implementation is roughly:
Add Queue.classMethod('Email', 'sendUserWelcome', ...) to the createUser and createGroup processes
Either re-use existing mail templates or create specific ones
Anything else?
—
Reply to this email directly, view it on GitHub https://github.com/Hylozoic/hylo-evo/issues/1594#issuecomment-2219308617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA5HJ3HHUZCYSERCMW4TTZLSGARAVCNFSM6AAAAABD2R4GRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZGMYDQNRRG4.
You are receiving this because you authored the thread.


Those items don't exist anymore, lots of things changed in 1.20 (or I think 1.20.5 and up- are you on 1.20 exactly?)
The warnings can be safely ignored. I will try to clean it up later, but I'd like to keep the items available for older MC versions so it may just be a matter of hiding the warnings.


chore: mark MsgModuleQuerySafe requests field as non-nullable

Description

closes: #6582

Mark MsgModuleQuerySafe.requests as non-nullable
Modify tests and docs for compatible with the change

Commit Message / Changelog Entry
chore: mark MsgModuleQuerySafe requests field as non-nullable

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/).
[ ] Added relevant godoc comments.
[x] Provide a conventional commit message to follow the repository standards.
[ ] Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
[ ] Re-reviewed Files changed in the GitHub PR explorer.
[ ] Review SonarCloud Report in the comment section below once CI passes.

should we consider this an API-breaking change?

it is? unless I'm missing something 😄

I might also be missing something, but I thought it could be because of this change. Users of the constructor will need to (slightly) change their code to not pass a slice of pointers, right?

Users of the constructor will need to (slightly) change their code to not pass a slice of pointers, right?

yup!

Ok, then I will push a commit adding a changelog and updating migration docs.


Bullet navigation should override moveType constraints

Description

Experiencing some odd behaviour with this;
If I have 4 panels and use moveType: 'strict' (1 panel at a time), clicking the 1st bullet when I'm on the 4th panel flicking flicks to the 3rd panel, but the 1st bullet becomes the "active" one.
Changing to moveType: 'snap' fixes the issue, but I prefer the UX of 'strict' for my case.
Steps to check or reproduce

Should be pretty easy to reproduce, but in case it isn't, my context is
Vue3 in Google Chrome Version 100.0.4896.88 (Official Build) (64-bit) on Arch Linux

Hello @eirikove. We apologize for the delay in checking the issue you have left.
We tried to reproduce the issue you left, but the behavior you left on the issue doesn't seem to be reproduced.
You can check out the demo where we try to reproduce the issue.
Can you provide us how you use options other than moveType?


ROX-17687: Operator PSP recovery

Description
This PR adds the new mapkubeapis extension to the operator. It checks if there're deprecated or removed objects in the release manifests and performs cleanup before the helm upgrade. This is especially useful when PSPs are removed from the cluster (i.e. by upgrading an OCP cluster to 4.12) and the operator is running a version that does not support PSP autosensing (i.e. 3.69.X).
Checklist

[x] Investigated and inspected CI test results
[x] Unit test and regression tests added
[x] Evaluated and added CHANGELOG entry if required
[x] Determined and documented upgrade steps
[x] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

Testing Performed

Added an integration test.
Tested the OCP upgrade on an infra cluster.

/lgtm

lgtm

/retest


Add Attila Blascsak to the list

@blascsi, I'm quite elated about your PR. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a PR and learned that I merged it?


[Bug]:  system prompt在openai中好像无效

Do you need to file an issue?

[ ] I have searched the existing issues and this bug is not already filed.
[ ] My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
[ ] I believe this is a legitimate bug, not just a question. If this is a question, please use the Discussions area.

Describe the bug
当我使用默认的system prompt时，模型总是回答I apologize, but I don't have any information about...，然后当prompt变短时，模型可以正常回答，这是openai的问题吗，还是说在后续的处理中将system prompt截断了？
Steps to reproduce
No response
Expected Behavior
No response
GraphRAG Config Used
# Paste your config here

Logs and screenshots
No response
Additional Information

GraphRAG Version:
Operating System:
Python Version:
Related Issues:

我都遇到這個問題，我是用ollama 行llama3.1的
我試過定義 role 是 "You are a helpful assistant of company ABC"
接問用local search 問"你是誰" 時，
會直接回答 I'm an artificial intelligence model known as Llama
但縮短了LOCAL_SEARCH_SYSTEM_PROMPT後(例如 直接刪走Data tables) ，
他就懂得回答 "I am a helpful assistant of company ABC"

如果你是用Ollama的話可以參考這個方法
我找到原來Ollama限制了tokens長度為2000，可以用Modelfile或經API 設定num_ctx的上限(e.g: 12800)，這樣LLM就接收到完整的system prompt了。

Is this happening when running global search? We have checks in place to filter out any community responses that the LLM deems low-relevance, which can sometimes mean no relevant summaries are collected together and the end result is that it can't answer the question. This is a somewhat cautious approach to avoid hallucination. You may be able to get better results if you tune the prompt to your domain for how the LLM assesses relevance and assigns the "Importance Score" here.


feat: render AvailablePools as ReactTable

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

High Risk PRs Require 2 approvals

What protocols, transaction types or contract interactions might be affected by this PR?

Testing

Engineering

Operations

Screenshots (if applicable)

#6454  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gomesalexandre and the rest of your teammates on  Graphite


Fixed #6978: DI Container is not reset when destroying application in functional tests

Added code to reset the DI container when destroying the application

@yiisoft/core-developers, @Ragazzo any issues with the change?

I am unsure: it could be someone relies on DI for test environment setup.
It could be better to save original instance if Container before running the test and then restore it, rather then simply recreating it.

@klimov-paul environment should be re-created for each test case i.e. it should be isolated.

i dont think that it will affect anything , since tests should be done in isolation , however we should recheck that DI - container is recreated each time in mockApplication()

however we should recheck that DI - container is recreated each time in mockApplication()

:+1:

Okay, do I understand this correctly now?
To be precise, we should do Yii::$container = null (to destroy is to set to default value) in destroyApplication() and  Yii::$container = new Container in mockApplication() (to mimick the first load of Yii class?)
class Yii extends \yii\BaseYii
{
}

spl_autoload_register(['Yii', 'autoload'], true, true);
Yii::$classMap = include(__DIR__ . '/classes.php');
Yii::$container = new yii\di\Container;

Ok, setting it to null is not a good idea, because yii\base\Application::__construct needs the container to be set already.

Added the change to the correct changelog, added the reset of DI container also to mockApplication.
Did you mean something like this by "recheck"?

Merged. Thanks! https://github.com/yiisoft/yii2/commit/a6dd9d37d5c5b7e5fac4edeb89c35cbc961df369


The effect of data layout

In my thought, the data layout(NHWC or NCHW) would effect the algorithm of some ops, and this would lead to different performance. Is this understanding right? And for neon backend, which layout is best?

Hi @Cola-Code NHWC is best for both the OpenCL and NEON backends at this time.

I believe that there's some test programs in the Compute Library that can show you the difference that it makes, but I don't know the details. If you're interested, it would be best to ask on their Github.

@MatthewARM , ok, i got it. Thanks very much!

Thanks and good luck!


Support named export in a CommonJS module in node_modules

Clear and concise description of the problem
Please don't mind me creating this issue from a discussion https://github.com/vitest-dev/vitest/discussions/1360 to keep on track.
Reproduction
https://github.com/Jinjiang/reproductions/tree/vitest-apollo-20231214
The package in my case is @apollo/client. In source code import { ... } from ... works. However, when it's written in a file inside node_modules, it doesn't work unless using the import pkg ... statement.
// THIS DOESN'T WORK NOW
import { gql } from '@apollo/client';

// THIS WORKS
import pkg from '@apollo/client';
const { gql } = pkg;

Suggested solution
Support named export in CJS package like @apollo/client
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

This is expected behaviour, this is how Node.js works. To bypass this, you can use server.deps.inline to inline all dependencies in the dependency chain that imports this file.

I see. I did a quick trial. Seems adding server: { deps: { inline: true } } to the test config doesn't help. Not sure what is the proper config to bypass. May I double check that with you? Thanks.
Error log:
$ pnpm test

> reproduce@ test /xxx/reproductions
> vitest

 RUN  v1.0.4 /xxx/reproductions

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Errors ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Vitest caught 1 unhandled error during the test run.
This might cause false positive tests. Resolve unhandled errors to make sure your tests are not affected.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Error: Failed to load url @vitest/expect (resolved id: @vitest/expect). Does the file exist?
 ❯ loadAndTransform node_modules/.pnpm/vite@5.0.8/node_modules/vite/dist/node/chunks/dep-uAHLeuC6.js:49374:21
 ❯ ViteNodeServer._transformRequest node_modules/.pnpm/vite-node@1.0.4/node_modules/vite-node/dist/server.mjs:393:16
 ❯ ViteNodeServer._fetchModule node_modules/.pnpm/vite-node@1.0.4/node_modules/vite-node/dist/server.mjs:359:17
 ❯ MessagePort.<anonymous> node_modules/.pnpm/vitest@1.0.4/node_modules/vitest/dist/vendor/index.cAUulNDf.js:60:20

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 Test Files  no tests
      Tests  no tests
     Errors  1 error
   Start at  21:32:25
   Duration  304ms (transform 35ms, setup 0ms, collect 0ms, tests 0ms, environment 0ms, prepare 0ms)

 ELIFECYCLE  Test failed. See above for more details.

You need to add a dependency that imports @apollo/client:
export default {
  test: {
    server: {
      inline: ['foo']
    }
  }
}

It works with the config you provided. Thanks so much.
May I have one more last question if you don't mind 😅 ? Why it failed with error about @vitest/expect when I set server.deps.inline as true? What happened behind?

https://github.com/vitest-dev/vitest/issues/2806


Migration

find out how to keep each history

git filter-branch for creating a new branch of each repo where the files are moved into a subdirectory

how the final repository should look like (folder wise)
(both folders and repositories:) sys/..., gir-files, atk, cairo, gdk, gdk-pixbuf, gdkx11, gio, glib, graphene, gtk, examples, pango, pangocairo
migrating the CI to github-actions
checking how to keep the "release branches" from the other repositories

by renaming: glib-0.10, et

update release script
update the crate versions
what about the repositories' issues?

very likely using a python script to migrate them all

update the crates' git repositories URL
archive old repositories and add a link to the new repository
Add a python script (like the one in gstreamer-rs) to handle regenerations

Does it make sense to keep the gtk4 ones separate ? there are quiet few of them actually: gsk4, gdk4, gdk4-x11, gdk4-wayland, graphene, gtk4 & probably sourceview5

We wait for their official stabilization to bring them in. Also, some crates that aren't "core" will remain outside of this repository (like sourceview).

Oh, you want to do a monorepo? :slightly_smiling_face:
I recommend using git subtree to merge repos. It's as simple as git subtree add -P <prefix> <repository> <ref> to merge an existing repository with its whole history into another one.

I'm almost done already. ;) The issue is mostly how the repository should look like in the end.

One problem with this is that all commit/PR/issue references in the commit messages are broken now.

Actually, if you're using git subtree or an equivalent, commit references won't break.
The rest would be true too if you moved to GitLab or anything else. I strongly encourage everyone to not put anything in commit messages that only works if the repository is at a specific location.
You could also always write your own custom script based on git filter-branch that rewrites the commit messages to contain permalinks, but that would probably be way too much effort to be worth it.

No, no subtree in here.

Still my point stands. If you're already preserving history, commit hashes, and thus references in other commits, are not necessarily going to break (depending on whether you rewrite all of the commits you integrate).

Yeah I agree and it's not really a problem, I just wanted to mention it :)
However I think something broke when merging the repos. The files don't have any history anymore.
Compare for example https://github.com/gtk-rs/gtk-rs/blame/ongoing/cairo/src/surface.rs vs https://github.com/gtk-rs/gtk-rs/commits/ongoing/cairo/src/surface.rs . git blame works, git log doesn't.
That seems a bit suboptimal and can be prevented. See for example GStreamer's merged repos: https://gitlab.freedesktop.org/thiblahute/gstreamer/-/commits/monorepo_simple/subprojects/gst-plugins-base/gst/audiomixer/gstaudiomixer.c
I think that is my only concern right now.
Bugfix releases we would do from the old repos so that's fine (don't archive them yet!), old tags stay in the old repo also not a problem.

@sdroege This may even be a difference of GitHub vs. GitLab, rather than git log not working. I'm seeing the same thing in a subtree-merged repo on GitHub. How was merging done in GStreamer?

@sdroege This may even be a difference of GitHub vs. GitLab, rather than git log not working. I'm seeing the same thing in a subtree-merged repo on GitHub.

It's the same effect when using git directly on the commandline though. Something's not correct there :)

How was merging done in GStreamer?

Taking each repo individually, git mv to a new subdirectory inside each, then git merge them all into one.

As we found out, this happened because @GuillaumeGomez updated the commit messages of all commits after the merge commit. So this has to be redone, and also we decided to not update the commit messages anymore as this will also cause chaos with the existing merge commits inside the repositories.

Turns out this is actually a bug in the git UI and github just replicates that, while gitlab handles it better. So I guess we'll have to live with this if we want to merge the repos.

The only way around that is to use git filter-branch to move all the files inside the individual commits instead of doing a git mv later.

Turns out this is actually a bug in the git UI and github just replicates that, while gitlab handles it better.

Not a bug, just a design decision, and only the default.
In the CLI, git log --follow cairo/src/surface.rs will show you the full history. I don't know if GitHub provides any way to do that in the web interface.

In the CLI, git log --follow cairo/src/surface.rs will show you the full history

This only works for actual files though, not for directories. Not much of a problem here, I guess.

I'm wondering what's still left to be done as part of the migration?

Moving the remaining issues and PRs

I think we can now close this issue.


running benchmark on x86

Hi ,
I am using python3 -m run --engines *-m-16-* --datasets glove-* for running the benchmark on x86. please let me know how much time it might take for the benchmark to complete ?
Thanks.

please let me know how much time it might take for the benchmark to complete ?

That's depends heavily on your machine specs: CPU, RAM, etc.
Closing this for now. Feel free to re-open if you have any more questions :)


attic does not backup UNIX domain sockets

On the mailing list, Dan Williams (2015-04-01) reported an issue with attic master branch code:
"""
There was one problem restoring, however: Attic failed to restore a socket
file. Ouch! The other two [obnam and bup] restored the file just fine.
"""
Can somebody else reproduce this?

Dan (or somebody else): could you add a description about how to reproduce, what the expectation is and how attic fails to meet that?

from attic/archiver.py:157:
        # Ignore unix sockets
        if stat.S_ISSOCK(st.st_mode):
            return

So, it is expected with current code that you won't have UNIX Domain Sockets in your backup.
So the remaining questions are "why not" and "why would one want them"?
I admit I have not much clue about UDS, so if someone can help with reasoning here, that would be welcome.

Just tried the good ol' tar:
tar: /tmp/mysock: socket ignored

So, tar doesn't backup UDS either. Just saying, the reasoning why or why not is still todo.

Backup / archiving tools that ignore sockets "know" that software will create or recreate a socket if it needs to and will bind or rebind it to a path name. So, backing up sockets makes no sense.

That's curious; I must admit I did not realise that tar skips sockets. A quick Google suggest that it's not even optional; it just skips them.
However, a better question from my point of view is, "should a backup program backup sockets?", rather than looking purely at tar. On this point, both Bup and Obnam backup, and restore, sockets. Equally, rsync will copy sockets, so I assume (I have not tested this theory) that rsync-based tools do too. Because of this, I was expecting Attic to do so.
Again, a quick Google suggests that there may be no purpose in backing up and/or restoring sockets. This is the conclusion of this thread on superuser. However, I am not sure that is the end of the question; I have two observations:

What if the program that usually uses the socket, and owned the socket, had permissions to use that socket but with it gone cannot recreate it, because it does not have permission on the containing folder? E.g. if the folder is owned by root. This would recreate user intervention to recreate the socket or change permissions. I am not sure if this is realistic, though, seeing as users generally don't have to create sockets!

To anyone running a backup and restore, and comparing the result, if the restored filesystem is missing sockets then they will get a different number of files. This is what I encountered, and it was unexpected. The user would have to verify that all the missing files were sockets, or do their comparison explicitly excluding sockets. I'm not sure this is obvious or intuitive.

Does it do any harm to backup and restore the sockets? In balance, it seems better, from a user's point of view? And the program using it will just recreate it either way. Perhaps this is why other tools do it?

@danwilliams 1 and 2 sound like pretty good reasons to me. @Ernest0x what do you think?

After first implementing "socket backup/restore support", I read that superuser discussion and esp. this:
Q: How to backup/restore unix domain sockets?

A: You don't.

Unix local sockets are created as soon as a program attempts to listen on the given path for connections, and despite being a type of file they only act as pointers to in-memory structures; so they are useful only as long as the program is still running (and only within the same machine; no NFS or anything such).

After the program exits, the socket file is no longer useful (and is normally deleted by the program itself); in fact, if the program gets restarted, it has to delete the old socket before listening on the same path – otherwise it would receive an "Address already in use" (the same as if two programs were trying to take the same TCP port).

This is somewhat different from named pipes (aka fifos), which work in a much simpler way (one process writes, one process reads) and therefore are reusable; a named pipe can be created using the mkfifo or mknod p … commands.

I also tried that myself and can confirm it: there is no point in re-using a restored UDS. The program that tries to listen on it will just fail. The program must be able to delete a existing UDS first to be able to listen on (and create) a fresh one. If it can't delete or create due to missing permissions, it can not work.
So, argument 1 is invalid.
About argument 2: we could backup and restore UDS on a "it was there when we backed up, it will be there after restore (even if not really connected and pretty useless)" basis.
Opinions?

If someone wants to give it another test:
https://github.com/ThomasWaldmann/attic/commits/uds

Cool, I can't remember ever having created or used a socket file myself for anything I've worked on, so I was unsure as to some of the finer points. The superuser discussion was quite informative and convincing, and if you have tested the conditions I speculated on in my first point, I am quite happy with your conclusion. (And it sounds logical, because to delete the socket, write permissions are required on the containing folder, etc.)
So I think we are all in agreement that there is no technical need to backup sockets.
I have thought quite a bit about point 2. I ultimately think that sockets should be backed up. My thinking goes like this:

If a file exists (of whatever nature) and is not restored, this can be unsettling for users checking integrity. Users should not have to learn about sockets or perform extra steps in data comparison to exclude them (this is essentially my point 2).
It should not be the responsibility of the backup software to decide what is "useless". This is something I thought about for a long time! There may well be other files or filesystem entities present which, upon restoration, could be useless. Where do we draw the line? E.g. a broken symlink, a special device for something inaccessible (say a floppy drive). So there are quite a few circumstances that I could think of under which "useless" or invalid data could be restored - and I do not think that is a problem. The key point to me is that the backup software should faithfully duplicate exactly what it finds, regardless.
The end state, having restored a socket, is - from what I can tell - no different to the state encountered if the program owning the socket had quit (assuming it left the socket behind). So this is not a bad thing. Although, it does ask the question about what would/should happen if restoring to a place where there are existing files and an existing socket. But that's probably off-topic here.

Of course, all this is just my personal opinion - I'm not even contributing to the codebase! So I can hardly complain if you disagree :o)
However:

If sockets are not to be supported, there should be some mention of this in the documentation, loud and clear so people will know what to expect.
If sockets are to be supported, it may also be worth considering implementing an option to exclude them from either the backup, or the restore, or both. This could also apply to other special files, perhaps - but may be unnecessary on the restore side because I guess someone could run find -xdev and pipe to Attic over stdin. Either way, I'd definitely prefer the default to be "on" and the option to turn them "off", rather than the other way around.

Regarding your patch: I will test this in the next couple of days; once I have finished my current tests with official Attic my plan is to rebuild my Debian packages based on the merge-all branch and give that a spin, at which point I will also include your UDS commit.

Restoring a socket file is not only useless, but will possibly also overwrite an already bound socket. This is bad because applications will not be able to connect to the service that binds the socket until that service recreates it. Many applications are not coded to be able to recover from this and will need to be restarted. So, please, do not break this.

If restoring into a location that already has content, you could say the same about other files - for instance, any PID files or files in use by flock. Restoring these files could therefore also cause problems. What would you have Attic (or any backup tool) do in this situation?
I would be happy if the default behaviour were to skip restoring sockets if they already exist. This seems sensible enough and would not cause any problems. Arguably the user could/should be informed about this. I do however see no purpose in adding an option to force-overwrite sockets, as this would be pointless due to their nature. But an option to filter them out when restoring could perhaps be useful to some people.

If restoring into a location that already has content, you could say the same about other files - for instance, any PID files or files in use by flock. Restoring these files could therefore also cause problems. What would you have Attic (or any backup tool) do in this situation?

You will normally exclude PID files as well as any other type of files that you do not need to backup, as you do not need to restore them. The good thing with socket files is that they are special, so we can hardcode their exclusion in the backup tools.

I would be happy if the default behaviour were to skip restoring sockets if they already exist. This seems sensible enough and would not cause any problems.

Don't be so sure. It could happen that the service creates the socket right after the restoration tool checked for the existence of the path, but before the restoration takes place.

Arguably the user could/should be informed about this. I do however see no purpose in adding an option to force-overwrite sockets, as this would be pointless due to their nature. But an option to filter them out when restoring could perhaps be useful to some people.

I would say the oposite. By default, do not backup socket files, but have an option if someone (like you) insists in taking backups of these.

You will normally exclude PID files as well as any other type of files that you do not need to backup, as you do not need to restore them.

That's a rather sweeping statement - do you really mean that for every backup you do, you carefully check where all the PID files are and write exclusion lists for them? And that you know this list is complete, and that you keep it up-to-date? If so, that is remarkable - and I suspect not many other people would do this. I have never bothered, as I can't see the point. I would rather have a backup that gathers up everything possible.
Regarding the sockets specifically, of the tools I tested, Attic was the only one that did not backup and restore sockets. My sample pool is rather small and I should probably investigate other tools, but the writer of Obnam in particular strikes me as rather pedantic about data integrity (which is a good thing) and so must have thought through this very problem.

It could happen that the service creates the socket right after the restoration tool checked for the existence of the path, but before the restoration takes place.

This seems like an extremely unlikely event.

I would say the oposite. By default, do not backup socket files, but have an option if someone (like you) insists in taking backups of these.

What is more intuitive for the general user - to do everything, or to miss bits out?
This is certainly an interesting debate - I had no idea people were so passionate about sockets! (Myself included!) ;o)

That's a rather sweeping statement - do you really mean that for every backup you do, you carefully check where all the PID files are and write exclusion lists for them? And that you know this list is complete, and that you keep it up-to-date? If so, that is remarkable - and I suspect not many other people would do this.

Thankfully, there is FHS. So, it's as simple as choosing to exclude any combination of some directories:

/var/run
/var/lock
/tmp
/proc
/sys
/mnt
/media
/dev
/var/cache
/run

But here we are talking about sockets. And sockets are an easy pick, since they are special and can be handled by the tool without users specifing paths.

It could happen that the service creates the socket right after the restoration tool checked for the existence of the path, but before the restoration takes place.

This seems like an extremely unlikely event.

You never know. Better be safe than sorry.
Also consider this scenario: You restore a socket file and its permission bits are set the same as they were at the time of the backup. If in the meantime, after the backup but before the restore, you had changed the configuration of the service creating the socket to run with different permissions, it will fail to recreate the restored socket file due to a permission error when trying to unlink() it.

What is more intuitive for the general user - to do everything, or to miss bits out?
I would say that current behavior, a logging message that sockets are ignored, is quite intuitive. If an option for including sockets in the backup is implemented, then that message could be extended with a hint for that option. But what it matters here is practicallity and having maximum safety in restores. If you are some kind of purist and know about the risks of restoring socket files, then use that option. If not, better be safe and let the tool do the safest for you.

Thankfully, there is FHS. So, it's as simple as choosing to exclude any combination of some directories...

Actually, no, it's not quite that simple - the socket I encountered during my backup test lives in my home directory somewhere. I would not have predicted its existence.
Also, I personally would not attempt to restore a root filesystem, and if I did, I would think carefully about exclusions. At this point I would perhaps/probably exclude sockets, but only at restoration time. Again, personally I only tend to back up /etc and /root in addition to data areas (/home and any known storage locations) as my preference is to reinstall the OS and restore data rather than consider restoring the OS.

Also consider this scenario: You restore a socket file and its permission bits are set the same as they were at the time of the backup. If in the meantime, after the backup but before the restore, you had changed the configuration of the service creating the socket to run with different permissions, it will fail to recreate the restored socket file due to a permission error when trying to unlink() it.

That's a very good point. You may also have changed the owner. Still, even though I totally agree with your statement, I feel it is off topic. The reason being, like I pointed out previously, you could do the same with PID files or indeed any file. There is always a chance that you may have changed something since you made the backup, and that restoring it could cause problems. I believe this is an exercise for the user at the point of restoration. I don't believe the backup software should make decisions like this - I think it's outside of the remit. In my very humble opinion on this matter, I think backup software should faithfully backup and restore everything, perfectly, to be an exact mirror of the original unless told otherwise.

I would say that current behavior, a logging message that sockets are ignored, is quite intuitive.

I have not seen that behaviour. All my tests so far have used the latest code on the official master branch. I assume that this new behaviour is part of the merge or merge-all branch? I would still like the message to be a restore-time message and not a backup-time message. That just seems safer.

But what it matters here is practicallity and having maximum safety in restores. If you are some kind of purist and know about the risks of restoring socket files, then use that option. If not, better be safe and let the tool do the safest for you.

I think this is where we disagree - to me, the "safest" behaviour for backup software is to include everything. When it comes to backing up my data, I guess perhaps I am a purist. I can live with that :o) But I would like to be able to do the following in an automated way:
Backup -> Restore elsewhere -> Diff -> Check identical
This to me is the gold standard of testing data integrity.
I have plenty of files that are most likely useless and it would not matter if they were skipped. But I don't want my backup software making that decision for me.
I also still believe that "safest" only applies in certain situations if the files are restored to an original location. In this instance the user should be carefully choosing the restore behaviour - whether to replace existing files, whether to restore sockets. So that would be an informed process, and one knowingly configured.
Still, it seems that we have reached an agreement on whether the sockets should be backed up (yes). Our current disagreement is whether the default behaviour should be to restore them or not. I am pragmatic, and providing there is a way to achieve the restoration of sockets, and this is clearly documented in terms of how to achieve it (and even more clearer stated that the default is not to restore them) then I guess I can live with that, although my vote is definitely to have it the other way around (this would also be more in keeping with other tools).
I'm not sure how such things are generally resolved; is there a community vote? Or does it come down to a decision by the people actually writing the code? Just curious.

Actually, no, it's not quite that simple - the socket I encountered during my backup test lives in my home directory somewhere. I would not have predicted its existence.

You shouldn't care about its existence, as far as your backup configuration is concerned. Backups of sockets are not useful. BTW, not following FHS standard (or extensions of it) makes administration of things more difficult.

The reason being, like I pointed out previously, you could do the same with PID files or indeed any file. There is always a chance that you may have changed something since you made the backup, and that restoring it could cause problems.

Yes. But here we are talking about the special case of socket files, with which the tools can be smart enough and not bother with.

I would say that current behavior, a logging message that sockets are ignored, is quite intuitive.

I have not seen that behaviour. All my tests so far have used the latest code on the official master branch. I assume that this new behaviour is part of the merge or merge-all branch?

My mistake. Ignoring socket files is currently silent. This can be changed though.

Backup -> Restore elsewhere -> Diff -> Check identical
This to me is the gold standard of testing data integrity.

There is no identicality in the case of socket files. The restored paths will not be bound to any in-memory socket objects.

I have plenty of files that are most likely useless and it would not matter if they were skipped. But I don't want my backup software making that decision for me.

It won't. It can only take a decision for sockets, which is a special, easily catched case.

Still, it seems that we have reached an agreement on whether the sockets should be backed up (yes). Our current disagreement is whether the default behaviour should be to restore them or not.

Nope. I clearly said that the way attic works now is the safest. It does not backup sockets. But I am ok with an option to explicitly backup socket files.

I'm not sure how such things are generally resolved; is there a community vote? Or does it come down to a decision by the people actually writing the code? Just curious.

Usually, @jborg listens to people and makes the final decisions.

You shouldn't care about its existence, as far as your backup configuration is concerned. Backups of sockets are not useful.

Other than the fact that I would like to be able to restore it if I want, to check that everything is an exact copy. As explained.

BTW, not following FHS standard (or extensions of it) makes administration of things more difficult.

I totally agree. Unfortunately, not all software follows those rules. The socket file I mentioned I discovered in my home directory (which I only realised existed when Attic didn't restore it) was not created by me. That test was on an Ubuntu desktop system and I have no idea what created it or if it was in a sensible location. Potentially lots of things could create such sockets I guess. It's a little easier on servers, but there is still no guarantee.

Ignoring socket files is currently silent. This can be changed though.

How? I am not aware of an option for it at present (unless that's in the newer branches) so I assume you mean it can be changed in the codebase. Again, it seems better to back them up, thereby not needing any warning or option, and leave the warnings and/or options to restore-time, whichever way it is achieved.

There is no identicality in the case of socket files. The restored paths will not be bound to any in-memory socket objects.

You are incorrect, at least from the context that I am talking in. As far as I am aware, a (named) socket exists as a zero-byte file. So, it has ownership, permissions, etc. but no contents. Hence an integrity check would pass if the file were restored, regardless that the restored file is not in use or bound.
Remember, I performed integrity checks (using diff, rsync, and bcompare) and both Bup and Obnam passed - they restored an identical copy of my data. Attic did not restore the socket file, hence how this discussion started.

Nope. I clearly said that the way attic works now is the safest. It does not backup sockets. But I am ok with an option to explicitly backup socket files.

Okay, perhaps I misunderstood. My apologies. But surely you cannot object to automatically backing-up the socket files, and having a restore-time option as to what to do with them? It would appear unnecessary to have to specify an option on both sides. After all, they are not exactly doing any harm, especially if the default behaviour is to ignore them on restoration.
I'm curious as to what others think on this topic? I feel that we have covered all the ground I can think of, but perhaps we have missed angles or points.

Remember, I performed integrity checks (using diff, rsync, and bcompare)
and both Bup and Obnam passed - they restored an identical copy of my
data

I would be willing to bet some amount of money that diff, rsync[1] and
bcompare does not compare sockets and what you've got were identical file
path, but almost certainly not identical data. Since, as was mentioned
previously, there is no meaningful way to compare sockets, and whatever
software created socket file in the first place likely changed it since
backup was ran.
So if, lets say, you have ~/tmp/socket1 and ~/tmp/socket2 and they are
switched up during restore, you would never know. However, you should not
and would not care.
I am with Petros here: there could be an option to back up sockets for
people that want this for some reason, but not backing them up is a
sensible default.
1: For example, rsync requires --specials to sync at sockets, which is off
by default
On Fri, Apr 3, 2015 at 1:52 PM, Dan Williams<EMAIL_ADDRESS>wrote:

You shouldn't care about its existence, as far as your backup
configuration is concerned. Backups of sockets are not useful.
Other than the fact that I would like to be able to restore it if I want,
to check that everything is an exact copy. As explained.
BTW, not following FHS standard (or extensions of it) makes administration
of things more difficult.
I totally agree. Unfortunately, not all software follows those rules. The
socket file I mentioned I discovered in my home directory (which I only
realised existed when Attic didn't restore it) was not created by me.
That test was on an Ubuntu desktop system and I have no idea what created
it or if it was in a sensible location. Potentially lots of things could
create such sockets I guess. It's a little easier on servers, but there is
still no guarantee.
Ignoring socket files is currently silent. This can be changed though.
How? I am not aware of an option for it at present (unless that's in the
newer branches) so I assume you mean it can be changed in the codebase.
Again, it seems better to back them up, thereby not needing any warning or
option, and leave the warnings and/or options to restore-time, whichever
way it is achieved.
There is no identicality in the case of socket files. The restored paths
will not be bound to any in-memory socket objects.
You are incorrect, at least from the context that I am talking in. As far
as I am aware, a (named) socket exists as a zero-byte file. So, it has
ownership, permissions, etc. but no contents. Hence an integrity check
would pass if the file were restored, regardless that the restored file is
not in use or bound.
Remember, I performed integrity checks (using diff, rsync, and bcompare)
and both Bup and Obnam passed - they restored an identical copy of my
data. Attic did not restore the socket file, hence how this discussion
started.
Nope. I clearly said that the way attic works now is the safest. It does
not backup sockets. But I am ok with an option to explicitly backup socket
files.
Okay, perhaps I misunderstood. My apologies. But surely you cannot object
to automatically backing-up the socket files, and having a restore-time
option as to what to do with them? It would appear unnecessary to have to
specify an option on both sides. After all, they are not exactly doing any
harm, especially if the default behaviour is to ignore them on restoration.
I'm curious as to what others think on this topic? I feel that we have
covered all the ground I can think of, but perhaps we have missed angles or
points.
—
Reply to this email directly or view it on GitHub
https://github.com/jborg/attic/issues/259#issuecomment-89280001.

--
Dmitry Astapov

I would be willing to bet some amount of money that diff, rsync[1] and bcompare does not compare sockets and what you've got were identical file path, but almost certainly not identical data.

Mmmm, I don't want to split hairs, but... I agree those tools do not attempt to compare the file contents, but disagree about that not meaning identical data. Sockets, like fifos, are recognised special files and it doesn't make any sense to try to look inside them for copy/backup purposes, plus they are technically zero-byte files, I believe. Hence the comparison is on the metadata (ownership, permissions, any other metadata) as well as the existence of the file. The backup/restore would also be on this basis, which is what I have experienced elsewhere, hence the data is in fact identical from a filesystem point of view. I hope this clarifies the intent of what I said earlier. So I am not expecting contents to be read.

On Tue, Apr 7, 2015 at 4:55 PM, Dan Williams<EMAIL_ADDRESS>wrote:

I would be willing to bet some amount of money that diff, rsync[1] and
bcompare does not compare sockets and what you've got were identical file
path, but almost certainly not identical data.
Mmmm, I don't want to split hairs, but... I agree those tools do not
attempt to compare the file contents, but disagree about that not meaning
identical data. Sockets, like fifos, are recognised special files and it
doesn't make any sense to try to look inside them for copy/backup purposes,
plus they are technically zero-byte files, I believe.

Ah, but sockets are not like fifos, which is why we have this email thread
in the first place. It makes sense to restore fifos (they are reusable), it
does not make sense to restore sockets (they are not reusable)

Hence the comparison is on the metadata (ownership, permissions, any other
metadata) as well as the existence of the file. The backup/restore would
also be on this basis, which is what I have experienced elsewhere, hence
the data is in fact identical from a filesystem point of view. I hope this
clarifies the intent of what I said earlier. So I am not expecting contents
to be read.

And I argue that any comparison is quite meaningless as the guarantees you
can practically get are really weak and not important for majority of
practical purposes.
Case in point - I just tried to use diff to compare directories with
sockets:
% mkdir /tmp/{1,2}
% cp -a /var/run/acpid.socket /tmp/1/a
% cp -a /var/run/acpid.socket /tmp/2/a
% diff -r /tmp/1 /tmp/2
File /tmp/1/a is a socket while file /tmp/2/a is a socket
No telling if they are same or different
Also, rsync:
% rsync -avi --specials /tmp/1/ /tmp/2/
sending incremental file list
.d..t...... ./
sent 63 bytes  received 15 bytes  156.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)
Now, lets change one of those sockets:
% cp -a /var/run/rpcbind.sock /tmp/2/a
% rsync -avi --specials /tmp/1/ /tmp/2/
sending incremental file list
.d..t...... ./
sent 63 bytes  received 15 bytes  156.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)
As you can see, even with --specials rsync does not tell me that sockets
are in fact different.
How sure you are that comparisons you ran would've actually detected any
restore errors related to sockets?
--
Dmitry Astapov

Well, firstly the restore check would show me if it was restored as an ordinary file instead of a socket, for instance. And the ownership and permissions of the actual socket do count as a difference, look:
$ mkdir tmp/{1,2} -p
$ cp -a .config/xpad/server tmp/1/
$ cp -a /var/run/acpid.socket tmp/2/
$ diff -qr tmp/1 tmp/2
Only in tmp/2: acpid.socket
Only in tmp/1: server

$ mkdir tmp2/{1,2} -p
$ cp -a .config/xpad/server tmp2/1/
$ cp -a .config/xpad/server tmp2/2/
$ diff -qr tmp2/1 tmp2/2
File tmp2/1/server is a socket while file tmp2/2/server is a socket

This is what I mean about it not being feasible to compare "contents" (because there are none from a filesystem point of view) but rather, the metadata.
Plus, I do think the matter of existence is important on its own. Perhaps I am in the minority here, but my opinion is consistent with certain other backup tools.

Hmm..
Nitpicking: you say "ownership and permissions of the actual socket do
count as a difference, look", but your examples do not show how difference
in file name could be detected. You can use rsync to detect change in
permissions/ownership ...
I also think that being consistent with some backup tools is neither here
nor there, as there are plenty of backup tools on the other side of the
hedge as well, tools that ignore sockets (rsync, tar, ...). In some sense,
even with proposed patch attic would be more in the "ignoring sockets"
camp, because any errors from socket.bind are ignored, which means that
attic would not restore sockets over files, or sockets over previous
versions of same sockets ... Which is completely fine in my book, btw -
unless some socket-related error terminates restore because nobody really
cares much about this obscure code path that have little practical purpose.
I'd personally be much happier if sockets were backed up only when an
explicit option is given (and always restored if they are present in the
archive).
On Wed, Apr 8, 2015 at 11:58 AM, Dan Williams<EMAIL_ADDRESS>wrote:

Well, firstly the restore check would show me if it was restored as an
ordinary file instead of a socket, for instance. And the ownership and
permissions of the actual socket do count as a difference, look:
$ mkdir tmp/{1,2} -p
$ cp -a .config/xpad/server tmp/1/
$ cp -a /var/run/acpid.socket tmp/2/
$ diff -qr tmp/1 tmp/2
Only in tmp/2: acpid.socket
Only in tmp/1: server
$ mkdir tmp2/{1,2} -p
$ cp -a .config/xpad/server tmp2/1/
$ cp -a .config/xpad/server tmp2/2/
$ diff -qr tmp2/1 tmp2/2
File tmp2/1/server is a socket while file tmp2/2/server is a socket
This is what I mean about it not being feasible to compare "contents"
(because there are none from a filesystem point of view) but rather, the
metadata.
Plus, I do think the matter of existence is important on its own. Perhaps
I am in the minority here, but my opinion is consistent with certain other
backup tools.
—
Reply to this email directly or view it on GitHub
https://github.com/jborg/attic/issues/259#issuecomment-90879998.

--
Dmitry Astapov

Sorry, I posted in a hurry and did not initially realise that I had made a mistake. I edited the post fairly quickly, but I think you have replied to the alert email...
To be honest I think everything that can be said has been said, so I'll leave it to the powers that be to decide :o)


GitHub Actions: use checkout v2

Hi @sullis , thanks for the PR! It seems like it has some problems - do you know what changed between v1 and v2 that could trigger this?

Hi @sullis , thanks for the PR! It seems like it has some problems - do you know what changed between v1 and v2 that could trigger this?

I am not aware of anything. I am using checkout@v2 on all of my libraries.

We're working on a rewrite, you can see the current progress on the branch architecture-inventory. There, checkout is already updated to v2.
If this is good enough for you, I would close this PR.


Escape +/- key in constant descriptions to avoid issues when generating RST

Hey all, this is my first pull request here.
Problem Description
This PR fixes the problems raised in #8127. The issues stem from the + and - characters used in the KEY_PLUS and KEY_MINUS enumeration descriptions not being escaped after the make_rst.py script is run. This results in the + and - characters being interpreted as bullet lists, rather than characters, as can be seen here.
Problem Solution
The cleanest solution that I can think of is to add additional escape logic to the escape_rst method in make_rst.py for the + and - characters by searching for the strings "+ key" and "- key". This will allow the KEY_PLUS and KEY_MINUS enumeration descriptions to display correctly after generating a .rst file from @GlobalScope.xml. This solution will be transparent to all of the other .xml files in the project.
I looked at trying to escape these characters in the same way that the * is handled, but found that this can break bullet lists in .rst files generated from other .xml files, such as EditorCommandPalatte.xml. As a result, the proposed solution is the cleanest way that I can think of to fix the problem.
Results
Upon diffing the generated _build/rst folders before and after applying the fix, only<EMAIL_ADDRESS>is modified:

Please let me know if someone has a cleaner solution!

It is also possible to fix this by editing<EMAIL_ADDRESS>in the godot repo. Specifically by subsituting the - in line 2171 (description for KEY_MINUS) with - and the + in line 2165 (description definition for KEY_PLUS) with +
This is how keys like < in line 2216 (description definition for KEY_LESS) and > in line 2222 (description definition for KEY_GREATER) are handled right now.
I personally think this is cleaner since it does not add any additional code and it mimics the approach made in other parts of the xml file

@AsperTheDog I gave it a shot, but I didn't end up being successful. I did the following tests without any of the make_rst.py changes included in this PR:

Try to brute force the escape sequence for KEY_PLUS by using \+ or \+ in @GlobalScope.xml
Try to handle KEY_MINUS the same way that KEY_LESS is handled by using - in @GlobalScope.xml

The first approach didn't work since the \ character is also escaped in the escape_rst method of make_rst.py, leading to an output of \\+ key. being generated in the associated .rst file.
The second approach didn't work since it will generate an unescaped - character in the generated .rst file, leading to an output of - key., which is what is currently happening in master. The use of < for KEY_LESS works fine since this character doesn't need to be escaped in the generated .rst file.
I've included a screenshot for completeness:

Do you know if I'm missing something? To your point, I would prefer not to add any additional code to make_rst.py, so I'd really like this alternative approach to work. 🙏

@transistasis it seems like it does not work as I expected. My bad. This issue is only present in the online docs, and not in the local docs of the engine. To test it looked as it should I compiled the engine and ran it with --doctool. Since the docs appeared to be correct I assumed it was working correctly.
So the approach I mention doesn't work.

@AsperTheDog It's all good, thanks for taking another look at it!
If you have any other ideas, let me know and I'll try them out. 🤘😼

NumPad keys' descriptions avoid this by starting with a word.

Add (+) key on the numeric keypad.

I think this can be done here as well, for all related descriptions.


Token's SOFA protocol

See here. SOFA is "A protocol to quickly develop apps for an open financial system."
Like Coinbase's Token I think of OpenBazaar as a platform (specifically, a marketplace platform), not as a standalone (ecommerce) app. Is OpenBazaar the next eBay? Or is it also the next Uber, AirBnb and KickStarter?
I believe we eventually want to give developers the power to write their own "OpenBazaar apps". The SOFA protocol which specifies allowable UI interactions is a possible way forward.

Like Coinbase's Token I think of OpenBazaar as a platform (specifically, a marketplace platform), not as a standalone (ecommerce) app. Is OpenBazaar the next eBay? Or is it also the next Uber, AirBnb and KickStarter?

Agreed, this was the vision all along. eCommerce is the beachhead.

I believe we eventually want to give developers the power to write their own "OpenBazaar apps". The SOFA protocol which specifies allowable UI interactions is a possible way forward.

It's a nice and simple model, and doing something similar would be worthwhile pursuing.


Error when evaluating SSR module (Unexpected token 'export') in DEV

Describe the bug
When I run pnpm run dev and load some page I've got an error in console:
3:53:23 PM [vite] Error when evaluating SSR module /.svelte-kit/dev/runtime/internal/singletons.js:
SyntaxError: Unexpected token 'export'
    at new AsyncFunction (<anonymous>)
    at instantiateModule (/home/www/sources/node_modules/.pnpm/vite@2.6.14_sass@1.43.5/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:66543:28)
3:53:23 PM [vite] Error when evaluating SSR module /.svelte-kit/dev/runtime/app/navigation.js:
SyntaxError: Unexpected token 'export'
    at new AsyncFunction (<anonymous>)
    at instantiateModule (/home/www/sources/node_modules/.pnpm/vite@2.6.14_sass@1.43.5/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:66543:28)
3:53:23 PM [vite] Error when evaluating SSR module /src/lib/Components/Base/LoginPopup.svelte:
SyntaxError: Unexpected token 'export'
    at new AsyncFunction (<anonymous>)
    at instantiateModule (/home/www/sources/node_modules/.pnpm/vite@2.6.14_sass@1.43.5/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:66543:28)
3:53:23 PM [vite] Error when evaluating SSR module /src/routes/__layout.svelte:
SyntaxError: Unexpected token 'export'
    at new AsyncFunction (<anonymous>)
    at instantiateModule (/home/www/sources/node_modules/.pnpm/vite@2.6.14_sass@1.43.5/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:66543:28)
Unexpected token 'export'
SyntaxError: Unexpected token 'export'
    at new AsyncFunction (<anonymous>)
    at instantiateModule (/home/www/sources/node_modules/.pnpm/vite@2.6.14_sass@1.43.5/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:66543:28)

But if I reload the page — no more errors until I again restart dev.
Reproduction
I can't tell exaclty why and when in happens, but looks like it's an error from packages. Probably after updating dependencies few days ago.
System Info
System:
    OS: Linux 5.4 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (2) x64 DO-Regular
    Memory: 249.28 MB / 3.84 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.13.0 - /usr/bin/node
    npm: 8.1.0 - /usr/bin/npm
  npmPackages:
    @sveltejs/adapter-node: ^1.0.0-next.55 => 1.0.0-next.55
    @sveltejs/adapter-static: ^1.0.0-next.21 => 1.0.0-next.21
    @sveltejs/kit: next => 1.0.0-next.200
    svelte: ^3.44.2 => 3.44.2

Severity
serious, but I can work around it
Additional Information
No response

I created a skeleton app and run in dev but I'm not getting the errors. Please provide a reproduction so we can track this down. Thanks!

Sorry, it was my mistake. But the reason of this error output totally unclear. I've just put image with wrong path (missed file):
img(src="images/default-ava.svg", alt="ava")
(I'm using svelte preprocess Pug)
So, it's really strange error output. And there is even no file where I'm put this missed image. Totally confused 🤷♂

Having the same types of issues here.  Valid Vite imports of functions in my .ts files are just failing.  Seems really random.

Without a proper reproduction there is nothing we can do to analyze this further. Please provide the required information.

The issue in the reproduction is caused by echarts exposing native JS modules without having "type": "module" in its package.json. This is a bug in that library; it should either add "type": "module" and use .cjs for the CommonJS files, or use .mjs for the modules. Either way, it should add an "exports" field to package.json. Otherwise, it won't work correctly in Node.
It can be worked around by including it in Vite's processing:
// svelte.config.js
export default {
  kit: {
    vite: {
      ssr: {
        noExternal: ['echarts']
      }
    }
  }
};

No idea what's going on with the original issue but since there's no repro there's no way for us to investigate — closing.

The issue in the reproduction is caused by echarts exposing native JS modules without having "type": "module" in its package.json. This is a bug in that library; it should either add "type": "module" and use .cjs for the CommonJS files, or use .mjs for the modules. Either way, it should add an "exports" field to package.json. Otherwise, it won't work correctly in Node.
It can be worked around by including it in Vite's processing:
// svelte.config.js
export default {
  kit: {
    vite: {
      ssr: {
        noExternal: ['echarts']
      }
    }
  }
};

No idea what's going on with the original issue but since there's no repro there's no way for us to investigate — closing.

This workaround isn't working anymore after the switch to Vite 3, reproduction in https://github.com/csjh/broken_kit


Add sorting for table frontends

Addresses #832

Example sorted by NarrativeQA - F1

Also there are other improvements that could be made (e.g. visual indication of which column is used for sorting, putting the sort in the URL) but I would prefer to address that in a new PR.


sigsev with forgejo

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x87a0c8]

goroutine 1 [running]:
github.com/updatecli/updatecli/pkg/plugins/resources/gitea/pullrequest.(*Gitea).isPullRequestExist(0x400037e2a0)
        /home/runner/work/updatecli/updatecli/pkg/plugins/resources/gitea/pullrequest/utils.go:38 +0x1b8
github.com/updatecli/updatecli/pkg/plugins/resources/gitea/pullrequest.(*Gitea).CreateAction(0x400037e2a0, {{0x40012a7b40, 0x40}, {0x4000e657f0, 0xe}, {0x4000e657f0, 0xe}, {0x0, 0x0}, {0x40012f66e0, ...}, ...}, ...)
        /home/runner/work/updatecli/updatecli/pkg/plugins/resources/gitea/pullrequest/create.go:37 +0x15c
github.com/updatecli/updatecli/pkg/core/pipeline.(*Pipeline).RunActions(0x4001060750)
        /home/runner/work/updatecli/updatecli/pkg/core/pipeline/actions.go:150 +0x934
github.com/updatecli/updatecli/pkg/core/engine.(*Engine).runActions(0x54ff460)
        /home/runner/work/updatecli/updatecli/pkg/core/engine/actions.go:22 +0x1c4
github.com/updatecli/updatecli/pkg/core/engine.(*Engine).Run(0x54ff460)
        /home/runner/work/updatecli/updatecli/pkg/core/engine/run.go:25 +0x290
github.com/updatecli/updatecli/cmd.run({0x2fc718e?, 0x0?})
        /home/runner/work/updatecli/updatecli/cmd/root.go:101 +0xb98
github.com/updatecli/updatecli/cmd.init.func5(0x54b1d40?, {0x40009826c0?, 0x0?, 0x2?})
        /home/runner/work/updatecli/updatecli/cmd/apply.go:47 +0x234
github.com/spf13/cobra.(*Command).execute(0x54b1d40, {0x40009826a0, 0x2, 0x2})
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:989 +0x81c
github.com/spf13/cobra.(*Command).ExecuteC(0x54b11c0)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1117 +0x344
github.com/spf13/cobra.(*Command).Execute(...)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1041
github.com/updatecli/updatecli/cmd.Execute()
        /home/runner/work/updatecli/updatecli/cmd/root.go:49 +0x68
main.main()
        /home/runner/work/updatecli/updatecli/main.go:8 +0x1c

Expected Behavior
Pull request opened
Steps To Reproduce
actions: gitea: {
	scmid: "forgejo"
	kind: "gitea/pullrequest"
}

Environment
- OS:

cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.20.3
PRETTY_NAME="Alpine Linux v3.20"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

- updatecli:
updatecli version

VERSION

Application:    0.85.0
Golang     :    1.23.2 linux/amd64
Build Time :    2024-10-07T06:48:15Z

Anything else?
https://forgejo.org
While forejo is a fork, I would imagine the pull request api wouldn't have diverged.
Worst case, I would expect updatecli to return a bit of an error about what happened, instead of crashing entirely

https://github.com/updatecli/updatecli/blob/d71451b35ef47a7e89b200f404538c5d544aa35b/pkg/plugins/resources/gitea/pullrequest/utils.go#L38
So that's that line, I imagine resp is probably nil in the case that an error is returned, so ironically trying to log debug information causes the crash :D

Changing the scm block spec to a API token does make it work. However I still would like to get oauth2 tokens working somehow.

Okay. After attaching a debugger. I think I have gotten to this point.
https://www.updatecli.io/docs/plugins/actions/gitea/ is slightly misleading, it says 'token' is an option, but it appears the gitea pull request action is basically driven from the SCM block, including the auth. So even if I specify the token here, I am getting the clone token anyway, annoyingly these seem to be slightly different in what gitea requires.
Eg a git clone, the oauth2 token is fine, and will work.
What's odd in curl, prefixing token, or bearer works. So now I can only think it's actually something in the http stack validating that http header, and failing before the http call.

A few things,

it says 'token' is an option, but it appears the gitea pull request action is basically driven from the SCM block

By default, all actions inherits parameters from the link scmid, for example the action gitea/pullrequest inherits default parameters from the scm gitea.
cfr https://github.com/updatecli/updatecli/blob/d71451b35ef47a7e89b200f404538c5d544aa35b/pkg/plugins/resources/gitea/pullrequest/main.go#L48

The only thing I don't really understand here is why a normal gitea token works

All API requests relies on a oauth2 token as defined on
https://github.com/updatecli/updatecli/blob/d71451b35ef47a7e89b200f404538c5d544aa35b/pkg/plugins/resources/gitea/client/main.go#L26
While by default git operation are done via basic auth http request
cfr


[Features] Support PV_RCNN module

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Support PV_RCNN module.
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the back-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects.
The documentation has been modified accordingly, like docstring or example tutorials.

Fix the remaining comments and LGTM


[New game]: Connect four game to be added

🎮 Game Request
Game logic and basic description
Connect Four (also known as Four Up, Plot Four, Find Four, Four in a Row, Four in a Line, Drop Four, and Gravitrips (in Soviet Union)) is a two-player board game in which the players first choose a color and then take turns dropping one colored disc from the top into a seven-column, six-row vertically suspended grid. The pieces fall straight down, occupying the lowest available space within the column. The objective of the game is to be the first to form a horizontal, vertical, or diagonal line of four of one's own discs.
Point down the features
Game points
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @pratyush0910 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hello @pratyush0910, Time's up!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗


update v4l2codec on android

great! +1

Hi Halley:
seems it's not build able for
"git clean -dxf && ./autogen.sh --prefix=$LIBYAMI_PREFIX --enable-tests --enable-v4l2  && make -j8 && make install"
"v4l2decode.cpp:67:20: error: ‘typeStrAndroidBufferHandle’ defined but not used [-Werror=unused-variable]
static const char* typeStrAndroidBufferHandle = "android-buffer-handle";
^
cc1plus: all warnings being treated as errors
make[2]: *** [v4l2decode.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory /home/thomas/projects/yami/libyami/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /home/thomas/projects/yami/libyami'
make: *** [all] Error 2

现在更正了。
抱歉，我本地fix了这个问题，忘了push到github了。

is it ok to merge?

@xuguangxin What's the status on this patch?

Hi @seanvk
It's only for android, we should decide it after all Android related things settled.If we do not need support android, maybe we will drop this patch set.

close this since we have #522


(MAINTENANCE) update settings with disables ticket ids (old, soldout)

I tried the trick of selecting 'no group' for the assigned ticket group, but it also 'unpins' the 'exhibitor' tag/role

@KarolinaTEH the best would be "disableTicketsIds" ... can you push update settings?

sure


add omitnil for map and slice

@maxatcn can you solve this problem?

@maxatcn can you solve this problem?


[WIP] What is QChem

Should be adjusted to fit the new website hierarchy, as discussed with Ben. :)
Tag @ikurecic for issues/changes.
Checklist
[✓] Images in relevant places
[✓] All metadata is properly populated
[✓] Renders properly

Thanks for this!
Overall it looks good, but major recommendation would be to merge the two sections drawing links between QML and QChem into one. I wasn't quite sure there was sufficiently clear motivation/explanation to draw it out into two sections

This was originally one section, but @ikurecic raised the point that the other "What is X" articles each have one more section compared to this one, so we split it in two. @ikurecic you okay if I revert this?

Thanks for this!
Overall it looks good, but major recommendation would be to merge the two sections drawing links between QML and QChem into one. I wasn't quite sure there was sufficiently clear motivation/explanation to draw it out into two sections

This was originally one section, but @ikurecic raised the point that the other "What is X" articles each have one more section compared to this one, so we split it in two. @ikurecic you okay if I revert this?

@isaacdevlugt — by all means, revert it, but we also do need a bit more content + to look at copy concerns Nathan pointed out. Since you wrote this one and have a much better idea of the intended meaning, any chance you'd want to do that?
We have until January.

Also if we could change the base from master to sc-30752-create-quantum-chemistry-subhub for this PR
That would help us manage merging sub-hubs into superhub PR as they get completed.

After I rebased, the deployment didn't render the actual "What is qchem" page:

@isaacdevlugt this is because the card link needs to be changed to what-is-quantum-chemistry; the actual page is https://qml-build-previews.pennylane.ai/pull_request_build_preview/584/what-is-quantum-chemistry.html

BTW something seems to have gone wrong in the rebase, there are now a lot of files marked as modified that shouldn't be modified 😬

@josh146 I fixed the rebasing errors, but not sure why there's a diff for .github/workflows/build-dev.yml and .github/workflows/build-master.yml 🤔

I think we're good @josh146 !


NPE in LSP refactoring

Thread 0 main threadNoSuchMethodError: NoSuchMethodError: The method '[]' was called on null.Receiver: nullTried calling: []("applied")
at Object.noSuchMethod(dart:core)
at ApplyWorkspaceEditResponse.fromJson(protocol_generated.dart:229)
at SimpleEditCommandHandler.sendWorkspaceEditToClient(simple_edit_handler.dart:81)
at <asynchronous gap>(async)
at PerformRefactorCommandHandler.handle.<fn>.<fn>(perform_refactor.dart:100)
at <asynchronous gap>(async)
at ServerStateMessageHandler.handleMessage(handlers.dart:189)
at <asynchronous gap>(async)
at LspAnalysisServer.handleMessage.<fn>(lsp_analysis_server.dart:330)

@DanTup
Which looks strange, I would expected cast exception in simple_edit_handler.dart:81 where we cast editResponse.result as Map<String, Object?>. Maybe we run LSP in google3 without null safety?

It looks that the server is null safe, at least I see dart_package(null_safety = True) in the BUILD file.
I don't see anything about the client :-(

It looks that the server is null safe, at least I see dart_package(null_safety = True) in the BUILD file.

hmm, the error seems odd then. Although I don't think whether null safety was on or not changes the issue here (only the error message/location it failed). The real issue is that the server got a response from the client that seems invalid.
Was the exception reported by a user, or come from something logging the exceptions? If the former, is it possible to ask them about their client/editor? If the latter, is it possible to have the --client-id and --client-version flags recorded with the exceptions so if this comes up again it will be easier to track down?
My feeling is that this is a client bug (eg. whatever editor the user was using is not strictly following the spec - it returned a response to the server without an error or a result) rather than a Dart/server issue. It would be nice to confirm that though (and if required, file a bug with whatever that LSP client is).

Was I wrong guessing that we should get the cast exception earlier in null safe mode?
It was logged, not reported. We configure the reporter here. I also see that we put some data about the client into the analytics session, but how it is used, I don't know.

Was I wrong guessing that we should get the cast exception earlier in null safe mode?

I don't think so, I would also have expected the error that you noted. I can't explain why that didn't happen though (unless it was not running with null safety, but I don't know about this environment so I don't know how that could have been the case).
It looks like the client ID is recorded in the "Application Installer ID" and the version in a custom dimension:
    // Record the client name as the application installer ID.
    analytics.setSessionValue('aiid', analysisServerOptions.clientId);
    if (analysisServerOptions.clientVersion != null) {
      analytics.setSessionValue('cd1', analysisServerOptions.clientVersion);
    }

I don't know if that's accessible from the exception reports though. It would be useful to know - for example if it's not VS Code, but Vim or Emacs or something, that might help track down the bug and file an issue the respective client.

We could try to add the client id/version here. It would be nice to have them as fields, but in CrashReportSender it would be too specialized for DAS. Or we could make it possible to add new fields to it. @devoncarew do you see issues with this?

@scheglov do you know if this has been seen recently?

No, actually we have very few crashes internally these days.

Ok, then I guess we should close this unless we see it occurring again. Thanks!