[FEAT]: Waitlist API - BACKEND

Description
Create a backend API endpoint to receive and store user information submitted through the waitlist signup form on the website.
Acceptance Criteria

The endpoint should be accessible at /api/waitlist.

The endpoint should accept POST requests to receive user information.

Given a POST request with user data, the system should validate and sanitize the incoming data.

Validation rules should include:

Email format validation.
Required fields: email, name.
The name should be a non-empty string.

Given valid user data, the system should securely store the information in the database.

Upon successful signup, the system should send a confirmation email to the user.

Return a 429 Too Many Requests status with an appropriate error message if the rate limit is exceeded

The system should handle errors gracefully and return appropriate status codes.

Request Body
{
  "email"<EMAIL_ADDRESS>  "full_name": "John Doe"
}

Successful Response (status code: 201)
{
  "message": "You are all signed up!",
}

Error Response
{
  "message": "Invalid email format",
  "status_code": 400,
  "error": "Bad Request"
}

Purpose
To allow potential users to join a waitlist for our product/service by submitting their information through a form on the website.
Requirements

[ ] Develop a RESTful API endpoint to handle POST requests
[ ] Validate and sanitize incoming user data
[ ] Store user information securely in the database
[ ] Implement rate limiting to prevent abuse
[ ] Send a confirmation email to the user upon successful signup
[ ] Handle errors gracefully and return appropriate status codes

Expected Outcome
A secure and efficient API endpoint that can receive user information, store it in the database and confirm the user's addition to the waitlist.
Testing

Test that the endpoint returns a 201 status code with a success message on valid submissions.
Test that invalid data triggers a 400 Bad Request response with an appropriate error message.
Test that a confirmation email is sent upon successful signup.
Test that the rate-limiting works correctly and returns the appropriate status code when exceeded.

are you looking for nest js or python dev for this issue??

are you looking for nest js or python dev for this issue??

We have those already, but I need a Go and C# dev

List (Slack ID) of Team Members  working on this issue

Antholeee
gurumarv
EAZYLINK
Paulson'sLegacy

are you looking for nest js or python dev for this issue??

We have those already, but I need a Go dev

Have you found a go dev, i can join the team

@0xigine


useRangeCalendarState should allow controlling selectionAlignment

🙋 Feature Request
The useRangeCalendarState should allow controlling the selectionAlignment prop of useCalendarState https://github.com/adobe/react-spectrum/blob/dad2cefcbda8e0e73ce55a9c5054bcc1e74b3eb3/packages/%40react-stately/calendar/src/useCalendarState.ts#L50-L51
🤔 Expected Behavior
Allow setting selectionAlignment
😯 Current Behavior
Does not allow setting selectionAlignment, it is automatically calculated from value
https://github.com/adobe/react-spectrum/blob/dad2cefcbda8e0e73ce55a9c5054bcc1e74b3eb3/packages/%40react-stately/calendar/src/useRangeCalendarState.ts#L52-L60
💁 Possible Solution
There should be a selectionAlignment prop and use the prop value if it is set and fallback to the existing value logic if there is no prop value.
Maybe something like these changes to useRangeCalendarState.ts
export interface RangeCalendarStateOptions<T extends DateValue = DateValue> extends RangeCalendarProps<T> {
    /** The locale to display and edit the value according to. */
    locale: string;
    /**
     * A function that creates a [Calendar](../internationalized/date/Calendar.html)
     * object for a given calendar identifier. Such a function may be imported from the
     * `@internationalized/date` package, or manually implemented to include support for
     * only certain calendars.
     */
    createCalendar: (name: string) => Calendar;
    /**
     * The amount of days that will be displayed at once. This affects how pagination works.
     * @default {months: 1}
     */
    visibleDuration?: DateDuration;
+   /** Determines how to align the initial selection relative to the visible date range. */
+   selectionAlignment?: 'start' | 'center' | 'end';
}

  let calendar = useCalendarState({
    ...calendarProps,
    value: value && value.start,
    createCalendar,
    locale,
    visibleDuration,
    minValue: min,
    maxValue: max,
-   selectionAlignment: alignment
+   selectionAlignment: props.selectionAlignment ?? alignment
  });

🔦 Context
I want to show a range calendar with 2 months but the selection should always be aligned at the start, so it should always start on the left/first month.
💻 Examples
Without this fix, sometimes my range selection start is shown on the right month.

I want it always be shown on the left month.

🧢 Your Company/Team

🎁 Tracking Ticket (optional)

This seems reasonable, would need to test the behavior to make sure it doesn't have any unintended side effects.


Which method to override  for async operations? main or start ?

As NSOperation's documentation states, I should override - start for async operations, but in your example it overrided - main, this is confusing.

OK, main it is.

@PrideChung you're right: the main method is to be overriden.
I am not sure if that is still actual to you but here's the rationale behind it:
Both simple and composite operations are based on COAbstractOperation class which contains implementation of state machine (let's call it "proto-" state machine). To handle the general flow of operation that class has the following overrides of start method:
- (void)start {
    if (self.isReady) {
        self.state = COOperationStateExecuting;

        if (self.isCancelled) {
            self.state = COOperationStateFinished;
        } else {
            [self main];
        }
    }
}

So having that in place the only thing you need to do to create your own subclass of COSimpleOperation is to just override its operation body i.e. the main method and to make sure that you have -finishWithResult or rejectWithError: methods at some point.
I hope that makes sense. Do you think that this needs to be clarified in documentation?


Order/Chaos guild notosend problem.

When guilds choose sides, those who choose the order/chaos support direction don't appear orange to each other, the same way chaos/chaos guilds don't appear green to each other. Only members of the same guild appear green and guilds that are at war appear orange.

This should be fixed now with the commit: #1091
You can download Sphere and test it, remember that you need to activate the optionFlag on Sphere.ini.

I think its not fixed, since from what I remember, If you are align Chaos or Order, now you can see neutral players as orange "NOTORIETY" which is enemy, but should be blue - neutral.

This has not been fully corrected. If the guild chooses either order or chaos, neutral guilds also appear orange. Actually Order/Chaos should be direct enemies and Order/Order should see green. Neutral guilds should not be involved in this notosend thing at all if there is no declaration of war. (deepl)

and Order/Order should see green.
I feel like this part would be good to have possibility to switch if green or blue....


extend proxy path matching functions that not exact path matching(before) but path pattern

extend proxy path matching functions that not exact path matching(before) but path pattern matching(after)
- original source from angular-router.js
add gitignore intelj resources

I want to call through some request to proxy server.
because current version is exact matching url request, I send PR for url pattern matching logic.
Plz. check this.


Re-log in the API after a "error":"Not authenticated"

Add new api functions:

is_authenticated
`logout``

Add a relog in send_request if is_authenticated is False fixing issue #86

This implementation in the tahoma_api.py fixed my login issue after updating TaHoma Box to version 2020.3.4-12. Thanks a lot for your effort!


Recognize REUSE Initiative markup in LICENSE files?

Is your feature request related to a problem? Please describe the problem you're trying to solve.
I read that GitHub is using this gem to detect the license of each repository. If I have a LICENSE file in my repo with a verbatim copy of e.g. the BSD-2-Clause license, then it correctly shows up as BSD-2-Clause. However, if I add the following markup at the beginning of that LICENSE file:
Valid-License-Identifier: BSD-2-Clause
License-Text:

<...full text of the BSD-2-Clause license here, as usual...>

then it's detected as an unknown license.
This markup is used by the REUSE Initiative so that their software tools can determine what license is in question. The current situation is that I can have either GitHub or the REUSE tool determine the correct license, but not both at the same time :) The REUSE conventions require the markup in the LICENSE file even for well-known licenses.
Describe the solution you'd like
Would it be possible to add support for the REUSE markup to licensee?
It could simply do a regexp or string match for the markup at the beginning of each LICENSE  file, perhaps after normalizing  whitespace. There ought to be few (if any) variations in how the markup is written. Luckily, the Valid-License-Identifiers they use are the exact same ones as the SPDX-License-Identifiers that licensee is already using.
Describe alternatives you've considered
I'm not using licensee for anything other than convenience, so this is not critical.
Additional context
Here's an example repo of mine

As you say this would be easy to support in licensee. It looks to be used a bit so far, https://github.com/search?p=2&q=Valid-License-Identifier&type=Code obtains 9046 results.
A couple questions:

Is there a spec to go along with the REUSE best practices document? I couldn't find one. I ask in part because some of the results above have additional key-value like entries which would be harder for licensee to support to the extent the values are free-form text. Example: https://github.com/rajanvaja/linux/blob/5c60a7389d795e001c8748b458eb76e3a5b6008c/LICENSES/preferred/MIT
Are Valid-License-Identifier and License-Text (and anything else from above) being discussed for inclusion in the SPDX matching guidelines?

By the way, the most attractive part of supporting Valid-License-Indentifier to me is that it provides a way to indicate -or-later or -only for _GPL licenses in a single LICENSE file, something which I've wished for but didn't know of any push to standardize so left the wish to idle. 😄

Thanks for the great response :) Those are all good questions!

Is there a spec to go along with the REUSE best practices document? I couldn't find one.

Unfortunately, I can find neither a formal spec nor an address to contact the authors of the guidelines. The campaign is promoted by Free Software Foundation Europe but I don't know who to contact in that organization. The command line tool reuse is their main software tool: https://gitlab.com/reuse/reuse. We could try asking the authors of that tool.

I ask in part because some of the results above have additional key-value like entries which would be harder for licensee to support to the extent the values are free-form text. Example: https://github.com/rajanvaja/linux/blob/5c60a7389d795e001c8748b458eb76e3a5b6008c/LICENSES/preferred/MIT

Good catch. As far as I can tell, those seem to be non-standard extensions - those tags are mentioned in neither the reuse tool's source code nor in the guidelines. Maybe this algorithm would work:

If the file starts with the line Valid-License-Identifier: ...
Then skip any following lines that are in Tag: Value format or start with whitespace
Until the tag License-Text: is found. Then stop parsing. Treat everything after that line as the license text.
If Valid-License-Identifier: and License-Text: were not both found, this is not a REUSE compliant license file. Fall back to other approaches.

Are Valid-License-Identifier and License-Text (and anything else from above) being discussed for inclusion in the SPDX matching guidelines?

No idea about this, as I have detailed knowledge of neither SPDX nor REUSE, just a happy user :) SPDX are big on manifest files - I don't know what their stance is on including the full license text in the repo. We should ask some people from those organizations. It seems like they have very compatible goals.
For what it's worth, the reuse compile command auto-generates a manifest in the SPDX format.

By the way, the most attractive part of supporting Valid-License-Indentifier to me is that it provides a way to indicate -or-later or -only for _GPL licenses in a single LICENSE file

Alas, I think that is not possible, or not recommended at any rate. But they have a solution that's even better in my opinion.
I think their idea is to have the comments
# Copyright year author
# SPDX-License-Identifier: license

in each source file, and additionally put the full text of each license in a text file in a standard place. Running reuse lint produces warnings for source files that don't have those comments even if you have a LICENSE file. This is probably a sound design choice, as licensing of individual files is often unclear in projects that have copied code from many other projects. Better to be explicit, and anyway that's only a couple lines of code, so it's not as obtrusive as putting a big license header in each source file.
Another thing is that it's possible to e.g. have some source files under GPL-2.0-only and other files  under GPL-2.0-or-later if those files came from different places. I think the REUSE idea is to store the full text of each license only once, and use SPDX-License-Identifiers in source files to specify the details.
They also suggest a LICENSES directory instead of a LICENSE file for projects with multiple licenses. IMHO that's a super elegant solution to the problem. Here's an example of it: https://gitlab.com/reuse/reuse/tree/master/LICENSES.
The readme for that tool says:

A special note on the GPL: If you use Valid-License-Identifier: GPL-3.0 or name the file LICENSES/GPL-3.0.txt, this will catch all the following licenses: GPL-3.0, GPL-3.0+, GPL-3.0-only and GPL-3.0-or-later. This applies to the entire GPL family of licenses.

And indeed, they have a GPL-3.0.txt in their LICENSES directory and the source files say SPDX-License-Identifier: GPL-3.0-or-later.

As you say this would be easy to support in licensee. It looks to be used a bit so far, https://github.com/search?p=2&q=Valid-License-Identifier&type=Code obtains 9046 results.

Awesome to hear that it's catching on :) I didn't think of doing a search :D

There ought to be few (if any) variations in how the markup is written.

Also, this should be another lesson to me to never say things like this again :D

According to https://reuse.software/practices/2.0/ is is possible to have Valid-License-Identifier: GPL-2.0+ in a LICENSE file. They obviously haven't updated the guide since -or-later became preferred to +.
SPDX is several things, the ones I have in mind here are the https://spdx.org/spdx-license-list/matching-guidelines which work together with the license file templates in https://github.com/spdx/license-list-XML/ which together specify what for any particular license text is mandatory, optional, etc. It seems to me any annotation scheme that wishes to be widely supported in LICENSE files really ought to be driven through the SPDX matching guidelines which various license detection tools implement to varying degrees.
I'll leave this open to gather more info for now since I'm not likely to work on it soon! 😬

OK, you're right, I missed this right in the REUSE practices:

The license identifier may be repeated if the same license file is used with multiple license identifiers. The example below is for GPL-2.0 and GPL-2.0+, but please note that it is not mandatory to list GPL-2.0+ separately.
Valid-License-Identifier: GPL-2.0
Valid-License-Identifier: GPL-2.0+

Also:

In the unlikely event your source code includes exceptions, such as the Classpath exception 2.0, you may include them in the same place as your licenses, using the same header style or the tags SPDX-Exception-Identifier and Exception-Text instead. This is an example of a valid exception:
SPDX-Exception-Identifier: Classpath-exception-2.0
Exception-Text:

Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole combination.

Not sure what in the same place means here - I think it means the LICENSES directory, not same license file. So although the files in the LICENSES directory are usually named according to the SPDX license identifier, they can presumably have other names if they contain Valid-License-Identifier or SPDX-Exception-Identifier tags.

It seems to me any annotation scheme that wishes to be widely supported in LICENSE files really ought to be driven through the SPDX matching guidelines which various license detection tools implement to varying degrees.

That sounds like a good idea! I wasn't aware that the SPDX matching guidelines go into such detail.

:(


Merge knife-windows into chef

Ship the knife-windows plugin directly in Chef.
Signed-off-by: Tim Smith<EMAIL_ADDRESS>

@tas50 rebase this PR with the current master also updated the ui.ask as per https://github.com/chef/chef/pull/10131

Closing this so we can do it the correct way post #9354


Turso migration

Description (required)

Add a "migrate to turso" recipe for Astro Studio users

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/astro-db.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Compute grading status on frontend

Description
Compute grading status on frontend to match backend changes.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Code quality improvements

How to test
Look at the grading status and assessments pages.
Checklist

[x] I have tested this code
[ ] I have updated the documentation

Pull Request Test Coverage Report for Build 5426

1 of 6 (16.67%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.06%) to 33.985%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/commons/sagas/RequestsSaga.ts
1
6
16.67%

Files with Coverage Reduction
New Missed Lines
%

src/commons/sagas/RequestsSaga.ts
2
7.49%

Totals

Change from base Build 5420:
-0.06%

Covered Lines:
1699

Relevant Lines:
4627

💛  - Coveralls


eyeball (collection) might be compromised by proxy

This seems to be critical where info.sender is set provided by proxy: https://github.com/public-awesome/ics721/blob/main/contracts/cw-ics721-bridge/src/contract.rs#L110
fn execute_receive_proxy_nft( ... ) -> Result<Response, ContractError> {
    if PROXY
        .load(deps.storage)?
        .map_or(true, |proxy| info.sender != proxy)
    {
        return Err(ContractError::Unauthorized {});
    }
    let mut info = info;
    info.sender = deps.api.addr_validate(&eyeball)?;
    let cw721::Cw721ReceiveMsg {
        token_id,
        sender,
        msg,
    } = msg;
    receive_nft(deps, info, TokenId::new(token_id), sender, msg)
}

So it would be possible having an exploited proxy contract and providing any random collection which will then be transferred to another chain.
One solution is checking, whether sender is owner of NFT by querying all_nft_info, instead of nft_info here:
https://github.com/public-awesome/ics721/blob/main/contracts/cw-ics721-bridge/src/contract.rs#L173

This issue has now been resolved by creating a new proxy package here:
https://github.com/arkprotocol/ics721-plus


Update neat to v2.1.0 and bourbon to v4.3.4

Latest versions of each library.
Fixes #9

I haven't tested this locally

Ok, this is working for me locally. This will need to be a minor or even major release for the addon since it will significantly break existing code for users because of the syntax changes in the neat framework.


Feature - Add second parameter for range method calls

Description
This PR adds a second parameter to both rangeForOrders and rangeForFills helpers on the Order/Fill models respectively. These changes allow those methods to performance ranges that are outside of a single block order
This PR is related to the performance changes included in https://github.com/sparkswap/broker/pull/527
Related PRs
List related PRs if applicable
Todos

[ ] Tests
[ ] Documentation
[ ] Link to Trello

@dannypaz Just noticed you changed the docs in #527, so no need to change them in this PR.


docker login how to?

under: Log in to a registry

You can also log in with docker login.

which implies to me this is optional but then all the subsequent steps use docker so it seems required, no?
How to improve docs
Assuming that is the case, how do I make docker login work?  Seems like this guide might help: Azure Container Registry authentication with service principals -> Create a service principal.
It would be handy for this page to provide a link on how to accomplish a docker login IMHO

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

ID: 22dc1f78-5ef2-391c-732f-740c0ca12880
Version Independent ID: ffad8c17-c1e6-fb99-3a39-98be4d6ed091
Content: Push & pull container image - Azure Container Registry
Content Source: articles/container-registry/container-registry-get-started-docker-cli.md
Service: container-registry
GitHub Login: @tejaswikolli-web
Microsoft Alias: tejaswikolli

@spottedmahn
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@tejaswikolli-web
Can you please check and add your comments on this doc update request as applicable.

made changes to the doc. https://github.com/MicrosoftDocs/azure-docs-pr/pull/201918

#please-close


cant install on manjaro with pamac or pip

Attempting to install 0.14.0-1 with pamac
and 0.14.0 with pip.

error log

Preparing...
Cloning pywlroots build files...
Checking pywlroots dependencies...
Resolving dependencies...
Checking inter-conflicts...
Building pywlroots...
==> Making package: pywlroots 0.14.0-1 (Tue 06 Jul 2021 04:22:33 PM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found v0.14.0.tar.gz
==> Validating source files with sha256sums...
v0.14.0.tar.gz ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Extracting v0.14.0.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
running build
running build_py
creating build
creating build/lib.linux-x86_64-3.9
creating build/lib.linux-x86_64-3.9/wlroots
copying wlroots/ffi_build.py -> build/lib.linux-x86_64-3.9/wlroots
copying wlroots/backend.py -> build/lib.linux-x86_64-3.9/wlroots
copying wlroots/renderer.py -> build/lib.linux-x86_64-3.9/wlroots
copying wlroots/init.py -> build/lib.linux-x86_64-3.9/wlroots
copying wlroots/helper.py -> build/lib.linux-x86_64-3.9/wlroots
creating build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/xdg_shell.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/xdg_decoration_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/xdg_output_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/matrix.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/data_control_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/output_damage.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/cursor.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/screencopy_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/data_device_manager.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/server_decoration.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/output_layout.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/xcursor_manager.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/box.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/virtual_keyboard_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/gamma_control_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/pointer.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/compositor.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/texture.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/input_device.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/seat.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/output_management_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/surface.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/keyboard.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/output.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/init.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/layer_shell_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
copying wlroots/wlr_types/primary_selection_v1.py -> build/lib.linux-x86_64-3.9/wlroots/wlr_types
creating build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/util/clock.py -> build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/util/region.py -> build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/util/edges.py -> build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/util/init.py -> build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/util/log.py -> build/lib.linux-x86_64-3.9/wlroots/util
copying wlroots/py.typed -> build/lib.linux-x86_64-3.9/wlroots
running build_ext
generating cffi module 'build/temp.linux-x86_64-3.9/wlroots._ffi.c'
creating build/temp.linux-x86_64-3.9
building 'wlroots._ffi' extension
creating build/temp.linux-x86_64-3.9/build
creating build/temp.linux-x86_64-3.9/build/temp.linux-x86_64-3.9
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fno-semantic-interposition -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIC -DWLR_USE_UNSTABLE -I/usr/include/pixman-1 -I/var/tmp/pamac-build-yobleck/pywlroots/src/pywlroots-0.14.0/include -I/usr/include/python3.9 -c build/temp.linux-x86_64-3.9/wlroots._ffi.c -o build/temp.linux-x86_64-3.9/build/temp.linux-x86_64-3.9/wlroots._ffi.o
build/temp.linux-x86_64-3.9/wlroots._ffi.c: In function ‘_cffi_checkfld_struct_wlr_surface’:
build/temp.linux-x86_64-3.9/wlroots._ffi.c:12155:31: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_below’; did you mean ‘subsurfaces’?
12155 |   { struct wl_list *tmp = &p->subsurfaces_below; (void)tmp; }
|                               ^~~~~~~~~~~~~~~~~
|                               subsurfaces
build/temp.linux-x86_64-3.9/wlroots._ffi.c:12156:31: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_above’; did you mean ‘subsurfaces’?
12156 |   { struct wl_list *tmp = &p->subsurfaces_above; (void)tmp; }
|                               ^~~~~~~~~~~~~~~~~
|                               subsurfaces
build/temp.linux-x86_64-3.9/wlroots._ffi.c:12157:31: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_below’; did you mean ‘subsurface_pending_list’?
12157 |   { struct wl_list *tmp = &p->subsurfaces_pending_below; (void)tmp; }
|                               ^~~~~~~~~~~~~~~~~~~~~~~~~
|                               subsurface_pending_list
build/temp.linux-x86_64-3.9/wlroots._ffi.c:12158:31: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_above’; did you mean ‘subsurface_pending_list’?
12158 |   { struct wl_list *tmp = &p->subsurfaces_pending_above; (void)tmp; }
|                               ^~~~~~~~~~~~~~~~~~~~~~~~~
|                               subsurface_pending_list
In file included from build/temp.linux-x86_64-3.9/wlroots._ffi.c:61:
build/temp.linux-x86_64-3.9/wlroots._ffi.c: At top level:
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13844:55: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_below’; did you mean ‘subsurfaces’?
13844 |   { "subsurfaces_below", offsetof(struct wlr_surface, subsurfaces_below),
|                                                       ^~~~~~~~~~~~~~~~~
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13845:60: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_below’; did you mean ‘subsurfaces’?
13845 |                          sizeof(((struct wlr_surface *)0)->subsurfaces_below),
|                                                            ^~~~~~~~~~~~~~~~~
|                                                            subsurfaces
In file included from build/temp.linux-x86_64-3.9/wlroots._ffi.c:61:
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13847:55: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_above’; did you mean ‘subsurfaces’?
13847 |   { "subsurfaces_above", offsetof(struct wlr_surface, subsurfaces_above),
|                                                       ^~~~~~~~~~~~~~~~~
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13848:60: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_above’; did you mean ‘subsurfaces’?
13848 |                          sizeof(((struct wlr_surface *)0)->subsurfaces_above),
|                                                            ^~~~~~~~~~~~~~~~~
|                                                            subsurfaces
In file included from build/temp.linux-x86_64-3.9/wlroots._ffi.c:61:
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13850:63: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_below’; did you mean ‘subsurface_pending_list’?
13850 |   { "subsurfaces_pending_below", offsetof(struct wlr_surface, subsurfaces_pending_below),
|                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13851:68: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_below’; did you mean ‘subsurface_pending_list’?
13851 |                                  sizeof(((struct wlr_surface *)0)->subsurfaces_pending_below),
|                                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~
|                                                                    subsurface_pending_list
In file included from build/temp.linux-x86_64-3.9/wlroots._ffi.c:61:
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13853:63: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_above’; did you mean ‘subsurface_pending_list’?
13853 |   { "subsurfaces_pending_above", offsetof(struct wlr_surface, subsurfaces_pending_above),
|                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~
build/temp.linux-x86_64-3.9/wlroots._ffi.c:13854:68: error: ‘struct wlr_surface’ has no member named ‘subsurfaces_pending_above’; did you mean ‘subsurface_pending_list’?
13854 |                                  sizeof(((struct wlr_surface *)0)->subsurfaces_pending_above),
|                                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~
|                                                                    subsurface_pending_list
error: command '/sbin/gcc' failed with exit code 1
==> ERROR: A failure occurred in build().
Aborting...

All dependencies are installed and up to date:
python-setuptools-scm              5.0.2-1                     community  124.4 kB
wlroots                            0.13.0-1                    community  993.3 kB
python-xkbcommon                   0.3-1                       AUR        194.0 kB
pywayland                          0.4.4-1                     AUR        1.9 MB
python-cffi                        1.14.5-1                    extra      1.1 MB
inxi -S output:
Kernel: 5.10.42-1-MANJARO x86_64 Desktop: Qtile 0.17.0 Distro: Manjaro Linux

Hi @yobleck! Thanks for the report. The versioning of pywlroots is setup to match the version of wlroots in major/minor versions. So, for wlroots 0.13.0, you would need one of the pywlroots versions 0.13.x. Looking at the traceback, that is not obvious. I think we can make the error message more clear so this is clear.
Do you have a link to the package in manjaro? I would report downstream that the dependencies of the pywlroots should be set based on the wlroots version.

arch user repo website: https://aur.archlinux.org/packages/pywlroots
It says the maintainer is @m-col so I suppose they'll get around to it if they see this and when it's convenient for them (no rush)
In the mean time I successfully installed version 0.13.5 via pip. Also the AUR says the current version of wlroots is 0.14 so I think I just need to force an update or something.
Thanks for the help :)

Hey @yobleck, thanks for bringing it up. I've set the pywlroots AUR version to be the latest release, but I guess instead it could/should match the wlroots version from the official repos in case they are not up to date themselves with the latest wlroots release.
However, looking at the official package for wlroots - https://archlinux.org/packages/community/x86_64/wlroots/ - they are at 0.14.0 so perhaps you need to update that and then re-install.

Thanks for checking @m-col!
I added a new pair of releases, 0.13.6 and 0.14.1, which add wlroots version checks on install, and should help users in figuring this out on their own.


Clarification and Details Needed on Project Architecture

I came across a post in the System Software 2024 Facebook group discussing this project, but there are several aspects that require further clarification and details:

Linux Char Device Driver Location: The post mentions that this project includes a Linux character device driver. Could you please specify where exactly in the repository the driver code would be located?

User Space-Kernel Space API Design: What is the current design of the API that facilitates communication between the user space and kernel space? It would be helpful to have a detailed explanation or documentation about this.

Embedding Machine Learning Model in Kernel: The post also indicates that a machine-learning model is embedded into the kernel. Could you provide guidance or existing design principles that have been followed for embedding such a model? Additionally, it would be beneficial to understand the expected behavior and limitations of this integration.

Understanding these elements is crucial for comprehensively grasping the architecture of this project. Any detailed information or documentation regarding these aspects would be greatly appreciated.

I understand that the third issue might be more relevant for a future roadmap. However, we could discuss its scope now to better define our plans going forward.

Did you review the repository's descriptions? They are not connected to a Linux kernel module, but rather pertain to a userspace program.


Fix issue with wildcard with supported extensions when plugins add external files and override getScriptKind to add script kinds for the additional extensions

When file is added to directory watched for wild cards, we check if the file is of supported extension. Here we dont want to match against include pattern because in most cases it doesnt include extension and we would re-evaluate root file names too many times if we did that. But with this if plugin adds extra file extension support (eg vue plugin) we ignore those files. This adds additional check to see if the script kind for the file is supported.
Fixes https://github.com/microsoft/TypeScript/issues/55525

Thanks for this fix! I think there is a very specific edge case, when the TS plugin proxy getScriptKind may cause this line to crash.
https://github.com/microsoft/TypeScript/blob/61a96b1641abe24c4adc3633eb936df89eb991f2/src/server/project.ts#L1516
Here are the conditions to reproduce:

Clone https://github.com/withastro/astro then execute pnpm install
Install the Astro extension in VSCode
Open https://github.com/withastro/astro/blob/main/packages/astro/client.d.ts
Execute the Organize Imports command, then VSCode reports: <semantic> TypeScript Server Error (5.3.0-beta) Debug Failure. False expression. Error: Debug Failure. False expression. at InferredProject2.updateGraphWorker (tsserver.log)

If you need me to open an issue, please let me know!

This looks like issue with one of the plugin in your chain where LanguageService used program, that was not updated through Project and hence the state of project is out of sync with LS


Fix flux_led only-white controllers (and remove explicit declaration as RGBW in automatic add)

Description:
When using only-white Magic Home controllers, the update routine didn't work properly. Now only-white controllers are treated as before my update for RGBW controllers.
Old description:
When flux_led devices are found with automatic discovery, they are automatically seen as RGBW devices, even when they are actually RGB devices, This pull request fixes this issue.
Issue #22161 will be completely fixed in the next pull request, because it needs an update to the flux_led module as well
Related issue (if applicable): fixes #22405
Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

@amelchio this pull request shall remove the bug from #22405 and my previous pull request

Great. I can review after the weekend. Meanwhile, is this tested with affected devices?

The problem is that I don't have a only-white controller, so I can't test it. The behaviour for other types has not changed.

I will test the stuff in the evening at home.

So, I have now tested the changes, they are fully working for RGBW devices (now waiting time is reduced to 1 second as well, this is enough)

Actually, can we just remove the bit that I moved since the same code seems to be present a bit further down in update()?

@autinerd I think that when @amelchio said "we", he meant that it's a change you should make to get this PR approved.

Oh yeah, thank you, I was just a bit confused. Thank you very much and hopefully there are no more problems with the logic of this component!

So since a few flux updates ago, my RGBW Led Strip has started 'toggling' between RGB and W. This problem was introduced several months ago but fixed. I was hoping that it would get fixed with this PR but sadly not.
Essentially it can't light all 4 channels at once - turning on the W turns off the RGB and vice versa.

I think it makes sense to turn off RGB when setting W and vice-versa. However, if setting both, we should allow that. I think there is an inconclusive architecture issue about this behavior :-/
Anyway, please file a new GitHub issue about this since we should not be discussing in closed tickets.


INT-2245 Jdbc Outbound Gateways - Change "request-timeout" to "reply-timeout"

For reference see: https://jira.springsource.org/browse/INT-2245

LGTM. I'll merge.


Allow user to specify path to Python

I just tried the 0.1 release. I have Python installed using Anaconda, but my default conda env doesn't have Jupyter in it. I have a separate named conda env I would like to run JupyterLab on. Right now in the app, if a python+jupyter can't be found, the user sees a screen that refers them to the jupyter docs. I think this screen should minimally allow them to enter a path to a python.

Could we even go so far as to automatically detect and list available environments?
The 'Jupyter not Installed' page needs to be improved in general. I implemented it pretty quickly before the release just so there was some user feedback. We could make the page pretty smart/intuitive. I think I'm going to make it my primary task for next week.

I think this can go in phases - let's start with allowing the user to
simply type a location, and later move to more automated approaches.
On Fri, Aug 4, 2017 at 5:43 PM, Luc Bouchard<EMAIL_ADDRESS>wrote:

Could we even go so far as to automatically detect and list available
environments?
The 'Jupyter not Installed' page needs to be improved in general. I
implemented it pretty quickly before the release just so there was some
user feedback. We could make the page pretty smart/intuitive. I think I'm
going to make it my primary task for next week.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyterlab/jupyterlab_app/issues/106#issuecomment-320380480,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0Ca0-yPJHOGLnFZxKvEcxGj7j4qHks5sU7qigaJpZM4OuTuT
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

nteract reimplemented jupyter paths in node, while also providing a way to fall back to asking jupyter directly. Beyond that, we do handle the sys-prefix lookup using https://github.com/rgbkrk/sys-prefix-promise.
I'm guessing since you're taking the approach of launching the server you likely won't go that route.

If you are building a list of available pythons/envs, you should also check PEP 514 for Windows: https://www.python.org/dev/peps/pep-0514/

Fixed in #115


SimplenoteOpen does not evaluate input

With the new Simplenote update it is now possible to use internal links. To make use of that feature, I tried to build a custom command that yanks the id in the link, and then calls SimplenoteOpen @". However (adding a print inside the python function) I discovered that the @" is used verbatim, even if vim.eval() is called on the function argument.
Is there any way to do something like that? I have no experience in developing vim plugins, but if you can give me some pointers I am available to try and implement this functionality myself and open a pull request. Thank you for your time.

Update: I managed to cobble up this function that goes to the next Simplenote internal link, yanks the note id, and opens the note in a new split, restoring the previous content of the yank buffer.
I added it to my simplenote.vim file and it seems to work fine. I'll open a pull request.
		function! SimplenoteGoFun() 			let temp = @" 			norm /simplenote://t)yiw 			let noteid = @" 			let @"=temp 			echo noteid 			call simplenote#SimplenoteOpen(noteid) 		endfunction 		command! -nargs=0 SimplenoteGo :call SimplenoteGoFun()

I'm closing this on on the basis that https://github.com/simplenote-vim/simplenote.vim/pull/113 has been merged in. If I'm missing something else though please re-open.


LogicalPlan for unifying flattening incorrect

In the query select loc[*] from zips where loc[*] > 68 we should unify the loc[*] so that we align the flattened results according to their shared provenance. The current LogicalPlan does not express this and  wraps one FlattenArray around the other instead of performing the operation on separate branches.
Rewritten Joins:
Let('__tmp0)
├─ Let('__tmp1)
│  ├─ Read(/spark/zips)
│  ╰─ Typecheck(Obj(Map[], Some(Top)))
│     ├─ Free('__tmp1)
│     ├─ Free('__tmp1)
│     ╰─ Constant(NA)
╰─ Invoke(Take)
   ├─ Invoke(Squash)
   │  ╰─ Invoke(FlattenArray)
   │     ╰─ Let('__tmp2)
   │        ├─ Invoke(ObjectProject)
   │        │  ├─ Invoke(Filter)
   │        │  │  ├─ Free('__tmp0)
   │        │  │  ╰─ Invoke(Gt)
   │        │  │     ├─ Invoke(FlattenArray)
   │        │  │     │  ╰─ Let('__tmp3)
   │        │  │     │     ├─ ObjectProject(Free('__tmp0){"loc"})
   │        │  │     │     ╰─ Typecheck(FlexArr(0, None, Int, Dec, Interval, Str, Timestamp, Date, Time, or Bool))
   │        │  │     │        ├─ Free('__tmp3)
   │        │  │     │        ├─ Free('__tmp3)
   │        │  │     │        ╰─ Constant(Arr(List(NA)))
   │        │  │     ╰─ Constant(Int(68))
   │        │  ╰─ Str("loc")
   │        ╰─ Typecheck(FlexArr(0, None, Top))
   │           ├─ Free('__tmp2)
   │           ├─ Free('__tmp2)
   │           ╰─ Constant(Arr(List(NA)))
   ╰─ Constant(Int(101))

As such this returns results that look like
 value        |
--------------|
  -151.679005 |
     68.11878 |
  -145.423115 |
    68.077395 |
  -156.817409 |
    71.234637 |
  -148.559636 |
    70.070057 |
...

when the correct results look like
 value      |
------------|
   68.11878 |
  68.077395 |
  71.234637 |
  70.070057 |
...

QScript compilation works as expected, given the LogicalPlan. Though after we fix the LogicalPlan, we'd like the QScript to look approximately like:
Map(
  Filter(
    LeftShift(
      ShiftedRead("zips", ExcludeId),
      ProjectField(Hole, "loc"),
      ConcatArrays(
        MakeArray(LeftSide),
        MakeArray(RightSide)))
    Gt(ProjectIndex(Hole, 1), 68)),
  ProjectIndex(Hole, 0))

We should also note that this query returns the correct results in old mongo because old mongo is making assumptions about the intention of the query that aren't in any way expressed in the LogicalPlan.
When this is fixed, we should be able to enable unifyFlattenedFieldsWithMultipleUses.test.

Looking at this again, I don't see anything incorrect about the logical plan. To fix this we need to modify the qscript to unify the two instances of flattening [*] across the Filter.


⚠ Fortnite has degraded performance

In 7087b6c, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1618 ms

Resolved: Fortnite performance has improved in 2351a48.


Projection isn't found in tx cache;

let's imagine Entity(id, value) with projection ValueIndex(id_value, entity_id). If we save in tx some entity and after it try to find projections - they will be unchanged
For example: this test is green
    @Test
    public void savedIndexIsNotInCache() {
        Book.Id bookId = new Book.Id("1");

        Book.ByAuthor index1 = db.tx(() -> {
            db.table(Book.class).save(new Book(bookId, 1, "title1", List.of("author1")));
            return db.table(Book.ByAuthor.class).find(new Book.ByAuthor.Id("author1", bookId));
        });

        Book.ByAuthor index2 = db.tx(() -> {
            return db.table(Book.ByAuthor.class).find(new Book.ByAuthor.Id("author1", bookId));
        });

        assertNull(index1);
        assertNotNull(index2);
    }

Does db.table(Book.class).saveOrUpdate(...) work?
Table.save() is marked "unsafe" because it does not work well with projections

No, it doesn't. Because we make actions with projections only in RwProjectionCache::applyProjectionChanges which calls on commit.
Overall projections is useful feature, but unsafe in current design. It looks impossible to remove it from current projects which are using YOJ. Anyway GlobalIndex can't close all case of projections. For example GlobalIndex can't be computable.


Add NullString tests and fix various adapters

Probably the various database-specific implementations of CLOB datatypes are incomplete.

Issue resolved in https://github.com/rbastic/dyndao/commit/25173a43846c15484abe144cd3b505429fea1781


Question About Training

Hi, when I train the code in hc-stvg, where the resolution is 448. and is trained in 32 gpus. But I find my cuda allways is out of memory. My config yaml follows yours. Can you answer the question? Thank you.

You can reduce the input resolution, e.g, res=416 or 384