Planning: Produce breakdown of tasks for requests to register Organisations

Overview
The workflow for how new researcher users register and start organisations must be determined. This could also be considered a "first time" registration setup process.
This issue will be used to gather initial notes/requirements and to discuss how to proceed so that concrete implementation tasks can be defined. This is a "living" document and is subject to change.
Breakdown

[x] Identify requirements for what is needed to have a researcher join an organisation
[x] Plan organisation joining/registration workflow with OUH

Requirements
Based on the description taken from the epic #421 and discussions with OUH, the following requirements can be implied:

An anonymous user must be able to submit an organisation registration request to the SDE.
Organisation registration requests will be submitted only when an existing organisation/department does not exist for a new user. Otherwise, the anonymous user will follow the workflow from #429.
An organisation registration request must allow no user ID to be recorded against it initially. However, once the first (approver) user account has been created in the SDE, the request must be updated to map the user to the request.
An organisation registration request cannot be marked as complete until the user ID of the new user has been assigned to it.

Organisation Registration
When this happens
It is necessary to submit an organisation registration request when:

A new user attempts to submit a user registration request
However, they cannot find a pre-selectable organisation and/or department for such a request
Meaning they instead submit an organisation registration request - with their personal details to act as the first organisation member (the "approver" by default).

Sequence of Actions
Below is the intended workflow of actions to carry out as part of the organisation registration request:
flowchart
    subgraph explorer
        anonUser[Anonymous user]
        firstTimeSignIn[First time sign-in]
        reviewRequestStatus[Review request status]
        userReadyForSde[Ready for SDE]
    end
    subgraph sde-admin
        pendingRegistration[Pending registration request]
        assignedRegistration[Assigned registration request]
        initialUserChecks[Initial user checks]
        rejectUser[Reject and notify user]
        mapUserToRequest[Map user to request]
        verifyOrg[Verify organisation]
        rejectOrg[Reject organisation]
        createOrgDept[Create organisation/department]
        createSdeUser[Create Mauro/SDE user records - approver]
        newUserReady[New user ready - approver]
        mapUserToOrg[Map user to organisation]
        mapUserToDept[Map user to department]

        pendingRegistration -- SDE administrator pickup --> assignedRegistration
        assignedRegistration --> initialUserChecks
        initialUserChecks -- Verified --> createSdeUser
        initialUserChecks -- Rejected --> rejectUser
        createSdeUser --> mapUserToRequest
        mapUserToRequest --> newUserReady
        newUserReady --> verifyOrg
        verifyOrg -- Rejected --> rejectOrg
        verifyOrg -- Verified --> createOrgDept
        createOrgDept --> mapUserToOrg
        mapUserToOrg --> mapUserToDept
    end
    subgraph azure
        addAzureAccount[Add guest account to tenant]
        authenticateUser[Authenticate user]
    end

    anonUser -- Submit registration form --> pendingRegistration
    createSdeUser --> addAzureAccount
    addAzureAccount --> newUserReady
    newUserReady -- Notify user --> firstTimeSignIn
    firstTimeSignIn -- Authenticate --> authenticateUser
    authenticateUser --> reviewRequestStatus
    reviewRequestStatus --> userReadyForSde
    mapUserToDept --> userReadyForSde

Request State Workflow
Below are some changes to the existing SDE request state workflow that will need to be achieved to support the additional request types for user and organisation registration:
stateDiagram-v2
    draft : Draft request
    awaitUserCheck : Await user checks
    initialUserCheck : Initial user check
    createUserAccount : Create user account
    awaitPickup : Await pickup
    otherSdeStates : Other SDE states...

    draft --> awaitUserCheck : Submit (Researcher)

    awaitUserCheck --> initialUserCheck : Assign (SDE Administrator)
    initialUserCheck --> draft : Rejected (SDE Administrator)
    initialUserCheck --> createUserAccount : Approved (SDE Administrator)
    createUserAccount --> awaitPickup : User ready (SDE Administrator)
    createUserAccount --> initialUserCheck : Pending (SDE Administrator)
    createUserAccount --> awaitUserCheck : Pending (SDE Administrator)

    awaitPickup --> otherSdeStates : Continue... (SDE Administrator)

The key differences are what happens between "Draft Request" and "Await Approval" or "Await Pickup":

For this kind of request, the status transitions straight from "Draft Request" to "Await User Checks".
Only SDE administrators can manage requests in the "Await User Checks" state.
An SDE administrator must be assigned to the request, moving to the "Initial User Checks" state.
In this state, the SDE administrator must make some initial background checks on the user to ensure they should have a user account. (These are processes to be determined by OUH).
All being well, they move the request to the "Create User Account" state. Here, they will perform the technical actions to setup their user account. Once created, the request can finally be mapped to this new user account.
Now that the initial approver is created, the rest of the organisation must be verified. This can only be done by an SDE administrator, so will transition to the "Await pickup" state. From here onwards, the current request workflow continue as before.

Registration Form
An anonymous user will be able to fill in a registration form in the Mauro Data Explorer, providing the following details:

Organisation name - including the legal name
Organisation details - website, country of origin, SMB status, etc
Department name - to name the first department. If not provided, then assume the default name is the same as the organisation name.
Contact details - personal details of the first user/organisation member:

Name of user - first and last
Email address - their organisation email address
Telephone
Position/job title - for records

Other contact details - e.g. project proposals

Once submitted, the request will not currently be attached to a user ID - because the user does not exist yet. When the user record is available though, it will be assigned to the request for tracking purposes.
SDE Administrator Actions
Once the registration request is picked up by an SDE administrator, the following actions must happen before an organisation is created and the first user/member can at a minimum sign-in to the Mauro Data Explorer and track their request:

Create Mauro/SDE user accounts - the SDE administrators must perform some initial checks to make sure a user account should be created e.g. the request is not spam or a bot. Once verified, some processes can happen to setup accounts. Note that these are no longer automatic, they must be triggered manually through the SDE Admin UI.

Mauro - create a user account with the same email address as the contact details. Also assign the user to the correct user groups.
SDE - create a user account with the same email address as the contact details.

Create user in Azure - next, a user account should be added/created in the Azure OUH tenant. This is a step performed by the OUH system administrators (currently not automated).
Notification - the user must be notified (somehow) that they can sign-in to the Mauro Data Explorer.
Verification - the SDE administrators/team must verify the suggested organisation and carry out "due diligence". These are not necessarily steps that can be automated in the SDE backend.
Create organisation - once verified, an automated step can happen to create a new organisation via the existing CreateOrganisationCommand. The first department will also automatically be created.

Note: although the user may sign-in finally and track their request, they must still be prevented from performing any actions until they are added to an Organisation/Department.
Add to Organisation/Department
Whilst the research user (approver) is able to access the Mauro Data Explorer, the user registration request can continue to be fulfilled by the SDE administrator. Once verified and approved, the SDE administrator will be able to run the following commands:

Add user to the new organisation
Add user to the new department within the organisation

Only once these are done can the organisation registration request be considered "Complete". Now the researcher is an organisation approver and is able to help verify new users who submit user registration requests.

I will close this issue as it is now superseded by #445.


no border

no white border for rows, and lot's scanner can not find the generated qrcode.

The "quiet zone" does need to be added manually, and should be 4 modules wide.
The library does not do this because it is easy for the calling library to do itself, is not always required (often a display on a device already has a valid quiet zone, or printed on paper which is already white) and adds memory requirements for data that does not need to be encoded (since it is known to be padding).
If you look at the Firefly Source Code, you can see how we manually add the 3 pixels (although it should be 8 pixels, since each module is 2 pixels, but there is not room on the display) of quiet zone around the QR code.
If you need help adding the quiet zone, let me know what your target is and we will see if we can help. :)

That's right. Thanks Ricmoo.


nydusify: enable pigz by default

We should use pigz for supporting parallel gzip decompression, so that improve the conversion speed when unpack gzip layer for source image.
We still allow users to specify the env CONTAINERD_DISABLE_PIGZ=1 to disable the feature when encounter any decompression error.
See https://github.com/containerd/containerd/blob/33c0eafb17dff6de43f4a530fcf05b02ed24330b/archive/compression/compression.go#L261

cc @changweige


Live plots ??

Is live plotting of candlestick can be achieved through this library

Yes it is, sorry for the late answer. You can find an example in the latest leptos example.


fix: allow RFC3339 encoded time strings

Fixes #292
Backport of #311
@monstermunchkin  can you please check if this works as expected on V1 and give some feedback?
You should be able to get update the module by its commit hash:
go get -u github.com/zitadel/oidc@865d637e339c43bab97d907c669ec9847ea7c39a

@muhlemmer
That works as expected, thanks! There's no more unmarshalling error with the .updated_at field.

Somehow messed up this PR while trying to figure branch naming for the auto-releaser. I've merged the fix manually and it is now available in release: https://github.com/zitadel/oidc/releases/tag/v1.13.4


When the connection pool is at capacity

I was just wondering if there is a way to determine whether or not the connection pool for a knex instance is nearing/is at capacity. I have an application that varies a lot in how many connections it might have at any one time, and I was hoping to be able to explicitly create a few singular connections whenever the pool runs over capacity.
I saw a comment on a bookshelf issue here saying that this would be a good feature to have, but I'm not sure if it was ever implemented.
Apologies if I missed it in the documentation! If it matters, I'm using knex with bookshelf.

There is no official way to do this.
As a workaround if you can get hold of pool instance you could maybe add call to pool.stats() call to knex global query event or something like that to find out if you need more connections.
pool.stats();
/* {
    min: 0,
    max: 10,
    allocated: 0,
    available: 0,
    queued: 0,
    maxRequests: Infinity
} */

As far as I know you cannot change pool parameters dynamically, so those few extra connections would require initializing new knex instance with other pool I suppose.
I don't know your use case, but creating new connection if connection limit is reached doesn't sound like a good option. It is the database server which ultimately says how many connections it accepts and that limit cannot be changed in knex side.


Untangle lib dependencies

master or ctp?

master or ctp?

What do you mean by that ?! :thinking:


Arg handling and help fixup

This pull request f1xes #122, and parts of #123, and a few other bits brought up by users, and improves
command-line backwards compatability on the non jobsub-submit wrappers.
You can now use --jobid=1234.0@schedd or 1234.0@schedd or -name schedd 1234.0
interchangeably on all the commands that take jobid's.
You can do any of jobsub_q --better-analyze or jobsub_q -better-analyze or condor_q -better-analyze,
ditto for -long / --long.
It also includes the condor_q --help info in jobsub_q --help, etc.

...except  jobsub_fetchlog won't take -name schedd 1234.0.   Not sure if I want to go back and change that.

I agree about your jobsub_fetchlog point.  We probably don't want that.


Docs rename

Overview

Test Plan

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


x64: use ByteSink more liberally in the rex module

In looking at adding auto-generated assembler code to Cranelift, I've noticed that we pass MachBuffer down when it is not always necessary. The ByteSink trait (which MachBuffer implements) is a simplified view to put* bytes into the buffer and it is a bit simpler to use when testing since it is also implemented by Vec<u8>. This change propagates the trait to the rex module.

Similar to #9504, this is just an attempt at trying to simplify what is needed to actually assemble an instruction. We still need MachBuffer for instructions that touch memory; thinking about it, it may just be unavoidable.

intuitively I would have thought that MachBuffer would be an integral part of it

I mean, that's how it has to be today. I'm kind of wondering if it should, though: it's nice to be able to "just emit" an instruction into a byte buffer during testing and that's what I've been thinking about. The setup in emit_tests.rs just to be able to emit an instruction is a lot, e.g. If we're proptest-ing or fuzzing we also want the "emit a single instruction" path to be relatively quick.
On the other hand, sometimes its unavoidable: I've notice that we register traps and labels using a MachBuffer in the encoding logic and that simply cannot be done with ByteSink. Maybe ByteSink can gain extra trait functions that do nothing for the Vec<u8> case or something like that...

Maybe ByteSink can gain extra trait functions that do nothing for the Vec case or something like that...

Ah! Yeah, that's an interesting idea: lift the whole interface of MachBuffer into a trait, and provide an implementation of that trait for a Vec<u8>.
There are interesting semantic implementations of this though when label references are involved: what should the assembled bytes from a mov rax, [rip+label] instruction be? Zeroes in the RIP offset (i.e. labels not resolved)? One aspect of the MachBuffer that is nice is that its types essentially force one to be aware one is referencing addresses in the buffer: you have to ask for a label to refer to it, the various amodes require a label, and if you don't bind it, (IIRC?) it should panic when finalizing.
Maybe another way of reading this friction is that we need some convenience APIs? It should be possible to write an assemble(inst: Inst) -> Vec<u8> that is something like:
fn assemble(inst: Inst) -> Vec<u8> {
  let mut buffer = MachBuffer::new();
  inst.emit(&mut inst, ...);
  buffer.finalize(&VCodeConstants::default(), &ControlPlane::default()).apply_base_srcloc(SourceLoc::new(0)).data.into()
}

(whew, that is a bit of a mouthful, I see why you want it!)


Add Sinatra::Subroute, allowing an app to make a request to another endpoint in the app.

Allows for, e.g.:
class App < Sinatra::Application
  helpers Sinatra::Subroute
  get '/target' do
    ...
  end

  get '/subrouted' do
    subroute!('/target')
  end
end

subroute! can also add or modify request params and the HTTP verb used.
(Originally from https://github.com/lookout/lookout-rack-utils)

Hello!
I'm sorry but I'm hesitant to merge this feature given there is an identical Rack extension (I think you can use).
Merging features requires that we have a maintainer for them, and users to adopt the feature. Since there is already a gem that does this, and seems to be maintained.. I must reject.
Thanks for your contribution!


PIXI.js 8 version with WebGPU

Hi, is it possible to use new beta version of PIXI.js 8 with WebGPU, if not, will it be supported in the future?

Hello, pixi.js 8 beta is under consideration and I will continue to follow.

+1. pixi.js was released one month ago. It would be very cool to have this project cranked up to the next version.

+1


Load modules?

Where to place Python modules if I want them to load (such as textract)

Have you see #213 ?


Nuxt build error: UMD and IIFE output formats are not supported for code-splitting builds.

Describe the bug
Using with nuxt 3 works in dev environment, but breaks during the production build
Error: Nuxt Build Error: [commonjs--resolver] Invalid value "iife" for option "output.format" - UMD and IIFE output formats are not supported for code-splitting builds.
To Reproduce
Steps to reproduce the behavior:

Create a new nuxt project and install any of the jsquash codecs
Handle the transpiling in nuxt config

build: {
    transpile: [
      "@jsquash/png",
      "@jsquash/avif",
      "@jsquash/jpeg",
      "@jsquash/jxl",
      "@jsquash/oxipng",
      "@jsquash/png",
      "@jsquash/webp",
    ],
  },
  vite: {
    optimizeDeps: {
      exclude: [
        "@jsquash/avif",
        "@jsquash/jpeg",
        "@jsquash/jxl",
        "@jsquash/oxipng",
        "@jsquash/png",
        "@jsquash/webp",
      ],
    },
  },

run npm run build
See error

Okay, I installed the single threaded versions of avif, jpegxl and oxipng and it seems to be working now

Closing this

Thanks for opening this issue @fayazara.
With the newer Vite versions (v5.2.2+) we shouldn't need the single threaded versions anymore.
Could you try add the following vite config to see if it fixes your build?
worker: {
    format: "es"
}

If you can confirm it, I'll update our README with the new information 👍

Works, thanks @jamsinclair


overflow numeric cell value on 386

Description
I am trying to read xlsx files containing ean13 codes for example<PHONE_NUMBER>225
Sample file (attached to issue or download from gdrive)
barcode_test.xlsx
https://drive.google.com/open?id=16FswVFaJ5I1cVPVeViOTZWLOGg1b1eJz
This is important because when I simply open and save this file in libreoffice, the error is not reproduced.

Steps to reproduce the issue:

Sample code

xlsx, err := excelize.OpenFile("./barcode_test.xlsx")
if err == nil {
	cell := xlsx.GetCellValue("Sheet1", "A1")
	fmt.Println(cell)
}

Build instructions

export GOARCH="amd64"; go build -o et.x64
export GOARCH="386"; go build -o et.x32

Execute binaries

Describe the results you received:
» ./et.x32
-2147483648
» ./et.x64
8595602512225

Describe the results you expected:
» ./et.x32
8595602512225
» ./et.x64
8595602512225

(and this output after open then save in libreoffice)
Output of go version:
go version go1.12.1 linux/amd64

Excelize version or commit ID:
require github.com/360EntSecGroup-Skylar/excelize v1.4.1

Environment details (OS, Microsoft Excel™ version, physical, etc.):
» uname -a
Linux XXX 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Microsoft Excel™ is unknown - i just received this file
(same result on win10)

Interesting, GetCellValue returns a string so I'm not sure why it would run through an integer first and have a chance to overflow like that.

I wonder if this is the culprit. We're not checking any errors there and it converts to an int. Will need to test to find out.

I'm guessing this has been fixed?
With latest:
$ go run test.go
8595602512225

I am taking a look if there is a regression test written in this respect. Would that be appreciated?

@psyomn not fixed
$ go test ./...
ok      github.com/360EntSecGroup-Skylar/excelize/v2    1.884s

$ export GOARCH=386; go test ./...
--- FAIL: TestOverflowNumericCell (0.01s)
    cell_test.go:108:
                Error Trace:    cell_test.go:108
                Error:          Not equal:
                                expected: "8595602512225"
                                actual  : "-2147483648"

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -1 +1 @@
                                -8595602512225
                                +-2147483648
                Test:           TestOverflowNumericCell
                Messages:       A1 should be<PHONE_NUMBER>225
FAIL
FAIL    github.com/360EntSecGroup-Skylar/excelize/v2    2.060s

Would you be able to PR this test into the repo? It would be helpful for making a fix and preventing a regression later.

hmm travis - tests passed, my laptop - failed
i dont understant it

bug localized in styles.go/formatToInt
- return fmt.Sprintf("%d", int(f))
+ return fmt.Sprintf("%d", int64(f))

now all ok @xuri

If I'm reading that correctly, that might be a good workaround for now, but I wonder what happens if we get even bigger numbers than (u)int64, or what the correct thing to do would be. Seems that fairly large numbers are supported in Excel:
https://support.office.com/en-us/article/Excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3

fairly large numbers

That’s an understatement if I’m reading the docs right.
I wonder if any of the crypto libraries have support for efficient big numbers.

@xuri Maybe for performance reasons and our own sanity we specify that the maximum numeric value we support is an int64? That should cover a substantial majority of use cases, and we can investigate broadening that support more carefully if it comes up. I'd be in favor of closing this issue now that we are at least properly specifying the integer type.


Package resolution failure: buffer overflow during APK index scan

Description of bug
The default buffer size of 64 KiB is not enough to read some lines in APKINDEX files, leading the index to be truncated.
As a result, package resolution for any package after truncation fails as it appears to be missing from the index.
This currently impacts the edge/testing index from Alpine:
https://dl-cdn.alpinelinux.org/alpine/edge/testing
The creation of the buffered scanner is found here:
https://github.com/chainguard-dev/go-apk/blob/789246e329dac4759a600a0b3471de9cdb12bcbe/pkg/apk/apkindex.go#L98
Go documentation tells us that there is a default buffer size of 64 KiB unless otherwise configured:
https://pkg.go.dev/bufio#Scanner.Buffer
https://pkg.go.dev/bufio#MaxScanTokenSize
Investigation and surrounding circumstances
Resolution worked as expected until 2024-03-23, when a new version of the coq package was published to edge/testing:
https://pkgs.alpinelinux.org/package/edge/testing/aarch64/coq
I noticed resolution worked if I switched to the 386 architecture — this is because coq is not available for that architecture, so we sidestep the issue.
https://pkgs.alpinelinux.org/packages?name=coq&branch=edge&repo=testing&arch=x86
The resulting index entry for coq in APKINDEX lists dependencies on a line that is 76.2 KiB, exceeding the default 64 KiB limit:
https://dl-cdn.alpinelinux.org/alpine/edge/testing/aarch64/APKINDEX.tar.gz
Because the line is longer than the default token size, the scanner ends and the for loop exits. No error is thrown. As a result, the index is truncated, ending with the last package before coq (in this case it was copyq-doc). While there should have been over 6,000 packages in edge/testing, only about 550 were listed.
For this reason, the package I was resolving appeared to be missing from the index and apko failed.
Proposed fix
Configure a larger buffer for the buffered scanner to account for unexpectedly long lines. Adding two lines below the scanner increases the buffer to 1 MiB and fixes the issue — the apko file is now able to resolve:
// pkg/apk/apkindex.go
indexScanner := bufio.NewScanner(apkIndexUnpacked)

// Increase max token size from default of 64 KiB to account for large dependency lists.
maxTokenSize := 1 << 20 // 1 MiB
indexScanner.Buffer(make([]byte, maxTokenSize), maxTokenSize)

This is the permalink to the code in question:
https://github.com/chainguard-dev/go-apk/blob/789246e329dac4759a600a0b3471de9cdb12bcbe/pkg/apk/apkindex.go#L98
There is similar logic, not on the critical path for this reproduction, that should likely be updated as well:
https://github.com/chainguard-dev/go-apk/blob/789246e329dac4759a600a0b3471de9cdb12bcbe/pkg/apk/installed.go#L240
Minimal reproduction
Write the following contents to a file named apko.yaml:
contents:
  repositories:
    - https://dl-cdn.alpinelinux.org/alpine/edge/main
    - https://dl-cdn.alpinelinux.org/alpine/edge/testing
  packages:
    - librespot
archs:
  - arm64

Then try to resolve and observe the failure (with apko 0.14.0):
$ apko show-packages apko.yaml
ℹ            | loading config file: apko.yaml
ℹ            | Determining packages for 1 architectures: [arm64]
ℹ            | loading config file: apko.yaml
ℹ  aarch64   | doing pre-flight checks
ℹ  aarch64   | initializing apk database
ℹ  aarch64   | finished initializing apk database
ℹ  aarch64   | setting apk repositories
ℹ  aarch64   | initializing apk keyring
ℹ  aarch64   | setting apk world
ℹ  aarch64   | using working directory /var/folders/pt/b0dbzm7x7s1cq2splzq095y40000gn/T/apko-1910105790/aarch64
ℹ  aarch64   | determining desired apk world
Error: failed to get package list for image: resolving apk packages: could not find package that provides librespot in indexes
ℹ            | error during command execution: failed to get package list for image: resolving apk packages: could not find package that provides librespot in indexes

Affected versions and host environments
I've tested apko at version 0.13.2, version 0.14.0 (output above), and at HEAD when downloading the main branch from https://github.com/chainguard-dev/apko. All versions are impacted.
This error occurs both on macOS (ARM64v8 / Apple Silicon) and Linux (AMD64).
Next steps
I will send a PR shortly with the proposed fix.
A new version of go-apk would then have to be published, and the apko module would have to upgrade to that version. We'd then need a new version of apko to be published.
https://github.com/chainguard-dev/apko/blob/64231f0b36d888a28066c3bedf4dae39bc4b1870/go.mod#L9

Related pull request:
https://github.com/chainguard-dev/go-apk/pull/246


Remove usage of boost::locale

Codecov Report
Base: 98.87% // Head: 98.87% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (d0d282e) compared to base (1300b20).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #381   +/-   ##
=======================================
  Coverage   98.87%   98.87%
=======================================
  Files          93       93
  Lines        3025     3026    +1
=======================================
+ Hits         2991     2992    +1
  Misses         34       34

Impacted Files
Coverage Δ

...p/cpp_odbc/Library/src/level2/level1_connector.cpp
100.00% <100.00%> (ø)

cpp/turbodbc/Library/src/cursor.cpp
100.00% <100.00%> (ø)

...pp/turbodbc_arrow/Library/src/arrow_result_set.cpp
97.68% <100.00%> (ø)

...urbodbc_arrow/Library/src/set_arrow_parameters.cpp
95.59% <100.00%> (ø)

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


header file missing wifi_internal.h

Hi, Please help me I worked on this error for 4 days still I don't know what I am doing wrong. I am trying to collect the PCAP data using the ESP32 microcontroller. (I am using MAC OS)
Here is the error message:
esp32_pcap_sd:12:10: fatal error: esp_wifi_internal.h: No such file or directory
#include "esp_wifi_internal.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1
esp_wifi_internal.h: No such file or directory
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
FYI: I have installed all the libraries that are mentioned in the description  ( Time, ESP 32)

I fixed this way
in esp32_pcap_serial.ino change this include
#include "esp_private/wifi.h" //#include "esp_wifi_internal.h"


Sort profile status table by entities

Summary
This sorts the list of profile statuses by entity, rather than mixing all rule types and entities together in database order.  I'll include a before/after screenshot, but this makes it much easier (for me) to interpret the output of minder profile status list --detailed -n <my-one-profile>
Before (note that some rows combine multiple entities under one rule type, but the same rule type is also repeated later):

After (I also did some formatting to narrow the table by combining columns using newlines to separate related data):

Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Manual testing by running the command.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[x] Checked that related changes are merged.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.007%) to 54.763%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/util/cli/table/simple/simple.go
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

internal/eea/eea.go
2
73.73%

Totals

Change from base Build<PHONE_NUMBER>2:
-0.007%

Covered Lines:
15534

Relevant Lines:
28366

💛  - Coveralls


Handling User relationships through a contract

Added User Contract for discussions and posts implementation;
Do not let Forum Service Provider boot up if the user settings does not implement the contract (require documentation);
Add tests for User having discussions;

I like the idea. but having an interface for relationships is overkill at the moment.


Send POST request

Now, we able to send HTTP request using POST method by this way
client.Request().Post("https://jsonplaceholder.typicode.com/posts", nil)

Fixes #5
This is unit test result on this changes.

cc @RafaelYon


Add Pepefe app

Thanks, @junwatu. Can you add some keywords like books, education, learning, etc?

Also please use screenshots that emphasize the app itself, not the entire desktop.


node config: min_peers and max_peers belong to network section

The node template config has parameters min_peer and max_peers in section footprint (see e.g. here).
According to the doc those belong to the network section instead.

This is fixed in PRs above, thanks for the report!


Image Blur size is tool small to use, expose an option for setting it.

The blur width is fixed.
https://github.com/zce/velite/blob/44a6010bb2676d00c94c514537cfd913f58c3689/src/assets.ts#L72

Although it is easy to implement this requirement, I still question whether it is necessary to adjust the size of the blur image?

I think you are correct. After trying velite for three days. The current blur image is good enough for me, no need to change. I'll close this issue.


fix error_code_test.go file bug

What this PR does:

assert.Equal(t, int(IO), 3)

Which issue(s) this PR fixes:

Fixes #

assert.Equal(t, int(TransactionErrorCodeIO), 3)

Special notes for your reviewer:

The test demo should be rigorous, although it is a small problem

Does this PR introduce a user-facing change?:

NONE

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.wuxian seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

这个 commit 建议重新提交一个 pr https://github.com/seata/seata-go/pull/458/commits/27b1d1de784854875cca4d8db9858f92838e5dd8


random surrogate key

⭐ when adding to bigquery and postgres, --random-surrogate-key my_surrogate_key should result in a column my_surrogate_key that is filled with generate_uuid()
this allows self-joining against tables that don't have a natural key (or natural surrogate key)
https://cloud.google.com/blog/products/data-analytics/bigquery-and-surrogate-keys-practical-approach

nevermind, this is the wrong place to implement this


Inject dependencies into constructors

This PR resolves issue #200
I have updated the commands to include some injected dependencies.  I also removed php 7.2.5 support due to takeout being updated to use phpunit 9.5 and laravel zero 8.0 which require ph 7.3 and higher.  Had to add the following to composer.json in order to get it to update in Windows. :)
"platform-check": false,
        "platform": {
            "ext-pcntl": "7.2",
            "ext-posix": "7.2"
        }

Let me know if you need me to make any changes.

Hey @mattstauffer got your requests. I will implement those changes first thing in the morning when I get to work. Sorry I got a little ahead of myself on some of those dependency injections. Using them in my windows menu PR. 😅
Thanks for the feedback! Feel like I'm learning a lot from contributing to the open source community. 🤙🏻￼

Thanks so much @delta1186! :)


⚠ Bofrost.lu has degraded performance

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

HTTP code: 200
Response time: 1897 ms

Resolved: Bofrost.lu performance has improved in 28e9f81 after 7 minutes.


Not Able to get Accuracy Score

ValueError: Found input variables with inconsistent numbers of samples: [18734, 18733]
I am able to get F1 scores when i pass test_dict  to evaluate function as model.evaluate_performance(test_dict)
but  if i pass "True"as a parameter to  model.evaluate_performance(test_dict,True) i am getting a ValueError. I crossed checked the  test_dict manually there are total 18734 samples in y_test so why is the function missing out one value in y_pred  that is the predicted number of samples ?.

It happened to me too, I think it is because NERDA model does not output predictions for sequences whose length is greater than max_seq_len


Added naive method for automating login

Added some simple JS to allow logging in with URL parameters.
Could not get docker to build on Mac, so not fully tested, nor documented.
Strongly recommend instead supporting basic auth on the serverside, so that instead of /login/?user=display&pass=foo&redir=...  it would be display:foo@ (or hidden in headers).
Hopefully this helps someone in the meantime.
:)

Technically a good idea, however this is definitely a very quick and dirty changeset. Also, as you state, it's not a very good idea to send passwords and usernames in HTTP GET parameters. Using HTTP Basic Auth isn't a solution for that either because there are various reasons why LibreSignage can't/won't use Basic Auth.
I have planned to implement a better way of authorizing and authenticating clients and I'll probably get around to working on that some time. Unfortunately I won't merge this patch, but thanks for your contribution anyway. Be sure to suggest changes in the future anyway!


Partner with us form doesn't work

When a user submits a partnership request via the form in /about-us, the data is not being sent to the backend. A 412 status code is returned with the following message: Gmail_API: Invalid grant. Please reconnect your Gmail account.

@JimmyTron This is probably up your alley


⚠ wakapi has degraded performance

In 3c7c282, wakapi (https://waka.mcha.cloud/api/health) experienced degraded performance:

HTTP code: 0
Response time: 0 ms

Resolved: wakapi performance has improved in 5588d4d after 15 minutes.


plugin not working on rutracker.org and rutracker.nl due to Cloudflare protection

Operating system
Windows
qBittorrent version
v4.4.1
Python version
Python 3.11.0.a6
Is magnet links support enabled?

[ ] Magnet links support enabled

Output
C:\Users\Admin\AppData\Local\qBittorrent\nova3>python nova2.py rutracker all archlinux
WARNING:root:Could not resolve mirror: https://rutracker.org
INFO:root:Found reachable mirror: https://rutracker.net
DEBUG:root:HTTP request: https://rutracker.net/forum/login.php | status: 200
DEBUG:root:cookiejar: <CookieJar[]>
ERROR:root:Unable to connect using given credentials.

Additional information
Plugin suddenly (08/03/2022) stopped working causing all others plugins to disappear from list, deleting the plugin solved the problem and every other plugin starts working again. Cannot install it via local file or web link. credentials working and tested by logging in and out through web browser in each mirror (.org, .net, .nl). DNS resolver for this system is <IP_ADDRESS> and <IP_ADDRESS>
I suspect that rutracker changed the method of logging in, also as of recent events, I noticed that rutracker implemented Cloudflare protection when I browse their page. Tried updating to latest python version, but problem persists.
Used plugin version: latest 2.14
logging level in rutracker.py:
Setup logging
logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger()

The same happened to me.

Thanks for the report. Indeed it seems RuTracker now uses Cloudflare. Bypassing this from the plugin might not be so easy... will see what I can do.

Thank you for taking the time, also for your work in this plugin.

I've played with the thing a few hours: Cloudflare protection is a pain to work around. It requires Javascript so that an invisible/automated CAPTCHA challenge can be solved, which then stores a cookie that is re-usable for further requests and bypasses Cloudflare for a time. Should Cloudflare be not happy with your IP (happens when you send too many requests), the automated challenge is transformed into a manual CAPTCHA.
There are two problems here:

A full-blown browser engine is required just to be able to get the CAPTCHA challenge. A simpler Javascript engine does not make the cut, as Cloudflare seems to refuse these and I could not bypass it without using a full-blown Blink or Gecko browser engine.
Due to the inherent forum structure of TorrentPier (inherited from phpBB), search results must be scraped using a lot of individual requests (max of 50 results per page). This triggers the Cloudflare protection and its manual CAPTCHA quite quickly.

Implementing all of this would complicate the plugin by several order of magnitudes, e.g. by integrating a Selenium-based solution and requiring users to install a Selenium WebDriver for their browser of choice so that the Cloudflare challenge may be solved (automatically at first, and subsequently manually as needed by prompting users).
Quite frankly, I am reluctant to do this. Even if I were to implement this mess (which is technically doable), the user experience would be mediocre at best as it requires users to manually install several third-party dependencies, and then a CAPTCHA prompt would have to be solved manually every time Cloudflare decides enough requests have been made... 😞
At this point, I'm actually wondering if it wouldn't be easier to have users manually connect on the website via their regular web browser and have them provide the Cloudflare cookie to the plugin, which would effectively be the same mediocre user experience but without implementing such a mess on the plugin's end. Not quite sure how to ease the extraction of the cookie from the browser to the plugin, though.
The whole point of the plugin was to never have to interact with the main website, and obviously the reason for implementing the Cloudflare protection is specifically so that users of tools such as this plugin come back to the main website. I would say, considering the above, that they're winning this round and the plugin is probably going to die unless a smart solution is found 😕
Any suggestions are welcome.

"At this point, I'm actually wondering if it wouldn't be easier to have users manually connect on the website via their regular web browser and have them provide the Cloudflare cookie to the plugin, which would effectively be the same mediocre user experience but without implementing such a mess on the plugin's end. Not quite sure how to ease the extraction of the cookie from the browser to the plugin, though."
I'm absolutely out of my depth about giving a suggestion, but I for one don't mind at all having to fiddle a little with requirements (the cookie conundrum cited above) to make the plugin work. For me browsing their site, without knowing the language is a PITA, even translating the site doesn't help that much, I think the users of your plugin feel the same way, in my opinion.
It's understandable that having to add layers of complexity defeats the purpose of having a plugin that 'just works' but still, we should adapt, otherwise just accept the defeat .. of this round :(
All of this is said without me having to work on the problem, and for that I thank you again.

Well, maybe we can actually still win a bit longer 😁
I just noticed only the .org and .nl domains are protected by Cloudflare, not the .net one. So for now the plugin is still usable with this mirror... albeit with a few changes released in v2.1.5, as the server now requires an additional header be provided. Hopefully this'll last a bit before bigger changes are required!

well that's a relief, for now, but still great news!!! :)

Interesting, I was fixing something else (deflate encoding) in the plugin today and I noticed the .org domain does not seem to have Cloudflare protection anymore. Will have to monitor if this fluctuates...

Interesting, I was fixing something else (deflate encoding) in the plugin today and I noticed the .org domain does not seem to have Cloudflare protection anymore. Will have to monitor if this fluctuates...

yeah, it's not there anymore. Trying to search their forums for anything related to this yields no results. Maybe it broke more things than they expected? afaik they implemented the protection due to the start of cyberwarfare a few weeks ago and the government pushing some laws about this kind of 'sharing content'. For now it seems that rutracker is in the spotlight, so I would expect more changes on their side.

.org domain now protected with Cloudflare again.

Seems like all mirrors are now Cloudflare-free... for now? :D

Seems like all mirrors are now Cloudflare-free... for now? :D

yeah, but now there's at least for me a problem with qbit, it doesn't yield results in the search engine, but if I check through CLI with CMD or Powershell, it works. Browsing through their forum I found that around past Saturday something went really wrong with their ISPs (government doing government stuff) and several users report that they can't connect to the DHT network, and that their torrents are dead, in short, peers can't see each other and they are turning to use a proxy system set up by them with a custom client. I've been keeping track on their threads (with the help of broken translation) but things don't look that good.

Re-enabled all mirrors in 88eecec8cfaa84f74fac3ebb7500dde53058fcd7, released in v2.1.9.

yeah, but now there's at least for me a problem with qbit, it doesn't yield results in the search engine, but if I check through CLI with CMD or Powershell, it works. Browsing through their forum I found that around past Saturday something went really wrong with their ISPs (government doing government stuff) and several users report that they can't connect to the DHT network, and that their torrents are dead, in short, peers can't see each other and they are turning to use a proxy system set up by them with a custom client. I've been keeping track on their threads (with the help of broken translation) but things don't look that good.

I don't know if that's the issue you had but there was an update to RuTracker which broke title parsing for the plugin, this should be fixed by 6eb36cb60719696ef729db070b57e299a94579b3, also released in v2.1.9.

Re-enabled all mirrors in 88eecec, released in v2.1.9.

yeah, but now there's at least for me a problem with qbit, it doesn't yield results in the search engine, but if I check through CLI with CMD or Powershell, it works. Browsing through their forum I found that around past Saturday something went really wrong with their ISPs (government doing government stuff) and several users report that they can't connect to the DHT network, and that their torrents are dead, in short, peers can't see each other and they are turning to use a proxy system set up by them with a custom client. I've been keeping track on their threads (with the help of broken translation) but things don't look that good.

I don't know if that's the issue you had but there was an update to RuTracker which broke title parsing for the plugin, this should be fixed by 6eb36cb, also released in v2.1.9.

yup that fixed it :D :D :D

Closing because I haven't seen CloudFlare in a while.


[TEP-0137] Rename customrun package

Dependencies:

[x] #6883

Once dependencies are merged, the PR will contain 1 commit only
Changes
The pkg/reconciler/customrun package contains a controller that
today sends cloudevents for CustomRuns. In the context of TEP-0137,
this controller will be repurposed to send events for all resources,
so the current name does not make sense anymore.
Renaming the package to "notifications", because the "events" and
"cloudevents" names are already used elsewhere and we don't want
a mass API rename for this. We might consolidate the code further
as a follow-up. The new name is also more future-proof, as the
controller may in future handle other kinds of non-cloudevents
type of notifications.
When renaming I realised that the customrun controller was being
started as part of the main controller as well as an independent
one. This PR fixes that bug as well.
Signed-off-by: Andrea Frittoli<EMAIL_ADDRESS>Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[x] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
The `CustomRun` events controller has been moved to the `pkg/reconciler/notifications` package.

/kind misc

/retest

/test pull-tekton-pipeline-go-coverage-df

/test pull-tekton-pipeline-beta-integration-tests

/approve cancel

/remove-approve

/lgtm
One question though - would this break downstream customrun implementations? Should we leave behind a simple package that type aliases to the new package?
If this is truly only for cloudevent notifications, you may also want to add a doc.go with some documentation calling this out.

Thanks @wlynch - it looks like the un-approve didn't work, so I'll address your comments as a follow-up.
The package is exclusively used to provide the ability to send cloud events for CustomRuns, it's not something that custom run controller implementors would use.
If you prefer I can introduce an alias; in https://github.com/tektoncd/pipeline/pull/6889 however I started restructuring that package in preparation for "TEP-0137", so I'm not sure an alias would be very helpful (or alternatively I will have rework that PR and the following one to keep the old methods around).


Add Optimism data in a way that conforms to the schema

Done here
https://github.com/hypercerts-org/oss-directory/pull/4


loaded event not emitted?

const browser = new Browser();
browser.on('loaded', function(){ console.log("loaded") });    // not called
browser.on('loading', function(){ console.log("loading") });  // called
browser.visit("file://project/index.html");

Hello?

Is it possible there was an error emitted, or some other problem that stopped it from loading?

It's possible, but I've switched to nightmare.


Puppeteer headless test have slightly different result depending on how nixos kvm test is triggered.

At this point I'm not expecting a solution as is quite specific, but if you have any ideas, would be happy to hear.
I'm bringing up a nixos-test using testing.makeTest from nixpkgs/nixos/lib/testing.nix, which runs chromium through a custom-packaged puppeteer to exercise a webpage in the same vm. It is all in headless mode, without X.
If I start up the test using nix-build -A theTest, there's a click expectation in the headless browser test that fails.
If I start up the test using
nix-build -A theTest.driver
tests=$(cat result/test-script) ./result/bin/nixos-test-driver

then the click expectation succeeds.
I'm somewhat puzzled - the two ways of triggering should (?) result in identical qemu options, but the result is consistent. Maybe there is some timing issue? But how can that be so consistent. Or some graphics setup issue? But the headless browser doesn't use graphics even (and the vms run in headless mode in both cases).

In retrospect, this might have been badly written test on my side. Puppeteer is an async JS API, and flakes can surface oddly. Generic Puppeteer tips:

Make sure you don't miss an await on some of the methods.
Disable or otherwise wait for animations in transitions. An element is often already "visible" when its opacity is still zero, so Puppeteer would start filling input fields. But then after the true fade-in, events might move focus around, disrupting the inputs.
Run in slowMo mode, take screenshots, or run in headed (headless=false) mode to spot what's odd.

An other difference to note: the nixos-test runs with network isolation, while starting the driver manually will have network access. Might make a difference.


Cannot read property "glob" of null

Failing when i execute "ng serve"
@angular/cli: 1.0.2
What ever node version(node: 7.7.4)  i install i am getting this error. Can some one help to fix this issue. I am completely blocked with this issue.
TypeError: Cannot read property 'glob' of null
at ObjectSchemaTreeNode._set (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:224:131)
at new ObjectSchemaTreeNode (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:209:14)
at OneOfSchemaTreeNode._createChildProperty (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:148:26)
at OneOfSchemaTreeNode._typesPrototype.schema.oneOf.map (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:161:25)
at Array.map (native)
at OneOfSchemaTreeNode (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:160:48)
at ArraySchemaTreeNode._createChildProperty (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:148:26)
at ArraySchemaTreeNode._set (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:286:39)
at new ArraySchemaTreeNode (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:267:14)
at ObjectSchemaTreeNode._createChildProperty (/usr/local/lib/node_modules/@angular/cli/node_modules/@ngtools/json-schema/src/schema-tree.js:148:26)
Version
@angular/cli: 1.0.2
node: 7.7.4
os: darwin x64
npm : 4.1.2
angular.cli.json
{
"$schema"<EMAIL_ADDRESS>"project": {
"name": "my-app"
},
"apps": [
{
"root": "src",
"outDir": "dist",
"assets": [
"assets",
"favicon.ico"
],
"index": "index.html",
"main": "main.ts",
"polyfills": "polyfills.ts",
"test": "test.ts",
"tsconfig": "tsconfig.app.json",
"testTsconfig": "tsconfig.spec.json",
"prefix": "app",
"styles": [
"../node_modules/bootstrap/dist/css/bootstrap.min.css",
"../node_modules/font-awesome/css/font-awesome.css"
],
"scripts": [],
"environmentSource": "environments/environment.ts",
"environments": {
"dev": "environments/environment.ts",
"prod": "environments/environment.prod.ts"
}
}
],
"e2e": {
"protractor": {
"config": "./protractor.conf.js"
}
},
"lint": [
{
"project": "src/tsconfig.app.json"
},
{
"project": "src/tsconfig.spec.json"
},
{
"project": "e2e/tsconfig.e2e.json"
}
],
"test": {
"karma": {
"config": "./karma.conf.js"
}
},
"defaults": {
"styleExt": "css",
"component": {}
}
}
Package.json
{
"name": "my-app",
"version": "1.0.0",
"description": "QuickStart package.json from the documentation, supplemented with testing support",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e",
"i18n": "ng-xi18n"
},
"private": true,
"keywords": [],
"author": "",
"license": "MIT",
"dependencies": {
"@angular/animations": "^4.1.0",
"@angular/common": "^4.1.0",
"@angular/compiler": "^4.1.0",
"@angular/compiler-cli": "^4.1.0",
"@angular/core": "^4.1.0",
"@angular/flex-layout": "2.0.0-beta.8",
"@angular/forms": "^4.1.0",
"@angular/http": "^4.1.0",
"@angular/material": "^2.0.0-beta.3",
"@angular/platform-browser": "^4.1.0",
"@angular/platform-browser-dynamic": "^4.1.0",
"@angular/platform-server": "^4.1.0",
"@angular/router": "^4.1.0",
"@ngx-translate/core": "^6.0.1",
"@ngx-translate/http-loader": "0.0.3",
"@types/underscore": "^1.8.0",
"angular-2-local-storage": "^1.0.1",
"bootstrap": "^3.3.7",
"core-js": "^2.4.1",
"font-awesome": "^4.7.0",
"hammerjs": "^2.0.8",
"ng2-validation": "^4.1.0",
"ngx-infinite-scroll": "^0.5.1",
"rxjs": "^5.3.0",
"underscore": "^1.8.3",
"zone.js": "^0.8.5"
},
"devDependencies": {
"@angular/cli": "^1.0.2",
"@angular/compiler-cli": "^4.1.0",
"@types/jasmine": "~2.5.38",
"@types/node": "^7.0.8",
"codelyzer": "~3.0.1",
"jasmine-core": "~2.6.1",
"jasmine-spec-reporter": "~4.1.0",
"karma": "~1.6.0",
"karma-chrome-launcher": "~2.0.0",
"karma-cli": "~1.0.1",
"karma-coverage-istanbul-reporter": "^1.2.1 ",
"karma-jasmine": "~1.1.0",
"karma-jasmine-html-reporter": "^0.2.2",
"karma-phantomjs-launcher": "^1.0.4",
"protractor": "~5.1.1",
"ts-node": "~3.0.2",
"tslint": "~5.1.0",
"typescript": "~2.3.2"
},
"repository": {}
}

Heya, do you maybe have an old angular-cli.json or .angular-cli.json in your user folder?

Hi filipesilva,
I have it '.angular-cli.json'. When i create the new application ,
For example
step 1: ng new 'my-app' // it is working (
step 2: i navigate to the path 'my-app'. Did 'npm install'
step 3: ng serve // it is throwing  same error  Cannot read property "glob" of null
Note:
goto  'my-app' applicaiton path and try to execute 'ng' command is not working
my-app user$ ng //// it is throwing  same error  Cannot read property "glob" of null
Appreciate your help. Most of the people are suffering becoz of this issue.
Thanks

I have tried the following option to resolve the issue
Steps to resolve the issue

$ pwd
it shows  —> /Users/YourName  /*** That is your Home path***/

Execute the below command to display the hidden files

$ defaults write com.apple.Finder AppleShowAllFiles true
$ killall Finder

After executing the above command you will see the hidden files.
if “.angular-cli.json” file exist under “/Users/yourname” (i.e Home Path) then remove “.angular-cli.json” file.
then navigate to your application path and try execute ‘ng’ command.

I'm going to reopen #4207, it has a lot more context about this type of problem.


Rename module.modulemap to PINRemoteImage.modulemap

This is to work around a compilation issue with Xcode 8. Pretty sure its related to this radar: http://www.openradar.me/30194818

Is this the same issue we're seeing in https://github.com/facebook/AsyncDisplayKit/issues/3232?

@nguyenhuy Yeah I think so. We should do the same in ASDK.


remove redundant Result type for byte_length() and bit_length()

Because of change of default branch to main.
See more:

https://github.com/fortanix/rust-mbedtls/issues/320

This PR need to rebase to main

bors try


feat(buildozer): add support for formatting on write, conditionally with an external binary

This patch adds support for the -buildifier flag of buildozer, which supports formatting the BUILD files it operates on with an in-built formatter, or conditionally with an external binary.

I don't mind this change but just wondering why buildoezer's builtin formatting is not good enough? Is it not the same already as of buildifier?

I don't mind this change but just wondering why buildoezer's builtin formatting is not good enough? Is it not the same already as of buildifier?

Two reasons:

Not always. I recently discovered a bug, and some light trail-following shows that Buildozer invokes build.Format() using its own logic. So there's room for error there.
Someone may have a patched buildifier executable and want to provide that as an input to buildozer. I doubt this is common, but the possibility is there (in other words, buildozer supports it).


Proposal for sidecar files

Generating high-quality clients across multiple languages can require significant amounts of metadata. One approach to this problem is just to say hey, add all your metadata to the service definition itself. The drawback is, I fear if you're generating code across say a dozen languages, the core API specification will be buried under a sea of metadata. Additionally, it requires coordination between the service authors and the client generators to share metadata definitions which may not be possible or desirable (e.g. because the API definition is provided by company A and company B is generating clients for their own use).
I propose we handle this scenario using side-car files which are able to add metadata to existing API specifications. Consider the following sidecar using the experimental projections feature:
// service.cadl
namespace SomeService;
model Pet {
  name: string;
}
@get op getPet(): Pet;

// typescript.cadl

// import metadata used by my custom TS emitter
import "myTypescriptMetadata.cadl";
using TSMeta;

projection SomeService.Pet#typescript {
  to {
    // emit an interface rather than a class
    @useInterface(Pet);
  }
}

Using the --include command line option we can then include this transform. Then, our custom emitter can enable the typescript projection when emitting a typescript client.
This approach has some nice benefits:

The service metadata remains simple and focused on the general API shapes. Handling specific scenarios can move into a sidecar.
The sidecars can apply metadata that the service knows nothing about. This would e.g. allow a team that owns the typescript emitter to annotate any services with additional metadata without sending a PR upstream.
Conventions can be established to make this easier/automatic, e.g. dropping a file with a particular name next to a cadl service definition makes it get picked up automatically.

The nice part is I don't think this needs any new language support, although it might be nice to allow projections to omit the explicit to { } block if this becomes a common scenario.
/cc @allenjzhang

Does --import not work for that already?

Yep, everything outlined here works already. This issue is more about, does this pattern seem good, should we bless it as a recommended pattern, should we work on establishing conventions/add tests/etc.

Potential Use Cases

richer content for docs
Richer examples
client side 'higher level operations'
generated tests

Additional considerations

verbosity of formatting  may be a usability concern for some use cases  [needs a proposal for an alternate format for documentation cases] {Allen}
versioning for sidecar metadata

refrerring to versioned models
doing different things for different versions

Here is an example using yaml to represent doc and examples injections. Behind the scenes will still be processed by projection, but this is more compact without the projection artifacts. The files can even be separated into doc.yaml, example.yaml to provide a concentrated view of the additional data.
This does not exclude using projections for more advanced or targeted projections.
SomeService
  Employee:
	@doc: |
	  This is very long doc string
	  2nd line
	  3rd line
	id:
		@doc: >
		  This is some description
		  that will be folded
  Employee.Get:
	@doc: |
	  This is very long doc string
	  2nd line
	  3rd line
	@example:
		- "GetExample1": ./examples/getEmployee1.json
		- "GetExample1": ./examples/getEmployee1.json

Here is an example using yaml to represent doc and examples injections. Behind the scenes will still be processed by projection, but this is more compact without the projection artifacts. The files can even be separated into doc.yaml, example.yaml to provide a concentrated view of the additional data.
SomeService
  Employee:
	@doc: |
	  This is very long doc string
	  2nd line
	  3rd line
	id:
		@doc: >
		  This is some description
		  that will be folded
  Employee.Get:
	@doc: |
	  This is very long doc string
	  2nd line
	  3rd line
	@example:
		- "GetExample1": ./examples/getEmployee1.json
		- "GetExample1": ./examples/getEmployee1.json

I don't think we should something with yaml. If we want less verbosity, more declarative or what not, then we should consider language features that we can tool, etc. For example, C# partial classes and methods have their attributes merged together, IIRC.
My fear here is that doing it with YAML won't be any easier but will have a lot of consequences. Years ago, for example FxCop suppressions were carried in a sidecar XML file and the end-to-end experience was pretty brutal IMHO.

Thing good about projection is this is part of the language. Doesn't feel like some "hack" or patching job build after the fact(autorest directives).
Feel like there might be some simplification in the projection language we might want instead.

I had some conversations with Allen offline but will share my feeling here. YAML is extremely complex and combining with cadl would have a combinatorial complexity effect that I really want to avoid.
We should focus on goals and investigate native-cadl solutions to those. One example is making projections to implicit so you don't have to add that added indent. You could also make other projection elements optional/implicit, add a new syntax form for a more light-weight function that doesn't use self, or a "method-like" thing that has the members of what its attached to in scope, or even allow projection statements top-level. The solution space is rich so I think once we get crisp on goals we can find a way to leverage our existing machinery in a way that reduces verbosity without increasing complexity, sacrificing toolability, etc.

"The solution space is rich so I think once we get crisp on goals we can find a way to leverage our existing machinery in a way that reduces verbosity without increasing complexity, sacrificing toolability, etc."
👍

Action items:

make 'to' block optional
Create specific design proposals for specific use cases that require additional / altered syntax [Brian]
Decide how projections correlate with emitters : what projection(s) are emitters expected to run? [Brian]

Universal projections [e.g. added metadata for new requirements]
Feature-specific projections (e.g. versioning, language translation)
Emitter-specific projections (e.g. user customization of emitters)

Future considerations

Add a lightweight function definition that could be called inside the projection
Merge decorators and functions
Allow sidecar files to simply specify decorator / function executions
Add a selector for namespace, to apply to all namespaces
For documentation, examples, it will be common to need to merge documentation into a versioned spec, will likely need a proposal/example for tersely describing docs and examples for versioned models.

Note on usage:
projection model#typescript {
 @doc(self.name, "My pet name")
 @doc(self.age, "My pet age")
}

will apply to all models. Similar selectors exist for:

model, interface, operation, union,
'namespace' is a possible additional selector

close for implementation issue

In the last few months I think we've learned more about how folks want to use this sidecar story and there are a few undesirable aspects the "just use projections" approach:

It brings in the additional complexity of projections and overloads the concept - the sidecar is really just using the projects as a function container (as evident by not needing the from projection)
There is too much syntax
Running the projection requires either an emitter to explicitly ask for it (necessitating some kind of convention), or some command line incantation to turn it on.
The decorators run very late, meaning other parts of the Cadl program which might be impacted by the additional sidecar decorators won't see the decorated state.

Thus, I propose a new approach: augment decorators (name is horrible please suggest better names)
Syntax
The @@ sigil leads an augment decorator. The augment decorator always takes at least one argument (the target) and so we can require this in the parser.
@@decorator(target, arguments)

For example, a sidecar file add-docs.cadl might look like:
@@doc(MyModel, "special documentation");

Combined with --include option on the command line, this enables factoring out use-case specific metadata into separate files that are included as needed.
Semantics
Augment decorators are run when the type they target is instantiated, and after any decorators that are attached to the declaration. This means that there should be no observable difference when a decorator on some type is instead moved to an augment decorator. This makes the side-car story super easy to reason about.
Implementation
In order to run augment decorators during type instantiation, we need to collect all augments across the entire program prior to doing any checking. We can do this work in the binder by building a map of target symbol -> augments. A complexity here is how to deal with late-bound symbols - we often don't know whether a model will have a property until we've computed its type via checking. We will likely need another map of [ late-bound container, symbol name ] -> augments to handle this case.
/cc @nguerrera @timotheeguerin

+1 I like this proposal. My only question is where are augment decorators allowed to occur. Wherever a statement can? Only at top level?
I also like the name "augment decorator" fine. 🙂

I think it's just a statement yeah, updated proposal to reflect. I don't think we gain much by limiting it further than that, and it might be frustrating if it has to go only at top-level given when you want to have types in the sidecar file as well (and thus likely want to use a blockless namespace).

Another update to the proposal: projections currently allows @doc(target, "contents"), this should be changed to @@doc(target, "contents") to align with this proposal.

I like it as well, the @@ syntax does feel a little weird but don't know anything better either so probably just need some getting use to.

Just thinking about alternative syntax.  Not sure if it's better, but might as well write down an idea that occurs to me.
@doc("This is special")
@yadaYadaYada
augment MyModel;

We add:
AugmentStatement :
   DecoratorList? `augment` ReferenceExpression

Possible advantages:

We continue to have a keyword at the front of every statement, which is relied upon in places.
You can add multiple decorators to something without repeating its name for each one.
We don't need to add @@ or change projection syntax

Could also make tooling easier since we wouldn't have to special case @@ vs @ in things like signature help.

IMO using the same syntax for augment and the projection is a good thing. In one case you augmenting all the time in the other with a specific projection.
if decorator worked after that would also not look too bad
augment MyModel @doc("foo")

I was thinking along those lines as I was pondering how you might augment by adding or wrapping parts of the type, e.g. to augment a member to an array you could do something like:
model Foo { x: string }

@added
augment model Foo {
  @added
  augment x: x[];
  newProp: int32;
}

would be equivalent to
@added
model Foo {
  @added x: string[];
  newProp: int32;
}

This would enable adding multiple decorators inside a model without constantly repeating the same model name.
But this is starting to look pretty complex!

I feel like the change from @ to @@ in projections is a good thing regardless of what we decide here as it enables creating decorated declarations inside projections.

But this is starting to look pretty complex!

Yeah, it's starting to look an awful lot like partial in C# and I don't think we want to sign up for that.

Concern: tooling wouldn't reflect side-car state making debugging difficult. There will be some design work to make this easy, but for now users can develop the augment decorators as regular decorators and factor them out later.
Do we want to gate these behind "feature flags" (i.e. do we somehow gate a sidecar file behind a flag name?)
Should we drop the @@ sigil and say decorators are "just functions".
We will likely need to add model properties/interface members going forward, but will tackle augment syntax with more experience.

removing dpg imnpact, asn this is covered by the client design issues (which are labeled as DPG Impact)

@markcowl if this has been decomposed to implementation issues, is there a reason this design issue is still open?

This has been implemented, so closing this issue.


OFF-EP 0005b

An alternative proposal to #30 to fix #29.
Other modifications that may be possible:

We could use solvent_dielectric to specify both reaction field dielectric constants and the Ewald boundary conditions dielectric constant (currently specified as part of the verbose Ewald3D-ConductingBoundary keyword)
We could migrate the specification of CODATA 2018 physical constants to a higher-level attribute
We could streamline or specify which physical constants are available in the potential expressions (here, pi and epsilon0 are used)
We could specify some common reaction field models (such as the OpenMM reaction field model used in SireMol) in this OFF-EP rather than relying on users to provide the complete functional form

I haven't yet updated the smirnoff.md from #30, but please take a look at the proposed alternative OFF-EP 0005.

I think I'm fine with this as well; I'd like to hear from @mattwthompson and @j-wags but it still seems relatively compact.

I don't have a seat on the committee and but since I was asked -
#30 solves, in my view, the problems we have identified as short-term blockers for version 0.11.0 of the toolkit (and a 0.2.0 release of Interchange, which will be paired with it) as I am trying to prevent #29 from creeping into Interchange. I intended for it to be unambiguously discrete in scope to the changes I need, both because I have not done research cycles on other topics and because I hoped it would be easier to review a more narrow proposal; the assumption is that it is easier to gain consensus on one move part than several. (This has been my hope with the OFF-EPs I have written, that targeted, narrow proposals would be easier to review, much like PRs to source code - even at the cost of having a larger number of proposals creating extra chatter.)
I think specifying physical constants would be an excellent improvement to SMIRNOFF, but I'm not sure it's in scope here and think it would be better split out into a separate proposal. Two questions that immediately come to mind are

How should implementations handle exports to engines that use different versions of CODATA (or a different system altogether)? Forbidding export to to i.e. GROMACS 2019 (which uses CODATA 2010) would be onerous, but allowing implementations to skip this check altogether implies it's not necessary - or should be communicated as a recommendation, not a requirement.
Assuming one doesn't wish SMIRNOFF to be on CODATA 2018 forever, what is the process for applying updates?

PME (and other methods) are permissible approximations to Ewald as long as they are controlled.

These needs clarification, presumably with coming changes to smirnoff.md. What does "controlled" mean here? What approximations are permissible, i.e. is it fine that Amber and OpenMM use different B-splines of different order?
Should the default dielectric be 78.3 (water) or 78.5 (consistency with Amber)? Does this difference matter? Separately from this proposal, it would be worth seeing if OpenFF's fitting/benchmarking pipelines are consistent - both in terms of this constant and any other changes to the electrostatics definitions.
I have no idea if the reaction field expression given in the example is supported by engines other than OpenMM; since it's not been an operational priority, I haven't dug into it and it's not a technique I'm familiar with. So I'm not able to given feedback on it except to repeat the same concern as above - if it's a requirement, it might be ignored when interfacing with slightly different implementations.
I also don't know how different engines compute electrostatics of intramolecular interactions. To be honest, it's only recently come to my attention that this is a detail that engines have opinions about.
I just need the specification revised to support the most common use case of our force fields: PME (with details possibly left unspecific) for periodic systems and something-close-to-exact-Coulomb for non-periodic systems. This proposal seems like it only adds content, if I'm reading things accurately. Assuming that updates to smirnoff.md in a final version of this proposal don't modify this, that need is met. I'm unable to provide useful feedback on some other points, though, so I will defer to the committee's judgement unless asked again.

PME (and other methods) are permissible approximations to Ewald as long as they are controlled.

These needs clarification, presumably with coming changes to smirnoff.md. What does "controlled" mean here? What approximations are permissible, i.e. is it fine that Amber and OpenMM use different B-splines of different order?

(not blocking) This would be good to answer. I don't see it as a hard blocker for my approval, and I don't know enough about PME implementations to write this in smirnoff.md myself. But I'd basically trust any reasonable scheme agreed upon by more knowledgeable committee members.

@mattwthompson @j-wags : Thanks so much for your detailed feedback!
Scope: My assumed scope differed from @mattwthompson's #29 in that I considered the scope of this OFF-EP to be "eliminate ambiguities in the definition of the Electrostatics tag", rather than "eliminate one ambiguity in the definition but leave a boatload of other ambiguities". I appreciate that there is tension between the desire to make narrowly-scoped, easily reviewable changes and the amount of additional work required to review, accept, and then implement each change, especially if this requires backward- (and possibly forward-)compatibility. I'm totally OK with implementing a series of narrowly-scoped changes if the software scientists are fine with implementing all of them, but it seems like this has the potential to create a great deal more work.

I think specifying physical constants would be an excellent improvement to SMIRNOFF, but I'm not sure it's in scope here and think it would be better split out into a separate proposal.

With my assumed scope of eliminating ambiguities, this was an ambiguity in the definition of how the potential was calculated that we need to explicitly address in this OFF-EP.

How should implementations handle exports to engines that use different versions of CODATA (or a different system altogether)? Forbidding export to to i.e. GROMACS 2019 (which uses CODATA 2010) would be onerous, but allowing implementations to skip this check altogether implies it's not necessary - or should be communicated as a recommendation, not a requirement.

If we know which constants a package uses internally to compute the potential energy from our parameters, it is trivial to adjust the parameters on export to ensure the energies match their intended values. This is only possible if we specify what physical constants we intend the spec to use. If we do not, we will just get different energies in each package.

Assuming one doesn't wish SMIRNOFF to be on CODATA 2018 forever, what is the process for applying updates?

As noted above, a future OFF-EP could explicitly specify the physical constants used at a higher level---perhaps at top level---and remove the specification of which physical constants are used from the Electrostatics tag. We could then update the physical constants as desired. This change was outside of my assumed scope, however---which was confined to just the Electrostatics tag.

These needs clarification, presumably with coming changes to smirnoff.md. What does "controlled" mean here? What approximations are permissible, i.e. is it fine that Amber and OpenMM use different B-splines of different order?

We need to agree on a criteria for this, but my assumption here is that we will first need to see some data before we can construct a criteria. One possible approach, for example, would be to curate a set of test systems for which we could provide Interchange parameters and reference energies for a true Ewald implementation, and benchmark the exported energies in other packages with a variety of settings (e.g. different pme-tolerance values in OpenMM with PME). We could then specify "your settings should reproduce these energies to within X kcal/mol maximum deviation on the provided systems and snapshots". This is but one idea, but it would provide a concrete way of determining whether the force field is correctly implemented in a package with particular settings.

Should the default dielectric be 78.3 (water) or 78.5 (consistency with Amber)? Does this difference matter? Separately from this proposal, it would be worth seeing if OpenFF's fitting/benchmarking pipelines are consistent - both in terms of this constant and any other changes to the electrostatics definitions.

We can choose not to define a default dielectric in this spec.

I have no idea if the reaction field expression given in the example is supported by engines other than OpenMM; since it's not been an operational priority, I haven't dug into it and it's not a technique I'm familiar with. So I'm not able to given feedback on it except to repeat the same concern as above - if it's a requirement, it might be ignored when interfacing with slightly different implementations.

I did not define any keywords for reaction field electrostatics because I haven't had time to review which functional forms are implemented in different packages. It will require some effort to make sure implementations are standardized or can be implemented or approximated in multiple packages. For now, the safest thing to do is either exclude them (which is inconvenient, since we know we need to support Cresset with an optimized reaction field form) or explicitly specify the functional form (which likely for Cresset with their OpenMM implementation). Some refinement of this part of the proposal may be necessary, however, if we want to easily be able to render this to NonbondedForce instead of CustomNonbondedForce in Interchange.

I also don't know how different engines compute electrostatics of intramolecular interactions. To be honest, it's only recently come to my attention that this is a detail that engines have opinions about.

These details matter for the energies they produce, so we cannot ignore them.

You and @mattwthompson have done most of the writing on this, so I'd be happy to edit the smirnoff.md file with the proposed changes, and the "Backward compatibility" section of this EP with a more thorough recommendation for up-conversion (I'll have to write an up-converter anyway, so it couldn't hurt to specify exactly what it will do). Please tell me if you'd like me to make these edits and I can do so on Monday!

@j-wags : Please feel free to make further changes to the branch directly! My goal here was to provide the basis of an alternative OFF-EP that more thoroughly addressed all identified ambiguities in the Electrostatics tag, but I am not committed to any of the specific solutions proposed here.
I'll respond to the other comments inline.

The remaining loose ends (PME details, reaction field implementation, intramolecular interactions) are each improved or not made worse by this proposal, so I don't see any reason to reject these proposals (a. I think we're in a good position to tackle them in the future.

Thanks for the changes, @j-wags!
Do we expect that (1) we will want to use a cutoff for non-periodic systems (which are primarily intended to match QM calculations) at some point in the future, and (2) we will want to at some point enable the cutoffs to be distinct in these cases? If so, this seems like a good future-proof change. I just couldn't envision a use case for either.

Do we expect that (1) we will want to use a cutoff for non-periodic systems (which are primarily intended to match QM calculations) at some point in the future, and (2) we will want to at some point enable the cutoffs to be distinct in these cases?

No opinion - my experience with cutoff potentials is limited.  @SimonBoothroyd or @davidlmobley, do you have an opinion?

Do we expect that (1) we will want to use a cutoff for non-periodic systems

The Shirts, 2017 way of testing for energy equivalence (which I would like to be able to do, https://github.com/openforcefield/standards/issues/6) uses a hard cut-off for electrostatics. But I don't know if this is something that must be supported for both periodic and non-periodic systems. I can't think of a use case outside of that (which would be strictly testing-only and never touch production).
If there is any friction associated with officially supporting this feature I'd just modify a system after preparation to do this, which is only a tiny detour away from official SMIRNOFF.

(2) we will want to at some point enable the cutoffs to be distinct in these cases?

I can't think of any cases; a cutoff being used in either periodic or non-periodic treatments should be rare and the possibility of shipping a force field using both should be vanishingly rare ... but I guess possible?

Re the question directed at me: I personally don't expect a hard cutoff for nonperiodic systems. And I don't see a use case for separate cutoffs in the two cases.
I also read everything else here and am fine with where this has ended up, so I approve this EP as written in its current form. @SimonBoothroyd ?

Ok, I think this is in good shape now. Thanks again @SimonBoothroyd for catching the inconsistencies.
The notable changes now (beyond just fixing inconsistencies) are:

There's now just one cutoff and switch_width (I've un-split it from having separate periodic_ and nonperiodic_ values)
The upconversion table has the full formula for reaction-field
switch_width, cutoff, and solvent_dielectric now default to "none" in the 0.4 Electrostatics section spec
The upconversion section recommends that, when upconverting 0.3 Electrostatics tags containing method=PME and non-none cutoff or switch_width, that those values should be upconverted to none (This will prevent massive section-compatibility headaches in workflows like "load sage and then append this other FF", trust me!)
Because cutoff/switch_width/solvent_dielectric would be required to be non-none if ANY of the three possibly-custom potentials included them, I think it'd be futile/brittle to check for all three terms in all three potentials, so I've softened the statement

Only cutoff="none" and switch_width="none" is allowed for Ewald methods---only finite-ranged methods should set these to a non-none value.

to

It is possible to define an Electrostatics section where no potential uses cutoff, switch_width, or solvent_dielectric. In these cases it is strongly recommended that these values be set to none to avoid ambiguity.


Create tx with pre-generated txkey

Since the tx private key is irrecoverable, I think it makes sense to provide some method of storing it. This PR adds an optional parameter to the create_transaction() and construct_tx() functions called txkey, so that you can generate and save the txkey, and use it to generate a transaction.
I'm unsure about how the branches work on this repo, so let me know if it's better to do a PR against develop

Hey there, yes, this is cool with me, and actually something I'm doing with the new C++ stuff. So just a heads up that we'll need to do this again. However I do want to ask you to explain the necessity to pass in the tx_key. It's not a bad thing, but it does open up the possibility that some unknowing integrator will pass a bad value. It would make sense if you want to control the source of random numbers but I don't see that being necessary (and therefore a good idea) here.

And yes, definitely do branch from develop please. It's basically the Gitflow model

My logic was you could do something along these lines:
const txkey = monero_utils.random_keypair()
const tx = monero_utils.create_transaction(...params, txkey)
// If you are using a subaddress, maybe modify txkey.pub or just get it from tx.extra
storeTxAndKey(tx, txkey)

I wanted to keep the code backwards compatible since it's such a small change, so returning the tx and txkey seemed like it might be a bit much. I can write some sort of check for txkey if that sounds good, but I'm more than happy to change my approach.

Hi Marcel, you could definitely tack on another parameter (tx key) in the success callback to SendFunds, and return the same however you want from cryptonote_utils.

Right. In any case, API changes happen. We ourselves inherited this original codebase. So I think the best we can do is prepare it to scale. But for what it's worth, have you seen what I'm doing with the serial_bridge_index? I'm sorry to say I had to take some time off over the weekend so I didn't get done my create_transactions C++ -> JS bridging of the final method, create_transactions, but I will have that ready to show you soon. It's trivial to return the tx key. Here's an example of returning multiple values.

Take a peak at #49 and see if you like my new changes


Getting error in installing wasmd on MacOS

I did the following steps to install the wasmd
git clone https://github.com/CosmWasm/wasmd.git
cd wasmd
git checkout v0.20.0
make install
But I am getting this log and it seems it brokes because of some flag that is provided but not defined.
go install -mod=readonly -tags "netgo,ledger" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=wasm -X github.com/cosmos/cosmos-sdk/version.AppName=wasmd -X github.com/cosmos/cosmos-sdk/version.Version=0.14.0 -X github.com/cosmos/cosmos-sdk/version.Commit=5828347c67a16754a43608d00746df55e416a5ec -X github.com/CosmWasm/wasmd/app.Bech32Prefix=wasm -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo,ledger"<EMAIL_ADDRESS>-trimpath ./cmd/wasmd
# github.com/keybase/go-keychain
cgo-gcc-prolog:203:11: warning: 'SecTrustedApplicationCreateFromPath' is deprecated: first deprecated in macOS 10.15 - No longer supported [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrustedApplication.h:59:10: note: 'SecTrustedApplicationCreateFromPath' has been explicitly marked deprecated here
# github.com/CosmWasm/wasmd/cmd/wasmd
flag provided but not defined<EMAIL_ADDRESS>usage: link [options] main.o
  -B note
    	add an ELF NT_GNU_BUILD_ID note when using ELF
  -E entry
    	set entry symbol name
  -H type
    	set header type
  -I linker
    	use linker as ELF dynamic linker
  -L directory
    	add specified directory to library path
  -R quantum
    	set address rounding quantum (default -1)
  -T address
    	set text segment address (default -1)
  -V	print version and exit
  -X definition
    	add string value definition of the form importpath.name=value
  -a	no-op (deprecated)
  -aslr
    	enable ASLR for buildmode=c-shared on windows (default true)
  -benchmark string
    	set to 'mem' or 'cpu' to enable phase benchmarking
  -benchmarkprofile base
    	emit phase profiles to base_phase.{cpu,mem}prof
  -buildid id
    	record id as Go toolchain build id
  -buildmode mode
    	set build mode
  -c	dump call graph
  -compressdwarf
    	compress DWARF if possible (default true)
  -cpuprofile file
    	write cpu profile to file
  -d	disable dynamic executable
  -debugtextsize int
    	debug text section max size
  -debugtramp int
    	debug trampolines
  -dumpdep
    	dump symbol dependency graph
  -extar string
    	archive program for buildmode=c-archive
  -extld linker
    	use linker when linking in external mode
  -extldflags flags
    	pass flags to external linker
  -f	ignore version mismatch
  -g	disable go package data checks
  -h	halt on error
  -importcfg file
    	read import configuration from file
  -installsuffix suffix
    	set package directory suffix
  -k symbol
    	set field tracking symbol
  -libgcc string
    	compiler support lib for internal linking; use "none" to disable
  -linkmode mode
    	set link mode
  -linkshared
    	link against installed Go shared libraries
  -memprofile file
    	write memory profile to file
  -memprofilerate rate
    	set runtime.MemProfileRate to rate
  -msan
    	enable MSan interface
  -n	dump symbol table
  -o file
    	write output to file
  -pluginpath string
    	full path name for plugin
  -r path
    	set the ELF dynamic linker search path to dir1:dir2:...
  -race
    	enable race detector
  -s	disable symbol table
  -strictdups int
    	sanity check duplicate symbol contents during object file reading (1=warn 2=err).
  -tmpdir directory
    	use directory for temporary files
  -v	print link trace
  -w	disable DWARF generation
make: *** [install] Error 2

Platform

Go go1.17.2 darwin/amd64
rustc 1.52.1 (9bc8c42bb 2021-05-09)

Please help me out to resolve this issue.

That command should work. You don't need Rust to compile wasmd.
I have never seen<EMAIL_ADDRESS>when compiling locally.
I believe it comes from LDFLAGS defined in your environment from elsewhere, which is picked up in the Makefile on line 68 (ldflags += $(LDFLAGS)).
Try the following:
echo $LDFLAGS
unset LDFLAGS
make install

I tried the same and it stop giving me any error but it is not showing up the wasmd in my system. now it ended up like this.
satyamagrawal@Satyams-MacBook-Pro wasmd % make install
go install -mod=readonly -tags "netgo,ledger" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=wasm -X github.com/cosmos/cosmos-sdk/version.AppName=wasmd -X github.com/cosmos/cosmos-sdk/version.Version=0.20.0 -X github.com/cosmos/cosmos-sdk/version.Commit=6a471a4a16730e371863067b27858f60a3996c91 -X github.com/CosmWasm/wasmd/app.Bech32Prefix=wasm -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo,ledger"' -trimpath ./cmd/wasmd
# github.com/keybase/go-keychain
cgo-gcc-prolog:203:11: warning: 'SecTrustedApplicationCreateFromPath' is deprecated: first deprecated in macOS 10.15 - No longer supported [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrustedApplication.h:59:10: note: 'SecTrustedApplicationCreateFromPath' has been explicitly marked deprecated here
satyamagrawal@Satyams-MacBook-Pro wasmd % wasmd version
zsh: command not found: wasmd


Exception Unsupported Font: .AppleSystemUIFont

Not using any custom fonts but getting this error when i try to generate the pdf. any leads?
Version: flutter 3.22.2
Platform: web
Device: MacBook Pro M1 14"
Browser: Chrome

Do you have a minimal way of reproducing the issue? Since I wasn't able to reproduce it on Chrome.

I'm seeing the same thing, for a MacOS application (presumably from the same root cause).
I've included a minimal example. It doesn't misbehave if I don't specify the style for text. That is, if the text has no style specified, it seems to work just fine.
Here's the top of the stack trace:
[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Exception: Unsupported Font: .AppleSystemUIFont
#0      TextStyleConverter.resolveFont (package:flutter_to_pdf/args/text_style.dart:66:11)
#1      TextStyleConverter.toPdfTextStyle (package:flutter_to_pdf/args/text_style.dart:39:21)
#2      TextConverter.toPdfWidget (package:flutter_to_pdf/widgets/text.dart:22:29)
#3      ExportInstance.matchWidget (package:flutter_to_pdf/export_instance.dart:176:40)
#4      ExportInstance._visit (package:flutter_to_pdf/export_instance.dart:58:29)
#5      ExportInstance.matchWidget (package:flutter_to_pdf/export_instance.dart:292:22)
#6      ExportDelegate._exportWidget (package:flutter_to_pdf/export_delegate.dart:109:30)
#7      ExportDelegate._exportPage (package:flutter_to_pdf/export_delegate.dart:121:39)
#8      ExportDelegate._exportDocument (package:flutter_to_pdf/export_delegate.dart:134:35)
#9      ExportDelegate.exportToPdfDocument (package:flutter_to_pdf/export_delegate.dart:61:18)
#10     _MyHomePageState.build.<anonymous closure> (package:pdf_apple_fonts/main.dart:59:32)

Here's main.dart:
import 'dart:io';
import 'package:flutter/material.dart';
import 'package:flutter_to_pdf/flutter_to_pdf.dart';
import 'package:path_provider/path_provider.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});
  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final ExportDelegate exportDelegate = ExportDelegate();
  final reportKey = UniqueKey().toString();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          children: <Widget>[
	    ExportFrame(
	      frameId: reportKey,
	      exportDelegate: exportDelegate,
              child: Text(
                'Sample text',
		style: Theme.of(context).textTheme.bodyMedium
              ),
	    ),
	    ElevatedButton(
              onPressed: () {
                exportDelegate.exportToPdfDocument(reportKey).then(
	          (value) => saveFile(value, 'foo'),
                );
              },
              child: const Text('Save to PDF')
	    ),
          ],
        ),
      ),
    );
  }

  Future<void> saveFile(document, String name) async {
    final Directory dir = await getApplicationDocumentsDirectory();
    final File file = File('${dir.path}/$name.pdf');

    await file.writeAsBytes(await document.save());
    debugPrint('Saved exported PDF at: ${file.path}');
  }

}

I'm seeing the same thing, for a MacOS application (presumably from the same root cause).
I've included a minimal example. It doesn't misbehave if I don't specify the style for text. That is, if the text has no style specified, it seems to work just fine.

Thanks for the example @mamarsh!
This way it was easily reproducible and I could do some investigation.
I wrapped the "Sample text" form your example in a Column and added another Text widget without any style for comparison.
The result is the following:

You can see that both Text widgets (with and without style) look exactly the same.
Thus I'd say the issue could be fixed by just handling a Text widget which uses the .AppleSystemUIFont in the exact same way as we handle Text widgets without any TextStyle / FontStyle provided.


insert into  values  select 时，seata解析sql报错

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
在插入数据时，其中的一个字段值是查询出来的，seata报错
Ⅱ. Describe what happened
在插入数据时，其中的一个字段值是查询出来的，sql日志大概如下：
SQL: INSERT INTO t_tb_a(    id,    amount,  )values(    ?,  ((select balance from t_tb_b where code = ?) - 1100.0))
If there is an exception, please attach the exception trace:
Cause: java.sql.SQLException: io.seata.rm.datasource.sql.SQLParsingException: Unknown SQLExpr: class com.alibaba.druid.sql.ast.expr.SQLBinaryOpExpr (
SELECT balance
FROM t_tb_b
WHERE code = ?

) - 1100.0
Just paste your stack trace here!

Ⅲ. Describe what you expected to happen
Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?
Ⅵ. Environment:

JDK version :1.8
OS : centos 7
Others: seata1.1.0  springcloud-alibaba 2.2.0  mybatis

@joshua-fan currently，insert into values select not support.

@slievrly  Thank you very much for your reply

ok I also pay attention

@joshua-fan currently，insert into values select not support.

wait hope solve

wait hope solve

+1

wait hope solve

@slievrly +1
INSERT INTO T_DEMO( ID, NAME, QUANTITY) SELECT NULL, 'AAAA', 1 FROM DUAL UNION ALL SELECT NULL, 'BBBB', 2 FROM DUAL UNION ALL SELECT NULL, 'CCCC', 3 FROM DUAL;

hi what do you mean?

When can it be supported?