VS 2008 for amd64 is no longer detected

This issue was originally created at: 2014-07-21 15:43:04.
This issue was reported by: kayhayen.
kayhayen said at 2014-07-21 15:43:04

In my Python compiler Nuitka, I specify the target architecture, as detected by
another Python running potentially under Python3, potentially on another
architecture. That is why I do TARGET_ARCH assignment when created the
environment.
For Python2 though, it's running Scons with sys.executable, as that will be good
enough for Scons. But it could well be imagined, and happens, that a Python3
compilation calls Scons with a Python2 of another architecture.
However, I noticed that with Scons 2.3.2, only the 32 bit compiler is found, but
when TARGET_ARCH is "x86_64", on the same system, that 2.3.0 finds it, it is not
found.
There is something in the release notes about TARGET_ARCH no longer defaulting
to HOST_ARCH. Not sure, if that is related.
So here is 2.3.2 output:
$ /c/Python27_32/python bin/nuitka --run --show-scons tests/basics/Asserts.py
Scons command: c:\Python27_32\python.exe .\nuitka\build\inline_copy\bin\scons.py
-f .\nuitka\build\SingleExe.scons --jobs 6 --warn=no-deprecated --no-site-dir -
-debug=explain show_scons=true python_version=2.7 unstriped_mode=false full_comp
at=true debug_mode=false target_arch=x86 optimize_mode=true source_dir=Asserts.b
uild cache_mode=true name=Asserts python_debug=false python_prefix=c:\Python27_3
2 module_count=1 result_name=Asserts nuitka_src=.\nuitka\build module_mode=false
experimental=false
scons: Reading SConscript files ...
AssertionError: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe
:
File "C:\Users\hayen\repos\Py2C\nuitka\build\SingleExe.scons", line 205:
assert False, getExecutablePath(env["CXX"], initial = False)
hayen@HAYEN-PC ~/repos/Py2C (master)
$ /c/Python27_64/python bin/nuitka --run --show-scons tests/basics/Asserts.py
Scons command: c:\Python27_64\python.exe .\nuitka\build\inline_copy\bin\scons.py
-f .\nuitka\build\SingleExe.scons --jobs 6 --warn=no-deprecated --no-site-dir -
-debug=explain show_scons=true python_version=2.7 unstriped_mode=false full_comp
at=true debug_mode=false target_arch=x86_64 optimize_mode=true source_dir=Assert
s.build cache_mode=true name=Asserts python_debug=false python_prefix=c:\Python2
7_64 module_count=1 result_name=Asserts nuitka_src=.\nuitka\build module_mode=fa
lse experimental=false
scons: Reading SConscript files ...
AssertionError: None:
File "C:\Users\hayen\repos\Py2C\nuitka\build\SingleExe.scons", line 205:
assert False, getExecutablePath(env["CXX"], initial = False)
I am merely dumping what env["CXX"] resolves to. No MSVC is in PATH of course.
For 2.3.0, this looks like this:
$ /c/Python27_32/python bin/nuitka --run --show-scons tests/basics/Asserts.py
Scons command: c:\Python27_32\python.exe .\nuitka\build\inline_copy\bin\scons.py
-f .\nuitka\build\SingleExe.scons --jobs 6 --warn=no-deprecated --no-site-dir -
-debug=explain show_scons=true python_version=2.7 unstriped_mode=false full_comp
at=true debug_mode=false target_arch=x86 optimize_mode=true source_dir=Asserts.b
uild cache_mode=true name=Asserts python_debug=false python_prefix=c:\Python27_3
2 module_count=1 result_name=Asserts nuitka_src=.\nuitka\build module_mode=false
experimental=false
scons: Reading SConscript files ...
AssertionError: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe
:
File "C:\Users\hayen\repos\Py2C\nuitka\build\SingleExe.scons", line 205:
assert False, getExecutablePath(env["CXX"], initial = False)
$ /c/Python27_64/python bin/nuitka --run --show-scons tests/basics/Asserts.py
Scons command: c:\Python27_64\python.exe .\nuitka\build\inline_copy\bin\scons.py
-f .\nuitka\build\SingleExe.scons --jobs 6 --warn=no-deprecated --no-site-dir -
-debug=explain show_scons=true python_version=2.7 unstriped_mode=false full_comp
at=true debug_mode=false target_arch=x86_64 optimize_mode=true source_dir=Assert
s.build cache_mode=true name=Asserts python_debug=false python_prefix=c:\Python2
7_64 module_count=1 result_name=Asserts nuitka_src=.\nuitka\build module_mode=fa
lse experimental=false
scons: Reading SConscript files ...
AssertionError: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64
cl.exe:
File "C:\Users\hayen\repos\Py2C\nuitka\build\SingleExe.scons", line 205:
assert False, getExecutablePath(env["CXX"], initial = False)
Any idea what is going on there?

dirkbaechle said at 2014-07-22 00:16:10

Kay,
if you're interested in immediate feedback to your problem, I can only recommend
to repost your questions on the User Mailing list at<EMAIL_ADDRESS>.
You'll reach a much larger audience there, we have quite a few Windows experts
that don't check on this issue database regularly.
In general, this is the preferred method anyway: Asking on the User ML first, to
get confirmed that it's a bug. Then create an issue report for it.
Thanks a lot in advance for your consideration.
Dirk

kayhayen said at 2014-07-27 11:28:41

I was looking at the code diffs, and trying with debug setting as advised on the
mailing list. No response to this, I guess, that is more development stuff:

If the user hasn't specifically requested a TARGET_ARCH, and

The TARGET_ARCH is amd64 then also try 32 bits if there are no viable

64 bit tools installed

try_target_archs = [target_platform]

if not req_target_platform and target_platform in ('amd64','x86_64'):

debug("msvs_find_valid_batch_script(): req_target_platform %s target_platfo

VS2012 has a "cross compile" environment to build 64 bit

with x86_amd64 as the argument to the batch setup script

if req_target_platform in ('amd64','x86_64'):

   try_target_archs.append('x86_amd64')

elif not req_target_platform and target_platform in ['amd64','x86_64']:

   # There may not be "native" amd64, but maybe "cross" x86_amd64 tools

   try_target_archs.append('x86_amd64')

   # If the user hasn't specifically requested a TARGET_ARCH, and

   # The TARGET_ARCH is amd64 then also try 32 bits if there are no viable

   # 64 bit tools installed
  try_target_archs.append('x86')

This may well explain my trouble. I do request TARGET_ARCH "amd64", but I only
have a cross compiler, Visual Studio 2008 installed (required to link against
Python2.7). Also, people use 32 and 64 bits Python, and I need to insist the
compiler matches.
So the old code will give "try_target_archs" as [ "x86_64", "x86" ], where the
new code only gives me [ "x86_64", "x86_amd64" ], which is more correct.
However, in my case, "vcvars64.bat" of the "x86" compiler is not attempted in
this case. Only "vcallvars.bat x86_amd64", which while listed in the /h output,
gives an error when executed. With 2.3.0, this error also occured, but then
"vcvars64.bat" was tried, and works.
So, I believe this is a regression of Scons with VS 2008 and x86_64 as a
requested target platform.

kayhayen said at 2014-08-10 11:43:28

So, is there any progress to hope for with this issue. I kind of nailed it pretty
well down, but I suspect nobody really cares anymore, right?
So, I am therefore requiring my users now to upgrade their MSVC installation. It
makes no sense to support 2008 for me anymore, mostly because it cannot be
installed by new users anyway. Whatever problem there would be to not using it,
other solutions need to be found anyway.
So I am open to closing this bug as "won't fix" or whatever it is in this bug
tracker.

This topic is addressed in #3538 - setting TARGET_ARCH defeats some of the logic of the "cross" environments, but not sure it will actually apply to MSVC versions this old.  Is there any reason to keep this issue open given the age of the MSVC and the notes in the last comment (which date to 2014)?

We can't reproduce this currently as VS2008's not available.
If this is still affecting anyone, please reopen and perhaps pop on the users mailing list, IRC, or discord servers so we can work with you to help provide a fix and have you test it.


TGVE should access data only by property name when generating layer

GeoJSON with mixed order of properties in features is a valid object and accessing it via index (as done now in TGVE) is a bug.

Test dataset.


pending pipelines that were stopped before starting never being stopped

run multiple pipelines as a batch. that result in some pipelines that will be in status pending.
take one of those pending pipelines and stop it before it being active.
the pipeline status will remain "stopping" i was waiting for at least 20 minutes without change

related to #17


[POA-2003] Update observability-ir version

Updated observability-ir version
Updated generated-types.go with the new changes

Isn't this blocked until the IR changes are merged so you can refer to the trunk commit?

Yeah, we should add a CI check for this.


Gnome tweak tool doesn't allow for installing shell extensions

Is this expected behaviour or am I missing something? I have my configuration.nix configured with gnome3 and gdm. Was support for the ability to install extensions removed? I am new to NixOS and I hope I am not cluttering your issue board.

Was there ever a support for installing extensions? I do not recall it.

I don't recall seeing within gnome tweak tool the ability to install extensions... Only configure already installed. I only know of installing via https://extensions.gnome.org/ . Perhaps it was removed from gnome tweak in favor of the web one?
There is a bug related to https://extensions.gnome.org/ : The gnome native messaging app is not working. There is a workaround for that issue. Which, once applied, enables extensions to be installed.
See

https://unix.stackexchange.com/questions/437248/how-can-i-install-gnome-shell-extensions-from-extensions-gnome-org-through-firef

The workaround for that is specifically:

determine the location of the the manifest org.gnome.chrome_gnome_shell.json
place under ~/.mozilla/native-messaging-hosts/

See also #26981 which added support. This support did originally work. Something changed with how the messaging app is referenced by firefox since then.

You can also install extensions in GNOME Software or though Nix.

Yeah, upstream removed support for this in 3.26, due to gnome-software now doing the the job: https://gitlab.gnome.org/GNOME/gnome-tweaks/blob/9e4143d786c29c88d289b3d5755b51a47bdb650f/NEWS#L290

To be clear Gnome Software only supports installing and removing not updating:

https://gitlab.gnome.org/GNOME/gnome-software/issues/380

Tweak only supports enable/disable. Not updating as well.
Looks like the only mechanism to update is via the chrome gnome shell.


Make conversion to Iterable tighter

Avoids other collections.abc types that inherit from Iterable being mistakenly treated as iterables, causing errors with things like Mappings

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @kennknowles

Run PythonLint PreCommit

R: @damccorm

possibly related: users were additional hints for more generic types in: https://github.com/apache/beam/issues/24704


Attempting to jog while scanning can wedge planner

this is odd since jogs are dropped

fixed there was some old code on keyUp() that I forgot about


Add scripts for Jenkins and update POM info in build.gradle

Instruction for Jenkins to build CBL-Java: https://gist.github.com/pasin/a61b8d43aac96f3bd88048f5717ddaca
Some of the scripts might need to be changed if we restructure couchbase-lite-java repo.

The PR validation is now passed after merging the PR in java-ee.


Add Get Started and Introduction Guide

Description
Fixes #1
This PR adds:

Pagination Plugin
Light/Dark Theme
Scroll Bar on all Pages
Introduction Guide
Getting Started Guide

@josead @viferga Kindly review :)


UI/UX Design for FilterForm Advancement

Closes:
What's Changed

TODO

[ ] Explanation of Change(s)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[ ] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

POC for #1608. No plan to merge as-is. Kept for posterity.
Great work @timizuoebideri1!


"You cannot use tokens without wrapping the component with StyleProvider" when using variants in react-native

Hi,
first of all, i love this library! This is exactly what i was looking for from an API perspective.
I have the following text component:
import React from "react"
import { Text as RNText } from "react-native"
import { styled } from "@gluestack-style/react"
import { TextProps } from "./text.props"
import { translate } from "../../services/i18n"

const StyledText = styled(
  RNText,
  {
    variants: {
      variant: {
        body: {
          fontSize: "$3",
        },
      },
    },
  },
  {
    componentName: "Text",
  } as const,
)
type StyledTextProps = React.ComponentProps<typeof StyledText>

export function Text(props: TextProps & StyledTextProps): JSX.Element {
  const {
    tx,
    text,
    children,
    txOptions,
    sx = {},
    variant = "body",
    ...rest
  } = props

  const i18nText = tx && translate(tx, txOptions)
  const content = text || i18nText || children

  return (

  )
}

However, when i use it i get

removing the token "$3" gets rid of the error, but this makes the variants api practically unusable for me. My entire app is wrapped in StyledProvider, so not sure what I'm doing wrong.
Thank you

Any solutions for that? I'm experiencing this when using gluestack babel plugin resolver in my project.

Any solutions for that? I'm experiencing this when using gluestack babel plugin resolver in my project.

I ended up using Dripsy for my project.

@rennanlurahy

Any solutions for that? I'm experiencing this when using gluestack babel plugin resolver in my project.

Same exact thing happened to me. Removed @gluestack-style/babel-plugin-styled-resolver and was able to get past this error specifically. Thanks for the heads up here 🙇

I got the same error but when using token with Center from @gluestack-ui/themed. Everything is wrapped inside GluestackUIProvider. Other components like VStack or HStack work with the same props.
...

If I use bg instead of backgroundColor, there will be no error, but it will translate the prop directly into CSS property named bg.

This is an error I'm experiencing despite passing in the config and having the provider wrapped around the entire app. Any updates on this? It's preventing me from using the babel plugin on my project.

I'm also experiencing this error only in certain circumstances which is a little absurd, because it normally works fine.
I'm not using the


in acorn_loose/statement.js recovered node for bogus import statements could be improved

I am using acorn 3.1.0, but this is still in master.
The following code reports an error when used with infer.js (from Tern) because there is no local for the corresponding import statement specifier.
   import * from "./exports"

I propose to replace line 378:
 if (this.eatContextual("as")) elt.local = this.parseIdent()

with:
elt.local = this.eatContextual("as") ? this.parseIdent() : this.dummyIdent();

Doing this we make sure that the specifier has a local (recovered in this case). acorn will properly reports a syntax error on the 'from' and infer.js won't fail anymore.
infer.js has the following code:
    ImportDeclaration: function(node, scope) {
      for (var i = 0; i < node.specifiers.length; i++)
        addVar(scope, node.specifiers[i].local)
    }

So without a local being set to a recovered node, addVar fails with:  TypeError: Cannot read property 'name' of undefined.

Sounds good to me. But really, it's better to just send a PR instead of an issue when you already identified what needs to be changed. Would you want to do that?

Ok, I'll prepare one. Thanks.


Feature: bumping patch, minor and major versions more easily

At the moment, tbump works by providing the version to upgrade to.
however, this implies knowledge about the current version of the developed software. Sometimes after many weeks of not working on a particular project I honestly forget with which version I tagged it last time. 😅
Sure, I can look it up in pyproject.toml or git log, but I suggest the following new flags:

tbump --patch to bump the patch version (eg from v0.0.2 to v0.0.3)
tbump --minor to bump the minor version (eg from v0.0.3 to v0.1.0)
tbump --major to bump the major version (eg from v0.1.0 to v1.0.0)

Sorry, there's already been a discussion about this. See #73, #107

Oh, okay. Sorry for not searching beforehand :sweat_smile:
Does that mean that, even if someone were to implement that functionality and contribute, you still wouldn't merge it?

Does that mean that, even if someone were to implement that functionality and contribute, you still wouldn't merge it?

Yup. That would be a disservice to future maintainers - which could include that very same benevolent contributor :)


Black/blank screen in settings and some other interfaces

Microsoft PowerToys version
0.81.1
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
Settings
Steps to reproduce

Click or double click on Powertoys in system tray.
A fully black window will open that doesnt funciton at all and will close itself in some time.

✔ Expected Behavior
Functional settings menu to open
❌ Actual Behavior
Black/blank window without any functionality instead of the settings window
Other Software
No response

Not able to repro this, going to close. Let us know if you see this again!


[Migration-Doc] - Issue with Oracle script provided for APIM component migration.

Description:
HI Doc team,
This issue was discussed on [1], please refer if needed.
Change  1:
The oracle script provided in APIM 2.6.0 - 3.2.0 [2]  is dropping the primary key of  AM_API_COMMENTS table and adding it back but not as a primary key. This is failing migrations when customers try to migrate to later versions.
ALTER TABLE AM_API_COMMENTS
DROP COLUMN COMMENT_ID
/

ALTER TABLE AM_API_COMMENTS
ADD COMMENT_ID VARCHAR(255) DEFAULT (SYS_GUID()) NOT NULL
/

Hence, we need to add the below command to the script [2]  too.
ALTER TABLE AM_API_COMMENTS
    ADD CONSTRAINT add_pk PRIMARY KEY (COMMENT_ID)
/

Change 2:
We also noticed that the same is done for AM_API_RATINGS  tables too. Hence this below command should be added to the oracle script of both documents [2] and [3] .
ALTER TABLE AM_API_RATINGS
    ADD CONSTRAINT add_pk PRIMARY KEY (RATING_ID)
/

Thankyou,
Inuri.
[1] https://github.com/wso2-enterprise/wso2-apim-internal/issues/717
[2] https://apim.docs.wso2.com/en/3.2.0/install-and-setup/upgrading-wso2-api-manager/upgrading-from-260-to-320/#step-2-upgrade-api-manager-to-320
[3] https://apim.docs.wso2.com/en/4.0.0/install-and-setup/upgrading-wso2-api-manager/upgrading-from-260-to-400/#step-3-migrate-api-m-database
Suggested Labels:
priority/High

Fixed.


github: run fuzz tests with unit tests

Downloads and extracts the fuzz test seed corpora into the LND tree so that "make unit" automatically runs the fuzz tests on the seeds.
The PR currently uses my own repository to host the seeds, since one doesn't exist under https://github.com/lightningnetwork yet.  @Crypt-iQ: Can you set up an official repo for this?
I verified this works by modifying FuzzAcceptChannel to fail on certain seed inputs and checking that the fuzz test failure showed up in unit tests in CI.
Updates https://github.com/lightningnetwork/lnd/issues/7452.

Should ideally be a separate target - if somebody runs make unit they shouldn't have to download all of the test seeds.

make unit doesn't download the seeds.  It simply executes them if they are already there.
This PR only downloads the seeds on the CI VMs.  Users would have to do it manually if they want to run the fuzz seeds with make unit.

Related PR: https://github.com/lightninglabs/lnd-fuzz/pull/2

@roasbeef: review reminder

@roasbeef: review reminder

@roasbeef: review reminder

@roasbeef: review reminder

@roasbeef: review reminder

@roasbeef: review reminder

Just needs a release notes entry!

Done.


[catch2] Update to 3.0.1

Update catch2 from 2.13.9 to 3.0.1.
Changelog : https://github.com/catchorg/Catch2/releases/tag/v3.0.1

Please don't merge it yet, I forgot to move the catch2main library to the manual-link folder. I'll fix it tomorrow.

Catch2 v3 is API incompatible with v2. It probably should be packaged separately from v2.

This should also close https://github.com/microsoft/vcpkg/issues/14391

Catch2 v3 is API incompatible with v2. It probably should be packaged separately from v2.

The upstream maintainer ( Hi @horenmar ! ) has indicated that is not possible because they cannot be installed side by side: https://twitter.com/horenmar_ctu/status/1527010719866277890 so they can't be separate ports. If you need to access a different version, you can do so with manifests and versioning, or with overlays.

Catch2 v3 is API incompatible with v2. It probably should be packaged separately from v2.

The upstream maintainer ( Hi @horenmar ! ) has indicated that is not possible because they cannot be installed side by side: https://twitter.com/horenmar_ctu/status/1527010719866277890 so they can't be separate ports. If you need to access a different version, you can do so with manifests and versioning, or with overlays.

I opened upstream issue, see https://github.com/catchorg/Catch2/issues/2429

vcpkg ports normally don't build test. So they don't actually use Catch.
The picture changes when you enable tests via features, triplet variables or similar. Dependencies might need different versions of catch. And this cannot be solved with overlay ports or manifests.

Lastly, see this https://github.com/microsoft/vcpkg/tree/master/ports/catch-classic . It is catch v1 packaged separately.

If you look at the whole port list, you'll find that this is an exception rather than the norm. Also, there's no single port which depend of catch-classic. As specified in its description, this port exists to provide compatibility with older compilers, which is a different issue than the one you're talking about.
What you're asking for was already suggested, and like horenmar, I don't think the multiplication of different catch ports is desirable : https://github.com/catchorg/Catch2/issues/1945

What I am doing is pointing to a known problem with a known solution. See the upstream issue I linked, and open the link to the Gnome docs I put there. You should be able to reproduce the bug in vcpkg, too. Try installing a port that depends on catch2, e.g.
vcpkg install msix
vcpkg install sqlite-orm[test]
vcpkg install nrf-ble-driver

All these now should fail to build because of the updated catch2

There's only 4 ports in vcpkg that depends of catch2, the one you listed here plus libkeyfinder[test]. I tried to build them on my computer using the latest vcpkg commit with both catch 2.13.9 and catch 3.0.1, and here's the results :

nrf-ble-driver passes with both catch versions.
msix fails to build with both catch versions with the following error :
With catch 2.13.9 :
LINK : fatal error LNK1181: cannot open input file 'folder\vcpkg-catch2\buildtrees\msix\x64-windows-dbg\src\msix\windowsexports.def'
With catch 3.0.1 :
LINK : fatal error LNK1181: cannot open input file 'folder\vcpkg-catch3\buildtrees\msix\x64-windows-dbg\src\msix\windowsexports.def'
sqlite-orm[test] indeed fails to build with catch 3.0.1, but passes with catch 2.13.9.
libkeyfinder[test] fails to build with catch 3.0.1, but passes with catch 2.13.9.

For sqlite-orm and libkeyfinder, the error is the same, they can't find the catch2/catch.hpp header. I suppose it would be pretty straightforward to fix it with a patch. msix fails to build in any case, so bringing a new catch3 port won't help for this one.

msix fails to build with both catch versions with the following error :
With catch 2.13.9 :
LINK : fatal error LNK1181: cannot open input file 'folder\vcpkg-catch2\buildtrees\msix\x64-windows-dbg\src\msix\windowsexports.def'
With catch 3.0.1 :
LINK : fatal error LNK1181: cannot open input file 'folder\vcpkg-catch3\buildtrees\msix\x64-windows-dbg\src\msix\windowsexports.def'

This doesn't seem to be related to Catch at all. And msix build in CI. So this is a different issue.

sqlite-orm[test] indeed fails to build with catch 3.0.1, but passes with catch 2.13.9.

libkeyfinder[test] fails to build with catch 3.0.1, but passes with catch 2.13.9.

So it fails when activating the non-default test feature. This is what I was pointing at:

The picture changes when you enable tests via features, triplet variables or similar. Dependencies might need different versions of catch. And this cannot be solved with overlay ports or manifests.

catch2 vs catch-classic ports are a legacy thing that predates vcpkg's versioning support and AFAIK wouldn't be done again today.

OK then, if you don't go the path with separate packages than the few ports that depend on catch2 should be patched in vcpkg so the build with v3. There are about 5, so this is doable.

Is this port built with the default C++ language version of the compiler? The library seems to build in C++14 mode (which is the default for VS2022), since if you instantiate Catch::StringMaker for type std::string_view or std::byte (like when using REQUIRE(some_string_view, "value")), linker errors will be emitted. Is a C++17 feature flag needed, like abseil?

Is this port built with the default C++ language version of the compiler?

That's up to the library.

The library seems to build in C++14 mode (which is the default for VS2022), since if you instantiate Catch::StringMaker for type std::string_view or std::byte (like when using REQUIRE(some_string_view, "value")), linker errors will be emitted. Is a C++17 feature flag needed, like abseil?

It would surprise me if abseil-like behavior were going on here. catch doesn't expose many data structures to users.

Re std version:
Catch2 does assume that both sides (header and library) are compiled with consistent C++ standard, so we can automatically provide customization points for newer std types (e.g. the mentioned std::string_view).
On another note, I am not sure vcpkg wants to handle Catch2's CMake config options.

We, like I belive many others ran into the undefined symbol Catch::StringMakerstd::string_view when we upgraded our vcpkg stuff and hence to catch2 V3. We are building with C++ 17 in VS which I undertand is the problem.
I am wondering if there is a short term work around or if this issue will result in a fix to this issue?
We can obviuously downgrade catch2 but we would rather not.

It would surprise me if abseil-like behavior were going on here. catch doesn't expose many data structures to users.

Catch2 does provide explicit specialization of the Catch::StringMaker class (which is used to pretty-print objects) for std::string_view and std::byte if compiled under C++17 mode. Currently this port seems to compile the library under C++14 (default language version of VS) and it results in linker errors if you used the C++17 StringMaker specializations.

Re std version: Catch2 does assume that both sides (header and library) are compiled with consistent C++ standard, so we can automatically provide customization points for newer std types (e.g. the mentioned std::string_view).

That sounds that as long as the separately compiled parts are compiled with at least as high a version as the consumer that should work? Or do you actually replace polyfills in a way that will be ABI incompatible?

On another note, I am not sure vcpkg wants to handle Catch2's CMake config options.

If they want to change these values, they need an overlay port or something similar. The state space is intentionally constrained to make sure ports can compose with each other.

Not sure if this is the right place for this. Maybe https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md#things-that-can-break-during-porting would be better. This applies to Visual Studio users using VCPKG.
If your upgrade vcpkg and start getting link errors about things like Catch::StringMaker as mention above it may be because you are building your code using C++17 or above while your catch2 is being built by VCPKS using C++14. Not sure why this happens, deep linker issues? Would be interesting to know if you should expect libraries to be link incompatible if you you use different compiler/linker versions? Hopefully Billy will explain to us mortals!
Anyway as a work aound you can use an overlay port of catch2 that bumps the C++ version to use. I have attached a zip file
catch2.zip
containing such an overlay.
To use it

Create a directory somewhere, I used C:\vcpkg-overlay-ports but wherever you like
Unzip the catch2.zip file in this directory. You should then have a C:\vcpkg-overlay-ports\catch2 with three files in it
One of these file fix-install-path.patch has a line +set(CMAKE_CXX_STANDARD 23) which patches this line in during the build. Feel free to change this to some other version rather than 23.
Add set(VCPKG_OVERLAY_PORTS "c:/vcpkg-overlay-ports") to your CMakeLists.txt. This must be before your project(...) CMake command. You can also set VCPKG_OVERLAY_PORTS on the command line. A search will find various examples
Build as normal. You should see Building catch2[core]:x64-windows... -- Installing port from location: c:/vcpkg-overlay-ports\catch2 or something similar in your CMake output

@BillyONeal

That sounds that as long as the separately compiled parts are compiled with at least as high a version as the consumer that should work?

Yes.

Or do you actually replace polyfills in a way that will be ABI incompatible?

I don't think we currently do, but we also make no promises.


chore: update testing dependencies to recent versions

open question: some dependencies were exact (==) some were open (>=), I have chosen to unify to open; but am OK with the stricter approach and update them in specific future PRs.

Codecov Report

Merging #219 (7e367d0) into master (8e088cb) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #219      +/-   ##
==========================================
- Coverage   92.89%   92.86%   -0.04%
==========================================
  Files           6        6
  Lines        2802     2802
==========================================
- Hits         2603     2602       -1
- Misses        199      200       +1

Impacted Files
Coverage Δ

pyodata/v2/model.py
93.34% <0.00%> (-0.06%)
:arrow_down:

Continue to review full report at Codecov.

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


Deye M100G4 / Update only every 5min

Hello,
unfortunately the plugin (V.1.5.1) only receives new data from the local logger every 5 minutes.
I have already had the support team change the interval to 1 minute and the current data is pushed to the Solarman database (web) every minute, but is only displayed in Homeassistant every 5 minutes.
Does anyone have any advice?
The device is an Deye M100G4 with the latest FW 1.62. Previously with FW 1.59 it was the same outcome.

Further - I have access to the same G3 Model without the Relais.

Same here with Deye SUN600G3-EU-230. It used to update more frequently.

The Solarman Team updated now the Data Upload Period to 1min and I can see this Update rate now in my Solarman Account.
But still it pulls the updates only every 5min to my HA. Is there any info yet, how to fix that?

Are you perhaps looking at the data that comes from short term statistics? There the resolution is 5 min (no matter what is collection interval).

Are you perhaps looking at the data that comes from short term statistics? There the resolution is 5 min (no matter what is collection interval).

No, I'm talking about the recording of the databases, but about the interval at which the data is pushed from Solarman to HA. This only happens every 5 minutes.
Despite the fact that Deye's update rate has been changed from 5 minutes to 1 minute, the data is only displayed in Homeassistant every 5 minutes.
The Solarman web interface is now updated every minute. This is a pity.

My Deye Hybrid updates production and some other entities every 30 seconds.
I edited this line:
/homeassistant/custom_components/solarman/const.py
MIN_TIME_BETWEEN_UPDATES = timedelta(seconds=30)

I found the solution:

Downgrade from 1.5.1 to 1.4.3. and reastart.
Add the deye_2mppt.yaml config into the custom_parameters.yaml and restart.
Now you´ll get an update intervall of 60sec.

An increase of the min update Intervall does not work in my case. But that is okay. From 5min down to 1min is a huge gain for me ;)

My understanding has been that MIN_TIME_BETWEEN_UPDATES is only used to throttle update method calls of Inverter class to be called at most with that interval.  The home assistant default sensor scan interval is 30s and it is defined here.
The type definition final hints that it should not be overridden.  But I have defined in a branch in my fork SCAN_INTERVAL = timedelta(seconds=600) in custom_components/solarman/const.py and it sets the scan interval to 10 min. (which suits my use case best with a reasonable load and data amount) .

Just moved to this integration:
https://github.com/davidrapan/ha-solarman
The update interval is 5 seconds and works well.


Add aws iam role and apply runner

Terraform plan in .

Error: this resource can only be used in the context of an organization, "coyotespike" is a user
Error: this resource can only be used in the context of an organization, "coyotespike" is a user

  with module.members.github_membership.membership_for_christie,
  on github/members/members.tf line 2, in resource "github_membership" "membership_for_christie":
   2: resource "github_membership" "membership_for_christie" {

Error: this resource can only be used in the context of an organization, "coyotespike" is a user

  with module.members.github_membership.membership_for_tim,
  on github/members/members.tf line 6, in resource "github_membership" "membership_for_tim":
   6: resource "github_membership" "membership_for_tim" {

Error: this resource can only be used in the context of an organization, "coyotespike" is a user

  with module.members.github_membership.membership_for_aj,
  on github/members/members.tf line 10, in resource "github_membership" "membership_for_aj":
  10: resource "github_membership" "membership_for_aj" {

:x: Failed to generate plan in PR Plan #5


Golang math.Round() doesn't likely naturally implement Banker's Rounding, Need Custom Implementation

@pwdel does this package support the rounding style you're referring to: https://pkg.go.dev/github.com/Rhymond/go-money
Round() method: https://pkg.go.dev/github.com/Rhymond/go-money#Money.Round


Fix | Support Georgian collation

fixes #2182
Adds support Georgian collation with code page 1252.

@DavoudEshtehari Thanks from Georgia!


Fixed value assignment of id variable

Purpose or Intent
This bug was introduced in https://github.com/ManageIQ/manageiq/pull/9423, changes at:
https://github.com/ManageIQ/manageiq/pull/9423/files#diff-e9876bc0951cc0bfad5b083d90d726efR1 & https://github.com/ManageIQ/manageiq/pull/9423/files#diff-c81c325b15df3f6deb16b0ebe7592ed2R1 were causing id to be set as "" in absence of @record.id, changed code to set id to "new" when @record does not have id set(for new records).
Steps for Testing/QA
Add a new Service Dialog, add a tab/box/element of TextBox type, then try to add a default value for textbox, this should throw an error.
Fixes #9862
@mkanoor please review/test.
@dclarizio please review.

@eclarizio Please review

👍

I think this is fine, though the rubocop errors bothered me so I looked and we already have url defined in the _dialog_field_form.html.haml. Why don't we just pass that in as a local to the two hamls here?

@eclarizio made suggested changes.

:+1:


Meeting 2020-10-29

Previous meeting: #62
Time: 17:00 CET
Where: #rust-gpu voice channel on Ark Discord.
Agenda
(please edit/add)

@khyperia project update
@termhn has officially joined!
How does open source feel so far?
How do we think it is going towards converting most Ark shaders by December?

tech discussions, not everyone required:

spirv-builder for single crate with multiple shaders, i.e. example-shaders crate that @repi has mentioned - @termhn
Related to #45, input/output/binding model to use for converting ark shaders? - @termhn
#128 bikeshed names (timeboxed) - @khyperia
#164 and #167 - documentation of unsupported-ness? (will add proper tests soon) - @khyperia
glam status update (any compiler support needed? any new thoughts on #81?) - @repi
how do we intend other repos (like Ark or Bevy) to use the rustc backend and crates - @repi
#164 - what spir-v version do we target by default? currently 1.3 by arbitrary choice (intel_compute_runtime only supports <=1.3) @khyperia
#45 - I've completely forgot what we decided re: moving Output to return value, I'm leaning towards not implementing this (just waiting for binding rfc), is that okay? - @khyperia

Meeting notes
Participants

@repi
@khyperia
@VZout
@Jasper-Bekkers
@arirawr
@XAMPPRocky
@termhn
@Jake-Shadle
Additional guests from Discord, first open meeting!

Minutes
How did the open sourcing go / feel?

"Only happy good feelings!" 💖

@arirawr: Very positive, quite happy!

@repi: Been awesome to see the positive response & interest, more than I expected!

Discord channel got very busy and a bit chaotic first

But looks like it is calming down a bit, continue to discuss bigger things in issues
If needed could split rust-gpu channel into "#rust-gpu-users" and "#rust-gpudev" channels
Or move more general discussions into the "#opensource" channel?

Lots want compute shaders

Probably from the wider Rust community, not graphics community
Will be supported, but graphics is first
Filed #180

Some setup problems for new users

Unknown GPUs, Vulkan setup, complex Linux
Let's at least document what we use and focus on as guideline for other devs.
Let's start on a FAQ / base requirements listing for the book. @XAMPPRocky filed #177

Converting our Ark shaders

@termhn will start converting our basic engine shaders from GLSL to Rust GPU!

Binding model will be one of the challenges

@khyperia: Not confident that can implement the new binding RFC-001 anytime soon
But can start using use the current system!

We have binding & location
Don't have textures & sampler types

Phased approach:

Find first simple graphics shaders to convert (mesh shader)

May need some smaller compiler support & fixes
Strip out Multiview extension support in our shaders? Or add it

Shaders with textures & bindings
Compute shaders

Put all of our shaders in a single ark-shaders crate with multiple entrypoints, already supported!

"Don't name everything after spirv" (#128)

Compiler backend and code generation is for SPIRV compiler, so target will remain SPIRV and low-level things named for it.

Eventually compiler may support other outputs or be more general GPU-related and could rename then, but don't want to do it now, too early and speculative.

Higher-level or more user-facing aspects can called "shader" or "GPU", but most will likely just be cross-platform Rust code (like glam)

SPIRV support before 1.3 (#164), and OpenGL (#167)

How much do we support, what are our tiers?

Too early to define proper tiers, but can do later on similar to Rust (but quite complex due to OS / driver / vendors)

Define what we (Embark) support and care about, what we will use in Ark in the short- & mid-term

Could have optional not-fully supported other targets from community, like OpenGL support

What happens when we require Vulkan memory model, require or make it optional? For now it is based just on our own needs, have to be able to move fast.

Define in the book what we are currently focus on so it is more clear for everyone what should work and is a priority

Vendors, capability levels, drivers and operating systems
File new issue and discuss, @XAMPPRocky filed #177

Decision: Staying & focusing on SPIRV 1.3 by default

Glam update (#134)

@repi: Made some really good progress, our shaders are working with it now on both CPU and GPU!

Some clippy issues remaining, may skip

How to expose further intrinsics and SPIRV specifics? 3 levels/approaches for it:

core::intrinsics::* - Rust core intrinsics, these are easy to map 1 to 1 with SPIRV intrinsics and we do this already
libm replacement - for f32 functionality missing in core::intrinsics

implement using Rust libm and replace in compiler backend with SPIRV intrinsics.
glam no_std CPU is using libm also (https://github.com/bitshifter/glam-rs/issues/5, branch)

unknown - for SPIRV intrinsics we want to use that neither core::intrinsics nor libm implements.

@JasperBekkers will file issue and start listing what intrinsics we want to use

@khyperia: Should we pursue the libm replacement as next step?

Required for glam tan
Decision: yes

Do we also have a f32x4 "built-in" simd type?

Decision: No for now, not needed as any crate can define their own instead

How to build & distribute rustc_backend_spriv for other repos?

Our spriv-builder is the easiest, is used today already but some issues with "Cargo in Cargo"

Can have separate shader folder and .cargo/config to build for right target with. @repi been doing this locally and nice with no "Cargo in Cargo" issues and works with more tools.

Ideally want to just cargo install the backend, or long term on have it part of rustup & Rust in general

@Jake-Shadle Can't do cargo install for dylibs/dlls today, that would have been nice

Could be solved, insert issue link
Or have a wrapper binary program
Or add support in Cargo/rust for it in cargo/rustup

@khyperia Another option is to to have a wrapper rustc.exe that includes and uses our backend and calls the real rustc

We'll discuss and experiment further but have a few approaches that can work

Other

@VZout: While loops are now in! 🎉 #

Decision: And not going to move input/output values (#45)


Download phar based deployer into vendor/bin/dep

Q
A

Issue Type
Feature Request

Deployer Version
All

Local Machine OS
All

Remote Machine OS
All

Description
I am not sure if something like that is already possible but IMO it would be good to have ability to require as composer package a phar based version of deployer which would be downloaded into ./vendor/bin.
I know I can do "composer require deployer/deployer" and it will do symlink to ./vendor/bin/dep but "deployer/deployer" depends on lot of packages and I do not want to include them in main project.
So having smth like "composer require deployer/deployer-bin" which will not depend on anything and make ./vendor/bin/dep would be the best option.
This solves at least few problems people face today:

If the deployer is installed globally then if I use deployer in versions 3,4,5 then I need to create 3 different symlinks and use it like for example "dep4 deploy live" on one project and  "dep3 deploy live" on second. Additionally I need to remember which deployer version is used in project I work in.

If I want to use "deployer/deployer" as composer package then it loads lot of dependencies into project which can bring conflicts.

What do you think ?
I know I can make myself smth like below in my composer.json:
"scripts": {
    "post-autoload-dump": [
       "curl -LO https://deployer.org/releases/v5.1.3/deployer.phar && mv deployer.phar ./vendor/bin/dep && chmod +x ./vendor/bin/dep"
    ]
}

but this will not update on "composer update" and other packages can not set dependency on strict version of deployer also.

I like your idea, really cool. I tried t configure composer to download phar but unsuccesful.
What about having something like deployer/deployer-phar or deployer/dist

If the deployer is installed globally then if I use deployer in versions 3,4,5 then I need to create 3 different symlinks and use it like for example "dep4 deploy live" on one project and "dep3 deploy live" on second. Additionally I need to remember which deployer version is used in project I work in.

If you have installed deployer globally and locally with composer, dep command will run locally installed version.

Created https://github.com/deployphp/distribution

Only auto update system left.

Great!!!
Installed / tested / works perfectly !!!
:smile: :smile:
I can take care of docs. Give me a notice if I should so we do not double the work.

@kszymukowicz ok, take care of docs (add section into installation.md) also if you can think about autoupdate system will be cool.

What do you mean exactly by autoupdate ?

After release of deployer. To don't run manually php update.

Auto update will implement myself.


feat(storage): add StorageClientInterface

Defining a StorageClient interface.
closes #24

I think we can move the implementation of StorageClientInterface to go-core as well. In the future we can handle other kinds of storage like S3, Blob Storage, GCS, NFS and so on...


Implements a new particle filter

The new filter achieves better performance on the unit test than the old filter did

@TrentHouliston You wrote half of this :stuck_out_tongue:  and missed the simple critical errors


About flutter_webview v0.3.16 ios platform multi-instance exception？

env:
       webview_flutter: ^0.3.16
       Flutter (Channel stable, v1.9.1+hotfix.6,on mac os x 10.14.6 18G103)
       xcode 11.2.1
       android studio (version 3.5)

problem:
1) Use the following code to find that the andorid platform is very smooth, but the iOS version release test is stuttered.
         2) Andorid platform can keep AutomaticKeepAlive successfully, but iOS platform cannot
         3) where index = 2 webview often fails to load the webview, and often the page text is misaligned and the scroll border is invalid
import 'dart:async';
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() => runApp(MaterialApp(home: WebViewExample()));
class WebViewExample extends StatefulWidget {
  @override
  _WebViewExampleState createState() => _WebViewExampleState();
}

class _WebViewExampleState extends State<WebViewExample> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Flutter WebView example'),
        actions: <Widget>[
        ],
      ),
      body: Builder(builder: (BuildContext context) {
        return ListView.separated(
          addAutomaticKeepAlives: true,
          addRepaintBoundaries: false,
          cacheExtent: 0,
          itemCount: 5,
          separatorBuilder: (BuildContext context, int index) => Divider(),
          itemBuilder: (BuildContext context, int index) {
            return getWebviewer(index);
          },
        );
      }),
    );
  }

  Widget getWebviewer(int index) {
    return Center(
      child: Container(
        width: 350,
        height: 300,
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.center,
          children: <Widget>[
            Text("number $index webview"),
            Expanded(
              child: KeepWebView(),
            ),
          ],
        ),
      ),
    );
  }

  @override
  void initState() {
    super.initState();
  }
}

class KeepWebView extends StatefulWidget {
  final String url;
  KeepWebView({Key key, this.url}) : super(key: key);

  @override
  _KeepWebViewState createState() => _KeepWebViewState();
}

class _KeepWebViewState extends State<KeepWebView> with AutomaticKeepAliveClientMixin {
  bool get wantKeepAlive => true;
  final Completer<WebViewController> controllerCompleter = Completer<WebViewController>();
  bool isFinished = false;

  @override
  void initState() {
    super.initState();
  }

  @override
  void dispose() {
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    super.build(context);

    return WebView(
      initialUrl:
          "https://flutter.dev/",
      javascriptMode: JavascriptMode.unrestricted,
      onWebViewCreated: (WebViewController controller) {
        controllerCompleter.complete(controller);
        print("on webview created");
      },
      onPageFinished: (String url) {
        print("on webview finished");
        isFinished = true;
      },
    );
  }
}

Hello @zhanghaigang666 !
Thank you for posting an issue.
Can you please also add the flutter doctor -v command output?

[✓] Flutter (Channel stable, v1.9.1+hotfix.6, on Mac OS X 10.14.6 18G103, locale
zh-Hans-CN)
• Flutter version 1.9.1+hotfix.6 at /Users/zhanghaigang/Flutter/flutter
• Framework revision 68587a0916 (3 months ago), 2019-09-13 19:46:58 -0700
• Engine revision b863200c37
• Dart version 2.5.0
[!] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
• Android SDK at /Users/zhanghaigang/Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling
support)
• Platform android-29, build-tools 29.0.2
• ANDROID_HOME = /Users/zhanghaigang/Library/Android/sdk
• Java binary at: /Applications/Android
Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build
1.8.0_202-release-1483-b49-5587405)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor
--android-licenses
[✓] Xcode - develop for iOS and macOS (Xcode 11.2.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 11.2.1, Build version 11B500
• CocoaPods version 1.7.5
[✓] Android Studio (version 3.5)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 41.1.2
• Dart plugin version 191.8593
• Java version OpenJDK Runtime Environment (build
1.8.0_202-release-1483-b49-5587405)
[!] VS Code (version 1.35.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
✗ Flutter extension not installed; install from
https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[✓] Connected device (1 available)
• UDwqewq • af8455030423f19150cf4b3f3d844b682a1c07b0 • ios • iOS 11.4

Hi @zhanghaigang666
Are you still experiencing this issue?
If so, can you please provide your flutter doctor -v and flutter run --verbose?
Thank you

Hi @zhanghaigang666
Without additional information, we are unfortunately not sure how to resolve this issue. We are
therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the
bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Resolution 6 when a origin is selected only for impact layer

I've tried with res 9, but it seems like the API has restricted max resolution.


JBPM-4812 - Allow to query by task variables including Query API

depends on https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/107

merged into master

Thanks @mswiderski ! :)


Ability to sort the file tre

Is this a bug report or a feature request?
feature request
Reproduction Repo
If you think this is a useful feature, I started this PR
https://github.com/Raathigesh/majestic/pull/133

fixed in https://github.com/Raathigesh/majestic/pull/133


use object instead of np.object

From the xarray test suite:
DeprecationWarning: `np.object` is a deprecated alias for the builtin `object`.
To silence this warning, use `object` by itself. Doing this will not modify any behavior and is safe.
Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations

ref: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations

I don't think the failures are related...

@mathause Sorry for being so late to this.
Is it possible for you to sign the CLA? Our CLA bot should have sent you an email?

Also, we need to show some love to nc-time-axis to migrate it away from travis-ci... and that's not your problem, that's on us :+1:

I signed the CLA. Yes, I know there is constantly a tool to be updated...

@mathause Awesome, thanks.
I'm actively working on a pull-request to re-boot nc-time-axis CI et al. Once that's landed, you'll need to rebase.
I'll ping you here when we're good to go :+1:

Closed by #66


Bump node version packages

Bump node version
Bump package versions

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 32.92%. Comparing base (36e9921) to head (95dee28).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #88   +/-   ##
=======================================
  Coverage   32.92%   32.92%
=======================================
  Files          22       22
  Lines         489      489
  Branches       75       75
=======================================
  Hits          161      161
  Misses        318      318
  Partials       10       10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


sfdx force:org:beta:create doesn't assign aliases

Summary
sfdx force:org:beta:create does not properly assign the alias it is given via flag.
Steps To Reproduce:
Repository to reproduce: dreamhouse-lwc
(Verified it was reproducible with dreamhouse)

Run command sfdx force:org:beta:create -t scratch -a dreamhouseScratchBetaTest -f config/project-scratch-def.json -v DEVHUB-ALIAS -d 1 --wait 60
After beta create command finishes, run sfdx force:org:list. The scratch org shows up without the defined alias.

Expected result
Expected the scratch org to get assigned with the alias given, and being able to approach the scratch org using said alias in other sfdx commands.
Actual result
The scratch org is created without alias. No alias shows up in force:org:list, and other commands (force:org:open, force:org:delete, etc.) do not respond to the alias either.
Scratch orgs made with the old force:org:create command with identical flags do get their alias assigned correctly.
System Information
This error is being encountered both on local computer, as well as when running a build using CI tooling for a project.

Which shell/terminal are you using?  (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)
Local computer: bash & cmd
CI builds: TeamCity using Runner type: 'Command Line'

If you are using sfdx

Run sfdx version --verbose --json

If you are using sf

Run sf version AND sf plugins --core

Paste the output here

Local Computer:
{
        "cliVersion": "sfdx-cli/7.159.0",
        "architecture": "win32-x64",
        "nodeVersion": "node-v16.15.1",
        "pluginVersions": [
                "@oclif/plugin-autocomplete 0.3.0 (core)",
                "@oclif/plugin-commands 1.3.0 (core)",
                "@oclif/plugin-help 3.3.1 (core)",
                "@oclif/plugin-not-found 1.2.6 (core)",
                "@oclif/plugin-plugins 1.10.11 (core)",
                "@oclif/plugin-update 1.5.0 (core)",
                "@oclif/plugin-warn-if-update-available 1.7.3 (core)",
                "@oclif/plugin-which 1.0.4 (core)",
                "@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)",
                "alias 2.1.0 (core)",
                "apex 1.1.0 (core)",
                "auth 2.2.2 (core)",
                "community 2.0.0 (core)",
                "config 1.4.14 (core)",
                "custom-metadata 2.0.0 (core)",
                "data 2.0.4 (core)",
                "generator 2.0.2 (core)",
                "info 2.0.1 (core)",
                "limits 2.0.1 (core)",
                "org 2.0.2 (core)",
                "salesforce-alm 54.6.2 (core)",
                "schema 2.1.1 (core)",
                "sfdx-cli 7.159.0 (core)",
                "signups 1.2.0 (core)",
                "source 2.0.7 (core)",
                "telemetry 2.0.0 (core)",
                "templates 55.0.0 (core)",
                "trust 2.0.1 (core)",
                "user 2.1.0 (core)"
        ],
        "osVersion": "Windows_NT 10.0.19043"
}

CI builds:
{
	"cliVersion": "sfdx-cli/7.159.0",
	"architecture": "linux-x64",
	"nodeVersion": "node-v16.15.1",
	"pluginVersions": [
		"@oclif/plugin-autocomplete 0.3.0 (core)",
		"@oclif/plugin-commands 1.3.0 (core)",
		"@oclif/plugin-help 3.3.1 (core)",
		"@oclif/plugin-not-found 1.2.6 (core)",
		"@oclif/plugin-plugins 1.10.11 (core)",
		"@oclif/plugin-update 1.5.0 (core)",
		"@oclif/plugin-warn-if-update-available 1.7.3 (core)",
		"@oclif/plugin-which 1.0.4 (core)",
		"@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)",
		"alias 2.1.0 (core)",
		"apex 1.1.0 (core)",
		"auth 2.2.2 (core)",
		"community 2.0.0 (core)",
		"config 1.4.14 (core)",
		"custom-metadata 2.0.0 (core)",
		"data 2.0.4 (core)",
		"generator 2.0.2 (core)",
		"info 2.0.1 (core)",
		"limits 2.0.1 (core)",
		"org 2.0.2 (core)",
		"salesforce-alm 54.6.2 (core)",
		"schema 2.1.1 (core)",
		"sfdx-cli 7.159.0 (core)",
		"signups 1.2.0 (core)",
		"source 2.0.7 (core)",
		"telemetry 2.0.0 (core)",
		"templates 55.0.0 (core)",
		"trust 2.0.1 (core)",
		"user 2.1.0 (core)"
	],
	"osVersion": "Linux 5.4.0-110-generic"
}

Additional information

Am encountering this error both on local computer, as well as when running builds using CI tooling for a project.

Screenshot of created scratch org lacking an alias:

yep, we just fixed this yesterday (thanks for the report, though!).  You can try/confirm by running
sfdx plugin:install org
and then sfdx plugins:uninstall org to get back to your normal CLI setup.

Can confirm setting aliases works with the newer org plugin, thank you!


demo is down

What is your question / Please describe your issue
hey guys,
i am exploring how fast is bagisto headless, so pretty pumped for this demo
but it looks down
What version of bagisto integration are you using?
1.0
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi @a7medo778
VSF demo is working now.
https://demo.bagisto.com:2087/


Add more Kombu and Celery type hints

Got another round of additional type hints to add that are missing for my use cases. Thanks!

@sbdchd Any chance you can take a look at my PR? I'm in no rush so if you aren't free that's ok. Also if your happy with these changes and would like to merge them, could you also create a new release of the project and publish it to PyPi so I can use them? Thanks in advance!

Oh sorry missed this! thank you for pinging

Also re the new release, I really need to automate that but haven't gotten around to it yet


Security Warning when installing plugins

Describe the bug
During initial setup of Eclipse, when installing the IDE plugins, Eclipse gives a security warning.
To reproduce the bug
Steps to reproduce the behavior:

In Eclipse, open the Install Wizard via the menu Help > Install New Software...
In the Work with: field, enter the URL of the Update Site for the plugin, given in brackets below.
Select the plugins you want to install, and install it with the help of the wizard.
See error

Expected behavior
Probably normal behavious, but irritating when installing the development environment.
Screenshots

Desktop (please complete the following information):

Operating System: Windows 10
Hexatomic Developer & Maintainer Documentation v0.4

Additional context
Add any other context about the problem here.

Solved with PR 298


path problem : NameError: name 'file' is not defined

I'm a new learning PyG currently.
I'm trying to use MNISTSuperpixels data for graph convolution, but I have some troubles using the example code.
Most of scripts were using
path = osp.join(osp.dirname(osp.realpath(__file__)), '..', 'data', 'MNIST')
However, they gave me an error
NameError: name '__file__' is not defined
I'm using Jupyter notebook on Ubuntu, and my working directory is
print(os.getcwd())
/home/hkimlx/GDL/pytorch_geometric/examples

which is the same directory where mnist_nn_conv.py is located.
I cannot load the dataset because of those problems here I think.
import os.path as osp
import torch
import torch.nn as nn
import torch.nn.functional as F
from torch_geometric.datasets import MNISTSuperpixels
import torch_geometric.transforms as T
from torch_geometric.data import DataLoader
from torch_geometric.utils import normalized_cut
from torch_geometric.nn import (NNConv, graclus, max_pool, max_pool_x, global_mean_pool)

path = osp.join(osp.dirname(osp.realpath(__file__)), '..', 'data', 'MNIST')

transform = T.Cartesian(cat=False)
train_dataset = MNISTSuperpixels(path, True, transform=transform)
test_dataset = MNISTSuperpixels(path, False, transform=transform)
train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)
test_loader = DataLoader(test_dataset, batch_size=64, shuffle=False)
d = train_dataset

Please help me. Thanks!

I solved the problem. I should have download MNISTSuperpixel and locate it to /data/MNIST/raw/ .


eq-1374 Revisit stylelint rules

What is the context of this PR?
Tightens up stylelint rules:

made stylelint actually work again 😯
switched to gulp-stylelint
disallows use of !important
no ids as selectors
4 levels of specificity on classes (this is too much but would require too much refactoring to fix)
1 level of specificity using tag names as selectors
double-quotes everywhere
removed unused prism library css
moved vendor folder out of components

NOTE: some changes are from my editor formatting stuff
How to review
This shouldn't introduce and styling changes but it's worth running through a survey to be sure.

@bennpearson worked for double quotes with me, and then when i changed to single quotes threw up lint errors


Closes #141

Don't call methods with empty currentId (it's empty if jasmine/startedConsumer failed or not exists)

Thanks. Actually the calls can be removed completely. I just have missed it in https://github.com/Sanjo/meteor-jasmine/commit/ed3ffafe632f1074f796f65b50314db6008e9a77.

Fixed by https://github.com/Sanjo/meteor-jasmine/commit/5d6eceeda63378734a9ce86dc7ec390de84177c4.


OLS-254: Return response immediatelly to avoid type confusion

Description

Return response immediatelly to avoid type confusion
Identifier llm_response was used in two context (totally different). That causes type checkers to identify type errors that were forcefully ignored by #type ignore comment. It is not needed now.

Type of change

[x] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #OLS-254

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

/lgtm

/approve


Docker busted from 1.9.0

Also in 1.10.0.
docker run --rm -it -v /Users/jwr003/coding/audio_program_generator/apgfiles:/audio_program_generator/apgfiles audio_program_generator:1.10.0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'audio_program_generator.__main__'
make: *** [apg] Error 1

Fresh repo pull of 1.10.0 and following instructions to the letter resulted in the docker build working just fine. Closing.


Add list widget

Can we add list widget? example here https://github.com/gizak/termui/blob/master/_examples/list.go

Thank you @CaramelHeaven, I think that is a good idea. Contributions are welcome.


Change an rviz_ogre_vendor dependency to libfreetype-dev.

The situation is complicated, but in versions of Ubuntu prior to Focal and versions of Debian prior to Bookworm, the name of the library was 'libfreetype6-dev'.  Since Focal and Bookworm, the name of the library is 'libfreetype-dev'. While 'libfreetype-dev' provides a "virtual package" for 'libfreetype6-dev', we should really use the new canonical name.
Further, there is currently a bug on ros_buildfarm where it doesn't properly deal with "virtual packages" like this. This is currently preventing this package from building on Ubuntu Noble.  That bug is being worked on separately.
Finally, I'll note that we already have a libfreetype-dev key in rosdep, so we just switch to using that here which should work around the bug on the buildfarm, and also use the correct canonical name going forward.

CI:

Linux
Linux-aarch64
Windows


docker build with several --tag options depends on tags order

There is a difference between
$ docker build --tag name --tag registry:5000/name .
# <- only 'registry:5000/name' tag created, 'name' tag NOT created

and
docker build --tag registry:5000/name --tag name .
# <- both 'registry:5000/name' and 'name' tags created

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

This is because -t does not accept multiple entries.
It's really only ever tagging 1 image both times (should be the last one specified).
In your test you've already created registry:5000/name in the first run, and the 2nd run tags name
Note that docker 1.10 will accept multiple entires for --tag.

@cpuguy83 Great! Thank you. I thought it was released in 1.9 already.

PR is here; https://github.com/docker/docker/pull/15780


Make FreeCEN Newsletter Available to Researchers.

It has been suggested that we need a menu item for researchers to download a copy of our Newsletter. This could be in the purple bar at the top of the researchers search page.
Chris could upload each newsletter here as a pdf and members of the public could then click on the link and open the pdf on their screen.
This increases our public profile and encourages interested researchers to regularly come back to our site. Some may eventually become volunteers.

Island on About page, below sidebar, linking to a Newsletter page containing the last 12 PDFs

I will speak to Alison about making this happen

@cmahoneynz
Chris
This was discussed at the last scrum. It is proposed that we give access to researchers via the purple menu bar at the top of the page so that researchers can read the Newsletter.
It is proposed that we make a rolling set of twelve (one year) of Newsletters available. They would be in pdf format (unless Alison has an alternative plan).
What are your thoughts?
Geoff

@cmahoneynz
Chris
Contrary to my message above, this is the proposed position of the Newsletter link.
Geoff

Accessing via the purple menu bar would work as long as it is somewhere people are going to notice it.
They currently go out in PDF as most people regardless of type of computer/device they have can read such files so best to keep in this format.  As to how far back they should go, not sure on this one.  Whatever we decide, there will always be someone who wants to go further (I still have the full set of all the ones done).
One thing I would add to the newsletter page is an option for people to sign up so they can receive them.

Chris
It will unfortunately be under the About tab. The purple bar is being reconfigured to match a new FreeUKGenealogy image.
I have asked that a message be included on the Search screen to make people aware that the Newsletter is there.
Geoff
From: Chris Mahoney @.>
Sent: Sunday, August 27, 2023 11:11 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: Geoff J @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Make FreeCEN Newsletter Available to Researchers. (Issue #1554)
Accessing via the purple menu bar would work as long as it is somewhere people are going to notice it.
They currently go out in PDF as most people regardless of type of computer/device they have can read such files so best to keep in this format. As to how far back they should go, not sure on this one. Whatever we decide, there will always be someone who wants to go further (I still have the full set of all the ones done).
One thing I would add to the newsletter page is an option for people to sign up so they can receive them.
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1554#issuecomment-1694536900 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFNEISSRH3NRKEXBTBTXXKNBVANCNFSM6AAAAAA2YJ2CDI .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFPU5QQDWBFIWCHSZELXXKNBVA5CNFSM6AAAAAA2YJ2CDKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTFACKMI.gif Message ID: @.*** @.***> >

Some comments:

the PDF format is not accessible unless someone has gone great lengths to make it so
the main (lavender) menu has limited space and is for top-level links — the newsletter does not count as a top-level link
if @cmahoneynz is prepared to keep it up to date, there will be a link to the listing on the About page (I fail to see that as "unfortunate")
from what I understand about project priorities and possibilities, a sign-up for Researchers seems unlikely for the present

Alison
For each of your comments:

the PDF format is not accessible unless someone has gone great lengths to make it so – Chris already produces his Newsletter in pdf format so it is already available.
the main (lavender) menu has limited space and is for top-level links — the newsletter does not count as a top-level link. – Understood, that is why it will be under the About menu. However a pointer will be needed somewhere s that researchers know it is there.
if @cmahoneynz https://github.com/cmahoneynz  is prepared to keep it up to date, there will be a link to the listing on the About page (I fail to see that as "unfortunate") – He already has the Newsletter and he is prepared to maintain the publications.
from what I understand about project priorities and possibilities, a sign-up for Researchers seems unlikely for the present. – Agreed. We cannot ‘value add’ for signed up researchers so it is not a viable option.

Geoff
From: AlOneill @.>
Sent: Monday, August 28, 2023 12:00 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: Geoff J @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Make FreeCEN Newsletter Available to Researchers. (Issue #1554)
Some comments:

the PDF format is not accessible unless someone has gone great lengths to make it so
the main (lavender) menu has limited space and is for top-level links — the newsletter does not count as a top-level link
if @cmahoneynz https://github.com/cmahoneynz  is prepared to keep it up to date, there will be a link to the listing on the About page (I fail to see that as "unfortunate")
from what I understand about project priorities and possibilities, a sign-up for Researchers seems unlikely for the present

—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1554#issuecomment-1694676270 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFPVLVBQIF55OJGFOR3XXNHGNANCNFSM6AAAAAA2YJ2CDI .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFLCWXW4ANQQM5C3VYLXXNHGNA5CNFSM6AAAAAA2YJ2CDKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTFAK2S4.gif Message ID: @.*** @.***> >

@geoffj-FUG
I think we are at cross-purposes: by 'accessible' I do not mean available but rather suitable for all users, regardless of disability. This would include those who use a screen reader and users who move around a page using only the keyboard, for example.
@cmahoneynz will be maintaining the webpage with the download links (I will set it up initially) i.e. he will need to upload each new newsletter and then put a link to it on the 'Newsletter' page, deleting the oldest link at the same time. The Newsletter page will be a child of the 'About' page and will be clearly signposted on 'About'.
Any other mentions are beyond my remit and control.

Suggestion: link to page could be placed in line with "News about Free UK Genealogy" in footer, additionally.
E.g. News about Free UK Genealogy | News about FreeCEN (order could be either way around)

Why not make it a rollover menu?
News about FreeCEN ... Display sub menus FreeCEN  FreeBMD   FreeREG  FreeUKGenealogy.
Geoff


Added a fallback download method for geckodriver

It should fix #2, which caused by the rate api limit exceeding. In the case when the limit exceeded the downloader uses a fallback method where it parses https://github.com/mozilla/geckodriver/releases page.

if you could extend the changes to also cover opera - as it is also hosted in github - i would take the pr with a smile into my fork. As it doesnt seem to be possible to get pr's into this project.

if you could extend the changes to also cover opera - as it is also hosted in github - i would take the pr with a smile into my fork. As it doesnt seem to be possible to get pr's into this project.

Is your fork public?  Do you think your fork should be submitted to PyPI?


Multiple runners on the same machine fail

Hello. The problem is this:

installed 6 runners on the same machine
all 6 got connected and ready for jobs
when the workflow started, they all failed
error: package.json not found

From the looks of it, only one managed to download the repo it was supposed
to build on, the rest failed and continue to fail.
It seems the repo gets deleted for some reason from the /_work/ folder
What may cause this and what is the fix?
Thank you

Hi,
The _work subfolder is maintained by GitHub self-hosted runner app it self, which "Don't need to have a clean instance for every job execution". Did you checkout your code every time in your workflow file, such as:
    steps:
      - uses: actions/checkout@v4

Hey. The problem was with the subflows.
If anyone is interested, the flows must be complete in order for each runner to
know what they are doing.
There are 2 options for this:

to speed up things with caching, use artifacts
write the entire flow so when fresh runner picks up a new job, it has all the info


Adopt Laminas CI workflow

Rebase done, now an approval is needed

The build fails on locked runs for PHP prior to 7.4.
I've indeed committed composer.lock after updating it on PHP 7.4.
What should I do @boesing ? Generate a lock for by PHP 5.6? I'd prefer remove it altogether, I don't see how it can help on such a wide range of PHP versions that, ndr, compile good on both lowest and latest

@Slamdunk drop support for PHP <7.3
I don't think that I'll create a new release just with the GHA added, so we can wait until we implement #3
Thats what I did in almost all other cache adapters.

Oh by the way, please remove the markTestSkipped from the test cases so we can verify that we are actually testing anything. Due to the CI output, all tests are actually skipped.
You may have a look at how I've done that for the redis adapter:
https://github.com/laminas/laminas-cache-storage-adapter-redis/blob/237fbc02ee4c5eeb6ef8fe7e3bf6ec55ef99f422/.github/workflows/continuous-integration.yml#L26
https://github.com/laminas/laminas-cache-storage-adapter-redis/blob/237fbc02ee4c5eeb6ef8fe7e3bf6ec55ef99f422/.github/workflows/continuous-integration.yml#L41

I saw testBinaryData is skipped in other adapters, we can then skip it here too if you agree

I've never used mongo aswell ;-)
I've created #1 months ago to fix that BSON problem but as it is not fixed at the moment, I would dev-require that version which was used in travis as the highest version.
After this, we create a feature PR where we are supporting old and newer versions of the extension.
So to achieve that the proper extension version is installed, we have to use PECL.
I've added a PR to the CI Action a few weeks back to support pecl on CLI.
So what we have to do is:

remove mongodb extension from the .laminas-ci.json
create a mongodb-extension-installer.sh under .laminas-ci/
add that file to the pre-install.sh
Implement switch/case to that file and use pecl to install specific versions of the mongodb extension

Doing this, we can ensure that we create the same "deps" as done in the travis build.
This way, we can add support for newer pecl extension versions easier.
Maybe, we use latest pecl version for e.g. the latest PHP version we support (e.g. PHP 8), but thats just an idea.

Maybe #1 can help to make some tests pass as I've experienced issues in v1.0.0 already but that version was meant to be a 1:1 copy of the original laminas-cache code.

Gosh I completely missed this reference :sob:

I've created #1 months ago to fix that BSON problem but as it is not fixed at the moment

What do you mean "it is not fixed at the moment"? This is the purpose of #1 a this PR, isn't it?

I would dev-require that version which was used in travis as the highest version.

I'm sorry I don't get this: "I would dev-require that version" of what?

After this, we create a feature PR where we are supporting old and newer versions of the extension.

mongodb/mongodb library already restricts ext-mongodb support:
https://github.com/mongodb/mongo-php-library/blob/df4e32cf506095ef03824638be88b6e06d6e8cc5/composer.json#L15
I think this is enough to let us ignore multiple ext-mongodb versions and only support latest one, isn't it?

I've added a PR to the CI Action a few weeks back to support pecl on CLI.

I miss the PR you are referring to :\

What do you mean "it is not fixed at the moment"? This is the purpose of #1 a this PR, isn't it?

Yes but that PR is kinda outdated. And this is why the bug is still present when mongodb/mongodb is used in v1.6.0+.
AFAIR, the mongodb/mongbd returned other types due to BC breaks and thus this component is not compatible with 1.6.0+ of mongodb/mongodb. I dont think we have to fix that in this PR.

I'm sorry I don't get this: "I would dev-require that version" of what?
mongodb/mongodb, for this PR, you might want to require that dependency <1.6.0 probably.

I miss the PR you are referring to :
https://github.com/laminas/laminas-continuous-integration-action/pull/20

I'm sorry I'm more confused than ever.

I dont think we have to fix that in this PR.

Why not? I mean, I understand we are looking for atomic PR, but as we decided to drop PHP <7.3, we might as well make it compatible with PHP >= 7.3

mongodb/mongodb, for this PR, you might want to require that dependency <1.6.0 probably.

Buy why? Why not simply have "mongodb/mongodb": "^1.8.0" in the require section?
Why should we test and support older versions when the latest one already passes the CI in all the PHP versions?

Why not? I mean, I understand we are looking for atomic PR, but as we decided to drop PHP <7.3, we might as well make it compatible with PHP >= 7.3

https://github.com/mongodb/mongo-php-library/releases/tag/1.5.0
That version is absolutely compatible with PHP 7.3 & PHP 7.4.

Buy why? Why not simply have "mongodb/mongodb": "^1.8.0" in the require section?

I think that would be indeed possible. But if you do that, we end up having an "CI Workflow" PR which does not simply add CI Workflow but drops support for older mongodb/mongodb versions.
But there is another concern I have: there might be projects which update this package and end up having another unused dependency just because we still require this package in laminas-cache. So thats why I struggle adding new dependencies to the 1.x version of the satellites.
This is why I've added conflict to the #1 PR rather than require that dependency, but I am actually not that familiar with all these dependency stuff in OSS.
Maybe @Ocramius has a view on this. I'd prefer having no new hard requirements for the satellites to avoid potential fuckups in upstream projects which do not even use this component.

But a concern I have: there might be projects which update this package and end up having another unused dependency just because we still require this package in laminas-cache. So thats why I struggle adding new dependencies to the 1.x version of the satellites.
This is why I've added conflict to the #1 PR rather than require that dependency, but I am actually not that familiar with all these dependency stuff in OSS.

Seems a correct concern and a good solution to me: what about a "conflict": {"mongodb/mongodb": "<1.8"} then?

what about a "conflict": {"mongodb/mongodb": "<1.8"} then?

That could be a way, but what if someone depends on that library in another use-case?
Well, we could ofc provide some guidance on how to remove this adapter from the project by using the guide:
https://github.com/laminas/laminas-cache/tree/2.11.x#avoid-unused-cache-adapters-are-being-installed
Sounds good enough to me. Go for it 👍🏼

Thanks @Slamdunk!
The only missing PR is PHP 8.0 support and then we're good to go 🎉
Great work here!

The only missing PR is PHP 8.0 support

It's already here https://github.com/laminas/laminas-cache-storage-adapter-ext-mongodb/pull/6/files#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R10

It's already here

🤦🏼♂ I definitely have to be more focused these days.


Add ability to publish to github pages.

[ ] Need to be able top publish to github pages.

done in https://github.com/typerefinery-ai/typerefinery-websight/commit/1743dc980e9546b9f24e36410d50da1341ba84be


[Feature Request]: Implementing Tarjan’s Algorithm in C++ under DSA folder.

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I propose adding the implementation of Tarjan’s Algorithm in C++ to the DSA (Data Structures and Algorithms) folder. Tarjan’s Algorithm is used to find strongly connected components (SCCs) in a directed graph. This algorithm is efficient and crucial for various graph-related problems.
Use Case
This feature would enhance the project by providing a robust method for identifying strongly connected components in graphs. For example, in applications involving network analysis, social network analysis, or any domain requiring the detection of strongly connected subgraphs, Tarjan’s Algorithm would offer a precise and efficient solution.
Benefits
Tarjan’s Algorithm provides an efficient way to identify strongly connected components, improving performance in graph-related tasks. The inclusion of this algorithm will help developers and students understand advanced graph algorithms and their applications.
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@Ajay-Dhangar sir, kindly assign me this issue under GSSOC'24.


Complete icon component tokens

This adds all missing icon styles to the Icon.json file, so all component tokens are available whenever new wikit-Icon pseudo classes are created.

This change seems ready to be reviewed. Is there a reason it's still e draft?
@SaiSan-WMDE

Shyness? 😅  I'm not sure anymore haha Happy to open it for review 😄

This change seems ready to be reviewed. Is there a reason it's still e draft?
@SaiSan-WMDE

Shyness? 😅  I'm not sure anymore haha Happy to open it for review 😄


ApiError documentation

Resolves #1727
The purpose of this PR is to improve documentation of ApiError and it's sub error types, and the error code mappings for them. For each variant, an integer value mapping is shown in a doctest.
ApiError's Debug impl also now try_froms the underlying error code to try to get more debugging for the user.

We have multiple, module-specific, errors with each documented individually. Would it be possible to have it (error documentation) statically-checked/generated and available in a single place? Products like cspr.live could integrate that "table" into their flow and present users with the human-readable interpretation of the error codes without having to parsing multiple files.

bors r+


Bugfix: Subscription attribute filter

closes #204

Codecov Report

Merging #211 (cc944aa) into main (3e87073) will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #211      +/-   ##
==========================================
+ Coverage   88.95%   89.02%   +0.06%
==========================================
  Files          31       31
  Lines        2680     2696      +16
==========================================
+ Hits         2384     2400      +16
  Misses        296      296

Impacted Files
Coverage Δ

goblet/deploy.py
88.47% <100.00%> (+0.10%)
:arrow_up:

goblet/resources/pubsub.py
92.30% <100.00%> (ø)

goblet/tests/test_pubsub.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Column mData defined as a function not working

With DataTables 1.10.3 and yadcf 0.8.4 when specifying datatable column's mData (or data) as a function, yadcf's appendFilters function throws an exception when it ends up trying to do split() on the function object here
A simple js that reproduces the issue:
$('#example').dataTable({
  data: [{}],
  columns: [
    {
     mData: function() { return "blah"; }
    }
  ]
})
.yadcf([
  {column_number : 0},
  ]
);

I'm not sure why the _aFilterData check is in it's own if-block so don't know if this introduces something new in another situation, but changing the code as follows fixes it for me:
            if (column_number_data === undefined) {
              col_inner_data = data[j]._aData[column_number];
            } else if (data[j]._aFilterData !== undefined && data[j]._aFilterData !== null) {
              col_inner_data = data[j]._aFilterData[column_number];
            } else {
              col_inner_data = dot2obj(data[j]._aData, column_number_data);
            }

Hi! I've got similar problem on 0.8.9 version with latest DataTables 1.10.
I have next code
var table= $('#searchTable');
var tableSettings = [{
    "data": function (row) {
        var devId = row._source.hasOwnProperty('id') ? row._source.id : '';
        return '' + devId + '';
    }
}];
dTable = table.DataTable({
    data: results,
    "columns": tableSettings
})
yadcf.init(dTable, [{ column_number: 0, filter_type: "text", column_data_type: "html", html_data_type: "text" }]);

result is JSON object, received from elasticsearch.
But, every time I receive next error:
dot_refs.split is not a function
When I tried to debug, I found that in function dot2obj(tmpObj, dot_refs) variable dot_refs is a function from tableSettings, and this is reason, why it can't be splitted

Hi,
Please provide a jsbin sample to speed up the fix for this one.

Hi!
Here jsbin example

Hi! Any news?

Ohhh.....
You must remove the "searching": false, because when it is set to false no filtering will be possible in datatables at all, in addition you should change from
column_data_type: "html",
html_data_type: "text"

into
column_data_type: "rendered_html"
read docs about it...
p.s
see working sample


Update: shared-mime-info to 2.0

Thank you for your efforts in this library.
This solves the problem alluded to in:  #93, remedies the erroneous PR in #94, and also solves: #4,  #74, and also #49 in a more permanent way.
Please do review and let me know if there is something that can be fixed.
Ben

@janko
hi there Janko
If possible, is it possible to review and push to Ruby gems, because it attempts to fix a few bugs that are causing considerable consternation atm.
Am deeply grateful and thankful for the time you've put into open source.
rgds
Ben

Thanks, @benkoshy. We are also experiencing issues with #49 as well and found this PR that might work for us.
@janko any chance to look at this yet?

Thanks, @benkoshy. We are also experiencing issues with #49 as well and found this PR that might work for us.
@janko any chance to look at this yet?

(To be fair to Janko, who's not the maintainer of this library: I did speak presumptuously in asking Janko to merge it - given Janko's stupendous contribution to Open Source and also incidentally to Janko having admin rights to this library.
@leviwilson  What I've done is created a fork and my Gemfile points to that particular commit in that fork. such an approach might work for you, if you're having problems

(To be fair to Janko, who's not the maintainer of this library: I did speak presumptuously in asking Janko to merge it - given Janko's stupendous contribution to Open Source and also incidentally to Janko having admin rights to this library.
@leviwilson  What I've done is created a fork and my Gemfile points to that particular commit in that fork. such an approach might work for you, if you're having problems

I updated the database to 2.1

I updated the database to 2.1

@minad thanks; will there be a release soon?

@minad thanks; will there be a release soon?

@leviwilson Please give it a test if the current master version works and then I can publish a new release.

@leviwilson Please give it a test if the current master version works and then I can publish a new release.

@minad when I used @benkoshy 's branch, it was working for me.
In master I get this (we're using Rails / Paperclip)
/Users/levi.wilson/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/paperclip-6.1.0/lib/paperclip.rb:68:in `require': cannot load such file -- mimemagic/overlay (LoadError)

That's because https://github.com/thoughtbot/paperclip/blob/e3f7493b4cc954405a0209d26933830333ae2869/lib/paperclip.rb#L68 requires it here, but it's no longer in master because of the last commit.

@minad when I used @benkoshy 's branch, it was working for me.
In master I get this (we're using Rails / Paperclip)
/Users/levi.wilson/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/paperclip-6.1.0/lib/paperclip.rb:68:in `require': cannot load such file -- mimemagic/overlay (LoadError)

That's because https://github.com/thoughtbot/paperclip/blob/e3f7493b4cc954405a0209d26933830333ae2869/lib/paperclip.rb#L68 requires it here, but it's no longer in master because of the last commit.

Okay, I will publish the new version as 1.0.0.

Okay, I will publish the new version as 1.0.0.

@minad thank you; I've tried this version and it does NOT fix #49 like the branch @benkoshy has.
@benkoshy did you do something special to get #49 working?

@minad thank you; I've tried this version and it does NOT fix #49 like the branch @benkoshy has.
@benkoshy did you do something special to get #49 working?

@leviwilson You can check for differences of the table.rb generated from the shared-mime-info 2.0 with the version in master and the version generated by @benkoshy.

@leviwilson You can check for differences of the table.rb generated from the shared-mime-info 2.0 with the version in master and the version generated by @benkoshy.

@minad I guess I'm misunderstanding why this PR was closed if it closes those issues that were mentioned?

@minad I guess I'm misunderstanding why this PR was closed if it closes those issues that were mentioned?

The PR was closed because I regenerated the table myself from an even newer version 2.1 instead of 2.0 as in this PR. In case you want to check, you can use a shared-mime-info package from https://www.freedesktop.org/wiki/Software/shared-mime-info/.

The PR was closed because I regenerated the table myself from an even newer version 2.1 instead of 2.0 as in this PR. In case you want to check, you can use a shared-mime-info package from https://www.freedesktop.org/wiki/Software/shared-mime-info/.

@minad thank you; I've tried this version and it does NOT fix #49 like the branch @benkoshy has.
@benkoshy did you do something special to get #49 working?

From memory i just updated the database.  The upstream database had incorporated a PR which solved the problem.  Unless there's a reversion in 2.1?

@minad thank you; I've tried this version and it does NOT fix #49 like the branch @benkoshy has.
@benkoshy did you do something special to get #49 working?

From memory i just updated the database.  The upstream database had incorporated a PR which solved the problem.  Unless there's a reversion in 2.1?

@benkoshy there must be a reversion, but I'm having a difficult time spotting what that would be.
All I know is:

master doesn't work for #49 for me
#95 does resolve #49 for me

I pulled both locally (master and git fetch origin pull/95/head:shared-mime-info-2.0) and did a diff looking for pdf / zip but nothing popped out to my untrained eye to spot the differences.

@minad would there be issues with merging this MR (with the 2.0 update) independently of the 2.1 update and then also releasing that?
I'm not able to spot the difference why there would be a regression, but it would be nice to be able to choose this version for the PDF changes (that are being misidentified as ZIP in #49).

This does not sound like a robust long-term solution to me. It is better to figure out the issue. Then I can make a new release.

@minad understood...and advices towards being able to do so?
I've done some custom mime magic before in our application regarding office documents, but I'm not seeing the PDF problem (the difference between 2.0 and 2.1).
I'd share a file except the ones I have contain sensitive information. The one in this branch I can test to see, though, how it responds.

I am also not sure what the issue is here. I suggest you debug the issue with the relevant files and look into which of the matchers detects the file.

@leviwilson hey Levi,
I've updated my local branch to the latest changes in upstream/master, and cannot reproduce the problems with zip files being incorrectly identified, given the test fixtures i added before. i cannot be sure of what is causing your particular problem at your end.

@benkoshy gotcha, thanks for the follow up. I'll keep digging then. In my case, it's a ZIP file of PDFs.


[OPTIMIZE] #272: Move click handling from Adapters

Softagram Impact Report for pull/4 (head commit: 617faced9e34)
:star: Change Overview

(Open in Softagram Desktop for full details)

:page_facing_up: Full report

Permalink: Full report for pull/4

Impact Report explained. Give feedback on this report to<EMAIL_ADDRESS>


[serverless-init] Add wait in signal handler of serverless-init process

What does this PR do?
Added a wait inside the signal handler so that the init process waits for the child to exit instead of immediately exiting.
(replace https://github.com/DataDog/datadog-agent/pull/17127 so CI can start)
Motivation
Fixes #17124.
Additional Notes
This wait was necessary even though there is a wait in the main process because as soon as the signal is received by the main process, the wait in main process exits.
Describe how to test/QA your changes
Setup the serverless-init container with a CMD process and try to send a SIGTERM signal to the container. It should wait for the CMD process to exit and then the init process should exit.
Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

I've been pointed to this issue from datadog support. This is impacting our ability to monitor google cloud run jobs, and would be very appreciative if this could receive a review & be released

Hi @maxday, is there any update on when we can expect this to be merged and released?

Hi @ollz272
Actually this fix has already been merged and released here: https://github.com/DataDog/datadog-agent/pull/17127/files
Since it does not seem to fix your issue, we need to spend a bit more time on this.
Thanks for your patience