Ability to view shared alarms from another accounts

It would be very nice if the plugin has the ability to show shared alarms from another AWS accounts, not only from the account where the IAM credentials/role resides:

Thank you!

Oh, I have not seen that option before in the AWS CloudWatch console.
If I am reading the correct docs,  It seems that AWS is using AssumeRole to access the alarms in the other accounts.
This plugin also supports assuming a role (although, I have not tested that feature much). You would have to  grant access to the IAM user to assume roles. Then, create the proper roles within the other accounts. Then, setup a datasource for each account and region, filling in the "Assume Role ARN" setting.
It might be possible to update this plugin so that it automatically iterates over all accounts within your AWS organization. However, that is probably tricky to implement. I based this plugin off the official Grafana CloudWatch datasource, which also does not support such a thing (as far as I know).
In our own setup I automatically provision multiple data sources using our CI/CD software, for each of our AWS accounts. You would have to generate a small YAML file. For example:
/etc/grafana/provisioning/datasources/example.yml
- jsonData:
    authType: keys
    defaultRegion: eu-west-1
  name: Production Alarms
  orgId: 1
  secureJsonData:
    accessKey: AKIAIOSFODNN7EXAMPLE
    secretKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  type: computest-cloudwatchalarm-datasource


Redis Service dies after a few days

Using the Redis Windows Service with all default config.
Redis 2.8.21 (00000000/0) 64 bit, stand alone mode, port 6379
It runs well for a while, then after what seems like a few days it randomly seems to die... here are the Event log entries...
syslog-ident = redis
=== REDIS BUG REPORT START: Cut & paste starting from here ===
syslog-ident = redis
--- EXCEPTION_ACCESS_VIOLATION
syslog-ident = redis
--- INFO OUTPUT
Faulting application name: redis-server.exe, version: <IP_ADDRESS>, time stamp: 0x558b1f29
Faulting module name: redis-server.exe, version: <IP_ADDRESS>, time stamp: 0x558b1f29
Exception code: 0xc0000005
Fault offset: 0x0000000000086a34
Faulting process id: 0x734
Faulting application start time: 0x01d0cafdb94cd7a1
Faulting application path: C:\Program Files\Redis\redis-server.exe
Faulting module path: C:\Program Files\Redis\redis-server.exe
Report Id: fef3c19e-3add-11e5-80c5-00155d018000
Faulting package full name:
Faulting package-relative application ID:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: redis-server.exe
P2: <IP_ADDRESS>
P3: 558b1f29
P4: redis-server.exe
P5: <IP_ADDRESS>
P6: 558b1f29
P7: c0000005
P8:<PHONE_NUMBER>086a34
P9:
P10:
Attached files:
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\WERB1BA.tmp.appcompat.txt
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\WERB1CB.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_redis-server.exe_e6fcaa5ef6f9ebff0fc8eac53205878b8f29c11_e1be9887_cab_7244b1d9\memory.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_redis-server.exe_e6fcaa5ef6f9ebff0fc8eac53205878b8f29c11_e1be9887_cab_7244b1d9\triagedump.dmp
WERGenerationLog.txt
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_redis-server.exe_e6fcaa5ef6f9ebff0fc8eac53205878b8f29c11_e1be9887_cab_7244b1d9
Analysis symbol:
Rechecking for solution: 0
Report Id: fef3c19e-3add-11e5-80c5-00155d018000
Report Status: 4
Hashed bucket:

Hi @goleafs
thank you for reporting the issue.
Do you still have the log that shows the crash? If possible post the previous 50 lines.
I'm asking it because the bug report doesn't include a stack trace so I need to verify if the bug is the one we fixed in v2.8.2101
Most of the crashes reported for v2.8.21 were caused by it and it can be verified checking the log just before the crash.
Thank you.

I think so.. is it in one of the files mentioned above?

@goleafs
when Redis is running as a windows service, the log file is located by default here:
C:\Program Files\Redis\Logs\redis_log.txt
the log file uses the unix new line convention, so it's better to open it with a program like Notepad++ to see the correct formatting.

Here are the last couple entries around the crashes..
[1844] 04 Aug 15:21:14.185 * 10 changes in 300 seconds. Saving...
[1844] 04 Aug 15:21:14.623 # fork operation complete
[1844] 04 Aug 15:21:14.951 * Background saving terminated with success
[1844] 04 Aug 15:21:22.548 #
=== REDIS BUG REPORT START: Cut & paste starting from here ===
[1844] 04 Aug 15:21:22.548 # --- EXCEPTION_ACCESS_VIOLATION
[1844] 04 Aug 15:21:22.548 # --- INFO OUTPUT
[7956] 04 Aug 16:40:59.702 * Redis 2.8.21 (00000000/0) 64 bit, stand alone mode, port 6379, pid 7956 ready to start.
[7956] 04 Aug 16:40:59.702 # Server started, Redis version 2.8.21
[7956] 04 Aug 16:40:59.702 * DB loaded from disk: 0.001 seconds
[7956] 04 Aug 16:40:59.702 * The server is now ready to accept connections on port 6379
[7956] 04 Aug 16:56:00.071 * 1 changes in 900 seconds. Saving...
[7956] 04 Aug 16:56:00.540 # fork operation complete
[7956] 04 Aug 16:56:00.868 * Background saving terminated with success
[1244] 30 Jul 14:10:25.560 * 10 changes in 300 seconds. Saving...
[1244] 30 Jul 14:10:25.998 # fork operation complete
[1244] 30 Jul 14:10:26.310 * Background saving terminated with success
[1244] 30 Jul 14:13:11.439 #
=== REDIS BUG REPORT START: Cut & paste starting from here ===
[1244] 30 Jul 14:13:11.439 # --- EXCEPTION_ACCESS_VIOLATION
[1244] 30 Jul 14:13:11.439 # --- INFO OUTPUT
[1844] 30 Jul 15:27:08.044 * Redis 2.8.21 (00000000/0) 64 bit, stand alone mode, port 6379, pid 1844 ready to start.
[1844] 30 Jul 15:27:08.044 # Server started, Redis version 2.8.21
[1844] 30 Jul 15:27:08.044 * DB loaded from disk: 0.000 seconds
[1844] 30 Jul 15:27:08.044 * The server is now ready to accept connections on port 6379
[1844] 30 Jul 15:32:39.636 * 10 changes in 300 seconds. Saving...
[1844] 30 Jul 15:32:40.074 # fork operation complete
[1844] 30 Jul 15:32:40.386 * Background saving terminated with success
[1844] 30 Jul 15:37:41.025 * 10 changes in 300 seconds. Saving...
[1844] 30 Jul 15:37:41.462 # fork operation complete
[1844] 30 Jul 15:37:41.774 * Background saving terminated with success

@goleafs
the log doesn't contain the definitive proof that I was looking for but some of the info matches the characteristics of the bug we fixed in v2.8.2101, so please update to the latest release.
Thank you.

Ok, I'll try it.. btw in the meantime I got another error as well..
[7956] 04 Aug 18:03:15.297 #
=== REDIS BUG REPORT START: Cut & paste starting from here ===
[7956] 04 Aug 18:03:15.297 # --- ABORT
[7956] 04 Aug 18:03:15.297 #
=== REDIS BUG REPORT END. Make sure to include from START to END. ===
   Please report this bug by following the instructions at:

 http://github.com/MSOpenTech/redis/wiki/Submitting-an-Issue

Suspect RAM error? Use redis-server --test-memory to verify it.

[2956] 04 Aug 18:26:55.045 * Redis 2.8.21 (00000000/0) 64 bit, stand alone mode, port 6379, pid 2956 ready to start.
[2956] 04 Aug 18:26:55.045 # Server started, Redis version 2.8.21
[2956] 04 Aug 18:26:55.045 * DB loaded from disk: 0.001 seconds
[2956] 04 Aug 18:26:55.045 * The server is now ready to accept connections on port 6379

@goleafs
the 2.8.2101 also contains a fix for the BUG REPORT that wasn't printing the STACK TRACE section, without the stack trace it's really difficult to determine the exact cause of the crash.
The last report seems to be an out of memory error but without the stack trace it can't be said for sure.

@goleafs
closing the issue since it refer to an old release.
Feel free to re-open it if needed.
Thank you.


Add files via upload

Added Pythagorean Triplet program which generates Pythagorean triplet.

@darpanjbora please review this commit and merge it. And add Hacktoberfest label to it


home page accessibility section

Currently we say UI Kit aims to be WCAG2 AA compliant, and AAA where possible.
I suggest instead UI Kit aims to be WCAG2 AA compliant, and AAA where appropriate. as some AAA criteria are possible but not always appropriate as by lifting the level for some you can actually disadvantage others.

Rather than calling out WAVE as the manual evaluation tool, let' say We are working on:  manual evaluation using a variety of tools

Agreed. I will be updating this content, which is now under Getting started > For developers > Accessibility.
I’ll run the edits past you as part of issue #58.
Closing this ticket as a result.


Localize docs content

All the content within docs should be moved to message properties files so that we can have our content localized. This would make the site more accessible to more people which I think is a good thing.

:+1: :100:


I can get the out of gas error while following test_out_of_quota.md

I'm now running the cita out of container, using solc version of 4.23, while following the steps in test_out_of_quota.md, in step 6, I do can get the out of gas error information.
# python get_receipt.py
--> {"params": ["7da081c919f25cdfe856e3535a4d291e38315f887a785a52b75ef5a3db8c9489"], "jsonrpc": "2.0", "method": "eth_getTransactionReceipt", "id": 1}
<-- {"jsonrpc":"2.0","id":1,"result":{"transactionHash":"0x7da081c919f25cdfe856e3535a4d291e38315f887a785a52b75ef5a3db8c9489","transactionIndex":"0x0","blockHash":"0x99363e5f0966c9f8d81902e3a6d89b38a2fc43ddb1f6f5b31aafb687566e1478","blockNumber":"0x9d8","cumulativeGasUsed":"0x98967f","gasUsed":"0x98967f","contractAddress":null,"logs":[],"root":null,"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","errorMessage":"Out of gas."}} (200 OK)
{
  "contractAddress": null,
  "cumulativeGasUsed": "0x98967f",
  "logs": [],
  "blockHash": "0x99363e5f0966c9f8d81902e3a6d89b38a2fc43ddb1f6f5b31aafb687566e1478",
  "transactionHash": "0x7da081c919f25cdfe856e3535a4d291e38315f887a785a52b75ef5a3db8c9489",
  "root": null,
  "errorMessage": "Out of gas.",
  "blockNumber": "0x9d8",
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "transactionIndex": "0x0",
  "gasUsed": "0x98967f"
}

This situation is correct. It's a previous bug
Thank you. I will update it ASAP.
You can check the tests/test/unit/quota_manager.js. It tests the quota using web3js


Feat: CodeForces Contest Scrapper

Describe the feature
Most of the students practice competitive programming by given contest on codeforces . I would like to code a scrapper that that scrapes :

Contest Name
Contest type(div)
Start Date and Time and the length of contest
URL that will allow users to directly navigate to registration page

I have provided ss of the page from which I will scrape the above listed.
@nikhil25803 kindly checkout the issue and assign it to me.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC 23 contributor
[X] I want to work on this issue

Go ahead @ojaswi18
Note

Create a separate module for this, as per the folder and project structure
Do not use the `selenium web driver as it is not compatible with all devices as well as cloud platforms.
Before making any changes, check if the module you want to add already exists or not. If yes, then add your functionality as a method only else make a separate module and class for it.


❄ add second power_cost entities for lumi.acpartner.mcn04

lumi.acpartner.mcn04 has 2 sockets, but micloud_statistics only processed 1
so change the config stat_power_cost_key to support keys array for further similar devices.
this change will add power_cost_today/month with suffix _2, _3..., won't change the entity naming for pervious devices.
FYI: I am not very familiar with the code structure, if this pr is not the proper way to achive this, let me know.

https://github.com/al-one/hass-xiaomi-miot/issues/1635


Add Zcoin (XZC)Electrum servers

Hi. I can connect to all this servers, but listunspent is empty, eg:
(echo '{ "id": 1, "method": "blockchain.address.listunspent", "params": ["a2aFa4UPARruz5rrXK9b3YmXpsw3uVVYEq"] }'; sleep 1) | ncat <IP_ADDRESS> 50002
does not return anything although the address has utxos:
https://chainz.cryptoid.info/xzc/address.dws?a2aFa4UPARruz5rrXK9b3YmXpsw3uVVYEq.htm
can you try it yourself and have a look at the logfile?


New feature: declare function schema

Hi, progressing with the use cases for plv8ify, I'd like to add another decoration to allow creating the functions in a specific schema.
Right now we're working around this by using prefixes, but it is sub optimal, as we either need to break down the code by schema, or create different scripts in the ci for them.
Would a decoration style like
//@plv8ify-schema <my_custom_schema>
export function my_test() {
  return "test";
}

be acceptable?
In this case the generated SQL would be something like:
CREATE OR REPLACE FUNCTION my_custom_schema.my_test()
...

Yes, go for it!

Implemented in V 0.54

Done via https://github.com/divyenduz/plv8ify/pull/42
Thank you @mattiarossi for the contribution 🙌🏼


Fix flakiness when ecto type module not loaded

Sometimes an underlying ecto type module, e.g. Money.Ecto.Composite.Type is not loaded and this will cause the &dump/1 function to not be found.

tests pass locally but fail on CI


Update authentication.md

Adding smart card to macOS

@davidbel A customer rep reached out to me regarding smart card auth on macOS. From my understanding, we do support macOS smart card auth to session host through Kerberos via KDC proxy to sign.
Therefore, I am updating the docs - if you can just provide a brief sign off that my information is correct. that'd be great

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

A similar change has been incorporated into the live article. I'll close the PR now. Thank you!


Update Docker 1.13.1

Travis build fails:

We added this file manually see to set eth0 as default ethernet interface name commit message maybe it can be removed?

@firecyberice Thanks, I removed the file 99-com.rules as there is nothing related to eth0 in that file.


Storm, Earth and Fire spell

Recreate the following spell in C#.
https://github.com/AzerothWarsLR/AzerothWarsLR/blob/master/jass/Spells/StormEarthAndFire.j

Closed by #102.


.count does not skip the default scope

I am using rails 4.2.3 and unscoped_associations 0.6.5.
Although the gem works when fetching associated records, it doesn't seem to work when counting associated records.
I'm using different models than your example, but the behavior in your example would be something like this: user.all_comments.count returns a smaller number than user.all_comments.to_a.count. Per SQL debugging in the rails console, the default scope is not skipped when .count is added.

Hi @encoder,
Yes, I think you're right, it probably doesn't work. This plugin is based on the unscoped method, I remember that chaining new scopes after unscoped calls are broken in AR itself. I'll take a look in deeper.
Using to_a works because all objects are already fetched from database and you are calling count over an array.
I'm not sure if this is easy to fix, need to review some AR internals... If you want to take a look would be really helpful.
Thanks for reporting.

Hi @encoder, I added some notes about this in the docs: https://github.com/markets/unscoped_associations#notes.


Plugin Not Working

Describe the bug (add an image if UI bug)
The plugin does not work once it's downloaded, uploaded, and activated on the site.
Which browser or device was used?
I used a MacBook computer with the Firefox browser.
Steps to reproduce
1- Download the plugin.
2- Upload the plugin to the site.
3- Activate the plugin.
Additional context (any extra information)
WordPress Version: 6.3
WooCommerce Version: 8.0.1
Thawani for WooCommerce Version: 1.4.1

Thank you for your prompt response.

no problem. happy to help

To clarify, I do not have any screenshots or error messages to share. Quite simply, the plugin does not appear on my end at all, even though it is activated.

This plugin does depend on 2 plugins
1, Thawani for woocommerce
2. WooCommerce
it may be the reason of local configuration.

Do you recommend any steps or actions that might help resolve this issue?

This plugin was created for 1 purpose only.. and to be used 1 time before going to production..
What I will suggest to you is to write a simple script that make the same task for you.

hey @k6111 ,
if the session, is by using Thawani Pay public keys then you can use the documentation of the plugin Retreive sessison. the documentation also provide some code samples see what are you familiar with and run it on your machine.
Regrads


upgrading hardhat/etherscan to fix verify task

upgrading @hardhat/etherscan fixes the verify process after deploying wrap n zap factory

whoops duplicate


Agent getting stuck in infinite loops with Stay [with perfect detector]

The agent, when trying to go to the alarm clock gets stuck in a loop - it keeps finding stay as the best action when it's far away.
Here are the potential issues :

https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/agent/components/policy_model.py#L124

Assume you are at location 0. The object is at location 1. So while doing MCTS simulation (in the abstract planning), it does move(0->1). Then it is looking for the next action. Then since it has an action prior, it tries to pick  one among the 2 move options - Move(1->0) or stay(1->1). Now, Move (1-> 0) is rejected because it is taking the agent farther. But Stay (1-> 1) succeeds, is added to preferences, and the action picking code - https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp/models/policy_model.py#L51 . Since there is only 1 action in preference, Stay (1->1), that is selected.  When it tries to do next step planning - since Stay(1->1) doesn't change the state in any way, this process will keep getting repeated until max depth is reached and no reward is found in this path. So a plan with (Move 0->1) + Stay (1->1) will never have the opportunity to call done.
So I guess a check needs to be added that if we already took a stay action, we should do something else most likely.
Other potential issue:
Take the same case as above - Agent at 0, does a Move (0->1), then stay(1->1), no observation is found so a random action is picked Stay(1->1) is picked randomly from https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp/models/policy_model.py#L53 , and then done is called later, it will not get the reward unless the agent was already looking in the correct direction( for the reward, it considers pitch and yaw - even for the upper level planning) - and in the case the agent isn't looking in the correct direction (which the upper level planner has no control over), the correct action sequence of (Move 0>-1), Stay (1->1) and done will not get any reward.
So it might be better to have a separate reward function for high level and low level planning. It looks like at the moment, both are using the same reward function.

I think I fixed the issue - I wrote a separate reward function for high level planning that gives reward as long as agent is close to the object and I added the condition that 2 stay actions cannot be called consecutively. It is no longer getting stuck in any infinite loop for anything I have tested.
It's having an issue of going close to the object and not looking down anymore but I think that is a separate issue.

So the change I made was in the success function - the condition for success is that the agent must just be in the range of the object of interest as opposed to looking at it with perfect pitch and yaw for the high-level planning to get its reward.
It still only gets a reward after calling the done action - so I think it still remains a sparse reward - only getting a reward when it thinks it's called done.


fixed typos

Q
A

content fix?
yes

New article?
no

Related issues?
n/a

What's in this Pull Request?
Fixed typos

@Pieter-Veenstra,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

thx Pieter, appreciated.


Configuration about .tern-project

Hi,
I am a huge fan of tern,and use tern-for-vim for nodejs code writing .
I am sorry this  question may not relate directly to tern-node-express plugin,but  I need your help to instruct me how to configure .tern-project file.

If I installed new packages via npm(global or local in project),how can I tell tern_for_vim  to auto complete items in that package?

If I switched to a newer version of node, how to make  tern_for_vim to auto complete the item that does not exist in the older version of node,but is included in the newer version?
For example, I have installed 2 version of node:

0.10.xx
4.4.2

In 0.10.xx,the execSync is unavailable,but it should appear in the 4.x version when I pressed dot after require statement:
 var execSync = require( 'child_process' ).execSync;

So pls let me know the way to configure .tern-project for these two  scenarios.
Many thanks in advance.

Please post your question to tern or tern for vim. Thanks.


Set up auto deploy to GitHub releases from Travis CI

Looks like this is partially setup. https://github.com/openxc/vi-firmware/blob/master/.travis.yml#L19
However, fab fails on travis b/c it's not found: https://travis-ci.org/openxc/vi-firmware/builds/456098978
If this is updated to include fabric in .travis.yml, then also update README in vi-firmware to just tag the commit from local machine and let travis do the rest - instructions in README need to be updated so you don't run local fab release - just a new command to gpg tag and push.


Add metadata capabilities to urql

In order to expose enough information to create valuable devtools I'm proposing we add a meta tag to our operations.
This tag can be set/updated at the following points:

on calling hooks / client execution
inside hooks (for sourcing the calling component)
inside any exchange

We could add this to context but I think keeping it separate would be best as any information added to the meta property of an operation should not be mission critical (i.e. no worry of breaking anything at runtime).
tl;dr: add meta property to operations

Do you want to summarise what you need. I'd be careful to add it to every exchange as that will make it a lot harder to write exchanges.
But what info do we really need? Whether some result has been retrieved from cache?
It'd be a bit easier to think about how it'd look if we know what info we need 😅

@kitten the point with this proposal is to add an ability to add any metadata to an operation at any point in an operations lifecycle.
While there are specific things we need this for (i.e. devtools) this is more intended to be a intent-agnostic metadata layer. As people create their own exchanges, the uses for this will vary.

@andyrichardson the thing though is that we have the context to add any data that exchanges may need. 😅
I see this information as targeted specifically at the devtools. Now we could add context.meta for instance, but it'd be interesting to discuss what information the devtools need

@kitten I already acknowledged the availability of context in the issue.
The incentives behind not just using context are:

metadata additions should not be able to break functionality
we need a separation between what is causing effects and what is purely metadata
we need to expose metadata to the end user for hooks/execution functions. Adding the ability to override the whole context would be a terrible idea.

Now we could add context.meta

Yes, storing the metadata inside the context works fine - using context for metadata would not be fine. The proposal is to pass metadata throughout an operations lifecycle.
The information we need for devtools isn't what I'm proposing here, it's the ability to pass metadata through an operation's lifecycle. I'm getting the impression you're not a fan. What's the concern with this addition?

@andyrichardson I think context.meta would be the best place for this addition 👍
I can't say whether I'm a fan or not because I'm unsure what information we'd actually add there 😅 the lifecycle is currently quite controlled via the input / output. So in the client we already know which queries are ongoing / subscribed to, what operations have started or got results, and whether that came from a cache or not (or rather resolved synchronously or not)
So I'm just a bit confused. Totally fine with reserving a meta field on context or the operation for this. But I just don't know what we'd use it for yet 😅

I think context.meta would be the best place for this addition 👍

Agreed! I'll put something together over the coming days 🚀

I can't say whether I'm a fan or not because I'm unsure what information we'd actually add there

I hear you! While this will be super valuable for devtools, the last thing we want to do is write a devtools solution to a problem that others may want to solve themselves.

So in the client we already know which queries are ongoing / subscribed to, what operations have started or got results, and whether that came from a cache or not (or rather resolved synchronously or not)

💯 but there's tons of information we are yet to get which could be useful such as:

The source component for a given operation
The state of the cache after a given operation
Who knows what else!

Well, I do see that we'll need it eventually 😅 but you can get the source component by calling the React utility for it whenever the operation comes in as long as that's synchronous.
I do totally see value in more information from the cache. But we probably need to be more granular than per operation.
Anyway, let's see what we need to add 🙌


cmd/compile: inconsistent panics on out-of-bounds slice index

What did you do?
Converted a string to a slice of runes then back to a string, and referenced non-existent elements on the slice of runes:
https://play.golang.org/p/MmJNLu6h6FT
What did you expect to see?
A runtime panic with a 'slice bounds out of range' error.
What did you see instead?
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

System details
go version go1.10 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/matt/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/matt/go"
GORACE=""
GOROOT="/opt/boxen/homebrew/Cellar/go/1.10/libexec"
GOTMPDIR=""
GOTOOLDIR="/opt/boxen/homebrew/Cellar/go/1.10/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/k4/_18vs9g119b0q2_p950t0jl00000gn/T/go-build038036646=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.10 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.10
uname -v: Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D47
lldb --version: lldb-900.0.64
  Swift-4.0

Interesting, thanks!
Here we can see that the cap is 32:
https://play.golang.org/p/PDAI5olA4YG
But uncomment the following line and the cap changes to 0:
https://play.golang.org/p/BA2ivc0sTY6
Definitely something messed up in the compiler.
/cc @randall77 @mdempsky

Actually, does the language guarantee the size of the cap on string->[]rune conversions?
https://golang.org/ref/spec#Conversions_to_and_from_a_string_type says only:

Converting a value of a string type to a slice of runes type yields a slice containing the individual Unicode code points of the string

But doesn't say anything about the slice's capacity.
/cc @griesemer

Here's another example using len() that might help clarify how confusing this could be:
https://play.golang.org/p/YLwjpbY7_nX

@mattbostock Thanks for the examples. I think this example summarizes/demonstrates the root issue you're noticing:
https://play.golang.org/p/Er5s4t9rO7R

(Also, note that the upper bound for slice operations is cap(s), not len(s); i.e., it's possible to grow a slice, as long as there's capacity.)
Like @bradfitz points out, I think the real question is whether string->[]byte or string->[]rune conversions guarantee a particular slice capacity. It seems the spec doesn't guarantee that.

So seems everything is working fine, but the language spec could possibly be more specific here.
Moving to NeedsDecision to see whether the language gets changed.
/cc @ianlancetaylor too.

I think that for these conversions the result should be a slice with cap == len.  I see no benefit to leaving it unspecified.

I see no benefit to leaving it unspecified.

I think there's a small performance benefit. Suppose something like:
var s string = f()
return append([]byte(s), "suffix")

For the conversion, the runtime will need to allocate memory. Also, it will pad the allocation up to the next allocation bucket size. If we expose this capacity to the user via the resulting slice's capacity, then the append might be able to fit into the existing space without requiring a second allocation.

As bad as it sounds, there may be existing code that relies on this feature...
Perhaps the spec just needs to say that it doesn't say anything about the capacity in these cases.

Related: https://github.com/golang/go/issues/14232 and https://github.com/golang/go/issues/14235

As bad as it sounds, there may be existing code that relies on this feature...

Considering that escape analysis changes somewhat regularly, I kinda doubt anybody's relying on this. We've never heard anything about it.

For conversions from string to both []byte and []rune, we allocate extra capacity.  This happens for both stack-allocated (round up to the 32-byte stack buffer) and heap-allocated (round up to the next size class) results:
func main() {
	foo := "foo"
	bar := []rune(foo)
	fmt.Printf("%d %d\n", len(bar), cap(bar))

	baz := []rune(foo)
	sink = baz
	fmt.Printf("%d %d\n", len(baz), cap(baz))
}

var sink []rune

Prints:
3 32
3 4

So escape analysis doesn't really figure into this discussion, it just affects the constants.
IMO when Go does an allocation and the user didn't specify a capacity, the runtime should be free to allocate capacity somewhat beyond the requested size.    Calling append or doing a cast need not.
*Although you could argue that only the 3-arg version of make requests an explicit capacity, the 2-arg version could allow cap>len.

So escape analysis doesn't really figure into this discussion, it just affects the constants.

I think @bradfitz's point was that because escape analysis changes, the constants particular user code sees sometimes changes too. Thus it's arguably safe if we want to intentionally change the constants.

*Although you could argue that only the 3-arg version of make requests an explicit capacity, the 2-arg version could allow cap>len.

I'd argue even for the 3-arg version, that the explicit cap argument should just be a lower bound on what the runtime returns.

Although you could argue that only the 3-arg version of make requests an explicit capacity, the 2-arg version could allow cap>len.

To be clear, the spec does currently appear to forbid this.

I'd argue even for the 3-arg version, that the explicit cap argument should just be a lower bound on what the runtime returns. But unfortunately these seems out of scope for Go 1.

There's an analogy with making maps, where the len arg is just a hint. On the other hand, we definitely wouldn't want the len arg to buffered channels to be just a hint, since they are used to strictly control concurrency.
Another option is to add a "round up" function to package runtime that accepts a size (obtained presumably by unsafe.Sizeof) and a quantity and returns a recommended quantity. Then in cases in which it really matters, people would have the tools to do it--at the cost of using both package unsafe and package runtime. Combine with generics and you could even build append as a library function. :)
(Note that if one wanted to go really nuts and build this yourself without package runtime support, you could, by writing an init function that makes byte slices of various sizes and calls append on them and records the cap you get back, and inferring malloc slab sizes from them.)

I think the discussions about make are interesting, but increasingly off topic. I've opened #24204 to discuss them further. :)


Dismiss Keyboard?

Is there anyway to prevent the keyboard from showing up?  If I'm giving the user a list of options, the keyboard is likely not needed.
I've tried textField.resignFirstResponder() but that doesn't work.  Also tried some combinations with func textFieldDidBeginEditing(textField: UITextField) etc.
One suggestion would be to extend the dropdown functionality to UILabel.  Any other suggestions appreciated.

Hello @craigpearce5,
How are you using the DropDown, can you show some code?
I think this question is not really related to the use of the DropDown itself, a textField.resignFirstResponder() should be enough, or a view.endEditing() where view is your UIViewController's view.

var programTextField: UITextField = UITextField()

// user taps on the text field and func is called
func textFieldDidBeginEditing(programTextField: UITextField) {
    showAvailablePrograms()
}

    let programDropDown = DropDown()

func showAvailablePrograms(){
    programDropDown.anchorView = programTextField
    programDropDown.dataSource = self.passedProgramNameArray!
    programDropDown.show()
    programDropDown.selectionAction = { [unowned self] (index: Int, item: String) in
        self.programTextField.text = item
        self.programIndexPosition = index

    }
}

Wouldn't it be simpler to use a UIButton instead of a UITextField if you just want the dropDown and no possibility to edit textField ? You would just need to add an action to this button to show the DropDown.
If you really need to stick with a UITextField though, you could use the delegate function textFieldShouldBeginEditing(_:) like this:
func textFieldShouldBeginEditing(_ textField: UITextField) -> Bool {
   showAvailablePrograms()
   return false; // Prohibits the text field to become first responder
}

Does that fixes you problem?

I wanted the textField to do both, on tap show the drop down and hold the value, simply to reduce the number of elements on screen (1 textfield vs 1 button 1 textfield).  It's not the worst thing if I have to add a button.  Once I get home I'll try your suggestion.
Thanks - a great tool by the way.  Super easy to implement and looks great.

Have you set self to programTextField.delegate ?. And check again if your viewcontroller have inherited from UITextfieldDelegate protocol

@nhnam Yes... here's a bit more code to show what I'm doing.  I didn't get a chance to try @kevin-hirsch suggestions yet though.
class ChildViewController: UIViewController, UITableViewDelegate, UITableViewDataSource, UITextFieldDelegate {
func textFieldDidBeginEditing(programTextField: UITextField) {
    showAvailablePrograms()
}
let programDropDown = DropDown()
func showAvailablePrograms(){
    programDropDown.anchorView = programTextField
    programDropDown.dataSource = self.passedProgramNameArray!
    programDropDown.show()
    programDropDown.selectionAction = { [unowned self] (index: Int, item: String) in
        self.programTextField.text = item
        self.programIndexPosition = index

        }
    }
}

App delegate includes DropDown.startListeningToKeyboard()


Refactor annotating invitations in team list

This was fun to read as it is interesting. It seems like it will be hard to maintain or understand. So what does it buy us? Performance, how much?
The stored closures in DeferredUIDMapper strike me as hopefully unnecessary complexity. Perhaps you could make DeferredUIDMapper a deduplicating map fetcher, instead of a callback machine. It would return a map uid -> NamePackage. Then the chunks that look roughly like this
var res
for _, team := range teams {
  for inviteID, invite := range invites {
    code code 1
    mapper.MapUIDToPackage(uid, func(package) {
      code code 2: use package value and write to res
      // these callbacks are hard to reason about because they write to
      // variables lexically available here, but execute down at Go
    })
  }
}
mapper.Go()

could be 2-pass like this (no closures)
var res
for _, team := range teams {
  for inviteID, invite := range invites {
    code code 1
    mapper.Add(uid)
  }
}
mapper.Fetch()
for res {
  package, err = mapper.Get(uid)
  code code 2: use package value and write to res
}

But you've given this more thought, so maybe a bad suggestion.

Made obsolete by https://github.com/keybase/client/pull/9692


Nothing happens after clicking RequestInfo

I downloaded this project, hosted it, opened it in my browser, connected a serial device to it and clicked request info. Nothing happens! I added an alert to recheck if the button click event was being fired correctly, and the alert does pop up, however nothing else happens. Could you help me out with this?
More Details
I am using an RS232 to USB cable that has an OTG adapter attached to it, and connecting my device using this cable to an android tablet.

The polyfill library is written in Typescript and so compilation is required before you can load the demo page. Run npm install. If that doesn't work check the developer console for other Javascript errors.

Closing due to lack of activity.


Update SDL section

Update the SDL2 section.

I don't understand why this page says there's no sdl_ttf for ocamlsdl2. It's there since a while.

Nice. I guess I just didn't find it. Thanks!


object-hash manipulates/alters the informed string before hashing it and generates an unexpected hash

Why do you "manipulate" the information that's going to be hashed and do not use the original string only?
Currently, your string hashing does the following (see here):
_string: function(string){
  write('string:' + string.length + ':');
  write(string.toString());
},

If someone uses your lib believing (s)he is hashing the informed string and that it could be compared to a hash generated in another program/language, then (s)he might run into problems. We just did.
We have 2 different applications using the a generated hash as PK on a DynamoDB table, and the values weren't matching. So I went to debug and just found that you're manipulating the informed string before hashing it.
PLEASE, add a notice about this behaviour in your docs.

Why do you "manipulate" the information that's going to be hashed and do not use the original string only?

Because that would break the cryptographic hashing property – there is no way to ensure that the hash for an object does not conflict with the hash for the corresponding string if we didn’t manipulate it.

If someone uses your lib believing (s)he is hashing the informed string and that it could be compared to a hash generated in another program/language, then (s)he might run into problems. We just did.

If you’re hashing strings only, this is the wrong library for it. This is about hashing JS objects and values, not strings, as the readme states.
If you’re hashing objects, you’re not going to get results that are comparable with other programming languages either way.

PLEASE, add a notice about this behaviour in your docs.

PRs are welcome.

Because that would break the cryptographic hashing property – there is no way to ensure that the hash for an object does not conflict with the hash for the corresponding string if we didn’t manipulate it.

Collision rate is most likely not improved by prefixing the original string. Representing any amount of data in a few bytes will cause collisions eventually.
Point taken. We've moved to pure crypto.

Because that would break the cryptographic hashing property – there is no way to ensure that the hash for an object does not conflict with the hash for the corresponding string if we didn’t manipulate it.

Collision rate is most likely not improved by prefixing the original string. Representing any amount of data in a few bytes will cause collisions eventually.

That’s not the point – the point is that we need to serialize objects to byte sequences in some way in order to hash them, but we also need to differentiate them from user input that represents that exact byte sequence as a string. For example, if objectHash({ a: 1 }) were to be implemented naïvely as hash(JSON.stringify({ a: 1 })), then objectHash({ a: 1 }) === objectHash('{"a":1}'), and that would be bad, because cryptographic hash functions should make it infeasible to generate two inputs with the same hash.

You can use any arbitrary format/sequence you want.
My concern is that the library provides an interface that allows strings to be hashed, and the hash is not generated based purely on the provided string, but rather over a sequence of different bytes. If this makes sense to this library, it's OK, but IMHO, this behaviour should be clearly stated in the docs.


Issue with Interface-Driven Controllers in Spring Modulith Project with Spring Boot Actuator Observability

Description
When using Interface-Driven Controllers in a Spring project configured with spring-web, spring-modulith, and spring-boot-actuator, the controllers do not function as expected. The issue appears specifically when including spring-modulith-observability as a runtime dependency.
For example, the following setup fails to work:
@RestController
class HelloController : HelloResource {
    override fun hello(testText: String): String {
        return testText
    }
}

interface HelloResource {
    @GetMapping("/api/hello")
    fun hello(@RequestParam("testText") testText: String): String
}

Reproducing the Issue
Here is a minimal sample to reproduce the issue:
demo.zip
When adding runtimeOnly("org.springframework.modulith:spring-modulith-observability") in the Gradle configuration, Interface-Driven Controllers fail to function. Removing this dependency allows the controllers to work as expected.
Expected Behavior
The application should process requests to the /api/hello endpoint and return the provided testText parameter as expected.
Observed Behavior
When spring-modulith-observability is included as a dependency, the endpoint does not work.

I will also include Java/Maven based minimal sample, the problem persists in it as well.
demo_java.zip

We now consider the global AOP proxying settings when applying the observability decoration. Please give the 1.4 snapshots a try!

Thank you, tried 1.4.0-SNAPSHOT and the issue is indeed resolved.

Thanks for the feedback and happy coding! 🙌


Incompatability with Farmer's Delight when registering any block skill event

I'm getting a KubeJS error when using Farmer's Delight and attempting to register any kind of block skill:
Error occurred while handling event 'BlockSkillEvents.register': java.lang.NullPointerException: Cannot invoke "net.minecraft.class_2960.toString()" because "value" is null
See the full stack trace in the KubeJS server log below.
Minecraft version: 1.19.2
Fabric
Player Skills version: 1.12.0
Block Skills version: 1.5.2
Farmer's Delight version: 1.3.9
KubeJS Log

This is Farmer's Delight (Fabric) problem as they don't expect nulls which are valid values in Java. Minecraft registeries use the null value to get the "default" whatever for that registry.


return out missing from fmt_resolution

return out missing from fmt_resolution

Oh I see it was patched here: https://github.com/hyrious/bun.lockb/commit/689d11a34bbeff23e1e9c45e6d2890af66c34d8d but not yet published

Just published v0.0.4.


[Tasks] Mismatch between input specs and task pipelines expected generation

Description
There's a mismatch between the task input spec and the expected generation parameters in task pipelines for automatic-speech-recognition and image-to-text tasks, and possibly others. Specifically, the input schema defines a parameter named generate for generation parameters. However, the _sanitize_parameters() method implemented in these task pipelines (eg: AutomaticSpeechRecognitionPipeline. _sanitize_parameters())  expects a parameter named generate_kwargs instead.
This mismatch causes errors when calling InferenceAPI according to the specified input specs.
Reproduction
If we follow the input specs defined here for automatic-speech-recognition:
import requests
import base64

API_URL = "https://api-inference.huggingface.co/models/openai/whisper-large-v3"
headers = {"Authorization": f"Bearer {os.environ.get('HF_TOKEN')}"}

with open("sample-3.flac", "rb") as f:
    data = f.read()
payload = {
    "inputs": base64.b64encode(data).decode("utf-8"),
    "parameters": {
        "return_timestamps": True,
        "generate": {
            "max_new_tokens": 100,
            "temperature": 0.7,
        },
    },
}

response = requests.post(
    API_URL,
    headers=headers,
    json=payload,
)
print(response.json())

this returns an output with an error:
{'error': 'unknown error', 'warnings': ["There was an inference error: unknown error: AutomaticSpeechRecognitionPipeline._sanitize_parameters() got an unexpected keyword argument 'generate'"]}

When replacing generate with generate_kwargs:
import requests
import base64

API_URL = "https://api-inference.huggingface.co/models/openai/whisper-large-v3"
headers = {"Authorization": f"Bearer {os.environ.get('HF_TOKEN')}"}

with open("sample-3.flac", "rb") as f:
    data = f.read()
payload = {
    "inputs": base64.b64encode(data).decode("utf-8"),
    "parameters": {
        "return_timestamps": True,
        "generate_kwargs": {
            "max_new_tokens": 100,
            "temperature": 0.7,
        },
    },
}

response = requests.post(
    API_URL,
    headers=headers,
    json=payload,
)
print(response.json())

No error in the output:
{'text': ' Thank you.', 'chunks': [{'timestamp': [0.0, 1.0], 'text': ' Thank you.'}]}

We have the same issue for image-to-text task.
I wanted to open this issue first before proposing any PR to have your opinion first on how to better align the task input specs with the task pipelines.

To be clear this is a report regarding the  json-schema definitions of tasks in @huggingface/tasks in https://github.com/huggingface/huggingface.js/tree/main/packages/tasks/src/tasks/automatic-speech-recognition/spec and such
cc @SBrandeis

cc @Wauplin as well

Thanks for flagging @hanouticelina This is quite annoying indeed. I personally don't like the idea of having an API parameter called generate_kwargs (which feels python-centric).
@ArthurZucker @LysandreJik is there a world where transformers pipelines could accept either generate or generate_parameters as kwargs instead of generate_kwargs? Since these are used for Inference API and Inference Endpoint, it would be nice to rename them.

generate_parameters does not look bad, generate is meaningless so no!

So generate_parameters it is then :)

cc @Rocketknight1 who started to work on integrating officially the specs to transformers pipelines in https://github.com/huggingface/transformers/pull/33730.
@hanouticelina let's update the specs to generate_parameters and ship it in huggingface_hub. Then transformers will be able to make the change.

Perfect! I will take care of updating the specs now :)

generate_parameters does not look bad, generate is meaningless so no!

Big +1
Or generation_parameters, if we are moving away from the Python-centric generate_kwargs.

Exactly my thinking, sorry for not explaining. Thanks @LysandreJik!

+1 @pcuenca. It also aligns with the naming used in the schema here

Even better! Agree on generation_parameters :)


add "kernel" to definition of concepts

It would be helpful to include a definition of "kernel" on the Origins and High Level Concepts page, under the Computing concepts section, as this term pops up in multiple places.

Thanks! Very good point


Trying to get styled-system working

Trying to get styled-system to work with solid-styled-system(goober) but it seem to be not working:
https://codesandbox.io/s/solid-goober-styled-system-emiq6?file=/index.js
Although, trying with emotion works:
https://codesandbox.io/s/solid-emotion-py2hy?file=/index.js
Any idea why?

Looks like Goober isn't serializing the object passed that way and just setting it to "object". I know it supports top-level object functions. I want to verify it with a different library with Goober like preact and they are in the process of winding up for 2.0.0 release. But I will look at opening up an issue on Goobers repo.

Ok confirmed this is functionality they do not have currently. While you can pass in object form top level it currently isn't supported nested in templates. I've opened up an issue. https://github.com/cristianbote/goober/issues/136

Hey there, pushed a new version 2.0.9 which now interpolates/compiles the objects inside the tagged templates as well. Hopefully this will get it going 👍  if not please let me know so I can address it.

Hi @cristianbote, thank you for the update.
@ryansolid can we please bump the goober version on the solid-styled-components package?

Sure no problem I can do that tonight.

So happy to close this one. v0.21.1. Enjoy.
Thanks @cristianbote.


Make sure Helidon support in MP starter is upgraded as we support new MP versions

The MP starter already supports Helidon, but for our support for MP 1.2.
As we support additional versions of MP we should make sure that the starter's support for Helidon keeps pace.

Close since this was addressed by PR #843 (at least for MP 2.2).

Ooops! I was thinking quickstarts. Sorry!

I've created https://github.com/eclipse/microprofile-starter/issues/192 to request and track the enhancement to the starter.

Rudy has a PR to add Helidon 1.2 MP 2.2 support to the starter: https://github.com/eclipse/microprofile-starter/pull/193

Posted  a question on the starter issue asking for an ETA. Waiting for a response.

The PR was approved today. All checks passed. Waiting for merge.

The PR has been merged. The on-line app at starter.microprofile.io does not yet show it though. I'll leave this issue open until it's there and I've had a chance to verify that it works.

Update from the PR approver:

You may watch https://gitter.im/eclipse/microprofile-starter for messages from bot about when the build is ready on https://test-start.microprofile.io/
It will appear on https://start.microprofile.io/ when we release 0.9.4

And the entry appears on the test URL but I have not had a chance to run it yet. Soon.

I will close this issue because the main site https://start.microprofile.io/ now shows Helidon as a choice for MP 2.2.
I will open another issue to do a similar update to the MP starter for Helidon and MP 3.0.


rustup fails with "missing package for component rust-analysis-aarch64-apple-ios"

I think this is my fault from my manifest change. I'm investigating. I believe there is a missing "nightly" in the archive name.

I believe there is a missing "nightly" in the archive name.

wrong

Fixed by https://github.com/rust-lang/rust/pull/40111


Set up husky pre-commit hook to fix formatting / lint on staged files before committing.

https://trello.com/c/gQdgpH03/86-set-up-git-hook-for-linting

 Set up git hook for linting

Should we run prettier too?

It turns out lint-staged does it automatically based on our .eslintrc.js

The husky npm package automatically sets up the git hooks for you, as opposed to having to make everybody manually set up the git hooks themselves (and of course not everybody will, and then we'll still have develop get broken a couple times a week).


status, status_p

Big update with more info on the random stat variation, some fixed typos, and tests for everything (unless I missed something). Should be good to merge now, possible mistakes excepted.


Fold comment with empty line inside of it (Fix #4140)

I need this fixed and I tried to fix it.
This also changes the behavior of TokenizedLine.isComment(), which is not documented in API docs and I believe this is not harmful... It now treats empty lines inside a block comment (not a single-line comment) as a comment. Thanks.

Bump-this would be nice to have :).

:+1:

:+1:

Would you mind merging in / rebasing master and fixing the merge conflicts?

I'll perform rebase tonight.

@mnquintana everything seems to be ok now.

,,,,,,
0
@ Ok
M??ll Iloilog
Polo ttseahe your t
What's this mean

Great improvement. Sorry for the extremely long delay. We have some new members on the team and processes in place to work through valuable PRs like this one more effectively.
I'm awaiting the build status of a merge commit here: https://github.com/atom/atom/compare/fold-comment-with-empty-line

Merged this via a787eb9674b09d3f9d5dedc3b107d6892a0357dc with conflicts resolved. Thanks a ton @hakatashi!


Example: Add the SPOT support for Managed Node Groups (#1129)

I have issues
I'm submitting a...

[ ] bug report
[ ] feature request
[ X] support request - read the FAQ first!
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
There is no example for managed node groups, using Spot instances
What's the expected behavior?
I would love an example.

The actual example for managed node group use SPOT instances.

The actual example for managed node group use SPOT instances.

@barryib
Sorry, somehow missed it.
I assume by that example you can't have a mixed on demand/spot instance deployment like you can using the asg style deployments?
I also don't see an option for applying additional policies to the worker nodes.

@barryib
Sorry, somehow missed it.
I assume by that example you can't have a mixed on demand/spot instance deployment like you can using the asg style deployments?
I also don't see an option for applying additional policies to the worker nodes.


Unsure how to do mutations for Class resolvers.

Is there a recommended way? I can't find anything in the docs.
I tried making a Root class and used that as the root resolver.
The Root class contains a Mutation and a Query class.
Except this doesn't work.
The example express app you have only uses Query.

I found a workaround (but might not be pleasant).
I am using Hono instead of Express by the way (so let me know if that's an issue). What I noticed is that there's a mismatch between the schema and resolvers considering that Grats is somewhat "schema-first"

"Schema-first" in the sense that you can tsdoc all the schema types anywhere you want, but it's still up to you to make sure that the "Root Resolver" you pass in the graphQL server is honors this schema you wrote).

❌1. What doesn't work (Using a Root Resolver and putting Query and Mutation properties on there and use it as a "root resolver").
/** @gqlType */
class Root {
    /** @gqlField */
    query(): Query {
        return new Query();
    }

    /** @gqlField */
    mutation(): Mutation {
        return new Mutation();
    }
}

app.use(
  "/graphql",
  graphqlServer({
    schema,
    rootResolver: (ctx) => new Root(),
  })
);

This doesn't work because the once you define Mutation and Query types in your schema, they automatically become the the topmost part of the schema. Root here is really just considered another "type" that isn't even under Query. It's still not considered topmost.
Also, I found that the queries and mutations actually don't have to be under "query" and "mutation" objects.

{
   query {
      book
      author
   }
   mutation {
      updateBook
      createBook
      updateAuthor
   }
}

In fact, they're supposed to be like this: (in one object)!

{
   book
   author
   updateBook
   createBook
   updateAuthor
}

❌2. What doesn't work # 2 (Spreading the new Query() and new Mutation() classes on the rootResolver).
Knowing that when you define your resolvers, if it technically has to have all the Queries and Mutations on the same level, not under a sublevel of "query" or "mutation", then spreading the two "instance of classes" would work right?
/** @gqlType */
export class Query {
...
}

export class Mutation{
...
}

app.use(
  "/graphql",
  graphqlServer({
    schema,
    rootResolver: (ctx) => ({
      ...new Query(),
      ...new Mutation(),
    }),
  })
);

Except this doesn't work because "instance of classes"(as in supposedly Objects), don't actually work the same way "objects (POJOs)" in JavaScript. If you're interested why, look up "enumerable properties" vs "non-enumerable properties" in Javascript. TL;DR of that is, even if you spread as the example above, those properties and methods of the object actually don't exist under the "instance of the class" (object) so they won't get spreaded because they're "non-enumerable properties". SPREAD and ASSIGN only deal with "enumerable properties".
✅ 3. Best work-around the works for me so far is this:
There is a way to make them "enumerable" or exist within the "instance". Using a constructor and assigning them with this. The reason I don't like this is that for every Query I make, I'll have to make sure I'm assigning them to the "instance" with this. That's the cleanest work-around I could find so far.
/** @gqlType */
export class Query {
  constructor() {
    this.hello = this.hello;
    this.test = this.test;
    this.wow = this.wow;
    this.book = this.book;
    this.author = this.author;
    this.books = this.books;
  }

  /** @gqlField */
  hello(): string {
    return "Hello world!";
  }

  ...
}

/** @gqlType */
export class Mutation {
  constructor() {
    this.updateBook = this.updateBook;
  }

  /** @gqlField */
  updateBook(args: { id: string; newTitle: string }): Book {
    const book = db.books.find((book) => book.id === args.id);
    if (!book) throw Error("Could not find book.");
    book.title = args.newTitle;

    return new Book(args.id);
  }

  ...
}

app.use(
  "/graphql",
  graphqlServer({
    schema,
    rootResolver: (ctx) => ({
      ...new Query(),
      ...new Mutation(),
    }),
  })
);

Let me know how you guys would approach this. Happy coding!

The way I've done this for https://api.webamp.org/graphql can be found here:
https://github.com/captbaritone/webamp/blob/25b5579157c1a5e1539ffdb68e434afdf809bbe6/packages/skin-database/api/graphql/resolvers/RootResolver.ts#L29
Basically my query class extends my mutation class. This means it has all the properties of both types. I then pass that as my rootResolver. I suspect there's a better way here though, so I'll leave this open.

Ohh right! Looking back, I think I should've just done that, extending the Mutation class.
I think spreading the instances every request seems less performant than your solution. Thanks for this.
I'll keep playing around and see what else can work. Keep up the great work! 🎉🚀

So, I've confirmed that graphql-js's execute assumes that you have a shared rootValue for both Mutation and Query: https://github.com/graphql/graphql-js/blob/7a6d055defd7a888f50c6133faae2b9010d45fad/src/execution/execute.ts#L432-L443
This does not fit very well with how Grats thinks about class-based resolvers. I'll continue thinking about a better way to model this in Grats. Maybe Grats could let you define something like:
/** @gqlSchema */
export class Schema {
   /** @gqlField */
   query() {
      return new Query({/* init options */});
  }
  /** @gqlField */
  mutation() {
     return new Mutation({/* init options */});
  }
}

my 2 cents: Having a Schema class (or function?) mirrors what's possible already with GraphQL SDL. Extending on @captbaritone 's example:
/** @gqlType */
export default class MyCustomQuery { /* ... */ }

/** @gqlType */
export default class MyCustomMutation { /* ... */ }

/** @gqlSchema */
export class Schema {
   /** @gqlField */
   query() {
      return new MyCustomQuery({/* init options */});
  }
  /** @gqlField */
  mutation() {
     return new MyCustomMutation({/* init options */});
  }
}

would become something like:
type MyCustomQuery {
  # ...
}

type MyCustomMutation {
  # ...
}

schema {
  query: MyCustomQuery
  mutation: MyCustomMutation
}

And it would also solve the same problem for subscriptions if Grats gets support for them.
While it is an extra (wrapper) class, most of the time it will be small, not too much code, and (very important IMO) it eliminates ambiguity.
I have no knowledge of Grats' internals, so what I don't know if this approach would force everyone to define a Schema class, or just using a Query as a resolver could be used as a shortcut, much like GraphQL SDL, which allows omitting the schema declaration, if the query type is literally named Query. In other words, this SDL:
type Query {
  # ...
}

is the same as
type Query {
  # ...
}
schema {
  query: Query
}

Very exciting project btw, just started to play around with it (in Deno, after a bit of module remapping)

I've looked into this a bit more, and from what I can tell, there's not a good way for Grats to be able to create the root object for a given operation and have it get passed to the top level field resolvers. Specifically, there's not really any place to hook in and create the object once per request.
TypeGraphQL seems to lean into this and treats these top level objects as global:

We can use a DI framework (as described in the dependency injection docs) to inject class dependencies (like services or repositories) or to store data inside the resolver class - it's guaranteed to be a single instance per app.

-- https://typegraphql.com/docs/resolvers.html
I'm skeptical of this approach, since data structures that are shared between requests feels like a recipe for leaking private data between users unless one is very careful. I'd prefer that dependency injection be done by adding data to the request context.
Looking forward
I'm still exploring options here. For example:

You define top level fields by defining a function that takes no root object but is annotated with something like @gqlQueryField
You define your Query and Mutation types using the existing @gqlType annotation, but we enforce that the actual type must be undefined: type Query = undefined.
Grats itself exports pre-existing Query/Mutation/Subscription types which you can use (but are typed as undefiend, so you don't get access to any concrete value)

Regarding Deno, I'm curious to hear about your experience! Are there things Grats could do better that would make it work more smoothly? If so, maybe you could open an issue and we could discuss there?

Regarding Deno, I'm curious to hear about your experience! Are there things Grats could do better that would make it work more smoothly? If so, maybe you could open an issue and we could discuss there?

I have opened an issue and created a reproduction repo with my findings so far.

Just sharing another workaround I found, pulling stuff from the  "mixins" pattern from the Typescript docs and a StackOverflow answer:

/**
 * The type of whatever arg we want to pass to the resolvers' constructor
 */
type ResolverConstructorParams = typeof ctx;

/**
 * @gqlType Query
 */
class QueryResolver {
  constructor(
    init: ResolverConstructorParams,
    // we could add a dataloader here.
    // dataloader: DataLoader,
  ) {
    /* ... */
  }

  /* ... */
}

/**
 * @gqlType Mutation
 */
class MutationResolver {
  // constructor signature has to match the rest if we want to combine them together
  constructor(
    init: ResolverConstructorParams,
    // If we added a dataloader to QueryResolver's constructor,
    // we would need to add it here as well for the signatures to match.
    // The constructor's body can ignore it if it's not used.
    // dataloader: DataLoader,
  ) {
     /* ... */
  }

  /* ... */
}

/*
 * The type hacks begin here
 */
type ResolverConstructor<T, Args extends unknown[]> = new (...args: Args) => T;

function Classes<Args extends unknown[]>(...bases: ResolverConstructor<unknown, Args>[]) {
  class Bases {
    constructor(...args: Args) {
      for (const base of bases) {
        Object.assign(this, new base(...args))
      }
    }
  }

  for (const base of bases) {
    for (const propName of Object.getOwnPropertyNames(base.prototype).filter(prop => prop != 'constructor')) {
      if (Object.prototype.hasOwnProperty.call(Bases.prototype, propName)) {
        throw new TypeError(`"${propName}" has already been defined in ${Bases.name}`);
      }
      Object.defineProperty(
        Bases.prototype,
        propName,
        Object.getOwnPropertyDescriptor(base.prototype, propName) ||
          Object.create(null)
      );
    }
  }

  return Bases;
}
/*
 * End of type hacks
 */

// We need both the `class` and `interface` definitions
export interface RootResolver extends QueryResolver, MutationResolver {}
export class RootResolver extends Classes(QueryResolver, MutationResolver) {}

// server.ts
// We now use a new instance of `RootResolver` to handle requests
app.use(
  "/graphql",
  graphqlServer({
    schema,
    rootResolver: ctx => new RootResolver(ctx),
  })
);

This is a very hacky attempt to emulate multiple inheritance, but at least the hacky looking stuff is well contained. This would also allow passing params to the resolvers' constructors, and will force all of these to have the same signature.
It probably contains bugs and limitations (for example, all instance properties must be enumerable for all of this to work)

@mandx Thanks for sharing that workaround. I can see that working! However, looking around at the ecosystem of GraphQL servers, there does not seem to be a standard way to provide a root value on a per-request basis. express-graphql (deprecated) uses the same object for all requests and Yoga does not seem to provide a way to create one at all. Ideally Grats could arrange to initialize the root value(s) once per request, but I don't see a way to do that within GraphQLSchema, and that's currently the structure Grats returns.
This is leaning me toward simply disallowing root objects all together since there's no standard way to implement it that would work with all GraphQL server implementations. Even when it is possible, how frequently the root values get recreated (once per request? once for the lifetime of the app?) is not standardized.
May I ask what you are currently using your root value for? For example, what do you use ctx for in the example you provide?
I'll try to take one more deep read through GraphQLSchema to see if I can see some way for us to hack this in before I give up on root values all together and head in the direction of all root fields being state-less (parent-less).

May I ask what you are currently using your root value for? For example, what do you use ctx for in the example you provide?

Strictly speaking, we already have a mechanism to provide a "context" object to resolvers, and that's in the contextValue key (right next to rootValue) in the object passed to pretty much any graphql-js based handler, which in turn, as you know, it's passed as the third argument to a resolver method/function. Setting contextValue or passing that to a contructor would be two ways of having shared data/resources available to all resolvers within that request.
My main pet-peeve with contextValue is that is typed as any/unknown, so when writing the resolver method, we have to specific the type we want, and trust that the value will be of that type. Using constructor constructor arguments on the other hand, provides better type safety (IMO).
However, I realize that to get this working I had to reach for some weird type acrobatics that I probably don't 100% understand, doesn't look that elegant and none of this is applicable to pure-function-based resolvers.
The key part is to provide a way to create dynamic context values, and IMO this falls out of the scope of Grats; that's on the "glue code" that connects a raw request handler with a GraphQL executor. With Deno's gql is simple because we are handle the request directly; with Yoga, one would provide a factory function as contextValue and same with graphql-http (which is supposed to be the successor to express-graphql).

I agree that the typing of context values is generally awkward. Since there are no static calls to resolver functions, there is no type-safety there. However, I think Grats is well positioned to provide this validation. We could provide some mechanism for your grats config to indicate which type you use as your context value, and Grats could validate a build time that your types conform. It can't ensure you actually provide that value to your executor, but that's defined in a single place.
I feel like this is a more robust solution to the context problem, and has well defined semantics (context values are tied to the lifetime of the request).

I've filed #21 to track the idea of allowing Grats to validate context values.

Ooohh I see what you mean now. Continuing the "context"-related discussion there.

Looking at the GraphQL docs again and this sentence stood out where it describes the parent object argument to resolvers (emphasis mine).

obj The previous object, which for a field on the root Query type is often not used.

https://graphql.org/learn/execution/#root-fields-resolvers
I think this supports my intuition that we should just enforce that the Query/Mutation/Subscription types be empty in some way and use function resolvers for top-level fields.

I think this supports my intuition that we should just enforce that the Query/Mutation/Subscription types be empty in some way and use function resolvers for top-level fields.

Seems to me that (at least for now) this is the way to go. In the future we could consider add const objects, like:
/** @gqlType */
export const Query = {
  /** @gqlField */
  me(): string {
    return '';
  }
}; // maybe this would need `as const`?

Problem is, there's still a missing piece, and is the utility (that IMO should be provided by Grats) that would inspect the Grats-generated schema, "collect" all these functions resolvers (everything that act on schema.query/schema.mutation/schema.subscription/etc and build a new object with all of these as methods/fields.
Here's how it could look like:
import {
  buildSchemaFromSDL,
  extractGratsSchemaAtRuntime,
  buildRootResolverFromGratsSchema, // -> New API (placeholder name)
} from 'grats';

const schema = process.env.FROM_SDL
    ? buildSchemaFromSDL(readFileSync("./schema.graphql", "utf8"))
    : extractGratsSchemaAtRuntime({ emitSchemaFile: "./schema.graphql" });

/**
 * Since (I'm assuming) the schema has encoded all the locations of
 * the resolvers functions/objects/etc. this would create a new object
 * with all the top level stuff merged into it, plus some additional
 * checks performed as necessary.
 */
const rootResolver = buildRootResolverFromGratsSchema(schema);

app.post(
  "/graphql",
  createHandler({
    schema: schema,
    rootValue: rootResolver,
  }),
);

For instance:
/**
 * @gqlField
 */
type Query {}

/**
 * @gqlField
 */
function me(_: Query): string {
  return 'me';
}

/**
 * @gqlField
 */
type Mutation {}

/**
 * @gqlField
 */
function sayHi(_: Mutation, { name } { name: string }): string {
  return 'hi!';
}

const resolver = buildRootResolverFromGratsSchema(schema);
/*
typeof resolver === {
  me: () => string;
  sayHi: (name: string) => string;
}
*/

This buildRootResolverFromGratsSchema API would also perform any checks necessary, and, same as buildSchemaFromSDL and extractGratsSchemaAtRuntime APIs, it would be expected to be run once during startup, not during handling of individual requests/operations.

Another idea (pulling from the context discussion we had elsewhere). We could enforce that all of your operation types were aliases of the same type:
type RootType = {
  db: DBHandle
};

/** @gqlType */
type Query = RootType;

/** @gqlType */
type Mutation = RootType;

/** @gqlField */
export function me(root: Query): User {
  return new User(db.getUserById("4"));
}

/** @gqlField */
export function deleteMe(root: Mutation): boolean {
  return db.deleteUserById("4");
}

Just like context we could then either require a /** @gqlRootType */ on that root type, or just enforce that they all match.
Then it would be up to the user to configure their executor to provide a root value of the type they specified. Again, this is just like how context works.

But don't we still need something that "collects" all the top-level operation fields into something to me used for the rootValue in graphql-js based frameworks?

In my example above we would expect the user to pass an object of type RootType as their rootValue. This same object would be passed as the "parent object" to each top level field (mutation, subscription or query). This matches the behavior of graphql-http and others.
In Yoga I don't think you get to pass any value, so you'd need to use undefined or unknown as your RootValue type.

wouldn't rootValue require an object having a type like:
{
  me: (root: Query) => User;
  deleteMe: (root: Mutation) => boolean;
}

for resolution to work properly?
Yoga is a bit different, but it still expects a resolvers key for the same purpose.

If you define a field using a free function, Grats will monkey patch the field type so that resolver is replaced with a call to the function. So, if all your fields are defined using free functions, the individual field methods don't need to be attached to the rootValue object.

Ooh I see, very cool. This makes me lean some more towards the idea of making free functions the preferred (if not the only) resolver style for top level fields.


php*Packages.oci8: init at 2.1.8

added the pecl oci8 library for php
had to make an adjustment to the oracle instantclient to make it compile
Motivation for this change
the php pecl oci8 library was missing from nixpkgs
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Fits CONTRIBUTING.md.

Went through the painful download of oracle stuff to check this out, even though I can't really test php as I have no idea about it. But stuff builds and this instantclient patch is really needed.

I had never used this either but got one of the developers to send me a simple php example and db and it ran as expected.
Thank you for the merge!


Add brand new logo to the project

Following your request in the tweet:
https://twitter.com/patrickbrouwers/status/1182557008773500929
Here it is your brand new logo. Hope you like it!

Big big thanks for the awesome logo <3

Big big thanks for the awesome logo ❤

It's done!! Thanks for patience 😃


Add ukranian

add ukranian lang

Please copy from the Meower-Svelte.pot file.

Lmao i did, and then i did the json thing

If you need the ua.po file so badly i can add it when i get home


Support browser events for unhandled rejection tracking

The naming of the events are slightly different, but should have same behavior.
https://googlechrome.github.io/samples/promise-rejection-events/index.html
I know pinkie is meant for Node.js, but people will still Browserify Node.js stuff that use it.

@sindresorhus Maybe you can give Yaku a try.

How should we handle the console output?
Chrome currently outputs a nice message that shows the rejected promise:

And then updates when it is later fulfilled:

(Note how the x changes to a check).
I have played with using window.dispatchEvent and it doesn't seem to output anything to the console. It only seems to work with native promises.
I am not sure we should be printing to the console at all, but doing so would better follow the native implementation.

How should we handle the console output?
Chrome currently outputs a nice message that shows the rejected promise:

And then updates when it is later fulfilled:

(Note how the x changes to a check).
I have played with using window.dispatchEvent and it doesn't seem to output anything to the console. It only seems to work with native promises.
I am not sure we should be printing to the console at all, but doing so would better follow the native implementation.


can not find 1.0 version

A clear and concise description of what the bug is.
How to reproduce the bug

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected results
what you expected to happen.
Actual results
what actually happens.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
(please complete the following information):

browser type and version:
superset version: superset version
python version: python --version
node.js version: node -v
any feature flags active:

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
/usr/local/bin/pip3.6 install apache-superset==
Collecting apache-superset==
Could not find a version that satisfies the requirement apache-superset== (from versions: 0.34.0, 0.34.1, 0.35.1, 0.35.2, 0.36.0, 0.37.0, 0.37.1, 0.37.2, 0.38.0, 0.38.1)

Hi there, I've encountered this issue whenever I'm on an older Python version. Python 3.7+ (ideally 3.8) is recommended:
https://pypi.org/project/apache-superset/


500 Internal Server Error  Server got itself in trouble

https://github.com/EGA-archive/beacon2-ri-api/blob/master/deploy/README.md#using-post
When running this example post request http POST http://localhost:5050/api/biosamples --json < request.json  on the test dataset on a local beacon install I get the above error.
Here is the log output of beacon:

beacon  | [beacon.request.handlers][DEBUG ] (L54) 10
beacon  | [beacon.request.handlers][DEBUG ] (L55) meta=RequestMeta(requested_schemas=[], api_version='2.0') query=RequestQuery(filters=[{'id': 'UBERON:0001256', 'scope': 'biosamples', 'includeDescendantTerms': False}], include_resultset_responses=<IncludeResultsetResponses.HIT: 'HIT'>, pagination=Pagination(skip=0, limit=10), request_parameters={}, test_mode=False, requested_granularity=<Granularity.COUNT: 'count'>)
beacon  | [beacon.request.handlers][DEBUG ] (L62) None
beacon  | [beacon.request.handlers][DEBUG ] (L72) public
beacon  | [beacon.utils.auth][DEBUG ] (L53) public
beacon  | [beacon.utils.auth][DEBUG ] (L60) ['CINECA_dataset', 'AV_Dataset', 'CINECA_synthetic_cohort_EUROPE_UK1']
beacon  | [beacon.request.handlers][DEBUG ] (L78) ['CINECA_dataset', 'AV_Dataset', 'CINECA_synthetic_cohort_EUROPE_UK1']
beacon  | [beacon.request.handlers][ INFO ] (L82) resolved datasets:  ['CINECA_dataset', 'AV_Dataset', 'CINECA_synthetic_cohort_EUROPE_UK1']
beacon  | [beacon.request.handlers][DEBUG ] (L83) True
beacon  | [beacon.request.handlers][DEBUG ] (L84) []
beacon  | [beacon.db.datasets][DEBUG ] (L27) Request parameters len = 1
beacon  | [beacon.db.datasets][DEBUG ] (L53) {}
beacon  | [beacon.db.utils][DEBUG ] (L28) Returning estimated count
beacon  | [beacon.db.utils][DEBUG ] (L37) FINAL QUERY: {}
beacon  | [beacon.request.handlers][DEBUG ] (L142) ['CINECA_dataset', 'AV_Dataset', 'CINECA_synthetic_cohort_EUROPE_UK1']
beacon  | [beacon.request.handlers][DEBUG ] (L145) []
beacon  | [beacon.request.handlers][DEBUG ] (L146) ['AV_Dataset', 'CINECA_synthetic_cohort_EUROPE_UK1']
beacon  | [beacon.db.biosamples][DEBUG ] (L28) Request parameters len = 0
beacon  | [beacon.db.filters][DEBUG ] (L21) Filters len = 1
beacon  | [beacon.db.filters][DEBUG ] (L41) Ontology filter: UBERON:0001256
beacon  | [beacon.db.filters][DEBUG ] (L44) {}
beacon  | [beacon.db.utils][DEBUG ] (L37) FINAL QUERY: {'$and': [{'scope': 'biosamples'}, {'id': 'UBERON:0001256'}]}
beacon  | [aiohttp.server][ERROR ] (L405) Error handling request
beacon  | Traceback (most recent call last):
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
beacon  |     resp = await request_handler(request)
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
beacon  |     resp = await handler(request)
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl
beacon  |     return await handler(request)
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 108, in impl
beacon  |     return await handler(request)
beacon  |   File "/beacon/beacon/response/middlewares.py", line 46, in error_middleware
beacon  |     return await handler(request)
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp_middlewares/cors.py", line 255, in middleware
beacon  |     response = await handler(request)
beacon  |   File "/usr/local/lib/python3.10/site-packages/aiohttp_session/__init__.py", line 154, in factory
beacon  |     response = await handler(request)
beacon  |   File "/beacon/beacon/request/handlers.py", line 200, in wrapper
beacon  |     entity_schema, count, records = db_fn(entry_id, qparams)
beacon  |   File "/beacon/beacon/db/biosamples.py", line 45, in get_biosamples
beacon  |     query = apply_filters(query, qparams.query.filters, collection)
beacon  |   File "/beacon/beacon/db/filters.py", line 45, in apply_filters
beacon  |     partial_query = apply_ontology_filter(partial_query, filter, collection)
beacon  |   File "/beacon/beacon/db/filters.py", line 238, in apply_ontology_filter
beacon  |     dict_regex['$regex']=label
beacon  | UnboundLocalError: local variable 'label' referenced before assignment
beacon  | [aiohttp.access][ INFO ] (L206) <IP_ADDRESS> [18/Dec/2023:14:58:31 +0000] "POST /api/biosamples HTTP/1.1" 500 245 "-" "HTTPie/3.2.2"

Hi @waakanni,
can you show what is your request.json file?
This error happens when you are trying to query by a filtering term you don't have in your filtering terms endpoint. So the beacon complains because it can't find a label for this id UBERON:0001256 inside filtering terms endpoint.
Best,
Oriol

here:
{
    "meta": {
        "apiVersion": "2.0"
    },
    "query": {
        "filters": [
            {
                "id": "UBERON:0001256",
                "scope": "biosamples",
                "includeDescendantTerms": false
            }
        ],
        "includeResultsetResponses": "HIT",
        "pagination": {
            "skip": 0,
            "limit": 10
        },
        "testMode": false,
        "requestedGranularity": "count"
    }
}

Thanks

Yes, is as I suspected. There is no filtering term for UBERON:0001256. If you run this other filtering term, UBERON:0000178, you will get some results as it appears by default in beacon reference implementation CINECA dataset. Try the request with request.json looking like this:
{
    "meta": {
        "apiVersion": "2.0"
    },
    "query": {
        "filters": [
            {
                "id": "UBERON:0000178",
                "scope": "biosamples",
                "includeDescendantTerms": false
            }
        ],
        "includeResultsetResponses": "HIT",
        "pagination": {
            "skip": 0,
            "limit": 10
        },
        "testMode": false,
        "requestedGranularity": "count"
    }
}

Thanks.

This does indeed solves the issue. Can we update the documentation?
Thanks for all the help @costero-e

Yes, I will update the documentation later this afternoon!
No problem @waakanni, thanks to you for the reporting.
Closing this issue now, let me know if you find any other.


Group Containers don't appear to work on macOS 12 / iOS 15

As I was browsing through the clients list today, I noticed @roop's iPhone running iOS 15 exhibits the same behavior that @AndrewDryga is experiencing on macOS 12.
What's happening is the firezone-id file is not able to be written to the Group Container store, causing a random one to be used each time the client authenticates. This causes duplicate clients to appear in the portal:

Fixing this will probably also fix the Tunnel Keychain popup @AndrewDryga is experiencing.

@roop I suspect fixing this for your iPhone will also fix it for macOS 12. It seems like the container store is not getting set up properly for writes on these two OSes?


#9340: Add optional output tensor to assign

Add optional output tensor support to unary assign op
All Post Commit Test : https://github.com/tenstorrent/tt-metal/actions/runs/9445831883

Added support in #12057


Add some more to Go IPAM

IPv6
Handle support
Release IPs
Cleaning up of attributes
Changed the AutoAssign signature.

@tomdee could you review?

 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.


ORC-947: Update coding guide to max line length 100 and enforce it

What changes were proposed in this pull request?
This PR aims to update the ORC Java coding guide to max line length 100 and enforce it.
Why are the changes needed?
Our coding guideline is outdated in terms of the max line length.
We had better make it consistent in our website and codebase.
How was this patch tested?
Pass the CIs.

BTW, could you try to update Apache ORC website with your new update? The following is the README to publish it.

https://github.com/apache/orc/blob/main/site/README.md

FY, I updated and published it, @williamhyun .


Issue with authorising

Expected Behavior
I expected the auth window to close and go back to my colab workbook
Actual Behavior
After I clicked on "allow", the window loaded to localhost, which was not recognised by chrome and said that the website took too long to load. Did this 5 to 6 times
Steps to Reproduce the Problem

Start a quickstart project
2.Write some code on colabratory
3.try and run the code and authorise the application

Specifications

Python version (python --version)
colabratory

The quickstart is not intended to be run directly in colab. It's meant to be run locally. The auth part of the quickstart would need to be rewritten to work in colab.
You can try and changerun_local_server to run_console to prevent it from starting up a server on localhost (which in colab case would be inaccessible) and have it expect to get the auth code via user input. I'm not super familiar with colab's environment and not sure if that would have other issues, but I'd start there.


Error with koboldcpp

I followed the instructions on how to install this program, it is running in one of my homelab servers.
When I search for anything, it returns:
[AI_NoTextGeneratedError: No text generated.] {
 name: 'AI_NoTextGeneratedError'
}

OS: debian 12
LLM runner: koboldcpp (https://github.com/LostRuins/koboldcpp)
Config file:
# Used to set the base URL path for OpenAI API requests.
# If you need to set a BASE URL, uncomment and set the following:
OPENAI_API_BASE=http://<IP_ADDRESS>:5001/v1

# Used to set the model for OpenAI API requests.
# If not set, the default is gpt-4-turbo.
# OPENAI_API_MODEL='gpt-4-turbo'

# OpenAI API key retrieved here: https://platform.openai.com/api-keys
OPENAI_API_KEY=

# Tavily API Key retrieved here: https://app.tavily.com/home
TAVILY_API_KEY=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

# Only writers can set a specific model. It must be compatible with the OpenAI API.
#USE_SPECIFIC_API_FOR_WRITER=true
#SPECIFIC_API_BASE=http://<IP_ADDRESS>:5001
#SPECIFIC_API_KEY=
#SPECIFIC_API_MODEL=

@Stargate256
Your Tavily API Key is exposed.
Don't write your API Key in an issue. I'll delete this issue.


Make error reporting more human readable

Issue: Fix error reporting so that it is more human readable
Description
Currently when an assembly file which contains errors is passed to the emulator error messages are difficult to understand, creating a difficult user experience. In order to make the emulator more easily usable and allow users to see and fix errors in their assembly files quickly, the error messages that are returned should be made to be more human readable and describe the issue concisely.

Current Example
creating an assembly file in which the instruction LDI 17, 0x01 is written, the error message returned is as follows:
ParseErrorBundle {bundleErrors = TrivialError 22 (Just (Tokens ('L' :| ""))) (fromList [Label ('w' :| "hite space"),EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "    LDI R19, 0x01\n    LDI 8, 0x45\n", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}}
"Error assembling the program"

End Goal Example
a more readable error message would likely be something along the lines of the following:
Parse Error: Invalid register label in line 2
> "    LDI 17, 0x01"

while this is merely an example and not a guideline on how it "has to be", a format such as this one is clearly readable and would be a favoured outcome.

Additional Notes
there are more types of errors than just Invalid register label, so keep in mind to not only improve error handling for this specific type of error, try creating tests for multiple types of errors such as giving a register when a hex value should be given or trying to give binary values instead of hex values, etc.

Working on it 🫡
Will be done before the new moon, I hope


Extraction of paint layers

Hi thanks for the cool lib.
I was wondering if it is possible to return just the paint layer seperate from the image.. I have tried: original_img - painted_img however
this doesn't seem to work (perhaps some postprocessing that changes resolution / pixels values subtely?)
Thanks

Right now we are taking kind of like a screenshot of the final output. The groundwork is laid now. We should be able to support the extraction soon.

is this feature ready?


modify startup flags/envs

NINEV_TAGS to become NINEV_MEMBER_TAGS
member tags and etcd hosts are comma separated

Since this changes the env vars we support, a docker push for a new minor version needs to happen as well (otherwise doing docker-compose up will pull 0.0.4 which doesn't support that env var).


[Settings] About section headers are now on a single line in collapsed mode

Summary of the Pull Request
As @htcfreek pointed out in #3656, in collapsed mode the About header has an unnecessary break. This PR sets the width of the panel to Auto in the right visual state.
Old behavior:

New behavior:

References
#3656
PR Checklist

[X] Applies to #3656
[X] CLA signed. If not, go over here and sign the CLA

Looks good to me.

Colorpickers are now no longer in collapsed mode, since they are now in a flyout anyways. Doesn't make sense to let the user click on 'more' again after clicking the color button.


authority which gives you a flexible way to add role-based permissions to your project menu

Hello sir,
Multiauth package is very useful for me, I have used it in my so many projects. only one thing is if you can add authority which gives you a flexible way to add role-based permissions to your project menu. that would be a more extensive and helpful feature for us!
for example if we have a menu like

product
revenue
customers

so if we have an authority which menu (or route) is available for which role to access

hey, have you used new version which  includes permissions also.
check out new docs http://bitfumes.github.io/laravel-multiauth

hey, have you used new version which includes permissions also.
check out new docs http://bitfumes.github.io/laravel-multiauth

sure


Feature: Add paybutton name, uuid and buttonData fields — Change paybuttonsService

Description:
Part of #33: Makes the necessary changes related to the new added fields to  paybuttonsService.ts and its tests.
Depends on:

[x] #113
[x] #114

Test plan:
The API & tests will be addressed in another PR, so those tests will fail. yarn docker t tests/unittests/paybuttonsService.test.ts should succeed.

Rebase with master.

Done.


docs: fixed typo in the contribution guide

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
successfull -> successful
Type of change
Please delete any options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] My code follows the style guidelines of this project
[ ] I ran ESLint and other linters for modified files
[ ] I have performed a self-review of my own code and tested it
[ ] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
[ ] My changes generates no new warnings
[ ] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

Thanks 🙏


update readme.md

Added 3 resources

AZ Cyberfare range- super dope live fire range for blue team red team capture the flag challenges. Beginner ranges are perfect for noobs and includ multiledae and bwapp. They provide really indepth resources. It's a awesome resource.
Added the wordpress exploit framework to tools
added xsspayloads.org to tools. also a super dope must check out resource for leveraging xss attacks.

Many thanks for contributing! :beers:


[Bug] EF Core Migration doesnt work any more after upgrading JsonWebTokens from 7.6.0. to 8.x

Which version of Microsoft.IdentityModel are you using?
    <PackageReference Include="Microsoft.IdentityModel.JsonWebTokens" Version="7.6.0" />
    <PackageReference Include="Microsoft.IdentityModel.Logging" Version="7.6.0" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols" Version="7.6.0" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="7.6.0" />
    <PackageReference Include="Microsoft.IdentityModel.Tokens" Version="7.6.0" />

(In Bug case I updated to 8.0.2 / 8.1.0, both created the bug)
Where is the issue?
see above
Is this a new or an existing app?
App exists since a few years.
Repro
When upgrading my nugets from 7.6.0 to 8.x, the EF Core migration command fails.
It works, when I dont upgrade.
EF Command:
dotnet ef migrations add Test
(but also fails on e.g. dotnet ef migrations has-pending-model-changes)
DbContext:
`    public class GenesisDbContext : DbContext
{
private readonly IHttpContextAccessor _httpContextAccessor;
    public GenesisDbContext(DbContextOptions<GenesisDbContext> dbContextOptions, IHttpContextAccessor httpContextAccessor) : base(dbContextOptions)
    {
        _httpContextAccessor = httpContextAccessor;
        AppContext.SetSwitch("Npgsql.EnableLegacyTimestampBehavior", true);
    }

// Just a few DbSets and seeding here

`
When I run with 7.6.0 the command
dotnet ef migrations has-pending-model-changes
I get:
No changes have been made to the model since the last migration.
When I upgrade to 8.1.0 I Get:
Unable to create a 'DbContext' of type ''. The exception 'Unable to resolve service for type 'Microsoft.EntityFrameworkCore.DbContextOptions`1[SMS.Server.Genesis.Data.GenesisDbContext]' while attempting to activate 'KommuneAktiv.SMS.Server.Genesis.Data.GenesisDbContext'.' was thrown while attempting to create an instance. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728
Expected behavior
Migration worked as before
Actual behavior
Migration command throws error:
Unable to create a 'DbContext' of type ''. The exception 'Unable to resolve service for type 'Microsoft.EntityFrameworkCore.DbContextOptions`1[SMS.Server.Genesis.Data.GenesisDbContext]' while attempting to activate 'KommuneAktiv.SMS.Server.Genesis.Data.GenesisDbContext'.' was thrown while attempting to create an instance. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728

@ReneKochITTitans
Which version of the ef tool do you run? What versions of EntitityFramework related packages to do you reference?
Can you run the command with --verbose flag? Maybe it'll give a more descriptive error.


Unit Test for Model Objects  for classes in org.eclipse.pass.object.model

We adapted the old test classes from pass-model in the pass-java-client project. Since we no longer need the JSON <-> object (de)serialization, these test methods were omitted. The new tests reflect changes made to the model, especially adapted for use with our new storage regime.

made changes to the unit tests to use jupiter, looks clean


SIL: Remove is_nonnull instruction

If anyone feels this is in error, please show me an executable test case that fails with this change.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 471224c5d47bcccd347dd5f51951a9146a75a99d

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 471224c5d47bcccd347dd5f51951a9146a75a99d

@swift-ci Please test Linux

Build failed
Swift Test Linux Platform
Git Sha - 471224c5d47bcccd347dd5f51951a9146a75a99d

_T0s13FloatingPointPsE08floatingB5Classs0aB14ClassificationOvgSd_Tgq5 ---> generic specialization <preserving fragile attribute, Swift.Double> of (extension in Swift):Swift.FloatingPoint.floatingPointClass.getter : Swift.FloatingPointClassification

So it even has q mangled into its name, why wasn't it marked serialized?

@swift-ci Please test Linux