Window Resize and Initializing Slidebars

Hey,
I'm trying to implement  Slidebars on devices with a width of 992 or lower.
Im using enquire.js to handle my media queries and I'm having after getting the first initial trigger from the media query.
I use $.slidebars.close(); to make sure the left-side closes when the user switches from lets say portrait to landscape.
However, if you resize the window again afterwards, either bigger or smaller by even 1px it bring slidebars back and adds all the classes (.sb-active-left, .sb-init, etc..) back to the html tag.
Note: This resize i'm talking about has to with physically resizing a desktop browser.
leftActive gets correctly set to false when i use $.slidebars.close(); but then upon the resize it returns true and brings back slidebars.
What would be the best way to achieve having slidebars active only at a certain breakpoints?
Thanks.

Hi, is this still the way to disable slidebars on desktop?

@hartey11 Nope, see: https://www.adchsm.com/slidebars/help/advanced-usage/disabling-slidebars/

Hey @JoryHogeveen I've tried this but I keep getting "Uncaught Slidebars hasn't been initialized" When resizing the browser. Any idea how to stop this?
Looks like it might be related to this issue.
https://github.com/adchsm/Slidebars/issues/274

Can you share your code on how you have set up Slidebars?

Sure:
`
function breakpoint() {
const tablet_small = window.matchMedia('(min-width: 37.5rem)'),
tablet_medium = window.matchMedia('(min-width: 50rem)'),
desktop = window.matchMedia('(min-width: 64.0625rem)');
if (!desktop.matches && !tablet_medium.matches && !tablet_small.matches) {
return 'mobile';
} else if (!desktop.matches && !tablet_medium.matches) {
return 'tablet-small';
} else if (!desktop.matches) {
return 'tablet-medium';
} else {
return 'desktop';
}
}
const controller = new slidebars();
// Enable/Disable Slidebars
const enableSlidebars = function () {
  if ($.inArray(breakpoint(), ['mobile', 'tablet-small', 'tablet-medium']) > -1 && !controller.isActive()) {
    controller.init(function () {
      console.log('Slidebars has been enabled.');
    });
  } else if ($.inArray(breakpoint(), ['desktop']) > -1 && controller.isActive()) {
    controller.exit(function () {
      console.log('Slidebars has been disabled.');
    });
  }
};`

Looks fine to me. You are still getting errors with this code I even though you are using isActive()?

Yeah. here's a link to the site. When you resize page the breakpoint at 1025px you get the error
https://seerene.harte.onine

Hi @hartey11 The link isnt working for me. DNS_PROBE_FINISHED_NXDOMAIN


[C++][Parquet] parquet::arrow::FileWriter::Close is not idempotent

Encountered a segfault when calling multiple times from Python
Reporter: Wes McKinney / @wesm
Assignee: Antoine Pitrou](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=apitrou) / @pitrou
PRs and other links:

GitHub Pull Request #449

Note: This issue was originally created as PARQUET-1071. Please see the migration documentation for further details.

Antoine Pitrou / @pitrou:
Adding an idempotence test doesn't seem to break things here.

Uwe Korn / @xhochy:
Issue resolved by pull request 449
https://github.com/apache/parquet-cpp/pull/449

Wes McKinney / @wesm:
I might be wrong about this, I will look more closely


replace wchar_t/L"..." with char16/_u("...")

Replace wchar_t/L"..." with char16/_u("...") in all sources (except public
JSRT APIs. Will revisit later.)

I took a sampling of the changed files.  Looks great

Reviewed 48 of 443 files at r1.
Review status: 48 of 443 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

lib/Runtime/Library/UriHelper.cpp, line 147 [r1] (raw file):
This is silly, but harmless.

Comments from the review on Reviewable.io

I looked at a few files and it looks good. I assume this was more or less a find-and-replace operation and since it compiles, I'd say LGTM

Thanks guys! Will merge this.


Obsolete term: asymptomatic dengue MONDO:0000259

I'm trying to trace why the term "asymptomatic dengue" (MONDO:0000259) was obsoleted, and when. We mapped some data in the Human Cell Atlas to it and discovered yesterday that our validation against the term is now failing, so are trying to update to a better mapping but there is no information on why the term was obsoleted and what it's been replaced with.

Apologies for this. We should have a general principle regarding
asymptomic diseases - are these really diseases?
Nicole, can you reinstate the class?
Now that we are past our initial phase and the MONDO has settled into a
stable state we should have a standard announce policy prior to
obsoletion.
On 20 Sep 2018, at 3:51, daniwelter wrote:

I'm trying to trace why the term "asymptomatic dengue" (MONDO:0000259)
was obsoleted, and when. We mapped some data in the Human Cell Atlas
to it and discovered yesterday that our validation against the term is
now failing, so are trying to update to a better mapping but there is
no information on why the term was obsoleted and what it's been
replaced with.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/monarch-initiative/mondo/issues/346

yes, will do!


Unable to install (compile) on AMD 64

Trying to install homeassistant 2024.2.x, pip3.12 module is not able to complete the installation while it compiles (since wheel package for python 3.12 is not present).
Very long error log, here tail part:
.....
/tmp/pip-install-6v52qols/webrtc-noise-gain_387db575794d4cecba1b3abb22efa28c/webrtc-audio-processing/webrtc-audio-processing-1/modules/audio_processing/agc2/adaptive_mode_level_estimator.cc:45:1: error: control reaches end of non-void function [-Werror=return-type]
45 | }
| ^
cc1plus: some warnings being treated as errors
Traceback (most recent call last):
File "/tmp/pip-build-env-yegcho52/overlay/lib/python3.12/site-packages/setuptools/_distutils/unixccompiler.py", line 185, in _compile
self.spawn(compiler_so + cc_args + [src, '-o', obj] + extra_postargs)
File "/tmp/pip-build-env-yegcho52/overlay/lib/python3.12/site-packages/setuptools/_distutils/ccompiler.py", line 1041, in spawn
spawn(cmd, dry_run=self.dry_run, **kwargs)
File "/tmp/pip-build-env-yegcho52/overlay/lib/python3.12/site-packages/setuptools/_distutils/spawn.py", line 70, in spawn
raise DistutilsExecError(
setuptools._distutils.errors.DistutilsExecError: command '/usr/bin/gcc' failed with exit code 1

Workaround: add ["-w"] to extra_compile_args in setup.py

Workaround with the additional compiler parameter "-w" also worked for me on Opensuse Tumbleweed on intel N100
some more steps to make it easier for other users

download the package
pip download webrtc-noise-gain
unpack
tar -xvzf webrtc_noise_gain-1.2.3.tar.gz
enter folder
cd webrtc_noise_gain-1.2.3
open setup.py and add the parameter "-w" to the common_cflags section
common_cflags = [
"-DWEBRTC_LIBRARY_IMPL",
"-DWEBRTC_ENABLE_SYMBOL_EXPORT",
"-DNDEBUG",
"-DWEBRTC_APM_DEBUG_DUMP=0",
"-D_GNU_SOURCE",
"-w",
]
save the changes and exit
install the package using pip
pip install .


Default order

Can you change orderby() default part . Please check if query has order inside, than use this order as default, not first column.
if ( ! is_array($dtorders))
{
return >>query has order by<<?"":$orders . $this->columns[0] . " asc";  // default
}
I have solution, can I send you by mail?

I think it is not necessary.
You can add an option parameter to javascript to order any column you want.
https://datatables.net/reference/option/order
example :
$('#example').dataTable( {
    "order": [[ 3, 'asc' ], [ 1, 'asc' ]]
} );

Btw, that default part works only if there is no header info. Datatables is sending the header info to sort first column as default

I know well datatables option, but I want to have initial order completely different. I can not make that kind of order with columns in datatable.

https://gist.github.com/n1crack/7467a9a991369cb44b1e4d6af4933ac2
I made some changes for you in this gist. let me know about the results. You must add "order": [] to your javascript.
Still when the user sorts the table via clicking columns, it will be ignored.

No it is not good. If I have in order by something like "case when c.data_type = 'STRING' then 1 else 0 end, c.column_name", than I got error Unknown column 'c.data_type' in 'order clause''.
My solution:
.....
$query = preg_replace("/((?:[^()]+|(?R))+)/i", "", $query);
preg_match_all("/SELECT([\s\S]?)((\s*)FROM(?![\s\S])))([\s\S]?)/i", $query, $columns);
$this->hasOrderIn = count(preg_grep("/(order\s+by)\s+(.+)$/i", explode("\n", $query)));
$columns = $this->explode(",", $columns[1][0]);
.....
....
if ( ! is_array($dtorders))
{
return $this->hasOrderIn?"":$orders . $this->columns[0] . " asc"; // default
}
....

Nice one. ty. This will be added in the next patch.

Thx


feat(whale-api): whitelist getaddressinfo

What this PR does / why we need it:

Whitelisting getaddressinfo to be able to verify if address is owned by the wallet in bridge
[ ] Checking if this can be used to verify if address is owned

Which issue(s) does this PR fixes?:

Fixes #
Additional comments?:

Whitelisting getaddressinfo to be able to verify if address is owned by the wallet in bridge
[ ]  Checking if this can be used to verify if address is owned

Nope it doesn't work like this, apps/whale-api doesn't hold an keys.

Whitelisting getaddressinfo to be able to verify if address is owned by the wallet in bridge
[ ]   Checking if this can be used to verify if address is owned

Nope it doesn't work like this, apps/whale-api doesn't hold an keys.

@fuxingloh Thanks, closing this PR then. Any thoughts on how to verify if an address is owned by a wallet?

Whitelisting getaddressinfo to be able to verify if address is owned by the wallet in bridge
[ ]    Checking if this can be used to verify if address is owned

Nope it doesn't work like this, apps/whale-api doesn't hold an keys.

@fuxingloh Thanks, closing this PR then. Any thoughts on how to verify if an address is owned by a wallet?

If you have the privateKey for it then you check it; what wallet system/provider are you using?

WhaleWalletProvider, ok I have an idea on what to do know as discussed. Will check via the index


Dynamic inventory script for CM does not work with Python 3

@roczei could you please take a look when you have time? Otherwise I will try to fix when I get a chance.

Hi @dbeech,
Ok, I am going to fix it this month (November 2019).

Hi @dbeech,
Done. This was an incompatible change therefore I created a new file for Python 3 and renamed the original one to reflect that it is for Python 2.
Python 2 version: cloudera-playbook/dynamic_inventory_cm_py2
Python 3 version: cloudera-playbook/dynamic_inventory_cm_py3
Here is the related commit.

Thanks for the quick turnaround @roczei


Update asset is prone to race condition

Description
We need to update the whole metadata array when updating assets document so when metadata are partially updated, we need to keep the previous metadata and merge with the new one.
2 calls to update will be vulnerable to race condition since we are getting the asset, merging metadata, emitting event and finally updating.

Isn't the whole manipulation of devices and assets vulnerable to race condition since we do not create mutex on top of ES, would it be linking, adding measures...

No, it's because two element try to alter content of the same field. (not erased it, but alter it)
In other update, that does nos cause race condition because the field is erased and we do not use the previous value to create the new.
We can probably using https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-update.html#upserts to resolve the problem.


Add basic SPI driver

After working with this in the enc28j60 branch I know understand that this API needs to be more high-level and support transferring of whole buffers.


run-length-encoding: make description consistent with test cases

Fixes #537.

Looks good @daveyarwood except one minor change.

Change made -- I amended my previous commit to keep things tidy.

Great, thanks @daveyarwood for fixing this! I'll go ahead and merge this one the Travis CI build completes.


Python 3.6.5: error while using sqlite3

I've just tried to upgrade my app to Python 3.6.5 (from 3.6.4) and I got this error:
sqlite3: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory

It's happening during deploy, we do extra steps to create a sqlite3 DB.
I managed to reproduce this in a more self-contained test. I created a very simple Python app.  Under 3.6.5, it generates the above error.

@browniebroke thanks for the bug report. I can reproduce this on my end. I'll take a look on what's wrong here.

We use it as partial database for our iOS app. That makes local DB the app can use without network latency or connection issues.

sqlite is important for python users! It's the future!

p.s. it's also required for silly tools like ipython, which must work on heroku

@browniebroke that sounds like a fantastic solution.


Create todo app using react,

In this project, I

[ ] created an empty todo-list react app,
[ ] created Todos, TodoList, InputTodo, and TodoItem components.
[ ] added functionality for:
- adding new todo,
- deleting a specific todo and
- editing a todo
[ ] added styles.

Thank you very much. I will update the license link.


Adding custom libraries in console doesn't work

Hi.
I tried to add my library.
http://jsbin.tumblr.com/custom-libraries
but It doesn't work. It just adds one 'undefined' menu in Add Library tab.

By following steps from JS Bin Help section, I am running typeof libraries which in return shows "undefined".
Am I missing something?

@sumitramteke are you doing this in your browser's native console - i.e. not JS Bin's console.

No @remy, I am doing it in JS Bin only

Okay, so you want to do it in the browser console.

No, actually I wanted to add my custom library in JS Bin but was failing. While debugging I found that libraries object was showing undefined.

This is the result of typeof libraries in incognito, not logged in:

@remy thanks! I misunderstood your previous comment. Its working now. From documentation I thought we have to use JS Bin console


col-auto removes gutters

Perhaps it is intentional, but when you add col-auto, or col-{breakpoint}-auto for that matter, it automatically removes the element's gutters.
In my case, the first column has col-auto. It indeed fits to its content, but since there are no gutters defined for col-auto, it fits the outer edge of the row parent. As a result, it kind throws off the general flow and style of the row/column formatting.
I feel it would be beneficial to keep gutters intact regardless of whether or not a column is given a specified column length or set to auto. For the time being I have manually added in padding.
I couldn't find any other issues for this matter, and documentation makes no mention of it either. In the examples, they use col-12 on top of col-md-auto, so the element conveniently gets the padding from the col-12 class.

Bug reports must include a live demo of the problem. Per our contributing guidelines, please create a reduced test case via JS Bin and report back with specific browser and OS details.

Example: https://jsbin.com/borusisaxi/edit?html,output
Using Chrome, Version 56.0.2924.87 (64-bit) running on Windows 10 64-bit OS

I'm experiencing the same problem on the latest v4-dev branch. I've applied the same fix as @goldboat90, but I'd agree that the expected behaviour would be that the gutters would remain intact.


Features/issue24 turning on iam role cannot be disabled

This PR is for Issue #24.  Note this is a breaking change for the use of environment variable AWS_USE_IAM_ROLE to turn on the use of IAM role.  The value of the variable now has to be a valid Boolean truthful value ('True', 'On', or 'Yes') for the use of IAM role to be enabled.  A value of 'False','Off', or 'No' will disable the use of IAM role, which can be a requirement for certain agents that are either not in AWS or for whatever reason do not have the appropriate role and you have to use access keys instead.
We've also added unit tests to cover this usage (and the use of AWS_USE_IAM_ROLE variable in general).  To enable executing of such tests in our environment, we've also mocked out the system environment variables in tests by parameterizing the environment hashmap in GoEnvironment.java (originally it was hard-coded to System.getenv(), so system environment variables could be polluting the tests).
Finally, the build.bat file was added to support CI in a Windows environment.

@manojlds Can you please help review the build.bat? Rest LGTM, except for minor comments here and there.

@manojlds @ashwanthkumar
The original PR was submitted when Java source was still 1.6, but that was since changed to 1.7 with commit fbfd1aac1f74d1a3b4e8db3444709ed0fa93a422, which seems to be the cause for the build check to fail.  Not sure what's the best way to proceed.  Should I close this and create a new PR, or is there another way to resolve?
Thanks

@haimizrael I changed our CI's configuration for this PR. It's all green now :)

@ashwanthkumar Thank you!

@ashwanthkumar do you guys need me to do anything else on this PR?

LGTM :+1:

LGTM :+1:

Merging this.

Thanks @haimizrael.


Semantics of action changed

TL;DR
With the latest changes, certain settings are now handled differently, which is a breaking change.
For example it seems timeout can no longer be provided as pure number.
The error is:
"message": "Invalid value at 'function.timeout' (type.googleapis.com/google.protobuf.Duration), Field 'timeout', Illegal duration format; duration must end with 's'",

Expected behavior
No response
Observed behavior
No response
Action YAML
-   id: Deploy
                uses: google-github-actions/deploy-cloud-functions@main
                with:
                    timeout: 540

Additional information
No response

Hi @cjanietz - thank you for pointing this out. We're doing some refactoring on master which might be unstable for a bit, but thank you for point this out, as we were missing a test for this!
https://github.com/google-github-actions/deploy-cloud-functions/pull/215


Use CSS Grid for VAudioTrack row layout

Fixes

Fixes #2010 by @obulat
Description

This PR simplifies the VAudioTrack's row layout by replacing flex layout with grid layout.
Testing Instructions

The CI should pass.
Checklist

[ ] My pull request has a descriptive title (not a vague title like Update index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@obulat are you considering updating this PR to resolve conflicts and merge? Or would you prefer that we should close it?

Given the no response since the last week and how behind this PR is from the main branch, I'll close it. Feel free to reopen it if you want to resume it!


Clean not working tests

@Nyan11 Oh ok I understand, this is why #9 don't pass ?

Fix in : https://github.com/OpenSmock/Bloc-Serialization/pull/10


Host aggregate model code

This includes the basic model code for Host Aggregates.
Basic tests are included, and exposing methods for automation.
Not yet included: ui, controller code, refresh code, or anything
linking to OpenStack via fog.
Also, there's nothing done with rollups or other metrics. I'm not
sure what's needed here and whether I'll need to add the vms association
to make any of that happen.
Also note that there are some associations commented out in the HostAggregate
model. I wanted to make sure there was no need for any of them (taken
from availability zone as my initial model for this) before nuking them
for good. In particular, the vms and events stuff may actually be needed,
in which case I'd need to rework the model and migrations to include it

OK, this should fix the schema test error.

This looks good to me at first blush.  @aufi, @Ladas, you guys have more experience modeling within ManageIQ - what do you guys think?

Revised the naming of the host/aggregate mapping model -- next step is rollups.

@Ladas @petrblaho FYI those "cloudforms" warnings are from the hostnames in the VCR cassette. Should the obfuscate script munge these too in some way? That might be tricky since it would mess with content-length, etc. In any case the existing files already have those names in place -- this isn't a new change. The only real change to the VCR data is the adding of the host aggregate API calls.

@miq-bot remove_label wip

@sseago I added some comments (not much important propably), but PR looks good

@aufi Thanks for the feedback. The next update will incorporate it, as well as the necessary code rebase.

:+1: The modeling and refresh code looks solid to me; unsure about the metrics rollup

@sseago Thanks, looks good (from my perspective).

+1, reasonable first set of changes for host aggregates

@blomquisg we've done some initial code reviews - do you think this is mergeable?

@miq-bot assign @blomquisg

@miq-bot assign @blomquisg

@tzumainn @sseago looking ...
Will have to be on my Monday list


Fresh install "Cannot find any driver"

Operating system
Debian
Description
Hey,
used the provided docker compose to fire up an instance of Windows 11 as mentioned in the "Getting Started"
services:   windows:     image: dockurr/windows     container_name: windows     environment:       VERSION: "11"     devices:       - /dev/kvm     cap_add:       - NET_ADMIN     ports:       - 8006:8006       - 3389:3389/tcp       - 3389:3389/udp     stop_grace_period: 2m

Getting the no driver found window.
Is there any solution for this?
Docker compose
services:
windows:
image: dockurr/windows
container_name: windows
environment:
VERSION: "11"
RAM_SIZE: "8G"
CPU_CORES: 2
DISK_SIZE: "64G"
devices:
- /dev/kvm
cap_add:
- NET_ADMIN
ports:
- 8006:8006
- 3389:3389/tcp
- 3389:3389/udp
stop_grace_period: 2m
Docker log
❯ Starting Windows for Docker v2.04...
❯ For support visit https://github.com/dockur/windows
❯ Booting Windows using QEMU emulator version 8.2.1 ...
3h3h3hBdsDxe: failed to load Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0xA,0x0)/Scsi(0x0,0x0): Not Found
BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
Screenshots (optional)
No response

Seems to work fine with the Windows 10 image

@mkccl In the log it says "Windows for Docker v2.04" which is a very old version. Could you please try again with the latest version (4.02).

Oh, thanks for the tip. Using :latest worked like a charm.
Can be closed. Thanks


Fix deprecated size prop usage in Loading component

Description:
This pull request addresses issue #2488, which pertains to the documentation of the Loading component. The documentation has been updated to replace references to the deprecated size prop with the correct fontSize prop to align with the current API standards of the @yamada-ui/react package.
Current behavior (updates)
The documentation for the Loading component was referencing the deprecated size prop, which is no longer supported and has been replaced with the fontSize prop in the latest API.
New behavior
The Loading component's documentation now correctly reflects the use of the fontSize prop instead of the deprecated size prop. This ensures that users following the documentation will use the component correctly.
Is this a breaking change (Yes/No):
No
Additional Information

This update is purely a documentation change. No functional changes were made to the component or its associated tests.
The documentation is now consistent with the current API, reducing potential confusion for developers.

@tmasuyama1114 @quantumshiro
Hi, thanks for the PR.
Isn't the issue you are specifying a documentation update?
It appears that you are changing the package instead.

@hirotomoyamada
Hi, thanks for pointing that out!
I see now that the issue was intended to be a documentation update only.
My apologies for misunderstanding; I initially thought the URL in the issue was just for reference 🙏
I've reverted the changes to the package and updated the documentation as needed.
Could you please review the PR again?

@hirotomoyamada
I see that the files I modified are automatically generated and should not be manually edited.
Thanks for pointing this out, and I have updated the PR accordingly.

Thanks


1.8.1 writtes message to error stream on installation

Following up to #430. Current version still seems to write messages to the error stream, which might cause trouble if run in a scripted environment, which watches the error stream and considers everything written to it as an error.
><EMAIL_ADDRESS>tabtab C:\Users\pascal.berger\AppData\Roaming\npm\node_modules\yo
> [ $CI ] || tabtab install --name=yo --completer=yo-complete

'[' is not recognized as an internal or external command,
operable program or batch file.
  tabtab:commands Windows shell completion not yet supported, skipping completion install +0ms

which watches the error stream and considers everything written to it as an error.

Then that environment is faulty. Exit codes indicate failure. The error stream is just an alternative stream.

In that case though, it's just the user mis-describing his issue. It doesn't have anything to do with the error stream.
The process is down straight failing because it tries to run bash code on windows. - Time to update your windows!
To be fair, we should remove the bash part of it as it'll fail on every old windows and tabtab should check for the CI variable internally.
cc @mklabs

Concrete problem is when using in a Chocolatey package, where we just call npm install -g<EMAIL_ADDRESS>in the chocolateyInstall.ps1 PowerShell script during the installation. Environment is Windows 10.

I agree with Sindre on this one, stderr is often used as an alternative stream (debug, npmlog, etc.)
@SBoudrias Ok on checking CI variable within tabtab. Might as well add a few more env var hook to skip tabtab install or specify a meaningfull default (like TABTAB_DEFAULT=2 or similar to skip prompts).

@mklabs I think we should skip prompt by default.
Then maybe if a user run yo completion manually, we prompt them if tabtab is not installed?

@SBoudrias yeah ok, was a concern when I initially did the PR. Will prepare a PR to move the tabtab install part behind yo completion.  I didn't cause it meant altering the generator loading for one keyword "completion".

Should now be fixed in 1.8.2


Email link re-authentication doesn’t work

Environment

Objective C or Swift: Swift
iOS version: 12.2
Firebase SDK version: 6.4.0
FirebaseUI version: 8.0.4
CocoaPods Version: 1.7.3

Describe the problem:
Steps to reproduce:

Setup anonymous & email link authentication
Set shouldAutoUpgradeAnonymousUsers to true
Sign in anonymously
Authenticate with email link
Sign out
Sign in anonymously again
Authenticate with email link same as email of step4
Email link authentication does not work

Observed Results:

What happened?  This could be a description, log output, etc.
The error FIRAuthErrorCodeEmailAlreadyInUse is occurred

https://github.com/firebase/FirebaseUI-iOS/blob/master/EmailAuth/FirebaseEmailAuthUI/FUIEmailAuth.m#L381-L387

However success alert is displayed because completion handler does not handle FIRAuthErrorCodeEmailAlreadyInUse error

https://github.com/firebase/FirebaseUI-iOS/blob/master/EmailAuth/FirebaseEmailAuthUI/FUIEmailAuth.m#L355-L374

Expected Results:

Sign in with email link succeeds

Relevant Code:

https://github.com/firebase/FirebaseUI-iOS/blob/master/EmailAuth/FirebaseEmailAuthUI/FUIEmailAuth.m#L381-L387
https://github.com/firebase/FirebaseUI-iOS/blob/master/EmailAuth/FirebaseEmailAuthUI/FUIEmailAuth.m#L355-L374

Thanks

I have been working on a problem that I believe is exactly this issue. I have a workaround for re-authentication, but it isn't ideal: https://stackoverflow.com/questions/58290744/firebase-ui-email-link-opens-app-and-is-handled-by-the-proper-method-but-does-n/58313033#58313033
I also provide more context on where the issue is occurring which can be summed up as:

Anonymous user inputting email for email link sign in/up will cause the email link to provide a field containing the anonymous user's uid
Handling an email link with an anonymous uid will Always cause the email auth provider to attempt to auto upgrade an anonymous user
Attempting to auto upgrade an anonymous user to an existing email-link account will always fail
If shouldAutoUpgradeAnonymousUsers = false, then the above will happen regardless, but in handleAnonymousUpgrade  the initial check will always fail, and the email auth provider will default to handling the login attempt as if the user has tried to sign in on a different device which never signs the user in

Not sure if this is the intended outcome for this scenario, but since this issue is still open I thought I would contribute more information to help pinpoint the issue.


A question about loss of pairwise learning

Hello，I'm interested in this work. But I find that in els_sac.py, there are only curl loss and DINO loss. However, the paper also shows the results of BYOL and SimSiam. Why are there no implementations of these two losses in the code?

Hi @ShiguangSun ,
Thanks for your interest. This repo is for evolving loss searching. In this setting, only CURL and DINO are in the search space that’s why the current repo does not contain other losses. I will upload the code you requested soon.
Best,

Hi @ShiguangSun ,
The core code for BYOL and SimSiam has been updated at byol_sac.py and simsiam_sac.py.
Best,

Thanks！


Allow submission of 'empty' forms

Added status field to views, this allows the submission of the form
with no other fields completed.  This means that validations will fire
and return an error enforcing the completion of the question.

@mattmb Can you review this?

LGTM, merge when the :traffic_light: goes green.


Cluster-checks: handle leader election and follower->leader redirection

What does this PR do?
Make the cluster-check handler aware of the leader election status to be able to:

plug into discovery when leading
unplug and redirect to leader IP when following

Accordingly to the RFC: in order to spread checks on all available nodes, the logic introduces a "warmup period" between becoming leader and starting to dispatch configuration. It is set to 15 seconds after receiving the first node status request
Leader election is not required: if it is disabled, the DCA assumes it is alone and starts serving as a leader.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?

Codecov Report

Merging #2696 into master will increase coverage by 0.42%.
The diff coverage is 77.19%.

@@            Coverage Diff             @@
##           master    #2696      +/-   ##
==========================================
+ Coverage   56.66%   57.09%   +0.42%
==========================================
  Files         380      382       +2
  Lines       24123    24364     +241
==========================================
+ Hits        13670    13911     +241
+ Misses       9538     9535       -3
- Partials      915      918       +3

Impacted Files
Coverage Δ

pkg/clusteragent/clusterchecks/stores.go
88.57% <ø> (ø)
:arrow_up:

...kg/clusteragent/clusterchecks/leadership_nokube.go
0% <0%> (ø)

pkg/clusteragent/clusterchecks/dispatcher_main.go
83.33% <100%> (+17.33%)
:arrow_up:

pkg/config/config.go
82.32% <100%> (-0.46%)
:arrow_down:

pkg/clusteragent/clusterchecks/api.go
100% <100%> (+100%)
:arrow_up:

pkg/clusteragent/clusterchecks/dispatcher_nodes.go
92.18% <100%> (+1.27%)
:arrow_up:

pkg/clusteragent/clusterchecks/handler.go
69.92% <70.83%> (+69.92%)
:arrow_up:

pkg/util/kubernetes/apiserver/endpoints.go
80% <80%> (ø)

pkg/logs/auditor/auditor.go
71.12% <0%> (-0.71%)
:arrow_down:

... and 7 more


New UI Plattform

This PR introduces the base for the new UI based on React. The current UI is referred 'classic' while the new React one is named 'plattform' - as it is based on a new UI platform.
The UI itself is de-facto empty - it is just a shell to show how the mechanism works. There will be a parallel PR with a first basic interface.
Detailed mechanisms:

there are env/config.yaml mechanisms to select which UI urls should be served
there are invoke tasks to build the code for the frontend and collect it into static
there are yarn tasks to extract/compile language files (based on gettext)

Fixes #3901

Exciting times!
Regarding translation - we will need to be careful that during this transition process we don't delete any existing translated strings (as much as we possibly can). Otherwise we lose all the great work that has been done on crowdin.

@matmair when this is ready to look at, can you provide a set of instructions to build and run a MVP?

@matmair is this ready to look at? How should I go about getting this running locally - anything I need to build?

Ok, @inventree/triage this should be ready for a first review now. It should just (tm)  work with dev containers.
The inv update command was modified to include everything necessary to set up and build the frontend.
Missing:

[ ] dev docs
[ ] min version of node. technically 16 but I would like to set a higher one (19/20) from the start
[ ] build step for docker (multistep - to not include node on the image) maybe after #5007
[ ] build step for releases
[ ] merging of translation files (or mapping - still not sure about that)

We already sort python imports, maybe it's worth sorting ts imports to. There is this prettier plugin.

Is there already a plan what to use for api requests? I can recommend TanStack/query. This offers a lot of caching, state management, refetching already out of the box. One thing we should also consider is building something to auto generate ts types from the open api definition. This would help us identify errors if we change some fields on the backend that are referenced in the fronted, because ts then would throw an error.

The frontend stack is already kinda done, I am using axios and react-query for now. The branch is here.
I thought about generating bindings but it created huge diffs in testing. My plan is to just test as much as possible of the frontend to catch this kind of issue. Still searching for a good solution to track frontend coverage.

My plan is to just test as much as possible of the frontend to catch this kind of issue.

I'm not sure if tests are the best way for eliminating that issue. They take a long time to run and also set up, especially e2e tests. I think if ts is set up correctly there are not that much bugs that could be catched with e2e tests that couldn't be also catched with typescript and im not sure if maintaining e2e tests are worth that low improvement.
What do you mean with huge diffs? You mean because generating generates them in different orders each time? We could sort them by name so the order is the same every time.

@wolflu05 a thousand lines in the git diff/commit for a simple endpoint addition/move. I do not see how ordering will resolve the problem - the openAPI changes themselves easily get sizeable. I tested with this generator.

But do you think it's better to define all types manually each time there are some changes? Maybe someone only changes backend logic and the ts types are forgotten. I would love if we would have something auto generated.

ok, so would you be ok with creating a FR for auto generated types and do this later if we already have something running, its not ideal, but I think definitely the right step.

Sure, we have a ton of horizon milestones. I like the idea but recognise the work needed to get something stable. A clean schema could also be used for the Python API (and maybe more languages).

@matmair ok getting setup to test this locally, have installed rpm / node / yarn.
root@36e94a55b060:/home/inventree# invoke frontend-compile
Installing frontend dependencies
00h00m00s 0/0: : ERROR: [Errno 2] No such file or directory: 'install'

@SchrodingersGat This works fine for me, tested by just opening the branch in codespaces. Google shows that there is something wrong with your yarn setup. See

@SchrodingersGat you need to be at the root of the repo. The task steps into the directory with the package.json file where the build command is defined at scripts.build

@matmair we'll need to add the required node / yarn dependencies to the development Dockerfiles

@SchrodingersGat I already added it to the dev container - shipping it with the distributed container will enlarge them, not sure if that is required.

This is not the distributed (production) images though. Just the development image for those who use it for dev

If I just open this branch with codespaces, I end up with a non clean working tree.
On branch plattform
Your branch is up to date with 'origin/plattform'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   .pre-commit-config.yaml
        modified:   src/frontend/src/locales/de/messages.d.ts
        modified:   src/frontend/src/locales/de/messages.ts
        modified:   src/frontend/src/locales/en/messages.d.ts
        modified:   src/frontend/src/locales/en/messages.ts
        modified:   src/frontend/src/locales/hu/messages.d.ts
        modified:   src/frontend/src/locales/hu/messages.ts
        modified:   src/frontend/src/locales/pseudo-LOCALE/messages.d.ts
        modified:   src/frontend/src/locales/pseudo-LOCALE/messages.ts

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        InvenTree/web/static/

no changes added to commit (use "git add" and/or "git commit -a")

Why are you removing eslint and prettier from the dev dependencies?

We do not need them; already running with pre-commit

Are you sure the vscode prettier and eslint extensions work? They need to have prettier and eslint installed in node_modules as far as is remember.

I have neither tested that nor plan to. formatting and lining is done by pre-commit both on the Django side and the new UI.

I highly recommend trying it out. It saves so much time, it directly highlights if something is wrong. Also you can type without caring about indentation in tsx and in combination with Format ok save, you just hit cmd+s and everything looks pretty. That doesn't mean I don't use the precommit, that's the last check for me if I overlooked something.

Most extensions do not work well with web IDE which means I can not use them at work so my interest is limited

@SchrodingersGat can we push docs/bare metal releases back and merge this in early?

We have to choose between guaranteed up-to-date pseudo language files or a 'clean ' working branch on the first start. I would rather have the first.

What are these pseudo languages?
the translations are not all, also the build output is not in the gitignore

@matmair I'd like to wait for response to @wolflu05 questions above :)

@wolflu05

they are required to check if all parts of the UI are translateable
if does not make sense to split out one language, will just lead to inconsistencies
yes because the compiled static need to be included to run without node

Those files should be committed - I just removed them for this PR because the UI is empty rn and it makes reading the diff harder without adding any benefit. It is the same as with the language files - we automated that part but at some point they need to be updated and included.

I would appreciate it if you would not extend your content meaningful after commenting by editing - I mainly read on mails to decide if I need to answer and do not get updates for edits @wolflu05

Those files should be committed - I just removed them for this PR because the UI is empty rn and it makes reading the diff harder without adding any benefit. It is the same as with the language files - we automated that part but at some point they need to be updated and included.

I don't like commiting the build output. As you said, the diff gets really huge, that means also the repo size rapidly grows => it takes an eternity to clone the repo, currently it already needs 40s to clone. I would say that node is required if you develop frontend parts and if you don't like to install it, use the devcontainer. It's a really bad idea if this is the only argument to commit these huge diffs later.
And regarding the languages and pseudo languages, you plan to commit them before merge?

With regards to translation files:

We need to be very careful that we don't remove the current string translations which have been done on crowdin
Any new translations (i.e. in react) should match the strings used in existing translations
We need to very carefully ensure that adding in new translation files happens in a way which is compatible with our current translation setup
At some point, we'll remove translation for html templates and js templates (way down the track)

@matmair with this in mind, can you please briefly outline how the translation files are calculated / stored in the new framework? So we can determine how we plan for integration with crowdin.

@wolflu05 if you see another way to distribute the front end I am open to ideas. The alternative way still has to work for bare metal installs - we would brake the upgrade path for most users otherwise judging from the issues.

@SchrodingersGat translations work basically the same as they do with the current frontend. Strings are discovered when the frontend-trans task is run, placed in .po files, those are picked up by crowdin, translated, pushed from crowdin to the translation branch and then merged into master before release.

We need to be very careful that we don't remove the current string translations which have been done on crowdin

the new translations would be separate, like the app translations

Any new translations (i.e. in react) should match the strings used in existing translations

Not sure this will be possible - a lot of the interface is underdocumented so there will probably be a lot of new tooltips, menu entries etc.

We need to very carefully ensure that adding in new translation files happens in a way which is compatible with our current translation setup

Uses the same mechanism as the current setup

At some point, we'll remove translation for html templates and js templates (way down the track)

A lot of strings are also used by the backend so that will not remove a lot of translatable files - a bunch of glue pieces for the current way of translations will be removed tough

@matmair ok thanks, I'm happy with that. Sounds like we have a way forward at least

Anything holding us back from merging at this point?

the front end I am open to ideas. The alternative way still has to work for bare metal installs - we would brake the upgrade path for most users otherwise judging from the issues.

We can build them and upload a zip file with the point releases. If you want to install from a none point release, require node. I know a lot of softwares that require node for their frontend build (e.g. gitea). And for apt packages, I guess there is already some build step where this could be build.

My feeling is that the compiled web files should not be included in the repo. If we run through the different ways to use InvenTree:
| Setup Method | How to get src files |
| Docker | Compiled as part of docker image build |
| Installer | Compiled as part of install process |
| Bare Metal | Compiled as part of install procedure |
| Devcontainer | Probably not needed, run using yarn? |
| Other ... | ??? |

Compiling the frontend on the server with bare metal and installer means that every user needs to install thousands of external packages on their machine. If only one of those is vulnerable (pretty likely) web proxies or on-device scanners will trigger - effectively making inventree uninstallable in the enterprise/goverment or for responsible sysadmins.
If this is the plan I need to hand-break my involvement in this whole thing hard as all usability in my deployments is gone. Requiring nodejs on the server means no installation in my environments - the whole frontend integration is designed around this requirement. If the user installs nodejs you could just use the build output of that but at that point, I can not deploy anymore. Also, the installation footprint shoots up significantly if you need all the modules on the server - that is above 1gb of unneeded junk for a 5-10 mb frontend.

Why not upload a build output to each point release as a zip file?

Compiling the frontend on the server with bare metal and installer means that every user needs to install thousands of external packages on their machine. If only one of those is vulnerable (pretty likely) web proxies or on-device scanners will trigger - effectively making inventree uninstallable in the enterprise/goverment or for responsible sysadmins.
If this is the plan I need to hand-break my involvement in this whole thing hard as all usability in my deployments is gone. Requiring nodejs on the server means no installation in my environments - the whole frontend integration is designed around this requirement. If the user installs nodejs you could just use the build output of that but at that point, I can not deploy anymore. Also, the installation footprint shoots up significantly if you need all the modules on the server - that is above 1gb of unneeded junk for a 5-10 mb frontend.

You make some great points here - the security implications in particular I had not considered.
I had been considering this front-end code in a similar way to how we currently render static files with invoke static. But if we are not going to be shipping node at all, as it is not required to actually serve the compiled frontend code, then this makes sense.
I'm happy to move forward with compiled front-end files "baked in". Let's keep this going, this is a super important path forward for the project.

I see the points with the vulnerabilities, but really, we shouldn't commit the build output. There are a lot of downsides:

The repo contains 14.5k commits and the folder is huge, 209MB currently. Cloning takes about 40s on my machine. If we commit the build files we dramatically increase that time and also the size.
PRs contain huge diffs of build changes
The build output is not very consistent, if you change only a few components it can result in a changed build output from ground up, because e.g. you have different versions of node packages. The build output files are normally minified, so they are all in one line
Merging get a PITA, especially with multiple concurrent merges as every pr changes these files

How to properly solve this problem:
As stated by @SchrodingersGat we have a few targets. My suggesting would be the following:
We have to distinguish between development and production.
Development
I think for development on the frontend it's not a big deal to install nodejs, you need it anyway. If you only want to do backend, go ahead and use some API client like postman or the integrated one. For devcontainer, its not a big deal the devcontainer contains node anyway.
Production

Setup method
How to deliver the static build output

Docker ✅
Compiled as part of docker image multistage build

Installer ❓
Compiled as part of the deb package build process

Bare Metal ❓
Compiled as part of a release pipeline and uploaded as a zip folder to the GitHub releases. The setup instructions could then just download the zip folder, extract it and place it inside static

Bare Metal (no point release) ❓
Can't help you, you need node, or at least docker and build it yourself, very small user base and also not the recommended setup for production

Please, evaluate the downsides, they are big for me. I really don't like to have them in here. I really know we want to move this forward, but once we decide to commit the repo will definitely grow fast and we can't reverse it.

Maybe due to me being a complete react noob, but is it possible you guys are talking about different things?
@wolflu05 you are talking about 200mb worth of files - which directory, specifically, and what purpose do these files serve?
@matmair you are talking about 10mb worth of files - which directory, specifically, and what purpose do these files serve?

I'm talking about the files in InvenTree/web/static/ that are generated by invoke frontend-build. They are only 5-20MB even the project grows, but committing a diff in those files only a couple of times increases the repo size, commit diff, checkout time by a lot.

I would rather have devs download a bigger repo from time to time then most users (especially the ones that have been using this for years when bare metal was the only real deployment option) dealing with node. Manual changes to the update methodology are about the most brutal thing you can do to a sysadmin.
@SchrodingersGat I am talking about the real files that are acutally present
@wolflu05 with that argument we should stop translations

I will step back from discussions for a few days as I do not feel that it will be productive in the end. Favouring one deployment method because of the lack of the others will only lead to more support load and if that is the result I'd rather ship the frontend as a plugin or reconsider the rewrite.

@matmair @wolflu05 are we happy to move on from here, and merge this (without the compiled front-end files), with the understanding that this code will not go into production without a complete, robust method for distribution that does not require the user to compile from node?

fine with me @SchrodingersGat

Yeah, also fine with me, merging this now definitely simplifies things e.g. the huge diff in the other PRs.

Fantastic :) @matmair are there any other changes you want to make here, or happy to merge as-is?

Yes @SchrodingersGat let's merge


Add certificate expiry validation in all the flows of SAML and OIDC

For example,

Identity Server is not validating the Service Provider's public certificate's expiry time in SAML and OIDC IDP flows along with SP initiated request validations and IDP response validations.

We also need to add the certificate expiry validation in  SAML2 Bear grant  +  Outbound SAML response validation

A Related fixed issue https://github.com/wso2/product-is/issues/5883

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


summarize updating project dependencies read me

Description of changes: summarizes each steps to take in order to update a project dependency due to a security vulnerability.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/override eks-distro-docs-presubmit

/approve


Uses the un-minified versions of typescript on nightly and pr builds

I jammed with @kingwl on getting better stack traces for PR and Nightly builds of TypeScript in the playground
Before:

After:

Thanks for the quick response!


Download links - direct and over the app are pointing for 1.6.4 after the 1.7 release

Describe the bug
Despite release the 1.7 version the only channel that got the update is Over the App for Apple Silicon. The x86 and both of the website direct links are pointing to 1.6.4.
To Reproduce
No response
Expected behavior
No response
Diagnostic report (REQUIRED)
No response
Screenshots and additional context (optional)
No response

Intentional. 1.7.0 is rolling out gradually.


Package/bundle Turbinia recipe yaml files for normal deployment mechanisms

Recipe yaml files are already included in the current build due to setuptools_scm pulling in all files tracked in Git.


Uppercase mistake in parameters for Deploy-Private-DNS-Zones policy set

Hi,
Three of the parameters in the Deploy-Private-DNS-Zones does not follow a consistent naming scheme. The names ends with ID in uppercase, in conflict with the rest of the parameters ending in Id.
Inconsistent parameters:
azureSiteRecoveryBackupPrivateDnsZoneID
azureSiteRecoveryBlobPrivateDnsZoneID
azureSiteRecoveryQueuePrivateDnsZoneID
How it probably should be:
azureIotCentralPrivateDnsZoneId
azureStorageTablePrivateDnsZoneId
azureStorageTableSecondaryPrivateDnsZoneId
Is there a reason for this? If not, I can submit a fix.

Thank you for pointing this out - at the moment these policies are synchronised from upstream in the Azure/Enterprise-Scale repo.
Please feel free to submit a fix there 😄


Rationalize the logging in ACA-Py

While the team building ACA-Py has been pretty good at maintaining the logging, there is some inconsistency in the handling of logging.  This task is to formalize the logging approach across the board, and then to do a pass through the code ensuring that the logging statements match the intention of the approach.
The first part (formalizing) is likely just creating something like a "logging.md" that outlines how contributors should be doing logging. Even better would be to find and reference (likely in "contributors.md") a well-known Python standard logging approach. Whatever is selected should be reviewed and agreed to by the team.
The second part includes ensuring the logging library is configured appropriately, any non-logging print statements are either removed or converted to logging calls, and that all logging is happening at the appropriate level (e.g. debug, warn, error, etc.).
Wrapping up the project will include adding guidance (or CI checks?) for existing and future devs on how they can make sure that the logging remains top notch.

I am interested in working on this issue.

Assigned to you @nacerix -- thanks.  Please let us know if you have any questions.
Please look at the contributor guidelines and especially make note of the need to DCO sign off every commit.  That is a requirement with all Hyperledger repos.  Much worse if you find out about that later. :-)

sure, I will do

Some proposals to start the discussion:
1- Print is not a good idea
2- Use Python standard logging module to:

You can control message level and filter out not important ones
You can decide where and how to output later
Write logging records everywhere with a proper level
3- Write logging record everywhere with appropriate level and configure them later.
What is the appropriate level to use? (to do Add recommendations?)
4- Recommend cascaded logger naming: use name as the logger name
5- Capture exceptions with the traceback
6- Use global logger instead of module level logger.
7- Use JSON or YAML logging configuration over code
8- If logging to a file, prefer rotating file handler
9- Setting level names to avoid typos
10- Performance: Wrap Expensive Calls in a Level Check
11- Performance: Avoid Logging in code that is critical for performance

Definitely agree on 1 :-) - that's one we want to be sure to eliminate.
I think the rest of your points are correct but leave it to the devs to both confirm and add guidance as to what is in place now and what we want to have.
@andrewwhitehead @nrempel -- can the two of you add your $0.02CDN to help kickoff this task?

Thanks for picking this up @nacerix!
I agree with all of your points. We use the python logging module and normally make it available like this: https://github.com/hyperledger/aries-cloudagent-python/blob/master/aries_cloudagent/protocols/present_proof/v1_0/manager.py#L42
We allow setting of log level with a command-line parameter when you start the process but it is also possible to ingest a python logging config .ini file for more complex configuration: https://github.com/hyperledger/aries-cloudagent-python/blob/master/aries_cloudagent/config/logging.py
We use print() in a couple places early in the lifecycle of the process. If you can find a clean way to move that to the python logging module, go for it. I think we currently use print() any time before our logging config has been loaded.
Let me know if you have any questions!

Dear community, this issue is already closed. Can somebody link a file that documents the log-levels or give an example how to change the default WARNING.
There is a command line parameter called log-level, but this seems only to handle debug, info and warning.
Other level fall back to warning.

@chriamue -- I recommend you open a new issue on how to use the log-level and anything else need to get logs.  You might try searching in the issues and on rocketchat for previous discussions and add a PR to doc it.  Sorry it's a pain to find.


Execute code blocks from other plugins within a cell

Problem
It would be incredibly useful to be able to execute code blocks from other plugins like Dataview or Tasks from within a cell.
Solution
I would envision this as a new cell type.
Additional details
No response

@clshafer Thanks for your feature request. I actually just tried this and you can execute dataview blocks from within a text cell. That is because I use the Obsidian MarkdownRenderer.renderMarkdown function. Essentially any markdown functionality that Obsidian has, should be supported by the tables. I could make this a new cell type though if that would be helpful

That’s really great! No need to create a distinct cell type, including it in the documentation should be sufficient.
One obvious application for this would to make a simple Kanban.

On Jun 12, 2023, at 11:25 AM, Trey Wallis @.***> wrote:
@clshafer https://github.com/clshafer Thanks for your feature request. I actually just tried this and you can execute dataview blocks from within a text cell. That is because I use the Obsidian MarkdownRenderer.renderMarkdown function. Essentially any markdown functionality that Obsidian has, should be supported by the tables. I could make this a new cell type though if that would be helpful
—
Reply to this email directly, view it on GitHub https://github.com/trey-wallis/obsidian-notion-like-tables/issues/563#issuecomment-1587567241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXCDLQIJQBRJGYG5AD3RJNTXK4YILANCNFSM6AAAAAAZDMJXXE.
You are receiving this because you were mentioned.


ImportError: cannot import name 'iterateints' from 'construct.core'

macOS 12.0.1 Monterey

Steps to reproduce:
$ git clone --depth=1 https://github.com/LedgerHQ/satstack.git
Cloning into 'satstack'...
remote: Enumerating objects: 1822, done.
remote: Counting objects: 100% (17/17), done.
remote: Compressing objects: 100% (11/11), done.
fetch-pack: unexpected disconnect while reading sideband packet

$ cd satstack

$ cd scripts

$ python3 -m venv venv  # ensure Python 3.7+

$ source venv/bin/activate

(venv) $ pip install -r requirements.txt
Requirement already satisfied: base58 in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 1)) (2.1.1)
Requirement already satisfied: click in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 2)) (8.0.3)
Requirement already satisfied: construct in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 3)) (2.10.67)
Requirement already satisfied: ecdsa in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 4)) (0.17.0)
Requirement already satisfied: ledgerwallet in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 5)) (0.1.2)
Requirement already satisfied: protobuf in ./venv/lib/python3.8/site-packages (from -r requirements.txt (line 6)) (3.19.1)
Requirement already satisfied: six>=1.9.0 in ./venv/lib/python3.8/site-packages (from ecdsa->-r requirements.txt (line 4)) (1.16.0)
Requirement already satisfied: tabulate in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (0.8.9)
Requirement already satisfied: cryptography>=2.5 in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (36.0.0)
Requirement already satisfied: Pillow in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (8.4.0)
Requirement already satisfied: hidapi in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (0.11.0.post2)
Requirement already satisfied: requests in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (2.26.0)
Requirement already satisfied: intelhex in ./venv/lib/python3.8/site-packages (from ledgerwallet->-r requirements.txt (line 5)) (2.3.0)
Requirement already satisfied: cffi>=1.12 in ./venv/lib/python3.8/site-packages (from cryptography>=2.5->ledgerwallet->-r requirements.txt (line 5)) (1.15.0)
Requirement already satisfied: setuptools>=19.0 in ./venv/lib/python3.8/site-packages (from hidapi->ledgerwallet->-r requirements.txt (line 5)) (49.2.1)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.8/site-packages (from requests->ledgerwallet->-r requirements.txt (line 5)) (2021.10.8)
Requirement already satisfied: charset-normalizer~=2.0.0 in ./venv/lib/python3.8/site-packages (from requests->ledgerwallet->-r requirements.txt (line 5)) (2.0.8)
Requirement already satisfied: idna<4,>=2.5 in ./venv/lib/python3.8/site-packages (from requests->ledgerwallet->-r requirements.txt (line 5)) (3.3)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in ./venv/lib/python3.8/site-packages (from requests->ledgerwallet->-r requirements.txt (line 5)) (1.26.7)
Requirement already satisfied: pycparser in ./venv/lib/python3.8/site-packages (from cffi>=1.12->cryptography>=2.5->ledgerwallet->-r requirements.txt (line 5)) (2.21)

(venv) $ ./getdescriptor --scheme native_segwit --chain main --account 3
Traceback (most recent call last):
  File "./getdescriptor", line 11, in <module>
    from ledgerwallet.client import LedgerClient
  File "/Users/michaelhenke/Projects/satstack/scripts/venv/lib/python3.8/site-packages/ledgerwallet/client.py", line 29, in <module>
    from ledgerwallet.manifest import AppManifest
  File "/Users/michaelhenke/Projects/satstack/scripts/venv/lib/python3.8/site-packages/ledgerwallet/manifest.py", line 10, in <module>
    from ledgerwallet import params
  File "/Users/michaelhenke/Projects/satstack/scripts/venv/lib/python3.8/site-packages/ledgerwallet/params.py", line 20, in <module>
    from construct.core import (
ImportError: cannot import name 'iterateints' from 'construct.core' (/Users/michaelhenke/Projects/satstack/scripts/venv/lib/python3.8/site-packages/construct/core.py)

latest pip installed:
(venv) $ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in ./venv/lib/python3.8/site-packages (21.3.1)

This project seems dead... Here's a solution to this problem though:
In the scripts/requirements.txt replace construct with construct==2.9.52.

Hi, this is now fixed.


ARROW-6599: [Rust] [DataFusion] Add aggregate traits and SUM implementation to physical query plan

This PR implements the traits for aggregate expressions and the SUM implementation.

Thanks for the review @paddyhoran ! I've addressed most of the comments. The reason for the concise function names for creating expressions is so that users can write concise code when building a query plan. For example:
HashAggregate:::new(
  col(0), // GROUP BY c0
  sum(col(1)), // SUM(c1)
  ..
);

Let me know what you think.

The reason for the concise function names for creating expressions is so that users can write concise code when building a query plan.

Ok I see, in that context it makes sense to keep them short and concise.


Flow type map perf improvement

This  is part of the work of #8739
907f394 add a customized set/map
ac6d8ee add the fast C comparison function
46e535a 6cfd2cf 7fb4d90 8a73104 micro tweaks using the new API

@panagosg7 comments addressed and rebased


Add Ruby 2.7 and Ruby 3.1 testing

Fill out our testing a bit
Signed-off-by: Tim Smith<EMAIL_ADDRESS>

I don't think we actually support 2.7 since refinements are buggy in that and I used them from the parallel_map stuff, we should probably have pinned chef-17 to 3.0 only (although it works fine if you don't touch knife at all)


🔧 MAINTAIN: Update package name to sphinx-jupyterbook-latex

This PR updates this package name to be sphinx-jupyterbook-latex and fixes #61
PR #55 updated the package to be dependant on sphinx rather than jupyterbook so this rename more closely aligns with the package and how it is implemented as a sphinx extension.
This package still contains the latex infrastructure for jupyter-book

[ ] rename actual github repo
[ ] Setup via PyPI
[ ] Setup via Conda Forge

@chrisjsewell @AakashGfude there is one failing test but that is expected as it is trying to run jb build and that upstream tool hasn't been updated yet.

[ ] what should be done around jupyterbook-latex links in the CHANGELOG.md. I guess they should be updated to sphinx-jupyterbook-latex given the name change and so they continue to resolve. @chrisjsewell do you agree?

Alternatively we could start a fresh repo but I don't think that makes sense.

I think just renaming this repo is OK so I have update links in CHANGELOG to sphinx-jupyterbook-latex so they continue to link.

This PR https://github.com/executablebooks/jupyter-book/pull/1340 needs to be tested once this is released

@chrisjsewell will I need to register this new package name with PyPI or will the publish workflow register it when it publishes via the v* tag rule?

[x] this has been tested against git+https://github.com/executablebooks/jupyter-book@sphinx-jupyterbook-latex in a local environment. @chrisjsewell I couldn't figure out how to specify a git+https install in setup.cfg to test via GitHub Actions.

@AakashGfude would you have time to review this PR?

thanks @AakashGfude I will change the name once jupyter-book=0.11 is released so it will be included in the next minor release jupyter-book=0.11.1

@choldgraf @chrisjsewell what is best practice re: name change release. Should we:

rename this repository and start issuing sphinx-jupyterbook-latex
archive this repository and setup a new repo named sphinx-jupyterbook-latex then deploy to pypi

Just thinking through pypi and starting to think Option 2 is the best route but thought I would see what you think.

Oh no definitely just rename the repo.

OK cool -- thanks @chrisjsewell wasn't sure if a rename would mess up pypi history. But looks like pypi tar files are hosted by pypi (rather than fetching from github)

Well pypi doesn't even care what the repo name is (of course packages can come from anywhere not just GitHub), it cares what the package name is, which are two distinct things

Yeh and pypi doesn't fetch from GitHub in anyway, you push to pypi


Create README.md

Description
This update implements a face recognition system using three models—CNN for feature extraction, SVM for classification, and ResNet for enhanced accuracy on suboptimal recognition rates. Key dependencies include TensorFlow, scikit-learn, and OpenCV for effective model training and image processing.
Fixes # (1582)
Type of change

[ ] Added a new machine learning frameworks, libraries or software.
[x] Documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

@sanjay-kv Plz review and designate a appropriate label


Add i18n support

run "npm install ipx"
if the issue continues which it did in my case, delete node modules and install again
rm -rf node_modules
npm install
that should fix it


Ellekit Support?

I did some research and it seems like adding ellekit is as simple as:

Adding a argument for it
Pretty much copying all of the Substitute Code but making it use libellekit.dylib instead of libsubstitute.dylib
Done (???)

I'll eventually get a pr made

How nice of evelyneee to include CydiaSubstrate.framework in the ellekit deb

what are you talking about
ellekit is just a hooking library, it's a replacement for the CydiaSubstrate API

so there is pretty much no need for it

Oh

what are you talking about
ellekit is just a hooking library, it's a replacement for the CydiaSubstrate API

So is substitute

what are you talking about
ellekit is just a hooking library, it's a replacement for the CydiaSubstrate API

Isn't substitute also a hooking library that is a replacement for the CydiaSubstrate API?

yeah, it's used in palera1n for example
it's just an alternative implementation


nixos/system: fix the systemd-network-wait-online@ template.

Description of changes
Use the %i specifier instead of %I. %I doesn't escape any characters that are significant for the network interfaces, but mangles - which is more common in the interface names.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Looks good. Upstream uses %i to template the interface name as well.
Comparing to upstream we still have a few differences that I'm not sure are correct:
We have Requisite instead of BindsTo so if systemd-networkd is stopped or skipped, we still still start systemd-network-wait-online@?
We are also missing DefaultDependencies=no. Not sure what net effect that will have.

Wait... why aren't we using the upstream unit? We can do the same ExecStart trick that we do for the non-template version to get the extra wait-online args. And why is our unit name spelled slightly differently (network vs networkd)? I feel like we should just switch to the upstream unit, create a compatibility alias for our misspelling, and possibly find a way to warn about its usage.

@ElvishJerricco I guess it begs the question why do we put all networkd settings under systemd.network.* instead of systemd.networkd.*?
I agree, moving to the upstream unit with our typical NixOS overrides makes sense.

Closing in favor of #360319.


Patron profile (user view)  - list of loans

Some users would like to be able to see all their loans on one page. Many users have a high number of loans.
For the time being, we display only 5 loans on a single page.
Is it possible to display by default a higher number of loans on this page (e.g. 30)?

We have discussed this feature, and we have decided that the best user experience here would be to. For each of the sections in Current and History tabs:

add the pagination component on the top and on the bottom
add a test that says something similar to Showing 5 out of x
add a show all button to display all of them when clicked


iTunes category parsing fails for nested categories

iTunes categories can be nested. The parser does not yet support this.

Should be fixed as of #15 :)

Should be fixed as of #15 :)

Yep, you're right :)

Yep, you're right :)


experiment_id: Definitions of 1pctCO2-rad and 1pctCO2-bgc

The experiment 1pctCO2-rad currently has the definitiion "Radiatively-coupled specified concentration simulation in which CO2 increases at a rate of 1% per year until quadrupling", which is slightly misleading because the 1pctCO2 experiment also has radiatively coupled CO2. The distinctive feature in 1pctCO2-rad is that there are two CO2 concentrations in play, one involved in the carbon cycle and one linked to the radiation code. 1pctCO2-rad and 1pctCO2-bgc form a pair: in the first the radiatively coupled CO2 is increasing, while the carbon cycle CO2 remains at control levels; in the 2nd this is reversed. After discussion with Chris Jones, I suggest the following descriptions (designed to make sense when read in isolation):
1pctCO2-rad: "1 percent per year increasing CO2 coupled to the radiation code with control CO2 concentrations applied in the carbon cycle",
1pctCO2-bgc: "1 percent per year increasing CO2 coupled to the carbon-cycle code with control CO2 concentrations applied in the radiation".

@taylor13 can we get clearance to make these changes from the MIP-chairs?

@martinjuckes @taylor13 @charliepascoe this is a duplicate of #339 so will copy this across and close this issue


NEXTAUTH_URL has to be specified when deploying to Netlify

Environment

Operating System: Darwin
Node Version:     v16.15.1
Nuxt Version:     3.4.3
Nitro Version:    2.3.3
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      ssr, target, modules, buildModules, css, runtimeConfig, auth, apollo, colorMode
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
No response
Describe the bug
The origin is not set correctly, and NEXTAUTH_URL has precedence over NUXT_ORIGIN, AUTH_ORIGIN, ORIGIN
Additional context
No response
Logs
No response

We also noticed this in our Azure environments, and this warning began appearing recently in STDOUT:
[next-auth][warn][NEXTAUTH_URL]
https://next-auth.js.org/warnings#nextauth_url

Had to add that variable to set origin on deployment.
Node: v18.16.0
Nuxt: v3.2.2
Nuxt-Auth: v0.4.4
Next-Auth: v4.22.1
Builder: Vite

This is also happening on our azure setup now (started a couple of days ago, without setup change). The NEXTAUTH_URL is now needed for it to work.

Hi! I have looked into this myself before, but never had enough time to complete it. From what I understand we need to add support for reading the NEXTAUTH_URL in order to properly deploy to Netlify right?
If that is the case you could add a extra section to do this in the following file:
https://github.com/sidebase/nuxt-auth/blob/main/src/runtime/server/services/utils.ts#L11
Feel free to take a swing at it and see if it resolves the issue!

Hello,
I had the same issue with Nuxt 3.5.2 and @sidebase/nuxt-auth 0.5.0, and I don't know what change but I tried today to upload in my production netlify site and all is working fine!
I just put my origin in nuxt.config.ts:
  auth: {
    origin: process.env.AUTH_ORIGIN,

and the environment variable in the setting section of netlify:

Maybe a Netlify patch?

Same issue

Nitro patched a bug this summer, where Netlify was having issues setting cookies with Nuxt projects. Have you tried deploying since then, as I can imagine, this caused many more issues!
https://github.com/unjs/nitro/pull/1452
After their patch, I managed to deploy the NuxtAuthExample to Netlify. If the issues, persists, you are welcome to reopen this issue!


null relation and NullResource return empty array instead of null

In pure Fractal, when you return a null from an include the field is not added on the output array.
If you return a NullResource I think it returns a "fieldname => null" instead (not 100% sure).
In laravel-responder it returns an empty array in both cases, it seems.
I actually recall that yesterday it returned a null field, but I don't remember if it was before or after i started playing with this library 🤔
Can you confirm this or it's a problem with my code? If it's the intended behaviour, would't it be better if it returned just null instead of an empty array?
The use case scenario here is that I have users with an avatar which is optional, so the relation could return null.
If it's not null, it returns the image transformed by its transformer as intended,
If it's null, it returns an empty array.

Strange, this does not sound like expected behavior, I'll look into it.

I can't seem to replicate. Nullable has-one/belongs-to relations output null for me when not set. Do you have some more information I can work?

I guess it's problem somewhere in my code then, I'll dig deeper and let you know if I find why this is happening

Ok, I came back on the problematic code and found out some more info.
The empty-array-instead-of-null is resulting from the includeMembers I used to overcome the add-pivot-data problem (see #81, I don't know how to share a link to a specific post).
The cause seems to be the fact that I provide an array to $this->resource($data) instead of a Model or Collection, and I think that it's related to the missing support of primitive data (which Fractal 0.17 has).
This have two effects:

the empty-array-instead-of-null mentioned early;
the serializer somehow strips out the "data" namespacing and the entity data in the resulting JSON is flattened together with decorators data, below an example of how it's outputted vs how it should be, with dummy data.

How it is with the bug:
[status] => 200
[success] => true
[id] => 3
[name] => ut
[created_at] => [ / data / ]
[is_admin] => 1
[members] => [
    [
        [id] => 28
        [display_name] => Kris Schowalter
        [avatar] => []    <=== wrong empty array
        [pivot] => [
            [admin] => 1
            [created_at] =>[ / data / ]
        ]
   ]
   [
        [id] => 29
        [display_name] => Prof. Branson Senger Sr.
        [avatar] => []    <=== wrong empty array
        [pivot] => [
            [admin] => 0
            [created_at] => [ / data / ]
        ]
   ]
],

How it should be:
[status] => 200
[success] => true
[data] => [    <=== normal namespacing
    [id] => 3
    [name] => ut
    [created_at] => [ / data / ]
    [is_admin] => 1
    [members] => [
        [
            [id] => 28
            [display_name] => Kris Schowalter
            [avatar] => null    <=== null instead of empty array
            [pivot] => [
                [admin] => 1
                [created_at] =>[ / data / ]
            ]
        ]
        [
            [id] => 29
            [display_name] => Prof. Branson Senger Sr.
            [avatar] => null    <=== null instead of empty array
            [pivot] => [
                [admin] => 0
                [created_at] => [ / data / ]
            ]
        ]
    ]
]

I pinpointed the problem with the empty-array-instead-of-null problem (which can be related to the second strange behaviour I reported right above).
It's because for transform() helper it's used NullSerializer which serializes null resources as empty arrays instead of just null.
I think this must be changed to keep consinstency with SuccessSerializer which returns null values as expected.
Probably this has been done in order to return always an array even if no given data is provided, if this is the case I'm not really sure about how it can be changed maintaining same behaviour, I think it's not possible. Still I prefer to get a null even in that case.
I got that problem because in includeMembers I was transforming data with the helper before returning it wrapped in a $this->resource($data) call.
It's not even possible to specify a custom serializer, so there is no possible workaround, as far as I know, other than redefining the transform helper or copying the code inside the helper definition.

I see. I'm actually not sure why the NullSerializer returns empty arrays for null resources. I believe this is a mistake, I'll look into it.

I tryed to modify it to return null and an error bubbled up from fractal package.
I've also checked Fractal serializers and they return [] too, so I guess it's some defaults behaviour inside Fractal that is managed at some point of the serializing process...

I figured it out. NullSerializer has sideloadIncludes() set to true, which attempts to merge the data with sideloaded data - which fails because it's not an array. However, it doesn't actually use sideloads for anything, so setting it to false and returning null from the null() method seems to do the trick!

I'm not understanding what "including side-loads" actually means...
I see that the ArraySerializer (which is the base of your SuccessSerializer) keep the default implementation of the method defined on SerializerAbstract, which returns false.
In other words, you can just remove the method from SuccessSerializer and rely on the default one.
In Fractal serializers, only the JsonApiSerializer overrides that method to return true.

The sideload including is an additional step used for adding more data to the final output. For instance, the JsonApiSerializer from Fractal uses it to add relationship information below the actual data. I thought I actually used the sideloadIncludes() method for something for SuccessSerializer. But it seems like the output stays the same even after removing both the sideloadIncludes() and includedData() method (which is only called if sideloadIncludes() is true). I'll do some more checking to make sure it's the same without, but removing this from SuccessSerializer will also fix the NullSerializer issue as you pointed out.

Ok, here is what I found about this issue and my hypotesis:

Fractal translated null to an empty array for "consistency" reasons: they want all branchs of the JSON to be array-based;
sideloadIncludes and includedData are not used in this library, but given that you expressed many times your idea of staying as much decoupled from Fractal as possible, I may imagine that you didn't want to rely on the underlying Fractal defaults method because they could change, so you just copied all methods, updating something, instead of overriding only the methods which were going to change. You probably saw that those two methods didn't break anything and just left them there (still dunno why sideloadIncludes returned true, maybe it was like this in a previous version of Fractal and you copied it from there?);
I also noticed that you removed, in NullSerializer, the ability to add meta data (pagination, cursor, etc), which I guess is a consequence of removing the data namespace;
You removed also the meta namespace for metadata informations, which again I think is a consequence of removing the data namespace from collections (Fractal have it, but you remove it inside mergeIncludes);
Your paginator and cursor methods are different from Fractal implementation: either you simplified them or copied them from a previous version; on this regards I'd suggest to rely on Fractal implementation where possible and copy the needed methods only when and if the package moves to another underlying transformation manager (Laravel Resources in this case) to avoid missing possible fixes/enhancements.

Given this, I changed null() return value from [] to null and removed sideloadIncludes and includedData from SuccessSerializer, then I updated the test for the NullSerializer and removed the tests for the methods removed from SuccessSerializer.
Here you can check the changes I've made.
I'll now test this setup on my project.
Tell me what do you think about this.

An ever better idea would be to return null if the relation refers to a sigle entity and an empty array when the relation refers to a collection of entities, but we currently have no way to know it, right?

Ok, the fix proposed won't work alone.
This is because Fractal allows to it's methods to return null (return types are not used) while you used the return type array on:

make() in FractalTransformFactory and TransformFactory related interface;
transform() in Transformer class and the interface with the same name;
transform() in TransformBuilder;
transform() in the helper file.

This can be resolved removing the return type or, when if using PHP7.1 or higher, using the nullable return type ?array.
This kind of behaviour cannot be checked with Unit tests, that's why you probably though it was ok to just remove those methods and change to null the null() method on NullSerializer.
I think it's better to start writing a test suite with Feature tests, but I'll leave to you to set the format, given that you said you were already going to do that.

return null if the relation refers to a single entity and an empty array when the relation refers to a collection of entities

I noticed that, given that Laravel always returns a Collection for xxx-many relationships but it returns null on missing not-xxx-many relationships, this behaviour already take place with the updates I did.
This need a Feature test too.

You probably saw that those two methods didn't break anything and just left them there (still dunno why sideloadIncludes returned true, maybe it was like this in a previous version of Fractal and you copied it from there?);

I believe I used the sideload includes in a previous version of the serializer, and then found a way to simplify the code for v2, but forgot to remove the methods. I believe these do absolutely nothing right now.

I also noticed that you removed, in NullSerializer, the ability to add meta data (pagination, cursor, etc), which I guess is a consequence of removing the data namespace;

The reason NullSerializer exists is that Fractal doesn't have an API for transforming data without also serializing. This limitation caused me headaches when dealing with web sockets, as I also wanted to expose all data in its transformed state. So the idea was to create a serializer which did absolutely nothing and apply that when using the transform() helper or Transformer service class. Pagination and meta data is part of the serialization part and therefore left out for it.

Your paginator and cursor methods are different from Fractal implementation: either you simplified them or copied them from a previous version;

It should be pretty much the same for SuccessSerializer, with the exception of the keys being camel cased. (It calls the parent method here).

An ever better idea would be to return null if the relation refers to a sigle entity and an empty array when the relation refers to a collection of entities, but we currently have no way to know it, right?

Yes, as you pointed out, this is already the case.

This is because Fractal allows to it's methods to return null (return types are not used) while you used the return type array on:

Indeed, this is something I was looking briefly at when working on supporting primitive resources. I agree this is an unwanted limitation. If we change the contracts I think we should push a new major version, though, as people might rely on these.

I think it's better to start writing a test suite with Feature tests, but I'll leave to you to set the format, given that you said you were already going to do that.

Yeah, I'll get on this soon :)

If we change the contracts I think we should push a new major version, though, as people might rely on these.

I'm not sure about this.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

This is the definition of versions following the Semantic Versioning.
Allowing nulls in return type "supersets" the current API, so I think it can be considered a backward compatible adjustment, so a minor version 🤔
Anyway, shall I make a PR? Then we can just leave it there until you prepare the tests

The $this->null() still returns empty array. I couldn't find a solution but passing the relation as a Primitive resource.

The $this->null() still returns empty array. I couldn't find a solution but passing the relation as a Primitive resource.

Thanks. i also got this error. Thought it would have been fixed by now.
Your solution fixed.
{     "class": "TypeError",     "message": "Flugg\\Responder\\Serializers\\NoopSerializer::null(): Return value must be of type array, null returned",     "code": 0,     "file": "/var/www/html/vendor/flugger/laravel-responder/src/Serializers/NoopSerializer.php:51",


Integrate kubebench report chart legend

1.Integrate kubebench report chart legend

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@18f591c). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #123   +/-   ##
=======================================
  Coverage        ?   43.70%
=======================================
  Files           ?       10
  Lines           ?     1167
  Branches        ?        0
=======================================
  Hits            ?      510
  Misses          ?      624
  Partials        ?       33

Flag
Coverage Δ

unittests
43.70% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Allow use of custom metadata descriptors in EDP simulator

Background
The primary intent of the EDP simulator is to facilitate Halo integration tests. It is however also useful for operators of Halo systems to use it for their own testing, so some functionality has been added to support this. The EDP simulator currently uses specific EventGroup metadata descriptors to control requisition fulfillment behavior w.r.t. how events are generated. The intent was that real EDPs could also be made to implement the same behavior to support conformance testing. With the advent of efforts such as HMSS, EDP libraries, and the EDP aggregator, the need for this kind of performance testing has diminished. Separately, Halo operators have indicated a desire to use the EDP simulator for end-to-end testing of other parts of their systems such as EventGroup search.
Proposal
Allow operators to specify EventGroup metadata using any EventGroup metadata descriptor. This means that the metadata descriptor cannot be used to control event generation behavior. Instead, this behavior is solely controlled via configuration of the simulator itself.

Note that no two registered EventGroup metadata descriptors can share types unless those types are in the "known event group metadata type" set. This is controlled by the --known-event-group-metadata-type option passed to the Kingdom and Reporting systems. See the v0.5.2 release notes for more details.

It'll be easier to implement this after first implementing #1881


Add Makefile for Installs, Builds and Local run

I have checked the following:

[X] I've searched existing issues and found nothing related to my issue.

Describe the feature you want to add
Add Makefile to easy development

Install npm dependencies
Build local packages
Build Sandbox libraries
Run local instances

Mockups or Images of the feature
List of targets:

I am already working on this @helloanoop

Hi @sreelakshmi-bruno , why has this been tagged as long-term?

Hi @stupidly-logical, we are currently looking into critical bugs and improvements which are blocking users from using Bruno. If this feature is a blocker for you/ you are working on a PR for this, let us know we can look into it. Thanks!

@sreelakshmi-bruno PR: https://github.com/usebruno/bruno/pull/3540

Hello @sreelakshmi-bruno I wanted to know more about Bruno's PR review process. Why it takes the time it does because I have 2 PRs open. Wanted to check if I am doing everything right.


[pyright] specify which interpreter to use

Explicitly tell pyright to use the tox python interpreter so there is no confusion on how to do import resolution. The pythonpath commandline argument was added in a later version than the version we pin, so suggesting we bump the version now and fix the the new typing errors later.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-messaging-webpubsubservice


gRPC connector that allows self-signed certs

This approach works on Mac with Golang gRPC server listening on https (self-signed certs). But it failing in k8s with below error:
2024-12-11T15:33:23.693266Z  INFO numaflow_core::metrics: Connecting to Monovertex daemon uri=https://<IP_ADDRESS>:4327/
thread 'tokio-runtime-worker' panicked at /numaflow/numaflow-core/src/metrics.rs:896:14:
daemon should be up: Status { code: Unknown, message: "client error (UserUnsupportedVersion)", source: Some(hyper_util::client::legacy::Error(UserUnsupportedVersion)) }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2024-12-11T15:33:23.693934Z  WARN hyper_util::client::legacy::client: Connection is HTTP/1, but request requires HTTP/2

This may be because of ALPN https://github.com/seanmonstar/reqwest/discussions/2350#discussioncomment-10020959
However, the unit tests shows ALPN protocols are set when we use enable_http2() method.
It seems hyper's client pool is http1 and tonic is trying to send http2 request https://docs.rs/hyper-util/0.1.10/src/hyper_util/client/legacy/client.rs.html#289
UPDATE:
This was because of https://github.com/golang/go/issues/46602 and https://github.com/golang/go/issues/14619

When we specifytls.Config.NextProtos = []string{"h2", "http/1.1"}, kubelet's health check tries to do health check probes with HTTP/2 request. The cmux we use thinks it is a gRPC request and results in 415 Unsupported content type. Since it breaks the k8s health checks, we won't be making this change.
Currently, this PR would only be adding a utility hyper client for future use with gRPC servers that use self-signed certs.

@kohlisid please make the changes @whynowy suggested.


feat(HACBS-2471): add update-infra-deployments task

We are re-using the update-infra-deployments task from build-templates
We have updated it to use extraData and snapshot json files as input.
Added simple test using mocking strategy

I have altered the test to use one of Martin's new methods.

It lgtm, but I think @mmalina's approval would be good too as he understands the new testing framework much better than me

Yeah, but we haven't really reached a conclusion about what to use going forward. If that's ok, I'd prefer to wait for that (and I will add documentation as well).


Horizontal scrollbar shown instead of shrinking columns when minWidth and width "*" are used

When first columns has low minWidth and others have greater minWidth we can get scroll even if the column with small minWidth could be smaller. See plunker: http://plnkr.co/edit/N9P7zsJr2AsKCOvlStO7?p=preview
In the example first column is set small minWidth but next columns are set with bigger minWidth.
Right now we calculate width from left to right and having the width we check if it fits from min to max width. Because of this first column is not shrink to it's minimum but get the size of 1/n.
Simple but not ideal solution: We should change the algorithm to calculate column's width in order from maximum minWidth to minimum. Columns with minWidth not set are calculated last.

It's already fixed in the RC21.


Context menu will disappear when there is new text appeneded in Output Channel

Issue Type: Bug
I could confirm this bug only repro when window.titlebarStyle is custom

VS Code version: Code - Insiders 1.28.0-insider (45986ca7abf63460dc96409a61fb2f0c98ba0b70, 2018-09-19T09:34:25.276Z)
OS version: Windows_NT x64 10.0.17134
Extensions (3)

Extension
Author (truncated)
Version

code-runner
for
0.9.4

azure-account
ms-
0.4.3

azure-iot-toolkit
vsc
1.4.0

duplicate of #54594


[WIP] fix big rnn eval hybridization and sparse_grad=False

Description
Fix a few hard coded places that causes param sharing / hybridization to fail
Checklist
Essentials

[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Job PR-277/1 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-277/1/index.html


[Request] Change Mist Icon to not be a square

I'm not sure what icons are available at all, however every icon other than mist has a more rounded appearance which makes 'mist' stand out as it is nearly a white square. Is there any way this could be changed to a more fitting icon?

I noticed this too. Note that wttrbar just uses the fog emoji, but the way it looks really depends on your font. https://emojipedia.org/fog shows that indeed most fonts draw it as a square icon. I'm happy to consider changing it something else but not sure which one is more fitting? there's a "foggy" icon but it's also a square usually.

All the icons shown on the Waybar are square, change them to those in the hourly forecast.

The same icons are used for the main indicator and for the tooltip. If you're seeing something else, please provide a screenshot as something seems to be broken with your setup.

I'm going to close this as I'm not sure there is a great solution to this without repeating icons. I wish there was a more rounded mist but without something like a custom icon I don't know that it's this repo's responsibility.

Yea, mist emoji does feels off than the rest used in this module.