Type Expected due to : in environment.ts file

yarn install is giving compile time error due to the extra ":" in the environment.ts file.

This issue is the same as https://github.com/devonfw/cobigen/issues/1261


how do i use this

how to use this plugin

You need to specify your question...
Otherwise have a look at the README.md.


Allow deleting of ports

It's possible I missed something, but I accidentally clicked the add port mapping button when deploying a container when I didn't need it, but had no way to  remove it, so I had to set it to something bogus.  It would have been much nicer if I could have just deleted it.

:+1:

This is fixed in the v3 ui.  Closing.


Add @goodwanghan, @kvnkho, @charlesbluca as recipe maintainers?

Comment:
Hi @thewchan,
First of all, thanks for your active maintenance on this feedstock 😄
I'm reaching out to ask if it would be possible to add @goodwanghan (creator of Fugue project), @kvnkho (core maintainer on Fugue), and I (maintainer of dask-sql, a closely related project) as maintainers for this recipe? I'm hopeful that this would significantly ease the burden you've taken on of modifying the recipes for each release, as well as make it easier to coordinate releases between PyPI and conda-forge.
Making this request across the feedstocks for fugue, qpd, and fugue-sql-antlr, which to my knowledge are the main packages which Fugue depends on (though @goodwanghan or @kvnkho can correct me if I'm wrong).

I was thinking of making this request too! Thanks for beating me to it and thanks for working on this @thewchan!
That is right but also:
triad - https://github.com/conda-forge/triad-feedstock/
adagio - https://github.com/conda-forge/adagio-feedstock
which are utilities for fugue.  Don't know if you want to be included there as well @charlesbluca

@charlesbluca @kvnkho Happy to add you all; just note that updates on Conda Forge is automatically generated when the upstream release is made, is the burden is minimal.

Don't know if you want to be included there as well @charlesbluca

Yup I am cool with be included there as well 🙂

I'm not a maintainer of https://github.com/conda-forge/adagio-feedstock, so someone else will have to add you @charlesbluca.

I can take care of that I think! Not as knowledgeable as you here @thewchan but I'll give it a shot!


[CT-2489] [Bug] [python models] dbt.config doesn't work in conditional statement

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
I just found out that if else statement doesn’t work with dbt python models when it comes to dbt.config.materilized
if dbt.config.get("target_name") == "local_dev":
        dbt.config(materialized='table')
        print('dev')
else:
        dbt.config(
            materialized="incremental",
            submission_method="serverless"
        )

I’d get a print “dev”
but still tries to materialized in incremental, but won’t submit in serverless, which is absolutely strange.
Then, if I remove the bottom dbt.config then I’d get print “dev” and everything works normally.
Putting the condition as a ternary operator results in:
  In dbt python model, `dbt.ref`, `dbt.source`, `dbt.config`, `dbt.config.get` function args only support Python literal structures

Which I assume that this particular statement isn’t processed as python but maybe jinja / something else.
Expected Behavior
I can have multiple materialization configurations based on conditional statements.
Steps To Reproduce
if dbt.config.get("target_name") == "local_dev":
        dbt.config(materialized='table')
        print('dev')
else:
        dbt.config(
            materialized="incremental",
            submission_method="serverless"
        )

It would try to materialized in incremental mode
Relevant log output
No response
Environment
- OS: macOS Ventura
- Python: 3.9
- dbt: 1.4.6

Which database adapter are you using with dbt?
bigquery
Additional Context
No response

@kalanyuz Thanks for opening! You have the right idea here:

this particular statement isn’t processed as python but maybe jinja / something else.

We use Python's AST to statically analyze the inputs (source code if you're interested). We're limited in what we've implemented support for — really just literals.
You could accomplish this conditional configuration with Jinja-in-yaml instead:
models:
  - name: your_python_model
    config:
      materialized: "{{ 'table' if target.name == 'local_dev' else 'incremental' }}"
      submission_method: "{{ 'serverless' if target.name != 'local_dev' else ... }}"

@kalanyuz Just saw you opened an issue for those over in https://github.com/dbt-labs/dbt-bigquery/issues/680 - nice! That's less to do with parsing the configurations, and more to do with how we're submitting the Dataproc job to create the table, and needing to pass in those additional configurations.

Going to close this in favor of an update to documentation for now, making clear that dbt.config supports only literal inputs. Any more-complex expression (including ternary statements) are not supported.


Don't needlessly wrap everything in div's

It makes stylesheets a nightmare to develop.
For example here http://docs.mirage.io/odoc/ocaml/Scanf/index.html you have:

...

...

Not only does this divitis prevents me of writing simple css rules like (h6 + h6) the added tags are purely worthless.
Basically a mli rendered to html should be seen as a literate document where you a proper document interleaved with properly delineated formal definitions.
Also this div wrapping seems random. For example it doesn't appear here:
http://docs.mirage.io/odoc/react/React/index.html#basics
(where we do see however horrible br and lack of p (#10))

The div wrapping is not random, at least not the
 which we put around each "docstring".
Sometimes the docstring will containt only {6 Some title} explaining the

Some title

 as is the case on your first link, scanf.mli starts like this:
(** {6 Introduction} *)

(** {7 Functional input with format strings} *)

(** ... *)

While on the second example you have one big docstring which happen to contain some title in the middle ( https://github.com/dbuenzli/react/blob/master/src/react.mli#L821 ), explaining why there is no div around the h1 tag there.
I can nevertheless simply remove the div wrapping around toplevel docstrings (i.e. ones which are not attached to a particular node); I assume we want to keep the

...

...

structure you suggested in #23 , i.e. keep the wrapping inside "spec" divs.
Does that seem like what you'd want?

Yes.


Feature/visca presets fix

fixes a bridging issue with camera vista device

@jtalborough What issue is this related to? I'm not seeing any new issues.
My assumption is that the preset names aren't populating when the EISC comes online. This would be better solved for all cameras that inherit from CameraBase and might possibly implement the IHasCameraPresets interface by adding a private method to the base class that sets the values on the bridge that can be called both when the event fires and when the EISC comes online.

As @andrew-welker has alluded, it would be helpful to confirm the issue that this branch attempts to solve.
If Andrew's assumption is correct, the best way to solve the issue would be, as Andrew suggests, to use the existing logic in the EventHandler lambda of the LinkCameraToApi() method in CameraBase (snippet below), and break this out into a separate method that would be called at the time the LinkCameraTo API initially runs, as well as when the PresetsListHasChanged event fires, and when the EISC comes online.
It's not best practice to fire the PresetsListHasChanged event in the link to API process, because it would have the unintended downstream effect of also causing anything else subscribed to that event to evaluate, when in fact, in this scenario, the presets themselves have not changed, they are simply being linked to a bridge.
I think this approach would solve the same problem, and also ensure that the PresetsListHasChanged event only fires when the presets list has actually changed.
            if (cameraDevice is IHasCameraPresets)
            {
                // Set the preset lables when they change
                var presetsCamera = cameraDevice as IHasCameraPresets;
                presetsCamera.PresetsListHasChanged += new EventHandler<EventArgs>((o, a) =>
                {
                    for (int i = 1; i <= joinMap.NumberOfPresets.JoinNumber; i++)
                    {
                        int tempNum = i - 1;

                        string label = "";

                        var preset = presetsCamera.Presets.FirstOrDefault(p => p.ID.Equals(i));

                        if (preset != null)
                            label = preset.Description;

                        trilist.SetString((ushort) (joinMap.PresetLabelStart.JoinNumber + tempNum), label);
                    }
                });

Cool...Thanks guys. You're correct on the issue the visca camera (or IHasPresets) preset names do not populate when a bridge is connected. Feel free to address however you would like.


Add 'scripthost' to 'lib' for the 'generate-spec' target.

Cherry-picks the first commit from #17215.
Fixes #19924.

Does scripthost let you access COM objects or something?

Yup.


The extension "jupyterlab-autoplay" does not yet support the current version of JupyterLab.

It appears the extension needs dependency version bumps. Complete error message follows.
Extension Installation Error
An error occurred installing jupyterlab-autoplay.
Error message:
The extension "jupyterlab-autoplay" does not yet support the current version of JupyterLab.
Conflicting Dependencies:
JupyterLab              Extension        Package
>=3.0.7 <3.1.0          >=2.2.4 <3.0.0   @jupyterlab/application
>=3.0.7 <3.1.0          >=2.2.5 <3.0.0   @jupyterlab/notebook
>=17.0.1 <18.0.0        >=16.9.0 <17.0.0 react-dom

Thanks for raising this issue.
There's a branch in the repo for Jupyter Lab 3. Would you mind trying it?
https://github.com/remborg/autoplay/tree/jupyter-v3

I can try, but I am not familiar with this development ecosystem. In the Development Install instructions, the first line fails:
$ pip install -e .
ERROR: File "setup.py" not found. Directory cannot be installed in editable mode: /Users/rjacobson/Development/autoplay


Cannot connect to LND on remote node

Description

Zap wallet is unable to connect to LND on my Umbrel node.  The node is fully synced, has several small channels opened, and is able to connect to the Zeus wallet.
Seems like there may be an issue with Orbot as the Zeus wallet has a built-in Tor implementation.  I think the app is unable to maintain connection to the Tor service.
Expected Behavior
Expecting wallet balances and the like to load after establishing connection to my Umbrel node over Tor.
Actual Behavior
Opening the app gives 1 of 2 error messages:
"Tor connection failed" OR
"Unable to connect to LND"
Possible Fix

Steps to Reproduce

Open Orbot
Toggle VPN mode to on
Select Zap wallet as a VPN app
Click start
Wait for network bootstrapping to complete
Open Zap wallet
Scan QR code from Umbrel node

Context

Your Environment

Zap version: 0.4.1-beta
Android version: (e.g. API 28)
Device: Pixel 3
LND Version: v0.12.1-beta
Orbot Version: 16.4.1-RC-2-to.<IP_ADDRESS> (from Google Play Store)

Hi,
thanks for your report.
Unfortunately Orbot often causes issues. Sometimes I just can't get it to work. What helps for me in this situation is to actually restart the phone (restarting Orbot and Zap is not enough). After that it works again for some days or weeks.
Integrating Tor natively is on the to do list, I hope this trick helps in the meantime.

I have just released v0.5.0-beta which includes native Tor support.
This should solve the Tor connection issues.
If there are still problems after the update, feel free to open a new Issue.


add eontimer 3 to releases

can somebody add eontimer 3.0 to releases? i got banned from blisys server (didn't even do anything bad) so i can't get the link.

@sakuraglitch what operating system are you on?

Hello, I have an MacBook Pro with BigSur, I have attempted to build the dmg for the version 3.0, but when I open it it doesn't work any of the buttons.. not sure if you can provide me with the 3.0 release, cause I tried to use on the build, a EonTimer custom background that doesnt actually works on my computer.

pretty sure eontimer doesnt work on mac
On Tue, May 24, 2022 at 9:20 AM FinocchiaroGR @.***>
wrote:

Hello, I have an MacBook Pro with BigSur, I have attempted to build the
dmg for the version 3.0, but when I open it it doesn't work any of the
buttons.. not sure if you can provide me with the 3.0 release, cause I
tried to use on the build, a EonTimer custom background that doesnt
actually works on my computer.
—
Reply to this email directly, view it on GitHub
https://github.com/DasAmpharos/EonTimer/issues/87#issuecomment-1135916071,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANB7QTD7MWFOCU5HAVWK6O3VLTJSHANCNFSM4ZJMUY3A
.
You are receiving this because you were mentioned.Message ID:
@.***>

still no 3.0 release? I don't know from where to download the latest one. Is it the 2.0.1?

@sakuraglitch @FinocchiaroGR @ElLorans I'm going to close this since it's no longer relevant. I recently rewrote the application in python with PySide6. You can find the alpha release artifacts here


skip flaky webview test (#150682)

This PR fixes #

@bpasero is there an issue to go with this?

Yeah: https://github.com/microsoft/vscode/issues/150682


[BUG] RHDA can not open pom.xml when it is not in default disk (Windows)

Describe the bug
RHDA can not open pom.xml when it is not located in default disk. For example, X:\
It shows this error:
ENOENT: no such file or directory, access 'C:\fravelgue\learn-spring\pom.xml'

To Reproduce
Steps to reproduce the behavior:

Open pom.xml that is in a different disk to C:\. In the screenshot: X:\fravelgue\learn-spring\pom.xml
See error

Expected behavior
The effective-pom.xml is generated, and I am able to analyze dependencies as normal.
Screenshots

Logs
n/a
VSCode(please complete the following information):

OS: Windows: 11 23H2
VSCode version: 1.91.1
Dependency Analytics Version: 0.9.5

Additional context
It works when using context menu (right button): Red Hat Dependecy Analytics Report.

I tried reproducing this issue on my mac, and I get different error, not sure if related.
I'll keep investigating.

Here's an update:
I've tested the VSCode extension from source, also being tested/referenced is the fabric8-analytics/fabric8-analytics-lsp-server from source, and I'm now no longer getting the previous error on the same package.json file.
So, maybe there's something in master of this repo, or something in master of fabric8-analytics-lsp-server that didn't make its way in the release. I'll keep investigating.

Hi @johnsteele
My understanding of this issue is that the VSCode extension is producing an error message when trying to deal with a pom.xml file that is stored on a different disk drive to the default drive.
Now that you have overcome the issue you described above, have you been able to recreate the original issue?

Hi @PhilipCattanach
Yes, I did test on pom.xml and I was not able to reproduce this issue.


Introducing....
Then next-world-reefer.html just shows your other examples with reefer.
I'll likely add store support and then release as a standalone project. Note that it works with vanilla Reefer -- no changes required (though I have a few suggestion)...
Not really an issue - but curious for thoughts/suggestions...
Test case: https://codepen.io/sreekotay/project/editor/ZvkWPj#

Oh I should mention - I did extend the Reef semantics to add "listeners".  There is only one call to addEventListener per document (per event type) but it handles the boiler plate stuff for Reef Components....

Not my personal style of coding, but really neat! PS: I dig your avatar!


feat: add configuration for file permission

Reason for Change:

This PR adds support for file permission for secrets being written to the pod.

Requirements

[x] squashed commits
[ ] included documentation
[ ] added unit tests and e2e tests (if applicable).

Issue Fixed:

fixes #712
Does this change contain code from or inspired by another project?

[ ] Yes
[x] No

If "Yes," did you notify that project's maintainers and provide attribution?
Special Notes for Reviewers:

Codecov Report

Merging #751 (64e2cf3) into master (a40f897) will decrease coverage by 1.11%.
The diff coverage is 12.00%.

I have added e2e tests for kind cluster.

The changes look good! Could you update the documentation here to add the new field? You can add available for version > v1.1.0 so users know it's not yet released.

added.


Add WebSDK version update notifications for 11/1/16 and 11/8/16

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Skype/AppSDK/Download.md
:white_check_mark:Succeeded

Details

Skype/WebSDK/SkypeWebSDKVersionUpdateNotifications.md
:white_check_mark:Succeeded

Details

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


all: Replace Entrypoint / Cmd with Args

This consolidates the Entrypoint and Cmd fields into a single Args field, which is simpler and more compatible with the changes proposed in #3100.
The Entrypoint in Dockerfiles is now largely redundant (except when used as a fallback when a job has no explicit Args, e.g. blobstore), and is now explicitly set in the bootstrap manifest, with a migration added to update the releases in the database.
I have also included a change to the scripts to support bootstrapping from a backup URL, and I have uploaded a backup of v20160624.1 (which includes the NodeJS example app) at https://s3.amazonaws.com/flynn-test/backups/nodejs-v20160624.1.tar.
Using the above, I manually tested restoring from a backup:
$ script/bootstrap-flynn --from-backup https://s3.amazonaws.com/flynn-test/backups/nodejs-v20160624.1.tar
===> 12:34:29.787 using backup URL https://s3.amazonaws.com/flynn-test/backups/nodejs-v20160624.1.tar
...
12:34:30.328530 check online-hosts
12:34:31.329800 run-app discoverd
12:34:31.440595 run-app flannel
12:34:31.502869 wait-hosts wait-hosts
12:34:33.505763 run-app postgres
12:34:33.815807 wait postgres-wait
12:34:35.829652 restore-postgres restore
12:34:38.320593 run-app controller
12:34:38.442225 wait-controller wait-controller
12:34:39.004028 run-app blobstore
12:34:39.106169 wait blobstore-wait
12:34:39.120159 run-app controller-scheduler
12:34:39.223460 status-check status
12:34:41.153589 cluster-monitor cluster-monitor

$ flynn -a nodejs ps
ID                                          TYPE  STATE  CREATED        RELEASE
host0-1c6b8b48-0e05-49b5-8c95-e33b5c18a78f  web   up     8 seconds ago  52ffe7cb-7b4c-4461-8c5d-17503448dd1d

This change breaks flynn run <args>... when used with a slug app because the <args> don't include the Entrypoint /runner/init.
I am thinking about a solution, but let me know if anybody has thoughts on that.

Slug release args fixed in 174c899.

LGTM


Fix invalid integer in settings file, add Gitignore, and remove package-lock.json

I've made a few updates to the project in this pull request. First, I fixed an invalid integer in the settings file as 0000000 is not considered as a valid integer that was causing issues with the app. I also added a Gitignore file to ignore unnecessary files and directories, and removed the package-lock.json file to keep the dependencies consistent across environments.

How does he then install the node modules?

It does not require the package-lock.json file it just needs the package.json file.


pythonparser.compat_ast as a tested drop-in replacement of stdlib ast

Creates a new module pythonparser.compat_ast, being as near as possible to stdlib ast. The intended usage is to change import ast to import pythonparser.compat_ast as ast on the existing and working code.
The tests on test_ast.py were imported and adapted from CPython repo (2.7 tag), being less tight on node attributes attribution. The "helper" functions were mostly copied over from CPython ast.py
With this branch only, the results of the tests are FAILED (failures=1, errors=19).
Merging #13, #14 and #15, the results are FAILED (failures=3, errors=11). This merged code is on branch alanjds/integration-compat_ast, having most errors about lists being not a real list on  stdlib ast. However, if you ignore "ASTHelpers" tests then there are only 5 errors!.
This is an effort to have https://github.com/google/grumpy switched from the C-module _ast parser to a pure-python parser. Progress is being tracked on https://github.com/google/grumpy/pull/216.

As I've mentioned elsewhere, full compatibility with the built-in AST module is not a goal because it is not designed particularly well. On top of several issues with the code, accepting this PR adds a significant maintenance overhead for no benefit that I see.

I see. But the 1st line of the docs at http://m-labs.hk/pythonparser/ says that

[PythonParser] parses source code into an AST that is a superset of Python’s built-in ast module, but returns precise location information for every token.

And a superset is the full original plus something. If you meant "subset" there than you are right. But if not, than using the original tests from the original feature set seems a good way to go.
Be clear that as an OSS author/contributor, you have all the right to do (or do not) whatever code you are being "not" paid do write ;). I just though to be helping towards the "superset = original + something" goal here.

Would you like to change from pythonparser.compat_ast to pythonparser.contrib.compat_ast, and mark this as community-sourced explicitly unmaintained stuff?
Is not what I would like, but if it solves the problem...

From the Grumpy perspective, having an ast replacement work out of the box
is nice to have, but I'm perfectly happy to maintain the compat layer on
our side.
On Tue, Feb 7, 2017 at 8:17 AM Alan Justino da Silva <
<EMAIL_ADDRESS>wrote:

Would you like to change from pythonparser.compat_ast to
pythonparser.contrib.compat_ast, and mark this as community-sourced
explicitly unmaintained stuff?
Is not what I would like, but if it solves the problem...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/m-labs/pythonparser/pull/16#issuecomment-278049866,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHLe2R_n1KlBkWvxeDyWlf7k1G5U3A8ks5raJkZgaJpZM4L4ttU
.

I see. But the 1st line of the docs at http://m-labs.hk/pythonparser/ says that
[PythonParser] parses source code into an AST that is a superset of Python’s built-in ast module, but returns precise location information for every token.

That's not what I meant when writing that. Rather, I meant that the ASTs returned by Parser admit the same accessors as the stdlib ast module, and have the same structure. (Worth altering the wording, I think.)

Looks like not even grumpy needs that, so, closing. The PR is trivial to resurrect anyway.

No problem. Sorry to forget it open.


Segmentation Fault when using SSL to connect inside a Debian container (node:18)

Bug description
Prisma causes the process to crash when trying to connect to a hosted database that requires SSL when run inside a Debian container (node:18).
(note the log in the image below saying connecting to localhost is a leftover from a previous run...local connections without SSL work fine and the seg fault was caused connecting to a cloud-hosted db)

This doesn't occur on windows machines and I've verified the connection and ssl parameters are correct by using node-pg to connect to the database without problems.
I've provided the node-pg client connecting successfully alongside the segfault in the repo below.
How to reproduce
Steps in README.md in example repo:
https://github.com/samfweb/prisma-tsdb-ssl-segfault
The repo uses TimescaleDB (a postgres extension).
Expected behavior
Prisma should connect successfully and not crash the process.
Prisma information
N/A
Environment & setup

Database: PostgreSQL (with TimescaleDB extension)
Node.js version: v18.2.0
OS: node:18 docker image (uses Debian)
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye

Prisma Version
prisma                  : 3.14.0
@prisma/client          : 3.14.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at<EMAIL_ADDRESS>Default Engines Hash    : 2b0c12756921c891fec4f68d9444e18c7d5d4a6a
Studio                  : 0.460.0
Preview Features        : interactiveTransactions

Can you try again once with Node 16?

Node 16 works! Thanks for the suggestion.

@pantharshit00
I was using node v18 and faced this error too, then switched to v16 and the error is gone.

I am using nodejs-18 on Debian, facing the same problem here, any workaround for this problem?
uname -a
Linux xxoo.cloud 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux

node -v
v18.5.0

prisma -v
Environment variables loaded from .env
prisma                  : 4.0.0
@prisma/client          : 4.0.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine da41d2bb3406da22087b849f0e911199ba4fbf11 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli da41d2bb3406da22087b849f0e911199ba4fbf11 (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core da41d2bb3406da22087b849f0e911199ba4fbf11 (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt da41d2bb3406da22087b849f0e911199ba4fbf11 (at<EMAIL_ADDRESS>Default Engines Hash    : da41d2bb3406da22087b849f0e911199ba4fbf11
Studio                  : 0.465.0

https://github.com/prisma/prisma/issues/10649#issuecomment-1247961614

Thank you for the report!
I'm closing this issue in favour of https://github.com/prisma/prisma/issues/10649 as a duplicate to consolidate them and make it easier to keep track of the issue. Please post any questions or additional details in that thread, or open a new issue if you experience a similar problem under completely different conditions (e.g., with other DBMS or operating systems).
While we are looking for the best way to fix or prevent the underlying problem, the recommended workaround for affected users is to make sure that the versions of OpenSSL used by Node.js and the system OpenSSL match:

either by downgrading Node.js to 16.x,
or by upgrading the operating system (or Docker image) to use OpenSSL 3 — this might be less suitable for production systems, but this is a good option for those who only encounter the issue on their local machines during development.

Alternatively, if you can't do that and you need to stay with Node.js 18 on a system with OpenSSL 1.1.x, you can switch to the binary engine in Prisma.

I use node versionv19.8.1, I had the same error. I fixed as the following:

Added   engineType = "binary" in schema.prisma in the client

generator client {
  provider = "prisma-client-js"
  engineType = "binary"
}

Run npx prisma migrate dev --name init
Run npx prisma generate

Please don't use that as the solution, but only a temporary workaround. https://github.com/prisma/prisma/issues/10649 now has a development version that fixes the problem - please take a look at that as well and let us know if this works for you and properly fixes the problem. Thanks.

Please don't use that as the solution, but only a temporary workaround. #10649 now has a development version that fixes the problem - please take a look at that as well and let us know if this works for you and properly fixes the problem. Thanks.

Yes, it worked for me.
In my package.json I updated prisma and @prisma/client with 4.12.0-integration-rtld-deepbind.3
  "dependencies": {
    "@prisma/client": "4.12.0-integration-rtld-deepbind.3",
    "prisma": "4.12.0-integration-rtld-deepbind.3"
  }

This issue is fixed in Prisma 4.13.0 which will be released tomorrow, on Tuesday, Apr 18. If you need to temporarily use a pre-release version until then, you can use 4.13.0-dev.33.

For future readers:
Note that this GitHub issue is about a specific bug that occurs when using Node.js 17+ on a system with OpenSSL 1.1 on x86-64 CPUs when using TLS to connect to database. Please do not post comments here if you encounter a segfault under different circumstances, and open a new issue instead.
If you are facing segfaults on ARM, please leave a comment in https://github.com/prisma/prisma/issues/18510 or open a new issue.


Saving few bytes for browser

Cached this in a variable
Commented now from utils.js as it is unused
Improved few if-else conditions

rebased, thanks for the contribution.
If you have time, this project is actually derived from RSVP.js, if you have time to help push similar improvements there. I would be very appreciative, as it will help me keep on-going maintenance in-check


Feat/page header footer design

:clipboard: Add associated issues, tickets, docs URL here.
Overview
Design changes for header and footer.
Changes
Describe your changes and implementation choices. More details make PRs easier to review.

Added component and storybook for footer.

Updated design for footer.

written test case.

fix for select styles

fix for select dropdown & gasWatcher component

resolves #959, souradeeps feedback (#1008)

gaswatcher to be migrated to typescript

added fee switcher to header component

added fee switcher

created hook for useOnboard & useWalletConnect

Updated home components.

Removed fetching dao specific data from home

NS cleanup

Simplified the Home component

Notification component to render alerts.
-Moved all modal from home to ModalContainers.

Updated the styles for the Home Container.

fix for connect button

fix storybook to render font's correctly

added font's for roboto and monteserrat

added stories for footer

design fixes of footer on light mode

Implementation of footer design

footer implemenation

updated test cases for layout header page

test cases for menu list

added test cases for themeswitcher

Testing
Describe how to test your new feature/bug fix and if possible, a step by step guide on how to demo this.

@sk-enya As we discussed during the meeting, I sent the change to make the connect button work after closing the connect modal. Apparently, we need to modify or update the usage of the setConnectETH and setConnectBOBA hooks. This is scattered across many files, so I'm not sure if we should consider cleaning up the old hooks (if we're no longer using them) to some extent.

@sk-enya I still believe that manually loading the typography in our application is not a good idea, as Google fonts are cached in most browsers worldwide. Therefore, I don't see the benefit of forcing the use of local files.
At the very least, we should consider analyzing it further. While this doesn't affect the functionality of the code, it adds at least 3 MB of additional loading when starting to use the app... which impacts the time it takes for the user to interact with our platform. I don't think it's a good idea.

@sk-enya I still believe that manually loading the typography in our application is not a good idea, as Google fonts are cached in most browsers worldwide. Therefore, I don't see the benefit of forcing the use of local files.
At the very least, we should consider analyzing it further. While this doesn't affect the functionality of the code, it adds at least 3 MB of additional loading when starting to use the app... which impacts the time it takes for the user to interact with our platform. I don't think it's a good idea.

Yeah, make sense will remove typography and use from google cdn.


fix: avoid predicate push down for outer join terms.

This PR ensures to keep the join condition about outer-terms (e.g. from L join R on ... WHERE R.v is NULL).
before:
from A join B on A.k = B.k WHERE B.v = 1
-- becomes
from A join B on A.k = B.k and B.v = 1 WHERE B.v = 1

after:
from A join B on A.k = B.k WHERE B.v = 1
-- becomes
from A join B on A.k = B.k WHERE B.v = 1 -- never copy the filter

This will fixed the following query behavior:
CREATE TABLE tb1(pk INT PRIMARY KEY, c1 INT);
INSERT INTO tb1 VALUES(1,10);
INSERT INTO tb1 VALUES(2,20);
INSERT INTO tb1 VALUES(3,30);

CREATE TABLE tb2(pk INT PRIMARY KEY, c2 INT);
INSERT INTO tb2 VALUES(1,10);
INSERT INTO tb2 VALUES(2,20);
INSERT INTO tb2 VALUES(9,90);

select tb1.pk, tb2.pk from tb1 left outer join tb2 on tb1.pk = tb2.pk where tb2.pk is null;

This is related to https://github.com/project-tsurugi/tsurugi-issues/issues/589.


WAF toggle doesn't make sense with the new Managed Rules

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the plugin and it is still present.

WordPress version
6.3
Cloudflare-WordPress version
4.12.2
PHP version
8.0.27
Expected result
WAF configuration should control managed rules
Actual result
WAF configuration consists of a single on/off toggle, which no longer exists with the new Managed Rules. Toggling it causes a "Bad Request" error.
Steps to reproduce
See "Security" section of Cloudflare plugin's "Settings" tab. If your zone has new Managed Rules enabled, toggling the WAF toggle will result in a "Bad Request" error.
Additional factoids
Environment

WordPress: 6.3
PHP: 8.0.27
Server: Apache/2.4.53 (AlmaLinux) OpenSSL/3.0.7
Database: mysqli (Server: 8.0.32 / Client: mysqlnd 8.0.27)
Browser: Safari 16.2 (macOS)
Theme: Twenty Twenty-Three 1.2
MU-Plugins: None activated
Plugins:

Akismet Anti-Spam: Spam Protection 5.2
All in One SEO 4.4.3
Cloudflare 4.12.2
Cloudflare Image Resizing 1.5.2
Code Syntax Block 3.1.1
Custom Fonts 2.0.2
DreamHost Panel Login 1.0.0
File Upload Types 1.3.0
Health Check & Troubleshooting 1.7.0
Jetpack 12.4
Jetpack Boost 2.0.0
Jetpack Protect 1.4.1
Jetpack Search 1.4.1
JSON Feed 1.4.3
Performance Lab 2.5.0
Redirection 5.3.10
Simple Cloudflare Turnstile 1.22.1
WebSub (FKA. PubSubHubbub) 3.1.3
WordPress Beta Tester 3.5.3
WPForms Lite <IP_ADDRESS>
WP Mail SMTP 3.8.2
Zotpress 7.3.4

References
https://developers.cloudflare.com/waf/reference/migration-guides/waf-managed-rules-migration/
May be related to #507

.


GitHub issues downstream tokens

Just here for the CI

Codecov Report
Attention: Patch coverage is 82.74510% with 88 lines in your changes are missing coverage. Please review.

Project coverage is 30.57%. Comparing base (80c7022) to head (02ffff0).
Report is 3 commits behind head on github_identity_provider.

Files
Patch %
Lines

test/testlib/browsertest/browsertest.go
0.00%
55 Missing :warning:

test/testlib/env.go
0.00%
11 Missing :warning:

...ternal/testutil/oidctestutil/testgithubprovider.go
86.88%
6 Missing and 2 partials :warning:

internal/githubclient/githubclient.go
95.80%
4 Missing and 2 partials :warning:

test/testlib/skip.go
0.00%
6 Missing :warning:

internal/testutil/testidplister/testidplister.go
95.55%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@                     Coverage Diff                      @@
##           github_identity_provider    #1963      +/-   ##
============================================================
+ Coverage                     30.14%   30.57%   +0.43%
============================================================
  Files                           358      362       +4
  Lines                         59869    60335     +466
============================================================
+ Hits                          18046    18448     +402
- Misses                        41293    41353      +60
- Partials                        530      534       +4

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


2.0 fails on upgrade checks if unicode characters are in the config file.

I use some unicode characters in my ~/.jrnl_config, but this breaks the upgrade check:
$ jrnl test -1
Traceback (most recent call last):
  File "/home/philipsd6/devel/jrnl/venv/bin/jrnl", line 9, in <module>
    load_entry_point('jrnl==2.0.0rc1', 'console_scripts', 'jrnl')()
  File "/home/philipsd6/devel/jrnl/jrnl/cli.py", line 145, in run
    config = install.load_or_install_jrnl()
  File "/home/philipsd6/devel/jrnl/jrnl/install.py", line 87, in load_or_install_jrnl
    upgrade.upgrade_jrnl_if_necessary(config_path)
  File "/home/philipsd6/devel/jrnl/jrnl/upgrade.py", line 22, in upgrade_jrnl_if_necessary
    if not config_file.strip().startswith("{"):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 170: ordinal not in range(128)

I created PR #399 to fix this issue.

Ouch. What a rookie mistake - thanks for catching that!


Use native git for git-commit-id-plugin to speed up build

Currently, git-commit-id-plugin takes a lot of time during the build

git-commit-id has support for 'native git', this is a config option. After this change:

To use this, added a configuration option in pom file to turn on native git.

@2bethere how did you generate those pie charts? And what do the measurements mean?

I used https://github.com/intuit/maven-build-scanner
Original blog:
https://medium.com/@alex_collins/10x-faster-maven-builds-at-intuit-5b7bb60c65e6
The # on the pie chart is cumulative ms during the build.


Ability to create ServiceAccount for each runner namespace

Following on from https://github.com/weaveworks/tf-controller/issues/297
Rather than creating additional resources outside of the chart, this PR adds the ability to pass a list of namespaces that the runner may run within, and creates the appropriate ServiceAccount and ClusterRoleBinding resources within each namespace.
runner:
  serviceAccount:
    allowedNamespaces:
      - test
      - stable
      - stage

Looks like the docs need to be updated  https://github.com/weaveworks/tf-controller/actions/runs/3273201286/jobs/5385113192

Looks like the docs need to be updated https://github.com/weaveworks/tf-controller/actions/runs/3273201286/jobs/5385113192

Docs pushed - sorry, we let GHA generate our docs, too used to that process!


Support request signing for AWS auth

Upgrade elastigo to use johnwchadwick/elastigo@aws-sign

@ukch thanks for the contribution and sorry its taken so long to get back
I'm about to start work on switching to a different elasticsearch library (https://github.com/olivere/elastic) and it has support for AWS request signing so I'll be sure to get it included with that change if that's ok?

closing in favor of #233


Lines Hit and Lines Found

This is more of a request than an issue. But could there be an update when producing the lcov file to show LH and LF? When using lcov report actions look for LH and LF to create a total coverage percentage.

@kshiflett88 I created PullReq for the same issue, and I published successor gem.
https://github.com/fortissimo1997/simplecov-lcov/pull/28#issuecomment-2239501041


Adams Bashforth startup is broken

I think there is an error in the way Adams Bashforth time stepping gets started up.
In the original code, the AB timestep coefficients get initialized in the __init__method with values that make it do forward Euler
         self.dt0 = self.dt
         self.dt1 = 0.

Then later in step_forward, after the first AB tendency has been calculated, they get updated.
         # add time tendencies (using Adams-Bashforth):
         self.qh1 = self.filtr*(
                     self.qh1 + self.dt0*self.dqh1dt + self.dt1*self.dqh1dt_p)
         self.qh2 = self.filtr*(
                     self.qh2 + self.dt0*self.dqh2dt + self.dt1*self.dqh2dt_p)

         # remember previous tendencies
         self.dqh1dt_p = self.dqh1dt.copy()
         self.dqh2dt_p = self.dqh2dt.copy()

        # the actual Adams-Bashforth stepping can only be used starting
        # at the second time-step and is thus set here:
        if self.tc==0:
            self.dt0 = 1.5*self.dt
            self.dt1 = -0.5*self.dt

Starting with this commit (f7f50f8b520123327f9c4f8ae29b1d7ad74c6a2a), the code to update dt0 and dt1 was moved before the first tendency calculation. This means that the first is calculated using forward Euler, but with 1.5*dt instead of dt. Later, when third order was implemented, the bug persisted, meaning that third order coefficients are used for the second timestep.
I will fix this along with my general rewrite of the AB code.

You're right. I'm sure this is a mistake – definitely my fault. Apologies for breaking this startup. Unfortunately I did not realize because of course this did not change anything anything in the final solutions of the example problem. Perhaps this advocates for the need to have many, unambiguous,  tests...

Why would this not change the test case? I would think that it should (very little, but probably enough to make the test fail). Or are you referring to the other tests that you added?

I was just referring to the example that is integrating over many years; the change to the equilibrated solutions was insignificant...
The "twolayer" test was failing for me from the beginning probably because of differences in platforms. So, after consulting Ryan, I didn't bother trying to pass it after my changes. Had the test passed when I first forked pyqg, I would have worked to try to make my changes pass that test before submitting the pull request. I think this was the origin of all the mess my changes caused. Sorry guys.

First of all, Cesar, no apologies at all, please. We are sorting this thing out. Lesson learned: be serious about tests! This was my mistake, not yours.
I have fixed this AB issue in the following commit: 1f8c816cb0ab33d296f6471c8f1af5ff12b81781
AB3 is still the default, but there is now an option useAB2 which force only second order to be used. I am now trying to get the test working using the origin values. This is complicated though by the other issue which is breaking the new code on the only machine I have which can pass the original tests.

Nobody is blaming anybody! I'm sorry if it came out that way! We just need to make sure that we have a protocol in place to make sure for the future that we are not putting in bugs and that we agree before making changes that change answers. So we need a good test. I just quickly checked, and it seems like the "twolayer" test is sensitive to this small error in the first timestep. It changes the answer for "qnorm" in the fourth significant digit. That gives an example of something that we do want to  be able to detect with the tests.

Malte, did you check with my latest commit? That should have fixed the AB bug and also restored the second-order AB timestepping to the test case. So it should, in theory, give the same result as the code before Cesar touched it.

As I just said in the other issue thread: the latest commit is crashing on my laptop:
ValueError: operands could not be broadcast together with shapes (32,17) (32,32)

Guys, I found  thread that was open in "Anaconda-issues" last September. People report this bug with mkl real fft and other bugs!
Here it works in my anaconda installation using mklfft with fftpack:

In [2]: np.fft.rfft2
Out[2]:  function mklfft.fftpack.rfft2
In [5]: np.fft.rfft2(np.zeros((16,16))).shape
Out[5]: (16, 9)

The timestepping issue was fixed with 1f8c816cb0ab33d296f6471c8f1af5ff12b81781.


Redo Resume Guide based off McDowell book

also add more examples and example resumes, like stated in #15


Rework type hierarchies?

Since breaking changes are on the table already (https://github.com/gtk-rs/cairo/pull/255#issuecomment-491065296) I’m considering some more, but I’d like some opinions before writing code.
Patterns
cairo-rs 0.6.0 has a Pattern enum where each variant contains a pointer-wrapping struct for the corresponding kind of pattern. Both the enums and each struct implement a PatternTrait trait that has methods in common to all patterns. Two of the structs implement a Gradient trait.
For bindings in object-oriented languages, https://www.cairographics.org/manual/bindings-patterns.html reccomends classes for each pattern kind and inheritance. The closest in today’s Rust is having structs whose only (or first, with #[repr(C)]) field is the parent type, that implement Deref<Target=ParentType> (and maybe AsRef<AncestorType> for all recursive ancestors, I’m not sure it’s needed given auto-deref). cairo-rs 0.6.0 already does this with surfaces.
This way, the Pattern and Gradient structs could have inherent methods that are usable on “sub-types” through auto-deref, without the need for traits.
Additionally, there could be methods similar to the standard library’s downcast to go from less specific to more specific types.
PDF, PS, and SVG surfaces
https://github.com/gtk-rs/cairo/issues/250 has some complaints about the API for these surface types. While I disagree with some of the points there (there’s a reason for differences with ImageSurface, they are already closer to idiomatic Rust than bare C FFI, …) I do agree that the current API is a bit weird:
There are public modules named pdf, ps, and svg (whereas all other modules except prelude are private with contents reexported from the crate root) and contain identical types named File, Writer, and RefWriter.
I think we can have one Rust type for each of these surface kinds, and no public module for them. For example PdfSurface with create and create_for_stream constructors.
(BTW I’m not sure we can safely keep RefWriter’s functionality, for the same reason as https://github.com/gtk-rs/cairo/issues/228. (Surface ref-counting make it insufficient to have a wrapper type with a lifetime parameter.) It may still be worth having an unsafe fn constructor for it.)
Remaining public traits

XCBSurface is a trait implemented for Surface, but https://github.com/gtk-rs/cairo/pull/102 does not explain why. Should it be a type similar to ImageSurface instead?

SurfaceExt could be inherent methods of Surface, accessible on “sub-types” through auto-deref.

MatrixTrait adds methods to the Matrix type which is reexported from cairo-sys-rs. There could be a local Matrix type that duplicates the definition and has compatible layout, so that it can have inherent methods. (A wrapper type would lose the benefit of public fields.)

With all this the prelude module could become unnecessary.
Thoughts?

cc @meh

Re patterns: :+1: . We use the same pattern elsewhere and the way it's currently in the cairo bindings is a bit more complicated as it has to be, and inconsistent with how we do similar things elsewhere. Thanks!
PDF/etc surfaces: Makes sense and I also agree with your comments on the other issue.
XCBSurface: That should be handled like all the other surface "subclasses" IMHO. Must be historical reasons why it isn't.
Surface/Matrix: :+1:
In summary, go for it :) And thanks for taking a look at the API and coming up with a plan to clean it up. That was long overdue!

I think we can have one Rust type for each of these surface kinds, and no public module for them. For example PdfSurface with create and create_for_stream constructors.
(BTW I’m not sure we can safely keep RefWriter’s functionality, for the same reason as #228. (Surface ref-counting make it insufficient to have a wrapper type with a lifetime parameter.)

The whole reason they are separate types were various requirements by @meh and me I think in #234 and related threads.
I don't see how RefWriter is problematic while Writer isn't, I think we have a huge problem with both of those, which we overlooked in the previous re-design. The problem is that Surface implements Clone (using the underlying C refcounting), which means no Surface wrapper can hold any resources, whether references or otherwise. Ie. I believe the current bindings are unsound.
I'm not sure what to do about this. We could stuff the writer object into user data, this would require the writer to be 'static. I'm not sure I like that. IMOH more Rust-idiomatic way would be to make it not Clone, like a proper resource-holder, but it's farther from the philosophy of the underlying API.

Right, the current API is unsound and adding a 'static bound to the W type parameter is what I had in mind, at least in the safe API. User data allows making cairo responsible for running a destructor (CC https://github.com/gtk-rs/cairo/pull/257). There could be an unsafe fn API that is less restrictive, where the caller is responsible for ensuring that the surface doesn’t live longer than the stream.
I think trying to prevent cloning (i.e. refcount > 1) would not be viable if there’s any code in the same process using cairo but not through cairo-rs (like code in C or another language). And even if not, as far as I understand a cairo_t context internally “clones” a strong reference to the underlying cairo_surface_t to keep it alive, for example.
Thanks for linking #234. I’ll read through comments on it and d39b674ef9e7a73cafebf7fa32e4eb7ae82f6900, they seem to be valuable background.

I think trying to prevent cloning (i.e. refcount > 1) would not be viable if there’s any code in the same process using cairo but not through cairo-rs (like code in C or another language). And even if not, as far as I understand a cairo_t context internally “clones” a strong reference to the underlying cairo_surface_t to keep it alive, for example.

Yeah, I think you're right, cairo is built around the refcounted nature of the surfaces too much.
Still, having a stream or a file which is finalized/closed at some arbitrary moment in the future when/if references to it are dropped is very annoying in the context of Rust. So, maybe a viable option would be to have the internal state nullable and the I/O callback could be aware of this - it would simply do nothing if the internal state were null. Personally I find the finish() method useful and it would be nice to be able to keep it, so that we have control over the moment at which the surface is 'done' writing to the backing I/O object, whatever it is.

Yeah, I think you're right, cairo is built around the refcounted nature of the surfaces too much.

Just to be explicit, surfaces are refcounted and that's what the Clone impl does. So for 'static it should be ok currently, otherwise not. And we can't enforce anything about refcounts due to interactions with other libraries (e.g. GTK) where we have no control over refcounts. In extension, every mutating operation on surfaces must be modelled as interior mutability in Rust.
And I agree that too much refcounting is used in cairo and also GObject based libraries, it's a PITA for Rust or other languages that have a concept of ownership and mutability. We ran into similar problems in other places before, and it's part of the reason why many things can't currently be Send. But I digress.
I think @SimonSapin's plan to have a safe 'static variant and an unsafe variant with arbitrary lifetime is a good idea. It's also how we handle similar problems elsewhere already. And also @vojtechkral's idea that it would be stored as an Option and a finish() method would take it out would seem like a good idea usability-wise. Instead of doing nothing I would suggest to have it return an error though.

Yes, to preserve the ability to recover the stream out of a surface I think it has to be nullable / optional in the internal state. In terms of public API this could be a take_stream method that returns an Option.
It’s tempting to only have one PDFSurface type without a type parameter, with create_for_stream and take_stream being generic. The latter could rely on something like std::any::Any for checked downcasting and None or Err when the types don’t match.
To avoid fallible dynamic downcasts we’d need a generic surface type like 0.6.0’s pdf::Writer<W>. Since there are also surface without a Rust stream (null output or libc file output) this means either:

Two surface types, one generic and one not. This requires two different names. PDFSurfaceWithStream<W> and PDFSurface?
Or one generic PDFSurface<W> type with a dummy placeholder like PDFSurface<!> or PDFSurface<()> when there’s no stream.

I'm in favor of two types, the stream variant name I think could be shortened to PDFSurfaceStream<W>. There's also an additional though miniscule benefit of having two types: The 'regular' type has no additional bookkeeping overhead.

 If there’s a separate type, I think we want a name that expresses that this is a surface (that has an output stream).
There would not be extra overhead with a single type. We can (and actually need to) keep the stream and io::Error slot in a cairo_surface_set_user_data data entry. The constructors for no-stream cases would simply not create that entry.

The constructors for no-stream cases would simply not create that entry.

Ok. It would be nice to have a single type, but then I'm not sure how to make this not awkward for the non-customized variant. The problem with PDFSurface<!> or PDFSurface<()> is that ! is nightly-only and () doesn't implement Write. A custom trait blanket-implemented for Write and ()?

I think the Write bound doesn’t need to be on the type, only the create_for_stream constructor.
How do you feel about a single non-generic PDFSurface type and checked dynamic downcast in take_stream?

How do you feel about a single non-generic PDFSurface type and checked dynamic downcast in take_stream?

Doesn't Any require the type to be 'static? That would prevent your idea to have an unsafe function that allows non-static writers to be passed in.
Otherwise that seems like a reasonable approach. There's enough runtime type machinery in the bindings anyway, one more is not going to hurt.

Assuming that W = &'a mut V where V: 'static (so for example not supporting W = MutexGuard<'a, V>) is good enough for this use case, the unsafe API could involve passing *mut V instead of &mut V. This both solves the Any: 'static constraint and reinforces the point the the lifetime of V is not tracked by cairo-rs.

Works for me. It would prevent some things, but I guess that's fine. Worst case the user could transmute T<'a> to T<'static> before passing to this API, I assume Any also works on that if you're careful enough.

I think the Write bound doesn’t need to be on the type, only the create_for_stream constructor.

Ah, sure, that makes more sense. If this is the case though, why is a dynamic variant preferable? Couldn't it be PDFSurface<W = ()>?

It can, only manipulating PDFSurface<()> (when you’re using file output or null output) is more noisy than PDFSurface.

With a single non-generic type (and dynamic downcast in take_stream) we could have Surface::as_pdf_surface(&self) -> Option<PDFSurface>. I’m not sure how that could work if there’s only one PDFSurface<W> type that has a type parameter.

Well with the default template arg you could just use PDFSurface with the () implied, as far as I know.
OTOH the downcast from surface would not be possible I think.
I don't know, either option is ok with me...

I’ll try it and ping you all when there’s a PR to look at.

Awesome, thanks for working on this :)

I’ve submitted https://github.com/gtk-rs/cairo/pull/260, please comment there.


Chapter 11. SELU example

Original
means = X_train.mean(axis=0, keepdims=True)
stds = X_train.std(axis=0, keepdims=True) + 1e-10
X_val_scaled = (X_valid - means) / stds

with tf.Session() as sess:
    init.run()
    for epoch in range(n_epochs):
        for X_batch, y_batch in shuffle_batch(X_train, y_train, batch_size):
            X_batch_scaled = (X_batch - means) / stds
            sess.run(training_op, feed_dict={X: X_batch_scaled, y: y_batch})
        if epoch % 5 == 0:
            acc_batch = accuracy.eval(feed_dict={X: X_batch_scaled, y: y_batch})
            acc_valid = accuracy.eval(feed_dict={X: X_val_scaled, y: y_valid})
            print(epoch, "Batch accuracy:", acc_batch, "Validation accuracy:", acc_valid)

New
x_val_means = X_valid.mean(axis=1, keepdims=True)
x_val_stds = X_valid.std(axis=1, keepdims=True) + 1e-10
X_val_scaled = (X_valid - x_val_means ) / x_val_stds

with tf.Session() as sess:
    init.run()
    for epoch in range(n_epochs):
        for X_batch, y_batch in shuffle_batch(X_train, y_train, batch_size):
            batch_means = X_batch.mean(axis=1, keepdims=True)
            batch_stds  = X_batch.std (axis=1, keepdims=True) + 1e-10
            X_batch_scaled = (X_batch - batch_means) / batch_stds
            sess.run(training_op, feed_dict={X: X_batch_scaled, y: y_batch})
        if epoch % 5 == 0:
            acc_batch = accuracy.eval(feed_dict={X: X_batch_scaled, y: y_batch})
            acc_valid = accuracy.eval(feed_dict={X: X_val_scaled, y: y_valid})
            print(epoch, "배치 데이터 정확도:", acc_batch, "검증 세트 정확도:", acc_valid)

Am I wrong?
If mine is not wrong, is there any reason you did that, which I couldn't catch ?
Thanks.

Hi @alogblog ,
Thanks for your question.  The original is correct.

When we perform feature standardization, we must compute the mean and standard deviation for each feature (not for each instance). So the axis should be 0, not 1.
Secondly, when we standardize a training batch, it is best to use the full training set's mean and standard deviation (for each feature), rather than the batch's mean and std.

To understand why feature standardization is important when using gradient descent, please read chapter 4 on gradient descent, there is a section that explains why features should be scaled.
Moreover, at test time we might get a single instance at a time: it would not make sense to standardize a single feature using its own mean and std deviation.  So instead, we will use the training set's mean and std deviation at test time to scale new instances.  Therefore, during training we should do the same: use the full training set's mean and std deviation (per feature).
Hope this helps,
Aurélien

Closing stale issues. Please reopen if you are still experiencing a problem.


Merge client's code into the vmd repository

Merge client's code into the vmd repository. Commits are verified.

Commit https://github.com/tiiuae/vmd/pull/34/commits/f8bce24ad4e31326dd6f5a7b5306002c816a4ba5 not signed off


updated docblock on GameState

Updated some doc blocks to use <see> and <remark> tags, etc. Updated the wording in some places too -- happy to change that if you disagree with any of the new wording

Closing this to and re-open on another branch


How can I use script_id in IHeapLocation to get js url ？

Is there any way I can get the js url of the specified node？

Is there any way I can get the js url of the specified node？

From what I understand, script_id in IHeapLocation is just an index referring to a data structure in Chrome's memory when the heap snapshot was taken, but Chrome does not seem to encode and serialize the index to URL mapping in JS heap snapshot.

Thank you for your reply


mypyc command (in mypy package) setuptools error

Describe the bug
mypyc doesn't work
Steps To Reproduce

add mypy in system pkgs (NixOS unstable) and rebuild
run mypyc

Expected behavior
not to, throwing an error
Screenshots

Notify maintainers
@martingms @lnl7 @SuperSandro2000

mypyc creates a build directory with a setup.py file that contains the following
from setuptools import setup
from mypyc.build import mypycify

setup(name='mypyc_output',
      ext_modules=mypycify([], opt_level="3", debug_level="1"),
)

For that to work we would need to leak setuptools into the user environment. Also I think mypyc is a build tool that you shouldn't normally execute like you did which means this is not a bug. You likely want to execute mypy or dmpypy.

Indeed you are right, I assumed it would at very least have a --help, it seems like not


Failed to use set_user_data() on Resource

Actually I have difficulty in using this library, or maybe improper usage.
Use case
I wanted to pass some MemMap from server to client thus using user data facilities. In the server, I called set_user_data then get_user_data in the client. It was segfault, so I suspect either set_user_data failed or the user data didn't get passed onto client.
Usage
I called set_user_data() of WlBuffer that passed onto WlShmPool::create_buffer(), but after checking WlBuffer's data, I discovered it to be null (both in GDB and LLDB). Thus caused segment fault when I access the data later.
It turned out, set_user_data() I called earlier was failed: the data ptr will be assigned if only
the WlBuffer (or Resource) structure initialized wiith Some data:
        fn set_user_data(&self, ptr: *mut ()) {
            if let Some(ref data) = self.data {
                data.1.store(ptr, Ordering::SeqCst);
            }
        }

But this buffer is automagically initialized, unfortunately with nulled data.
Code
I apologize if my code is a mess.
    fn create_buffer(&mut self,
        evlh: &mut EventLoopHandle,
        client: &Client,
        resource: &WlShmPool,
        bfrtpl: WlBuffer,
        offset: i32,
        width: i32,
        height: i32,
        stride: i32,
        format: Format
    ) {
        // BufferData impl wl_buffer::Handler
        let bufdata = BufferData::new(self.data.clone(), offset, width, height, stride, format);

        // ..other codes

        let handler_id = evlh.add_handler(bufdata.clone());

        // I inspect bfrtpl with GDB and was null prior assignment

        // assign data
        let bufdata = Arc::new(Mutex::new(bufdata));
        let data = Box::into_raw(Box::new(bufdata));
        bfrtpl.set_user_data(data as *mut ());

        // I inspect with GDB again and was null after assignment

        evlh.register::<WlBuffer, BufferData>(&bfrtpl, handler_id);
    }

Notes
I use older wayland-rs v0.9.9, but I see the same codes internally. Let me know when you need more snippet. Also let me know when actually I need to upgrade the version since I persistent to upgrade without reason.
Thank you.

Hmm, this is using an old version of wayland-server, and the code and API of the library has actually changed a lot since then. I can't force you to upgrade (especially given the amount of work this represent), but we aware that this version line is no longer maintained. wayland-rs is still in a moving state while I'm trying to figure out the most appropriate API (see #165 ).
However, maybe I'm misunderstanding, but you seem to be trying to access user_data attached server-side from the client-side ? This is not how user_data works nor how it can be used. I allows you to attach a point to a Resource and retrieve it from any other handle to the same resource, but in no case is it transferred to the client. These are two different programs, you can't pass pointers around from one to the other. Client and server can only communicate using the protocol messages.

Hmm.. so technically this likely has been solved. Close this..
Thank you for your time.


runTests.js: Cannot find module 'xmlhttprequest'.  Cannot call method 'ensureIndex' of undefined.

When I 'node runTests.js' in the tests directory I get a bunch of successes, but then I get the following:
♢ UseUI

  Socket.IO A GET to /socket.io/?t=test
    ✓ should respond with 200
    ✓ returns it is ready
'Error: Cannot find module \'xmlhttprequest\'
    at Function._resolveFilename (module.js:317:11)
    at Function._load (module.js:262:25)
    at require (module.js:346:19)
    at Object.request (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/socket.io-client/lib/util.js:159:26)
    at Socket.handshake (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/socket.io-client/lib/socket.js:149:25)
    at Socket.connect (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/socket.io-client/lib/socket.js:202:10)
    at new Socket (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/socket.io-client/lib/socket.js:62:12)
    at Object.connect (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/socket.io-client/lib/io.js:192:16)
    at Object.<anonymous> (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/tests/app-useui-test.js:40:31)
    at run (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/vows/lib/vows/suite.js:128:31)'

That last is repeated many times.  Then there's a pause, and then I get the following repeated many times:
'TypeError: Cannot call method \'ensureIndex\' of undefined
    at Object.addCollection (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/ldatastore.js:36:40)
    at Object.addCollection (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/lsyncmanager.js:21:16)
    at processData (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/lsyncmanager.js:395:15)
    at /Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/lsyncmanager.js:359:53
    at /Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/async/lib/async.js:97:13
    at Array.forEach (native)
    at /Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/async/lib/async.js:26:24
    at Object.forEach (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/node_modules/async/lib/async.js:96:9)
    at /Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/lsyncmanager.js:359:15
    at Object.init (/Users/tlarson/Documents/dev/locker/lockerbox/Locker/Common/node/ldatastore.js:21:30)'

After that a pause, then that part is repeated again, followed by a pause, followed by repeated error... endlessly.
This is code checked out yesterday (Dec 2).  I'm running on a Mac OSX 10.6.8.

Similar to #480 that I filed

Trent, what version of Node.js are you running? And what version of CLucene do you have installed?

node is v0.4.9
CLucene is harder to determine; I built it from clucene.git.sourceforge.net, which hasn't been changed since May so you may be able to determine from the source; I'm guessing <IP_ADDRESS> from the CMakeLists.txt file and the highest /usr/local/lib/libclucene... file which is liblucene-shared.<IP_ADDRESS>.dylib.

Having Eric take a look at this -- may be Linux-specific.

Search indexing is being refactored, setting this to OPT-CLOSE


Issue 15913 - cannot initialize immutable fixed size array without similar const-code

Could you please identify where the actual fix is amidst the refactorings?

Could you please identify where the actual fix is amidst the refactorings?

I separated commits.

LGTM, the patch also works for LDC.

This PR should only consist of the second commit here.
Please, please do NOT kitchen sink random stuff into a bug fix PR. Refactorings and other jazz should go in separate PRs. I've repeatedly explained why. Having separate commits is not good enough.
Note that this PR is held up by a debate over a refactoring that is irrelevant to the bug fix. This is one of those reasons. I couldn't even find the bug fix in the original incantation of this PR, it being lost amongst the refactorings, which is another reason. Mixin in refactorings make it hard to cherry-pick bug fixes into other branches. Refactorings have been known to introduce regressions. And on and on.
https://github.com/D-Programming-Language/dmd/pull/5652/commits/587591160457a9e453ec686bd2f59b33bdcebd8b is the kind of PR bug fix I like to see.

@WalterBright OK, I broke up those trivial prepared changes into *three pulls: #5623, #5670, and #5671.
When I've tried to fix issue 15913, those changes were actually necessary to me to understand git master code base. I'm a lazy programmer, so I deny to repeat same things in the future.

I broke up those trivial prepared changes into three pulls: #5623, #5670, and #5671.

All three of those contain the printGaggedErrors changes and so are not pullable.

@WalterBright Ping.

Auto-merge toggled on

This looks ok now, setting auto-merge.


Blas xGEMV launch failed error when running on GPU.

I've ran into a really strange error that is incredibly difficult to track down.  I have a version of Tensorflow (2.6.0-rc1) using Cuda 11.3 that I compiled from source.  When I run it using my GPU for evaluating a pretty normal feed forward model I constantly get this crash on this one particular line.
    h = tf.matmul(h, self.output_weight)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/util/dispatch.py", line 206, in wrapper
    return target(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/ops/math_ops.py", line 3654, in matmul
    return gen_math_ops.mat_mul(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/ops/gen_math_ops.py", line 5696, in mat_mul
    _ops.raise_from_not_ok_status(e, name)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 6941, in raise_from_not_ok_status
    six.raise_from(core._status_to_exception(e.code, message), None)
  File "<string>", line 3, in raise_from
tensorflow.python.framework.errors_impl.InternalError: Blas xGEMV launch failed : a.shape=[1,2728550,5], b.shape=[1,5,1], m=2728550, n=1, k=5 [Op:MatMul]

When I look up this error it usually indicates a problem in the CUDA install or other similar problems, but in this particular case CUDA is working just fine. I am able to run another script which uses Keras from the same Tensorflow install and use the GPU with zero problem. In fact in this same exact code 2-3 TF.MatMul calls go through with zero problem right before it crashes on this line.
h = tf.matmul(h, self.output_weight)
Where self.output_weight is a tensorflow Variable class and h is as well.  Both data types float32.  The thing is the h variable also was computed by multiple sequential calls that run on the GPU just fine.  When I run in CPU only mode it runs just fine with zero problems.  The model only uses matmul opperations and standard tensorflow library functions. What's even stranger is this same exact code works on the GPU for a different set of input!
I'm running this on Linux Mint 20.2 with Kernel version 5.4.0-88-generic.  Cuda version 11.3 with the corresponding compatible version of TensorRT, the NVidia drivers, etc.  This is being done on a RTX 3090 graphics card.   It's an incredibly strange error since it only pops up on this one particular line. I also tested out my Cuda install via the samples folder in the Cuda install directory.  My other Cuda based GPU applications work just fine as well.  Nvidia-smi also shows Python3 taking up most of the card's memory as it usually does.

My guess would be that the [1,2728550,5] tensor is wayyy too large, so your input is probably too large.
You could feed inputs of increasing sizes into your model to find the point at which the code collapses.

@mrnucleation
In order to expedite the trouble-shooting process here,Could you please fill the issue template,Could you please try as per the comment above and let us know if it helps? Thanks!

My guess would be that the [1,2728550,5] tensor is wayyy too large, so your input is probably too large.
You could feed inputs of increasing sizes into your model to find the point at which the code collapses.

I was able to get it to compute by cutting up the array into blocks of 1/100th of the original size and passing them through one at a time.  Then pasting the fragments together at the end. Though it' still a bit perplexing why it crashes on the last line.  That's more what's absolutely confusing.
If anything it should have crashed in the middle of the network where the intermediate tensors are far larger. The finally tensor is just a Nx5 tensor where as the intermediate ones are Nx16 and Nx32 in size.  I'm thinking it might have to do with the previous computations hanging around in memory and clogging things up.
The computer this is running on has 64GB of system memory and 24GB of GPU RAM. When I measure the ram consumption with NVIDIA-SMI it only takes up 3GB of ram.  It seems like rendering a 8K image should be a more resource intensive task than this and this system can do that just fine. So it seems to have more to do with the TF backend not liking that.

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Mint 20.2
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary):
TensorFlow version (use command below): 2.6.0-rc1
Python version: 3.8.10
Bazel version (if compiling from source): 3.7.2
GCC/Compiler version (if compiling from source): 9.3.0
CUDA/cuDNN version: 11.3
GPU model and memory: MSI Geforce RTX 3090 24GB

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

v2.6.0-rc1-4-g9a63e4600fa 2.6.0-rc1
Describe the current behavior
Crashes when running in GPU mode on final computation of a network.  Passes two layers of a feed forward type model perfectly and then throws a BLAS error when computing the final output.  Works just fine in CPU Only mode. Crashes with the error message

  File "/<redacted>/SymbolicNetworks/ThreeBody/StabiliyTest/symbolic_network.py", line 162, in __call__
    h = tf.matmul(h, self.output_weight)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/util/dispatch.py", line 206, in wrapper
    return target(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/ops/math_ops.py", line 3654, in matmul
    return gen_math_ops.mat_mul(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/ops/gen_math_ops.py", line 5696, in mat_mul
    _ops.raise_from_not_ok_status(e, name)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 6941, in raise_from_not_ok_status
    six.raise_from(core._status_to_exception(e.code, message), None)
  File "<string>", line 3, in raise_from
tensorflow.python.framework.errors_impl.InternalError: Blas xGEMV launch failed : a.shape=[1,18800375,6], b.shape=[1,6,1], m=18800375, n=1, k=6 [Op:MatMul]

Describe the expected behavior
Computation passes through two layers of the network successfully in GPU mode and crashes on final computation.

@mrnucleation We see that you are using 2.6.0-rc1 ,Could you please try with the stable version of TF 2.6.0 ,please refer to build from source.Please refer to some similar issues link1, link2,link3 and let us know if it helps?Thanks!

I have a similar issue when using CUDA 11.3. I would suggest to downgrade CUDA 11.2. There should be some unknown compatibility issues with CUDA 11.3. (And I hope it can be investigated)

UPDATE: It may be a bug of cublas. See https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#cublas-11.4.0

@mrnucleation, This issue can be due to several reasons,

out of memory: Limit the GPU memory growth
configuration Mismatch with CUDA/cuDNN
remove the cache folder ~/.nv/

您的邮件已经收到--阿杰


Update azure-monitor-agent-migration.md

2407250050004662 - Advisory ask. Cx asked if MMA and LA Agent can be used together. cx also asked if LA Agent will continue to function with the deployment of AMA

@EdB-MSFT
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

#sign-off

#sign-off

#sign-off

Please can you include my name as a contributor
Ashi Sunnam
Azure Monitoring Support Engineer
Azure Monitoring and Automation | Customer Services and Support
Office: +1<PHONE_NUMBER>| Email: @.***
Working hours: Mon – Fri: 9 am - 6 pm Eastern
If I'm not available:
Team Manager | Stanley  Parker @.)
If you have any feedback about my work, please let either me or my manager Stanley Parker know at  * @.*
If you need immediate assistance for this case while I am out of the shift, please send a separate email with the case ID to @.***

From: Ed Baynash @.>
Sent: Monday, August 26, 2024 8:34:04 AM
To: MicrosoftDocs/azure-docs @.>
Cc: Ashi Sunnam @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Update azure-monitor-agent-migration.md (PR #124184)
#sign-off
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/124184#issuecomment-2310103249, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A336OIMN47FOKRBMEFFETN3ZTMODZAVCNFSM6AAAAABM3FAKS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGEYDGMRUHE.
You are receiving this because you were mentioned.Message ID: @.***>


update message manager

I want to merge this change because...

PR intended to be tested with API branch:
Screenshots

Pull Request Checklist

[x] All visible strings are translated with proper context.
[x] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Translated strings are extracted.
[x] Number of API calls is optimized.
[x] The changes are tested.
[x] Type definitions are up to date.
[ ] Changes are mentioned in the changelog.

@AlicjaSzu when testing new messages with storybook, message timer is not stopping when mouse is on message. Will it be added in separate PR?

Task linked: CU-60rppx Handle timer for closing notifications

Task linked: CU-60rppa Implement info and warning notification levels

Task linked: CU-60rpqx Add ability to expand description

Task linked: CU-60rtv2 Handle multiple notifications on screen

@AlicjaSzu error message is closing itself at storybook. DoD specified that error messages will not have timers (https://app.clickup.com/t/60rppx)


How to access headers['link'] from api-version 2019-07

Hi,
Do you know how to access the headers['link'] from the REST request to get the link attribute (pagination https://help.shopify.com/en/api/guides/paginated-rest-results)?
I tried to do $request->response->headers and get an error that says
production.ERROR: Cannot access private property GuzzleHttp\Psr7\Response::$headers {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalThrowableError(code: 0): Cannot access private property GuzzleHttp\\Psr7\\Response::$headers at
Thanks,
Fran

$linkHeader = collect($request->response->getHeader('Link'))->first();

Thanks @bnzo !


Deploy draft releases to BM fleet

patch: Merge new action with Flowzone
patch: Deploy draft releases to BM

@balena-ci I self-certify!


There's no info anywhere that Docker doesn't work with Windows x86 and requires x64

I was quite surprised and disappointed when the installer said that it requires x64.
You should specify this "little" detail somewhere on the Docker site: in filename and on a couple of pages, like here and here, I think, so people know that it won't work on their x86 Windows BEFORE they download and try to install Docker.

#dibs


Add utility function void ChangeWindowFullMonitorWorkArea() like void…

Add a utility function ChangeWindowFullMonitorWorkArea() to resize the window with the monitor work area.
This new function works like ChangeWindowSize(...).

Hi @Robxley
Many thanks for the PR, this is a good idea!
I'm a bit sensitive to naming. Could you change the name to something like WindowUseFullMonitorWorkArea (or you may propose another name inspired from this).
By the way, could you give me more info about the context in which you are using Hello ImGui.
Thanks!

Hi @pthom,
Thank you for your quick response 😁.
I completely agree with your naming suggestion; after all, it's your project 😊. "WindowUseFullMonitorWorkArea" is indeed more explicit.
Regarding your question about how I use Hello ImGui: I’ve been working with ImGui for a long time, especially in computer vision projects.
In my personal projects, I enjoy developing 3D/2D engines as a hobby (often for no particularly useful purpose 😋), and ImGui has always been my go-to tool for creating user interfaces for these wonderfully useless projects !
In my professional role as a computer vision engineer, I often need to track and display video and image processing results from existing production pipelines. ImGui is very convenient in these contexts, particularly because it is easy to use across different platforms and integrates seamlessly with existing computer vision production engines.
I recently discovered Hello ImGui, and it perfectly addresses the needs of creating cross-platform applications without any pain. I wouldn’t have had the time (and your expertise) to achieve such an integration on my own.
Thanks to your great work, Hello ImGui is straightforward to use and makes it very simple to set up a new app.
Why reinvent an (probably unstable) wheel ... 😁
And if I can contribute occasionally with some humble new features, I’d be happy to help!
Have a good day.
Robxley

Hi again,
I may have answered too quickly regarding the function name.
In your code, the function for resizing is named ChangeWindowSize. To keep the syntax consistent (action + description), perhaps UseWindowFullMonitorWorkArea would be a better fit than WindowUseFullMonitorWorkArea.
What do you think?
Robxley

In your code, the function for resizing is named ChangeWindowSize. To keep the syntax consistent (action + description), perhaps UseWindowFullMonitorWorkArea would be a better fit than WindowUseFullMonitorWorkArea.

Perfect! Can you please push a modified version?

In my professional role as a computer vision engineer, I often need to track and display video and image processing results from existing production pipelines.

You might be interested in ImmVision, which I also developed, and which is part of ImGui Bundle.
See demo, and click on the ImmVision tab:

Merget, thanks a lot.
PS: I was a computer vision engineer in a previous life.

Thank you for the tips about ImmVision.
When I came across hello_imgui, I also explored your GitHub. 😄
I’ve seen ImmVision—it looks very interesting, similar to the Image Watch extension for Visual Studio but with more tools.
I haven’t had a chance to use it yet, but maybe someday! 😊


[BEAM-13881] [Playground] Increase test coverage for the utils package

[BEAM-13881]
Added unit tests to increase test coverage for the utils package.

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

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] 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: @pabloem

thanks LGTM!


Small replacement orders fail due to size violation.

When a new order is created, the default behaviour is for Flumine to validate against the minimum bet size of (varying by location, but GBP 2.00 stake or GBP 10.00 exposure in the UK).
This functions correctly, however when replacing an order, this validation should not occur, as it should be possible to amend the price for the remaining portion of an existing order, currently this returns a Violation, whereas in the GUI and via the REST API it is possible to change the price on these small sizes.

Quick fix will be to only enable the min_bet_size validation when the OrderPackage is a place, minor refactor.

Quick fix will be to only enable the min_bet_size validation when the OrderPackage is a place, minor refactor.

Do you have logs for this?
The control only checks the original size/price so a replace below minimum will not cause a violation, just checked on my side and it works as expected.

Do you have logs for this?
The control only checks the original size/price so a replace below minimum will not cause a violation, just checked on my side and it works as expected.

Here is the log:
https://betfairlightweight.slack.com/archives/C4H05ML2E/p1610403796071400
When I set:
client.min_bet_validation = False
and handle the logic elsewhere it works fine, so it definitely appears to be that causing the error.

Here is the log:
https://betfairlightweight.slack.com/archives/C4H05ML2E/p1610403796071400
When I set:
client.min_bet_validation = False
and handle the logic elsewhere it works fine, so it definitely appears to be that causing the error.


libuv: Remove GCCVER redefinition.

Summary
Impact
Testing

[Experimental Bot, please feedback here]
I need the content of the PR to assess if it meets the NuttX requirements. Please provide the following:

The actual PR content:  This includes the PR description, code changes, and any relevant comments.
Information about the specific changes being made: For example, what problem is the PR trying to solve? What specific files and functions are being modified?

With this information, I can then evaluate the PR against the NuttX requirements and provide a more accurate and helpful response.


h5p uploads broken in latest plugin update

I  found and solved an issue and I thought you may like to know the solution so you can edit your code.
The older h5ps seem to be calling a dependency that has been deprecated.
1. I changed the filename from "name.h5p" to "name.zip"
2. Opened it in file explorer (or winzip etc)
3. Opened h5p.json
4. removed the first dependency (it seems to have been depreciated) (I compared the *.json file with a newer H5P module)

Line was: {"title": "Phloem coloured", "language": "und", "mainLibrary": "H5P.CoursePresentation", "embedTypes": ["div"], "license": "U", "defaultLanguage": "de", "preloadedDependencies": [{"machineName": "H5P.Image", "majorVersion": "1", "minorVersion": "1"}, {"machineName": "H5P.CoursePresentation", "majorVersion": "1", "minorVersion": "21"}, {"machineName": "FontAwesome", "majorVersion": "4", "minorVersion": "5"}, {"machineName": "H5P.FontIcons", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "H5P.JoubelUI", "majorVersion": "1", "minorVersion": "3"}, {"machineName": "Drop", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "Tether", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "H5P.Transition", "majorVersion": "1", "minorVersion": "0"}]}
New line: {"title": "Phloem coloured", "language": "und", "mainLibrary": "H5P.CoursePresentation", "embedTypes": ["div"], "license": "U", "defaultLanguage": "de", "preloadedDependencies": [{"machineName": "H5P.CoursePresentation", "majorVersion": "1", "minorVersion": "21"}, {"machineName": "FontAwesome", "majorVersion": "4", "minorVersion": "5"}, {"machineName": "H5P.FontIcons", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "H5P.JoubelUI", "majorVersion": "1", "minorVersion": "3"}, {"machineName": "Drop", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "Tether", "majorVersion": "1", "minorVersion": "0"}, {"machineName": "H5P.Transition", "majorVersion": "1", "minorVersion": "0"}]}
 5. deleted the bold text, then saved the changes and closed the file.
6. changed "name.zip" back into "name.h5p" and uploaded it. Works fine now.

By the way, Thankyou so-much for this software, it has saved me so much time!

I Think you may only need to edit the template.h5p

by the way
Moodle 3.11.4 (Build: 20211108)
H5P 1.22.4 (plugin for moodle)
Running on Docker: bitnami/moodle:latest
However my university has the same issue as well.
Sam

Thanks for digging this up. When I find the time, I will make a test between those two versions.

I have been trying to compile the code with my differnt version of the h5p.json and It won't work.
do you compile the pptx2h5p.py? or the .spec?

any tips?

Take pyinstaller and compile the .spec

Thanks!

Hi, same problem here, would be very grateful is this would be solved, sadly enough i can't :(
thnx

I have edit the .json file as @King1a3 find, BUT I got "Error writing to database" after the save.
Running on Moodle 3.11.9
Anyone found a solution? or an update ?
The first error that I got without any edition on H5P file is:
"You're trying to upload content of an older version of H5P. Please upgrade the content on the server it originated from and try to upload again or turn on the H5P Hub to have this server upgrade it for your automaticall."

You could try to replace the template by any h5p file downloaded from your instance, hoping that nothing changed under the hood concerning this tool.
Sorry, i won't have time to look deeper for the next few weeks.

Am 07.10.2022 um 15:22, metadata.bug  @.***>  schrieb:
I have edit the .json file as  @King1a3  find, BUT I got "Error writing to database" after the save.
Running on Moodle 3.11.9
Anyone found a solution? or an update ?
The first error that I got without any edition on H5P file is:
"You're trying to upload content of an older version of H5P. Please upgrade the content on the server it originated from and try to upload again or turn on the H5P Hub to have this server upgrade it for your automaticall."
—
Reply to this email directly,   view it on GitHub, or   unsubscribe.
You are receiving this because you commented.Message ID:  @.***>

I've updated the toolchain and template config from a fresh download off of h5p.org. It should be inline with your findings. Check it out: https://github.com/MM-Lehmann/pptx2h5p/releases/tag/v1.3

Cheers,
Your tool is great!
On Sun, Dec 17, 2023, 5:05 AM Martin @.***> wrote:

Closed #8 https://github.com/MM-Lehmann/pptx2h5p/issues/8 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/MM-Lehmann/pptx2h5p/issues/8#event-11266073644, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AWYIKRYD5R2OQXNMIS75NX3YJXBDRAVCNFSM5ONGJ4J2U5DIOJSWCZC7NNSXTWQAEJEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW4OZRGEZDMNRQG4ZTMNBU
.
You are receiving this because you were mentioned.Message ID:
@.***>


feat: remove @analytics/ua-parser as dependency of @amplitude/analyti…

Summary

Removes @analytics/ua-parser as dependency of @amplitude/analytics-connector
Adds @analytics/ua-parser as dependency of @amplitude/experiment-js-client

The ultimate goal is to remove @analytics/ua-parser as direct/indirect dependency of @amplitude/analytics-browser.
Checklist

[x] Does your PR title have the correct title format?
Does your PR have a breaking change?:  No

for just the analytics sdk, if we don't use ua-parser, how are we going to get os and device model?

for just the analytics sdk, if we don't use ua-parser, how are we going to get os and device model?

Same question, are we going to rely on the pipeline to determine the device info for analytics sdk?

@nirmal91

we don't use ua-parser, how are we going to get os

@liuyang1520

Same question, are we going to rely on the pipeline to determine the device info for analytics sdk?

The Browser SDK will send raw user agent values from navigator.userAgent and let ingestion parse and populate the respective fields which I believe happens here: https://github.com/amplitude/amplitude/blob/master/event/converters/http_event.py#L353-L367

@nirmal91

we don't use ua-parser, how are we going to get os

@liuyang1520

Same question, are we going to rely on the pipeline to determine the device info for analytics sdk?

The Browser SDK will send raw user agent values from navigator.userAgent and let ingestion parse and populate the respective fields which I believe happens here: https://github.com/amplitude/amplitude/blob/master/event/converters/http_event.py#L353-L367

Thanks @kevinpagtakhan for sharing the details! Should we also rely on the pipeline/ingestion side for experiment to get consistent parsed results? Probably out of scope for this PR though, changes LGTM.