Commit reveal Standard to FLOW

Issue To Be Solved
A generic proposal to apply commit reveal to NFT metadata. This approach is used for blind sale where we want to hide the metadata information and only then reveal it, using provenance hash to ensure that there was no manipulation in the metadata.
(Optional): Suggest A Solution
My suggestion is to create an interface with public access and apply it to the Collection, that way it would be possible for the administrator to access the NFT within the collection of a third party. Only the admin can use the interface because it requires Admin resource reference.
The interface receiving NFT Id, admin resource reference and the original metadata with all information
  pub resource interface IRevealNFT {
    pub fun revealNFT(id: UInt64, admin: &Admin, metadata: {String: String})
  }

The standard collection applying the IRevealNFT to call reveal function to a specific NFT
  pub resource Collection: NonFungibleToken.Provider, NonFungibleToken.Receiver, NonFungibleToken.CollectionPublic, MetadataViews.ResolverCollection, IRevealNFT {

    ....

    pub fun revealNFT(id: UInt64, admin: &Admin, metadata: {String: String}) {
      if self.ownedNFTs[id] != nil {
        let nft = &self.ownedNFTs[id] as auth &NonFungibleToken.NFT
        let storeFrontNFT = nft as! &NFT
        storeFrontNFT.reveal(metadata: metadata)
      } else {
        panic("can't find nft id")
      }
    }

   ....

  }

The HashMetadata struct to save the hash from a specific range of NFTs, considering that we can have multiples hash from one collection/drop
  pub struct HashMetadata {
    pub let hash: String
    pub let start: UInt64
    pub let end: UInt64

    init(hash: String, start: UInt64, end: UInt64) {
      self.hash = hash
      self.start = start
      self.end = end
    }
  }

The NFT resource with reveal function where it update the metadata field - just add here to exemplify, it is not part of suggestion
  pub resource NFT: NonFungibleToken.INFT, MetadataViews.Resolver  {
    pub let id: UInt64
    access(contract) var metadata: {String: String}
    pub let hashMetadata: HashMetadata

    ....

    access(account) fun reveal(metadata: {String: String}) {
      self.metadata = metadata
    }

    ....
  }

I've also been thinking about how to reveal on-chain metadata. I really like your proposal. I think the provenance hash is even an improvement upon existing reveal mechanisms, some of which only rely on the NFT ID to map to an off-chain file that may  or may not be content-addressable.
Is the IRevealNFT interface necessary? I see it as more of a nice-to-have. I think an admin can borrow an NFT through the normal CollectionPublic capability and then call the reveal function, which could be contract-restricted. I'm just not sure it makes sense to require the user to link an additional capability that should only ever be used once.

@psiemens Agreed, I don't think we must have the IRevealNFT interface, it's just a fancy way to be more explicit. Talking about to add on CollectionPublic, since this function will be only available to admin I don't like the idea to add on public access.

I think it is a nice concept however would it be possible to have the metadata be Traits? Then you can send in other values then strings.
So lets say I have an nft where i want to reveal the play_id and the serial of that play. They are both uint64.

I agree with @psiemens, it would be nice to have this on CollectionPublic.
Roughly I think below can work.

    pub resource interface CollectionPublic{
        access(contract) fun reveal()
    }

    pub resource Admin {
        pub fun reveal(user: Address, id: UInt64, metadata: {String: String}){
            getAccount(user).getCapability(/public/PublicMyCollectionPath)
            .borrow<&MyCollection{CollectionPublic}>()!
            .reveal(id: id, metadata:metadata)
        }
    }

I don't think we should only restrict the revealing permission to ADMIN itself, It can be done by anyone given that provided metadata hash is same as the hash provided during the mint. The reason of doing so is that there are some cases where NFTs are minted from a contract and NFT owner would not want to give the Admin resource to the minter contract or whatnot so minter contract can easily facilitate the reveal process if reveal is public to use.

Is this correctly assigned to @satyamakgec  or should it be assigned to @sisyphusSmiling ? Just want to make sure we are tracking this properly

It's probably nobody assigned to this TBH. The Commit-reveal being discussed isn't about the standard, but specifically for random. But maybe we can consider a standard after that?


⚠ ClamAV has degraded performance

In a834e89, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 443 ms

Resolved: ClamAV performance has improved in 55cc5db.


Edit text file is not working in documents section.

Describe the bug
Click on Edit button of text file throws this error.
Screenshots

not able to reproduce


HDDS-4915. Integrate CertClient.

What changes were proposed in this pull request?
This PR is to implement

Use RootCertificate server to issue certs for SCM
Use scmCertificatServer to issue certs for DN/OM. (This cert server got certs from RootCertificate Server)
Start RootCertificate server only on primary SCM.

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-4915
How was this patch tested?

PR based on #1988

Please hold on the merge util we finish merging master back to 2823. Thanks!

@bharatviswa504 thanks for working on this. Can you separate the patch into smaller ones? For example
separate the bootstrap of the non-primary from this patch and focus only on the init of primary SCM.
Otherwise, the review will take longer time.

@xiaoyuyao I understand it is a big change, sorry for the trouble. Bootstrap changes will be less than 100 LOC, but if it is still needed I can split it into a new Jira.
Actually, I have planned to implement CertClient and Integration in two parts, later when integrating found issues and closed the other one. Let me see if I can split again, but 2nd PR integration one will be dependent on this. Can we also have a call for a review?

I have split the changes into 2 Jiras HDDS-4897 and HDDS-4952.
Integration to code will do in this Jira, once the above Jiras are merged.

I have split the changes into 2 Jiras HDDS-4897 and HDDS-4952.
Integration to code will do in this Jira, once the above Jiras are merged.

Thanks for the efforts. I will look into those dependency JIRAs.

@xiaoyuyao Addressed/replied review comments these are addressed in HDDS-4897.
Can we continue the review #2041
I will update the PR to use all the Jira's which went in and integrate it.

Re-opened pull request based on HDDS-4897.

Rebased with latest HDDS-2823.

Thank You @xiaoyuyao for the review. Addressed/replied review comments.

Thank You @xiaoyuyao for the review. I have addressed review comments.

Thank You @xiaoyuyao and @GlenGeng for the review.


Expiration is overwritten in CouchbaseSessionStateProviderAsync

The session expiration can be overwritten in CouchbaseSessionStateProviderAsync causing the session expiration to be infinite.

Fixed by https://github.com/couchbaselabs/couchbase-aspnet/pull/84


TaskBuilder and JsPromise

API for executing tasks on the libuv threadpool and settling JavaScript Promise.
fn return_a_promise(cx: FunctionContext) -> JsResult<JsPromise> {
    let promise = cx
        .task(|| { /* ... */)
        .promise(|mut cx, _result| Ok(cx.undefined()));

    Ok(promise)
}

Implementation PR: https://github.com/neon-bindings/neon/pull/789

This is freaking amazing.

For high level APIs that reduce complexity and closure nesting, I propose:
// Wraps with a `try_catch` and resolves/rejects based on the `JsResult`
// Without GAT, because of the lifetime on the result, this might need to return `JsValue` instead of `T: Value`
Deferred::and_settle(self, f: impl FnOnce(cx: TaskContext) -> JsResult);

// On queue, to remove the `.send(move || {})` closure boilerplate:
// Calls `Deferred::and_settle` for you
EventQueue::send(&self, f: Impl FnOnce....)

For high level APIs that reduce complexity and closure nesting, I propose:
// Wraps with a `try_catch` and resolves/rejects based on the `JsResult`
// Without GAT, because of the lifetime on the result, this might need to return `JsValue` instead of `T: Value`
Deferred::and_settle(self, f: impl FnOnce(cx: TaskContext) -> JsResult);

// On queue, to remove the `.send(move || {})` closure boilerplate:
// Calls `Deferred::and_settle` for you
EventQueue::send(&self, f: Impl FnOnce....)

A couple of potential issues with this RFC.
Lifetime Inference
Since the closure in settle_with takes a borrowed TaskContext, users may run into a lifetime inference issue if the closure is saved to a variable instead of passed directly to the function.
395 |                 .try_settle_with(deferred, callback)
    |                  ^^^^^^^^^^^^^^^ one type is more general than the other
    |
    = note: expected enum `Result<neon::handle::Handle<'_, _>, _>`
               found enum `Result<neon::handle::Handle<'a, _>, _>`

This issue is avoided if an owned TaskContext is passed. Since Neon owns the lifetime, we can give an owned TaskContext to ease this case. We may also want to consider doing the same in try_catch.
This is a breaking change and needs to be decided prior to merging.
Promises and synchronous exceptions
One advantage of using async function() {} over a function() {} that returns a promise is that the function is guaranteed to always return a Promise. Synchronous exceptions are transparently converted into rejections. This is cumbersome to do in Neon because it requires using try_catch and handling the result. I propose a new helper JsPromise::try_catch for performing this.
fn never_throws_synchronously(mut cx: FunctionContext) {
    Ok(JsPromise::try_catch(|cx| {
        let n = cx.argument::<JsNumber>(0)?.value(cx);

        cx.task(move || n + 42)
            .promise(|cx, n| Ok(cx.number(n)))
    }))
}

The downside of this approach is that it still requires careful code to avoid an unhandledRejection when using cx.promise(). The (deferred, promise) pair shouldn't be created until after all code that can be thrown synchronously.
Alternatively, we could provide a Deferred::try_catch that uses the existing promise to avoid this gotcha. However, I'm not sure how to align these two use cases. A user could still stumble onto the JsPromise::try_catch version which is better suited towards TaskBuilder::promise.
fn never_throws_synchronously(mut cx: FunctionContext) {
    Ok(cx.try_promise(|cx, deferred| {
        let n = cx.argument::<JsNumber>(0)?.value(cx);
        let channel = cx.channel();

        std::thread::spawn(move || {
            let n = n + 42;

            channel.settle_with(deferred, move |cx| Ok(cx.number(n)));
        });

        Ok(())
    }))
}

This is an extension and can be added later without causing any breaking changes.

@kjvalencik So you mean settle_with and try_settle_with should take an owned TaskContext, yes? That seems fine to me.

We may also want to consider doing the same in try_catch.

Are you talking about a backwards-incompatible change to the existing cx.try_catch() API, or are you talking about one of the try_catch proposals you're making in the second half of your comment? I'm not quite following the "Promises and synchronous exceptions" section, it seems like there are several different hypothetical APIs in play here, some of which might be typos but I'm not sure?

JsPromise::try_catch
Deferred::try_catch
Context::try_promise

This sentence was hard to follow in particular:

A user could still stumble onto the JsPromise::try_catch version which is better suited towards TaskBuilder::promise.

@dherman I meant a breaking change to cx.try_catch (which is still feature flagged).
These are several different proposals for similar things. The idea is we should make it easy for a user to write a Neon function that always resolved or rejects a promise instead of throwing an error synchronously.
The issue I'm having is I haven't been able to come up with a single API that works for both TaskBuilder and Context::deferred.

After some testing, moving to an owned TaskContext does not resolve this issue. With that said, I think it should still get an owned TaskContext for consistency.

Merged in https://github.com/neon-bindings/rfcs/commit/2e6c1f1f9a594a636a8206665d6263652284ed1b


Fix EventStore.getConsumer returning Consumer instance

This change removes the EventUnwrapper transform stream from EventStore.getConsumer(), which made the method return a stream.Transform instead of an instance of Consumer.
This means that the Consumer from an EventStore receives stored event structures, which constist of { stream: string, payload: object, metadata: object }, where payload corresponds to the original event that was committed.
Resolves #172

Coverage decreased (-0.008%) to 97.718% when pulling 38a56944afdc05847ae5511139459e711df66035 on consumer-fixes into 8a6d93a836e9ebb7c8e2ae12961b970253a9481e on main.


Open New tab by duplicate current tab not open the default Home Directory

What's the Problem?
Right now Files open new tabs by go to Home folder
Solution/Idea
It will be great to have an option in preference that allow it by default open new tabs by duplicating current tab instead.
And maybe another option in preference to allow user choose where is the default folder.
Alternatives
Or Ctrl + T = Open new tab to default home folder
Ctr + D = Duplicate current tab
Priorities
| This proposal will allow end users to quickly open folder instead of going back to default folder since Files quite laggy with big folders | Should |
Files Version
Version: <IP_ADDRESS>
Windows Version
Windows 10.0.19044.1466
Comments
No response

#7901 added a shortcut to duplicate tabs.


Get (x) berries in pico-8 and Read diary in elevator shaft dont get recognized as achieved

As the title says

I found the bug behind the pico berries, and that's fixed, but I wasn't able to reproduce the diary problem.

As of 0.0.9, reading the diary ticks off as intended.


[FEATURE] Submit websocket validations to registry api

DEC-559

Test is failing due to current crawler api instance not being publicly accessible.

Awesome :+1:

:100:


allow to guess external ip for shell command

Allow RPC to remote service from shell.
$ lymph shell --guess-external-ip
...
In [1]: client.proxy('echo').upper(text='abc')
Out[1]: 'ABC'

(assuming that echo runs remotely)
As for why, check here:

https://github.com/deliveryhero/lymph/blob/master/lymph/cli/main.py#L28
https://github.com/deliveryhero/lymph/blob/master/lymph/cli/main.py#L68

LGTM


Hi issue found with mobile app of zen

The qr code not responding with desktops wallet . It feels as a separate cold storage wallet . It responded to an online zencash as I put an address , tho it did not register as transaction happening on zen desktop through zenonlineclaim

Hi @Cryptonewsmedia , could you please open a ticket here: https://support.horizen.global/ this way our support team can give you a faster response on your issue. thanks in advance!

hey there @Cryptonewsmedia
There is no current compatibility of QRs for our products, we already have this issue already noticed.
In the future, we are going to be making sphere mobile which is going to be fixing this issue. As of now, we have been limited in resources and we do not have defined date of when this is going to happen. Please be patient and I'll keep you on the loop. Regards

ok.confirmed.solved


React native JS Engine and Foreground Service

Description
I am working in an application where we need to make sure the application stays alive in the background. We are using foreground service for it. (Already used START_STICKY). We also enabled Hermes engine in application.
Issue comes when Android OS kill our app due to any/random reason (not crash), Application instance and Foreground service gets re-created as it is declared as START_STICKY. But React-native JS engine does not get re-created.
We have some classes and manager declared in React-native which are not getting created due to this.
2022-04-13, 11:44:54 a.m. | INFO | ["DataConsumer -> Received hr data ",{"hr":76,"error":null,"mean":76,"std":2.7460647515915926,"snr":1.9386964917651681,"R2RAmp":11624.456661888753,"channel":1,"quality":100,"computedHR":0,"timeTaken":134,"startTime":1649864694235,"isRHR":true,"save":true,"leadState":81}]
2022-04-13, 11:44:54 a.m. | INFO | ["DataConsumer -> Saving hr data ",{"hr":76,"error":null,"mean":76,"std":2.7460647515915926,"snr":1.9386964917651681,"R2RAmp":11624.456661888753,"channel":1,"quality":100,"computedHR":0,"timeTaken":134,"startTime":1649864694235,"isRHR":true,"save":true,"leadState":81}]
2022-04-13, 11:44:57 a.m. | INFO | ["DataConsumer: Saving the ECG array for channel 1 with length of :",296400]
2022-04-13, 11:44:59 a.m. | DEBUG | ["DataValidationService: Acc Counter: 2822571"]
2022-04-13, 11:45:01 a.m. | INFO | ["DataConsumer: Saving the ECG array for channel 2 with length of :",296400]
2022-04-13, 11:45:02 a.m. | DEBUG | ["DataValidationService: Temperature 3692. Timestamp:<PHONE_NUMBER>"]
2022-04-13, 11:45:03 a.m. | INFO | ["DataConsumer: Saving the ECG array for channel 3 with length of :",296400]
2022-04-13, 11:45:13 a.m. | DEBUG | ["DataValidationService: Ecg Ch: 1, Lead state 1. Counter: 2837265"]
2022-04-13, 11:45:13 a.m. | DEBUG | ["DataValidationService: Ecg Ch: 2, Lead state 1. Counter: 2837265"]
2022-04-13, 11:45:13 a.m. | DEBUG | ["DataValidationService: Ecg Ch: 3, Lead state 1. Counter: 2837265"]
Wed Apr 13 11:45:17 EDT 2022 ForegroundService onCreate called
Wed Apr 13 11:45:18 EDT 2022 ForegroundService onStartCommand
2022-04-13, 12:13:07 p.m. | INFO | ["App: Creating UI"]
2022-04-13, 12:13:07 p.m. | INFO | ["GlobalManager: Starting Managers ... ","2022-4-13 12:13:7"]
2022-04-13, 12:13:07 p.m. | INFO | ["GlobalManager: The build is debug? ",false]
2022-04-13, 12:13:07 p.m. | DEBUG | ["Is Internet connected?",{"details":{"isConnectionExpensive":false},"isInternetReachable":true,"isConnected":true,"type":"wifi"}]
2022-04-13, 12:13:07 p.m. | DEBUG | ["RemoteConfig -> Current environment swithched to","prod"]
2022-04-13, 12:13:07 p.m. | DEBUG | ["App is in foreground",null]
2022-04-13, 12:13:07 p.m. | INFO | ["GlobalManager: DB Initialized"]
2022-04-13, 12:13:07 p.m. | DEBUG | ["Auth manager -> The environment on initial Auth check is ","prod"]

Version
0.66.1
Output of npx react-native info
System:
    OS: macOS 11.5.1
    CPU: (8) arm64 Apple M1
    Memory: 134.31 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.17.6 - ~/.nvm/versions/node/v14.17.6/bin/node
    Yarn: 1.22.10 - /opt/homebrew/bin/yarn
    npm: 8.1.1 - ~/Myant-skiin-health-RN/node_modules/.bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.2 - /opt/homebrew/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
    Android SDK:
      API Levels: 28, 29, 30, 31
      Build Tools: 28.0.2, 28.0.3, 29.0.2, 30.0.2, 30.0.3, 31.0.0, 31.0.0, 31.0.0, 31.0.0, 33.0.0
      System Images: android-25 | Google APIs ARM 64 v8a, android-29 | Android TV Intel x86 Atom, android-29 | Intel x86 Atom, android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom_64, android-29 | Google Play Intel x86 Atom, android-29 | Google Play Intel x86 Atom_64, android-30 | Android TV Intel x86 Atom, android-30 | Google TV Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom_64, android-30 | Google Play Intel x86 Atom, android-30 | Google Play Intel x86 Atom_64, android-S | Google APIs ARM 64 v8a, android-S | Google Play ARM 64 v8a
      Android NDK: Not Found
  IDEs:
    Android Studio: 2021.1 AI-211.7628.21.2111.8193401
    Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_302 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: ~17.0.2 => 17.0.2
    react-native: ~0.66.1 => 0.66.1
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

Open app with Foreground Service.
Keep application in background Overnight

Snack, code example, screenshot, or link to a repository
No response

Anyone?


Update Node.js to latest LTS

Tool name
Node.js
Tool license
MIT
Add or update?

[ ] Add
[X] Update

Desired version
v16 Current LTS
Approximate size
No response
Brief description of tool
No response
URL for tool's homepage
No response
Provide a basic test case to validate the tool's functionality.
No response
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[X] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11
[ ] Windows Server 2016
[ ] Windows Server 2019

Can this tool be installed during the build?
No response
Tool installation time in runtime
No response
Are you willing to submit a PR?
Sure

The form didn't really provide any option to add "other" information.
Currently in the Ubuntu 20 container (and all other containers) the highest installed Node.js version is 14 but the current LTS version is 16.
Even though it is possible to install a different version it would imo be better to follow the LTS versions.
Node.js LTS timeline: https://nodejs.org/en/about/releases/

@catthehacker You are right 😅 Strange that they release it but not as LTS yet. I am used to other softwares where when they release the next LTS version it will be so on release and not 6 months after first release.

Confusing according to what and how everyone does but I think it's because they want to iron out major issues before people who like stability (e.g. corporations) switch to that version.

Hi @Glennmen! As @catthehacker mentioned Node 16 is not LTS till October that's why we stay on 14 and don't add 16 to the pre-cached versions as well. Here is our software support policy
https://github.com/actions/virtual-environments/blob/main/docs/software-and-images-guidelines.md

The recommended way is to use https://github.com/actions/setup-node action, which enables you to install any Nodejs version in a moment.
I'm going to close the issue, but please feel free to contact us if you have any concerns.
Thank you!


add support for showInputError() and close()

closes #39
expose SweetAlert.showInputError and SweetAlert.close functions (in both cases delegate them to window.swal, just like everything else does)

@oitozero thanks for the merge! :raised_hands:  you'll need to update the minified source


Deriving types for QueryResult Records (and the Option of)

As the query results are Any, how do you suggest deriving types for the values?
For example:
val temperature: Double = record("temperature").asInstanceOf[BigDecimal].toDouble

but that seems nasty. Do you retain the type from the JSON wire format? Any fancy implicit encoders available?
Similarly, how do you advice handling values which may be not there, e.g.
val maybeTemperature: Option[Double] = record("maybeThere") ...

Would be nice, but as it stands I can get NoSuchElementException when I request something that isn't there.
I had a poke around but couldn't find anything obvious.
Thanks in advance

@tobyweston, in the first case I'm not sure what a good solution could look like, as these types can be different for each row. Maybe we could add type parameters to the query for when you know the types in advance and just fail the query if one row doesn't match. What do you think?
And yes, records should return Options instead of throwing an exception. Right now you can only surround it with a try-catch.

Yeah, that's the best I can think of, something like:
val temperature: Double = record("temperature")

Where Double should be enough for an implicit conversion method to kick in?
def toDouble(any: Record): Double = any.asInstance[BigDecimal].toDouble // with some error handling

or maybe
def toDouble(any: Record): Option[Double] = {
    Try(any.asInstance[BigDecimal].toDouble).toOption
}

to handle the error and absence of the value at the same time?
I don't know if there are other constraints within the codebase that make implicits not a good option but from a client API perspective, i'd certainly prefer not to have to care how types are pulled back. I haven't tried it yet so hypothetical ATM 👍


Update schema to use new definitions groups

Preparing a minor patch-release to update the pipeline schema.
See https://github.com/nf-core/tools/issues/696

You have put tomorrow's data in the CHANGELOG so happy to release both pipeline's tomorrow unless there is an urgency to get it out? Should I be waiting for you guys to be happy with the changes you are about to make to nf-core/tools? What I am asking is is this likely to change now? 😅

Yup - so this change will break the Launch functionality on the nf-core website. I still need to update that. I'm hoping to do that today, then maybe we can merge / deploy that tomorrow and do the releases at the same time?

Cool. I am no rush so when you guys are happy and tested everything just let me know.

Added new schema linting tests to check the schema title etc: https://github.com/nf-core/tools/pull/695/commits/66968f54b793b64c72391911f4722906d3073178

The CI test to push the new Docker image is being skipped here @ewels 🤔 Is this expected? Will the Docker image for the release be pushed to DockerHub automatically?

Yeah, it only runs on push or release, not pull-request:
https://github.com/nf-core/chipseq/blob/048fd6854fcc85b355c61dfc2e21da0bcc6399ea/.github/workflows/ci.yml#L101
Should move this chunk into its own YAML file really, then it won't show up as being skipped.


configury: use gnulib memrchr on hosts without native implementation

bootstrap.conf (gnulib_modules): Add memrchr.
Makefile.am (AM_CPPFLAGS): Make sure to pick declarations from
gnulib generated replacement headers.

I'm sorry, I wish I'd caught this earlier. I don't think we can use gnulib code, since luaposix is MIT-licensed, and in any case, memrchr is not, as I thought when I added it, an ANSI function. (There shouldn't be any functions in luaposix that aren't in POSIX.) Finally, we don't use memrchr in Lua Zile (any more), so I can safely remove it.

No problem.  As long as it compiles and runs, I'm happy :)
Did you mean C Zile?  I've never noticed any memrchr dependency in Lua Zile previously...


Add consul support for security-proxy-setup to retrieve configuration file.

Currently security-proxy-setup gets the configuration file either from the local file system or command line parameters. The option to retrieve configuration from consul ( similar to other microservices ) needs to be added.

One thing I noticed was that we are using the TOML type List/Array for the SNIS configuration property which is mapped to a slice of strings([]string).
This property:
https://github.com/edgexfoundry/edgex-go/blob/a8c98aa17145faa549b1f7c47218a0b48e2b4e89/cmd/security-proxy-setup/res/configuration.toml#L51
gets loaded into this field:
https://github.com/edgexfoundry/edgex-go/blob/bffbfbb22ffcf4af19cdb9abd2bfdafab25ed54a/internal/security/proxy/kongParameters.go#L90
This might be a problem when populating Consul via config-seed as the result will be a directory named SNIS and entries where the key is the slice index(i.e. 0,1,2,etc.) and the values being the strings(in this case edgex-kong). I am not sure if this is how you represent Lists in Consul, I did some digging and could not find anything. The other half of the issue is that the current unmarshaling mechanism we are using will panic when trying to load the configuration with the layout created by config-seed. I wanted to make a note of this so that if we find away around this I would like to also apply that to the pattern we use when integrating the SecretClient into the core-services and loading this configuration:
https://github.com/AnthonyMBonafide/edgex-go/blob/2e28b9be966421ef6321ac3a0cb60d92e0ca15f1/cmd/core-data/res/configuration.toml#L62

@AnthonyMBonafide , good catch on this. The problem is that Arrays are not supported by the Consul API we use to pull the configuration from Consul. We need avoid use of arrays and use CSV strings in these cases.

Since it is decided that no configuration changes for Geneva and we will be introducing break change for the next major release, I would propose an option as below:

Leave the code and configuration as it for Geneva,
For the next major release, we need to change the SNIS from array to CSV string so that the SNIS will be like this

SNIS = "edgex-kong,localhost,whatever"

Before calling SNIS directly, we may need a function call to convert CSV string to array

https://github.com/edgexfoundry/edgex-go/blob/66410e18d718e37ade8ffa971b6c490420a0802d/internal/security/proxy/service.go#L176

# something like below:
Snis: FromCVStoArray(s.configuration.SecretService.SNIS)

Leave the code and configuration as it for Geneva,

@tingyuz , this was like this in Fuji? Doesn't it cause a panic when reading it back from Consul? I.e. this is a bug that needs to be addressed.

@tingyuz , never-mind, I didn't look at the topic for this issue. So it currently ins't using consul.... so no bug.

This is being covered by https://github.com/edgexfoundry/docker-edgex-consul/pull/26

This issue was discussed in security wg meeting on April 15th ( meeting notes reflects the details ). Bryon suggested to move this configuration to internal since no customer seems interested in the feature for now. We will check with Tony and make decision.

I'm not sure what move this configuration to internal means?

Instead of exposing the configuration through config file, Bryon's proposal is to make it as part of internal structure so customers won't be able to modify it.
I am OK to push it back to icebox for the future version as it is same as the point 1 in my previous comments.

This is in core working backlog.  It appears to be worked in security WG.  Is there a part of this that is core WG?  Putting this in Core WG icebox for now too.

during security pre-wire planning the security working group decided we will close this as won't fix. Reasoning and discussion is in the recorded zoom as well as recorded on the security working group pre-wire wiki document


On Windows 11 the Bloatware-Removal-Utility.bat doesnt start/open when running as administratror.

Clicking on the BRU gui .bat as admin doesn't do anything. It also doesn't work when placing the streams.exe in the BRU-uninstall-helpers folder.

You right clicked then run as admin right? Not just clicked on it when logged in as admin?
It is probably your antivirus stopping it. If there are any logs at c:\BRU can you attach them here?

If there are any logs at c:\BRU can you attach them here?

File explorer says windows can't find C:\BRU.

If no logs that means it didn't run so your antivirus probably killed it prior to running. HP wolf security does this sometimes. What AV was on that machine?

closing due to no response


Suppressing the run summary generated when a wandb process finishes?

Hi,
I have to write my code to handle both multiprocessing (ray) and without multiprocessing, and I believe the easiest way to use wandb for this is to wrap all calls that use wandb in a context manager, e.g.,
with wandb.init(project='project', reinit=True) as run:
    train(run)

with wandb.init(project='project', reinit=True) as run:
    evaluate(run)

However, every time the context ends, wandb prints the run summary, with a huge number of metrics printed to the console. Can I suppress this summary in some way?

Actually, even this doesn't work for what I am trying to do. It creates a new run in the wandb client for every call to wandb.init. Is there any way for me to log to a single run using this approach?

Hey @alsuhr-c yep, setting your own globally unique run id with wandb.util.generate_id() or just storing the result of your first wandb.init call will allow you to start the second run by setting wandb.init(id=stored_id, resume="allow").  Assuming these scripts run serially and not in parallel.  To suppress output of summary information set the environment variable WANDB_SILENT=true
https://docs.wandb.com/library/environment-variables#optional-environment-variables

Is resume="allow" necessary for this? It seems like I can get the same behavior without this flag -- just want to make sure it is necessary?
On the answer to my other question -- thanks!

Resume will ensure future calls to wandb.log have the appropriate "step" associated with it.  Without it, calls to wandb.log will begin at 0.

Ah I see, thanks. I am explicitly setting the step index whenever I log to wandb, so this is why it has worked.


fix: add blank line to do release

Again approving myself since this is just to do workflow stuff

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Build error due to Legacy Build System

Context
Currently, you cannot build master branch due to libde265-Xcode at 1.0.8 due to Cartfile.resolved using Legacy Build System which is now deprecated in Xcode 13.4.
I created this issue in libde265-Xcode asking to release a new version in Carthage so this project can use it.
Workaround: specify dependency to point to at least 43a87a1bef850fed5646875d2e965e349ceef3aa.
Steps to repro

git clone git@github.com:SDWebImage/SDWebImageHEIFCoder.git
carthage update --platform iOS

 henrique@Henrique-Valcanaia-MacBook-Pro: ~/Developer/SDWebImageHEIFCoder: master: carthage update --platform iOS
*** Fetching libheif-Xcode
*** Fetching SDWebImage
*** Fetching libde265-Xcode
*** Checking out SDWebImage at "5.12.5"
*** Checking out libde265-Xcode at "1.0.8"
*** Checking out libheif-Xcode at "1.9.0"
*** xcodebuild output can be found in /var/folders/xp/l3qg7cxs1kg8hqy4lxd4dpj40000gn/T/carthage-xcodebuild.dlsvI3.log
*** Building scheme "libde265-iOS" in libde265.xcodeproj
Build Failed
	Task failed with exit code 65:
	/usr/bin/xcrun xcodebuild -project /Users/henrique/Developer/SDWebImageHEIFCoder/Carthage/Checkouts/libde265-Xcode/libde265.xcodeproj -scheme libde265-iOS -configuration Release -derivedDataPath /Users/henrique/Library/Caches/org.carthage.CarthageKit/DerivedData/13.4_13F17a/libde265-Xcode/1.0.8 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive VALIDATE_WORKSPACE=NO -archivePath /var/folders/xp/l3qg7cxs1kg8hqy4lxd4dpj40000gn/T/libde265-Xcode SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/henrique/Developer/SDWebImageHEIFCoder/Carthage/Checkouts/libde265-Xcode)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/xp/l3qg7cxs1kg8hqy4lxd4dpj40000gn/T/carthage-xcodebuild.dlsvI3.log

The lib*  C library, should match the upstream version. So I think I can only fix the new version, however libdav1d seems 2 years no new commit :(
The libheif and HEICoder can bump the version and fix this.
And, Carthage support is no mantainess for long-time from 2020...SwiftPM and CocoaPods is the preferred way

A tricky way is to release a libde265 1.0.9-beta.
I found that HEIFCoder and libheif does not contains the wrong Xcode settings

Pushed: https://raw.githubusercontent.com/CocoaPods/Specs/3c007f412cd28c1447c39c429604ceb55c2cee56/Specs/1/0/4/libde265/1.0.9-beta/libde265.podspec.json

You just need to upgrde the libde265, ensure it's pointed to 1.0.9-beta +

Thank you for the fast response!


deriveAutomaticModuleNamesFromFileNames Breaks with Dagger

Here's a minimalistic repro using deriveAutomaticModuleNamesFromFileNames:
Java file:
package org.example;

import javax.inject.Inject;
import javax.inject.Singleton;

@Singleton
public final class Empty {

    @Inject
    public Empty() {}
}

Dependencies block:
dependencies {
    annotationProcessor("com.google.dagger:dagger-compiler:2.48.1")

    implementation("javax.inject:javax.inject:1")
}

Error:
Execution failed for task ':lib:compileJava'.
> Could not resolve all files for configuration ':lib:annotationProcessor'.
   > Failed to transform javac-shaded-9-dev-r4023-3.jar (com.google.errorprone:javac-shaded:9-dev-r4023-3) to match attributes {artifactType=jar, javaModule=true, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for ExtraJavaModuleInfoTransform: /home/mike/.gradle/caches/modules-2/files-2.1/com.google.errorprone/javac-shaded/9-dev-r4023-3/72b688efd290280a0afde5f9892b0fde6f362d1d/javac-shaded-9-dev-r4023-3.jar.
         > javac.shaded.9.dev.r4023: Invalid module name: '9' is not a Java identifier

This is because this is one of the cases where a Module Name cannot be derived from the Jar name (see ModuleFinder Javadoc). If you put the (unmodified) Jar onto the --module-path of java directly you get the same error:
$ java --module-path javac-shaded-9-dev-r4023-3.jar
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for javac-shaded-9-dev-r4023-3.jar
Caused by: java.lang.IllegalArgumentException: javac.shaded.9.dev.r4023: Invalid module name: '9' is not a Java identifier

Which means in this case you need to define a different name explicitly for com.google.errorprone:javac-shaded using automaticModule(...). Which is an advantage of using this plugin over giving the unmodified Jar to java. The unmodified Jar will never work on the Module Path as it is.

A special thing in this setup is that the Jar is on the annotation processor path. You might not care about these Jars turned into modules. If that is the case, you can deactivate what this plugin is doing (the Jar Transformation) for the annotationProcessor configuration:
configurations {
    annotationProcessor {
        attributes { attribute(Attribute.of("javaModule", Boolean::class.javaObjectType), false) }
    }
}

See: https://github.com/gradlex-org/extra-java-module-info#how-do-i-deactivate-the-plugin-functionality-for-a-certain-classpath

This does go against the "Can't things just work™ without all that configuration?" branding of deriveAutomaticModuleNamesFromFileNames, though. And "things just work™" in Maven.
In Gradle, module-info.java would look like this if you take a dependency on Dagger:
module org.example {
    requires dagger;
    requires java.compiler;
    requires javax.inject;
}

Without this plugin, you would get a module not found error for requires javax.inject.

Now here's what would happen with various options:
1. Maven
Things just work™. You will get this warning, though:
[INFO] Required filename-based automodules detected: [javax.inject-1.jar]. Please don't publish this project to a public artifact repository!

2. deriveAutomaticModuleNamesFromFileNames, for Direct Dependencies Only
I am fairly confident that this option would work. IIUC, to fix the compilation error, the only dependency that needs to be transformed to an (explicit) automatic module is javax.inject:javax.inject. (Transforming transitive dependencies is nice as well, but IIUC, it's not needed to make the build succeed.)
(The one edge case here could be if you require'd a module, but you didn't list the corresponding dependency in the dependencies block of build.gradle.kts; it got pulled in as the transitive dependency of another dependency.)
3. deriveAutomaticModuleNamesFromFileNames, for Transitive Dependencies
This is how the plugin currently behaves. This is where we run into the issue with javac-shaded-9-dev-r4023-3.jar.

To get back to a "things just work™" state, one fix would be to just allow those "special" filename-based automodules to exist as-is, and not attempt to transform those. Dagger is a fairly popular dependency injection framework.
It does look like that "special" JAR is only pulled in by the com.google.dagger:dagger-compiler annotationProcessor dependency; it's not pulled in by the com.google.dagger:dagger implementation dependency. Another option is to add a note to the "Can't things just work™ without all that configuration?"; this note would include that configuration {} snippet. A build engineer like yourself can fairly easily diagnose that error, but a typical software developer may not easily figure out the fix.
The potential downside with the latter option is that we're overfitting to Dagger; we may learn later that some other popular implementation dependency pulls in a "special" JAR as a transitive dependency. In which case we're back to ground zero.

An additional note on the solution when trying it in a real-world context (as opposed to a minimalistic repro): you may also need to do this for testAnnotationProcessor as well:
configurations {
    annotationProcessor {
        attributes { attribute(Attribute.of("javaModule", Boolean::class.javaObjectType), false) }
    }
    testAnnotationProcessor {
        attributes { attribute(Attribute.of("javaModule", Boolean::class.javaObjectType), false) }
    }
}

If you have a multi-module build that use the java-test-fixtures plugin (and we assume that you want to put this configuration block in buildSrc), it's a bit more complex:

Add `java-test-fixtures` to the plugin block of buildSrc/src/main/kotlin/[package].java-conventions.gradle.kts (as opposed to adding it to individual modules that have test fixtures).
You can then add the corresponding testFixturesAnnotationProcessor configuration to your configuration block.

(If you add the java-test-fixtures plugin to individual modules, then the configuration block in the buildSrc conventions file won't have access to testFixturesAnnotationProcessor.)

The problem is not about javax.inject-1.jar but about javac-shaded-9-dev-r4023-3.jar which is on the annotation processor path.
If you put com.google.dagger:dagger-compiler:2.48.1 and its transitive dependencies (that include com.google.errorprone:javac-shaded:9-dev-r4023-3) on the --processor-module-path directly, you get the same error from javac. It's just that the build tools ofter do not yet use the new --processor-module-path but put everything on the classpath-based --processor-path. That's why I wrote you might not care about the processor Jars being modules.
You can disable this plugin for all annotation processor paths by doing it for all source sets. I have updated the Readme to contain this as well:
sourceSets.all {
    configurations.getByName(annotationProcessorConfigurationName) {
        attributes { attribute(Attribute.of("javaModule", Boolean::class.javaObjectType), false) }
    }
}


Wrong flag for Croatia

Stripes have slightly different height. They must have equal height.

Fixed in https://github.com/lipis/flag-icon-css/commit/d3f57d3ec4293bf7b66a126ec4fbd24f79c8249b


Discord recipe

If I'm not wrong, https://github.com/deployphp/recipes have been archived and many recipes have been moved into the main repository. But here I don't see Dicord recipe listed.
Is it possible to move it to the main repository?
Thank you very much.

Hey! Yes, let’s do that! Would you mind to add one as a PR?


Task2: Added some graphs using plotly

In part 2 of my notebook, I have made 4 plots using Plotly according to different criteria.

Good work, you can work on task 3!!


release: 0.20.0

Issue #, if available:
Description of changes:
Checklist:

[ ] Write Design Document (Do I need to write a design document?)
[ ] Write unit tests
[ ] Write/update functional tests
[ ] Write/update integration tests
[ ] make pr passes
[ ] Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Builds should be back to passing soon :)


Help: Hide inserting row after data insert

Hi Need help for following two scenario

I want to hide my inserting row after data gets inserted.
if I am doing $("#jsGrid").data("JSGrid").option("inserting", false);  its hiding the inserting row but not toggling the header row insert icon (+) to previous state.
Disable insert row (+) icon once max row count in grid reaches certain number and re enable it once any record gets deleted.

Thanks in advance

You need some tweaking of the control field.

click the button instead of hiding the inserting row manually: $(".jsgrid-insert-mode-button").click()

handle onRefreshed event (http://js-grid.com/docs/#onrefreshed) and disable .jsgrid-insert-mode-button depending on the amount of items in the grid


Fixes NPE on JavadocParser for empty javadoc at class level

fixes #178

WIP: Need to add a test

Once again thanks! :-)

You're welcome :+1:


Enable to remove "Please Do Not Spam" on my channel's comments.

I know the reason for the latest implementation of the comments "Please Do Not Spam" message, when people either type too much, or put a link to another odysee publication. But, there is a problem.
If you scroll down on any of the articles in @blenderdumbass:f you will find a section like this:

This is an auto generated part, using a script, that looks at latest supported comments and shows them in the text of the article.
Sometimes, like for example here:

...the person is linking another odysee ( LBRY ) publication. And I want it to be possible. It's basically an ads system that's totally decentralised. The script is Free Software and I link to it on each article, you can use it too.
The problem
To avoid malicious spamming, you also removed legit linking of other interesting publications.
The solution
Make a setting somewhere in the Channel settings, that will set a minimum support amount for commenting links. Spammers will have to pay to spam, so they will not do it. Legit advertises, though, will be able to advertise their things through my articles.

I think this is a great idea

The spam message is shown when you post the same thing over and over on a single claim. If someone tips with it, i don't think it counts as spam.
Does that sound right in terms of what is being posted? Let me know and we'll open the issue on the comment repo if needed.

I just tried posting a 5 lbc supported comment with a link on a publication. It had a link to one of my articles. Though, something during posting happened that might explain your take on it. I tried adding a sticker. And it posted a sticker as a comment, returning me to the text that I typed earlier. I tried posting the text and it kept repeating the same error. Until I posted it with FastLBRY without a support. ( Because FastLBRY does not support supported comments yet ).
This is the publication. Funny that the sticker was posted twice for some reason. Once with a support and one without. Which is also a bug, I guess.

I just got this "please do not spam" pop up and I wasn't even typing too much or linking anything. I was pointing out the channel was promoting scam windows 10 pro keys with discount codes and referral links. Is odysee going full retard? Expect so.


List all contracts created by a transaction

Also, I feel like we should list all contracts created by the transaction, not just the root contract deployment.  As a simple example, anyone using Deterministic Deployment Proxy wouldn't see a contract created.
My guess is that almost no one creates a transaction directly (via to: null) these days, everyone uses some proxy (e.g., Gnosis Safe, Maker Vaults, etc.)
Originally posted by @MicahZoltu in https://github.com/DarkFlorist/TheInterceptor/pull/239#pullrequestreview-1351788020

Currently we don't have possibility to know which contracts were created. But this would be nice information to have


Introduce batch handler

Introduce batch handler

Thanks @mahmoudbahaa ! This definitely is easier for me to get my head around.
I appreciate the approach, but honestly, there's no way we can take a patch that includes all the Java stuff. I would rather just test the emulator using plain Go HTTP requests that we can construct in the test code. I can help make this happen.

as in the description these bugs don't happen in go sdk plus go sdk doesn't have batch support

as in the description these bugs don't happen in go sdk plus go sdk doesn't have batch support

👍 yup, I understand.  But we can write some fairly straightforward Go code that constructs an appropriate HTTP batch request, and verify that such code works against real GCS as well as our emulator.  That will be a lot less invasive than grafting in another build system.

ok I am not that verse in go though so would appreciate the help we can then remove the changes in gcs_emulator.go along with the h header file and the java code. I will do so and separate this into 2 PRs one for the batch and one for the gzip fix.

@dragonsinth

removed all java code
removed unrelated code
made batch handler a separate top handler as requested

👍 sweet, gimme a couple days to write some tests but this is looking good

@mahmoudbahaa sorry I haven't been able to drill down on this more, I haven't forgotten about this!

@mahmoudbahaa actually I had a few minutes this morning to check out and rebase your branch.  I made a few updates, hooked up the tests, and everything LGTM.  Would you mind taking a look and testing this out against your Java client?


Error when Nickname mixed Arabic and English

I got error "Erroneous nickname" when set my nickname to this or even with number instead of English latter:
مjم

Hey Zaher! Unfortunately this is restrictions put in place by the Unicode people – specifically, the ones that made PRECIS and the UsernameCaseMapped profile. I suspect mixing scripts in that way is specifically disallowed by them. In addition, the restriction of IRC that the first character of a nickname can't be a number.
Because of that, I'm not really able to change it unfortunately 😅

No problem with numbers,
The weird thing that Oragono accepts unicode name like زاهر but if added one English latter it refuses it.
BTW I modified my client to use only English nickname.

Related discussions: #137 (directly relevant as it was a case where we were thinking about relaxing the PRECIS constraints), #178.

Ah yeah, the issue is that PRECIS specifically forbids things with BIDI markers in it iirc, which means that certain scripts (Japanese, Arabic, etc) might not work with others. Specifically, scripts written right-to-left and those written left-to-write may not work together – because of how those RTL and LTR languages work in Unicode, the extra characters can mess up and make the same visual letters look different in code.

Yeah I'm going to close this for now, since it's a dependency on the underlying PRECIS system unfortunately we can't solve this ourselves.


Fix import errors without dev dependencies

Codecov Report

Merging #214 (f868fcf) into master (227f0af) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head f868fcf differs from pull request most recent head b25954b. Consider uploading reports for the commit b25954b to get more accurate results

@@           Coverage Diff           @@
##           master     #214   +/-   ##
=======================================
  Coverage   70.01%   70.01%
=======================================
  Files          30       30
  Lines        2368     2368
=======================================
  Hits         1658     1658
  Misses        710      710

Continue to review full report at Codecov.

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


yatee: Support @for on map and list.

Signed-off-by: Matthieu Nottale<EMAIL_ADDRESS>
- What I did
Add support for iterating over dictionaries and lists in @for
- How to verify it
unit tests were added.

@silvin-lubecki @simonferquel  what is the status of this PR ?

Closing as it is stale :sweat_smile:


[Git master] Fails to compile on Linux with fatal error: microhttpd.h: No such file or directory

Hi!
This is what I get on Linux with latest master.
# cd "$(mktemp -d)"
# git clone https://github.com/clangen/musikcube
# cd musikcube/
# git submodule update --init
# cmake -S . -B build
# make -C build
# make -C build
make: Entering directory '/tmp/tmp.0k9P83aINW/musikcube/build'
[  3%] Built target supereqdsp
[ 41%] Built target musikcore
[ 43%] Built target taglibreader
[ 44%] Built target alsaout
[ 45%] Built target nullout
[ 47%] Built target pipewireout
[ 48%] Built target portaudioout
[ 51%] Built target pulseout
[ 52%] Building CXX object src/plugins/server/CMakeFiles/server.dir/HttpServer.cpp.o
In file included from /tmp/tmp.0k9P83aINW/musikcube/src/plugins/server/HttpServer.cpp:35:
/tmp/tmp.0k9P83aINW/musikcube/src/plugins/server/HttpServer.h:39:14: fatal error: microhttpd.h: No such file or directory
   39 |     #include <microhttpd.h>
      |              ^~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/plugins/server/CMakeFiles/server.dir/build.make:90: src/plugins/server/CMakeFiles/server.dir/HttpServer.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:780: src/plugins/server/CMakeFiles/server.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
make: Leaving directory '/tmp/tmp.0k9P83aINW/musikcube/build'
# git ls-files | grep microhttpd.h
src/3rdparty/win32_include/microhttpd.h
# git rev-parse HEAD
b2652ad64348f1d416a9d243ac77f40cee7bc303

Is this a bug in the build system?
Best, Sebastian

Any thoughts?

It’s listed as a Networking dependency.
https://www.gnu.org/software/libmicrohttpd/

Yeah, libmicrohttpd must be available.

It seems to compile after installing microhttpd. Any chance to have the build system detect absence of microhttpd and ask to install it?

I just added improved detection for microhttpd during build, this will be fixed in the next release.

sudo apt install libmicrohttpd-dev  # On Ubuntu/Debian
sudo yum install libmicrohttpd-devel  # On CentOS/RHEL


Flying Waypoint Path

Flying Waypoint Path
Problem
Flying waypoint path given a datastructure of gps values (list of dictionaries).
Solution
Using the mavsdk goto locations fly to each waypoint within 25 ft.

Closed by #27


Update CONTRIBUTING.md

Add a note to tell people to use go 1.9.1 or newer.

If you try to use an older version,  you will get the following error when trying to build Fn:
github.com/fnproject/fn/vendor/github.com/rdallman/migrate/database/mysql:
no buildable Go source files in
<whatever>/go/src/github.com/fnproject/fn/vendor/github.com/rdallman/migrate/database/mysql


release-2.0: Operations Guides » Pluggable transaction endorsement and validation

assign me to translate

assign me to review

已校对


Assets sub folders

Hi,
This is possible out of scope, but would it be possible to created Assets sub folders when generating modules (e.g. css, js, img)?  Perhaps adding it as a option  when generating a new module?
Any thoughts on this?
Thanks
Nhg

I'm not in favor of that idea considering most of my modules don't actually need additional assets, so I'd be creating a slew of empty directories. You can already put your subfolders in the modules/module/Assets directory and when you do:
php artisan module:publish module

It will place all your extra assets in the public/modules/module/ directory.


Improve installation and walkthrough instructions

This change loses syntax highlighting on a few places, I'm not sure how to generate that statically like shown. Not sure how big a deal it is, can be added back in later.
Fixes #47, fixes #46, and fixes #38.

that statically like shown

I think this was simply exported from an Emacs buffer using https://github.com/hniksic/emacs-htmlize

Yeah, it's using htmlize indeed. The code it generated makes it really hard to work with the markup, so ideally at some point we should just drop all of it inline css and clean up the structure. It'd rather have clean markup than highlighting.


Swap positions of "contact us" and partner text in Info Bar.

Changes
Fixes #3992. :cactus: :dancer: :facepunch:
For review: @DoSomething/front-end

:100: :+1:


Authentication using Certificates

Thanks for putting together this postman collection.
Is there a guide for testing it with certs (instead of the client_secret)?

I"m still investigating this one...sorry for delay.

OK so further investigation.
Here is a stackoverflow post that explains what the request called are
https://stackoverflow.com/questions/39354835/what-happens-during-a-acquiretokenasync-call-using-the-client-certificate/39371624#39371624
For those following along , here is more details on auth with certificates:

Client credentials flow using a certificate: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#second-case-access-token-request-with-a-certificate
Format of the client_assertion (a JWT signed by the authorized certificate): https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-certificate-credentials


Error: Cannot combine flow and typescript plugins.

Environment

System:
  OS: macOS 10.14.5
  CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Memory: 764.94 MB / 16.00 GB
  Shell: 3.2.57

Binaries:
  Node: 10.16.0
  npm: 6.9.0
  Watchman: 4.9.0

SDKs:
  iOS SDK:
    Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2

IDEs:
  Xcode: 10.2.1

npmPackages:
  react: 16.8.6
  react-native: 0.59.9

npmGlobalPackages:
  react-native-cli: 2.0.1

Platforms

iOS
Versions

iOS: 12.2
react-native-netinfo: ^3.2.1
react-native: 0.59.9
react: 16.8.6

Description

I changed to the new version of React Native 0.59, and to remove the NetInfo warning I installed and changed the imports of my project by  '@ react-native-community / netinfo' .
I followed all the steps described in the NetInfo readMe, but likewise the following error appears.

Reproducible Demo

Change :
import { NetInfo } from 'react-native'
To :
import NetInfo from '@react-native-community/netinfo'

:wave: Can you send over the version of the metro-react-native-babel-preset module you have and the contents of your Babel config file?

Yes sure!,
Babelrc project Config :
{
  "presets": [
    "react-native",
    "module:metro-react-native-babel-preset"
  ],
  "sourceMaps": true,
  "plugins": [
    "transform-react-class-displayname",
    "inline-package-json",
    "transform-inline-environment-variables",
    "@babel/plugin-proposal-nullish-coalescing-operator"
  ],
  "env": {
    "test": {
      "plugins": [
        "istanbul"
      ]
    }
  }
}

Project Versions :

"metro-react-native-babel-preset": "^0.54.1"
"babel-preset-react-native": "4.0.1"

According to the README for babel-preset-react-native that preset has been replaced by the metro one and you should use one or the other:
https://www.npmjs.com/package/babel-preset-react-native
If you change your Babel config to just use the module:metro-react-native-babel-preset preset then it might fix your issue.

Thank a lot!!, it has been very useful.
Now I close the issue 🚀

No problem! Glad you fixed it 👍

I am having this same issue crop up on React Native 0.60.6. I switched over to @react-native-community/netinfo 5.5.0 and I have "presets": ["module:metro-react-native-babel-preset"] in .babelrc. Is there a step I'm missing?


fix(traffic_light map_based detector): vibration offset computation

Description
As mentioned before internally, I think that the computations regarding the offsets produced by the vibrations are incorrect. The effect is small when the ROIs are near the optical center but increases as the ROIs get away from it.

Tests performed
Validated using the # 4 data from 2023/04/17

Effects on system behavior

Not applicable.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

Could you please provide slides or something to explain the computation?

Sure thing.
TIER IV INTERNAL LINK

cc: @Mingyu1991 @yukkysaito

Sorry for late reply.
I'll review today :pray:

I don't know how to read the figure, so please tell me. :pray:
Where is it on the image to be projected?
If the blue line is where the image is projected to, then why not leave it as it is now?

@yukkysaito
It is not "good" to represent the camera projection plane at an arbitrary such as in the blue line (unless it is the same distance for multiple examples) since it can be easy to arrive to misleading conclusions. Additionally, I think is better to understand this problem in the camera coordinate system rather than in the image space (forgetting the projection model for a while)
The current way to compute things it is not wrong per se, it is just not what it says it seeks to do.
A way to see the problem clearly is considering a very wide FOV and the  TLR in the border of the image. In that case:

The z component is almost null compared with the x component which is very large (in camera coordinates)
With the current way to compute things no matter how large we select the vibration yaw parameter the delta x does not really change. delta_x = sin(vibration_yaw) * z. Since z << x, no choice of vibration_yaw has an relative effect on x.

With the current cameras it is not really a problem, but as we move to higher resolutions (larger distances) and wider FOVs, the effect will be less easy to ignore.
It is always a choice to not adopt this way of computing the deltas since none of our products are really in need of it right now and adding this fix may cause concerns of man-hours (I don't think that is the case, but even so).
However, I would like at least for the people involved to be aware of the limitations of the current way we compute these deltas so that is we have issues in the future, we know what and how to address it.

@knzo25 What is the status of this PR?

@kminoda
The relevant people don't think it is relevant so it being left-as-is for now (we are starting to use 120deg lenses so it may become relevant in the future)

@knzo25 Thanks! Let me convert this to a draft but feel free to reopen if necessary.


Mention just how loose this component is

var matcher = /^\w+:\/\/([^\s\.]+\.\S{2}|localhost[\:?\d]*)\S*$/;

Will fail SO badly in so many cases: IDNs, modern TLDs, parens in URLs, punctuation at the end etc.
There's a much more powerful regexp in component/regexps.uri.
I understand this component doesn't really aim to properly parse URLs like linkify, but perhaps it's better to just use the regexps component.

Why develop yet another "is this string a URL" library

Perhaps this observation is too late now. This module gets 2M downloads/month on npm.
Worth closing this issue?

Looks like validator has more traction.


Issue 1033 - Use logger in ReinitialiseTable instead of System.out

Make sure you have checked all steps below.
#1033 Issue

[X] My PR addresses the following issues and references them in the PR title. For example, "Issue 1234 - My Sleeper
PR"

Resolves https://github.com/gchq/sleeper/issues/1033

Tests

[X] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Doesn't need testing (it is for logging that was previously implemented)

Documentation

[X] In case of new functionality, my PR adds documentation that describes how to use it, or I have linked to a
separate issue for that below.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

It looks like you're still using the java.util.logging.Logger methods. You can use debug instead of fine and error instead of severe.
You can also use string interpolation like LOGGER.info("Value: {}", value), rather than using string concatenation. This stops it evaluating the string if it's not going to save the log message.
It's probably also okay to use System.out in the main method, particularly as it's using System.console().readLine there as well.

Thank you @gaffer01 for your kindness.
Thank you @patchwork01 for your constructive feedback.
I understand more fully what it is you are looking for, one question I do have. I notice that you said I can use LOGGER.debug instead of LOGGER.fine, however in your string interpolation example and in how ReinitaliseTableFromExportedPartitions used to be, they all use LOGGER.info
Which do you feel is more appropriate for this project?

Thank you @gaffer01 for your kindness.
Thank you @patchwork01 for your constructive feedback.
I understand more fully what it is you are looking for, one question I do have. I notice that you said I can use LOGGER.debug instead of LOGGER.fine, however in your string interpolation example and in how ReinitaliseTableFromExportedPartitions used to be, they all use LOGGER.info
Which do you feel is more appropriate for this project?

ReinitialiseTable is part of a collection of tools that allow the user to interact with the system, so I think it's best to stick to LOGGER.info and LOGGER.error.
LOGGER.debug is useful for seeing how data is handled internally and helps narrow down problems, but it tends to be much more verbose.

I've also raised an issue for the problem that's causing the checks to fail, we'll fix that :)

https://github.com/gchq/sleeper/issues/1053


Change text color on select/highlight in origin story

@lujainibrahim if u can do this bc I wont have a laptop for a while i will he vvv grateful <3 just add it to  in the doc itself lol ill organize the code later

thank you <3


.Net: FunctionCallingStepwisePlanner failing with Error 400

Describe the bug
Using "FunctionCallingStepwisePlanner" is throwing error while calling ExecuteAsync. The error response looks like this -
 {     "message": "Invalid value for 'content': expected a string, got null.",     "type": "invalid_request_error",     "param": "messages.[18].content",     "code": null   }
The ExecuteAsync call was working normally atleast till 08Jan'24 but stopped working on 9th. I'm still able to create and invoke the plan using HandleBarsPlanner correctly and use kernel.InvokeAsync as well.
To Reproduce
Steps to reproduce the behavior:

Use following configuration
nuget - Microsoft.SemanticKernel.Planners.OpenAI  version: 1.0.1-preview
Model name: gpt-4
Model version: 1106-Preview
Create planner using var planner=new FunctionCallingStepwisePlanner();
Call Plan execution uing var result = await planner.ExecuteAsync(kernel, planPrompt);
Following error response is now getting returned:

      Status: 400 (model_error)

      Content:
      {
  "error": {
    "message": "Invalid value for 'content': expected a string, got null.",
    "type": "invalid_request_error",
    "param": "messages.[18].content",
    "code": null
  }
}

      Headers:
      Access-Control-Allow-Origin: REDACTED
      X-Content-Type-Options: REDACTED
      x-ratelimit-remaining-requests: REDACTED
      apim-request-id: REDACTED
      x-ratelimit-remaining-tokens: REDACTED
      X-Request-ID: REDACTED
      ms-azureml-model-error-reason: REDACTED
      ms-azureml-model-error-statuscode: REDACTED
      x-ms-client-request-id: 0dbca26b-ed41-4e83-a4ef-05b86c642978
      x-ms-region: REDACTED
      azureml-model-session: REDACTED
      Strict-Transport-Security: REDACTED
      Date: Wed, 10 Jan 2024 15:16:23 GMT
      Content-Length: 189
      Content-Type: application/json

         at Azure.Core.HttpPipelineExtensions.ProcessMessageAsync(HttpPipeline pipeline, HttpMessage message, RequestContext requestContext, CancellationToken cancellationToken)
         at Azure.AI.OpenAI.OpenAIClient.GetChatCompletionsAsync(ChatCompletionsOptions chatCompletionsOptions, CancellationToken cancellationToken)
         at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.RunRequestAsync[T](Func`1 request)
         --- End of inner exception stack trace ---
         at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.RunRequestAsync[T](Func`1 request)
         at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.GetChatMessageContentsAsync(ChatHistory chat, PromptExecutionSettings executionSettings, Kernel kernel, CancellationToken cancellationToken)
         at Microsoft.SemanticKernel.ChatCompletion.ChatCompletionServiceExtensions.GetChatMessageContentAsync(IChatCompletionService chatCompletionService, ChatHistory chatHistory, PromptExecutionSettings executionSettings, Kernel kernel, CancellationToken cancellationToken)
         at Microsoft.SemanticKernel.Planning.FunctionCallingStepwisePlanner.GetCompletionWithFunctionsAsync(ChatHistory chatHistory, Kernel kernel, IChatCompletionService chatCompletion, OpenAIPromptExecutionSettings openAIExecutionSettings, ILogger logger, CancellationToken cancellationToken)
         at Microsoft.SemanticKernel.Planning.FunctionCallingStepwisePlanner.ExecuteCoreAsync(Kernel kernel, String question, CancellationToken cancellationToken)
         at Microsoft.SemanticKernel.Planning.PlannerInstrumentation.InvokePlanAsync[TPlan,TPlanInput,TPlanResult](Func`5 InvokePlanAsync, TPlan plan, Kernel kernel, TPlanInput input, ILogger logger, CancellationToken cancellationToken)

Expected behavior
Expected a properly formed response JSON.
Screenshots
Platform

OS: Windows
IDE: Powershell
Language: C#
Source:
nuget -
Microsoft.SemanticKernel.Planners.OpenAI  version: 1.0.1-preview
Microsoft.SemanticKernel version: 1.0.1
Model name: gpt-4
Model version: 1106-Preview

Additional context
The issue suddenly started happening while planner was working pretty fine for last few weeks.

@arajawat, is the model being served up by OpenAI or Azure OpenAI? Also.. are you suddently getting a 400 error for other types of prompts that you use with your model? Or is it specific to the planner?
@markwallace-microsoft or @alliscode, are either of y'all aware of a change in the endpoints of OpenAI or Azure OpenAI that would cause this to suddenly break?

@matthewbolanos  We're using Azure OpenAI. It is specific to only FunctionCallingStepwisePlanner only. I am able to call HandleBarsPlanner and get the desired result and I am also able to directly call kernel, pass the prompt and get the result.

@matthewbolanos The issue seems to be with Azure OpenAI deployment for models "gpt-4" & "gpt-4-32k". We are not getting any error "gpt-35-turbo-16k" and everything works fine with this.
The above mentioned error is coming from model version - 1106-Preview
For other model version "0613" of gpt-4 and gpt-4-32k, we get some other error stated below:
  {   "error": {     "message": "Unrecognized request arguments supplied: tool_choice, tools",     "type": "invalid_request_error",     "param": null,     "code": null   } }

I can confirm, there is a issue in version 1.0.1 but I just download sourse code, and seems now gpt4-turbo works fine.

I am now able to reproduce the issue. Investigating....

This appears to be an issue with the model on Azure OpenAI service, not in our code.
I can see that the model is returning a response with finish_reason equal to tool_calls, but the list of tool calls is empty and the content string is null (as it should be for a tool call). When we add this message back into chat history and request another completion, the model identifies this entry in the chat history as invalid, since neither the tool call or content are populated.
At this time, the only workaround I can suggest is to use a different model version -- this seems to be an issue with the 1106 models.
Here's a related thread on the OpenAI community forum: https://community.openai.com/t/function-call-response-is-empty-despite-completion-tokens-being-used/580888

Sorry, forgot to mentioned, for me it was Azure OpenAI

@gitri-ms  Thanks for the analysis and sharing associated thread. Apparently there are 2 different issues with both available versions:
Issue with 1106 preview (& you provided your research insights above) : Invalid value for 'content': expected a string, got null.
Issue with 0613 : Unrecognized request arguments supplied: tool_choice, tools
So even the other "0613" model version is throwing error. For now, the only work around is stepping back to gpt35-turbo-16k.

Dupe of #4674 which has been resolved


[Ready to sign] increase max gas limit

[Ready to sign] increase max gas limit

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1

Review Error for mds1 @ 2024-12-06 19:37:50 UTC
User must have write permissions to review


fix warnning sidebar propTypes &  update react-svg-pan-zoom to 3 by following the documents &  fix some type error

Sidebar's width + height are not required any more.

update react-svg-pan-zoom to 3 by following the documents, and fix some type error

add objExporter, save project with JSON and OBJ,
fix new project then add woods in catalog will cras