Procedural items

This issue supersedes #172 and is implemented by #256.
The larger changes to the CF governance process discussed at length in #172 have been pursued in a separate activity. I would like to capture the procedural changes affecting how we use GitHub that were discussed (and, I believe, mostly agreed) here.
People who have expressed interest in the original issue:
@castelao @davidhassell @JonathanGregory @ethanrd @dblodgett-usgs @martinjuckes @DocOtak @kevin-obrien @marqh @zklaus
People who expressed explicit support in their comments on that issue:
@DocOtak @ngalbraith
Summary of changes in PR
Implementation in GitHub / procedural stuff

[x] **Do we use semver?**Yes, but we shouldn't get hung up on it. Now we say we're "inspired by semver".
[x] Checklist before merges? Yes. Edit history.adoc, update authors, etc. in PR template.
[x] How do we ensure that issues are dealt with in a timely fashion? Attach the release frequency to the meeting so that changes actually come in. Note explicitly that pre-annual meeting 3 week feature freeze is a feature freeze. Tag stuff for milestones, that's motivating, and it summarises upcoming changes.
[x] Who sets tags and when? Secretary, 6 weeks after annual meeting.
[x] When do we delete branches? Whenever we want as long as they're not protected. Normally after merging.

Questions that in the #172 were considered interesting but are not addressed here:

Who owns docs from the website?
Align descriptive language in CONTRIBUTING.md with GH roles?

Thanks for summarising the issue(s), @erget. The constitutional aspect is now in https://github.com/cf-convention/cf-convention.github.io/issues/88. We will have to wait for the website-building process to be fixed before proceeding further. I put that issue in the cf-convention.github.io repository, rather than in this one, because it's not specifically about the conventions, but about the governance of CF as a whole, and the governance documents belong in the website. On the other hand, this issue belongs here because it's specific to the management of the conventions document.

Thanks @JonathanGregory for providing some context.
This PR is related solely to how we do things on GitHub. Currently we have no rules on how to accept such changes (I'd like to address that soon when taking a closer look at the "Rules" document on the website) and thus I propose that we treat it in the same way as we treat proposed changes to the Conventions themselves.
The proposed changes are summarised as follows:

Refer to issue templates rather than describing them in CONTRIBUTING.md. This makes us more flexible.
Offer help to those who are not familiar with GitHub if they have difficulties submitting proposals
Note that the 3-week rule implicitly includes a "feature freeze" that submitters should be aware of
Copyedit
Augment pull request template to include procedures for making it easier to mint a release after any given merge
Link to associated pull request in issue templates

Would anybody be willing to moderate the discussion surrounding these changes? I consider them to be of a minor nature.

This looks good to me and I support the changes. Thanks. I will also moderate the discussion, if there is any, unless someone who is more skilled with GitHub (i.e. practically anyone else) is willing to do it. These rules belong within the remit of the conventions committee, so I agree it's logical to apply the conventions rules to changing these rules, which means three weeks start today for disagreements and suggestions to be noted.

Looking at it again, I wonder whether what is happening to the text about single- and multiple-section changes in CONTRIBUTING.md - is it somewhere else? Thanks.

Hi @JonathanGregory I considered it an enhancement to the guidelines to combine them into one and the same category - "Enhancement" - and describe that in the issue template. In my opinion it's better to simply say in CONTRIBUTING something along the lines of "Use an issue template that matches what you want to do" and then describe what to do in the issue itself.
Furthermore I think it makes more sense to differentiate the approach by the nature of the change proposed, rather than simply how many sections would be changed - either way there may be the necessity for changes to multiple sections that the original author may not notice at first blush, and so a full review should take place IMHO regardless of whether the change text is small or large.
What do you think?

Dear @erget
Yes, I agree with

It's better to simply say in CONTRIBUTING something along the lines of "Use an issue template that matches what you want to do" and then describe what to do in the issue itself

and thanks for implementing that approach. In order to follow the approach, the contributor needs guidance to decide which template to use - whether it's a defect, typo fix, github issue or enhancement. These categories should be related to the two categories in the rules documents (making changes, and correction of errors).
I also agree that single- and multiple-paragraph changes are the same kind of enhancement and the guidance doesn't have to be separated like that. However, some of this advice is useful, and it would be a pity to lose it:

If important to the issue, the problem text should be pasted in the body of the issue and proposed fix included.
A link to the line where the problem exists could also be included.
If the modification is non-controversial, a pull request could be opened simultaneously.
Discussion of the proposal should take place in one issue.
Final review should take place in the pull request and the issue closed when the pull request is merged.
Depending on the nature of the proposal, interested community members can decide what the most effective tool is for development and review of specification changes.
Tools used for development of significant changes are up to those contributing and reviewing it.
Note that there is a rendered "rich-diff" view of a pull request that can be helpful for review of large contributions.

You may have put some of this in general guidance. If not, could the reminder belong in the template for an enhancement? Similarly, we currently have this guidance for a typo issue, which could go in its template:

A pull request with the fix can be submitted directly.
Contributors not familiar with github can submit issues for typos and similar issues for others to fix.

Thanks for considering this.
Jonathan

Hi Jonathan,
I agree that this guidance is useful and think it's best to put it in the appropriate issue templates.

If important to the issue, the problem text should be pasted in the body of the issue and proposed fix included.
A link to the line where the problem exists could also be included.

I've included both of these in the "Defect", template.

If the modification is non-controversial, a pull request could be opened simultaneously.

I've included this in the "Enhancement".

Discussion of the proposal should take place in one issue.

This is noted in CONTRIBUTING.

Final review should take place in the pull request and the issue closed when the pull request is merged.

I believe CONTRIBUTING also sufficiently covers this in its final section.

Depending on the nature of the proposal, interested community members can decide what the most effective tool is for development and review of specification changes.
Tools used for development of significant changes are up to those contributing and reviewing it.
Note that there is a rendered "rich-diff" view of a pull request that can be helpful for review of large contributions.

I would consider this implicit based on CONTRIBUTING lines 14-18:

These contribution guidelines are designed to make it easy to contribute to the
CF Conventions and are tailored to the platform where they are hosted, GitHub.
They are intended to support your work and not to constrict you; if at any time
you find them difficult to follow, ask for help.
Your contribution is valuable and the community will be happy to give a hand.

What do you think?
Cheers,
Daniel

I think that's fine, Daniel. Thanks for your thoroughness. Jonathan

Hi Daniel, this is all very good - thanks for putting it together. I support all of the changes/enhancements here, but I have one question: In .github/PULL_REQUEST_TEMPLATE.md  you have:
For maintainers

After the merge remember to delete the source branch

I'm not sure what this means, as the source branch will typically not belong to a maintainer, rather a member of the CF community. Perhaps I've misunderstood the term "Maintainer"? (As an aside, I wonder why is it good practice to delete source branches after they've been merged? I'm sure it is, just curious.)
David

Hi @davidhassell as in many things git-related, I don't feel that this is a best practice - it's more of a preference. I prefer a repository that feels tidy, and as branches are identifiers just like tags or commit IDs, having fewer of them makes for a more pristine autocomplete.
Under "Maintainer" I understand somebody who can perform a merge on the canonical repository - so probably the IM team in our case. My interpretation would be that if the source branch is on another repository, which will more often be the case, the proposer would do as they like with their branches.

@erget and others, I have some ideas for how to improve handling contributions/associated processes and a few GitHub recommendations.  Hopefully this is the right place to comment vs. opening a new issue.
This is from the perspective of a relative newcomer interested in making minor contributions to the convention docs.  If similar suggestions have been made already somewhere I missed, please disregard.
Mostly, these have to do with the current version of the Rules for Contributions from the website and also CONTRIBUTING.md.
Suggestions:

link directly from Rules page to this repo and/or discuss repo to make it obvious where to file an issue/proposal under which circumstances - cf-conventions repo for proposed changes to the conventions and discuss for standard names and other CF matters (as it is now the doc mentions GitHub and GitHub issues but isn't specific as to the repo and doesn't provide any links outside of the page itself, which is not very helpful).  It sounds like this may be in the works here in part, so ignore if so.  This would make the Rules page much more useful!

update the README in both repos with a clear link back to the Rules page and/or CONTRIBUTING.md page(s).  I didn't find any links to CONTRIBUTING.md outside of perhaps mentions in old issues, unless I missed them, and I think expecting new contributors (esp. those new to GitHub) to read that file is not reasonable.  Both resources should be called out clearly in the cf-conventions README.  The discuss README does this in part but it could also link back to the Rules page.  The README in the cf-convetions repo is also mostly technical and could use more repo usage/intent information to make it more informative.

add some means (such as an '@' team alias in GitHub) that allows contributors to directly communicate with the CF Governance Committee or some other appropriate governance team about dormant issues, and advertise this clearly in the Rules page, READMEs, CONTRIBUTING.md or elsewhere.  At the moment, it's not clear to me as a contributor whom I should try to engage with about the status of my PR and/or issue.  If an issue is created by someone and doesn't receive a moderator or discussion lags, what should the author do?  It's not clear IMO.  It would be helpful to describe where they can go for help or how to flag their issue for followup, and it might make the contribution process a better experience to newcomers and help grow the community.  Teams could be created from the current membership in the groups from the Governance page as a suggestion.

Dear Micah @mwengren
I think this issue should be confined to CONTRIBUTING.md and the other GitHub files outlined at the start, but I believe Daniel already has in mind to make Rules point to CONTRIBUTING.md as a separate issue. Your third point is good as well, but probably the answer to this has first to be decided before it can be advertised i.e. who is actually responsible. This depends both on the nature of the issue (technical GitHub/website vs content) and which repo it is (governance on the website, conventions, or standard names in discuss). I'd say that is an issue to be raised separately from this one.
Jonathan

@JonathanGregory thanks for your input.  Understand about the scope.  I will create a new issue to handle my third point regarding communication/feedback pathways for contributors.
Regarding the other two suggestions I made, if additional linkages between the Rules page and CONTRIBUTING.md are in the works, that will help.
I would still suggest expanding the scope here to include some edits to README.md to address the process of making contributions, whether they be links back to the Rules page or to CONTRIBUTING.md.  My recommendation would be just to add a header and paragraph titled 'Making Contributions to the CF Conventions' or something like that.
As is, the README still seems to be a little lacking as a front page about what the repo is and how users should interact with it.  It is the first place everyone will look, after all.

@mwengren, thank you for your comments and your further research on GitHub teams. Nonetheless your point is a good one. We need to define who is responsible for making sure issues proceed to a conclusion. This is a governance issue. I've made a note of it (on my own to-do list).
@erget, would you consider Micah's suggestion to add text to README.md that points to CONTRIBUTING.md and the rules? That makes sense to me, since README could be a natural place to look if you come to the repository first, rather than the website.

@mwengren @JonathanGregory thank you for your input. I've added some updates to README.md. I've proposed (surgical) changes to README.md accordingly (see #256 for details).

Thank you, @erget. I think that addresses @mwengren's point. Presuming he agrees with that, there are no outstanding matters. This enhancement (procedural items especially CONTRIBUTING.md) has sufficient support according to the rules and will be agreed on 23rd June if no further objections are raised.

Looks good to me, thanks.  I would still advocate for some clear process for contributors, in either issues or PRs, to ping the Governance Committee or other group of GitHub stewards about status of contributions, but as I said earlier, GitHub Teams don't currently support this, for better or worse.
Perhaps if they did someday or if @JonathanGregory or anyone else has good suggestions, this can be added in the Rules later on.

@mwengren I agree that this would be good! I also however think that this is separate from the issue at hand. Do you plan on attending the upcoming Community Workshop? There will be a session where we discuss GitHub procedures on the first day and I think your input here would be very valuable to help us continue to improve our processes.

Michah @mwengren, perhaps you could comment on https://github.com/cf-convention/cf-convention.github.io/issues/102, which is another issue from Daniel @erget. In that issue, I have proposed assigning particular labels, which would imply who was responsible for various classes of issue. I think that would help to solve the problem you identified in this issue. At least you would know who[m] to ping.
This issue (procedural items) is still on course to be agreed next Tuesday 23rd.

This issue has been approved, according to the rules, and I have merged the pull request. Thank you @erget for the proposal and to others for comments.


Made minor improvements

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: TiagoBrenck sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@kalyankrishna1 , please review


AMPI: manage freeing of keyvals from Comm_free and Comm_free_keyval

I've combined this commit with follow-on commits into my evan/romio_fixes branch.


Can't drag from right to left

Hello.
So, all your demos are left to right dragging.
When I try to use it for dragging from right to left, the internal state goes crazy and it somehow reset the state.
In the photo I attached you can see how i'm trying to go from right to left and it is continuously "reseting" the state instead of going smoothly from 421 to 430
react

I guess I'm experiencing the same issue. I put my ResizableBox to bottom-right of its container and when I resize it to the up or to the left, it behaves similarly to what @andrei102896 describes. Looks like during resize process onDrag callback is called with both negative and positive deltaX/Y (while on bottom-right resizing only same sign deltas occur).
Here is a basic snippet for this case:
<div
    style={ {
        width: 500,
        height: 500,
        display: 'flex',
        alignItems: 'flex-end',
        justifyContent: 'flex-end',
        backgroundColor: 'gold',
    } }
>
    <ResizableBox
        width={100}
        height={100}
        resizeHandles={ ['sw', 'se', 'nw', 'ne', 'w', 'e', 'n', 's'] }
     >
        <div style={ { height: '100%', backgroundColor: 'green' } }>
            Some content
        </div>
    </ResizableBox>
</div>

I'm not certain that what I'm experiencing is the same as those described above but I'm having a problem with resizing from the left and from the top as well. It does seem to be an issue of this library's internal state for detecting position deltas being invalidated by the top-left position of the object being moved due to the last resize callback, resulting in a jump, which then causes further confusion with internal state, resulting in a series of jumps back and forth over where the user is actually dragging.
I've put together a simple codesandbox reproduction showing how dragging an object from the right of a left-justified object, not affecting its top-left positioning results in a smooth resize, whereas dragging from the left of a right-justified object, which DOES change the top-left positioning results in a horrible stutter: https://codesandbox.io/s/react-playground-vwlpk?file=/index.js
Samples:

Dragging to the right: smooth

Dragging to the left: jumpy/flickering

I've just opened a PR https://github.com/STRML/react-resizable/pull/136 to address this issue. Hopefully it gets in soon 🤞


Fixes #67

Will this still produce CDATA for non-empty binary strings?

The round trip tests just make sure that x == deserialize(serialize(x)). Since I bet we'll treat them the same when deserializing, there isn't really any verification that the serialization stays consistent...
I opened #77 to track that fix in the future.

Fair enough. I'll write a test for the binary thing later today.

Oh shoot, I completely misread the actual issue this was fixing 😅
I'll fix it up in a minute.

Can you add an entry to the changelog for rbx_xml and link to this PR?

Travis build hung, I'll restart it...


leiningen always uses java from package 'jdk"

Describe the bug
I would like to use leiningen and decide the jdk version its using
Steps To Reproduce
Steps to reproduce the behavior:

install package leiningen
install alternative jdk, for example: jdk21
force JAVA used by leiningen version via:  JAVA_HOME=/nix/store/iqz8lfhx69qxb0ydixfldsf0wiw87q34-openjdk-21+35 lein version

Expected behavior
java 21 should get reported and used
Leiningen 2.10.0 on Java 21
found behaviour
default  jdk is used:
Leiningen 2.10.0 on Java 19.0.2
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
 - host os: `Linux 6.1.84, NixOS, 23.11 (Tapir), 23.11.5987.d272ca50d1f7`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"home-manager-23.11.tar.gz, nixos-23.11, unstable"`
 - channels(carsten): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

jdk seems to be "hardcoded" by ths line:
https://github.com/NixOS/nixpkgs/blob/4c62c9792c90c78a6029b49d3a91f1bb733afaba/pkgs/development/tools/build-managers/leiningen/default.nix#L24

You should be able to override jdk argument, with your desired java version, as long as it's compatible to leiningen. Be aware that this will result in a cache miss and you will need to build it on your machine.
Idk leiningen, by I would also more suspect the JAVA_CMD few lines later to control the used java version, not the propagatedBuildInput.

Thanks @Shawn8901 ,
it solved it.


POC showing kubeflow on Tekton

This PR shows a working POC of a Tekton Ppipeline
generated by a kubeflow DSL.

/assign @jerop

Thank you Chitrang!  🤗
@mihaimaruseac @laurentsimon, Chitrang reverse-engineered the Tekton Pipeline into a Kubeflow Pipeline, which would be more familiar with ML engineers. Users can then compile the Kubeflow Pipeline into a Tekton PipelineRun, using Kubeflow on Tekton. PTAL 🙏🏾

@chitrangpatel please update the future work item for adding kubeflow on tekton

Can you fix the lint issues, please?

We still need the lint fixed and then rebasing the PR on main should make it meargeable

Thank you!


Delete LimitingViewport and call ViewportLimiter from Navigator

The purpose is to simplify our code.  The LimitingViewport served a purpose once. It was the gatekeeper that made sure the limit of the Viewport was correct. Now that the Navigator is the primary way to set the Viewport the LimitingViewport can be removed. Within the Navigator we need to explicitly check the ViewportLimiter.

Related #https://github.com/Mapsui/Mapsui/issues/908

I‘m not sure, if the Navigator is the right place. It is a limiter for the Viewport, then it should handled there. The Navigator try’s to set values for the Viewport, but the Viewport handles this new values by respecting the ViewportLimiter. If you set the Viewport values by hand without the Navigator, should then the ViewportLimiter not respected?

This was now rewritten. The Viewport is now a record that only holds te state and does no manipulation. The Navigator transforms the viewport and makes sure the limiting is always applied. There is no separation between the LimitedViewport and the Viewport.


Bump deps

Bump a couple of dependencies. crossbeam requires some code changes and a documentation link update.

Things to check before submitting a PR

[x] the tests are passing locally with cargo test
[x] cookbook renders correctly in mdbook serve -o
[ ] commits are squashed into one and rebased to latest master
[ ] PR contains correct "fixes #ISSUE_ID" clause to autoclose the issue on PR merge
[x] spell check runs without errors ./ci/spellchecker.sh
[x] link check runs without errors link-checker ./book
[x] non rendered items are in sorted order (links, reference, identifiers, Cargo.toml)
[x] links to docs.rs have wildcard version https://docs.rs/tar/*/tar/struct.Entry.html
[x] example has standard error handling
[x] code identifiers in description are in hyperlinked backticks

Things to do after submitting PR

[ ] check if CI is happy with your PR

can you remove partial.md from this PR?

Rebased.


[Request for External] Make InsertGroup() @ Codeunit 7111 "Insert Analysis Line" public

I'd like to request that you make the function InsertGroup() public so that we as partners can extend the functionality.
Please let me know if you need more information from me.
// Status Quo:
local procedure InsertGroup(var AnalysisLine: Record "Analysis Line"; GroupDimCode: Code[20]; TotalingType: Enum "Analysis Line Type")
// Requested:
procedure InsertGroup(var AnalysisLine: Record "Analysis Line"; GroupDimCode: Code[20]; TotalingType: Enum "Analysis Line Type")

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


How to get the distance of the vehicle from a building?

Thanks for Carla team hard work.

I want to know how to get the distance of the vehicle from a building ? there is a way without use a Lidar sensor.
How to get attributes for a building (as id )?

Help me please

Hello @yousinf. Only dynamic actors such as vehicles or pedestrian have unique ids, used to identify them. This also holds true for static actors such as landmarks (traffics lights, traffic signs...).
The rest of the scene has id = 0, and all their actor properties are set to their default values. For example, if you add a CollisionSensor to your vehicle and crash with a building, you can see that it has id = 0 and location = (0,0,0)

OK. Thanks.

@yousinf I don't know what you are really trying to do, but let me send this your way. How about setting a depth sensor camera and a semantic segmentation camera? You can retrieve the depth (distance) for the building classes.


[v11] Lazy load deprecated dtypes

Backport of #7245 for v11. (I forgot to do this in #7263)
This avoids emitting DeprecationWarning when importing CuPy in NumPy 1.24 environment.

/test head

Confirmed import error resolved.


onLeave is called when changing params

The onLeave hook of the route is called when changing params of a route.
Given the following route config:
{
  name: 'profile',
  path: '/profile/:username',
  onLeave() { /* ... */ }
}

Changing from profile/foo to profile/bar will call onLeave. Is this intentional?

This is a react-router issue, if anything. This doesn't have to do with this library.


Unexpected warning: Expected a colon (:) followed by a query

For this query in my .moor file:
worksByComposer:
SELECT DISTINCT A.* FROM works A, works B ON A.id = B.part_of
    WHERE A.composer = :id OR B.composer = :id;

I get the following unexpected warning from the builder:
[WARNING] moor_generator:moor_generator on lib/database.dart:
line 45, column 46: Expected a colon (:) followed by a query
   ╷
45 │ SELECT DISTINCT A.* FROM works A, works B ON A.id = B.part_of
   │                                              ^
   ╵

If this warning is intended here, I would like to know what I'm doing wrong. Thanks a lot!
EDIT: I just noticed that the query is also not working as expected. It generates the following function which omits the intended parameter :id:
Selectable<Work> worksByComposer() {
    return customSelectQuery('SELECT DISTINCT A.* FROM works A, works B',
        variables: [], readsFrom: {works}).map(_rowToWork);
  }

In my understanding the query is invalid indeed. You use a join constraint (ON A.id = B.part_of), but those only work with join operators, not when selecting multiple tables with a comma. So something like FROM works A LEFT JOIN works B ON ... should work.
When we hit a parsing error (like in this case), we try to make the best out of it. If we just failed as soon as we hit any error, working on a moor file with multiple syntax errors is very annoying - so we try to report all of them. This means that moor will do some lax parsing in case of an error. In this case, it saw that the part until the ON is a valid query on its own, and decided that what follows has to be another query. So, it interprets the ON as a query name and then complains about a missing colon.
In this case, the parser recovery resulted in an unfortunate error message that made things more confusing. In general this is tricky to get right and the errors only indicate a rough position, but this seems like an easy case to improve.

This will be fixed in the next moor version - thanks again for the report.

Thanks for fixing the warning! I got this confusing syntax from the w3schools SQL tutorial. I guess, Google brought me there. Afterwards I slipped the ON in and the confusion was complete. The funny thing is, that this query works just fine and as expected in SQLite, otherwise I hadn't filed an issue. Of course I'll rewrite it anyway. Thanks for the explanation!

this query works just fine and as expected in SQLite

You're right, good catch! This is a parser bug indeed, I think I've misread the syntax diagram for selects. This should be fixed with 1a2d3bdee75d6dc4defeef480283c38db5fba1fb, so in the next moor version that query should be parsed correctly. Until then, you can manually specify the join operator as a workaround.


environment variable not set

Hi, looking at your docker-compose file, every service sets the reschedule environment variable to on-node_failure. Is that what you are trying to do ?
Because it is not get set in the running container. Docker-compose silently fails (yaml gets parsed properly).
that's because you should use an equal sign.
Instead of:
    environment:
      - reschedule:on-node-failure

we should have:
    environment:
      - reschedule=on-node-failure

Unless I misunderstand what this env is doing.

thanks @runseb, yes that was the desired behaviour. I will update the docker compose files


Testbed does not halt on error

Connection errors, for example, do not terminate the script. Living it to finish only in the occurrence of a fatal error or in the end of the timeout. We should try to detect those errors - taking an appropriate action - before continuing.

Covered by #66


fixed .travis.yml inconsistency

Codecov Report

Merging #8 (d8b349c) into main (2a98020) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #8   +/-   ##
=======================================
  Coverage   72.47%   72.47%
=======================================
  Files           4        4
  Lines         476      476
  Branches       74       74
=======================================
  Hits          345      345
  Misses        131      131

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 2a98020...d8b349c. Read the comment docs.

:tada: This PR is included in version 0.0.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


editorial pass on project tech docs

Fixes #1695

@ma2b0043 please review. Bucky did almost all of the work, this is more or less an editorial pass. If it's easier for you to review, feel free to comment directly here and I will address the issues: https://docs.google.com/document/d/1cYrze9UYB7KjIjkxNs7ZXy_Bv3bOS6DkVCQtAoZsYYo/edit?usp=sharing


[Improvement] Update API references from v4

Description

Rename livestream demo package name to com.uiza.module.samplelivestream
Re-generate Docs

Impacted Areas

Sample livestream

Ticket URL

https://uiza.slack.com/archives/CJD7KQN64/p1559265726030600

Seem this PR is not valid, close now & update later !


Both CJS and ESM versions of dependency loaded, causing React Context mismatch in test

Describe the bug
In my repo, I have some context that is not being recognized by another package. I've identified the issue as caused by the React provider being loaded from the ESM version of the wagmi package, but the next context which consumes the WagmiConfig context, loading the CJS version of the wagmi package. Because react context is based on a global, having two different files loaded is causing context to not work.
The app works fine in vite dev! I'm having trouble tracking down why vitest is loading the ESM version of the wagmi dependency in the direct reference, but the CJS one when referenced from the @rainbow-me/rainbowkit package.
Reproduction
https://github.com/metaphor-xyz/ens-small-grants
yarn install && yarn test
System Info
System:
    OS: macOS 12.3.1
    CPU: (8) arm64 Apple M1
    Memory: 81.39 MB / 16.00 GB
    Shell: 3.4.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 16.14.2 - ~/.local/share/nvm/v16.14.2/bin/node
    Yarn: 3.2.1 - /opt/homebrew/bin/yarn
    npm: 8.5.0 - ~/.local/share/nvm/v16.14.2/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 102.0.5005.61
    Firefox: 92.0
    Safari: 15.4
  npmPackages:
    @vitejs/plugin-react: ^1.3.0 => 1.3.2
    vite: ^2.9.9 => 2.9.9
    vitest: ^0.12.9 => 0.12.9

Used Package Manager
yarn
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 reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

A little more investigation on this, I found a workaround by inlining @rainbow-me/rainbowkit:
/// <reference types="vitest" />
import react from '@vitejs/plugin-react';
import { defineConfig } from 'vite';

// https://vitejs.dev/config/
export default defineConfig({
  define: {
    global: process.env.VITEST ? 'global' : 'globalThis',
  },
  plugins: [react()],
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/test/setup.ts',
    deps: {
      inline: ['@rainbow-me/rainbowkit'],
    },
  },
});

I dug into a little of how the VitestPlugin works, it seems likely the culprit here is resetting the mainFields config option:
https://github.com/vitest-dev/vitest/blob/3d8eba4e8bcfdee7c6f0800fb637e9814fb2c583/packages/vitest/src/node/plugins/index.ts#L72-L77
However, simply removing that line causes other libraries to break, because of the behavior described in the comment. This workaround is fine, but I'm wondering if there is a way to fix this behavior, since it does work fine in the Vite dev server. It's also a very tricky bug to track down, I spent several hours figuring this out!

mainFields is a field on top level of your package.json. Usually Node cannot import this files, because they are not actually ESM (for example, named .js in a commonjs package). This is why it is disabled.
Vitest imports a cjs version of wagmi package, because their exports field is incorrect. See explanation.
The right way to do it is to create an issue in the repo and fix it. And inline dependency, while they are fixing it.


Add files via upload

Looks good!

The "green check" means the check was ran at this commit which also includes all previous files you have made in this same pull request. All of your validators were included in this pull request. If you plan to upload more validators, please open a new pull request.


python36Packages.django_classytags: 0.6.1 -> 0.8.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/python3.6-django-classy-tags/versions.
meta.description for python36Packages.django_classytags is: '"Class based template tags for Django"'.

Checks done (click to expand)

built on NixOS

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.8.0 with grep in /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0

directory tree listing: https://gist.github.com/ab8f0de6fa352e3b9f38373adce50362

du listing: https://gist.github.com/eb3803dde8047167dd9c9b8d7dc1427d

Outpath report (click to expand)

Outpath difference report
8 total rebuild paths
2 package rebuilds
2 x86_64-linux rebuilds
2 i686-linux rebuilds
2 x86_64-darwin rebuilds
2 aarch64-linux rebuilds
First ten rebuilds by attrpath
python27Packages.django_classytags
python36Packages.django_classytags

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A python36Packages.django_classytags https://github.com/r-ryantm/nixpkgs/archive/5ae13d48d26d65522a2af3027619abecc1d15015.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0
ls -la /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0/bin

Success on aarch64-linux (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
Installing collected packages: django-classy-tags
Successfully installed django-classy-tags-0.8.0
/build/django-classy-tags-0.8.0
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0/lib
patching script interpreter paths in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0
checking for references to /build in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0...
/nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0

Success on x86_64-linux (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
Installing collected packages: django-classy-tags
Successfully installed django-classy-tags-0.8.0
/build/django-classy-tags-0.8.0
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0/lib
patching script interpreter paths in /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0
checking for references to /build in /nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0...
/nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0

Success on x86_64-darwin (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
Processing ./django_classy_tags-0.8.0-py2.py3-none-any.whl
Requirement already satisfied: Django>1.3 in /nix/store/b6g5wsgqigbv2gcnir4x2g3i9pv343m4-python3.6-Django-1.11.16/lib/python3.6/site-packages (from django-classy-tags==0.8.0) (1.11.16)
Requirement already satisfied: pytz in /nix/store/9hns3297dvdf7yxg5fp7xk8pyyk4fxbc-python3.6-pytz-2018.5/lib/python3.6/site-packages (from Django>1.3->django-classy-tags==0.8.0) (2018.5)
Installing collected packages: django-classy-tags
Successfully installed django-classy-tags-0.8.0
/private/tmp/nix-build-python3.6-django-classy-tags-0.8.0.drv-0/django-classy-tags-0.8.0
post-installation fixup
strip is /nix/store/g5r4apl0za012ffs6ladinwa5w0m1l3k-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/7hj39hihm52awvypzhni3fi82q7wn2q2-python3.6-django-classy-tags-0.8.0/lib
patching script interpreter paths in /nix/store/7hj39hihm52awvypzhni3fi82q7wn2q2-python3.6-django-classy-tags-0.8.0

checked and clarified why tests need to be disabled

Success on aarch64-linux (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
Installing collected packages: django-classy-tags
Successfully installed django-classy-tags-0.8.0
/build/django-classy-tags-0.8.0
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0/lib
patching script interpreter paths in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0
checking for references to /build in /nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0...
/nix/store/slcq9ckb4g8siybsx7bmxrhzyv8gkqnf-python3.6-django-classy-tags-0.8.0

Success on x86_64-linux (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
/nix/store/q57ibz8f4941aga4815yb65kwqxqm3h5-python3.6-django-classy-tags-0.8.0

Success on x86_64-darwin (full log)
Attempted: python36Packages.django_classytags
Partial log (click to expand)
Requirement already satisfied: Django>1.3 in /nix/store/b6g5wsgqigbv2gcnir4x2g3i9pv343m4-python3.6-Django-1.11.16/lib/python3.6/site-packages (from django-classy-tags==0.8.0) (1.11.16)
Requirement already satisfied: pytz in /nix/store/9hns3297dvdf7yxg5fp7xk8pyyk4fxbc-python3.6-pytz-2018.5/lib/python3.6/site-packages (from Django>1.3->django-classy-tags==0.8.0) (2018.5)
Installing collected packages: django-classy-tags
Successfully installed django-classy-tags-0.8.0
/private/tmp/nix-build-python3.6-django-classy-tags-0.8.0.drv-0/django-classy-tags-0.8.0
post-installation fixup
strip is /nix/store/g5r4apl0za012ffs6ladinwa5w0m1l3k-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/7hj39hihm52awvypzhni3fi82q7wn2q2-python3.6-django-classy-tags-0.8.0/lib
patching script interpreter paths in /nix/store/7hj39hihm52awvypzhni3fi82q7wn2q2-python3.6-django-classy-tags-0.8.0
/nix/store/7hj39hihm52awvypzhni3fi82q7wn2q2-python3.6-django-classy-tags-0.8.0


[NCGenerics] add ~Escapable

This PR introduces the Escapable and ~Escapable types with support for generics, etc, matching what ~Copyable is capable of today.
resolves rdar://119216918

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please test

@swift-ci please test


Feature request: Configurable IPv6 Prefix Advertisements

My Problem is the use of Global Unique und Unique Local Unicast addresses at the same time on the same interface which is supportet by the IPv6 standard. To utilize this it would be needed to advertise them which should be configurable under /services_router_advertisements.php there should be a new list like "Advertise Routes" which would configure the "ICMPv6 Option (Prefix Information)" in the ICMPv6 Packets of type "Router Advertisment (134)".
Respecting the possibility of dynamic prefixes via interface tracking, it should be considered the possibility how to enter this possibly changing prefix into this form.

As I am new to writing feature requests on GitHub I hope it is not rude to ask for guidance why my request recieved the "incomplete" label, but as far as I can see I considered every aspect of the issue template:

I described my problem ([...] the use of Global Unique und Unique Local Unicast addresses at the same time [...]
I described the solution I would like ([...] a [...] list like "Advertise Routes", [...] under /services_router_advertisements.php [...]) and noted a clear and concise description of what I want to happen ([...] configure the "ICMPv6 Option (Prefix Information)" in the ICMPv6 Packets of type "Router Advertisment (134)" .)

It's not rude, no problem at all, we tend to mark issue incomplete if our templates aren't used.


Correction for raw affiliation IHRIM, Lyon, France

Correction needed for raw affiliation IHRIM, Lyon, France
raw_affiliation_name: IHRIM, Lyon, France
new_rors: ;02wmc6m46
previous_rors:
works_examples: W4235991046;W4389798259;W4362499816
contact: 1c29503260de88a5f34259ccf43a695e:e4b39829c7066d68ebe1804a2352 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-01. The new affiliations should be visible within the next 7 days.


update readme

Some info for users if they encounter problems with building

Thanks for figuring this out!
Please for consistency purposes change the title so that it follows this convention: https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type, for example: docs: add troubleshooting instructions
Also please use this template for the PR description :)

Thanks for figuring this out!
Please for consistency purposes change the title so that it follows this convention: https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type, for example: docs: add troubleshooting instructions
Also please use this template for the PR description :)

Ok done.


Fixed not properly returning calls of #eval

Fixes the eval(string) issue of #3429. The generated proc is executed by the same code that's used by Object#instance_eval(&block). Calling eval('Fiber.yield') (#3415) works.

Wooops. Doesn't work after all...


Bugfix/yousong network

这个 PR 实现什么功能/修复什么问题:
networks: sep check of masklen only for start,end type creation
networks: decrease indent
networks: validateUpdateData: eliminate intermediate vars
networks: validate that start, end, gateway ip are in the same subnet

[x] 冒烟测试

[x] 正常创建
[x] 创建：start, end ip不符
[x] 创建：gateway ip不符
[x] update

是否需要 backport 到之前的 release 分支:

release/3.2

/area region
/cc @swordqiu @ioito @zexi

Codecov Report

Merging #6775 into master will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #6775      +/-   ##
==========================================
- Coverage    7.13%    7.13%   -0.01%
==========================================
  Files         650      650
  Lines      109894   109929      +35
==========================================
  Hits         7843     7843
- Misses     101445   101480      +35
  Partials      606      606

Flag
Coverage Δ

#aFlag
7.13% <0.00%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/compute/models/networks.go
0.52% <0.00%> (-0.02%)
:arrow_down:

pkg/appsrv/response.go
66.17% <0.00%> (ø)

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 232077b...0280b6a. Read the comment docs.


Why not use the output of ICP as the loop constrain edge for iSAM?

Hi @TixiaoShan ,I'm a little confused about the data in loopPoseQueue.
These are the relevant codes：
        // Get pose transformation
        float x, y, z, roll, pitch, yaw;
        Eigen::Affine3f correctionLidarFrame;
        correctionLidarFrame = icp.getFinalTransformation();
        // transform from world origin to wrong pose
        Eigen::Affine3f tWrong = pclPointToAffine3f(copy_cloudKeyPoses6D->points[loopKeyCur]);
        // transform from world origin to corrected pose
        Eigen::Affine3f tCorrect = correctionLidarFrame * tWrong;// pre-multiplying -> successive rotation about a fixed frame
        pcl::getTranslationAndEulerAngles (tCorrect, x, y, z, roll, pitch, yaw);
        gtsam::Pose3 poseFrom = Pose3(Rot3::RzRyRx(roll, pitch, yaw), Point3(x, y, z));
        gtsam::Pose3 poseTo = pclPointTogtsamPose3(copy_cloudKeyPoses6D->points[loopKeyPre]);

        loopPoseQueue.push_back(poseFrom.between(poseTo));

Why not use the output of ICP, i.e. correctionLidarFrame, as the loop constrain edge for iSAM directly?
And suppose the world origin is W, the current pose is C, the history loop frame pose is H, then correctionLidarFrame = H2C, tWrong = W2C. Thus, tCorrect = H2C * W2C. I cannot understand what tCorrect means?

correctionLidarFrame is the correction delta_transform, which is the global perturbation got from icp, not local perturation, because icp's source and target point clouds are already transformed into the global frame. So we can view correctionLidarFrame as a transformation, which start from history keyframe to current keyframe in the global frame perspective. Gtsam is hamilton, so multiplys left, not right.

@narutojxl  Can you explain it in more detail as I'm new to Gtsam? You said  "correctionLidarFrame can be viewd as a transformation, which start from history keyframe to current keyframe in the global frame perspective", does it mean that “correctionLidarFrame = H2C ” ? And does Gtsam require the between Factor in local frame or global frame?

If icp's source and target point clouds are all in their own's local frames, then you will get H2C transform, which transforms points from source frame into target frame, namely transforms points from current keyframe into history keyframe. Meanwhile, this transform is  current keyframe's pose with respect to history keyframe.  But in code, author already transformed them into global frame, so  correctionLidarFrame is in the global frame. It is a global perturbation of current keyframe, not local.
Because gtsam's pose  is hamilton, with a global perturbation to corret current keyframe, we multiply it left on the old pose, not right.
Gtsam's between factor between A pose and B pose is A respect to B , or B respect to A, which depends on the order of you call  this API. It is a local transform, not global.

If icp's source and target point clouds are all in their own's local frames, then you will get H2C transform, which transforms points from source frame into target frame, namely transforms points from current keyframe into history keyframe. Meanwhile, this transform is  current keyframe's pose with respect to history keyframe.  But in code, author already transformed them into global frame, so  correctionLidarFrame is in the global frame. It is a global perturbation of current keyframe, not local.
Because gtsam's pose  is hamilton, with a global perturbation to corret current keyframe, we multiply it left on the old pose, not right.
Gtsam's between factor between A pose and B pose is A respect to B , or B respect to A, which depends on the order of you call  this API. It is a local transform, not global.

Thank you for your patient explanation. If the pose in the global frame is specified as P', then correctionLidarFrame = H'2C', and tWrong = W'2C'.Thus, is this equation that tCorrect = correctionLidarFrame * tWrong = H'2C' * W'2C’ = H2C  right as you said that a local transform is needed by GTSAM's between factor?

Not true, tCorrect is corrected current keyframe's pose in global frame.

Not true, tCorrect is corrected current keyframe's pose in global frame.

Thanks. I finally understand what you said.
I'm confused about how to understand tCorrect = correctionLidarFrame * tWrong  mathematically. For example,What would happen on this equation if we exchange the source cloud and target cloud of ICP?

If we exchange source and target clouds of icp in code,  i guess maybe we will get history keyframe's global perturbation, i don't know how to derivate its meaning in mathematics, if we don't do a test to verify.
If we do not firstly change source and target clouds into global, namely souce point clouds are in current keyframe, target point clouds are in history keyframe, then what's the meaning of icp's transformation, does it transform points from corrected current keyframe into history?  How to derivate its meaning in mathematics?  To be honest, I have no idea.
Hi dear knowledgeable author, @TixiaoShan, how did you derive?

I hold the same doubts with FishInWave. Suppose source cloud and target cloud fully overlap with each other, then correctionLidarFrame is identity matrix, does it mean the current pose does not require correction based on the code?
BTW, @narutojxl what do you mean by "BetweenFactor is in local frame"?

If source and target fully overlap,  correctionLidarFrame should be I. But there always exist drift(small or big) in backend, this rarely happens. Gtsam's between factor between A pose and B pose is A respect to B , or B respect to A, which depends on the order of you call this API.


Setup Teams feature under Organisation to enable addtional feature

Reference Link

Team section is visible, Thanks @AryanGupta0007
Closing this issue now.


⚠ Bofrost.lu has degraded performance

In 9bc685d, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1447 ms

Resolved: Bofrost.lu performance has improved in 6e0886b after 19 minutes.


Add Function to Define setUp and tearDown in niml and nimy

Add function to define setUp and tearDown in niml nand nimy.
setUp runs when the lexer/parser is constructed and tearDown runs when they destructed.

[x] implement setUp and tearDown in niml
[x] ~implement setUp and tearDown in nimy~
[x] add documents

tearDown is unsuitable for nimy's design

closed by #55 and #67.

closed by #55 and #67.


keep the precedence of the vscode auto-import completion items

set the sortText prefix to U+FFFF9 + the current index, in order keep the precedence of the auto-import completion items.
vscode uses U+FFFF5 as sorting string for auto imported completion items
https://github.com/microsoft/vscode/blob/6ec6f9e3f4d17f0cef0480688a1f350b9141e567/extensions/typescript-language-features/src/features/completions.ts#L56

init the kind property in case of undefined ( language service is not started )

remove the preselect property and let vscode to select the matching item

I've tested this locally (by modifying the out file) and it seems to work as intended, any chance we can get a pair of 👀 at this? I also see a conflict right now..

@dimacodota ??

Why was this closed?

This was resolved in another PR. Why? Are you experiencing any issues regarding it?

Oh, it was? I didn't catch that, but it seems to not be respected still, unless I'm understanding it wrong, I'd expect TS suggestions first 👀

@vladfrangu yea you are understanding it incorrectly. You should expect TabNine suggestions 1st always.

We currently do not support configuration for that (nor do we plan to), but we would love to receive any ideas regarding how to improve our suggestions and overall experience.

@vladfrangu yea you are understanding it incorrectly. You should expect TabNine suggestions 1st always.

But..why? The point of this PR was to change exactly that, and make TS suggestions come before TabNines (the GIF attached in the PR description shows just that), as it gives far more accurate results context wise... I love TabNine, I really do, but personally, I'd expect TS suggestions first, and as I start typing out what I'm looking for, making the query return less and less, see both TS and TabNine directly after so I can go "Down arrow, tab" and get the sweet AI autocomplete.
This can also be a very simple config option to add, a simple true/false which adds the prefix from this PR if enabled, or doesn't otherwise 👀
Even from the screenshot I shared, the TabNine autocompletes are really..not..helpful (in this one example). Of course, this is just feedback, I still love how helpful TabNine is overall, and it has helped me skip a lot of time wasted on tedious things!

This PR didn't intent to address what you describe.
I totally understand your expected behaviour, and will let @avichay77 know so we will take this into account.
Please do not expect that behaviour to change currently, as we strongly believe that setting a lower priority to TabNine is not a sustainable solution. But we are experimenting with different ways to improve its behaviour.
Thanks you for caring and using TabNine! We highly appreciate your feedback!

This PR actually addressed what I described, here's a screenshot with the code and it's result:
Before "this PR" (before applying the prefix manually)

After "this PR" (after applying the prefix manually, and disabling preselect like in this PR) (the highlighted client in the second image is the TabNine suggestion)

Of course, this wouldn't be something you'd want enforced (by all means, for most people, TabNine is probably what they want to see first when it comes to suggestions, and from a product stand point it makes a LOT of sense), but rather something that a user can choose to change (so you can optionally change it if you so desire). I can also respect not wanting to add this behavior (although it would really help me and others out, as we want TabNine to augment our suggestions, not overtake them entirely (or require us to scroll down through suggestions to get to the ones provided either by TS or extensions that provide Intellisense based on the language one uses); I know this has deferred one of our teammates from using TabNine :c), hence this is just a feedback! I'm glad to hear that it will be taken into account, and I wish all of you a great day! ❤


You use wrong host name to check my school again.

Hi, Philipto
You use wrong host name to check my school mail server
The currect domain was live.asia.edu.tw.
Is  ASIA not ASIS, please check again thanks for you help.
Institution/School Name
Asia University, Taiwan
Instiution/School Website
https://www.asia.edu.tw/
Email Users
e.g<EMAIL_ADDRESS><EMAIL_ADDRESS>Please place an x between the square brackets if yes

[x] Students
[ ] Academic/Teaching Staff
[ ] Other/Support Staff
[ ] Alumni

Education Levels
Please place an x between the square brackets if yes

[ ] Post-graduate research
[ ] Graduate School
[x] College (University) or Undergraduate School or equivalent
[ ] Community College or equivalent
[ ] High School or equivalent
[ ] Elementary School or equivalent

@wade9058 I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host live.asis.edu.tw not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for understanding!


reserveCells crashes mint mesh inside Umpire

Crash reserving space for UnstructuredMesh

This PR is a bug fix
It does the following:

Adds tests that verify the crash (which happens on our docker platforms)
Fix the bug (if it is indeed a bug) or make the code die gracefully

This crash has been plaguing PR https://github.com/LLNL/axom/pull/1263.  The MarchingCubes test crashes while asking mint::UnstructuredMesh to reserve space.  This PR aims to provide a reproducer and correct the crash.
Two identical tests were added:

In src/axom/quest/tests/quest_initialize.cpp
In src/axom/mint/tests/mint_mesh.cpp

Interesting behaviors:

The test added to quest reproduces the crash, but the one added to mint does not.
The crashes only occur in our docker builds.
Bypassing the memory reserve calls doesn't work for the originating problem.  The crash occurs later, when memory allocation takes place.

Some new observations:

Based on @white238's guess, I disabled MPI (and MFEM, which was configured with MPI) from the failing config.  This fixed the failure.  Not exactly sure what the mechanism of failure was.
I tried to construct the UnstructuredMesh without using Sidre.  This also gets past the crash.  This provides a work-around for this bug, but it effectively disables some Sidre-dependent features when using the UnstructuredMesh.

After merging in the latest develop branch, the failed test (quest_initialize) continues to fail.  But if I remove the -DBUILD_SHARED_LIBS=ON from the configuration, the tests pass.  @white238 What do you think of this clue?


In-game notepad

Would it be possible to add a notepad/quick notes to the mod? Like a button that opens a basic text editor/notepad?

Shouldn't be too hard, just need to get a custom popup system in place.


Font style of the description in the autocomplete popup

How can I change a font style of the description in the autocomplete popup?

We do not control that, sublime itself does.


Added missing quotation marks in assertion error messages

This is just a minor change for consistency.  The error messages for the file_equal assertion were missing quotes around the file name.

LGTM

LGTM!


[edge-compute] - Return stack name in edgestack config

related to portainer/agent#125
Should provide the edge stack name to the agent

Closed via #3809


[Feature Request] UBI should be able to accept custom attributes

Is your feature request related to a problem? Please describe
UBI allows queries to have a client-side generated query_id, along with optional user_query, object_id, and client_id values. It would be nice to allow the client to send custom attributes to associate with the query.
Describe the solution you'd like
The client should be able to send custom attributes in the ubi block of ext in search requests. For instance, to send a store_id, the user could send a request:
#!/bin/bash -e

curl http://localhost:9200/ecommerce/_search -H "Content-Type: application/json" -d'
 {
  "ext": {
   "ubi": {
     "query_id": "12300d16cb-b6f1-4012-93ebcc49cac90426",
     "user_query": "toner",
     "object_id": "name,
     "client-id": "01dabe13-3d25-42d2-a8f8-be459df2105d",
     "store_id": "store1"
    }
   },
   "query": {
     "match": {
       "name": "toner"
     }
   }
 }'

Additional context
This relates to UBI which is described in https://github.com/opensearch-project/OpenSearch/issues/12084 and https://github.com/opensearch-project/OpenSearch/issues/13545.
This issue can be assigned to myself.

Closing this RFC because the initial implementation is now available at https://github.com/opensearch-project/user-behavior-insights and new issues can be created there.


Walk towards - mining

Continues walking post mining, somehow?

After discovering this it almost feels like a feature

So it mines and starts walking/executing steps afterwards? I would also call that a feature instead of a bug. It should keep walking until it hits another walk step.


CI builds of /ockam use Nix and Make (ockam-builder is removed)

We should update our Build environments to use Nix infrastructure

[x] Automatic update of Nix Lockfile
[x] Build a replacement of ockam-builder and see how much docker packages we can replace with Nix
[ ] #5942
[ ] Scanning of Nix packages for vulnerabilities

I'll be closing this issue for others which are more descriptive https://github.com/build-trust/ockam/issues/5942


A system that sets the correct properties for the execution context

Sets the Environment field based on an environment variable
Resolves the tenant with a specific strategy. Only the hostname strategy is implemented as of now.
I have not created specs yet, I will wait for the feedback on this before I do so.

Some of the classes here should perhaps be marked with the SingletonPerTenant attribute, I'm not sure.


Error handling when no match is found in device database

When the solution fails to find a matching entry in the device database, it throws a "Failed to recalculate device parameters" exception and returns an invalid cardboard device.  The LG G5 and iPad are both devices which can reproduce this issue.  Expected result should be one of the following:

Return a cardboard device with canPresent capability set to false.
Return a cardboard device with reasonable fallback parameters (~5.1" 16:9 display)
Return no cardboard device.

@zvxryb Were you able to find a workaround for this? I am getting crashes on iPads which prevent the viewer from loading.

Current behavior is that there's a default fallback to a default Android / iOS phone size. Why are you trying to do this on an iPad? It won't work in VR, but should still work in magic window mode. Or are you seeing issues there?

Sorry, yeah I as talking about the magic window mode. However, I can no longer reproduce this for some reason. Please ignore my comment.

OK. Closing.


add DROP-IN-RPM to the title of submodule commits

If a Git commit only contains a change to a submodule, then the title of the downstream commit should be prefixed with DROP-IN-RPM so we can filter it out during rdopkg patch.

There is a "find changed submodules" script here: https://github.com/ceph/ceph-build/blob/master/ceph-pr-submodules/build/build. I'm not sure if that is entirely functional, though - there was a rumor a while back that it was not catching submodule changes. Maybe we could collaborate on a shared Python lib that does this.


"react/no-did-mount-set-state", not considered an valid rule since React 16.3.0

Not valid rule on latest React -release, should be removed.

Can you elaborate?

Sorry for not been to clear. "componentWillMount", "componentWillUpdate", "componentWillReceiveProps" will be deprecated life-cycle methods (React 16.3.0, introduced these and deprecation warnings are scheduled to come with 16.4.0), and replacements for those will be accordingly "componentWillMount" => "componentDidMount", "componentWillUpdate"  => "componentDidUpdate" and "componentWillReceiveProps" => with new introduced "getDerivedStateFromProps".
Therefore it's not relevant to have this rule and existing code bases should be migrated soon enough to match new life-cycles. https://medium.com/@baphemot/whats-new-in-react-16-3-d2c9b7b6193b here's short Medium posting according to changes.

I'm aware of those deprecations, but I'm not sure why it suddenly means that componentDidMount - which is NOT deprecated - would be able to have a setState call in it.

Since componentWillMount will disappear the state change done needs to go somewhere else. For this case, users can almost always use getDerivedStateFromProps to achieve this, but there will be some other cases where users need to call setState in componentDidMount or componentDidUpdate.
From the blogpost:

{...} In general, it is better to avoid cascading updates like this, but in some cases they are necessary (for example, if you need to position a tooltip after measuring the rendered DOM element).

Whole post with more examples and best practices: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html

In my opinion most relevant use cases for this, would be async rendering or if you would like to meddle with refs.
I don't see what is problem having setState in componentDidMount, except if you consider extra render as performance issue.

In general, it is better to avoid cascading updates like this, but in some cases they are necessary (for example, if you need to position a tooltip after measuring the rendered DOM element).

Mmm, it is exactly for this reason that this rule was created in the first place (but was removed from the recommended configuration since there is some legitimate use cases, see https://github.com/yannickcr/eslint-plugin-react/issues/596).

This is also one of the legitimate use case. And saying 'some legitimate' use cases is kind of miss leading.
There are actually plenty of cases where setting state in componentDidMount life-cycle is 'right' way to do the job. Right now if you are doing async component rendering you should do fetches in componentDidMount. There surely might be some change to this when we get asynchronous render-method.
Other case if you want to do some layout changes based on your referenced elements this is also way to go.
And like I have seen in many posts where people have said to do setState in componentWillMount (gladly now deprecated) have been miss understanding and has been no-op for a quiet time now.

Why is this rule not removed? It confused me, but it's perfectly valid for tooltips.

@steida people still use Reacts older than 16.3.

Seems like the actionable thing to do here is, when the React version pragma is >= v16.3, these rules should no-op.

@ljharb, has this no-op behavior been implemented? I'm having trouble with ESLint still complaining about this rule, even if I explicitly set settings.react.version to 16.8 in .eslintrc.json.

No, it hasn't yet.

hi
any update on this?
thanks


[Bug] Python3.8 is not supported by recce

Current Behavior
I'm want to create a devcontainer features with recce. My devcontainer test fails because it's built with all python version allowed.
In https://github.com/DataRecce/recce/blob/main/setup.py#L26C4-L26C31 Python 3.8 is allowed, but recce use zoneinfo.
The zoneinfo module was introduced in Python 3.9
Expected Behavior
Could you update project configuration to remove python 3.8 support ?
Steps To Reproduce
podman run -it --rm --entrypoint /bin/bash docker.io/python:3.8
> pip install pipx
> pipx install recce
> recce version
bash: recce: command not found
root@8b8e390c3181:/# root/.local/bin/recce version
Traceback (most recent call last):
  File "root/.local/bin/recce", line 5, in <module>
    from recce.cli import cli
  File "/root/.local/share/pipx/venvs/recce/lib/python3.8/site-packages/recce/cli.py", line 9, in <module>
    from recce import event
  File "/root/.local/share/pipx/venvs/recce/lib/python3.8/site-packages/recce/event/__init__.py", line 14, in <module>
    from recce.event.collector import Collector
  File "/root/.local/share/pipx/venvs/recce/lib/python3.8/site-packages/recce/event/collector.py", line 9, in <module>
    from zoneinfo import ZoneInfo
ModuleNotFoundError: No module named 'zoneinfo'
``

### Relevant log output

_No response_

### Environment

- recce:
- OS:
- Python:
- Data Warehouse:
- dbt:

### Additional Context

_No response_

Hi @cedric-orange
Thanks for reporting the issue!
We replaced the zoneinfo package with datetime.timezone and removed python 3.8 support since it's EOL.
Please verify if it works for you with the next next release. 🙌🏼


refactor check

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 35 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.01%) to 42.862%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/types/check.go
0
35
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/types/check.go
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
1357

Relevant Lines:
3166

💛  - Coveralls


Semver 2 normalize version

Fixes #22

Puvlished as version 1.3.1 . Thanks for your contribution!

I reverted this version. There were errors with universal packages. I need some time to fix this, or maybe you can take another look


docs: Remove deprecated mixin from klondike tutorial

Description
It just removes a deprecated line that is in the tutorial for building a Klondike game. The final code does not have it and it is no longer necessary to have it in the KlondikeGame class.
Checklist

[x] I have followed the Contributor Guide when preparing my PR.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples or docs.

Breaking Change?
No, just docs.
Migration instructions

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues

No problem, happy to help at least in that regard! Keep up the good work 👌🏼


Please add me to Slack

My email address is<EMAIL_ADDRESS>

Invitation sent.

I'm on slack, txs


KAFKA-4642: Improve test coverage of ProcessorStateManager

Most of the exception paths weren't covered. Now they are.

@enothereska @mjsax @guozhangwang

LGTM

Merged to trunk.


Add Dry::Monads::Unit

Unit is a direct replacement for nil where you care only about type constructor, ignoring the underlying value. For example, I have a few places in my code where I intentionally return Success(nil) as a result, here Success(Unit) reveals intentions better. Besides it, Some(nil) throws an error so you had to use Some(true) or something similar instead. Now Unit can be used in both cases.

I also added RightBiased::Right#discard for mapping successful results to Unit
E.g. here you explicitly don't process a successful result of http request:
x = Try { do_http_request }.discard # => Try::Value(Unit)

@flash-gordon This is great! I've had the same Success(nil) weirdness in a few places myself and have wondered what we could do.


Replace help-blocks

They're deprecated in BS4: https://getbootstrap.com/docs/4.3/migration/#forms-1
find src -type f | xargs grep help-block
src/components/search/Search.jsx:        Sinopia search: use * as wildcard;
src/components/exports/Exports.jsx:
Exports are regenerated weekly. Each zip file contains separate files per record (as JSON-LD).

src/components/load/LoadByRDFForm.jsx:
Accepts Turtle, TriG, N-Triples, N-Quads, and Notation3 (N3).

src/components/load/LoadByRDFForm.jsx:
Omit brackets. If base URI is <>, leave blank.

src/components/load/LoadByRDFForm.jsx:
This will create a new resource that can be saved in Sinopia.

src/components/editor/property/InputLiteral.jsx:      {error && {error}}
src/components/editor/property/InputLookupSinopia.jsx:      Use a * to wildcard your search.
src/components/editor/property/InputLookupSinopia.jsx:      {error && {error}}
src/components/editor/property/InputListLOC.jsx:      {error && {error}}
src/components/editor/property/OutlineHeader.jsx:        { error && {error}}
src/components/editor/property/InputLookupQA.jsx:      {error && {error}}
src/components/editor/property/InputURI.jsx:      {error && {error}}

Note that it is possible we may also need to remove the .has-error class on form elements and decorate those elements with required, but that may require changes to the components that render the form elements, so not undertaking that here.


Investigate lodpdf discrepancy across ilmm and open source naive ilmm

Currently, logpdf does not match to the same atol as all other functionality between these two models, which should be equivalent. This can be recreated and noticed by examining the atol provided for testing in test/illm.jl. Given the oilmm and ilmm are approximate up to atol=1e-9, this might need to be looked in to via the naive ilmm implementation in KernelFunctions.

Did we resolve this the other day @thomasgudjonwright , or is it still a problem?

Closed in #19


Relationships

Relationships are complex. This tracks all of the work that needs to get done.

Cardinality
Representation
Full support

many-to-one
Own table
✓

one-to-many
Host's table

one-to-one (host)
Own table
✓

one-to-one (guest)
Host's table

many-to-many
Associative table

Full Support
"Full support" requires the following features:

Supported in the database
Read one
Read many
Updating a resource with that relationship
Creating with that relationship

A feature is supported when there is an integration test demonstrating that it functions.
Note: For now, I'm going to ignore the behavior of deletes, as that's a 'whole 'nother set of complexities.
To-do's
This is a list of to-do's for each not-fully-supported relationship type:
One-to-many

[x] Supported in the database
[x] Read one
[ ] Read many
[ ] Updating a resource with that relationship
[ ] Creating with that relationship

One-to-one (guest)

[x] Supported in the database
[x] Read one
[ ] Read many
[ ] Updating a resource with that relationship
[ ] Creating with that relationship

Many-to-many

[ ] Supported in the database
[ ] Read one
[ ] Read many
[ ] Updating a resource with that relationship
[ ] Creating with that relationship

The first step to supporting the rest of these features is to clean up the integration tests around relationships. Each type of relationship will have its own migrations directory, so that they won't be interfered with by other things in the kitchen sink directory.


add testcase for #2195 (security delays)

#2195 add delay validation for linkauth/updateauth. add test cases for unlinkauth.

hi I've created another pull request replacing "try" into BOOST_REQUIRE_EXCEPTION. Please would you review it?


The pretained model (trrain on seen classes and test on unseen classes of the same dataset) could not match the result in paper.

I download the pretrained model Trained Model, and evaluate on the cocostuff dataset. The results of Directly using CLIP vision eccoder without tuning are 21.01 mIoU and  26.95 mIoU for seen and unseen respectively. However, the results of paper are 26.8 mIoU and 29.7 mIoU. Are the results reasonable?

I didn't check it carefully buy I think it is due to the stability issue of the learnable prompts. The result in the paper is trained with an old version code and the provided model is re-trained with the reformatted code (As reported by other people, even with the same code, the stability issue still exists. But I haven't found a good solution for the problem.). However, you can find the old model in Drive. By modifying the current code, it should be able to load the old weights. Or you can ask me for the old version code through email.

Hello，I download the pretrained model Trained Model and follow the same Command line, but I got [AssertionError: Non-existent key:  MODEL.WEIGHTST] , please help me.


The backend receives the answer of a player and based on that, the GameJudge calculates the points and updates the game so the next round can be continued.

when saving the answer, game judge is called


⚠ ClamAV has degraded performance

In ccd3b9b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 66 ms

Resolved: ClamAV performance has improved in 845ab2a.


Output tab steals focus from Terminal tab

The output tab will steal focus from the Terminal tab when I edit code in Rust. This interrupts my workflow since I need that to read error messages from the compiler.
thread '<unnamed>' panicked at 'could not create cargo workspace: CargoError(Msg("failed to read `b:\\Programmering\\SandboxOS\\stateful-work\\gen\\rust-copy\\Cargo.toml`"), State { next_error: Some(CargoError(Io(Error { repr: Os { code: 2, message: "The system cannot find the file specified." } }), State { next_error: None, backtrace: None })), backtrace: None })', src\libcore\result.rs:860

I am guessing you are using an extension for Rust which opens the output tab.
Please open the issue in the repo for the rust extension you are using.


Add good listing

This pull request was automatically merged to incorporate new packages into R-multiverse. An automated GitHub actions job will deploy the packages. Thank you for your contribution.


Update windows-iot-core.md

Docs Build status updates of commit 61208e3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/windows-iot-core.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add batch timeout capability to mempool

Candidates: @dnkolegov
Estimate: 1wk

I removed the P0 tag, as this is actually not really critical and purely performance-related. I had initially put it among the P0 tasks, as it was a natural (small) part of implementing the mempool that we needed to work on anyway. The system can, however, work fine without it, just not with optimal performance. The change can be implemented later when there is less time pressure.

Oh, this is outdated, actually, sorry, I forgot to close it. In the end we don't have a batch timeout directly in the mempool, but we achieved the same effect by other means.


Local and global deployer

Q
A

Issue Type
Feature Request

Deployer Version
v4

Local Machine OS
N/A

Remote Machine OS
N/A

Description
If runned global dep inside project with installed local dep via composer, use this local dep.

Done. But need more tests.


Dev.openlayers.org is gone

Hello, I have an integration with OpenLayers working for many years now.
As the API code examples we were using dev.openlayers.org/OpenLayers.js
Now the whole site is gone.
My question is do you plan to reopen that site? Why are the files taken down?
My code no longer works properly, for example some maps (like Google Maps) no longer work.

This site has been down for a long time, and the url you've been accessing points to the built js of an unreleased version of ol2. The built js of the last released version of ol2 is here:

https://openlayers.org/api/2.13.1/OpenLayers.js
https://openlayers.org/api/2.13.1/theme/default/style.css

The code is in this repository. If you want to build the latest unreleased version yourself, follow these steps:
git clone<EMAIL_ADDRESS>cd ol2/build
python2 build.py full

Then you will find OpenLayers.js in the build/ directory, and you can take style.css from the theme/default/ directory.

Strangely enough the site was done a couple of days ago. It's still accessible on Google index which shows my point.
Anyway, I'm using the 2.13.1 API now and I still have the same problem.
Google Maps are not being shown. There is a dropdown radio button where I can select the maps. Only OpenStreet Maps work now. Google Maps layers are all black.
Can you provide any help? Am I missing something? A couple of days ago it was working flawlessly.

I can confirm that I'm seeing an orphaned snapshot of dev.openlayers.org in the Google cache, from a couple of days ago. I was not aware that site was still up, because we told the OSGeo foundation, who was hosting that site, a long time ago that there is nothing on it that is still needed (i.e. no assets that were part of an official OpenLayers API).
Regarding the Google layer: I was able to get the Google layer to show in a local version of the https://github.com/openlayers/ol2/blob/master/examples/google.html example, but greyed out and with a warning.
Here is a build of OpenLayers.js from the latest commit in the default branch:
OpenLayers.js.zip
Maybe you're luckier with that file, because I think it is closer to what you've been using.
Other than that, I can only recommend removing the Google layer, upgrading to a recent version of OpenLayers, or using an alternative mapping library. You can also check out https://www.osgeo.org/service-providers/ to find professional support, if you need help upgrading your application.

Thank you so much for your support. In fact everything was working fine before deletion.
After deletion of the dev site I had to find the OpenLayers.js and theme and "img" folder in order for it to work again.
I've linked it to my site, then it started working.
I've tried with the version you sent me and I still have the same problem with Google Maps (i.e. black map).
I've tried with the example you provided me in my server and still the same.
This is the code I'm using:
    super.writeJSIncludes(out, reqState, new String[] {
        JavaScriptTools.qualifyJSFileRef("http://maps.google.com/maps/api/js?v=3&sensor=false"),
        JavaScriptTools.qualifyJSFileRef("maps/jsmap.js"),
        "https://www.cartrackgps.com/OpenLayers.js",
        JavaScriptTools.qualifyJSFileRef("maps/OpenLayers.js")
    });

Maybe I'm missing some file, as I've seen that there is a "lib" folder. I've uploaded the lib folder but still it doesn't work.
What is strange to me is that before the deletion of the site GoogleMaps worked. Now I cannot seem to make it work.
Thank you very much for your support.

I think I missed something, now it's working perfectly with the file you provided.
I cannot thank you enough and will take you into account for the future sponsorship.

Thanks for the kind words, @pzacheo. Glad to help.

There is a small detail I just found out that on the mobile Apps one cannot drag the map or zoom in/out using gestures. I've been told by another developer that this problem resides on the OpenLayers.js unable to detect touch events. They told me I should request a new version of the file including support for mobile. Sorry to bother you again.

The file I provided is a full build, and it comes with mobile support out of the box. To make the map navigation work on mobile devices, you'd have to set up the html so it does not zoom upon user gestures, like in the official examples. Add this to the <head>:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">

But that should be no different than with the build you previously used.

Thank you for your support again.
On desktop it is working perfectly.
But on mobile (Android App) it's not working as before. So that it won't zoom in or out using gestures, and I cannot drag the map around.
Everything else works, like clicking on the map layers and clicking on the "+" and "-" zoom symbols.
Maybe I'm missing openlayersmobile.js ?

Here you go:
OpenLayers.mobile.js.zip


feat: custom renderer in theme

i should state up front that i'm not sure if this is a desirable change, and i considered opening an issue instead but thought a pr might be easier to start the conversation with. no worries if you'd rather not introduce this change.
we're leveraging wish and bubbletea over @terminaldotshop and i noticed that our huh form colors were slightly off from the rest of our app, despite having configured them with the same lipgloss.Color values. i ended up copying over a bunch of the theme stuff into our repo in order to use the same lipgloss.Renderer and it solved the issue, so i'm bubbling up that change here. i wanted to avoid introducing a breaking change, so went with this approach, but it also looks a little clunky. lmk what you think!

refs https://github.com/charmbracelet/huh/pull/141

Thanks so much for this change! I will add an SSH example to huh to test this out.

Simple SSH form example:
https://github.com/charmbracelet/huh/pull/216

#141 looks like a better (and more conplete) implementation! did the reason for closing it still apply?

Yeah I think we should either go with #141 or #217! I think the team is leaning towards #141

went ahead and closed this, i'll track the other PRs to see what lands!


[Bug]: FetchPlugin does not support server-side rendering

Which web client version did you detect this bug with?
v1.12.0
What environment (build systems, module system, and framework) did you detect this bug with?

NextJS 12.3.4
React 18.2.0
TypeScript 4.9.5
Webpack (unknown version, NextJS internal)

Is your web application a single page application (SPA) or multi page application (MPA)?
SPA
Please provide your web client configuration
N/A
Please describe the bug/issue
When instantiating new AwsRum(), server-side rendering throws an error:
TypeError: Failed to fetch
     at VirtualPageLoadTimer._this.fetch (webpack-internal:///./node_modules/aws-rum-web/dist/es/sessions/VirtualPageLoadTimer.js:57:18)
     at eval (webpack-internal:///./node_modules/aws-rum-web/dist/es/sessions/VirtualPageLoadTimer.js:71:33)
     at FetchPlugin._this.fetch (webpack-internal:///./node_modules/aws-rum-web/dist/es/plugins/event-plugins/FetchPlugin.js:163:18)
     at eval (webpack-internal:///./node_modules/aws-rum-web/dist/es/plugins/event-plugins/FetchPlugin.js:179:33)

It appears to be trying to call window.fetch once instantiated, which of course does not exist.
I would like to instantiate new AwsRum on the server without it actually connecting to emit any metrics, since there is no user in this context -- there should be nothing to emit, as no events have been triggered.

I understand that a server-side rendered page cannot (should not) be connecting to RUM to emit metrics.
My concern is that I do not believe that instantiating AwsRum in and of itself should not be connecting to RUM to emit metrics.

Please advise. 😊

Hi Charles, web clients should not be initialized on a server - is there a specific reason why you wish to do so?

I'm server rendering a React application, so the client side runtime code is also executing on the server.

Hi, does this issue mean that RUM is not supported when server-side rendering is enabled on frameworks such as NextJS? This should be clearly noted, as NextJS is currently the recommended React framework, and is a blocker to teams using server-side rendering. @CharlesStover , did you find a way around this for your use case?

You can use useEffect to instantiate RUM only after your application has loaded on the client, even though this is an anti-pattern per NextJS.
You can use patch-package to patch the RUM package to not call window.fetch on the server.
I forget which path I ended up going.

When initialized, the web client (1) performs steps to get credentials, and (2) emits a session start event. I believe both of these events can be deferred.
Regarding (2), initialize the web client in the disabled state by setting enabled: false in the config. The web client will not dispatch events when disabled.
This setting is currently missing from the docs, which we should fix. The use of this setting is demonstrated in this blog.
Regarding (1), omit the guestRoleArn and identityPoolId from the config. When the application is ready, use the setAwsCredentials command to pass the credential provider.
We may want to do something so that credentials are not fetched when the web client is disabled, in which case the application need only flip the web client from disabled to enabled when it is ready.

Please re-open if this doesn't work or if you have thoughts on a better solution.
Meanwhile, we'll add these to the backlog.

I'll give those a try. As a placeholder, I've seen as a common pattern for SSR+CSR packages to use if (typeof window === 'undefined') to determine if they are rendering on a client or server. This pattern may work for you if you want RUM to no-op on a server render: only call window.fetch if window is defined.

So to clarify, when rendering on a server (i.e., no window object), you expect all calls to the web client to be no-ops?

So to clarify, when rendering on a server (i.e., no window object), you expect all calls to the web client to be no-ops?

Yes, server-rendering serves primarily to generate the initial DOM. Once passed to the client, React will "hydrate," re-executing the render to (1) build the virtual DOM into memory [since the actual DOM is already present] and (2) execute any non-DOM side effects. For example, instantiating RUM and monitoring web vitals does not impact the initial DOM or view, so this behavior does not need to occur during the initial server render. There's no value in having a RUM object in server memory, but once the application re-hydrates on the client, RUM can instantiate in memory and perform browser-based actions like fetching and web vitals.
For a server-side rendered application, the application code is executed once on the server to build the initial DOM and again on the client to hydrate the application into browser memory. By saying "only perform this actions when the window object exists," it will no-op on the server, but it will still execute in the browser during the hydration cycle of the application, as that same JavaScript will re-execute, however now in an environment where window exists.
Thanks for the attention to the issue. 🙂

Agree with @CharlesStover here. Would be great to have a mock/stub implementation of the RUM library.
Not only for SSR purposes but also for testability.
A great example of this mocking ability is Undici:
https://undici.nodejs.org/#/docs/api/MockClient
This greatly simplifies testing, and don't need to monkey patch or use jest.mock.

@moltar If you are using React, my package aws-rum-react comes with a MockAwsRumProvider that you can wrap your test in to mock implementation of the RUM library. It still doesn't support SSR per se, but it can help with unit tests. :)

Core functionality of RUM for SSR website is not working to capture http error.

Upgraded the RUM version from 1.18.0 to 1.19.0
I would like to clarify that the Performance API focuses on performance-related metrics, which don't meet my request. I only want to track HTTP and error metrics. But still, I tried implementing the script you suggested for the Performance API, but unable to catch the 403 error.
I've increased the priority of the cwr.js file, so now it's loaded before the generated JS file. However, we are still experiencing issues with session and not catching HTTP errors.
performance telemetry also not able to capture 4xx and 5XX error


#883 regressed performance by ~7%

https://github.com/swiftlang/swift-format/pull/883 regressed swift-format’s performance by 7-8%. To reproduce run
cd /tmp
git clone https://github.com/apple/swift-syntax.git
cd swift-syntax
git checkout -f 509.0.0

cd path/to/swift-format
swift build -c release
.build/release/swift-format lint --measure-instructions --recursive /tmp/swift-syntax

And compare the instruction count between swift-format with and without https://github.com/swiftlang/swift-format/pull/883.

Synced to Apple’s issue tracker as rdar://141233035

In case anyone was wondering, here is the difference.
Before #883: Instructions executed:<PHONE_NUMBER>1
With #883: Instructions executed:<PHONE_NUMBER>9

Changing the code to:
let lines = text.count { $0 == "\n" }
    lineNumber += lines
    guard lines > 0, let range = text.range(of: "\n", options: .backwards) else {
      // Handle case where no newline exists
      column += text.count
      return
    }
    let lastLine = text[range.upperBound...]
    column = lastLine.count

Lowers the instructions executed to:<PHONE_NUMBER>1

After playing around in Godbolt it seems that lastIndex(of:_) uses a few less instructions per-loop than range(of:_). Changing the code to:
 let lines = text.count { $0 == "\n" }
    lineNumber += lines
    guard lines > 1, let lastNewlineIndex = text.lastIndex(of: "\n") else {
      // Handle case where no newline exists
      column += text.count
      return
    }
    let lastLine = text[text.index(after: lastNewlineIndex)...]
    column = lastLine.count

Further lowers the instruction executed count to:<PHONE_NUMBER>3