Provide IGNORE option for AWS_XRAY_CONTEXT_MISSING configuration variable

Description
In #52, it was noted that calls to unsupported APIs will results in exceptions that break a customer's app. We suggested a workaround where setting AWS_XRAY_CONTEXT_MISSING=LOG_ERROR logs instead of throwing an exception as explained in our X-Ray Java SDK Documentation.
However, there are so many logs that the log file is flooded.
We should update the code to support an option like IGNORE so that neither an exception is raised nor a log message is printed out. (Or we can log at a Debug log level with LOG_DEBUG).
Perhaps we can even make it only log once so that the customer can still notice the issue.
https://github.com/aws/aws-xray-sdk-python/blob/f5f9c470b189bb34f31a1d0a28f497741132b7d2/aws_xray_sdk/core/context.py#L122-L125

Thanks @NathanielRN for your bias for action! 🚀 I would vote for the IGNORE option to silence all missing segment logs, even without logging once; because of following reasons:

The setting AWS_XRAY_CONTEXT_MISSING = IGNORE is not default, so the user will take action to set it IGNORE, so it's an informed decision.
If the traced resource is a short-lived function and uses a function with a missing context just once, it'll produce the same amount of logs since the first occurrence will be logged.

Thank you for raising this request! We will prioritize it as soon as we can, but would also be open to a PR to add support for this. It should be fairly straightforward to add - just be sure to document in README!


Cleanup ephemeral volumes if instance fails early

If an instance fails to get added early in the process (possibly due to a quota based rejection) then the ephemeral volumes for it need to be cleaned up.
Fixes: #1206

Coverage increased (+0.003%) to 66.038% when pulling 4a185f2472326b35811c9649bb24e4519c8b004c on rbradford:instance-cleanup-ephemeral into 57bc08fba54f6df07da8370052575696db32077e on 01org:master.

Coverage increased (+0.1%) to 66.104% when pulling 70fdd5c62399de10e028991909ff611d7abfcf1d on rbradford:instance-cleanup-ephemeral into a08f9ff909e97828dc4fe687e8f612e4c379e32a on 01org:master.

Coverage increased (+0.005%) to 65.92% when pulling 276ac3eff051387b72506325b7f2bc7bbc7184fe on rbradford:instance-cleanup-ephemeral into 705c4939e3d595e295d1e291a0a4ef82ab18a0d2 on 01org:master.


Fixes Blocking Warning for calibrate sensor block ev3

fixes https://github.com/OpenRoberta/openroberta-lab/issues/662

Thank you! Could you create it without the build files (just the change in robSensors.js) that way I can use the GitHub merge feature instead of doing it manually.

Oh yes, sorry. Updated.


[DOC] Improvements to Python docs.

Test build #29342 has started for   PR 5238 at commit dd91b1a.

This patch merges cleanly.

Test build #29342 has finished for   PR 5238 at commit dd91b1a.

This patch passes all tests.

This patch merges cleanly.

This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29342/
Test PASSed.

cc @davies - can you build to make sure this is OK on your computer? Also I added deprecation warning for 2 methods.

Test build #29356 has started for   PR 5238 at commit 8c1031e.

This patch merges cleanly.

Test build #29356 has finished for   PR 5238 at commit 8c1031e.

This patch fails PySpark unit tests.

This patch merges cleanly.

This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29356/
Test FAILed.

Test build #29358 has started for   PR 5238 at commit c285951.

This patch merges cleanly.

@davies I took the deprecation part out of this PR. Can you submit a PR to throw a proper deprecation warning?

Merging in master & branch-1.3.

@rxin will do.

Thanks.

Test build #29358 has finished for   PR 5238 at commit c285951.

This patch passes all tests.

This patch merges cleanly.

This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29358/
Test PASSed.


Form input lack string //avvv//

Laravel Version: 5.0
PHP Version:5.4
Database Driver & Version:

Description:
in Input of form if value = //abbb/// -> it doesnt show all the full of value-> not save correct data to db.
example:
{!! Form::text('patternCode', , ['id' => 'pattern_code',  //abbb///,'class' => 'ag__input']) !!}
Steps To Reproduce:
{!! Form::text('patternCode', , ['id' => 'pattern_code',  //abbb///,'class' => 'ag__input']) !!}

Did you mean to file a bug report at https://github.com/LaravelCollective/html ?

Yes please, report the issue there, these classes are not in Laravel core anymore.


TiKV-CDC skip the data imported by the Lightning physical mode

close by https://github.com/tikv/tikv/issues/17897


docs: startup and expectations

Write best practice guides or similar.  This should include expectations, like writing tests and managing dependency updates.
Use these as an example.
https://apps.nrs.gov.bc.ca/int/confluence/pages/viewpage.action?pageId=160074735
https://apps.nrs.gov.bc.ca/int/confluence/display/AR/NRM+Development+Standards+-+DRAFT
https://apps.nrs.gov.bc.ca/int/confluence/display/FSAAR/Communication+Structures+for+FDS

Out of scope.


make stopping at 80% at DefaultCallbackProvider.cpp.o

Running on a Raspberry Pi 3 Model B Version 8 (jessie)

Solved the issue upgrading the Raspberry PI version


Improve onboarding in readme

As someone unfamiliar with rust and fontc, I would need some help getting started. Are there and how to get precompiled binaries? How to do a local debug build?

no precompiled binaries yet. I'd start with installing the rust toolchain (https://www.rust-lang.org/learn/get-started) and then run cargo build (for default debug build) or cargo build --release, then you'll find the binaries in either target/debug or target/release sub-directories. cargo run -p fontc -- [fontc options] will rebuild and run fontc at the same time.

Can you put that into the readme?

Pardon the delay, was out for TPAC. Does https://github.com/googlefonts/fontc/pull/455 help?

Closing, please reopen if it's still hard to get started.


Anchor version mismatch causing tests to (silently) fail

Dockerized anchor test is no longer working, but (silently) failing with:
Successfully built d1622a1d555c
[2059](https://github.com/dialectlabs/protocol/runs/5171630852?check_suite_focus=true#step:3:2059)
Successfully tagged dialect/protocol-tests:latest
[2060](https://github.com/dialectlabs/protocol/runs/5171630852?check_suite_focus=true#step:3:2060)
Package binary version is not correct. Expected "anchor-cli 0.18.0", found "anchor-cli 0.17.0".
[2061](https://github.com/dialectlabs/protocol/runs/5171630852?check_suite_focus=true#step:3:2061)
Trying globally installed anchor.
[2062](https://github.com/dialectlabs/protocol/runs/5171630852?check_suite_focus=true#step:3:2062)
Failed to get version of global binary: Error: spawnSync undefined/anchor ENOENT

E.g. see https://github.com/dialectlabs/protocol/runs/5171630852?check_suite_focus=true

Resolved by #86


chore(workflow):add dataset builder to release action

Description
The dataset build will install starwhale and it's dependencies at first if use the image of base, so build an image that already installed starwhale which version is the same with server would speed up the build time.
Modules

[ ] UI
[ ] Controller
[ ] Agent
[ ] Client
[ ] Python-SDK
[ ] Others

Checklist

[ ] run code format and lint check
[ ] add unit test
[ ] add necessary doc

add the image to scripts/publish/image_sync.sh ?

add the image to scripts/publish/image_sync.sh ?

done


SWDEV-393139 - Add mipmap tests

Add 1D/2D/3D mipmap tests covering necessary data types and
config parameters.
Change-Id: I6079d9f3a2ddf4e42b8a6f7f3902322cfca02cff

This PR has been merged in internal repo.


Bump pyjwt; remove Python 2.7 build workflow

pyjwt is updated to 2.4.0

@marjan-georgiev do we need to force merge this given v2.7 was removed from the tests?

@marjan-georgiev do we need to force merge this given v2.7 was removed from the tests?

Removed the 2.7 as required check. Should be able to merge now


Documentation

Document and license the project

Since there's no more ppl invoved int he Talks repo I'll merge this.


Missing check whether $WorksheetName is longer than 31 characters

Hi, Doug. I've been working with ImportExcel for a few days. This is a great module. 👍
I found an oversight in validation of $WorksheetName. If it is longer than 31 characters, it will be truncated (I think) during the $pkg.Save() call inside Export-Excel.ps1. I haven't looked much into the EPPlus library to see how it works, but the maximum legal length for any worksheet name in Excel is 31 characters.
If you try to export two worksheets whose names begin with the same 31 characters into the same workbook, an exception will be thrown (because either $pkg.Save() or  $ws = $ExcelWorkbook.Worksheets.Add($WorkSheetname) will fail). Further, if the second worksheet's name is exactly 31 characters, then it will replace the first worksheet if ClearSheet = $True.
I cloned the repo and tested the following:
$ModulePath = $env:USERPROFILE + "\Documents\GitHub\importexcel\ImportExcel.psm1"

Import-Module -Name $ModulePath

$Path = $env:USERPROFILE + "\Documents\GitHub\importexcel\__tests__"
$Path += '\LongWorksheetNames.xlsx'

$LongName1 = "ThisWorksheetNameIs31CharactersAndThenSome"
$LongName2 = "ThisWorksheetNameIs31Characters"

$ExcelParams1 = @{
    Path = $Path;
    WorksheetName = $LongName1;
    ClearSheet = $True
}

$ExcelParams2 = @{
    Path = $Path;
    WorksheetName = $LongName2;
    ClearSheet = $True
}

$LongName1 | Export-Excel @ExcelParams1
$LongName2 | Export-Excel @ExcelParams2

This block will run without errors if the workbook at $Path does not exist. But the workbook will contain a single worksheet containing $LongName2. Run the block again, and the exception in the else block (line 576) is thrown:
Catch {
	if ($AlreadyExists) {
		#Is this set anywhere ?
		throw "Failed exporting worksheet '$WorkSheetname' to '$Path': The worksheet '$WorkSheetname' already exists."
	}
	else {
		throw "Failed preparing to export to worksheet '$WorkSheetname' to '$Path': $_"
	}

(I do not see any place where $AlreadyExists is set. I think the if block is unused.)
If you delete the workbook and swap the values of $LongName1 and $LongName2, then an exception is thrown when exporting $LongName2, since its worksheet name gets truncated to 31 characters and collides with the first worksheet. The same occurs if you comment out $LongName2 and try to re-export of $LongName1. That is how I originally ran into this problem.
I don't know what the best solution is. I suspect most users would prefer to let the export to Excel continue with the truncated worksheet name (and perhaps with a warning written to the console) as they probably won't have several worksheet names beginning with the same 31 characters. Truncating the worksheet names to 31 characters (and modifying characters at the end to make each worksheet name unique) would work, but is this a solution best left to the user? For example, this module doesn't stop you from trying to name a worksheet with forbidden characters

FYI - i already do this in my code rather than relying on Export-excel to do this - if its added fine no problem.
If you are modifying things then add in a check for "History" as that is an invalid worksheet name for excel - its used for some hidden validation by excel - if you manually create a worksheet called History you will get an error shown by excel.

When a sheet is added the EPPlus library will try to make an illegal name into a legal one.
The latest code I have checked in looks to see if the name of the new sheet is the name which was requested. If it isn't it tries to work with the new name and flags a warning to the user. This is better than before and avoids losing the data if the worksheet name is wrong; but it the test for legal names could be more complete.


chore(release): v1.0.0 🎉

:robot: I have created a release beep boop
1.0.0 (2024-05-25)
Features

init: initialize repo based on latest best practices (3981164)
type: expose AsOfGlossary and OfGlossary generics (2672198)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/domain-glossaries/releases/tag/v1.0.0 :sunflower:


An API to return the parts of the computed humanized duration

🙋 Feature Request
It would be nice if we can have a humanizeDurationParts that can return the parts of the computed humanized duration.
🤔 Expected Behavior
humanizeDurationParts would return a shaped representation of the humanized duration. For example, something like:
humanizeDurationParts(12000); // {largest: 'second', parts: [{unit: 'second', value: 12}]}
humanizeDurationParts(97320000); // {largest: 'day', parts: [{unit: 'day', value: 1}, {unit: 'hour', value: 3}, {unit: 'minute', value: 2}]}

Alternatively, we can discuss what's the best shape to return; for example:

Array ordered by largest unit:humanizeDurationParts(70000); // [{unit: 'minute', value: 1}, {unit: 'second', value: 12}]

Unordered array (would have to traverse whole array if interested in a particular unit):humanizeDurationParts(70000); // {largest: 'minute', parts: [{unit: 'second', value: 12}, {unit: 'minute', value: 1}]}

Map/Associative array (simple, but can be cumbersome when traversing):humanizeDurationParts(70000); // {'minute': 1, 'second': 12}

😯 Current Behavior
There is no such API.
💁 Possible Solution
Parse the output string of humanizeDuration? But what do you do if the output string is in a different language?
🔦 Context
Be able to use this with the Intl.RelativeTimeFormat API so that one can be able to pass the correct unit to the API to render something like 3 months ago.
💻 Examples
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
const {value, unit} = humanizeDurationParts(12000)[0]; // assuming ordered array shape
rtf.format(value, unit); // "in 12 seconds"

OR
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
const {value, unit} = humanizeDurationParts(-70000)[0]; // assuming ordered array shape
rtf.format(value, unit) // "1 minute ago"

Would the parse-ms module work for you?
This library is actively maintained but no new features will be added, so I'm going to close this issue, but I'm happy to discuss a fork or help out with another module.

Would the parse-ms module work for you?
This library is actively maintained but no new features will be added, so I'm going to close this issue, but I'm happy to discuss a fork or help out with another module.

Yes, that works, thank you very much!


GSSoC: Add an Introduction to the site at home page

We can utilize the empty space in the home page by giving short information about what is this site for and how is it beneficial. We can have a nice use of fonts and colors to make it appealing and have the links below it.
Now

Expected

add one announcement banner.

As we can see there is a lot of white space.

Sign up to https://www.oxiton.live/auth

hey @Swarnendu0123 I'm sorry but can you guide me a bit? I have started both the frontend and backend. But not able to access the site after this page.  Sorry and thank you!
https://github.com/oxiton-foundation/click-metrics/assets/149051659/486846b8-539c-4e19-a133-7499e6474ec1

Please set up our new codes, we have removed this unstructured landing page.

@Swarnendu0123 sure thank you!


Don't output default values, nulls, or empty arrays in JSON Output

Should we really avoid ouputting nulls and empty arrays?  I think we should target default values only and find a better way to expression the default value for array properties.

We should avoi doutputting nulls and empty arrays when those are the default values, not otherwise. The same as we did in FOAM1 (and the previous 10 versions).

when those are the default values

That's my point, is we don't currently have a way to differentiate between the "default value" of an array empty array or being set to the empty array.
When the default value of a property is null, or empty array, then we should absolutely not output it, but that is just an extension of the "don't output default value" policy.

After discussions, the real problem is that hasOwnProperty is not what we wanted to check most of the time.
The real user interface that people should use is "isDefaultValue()" because what they usually actually care about is if the current value is the default one, not whether something is being stored for it.
So we will add isDefaultValue, and let hasOwnProperty continue  to be "inconsistent" but encourage users to use isDefaultValue as its the "right" interface most of the time.

We should also add factory back to array properties.


[Modal] close on mousedown (right and middle mouse buttons)

Currently a Modal closes on escape and left button click, would it be possible to make it close also on right and middle button clicks (mousedown event) ?
thanks a lot for your great work :-)

Here we go, https://stackoverflow.com/questions/60568518/mui-modal-close-on-mousedown-right-and-middle-mouse-buttons


Sign MacOS (Darwin) binaries

Currently our MacOS users get a message saying that conduit "cannot be opened because the developer cannot be verified", making them jump through hoops to run the released binary. We need to sign the binaries if we want to remove this hurdle.
Related tool: https://github.com/anchore/quill

Closing as duplicate of https://github.com/ConduitIO/conduit/issues/890.


Add files via upload

@esceleto I am sorry, the domain student.napavalley.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


[BUG]ts_dataframe

[x] I have checked that this bug exists on the latest stable version of AutoGluon
[x] and/or I have checked that this bug exists on the latest mainline of AutoGluon via source installation

Describe the bug
A clear and concise description of what the bug is.
pandas dataframe
Area.x	Date			Vehicle Demand

0	1	2021-01-01 00:07:00	20
1	1	2021-01-01 01:07:00	26
2	1	2021-01-01 02:07:00	20
3	1	2021-01-01 03:07:00	6
4	1	2021-01-01 04:07:00	12
...	...	...	...
118603	1	2021-01-07 19:07:00	6
118604	1	2021-01-07 20:07:00	3
118605	1	2021-01-07 21:07:00	5
118606	1	2021-01-07 22:07:00	5
118607	1	2021-01-07 23:07:00	3
118608 rows × 3 columns
ts_dataframe for Area.x == 1
                    Vehicle Demand

timestamp
2021-01-01 00:07:00	20
2021-01-01 00:07:00	20
2021-01-01 00:07:00	20
2021-01-01 00:07:00	20
2021-01-01 00:07:00	20
...	...
2021-01-07 23:07:00	3
2021-01-07 23:07:00	3
2021-01-07 23:07:00	3
2021-01-07 23:07:00	3
2021-01-07 23:07:00	3
118608 rows × 1 columns
Expected behavior
A clear and concise description of what you expected to happen.
ts_dataframe for Area.x == 1
                    Vehicle Demand

timestamp
2021-01-01 00:07:00	20
2021-01-01 01:07:00	26
2021-01-01 02:07:00	20
2021-01-01 03:07:00	6
2021-01-01 04:07:00	12
...	...
2021-01-07 19:07:00	6
2021-01-07 20:07:00	3
2021-01-07 21:07:00	5
2021-01-07 22:07:00	5
2021-01-07 23:07:00	3
To Reproduce
A minimal script to reproduce the issue. Links to Colab notebooks or similar tools are encouraged.
If the code is too long, feel free to put it in a public gist and link it in the issue: https://gist.github.com.
In short, we are going to copy-paste your code to run it and we expect to get the same result as you.
Screenshots
If applicable, add screenshots to help explain your problem.
Installed Versions
Which version of AutoGluon are you are using?
If you are using 0.4.0 and newer, please run the following code snippet:

# Replace this code with the output of the following:
from autogluon.core.utils import show_versions
show_versions()

Additional context
Add any other context about the problem here.

temp_2.xlsx
the attached file had other area codes also like 2, 3, 4 etc but I removed them to reduce the file size

this is not a bug, I had made a mistake in my code.


[ADP-1883] add delegation-history store

For the delegation history store

[x] add a (brief) documentation on the store logic
[x] add a specification for the store logic
[x] implement delta encoding for the store
[x] implement store properties
[x] implement database backend for the DBVar over the store

Comments

Issue Number
ADP-1883

bors merge

bors merge


updated djview (4.10.5)

I reported the incorrect version number upstream, and they have corrected it.

Thank you for the contribution. It was merged directly as d175bda721616946a84aee3e08d35bd16eb03728 to keep commit history cleaner. Your contribution is still credited to you.


adds blog.djnavarro.net.json

hoping this is correctly formatted 🙂

Thank you for adding your blog to the list and for making free and open R content 😊


add kattis comp. page

:+1:

looks good :) any reason why we're removing the previously existing chess event page?


Datadog logs unsupported on the latest version of the container.

The official container is several versions behind of the natively installed agent. Logging was released in version > 6.0 of the datadog agent. Currently all containers are using the 1:5.22.3-1 version of the agent.
Would it be possible to get a version of the official container that includes a new enough version of the agent that logging is supported  or should I roll my own?

Closing because i found the official version of the container for agent 6


[SocketDevScore] Add badges for socket.dev 🛡

This adds a number of badges for the Socket (@SocketDev) JavaScript supply chain analysis service.

cc @feross you might like to take a look to this PR too!
📋 Description
This badge is for the service Socket (socket.dev) that scans npm packages for supply chain attacks.
On their report for a given npm package, e.g. fetch-cookie they show a number of scores for supply chain security, quality, maintenance, vulnerability and license:

This PR allows to embed a badge version of those scores, e.g. socket score | 99%, socket score (quality) | 85% and so on.
🔗 Data
The data comes from the https://socket.dev/api/npm/package-info/issues?name=<package> endpoint, which appears to be publicly accessible without API key. I'm not aware of an API documentation for it but the endpoint was very straightforward to find and understand.
Now I'm writing this I realize I don't have explicit authorization to use this endpoint even though it's publicly accessible so it would be great if @feross or someone from @SocketDev could look at this and give an approval (or not). 😁
🎤 Motivation
I think the Socket scores are a valuable metric for npm packages and I would like to embed them next to my other shields.io badges in the readme of my packages!

Thanks for your interest and submitting a PR
However, given that this is out of the blue without an associated issue (which is perfectly fine!), it would be helpful if you could also provide all the relevant details we ask for as part of the issue template for new badge requests.
Relevant sections from the template included below for reference, where applicable, please address all points for each specific badge you are proposing.
:clipboard: Description
A clear and concise description of the new badge.

Which service is this badge for e.g: GitHub, Travis CI
What sort of information should this badge show?
Provide an example in plain text e.g: "version | v1.01" or as a static badge
(static badge generator can be found at https://shields.io)

:link: Data
Where can we get the data from?

Is there a public API?
Does the API requires an API key?
Link to the API documentation.

:microphone: Motivation

What is the specific use case?

Thank you @calebcartwright, I just updated the PR description to follow the issue template as you pointed out :)

Thank you for the additional detail @valeriangalliat and yes we want to get some kind of documentation or official blessing before using any endpoint for reasons Chris has summarized well in https://github.com/badges/shields/issues/5506#issuecomment-1067129626

Agreed - we should get a confirmation that we're good to use this API.
As a tangent, I was reading up on socket.dev the other day. At the moment their GitHub app only supports detecting when you've accidentally added a typosquatted dependency as a dependency but their "coming soon" featureset for the GitHub app looks like it could be really useful in helping us flag package bump PRs that warrant additional review so I may talk about this more in another issue if those features materialize. I've installed it on another of my repos as a test for now.

@valeriangalliat - we're going to be unable to move forward unless and until we get some kind of explicit acknowledgement from the service maintainers. That doesn't seem to be happening here, so perhaps you'd be interested in opening an issue on one of their repos, trying a chat channel, etc.?

Thanks for following up @calebcartwright! I just asked them on Twitter and got an approval:

Is that a good enough authorization or should I ask them to post something directly in this thread? 😄

That works for me, thanks!

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @valeriangalliat!

  Generated by :no_entry_sign: dangerJS against 63f7fee5f934cb3876cb8b3064ca5b769d3f6975

The CI failures seem to be non-spurious. Are you able to get the tests passing locally? (npm run test:services -- --only=socket should do the trick)

@calebcartwright tests pass on my side:
0407220918 Server is starting up: http://localhost:1111/
  SocketDevScore
    [live] should show final score
      ✔
	[ GET /supplyChainRisk-score/npm/vue.json ] (523ms)
    [mocked] should show color
      ✔
	[ GET /supplyChainRisk-score/npm/mock-for-package-score.json ]
    [live] should show final score with scope
      ✔
	[ GET<EMAIL_ADDRESS>] (280ms)
    [live] should show quality
      ✔
	[ GET /quality-score/npm/vue.json ] (311ms)
    [live] should show maintenance
      ✔
	[ GET /maintenance-score/npm/vue.json ] (208ms)
    [live] should show vulnerability
      ✔
	[ GET /vulnerability-score/npm/vue.json ] (252ms)
    [live] should show license
      ✔
	[ GET /license-score/npm/vue.json ] (218ms)
    [live] unknown package
      ✔
	[ GET /supplyChainRisk-score/npm/npm-api-does-not-have-this-package.json ] (268ms)

  8 passing (3s)

But it looks like the CI and CD both worked after you merged master into this branch yesterday?

Hmm so they are, perhaps it was transient after all!

Apologies for the delay in review follow up. I've been poking around and one concerning item I've seen is that the upstream API is quite slow to respond. Do you know if it's attempting to perform a real-time analysis when it receives a score request?
It does seem to have some kind of caching mechanism, but the first score request for a badge often takes more than 5 seconds.
Shields has a rather tight time window in which to complete the entire request/response flow of the badge back to our users, otherwise the common places users put our badges, like GitHub, will refuse to render the badge.

I think one aspect of this is that they have not analysed the entire NPM registry, so if you request a package that has already been analysed before then it will be quicker, but if you request a package they have never analysed then it will be slow because it has to go off and do the analysis on-the-fly. I'd guess that they must also sometimes invalidate the results (can't present the same stale data forever). I'd guess they probably do that each time a new version of the upstream package is published, but it could be on a schedule or there could also be some secondary cache at play too..
I think we do have some other badges that work like this e.g: Mozilla Observatory. The first request in a 24 hour period will never load, but once it has cached the result subsequent requests will be fast. Its not ideal, but its not unprecedented.
It might be useful to understand it a bit more. IMO we could certainly live with one slow request per package version

I've been seeing the same thing all day with the packages I've been testing with, including many of the ones included in the proposed changes as examples and test targets.
I could live with something like the Mozilla Observatory experience wherein there's maybe once per day for a single person when your badge would fail to load. However, what I'm seeing so far seems to be quite different in terms of frequency. If your experience is different and closer to M.O. that's great, but mine is quite different: markedly slower, and definitely measured in terms of low single digit hours; not days.

Yeah I think we do need more info ideally. That's what I'm getting at when I say

but it could be on a schedule or there could also be some secondary cache at play too..

Interestingly, I've just tried a bunch of packages today. Some that I tried yesterday, some that I didn't. All of them returned a result quickly .e.g:

https://socket.dev/api/npm/package-info/score?name=semver
https://socket.dev/api/npm/package-info/score?name=express
https://socket.dev/api/npm/package-info/score?name=react-dom
https://socket.dev/api/npm/package-info/score?name=fetch-cookie
https://socket.dev/api/npm/package-info/score?name=yargs
https://socket.dev/api/npm/package-info/score?name=badge-maker

Then I tried https://socket.dev/api/npm/package-info/score?name=@vue/cli and it took aaaaaaaages (and the latest release for that package was ~a month ago). I wonder if there is something like the size of the codebase or size of dependency tree that makes the result for some packages take a super long time to calculate.

Great observations, thanks for the thorough review, I didn't consider this aspect.
My understanding (from this podcast) is that they analyze packages on demand and cache the results, e.g. if we request scores for express they lookup what's the latest express version, and if they already analyzed that version, return the cached results, otherwise analyze then return results (which is quite slower).
They can also change the rules for determining scores in which case, parts or all of the analysis might need to be recomputed with the new rules to come up with the score, which is also going to be slower.
What about putting a 4 seconds timeout on the request to this API and return status: pending otherwise?  Unless it happens very often that it responds in over 4 seconds...
Then, would an endpoint that:

always returns the latest cached response even if stale,
returns status: pending right away the very first time it encounters a package,

be better to back a badge?
(I'm not aware of such an endpoint nor am I in a position to create one on Socket, just asking out of curiosity)

Either way I think having Socket badges is kind of a niche use case at the moment so I wouldn't put too much effort into this until there's more demand for it. Feel free to close this PR for now, and we can always reopen it in the future if more people want this and if the Socket team is interested in implementing a compatible endpoint.
Cheers!

Either way I think having Socket badges is kind of a niche use case at the moment so I wouldn't put too much effort into this until there's more demand for it. Feel free to close this PR for now, and we can always reopen it in the future if more people want this and if the Socket team is interested in implementing a compatible endpoint.

I won't speak for Chris nor any of the other maintainers, but I'm rather intrigued by the Socket service itself and quite bullish on being able to provide badges for it as I think it's a great fit for the types of badges we like to be able to provide our community.
I think there's two related but arguably distinct tracks/considerations here.

Given that the Socket service and API contract appears to be in beta/active development, is there an opportunity for collaboration or at least for us to share some feedback that the Socket.dev team can consider when designing and building out their API surface
Could/should we try to proceed with our badge implementation based on the current state of the API

I personally would prefer a "yes" to the first, provided we've got a good way of connecting with the team (my apologies @valeriangalliat as I thought you were associated with/a member of the Socket.dev team, but realized I'm confusing a couple PRs/new badges we have open).
For the second, I'm still on the fence, but would want to dig into more than some of the anecdotal experiences we've had so far

What about putting a 4 seconds timeout on the request to this API and return status: pending otherwise?  Unless it happens very often that it responds in over 4 seconds...

Two separate things here, the first being a Shields side break-glass like mechanism with the service class to account for behavior, the second being the specifics and overall nature. Remember that there's a rather sequential flow to the entire badge request/response loop; the API call our badge servers make to an upstream provider is just one piece of that overall flow, and it's the entire flow that needs to complete in ~3-3.5 seconds. I also don't want to minimize the impact of GitHub and camo's caching as it's a very significant factor in how users experience badges.

Then, would an endpoint that .... always returns the latest cached response even if stale,

I think this would be the best, at least for our purposes. The second approach strikes me as more of a pivot to an asynchronous flow which isn't something we'd be able to utilize directly, and doesn't give us anything we couldn't already handle ourselves by limiting the amount of time we'd wait for the synchronous response and just returning pending from our end.

I personally would prefer a "yes" to the first, provided we've got a good way of connecting with the team

I'm on the Socket team and I'm happy to share this feedback with the team and help make our API work for the shields use case. Let me know how I can help. If you ever need to reach me directly, my email is @socket.dev.

always returns the latest cached response even if stale

All data in our analysis pipeline has a TTL. Some work can be cached forever. Other work (like checking the number of npm downloads a package has) cannot be cached and has a TTL set to ~1 week. If you request a package score and data is available, but stale, we'll return it for up to 1 week. This is similar to the HTTP Header "stale while revalidate". We'll return stale data that is up to 1 week old while simultaneously kicking off a new analysis in the background to update the score.
Let me just double-check with the team that the public API is using the same stale-while-revalidate logic as the https://socket.dev website itself. Will get back to you!
Let me know if I can be helpful in any other way :)

I wrote the stale while revalidate logic for socket.dev and can confirm it works like @feross said above.
To clarify, we always return data on that endpoint even if it's up to a week stale. In the the Cache-Control HTTP header, we set max-age=<time until stale>,stale-while-revalidate=<time until stale + 1 week>. So if max-age=0, that means you're getting stale data. Whenever we return stale data, we will kick off a recalculation on our backend, so hopefully next time you'll get more recent data.
One other reason that endpoint will be slow to respond is if we change the logic to compute the scores (which we do somewhat frequently as we fix bugs or enhance the analysis). We don't return stale data if the formula changed, so we can't guarantee the endpoint will be fast in general.

Thank you both very much, and apologies for the delayed response! The behavior as described certainly seems reasonable and feasible for our needs. The concern was that our experiences, albeit limited and anecdotal, didn't seem to be lining up with that description.
I'm a bit stretched on bandwidth at the moment and believe most of the other maintainers are as well, but one or more of this should get back around to testing this more thoroughly in the not too distant future.

Something for us to think about: If we're going to take this on, I think my biggest concern is that we have this badge that intermittently doesn't display a value for reasons that aren't obvious to an end user and becomes a source of questions or support requests we can't really do anything about.
So one question is: Will this API respond quickly 100% of the time, and it seems like we can deal with the answer to that being 'no'.
Then another question is: Can we present or explain that behaviour (in badge form) in a way that doesn't generate burden.

As an update, so far the response times seem much snappier, even for the packages we were seeing issues with before :heart:
The net new scans can still take a minute (figuratively, more like ~30-40 seconds literally) but that's not unexpected nor concerning.
One thing I did notice, as a rare side effect at being prone to typos, is that an unknown/bad package name is returning a 500 response whereas I'd have expected something more like a 404. Is the 500 intentional?
e.g.
$ curl -I  https://socket.dev/api/npm/package-info/score?name=gatbsy
HTTP/2 500
date: Mon, 30 May 2022 02:00:20 GMT
content-type: application/json; charset=utf-8
content-security-policy: default-src 'self' ; connect-src 'self' https://socketusercontent.com *.hubspot.com ; frame-src 'self' *.hubspot.com ; img-src * data: ; object-src 'none' ; script-src 'self' *.hs-scripts.com *.hscollectedforms.net *.hs-banner.com *.hs-analytics.net *.usemessages.com ; style-src 'self' 'unsafe-inline' ; base-uri 'none' ; frame-ancestors 'self' ; form-action 'self' https://github.com ;
cross-origin-opener-policy: same-origin
document-policy: document-write=?0
etag: W/"2b-bmZMytH5Joz1u1QlKYUq9dYqiwE"
origin-agent-cluster: ?1
permissions-policy: geolocation=(), camera=(), microphone=(), sync-xhr=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: Accept-Encoding
x-content-type-options: nosniff
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=DqUfXhS5Oza4qRYp70dpmn2ziexSSHLgDZOe%2FNgw7zAqs1Z1L8Z%2BOyhhwx%2BbKpceca6CzF1BCAN6EyiQOxraqHxXam1v%2FZ3eBsO8MmtU3lZ3G6aQY9PH6YA%2Feu3ZP97avMvJakx%2BQpw%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 7133e023aaecb09f-ATL
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

One thing I did notice, as a rare side effect at being prone to typos, is that an unknown/bad package name is returning a 500 response whereas I'd have expected something more like a 404. Is the 500 intentional?

Not intentional. We're working on fixing this.

I'm going to close given the age, but certainly feel free to reopen or follow up with us when this is ready to be picked back up!

Hello. After some discussion in https://github.com/badges/shields/issues/9174 we've settled on a pattern for handling services that work in this way (based on some of the conversation in this PR) and implemented it in https://github.com/badges/shields/pull/9233
I appreciate this has take a while, but would you be up for re-visiting this PR using the approach shown in code example in https://github.com/badges/shields/pull/9233 ?


CUDA out of memory when using long prompts and context sizes

When using a large context window (via num_ctx) and providing a large prompt, Ollama may run out of memory.

To add on this, based on my observation, it looks like Ollama calculates how many layers to offload to the GPU on the model alone - ignoring the overhead that is induced by the custom context size defined in the Modelfile.
In my experience, I can run Mistral by offloading all layers to the GPU. Specifying a bigger context size leads to CUDA being out of memory.

@jmorganca I tested the latest pre-release of 0.1.21 using one of my test cases that could consistently cause an OOM, and it seems like this issue is fixed for me. The q3_K_S model still offloads all 33 layers with a 2048 context, so that's great too. (although the q3_K_M only offloads 32 layers, even though they're virtually the same size? I guess the very slight difference is the tipping point.)
I haven't been pushing Mixtral with large contexts as much for the past week or so, but I also haven't seen any OOMs with the latest pre-release. So, I'm optimistic that this issue is fixed.

I've tried the new 0.1.22 version and seems that in my case the OOM is also fixed. It offloads less layers to the GPU. However, I tried (out of curiosity) yarn-mistral:7b-128k, and maybe because of the context window is so large, it does not offload any layer to the GPU, even when I provide exactly the same prompt.
As a reference, I have a 32 GB of RAM laptop with a  crappy GPU (NVIDIA RTX A1000 Laptop) with 4GB of VRAM.

I am using olama/ollama: 0.01.27, and CUDA: out of memory will also appear.
The model I am using is gemma:latest
The graphics card is Tesla P4.
The dialogue content is: 我现在需要你来扮演这样的角色, 比如当我对你说 "在下午3点打开客厅空调", 你返回给我一个json文本, 内容是一个类似 AST 逻辑的结构
No need to try multiple times, directly requesting this conversation after startup will crash

me to

Is there anyway to recover from this issue other than reboot the computer?
Restarting the ollama server does not work for me.
I am hoping to find an workaround until this issue is fixed.
I run into this issue on windows 11 with wsl2 ubuntu and also on  ubuntu 22.04.
The only way for me to recover is to reboot my computer.
Also is there an estimate of when this issue will be fixed?
22.04.1-Ubuntu
Mar 05 07:39:26 kenneth-MS-7E06 ollama[85037]: CUDA error: out of memory
Mar 05 11:34:14 kenneth-MS-7E06 ollama[556803]: CUDA error: out of memory

@kennethwork101 rebooting should make no difference as far as ollama is concerned. It sounds like you have other apps that are using VRAM on your GPU, causing ollama's calculations to be incorrect. (I'm not a developer on ollama, just someone who uses it.)

I experience the same issue.

Able to reproduce the issue on:  0.1.28
grep "CPU only" outollama_11.txt
Mar 06 10:26:15 kenneth-MS-7E06 ollama[2968]: time=2024-03-06T10:26:15.445-08:00 level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"
Mar 06 10:30:19 kenneth-MS-7E06 ollama[2968]: time=2024-03-06T10:30:19.651-08:00 level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"
kenneth@kenneth-MS-7E06:~/ollamalogs$ ollama --version
ollama version is 0.1.28
Wed Mar  6 10:26:12 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.161.07             Driver Version: 535.161.07   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 4070 Ti     Off | 00000000:01:00.0  On |                  N/A |
| 30%   51C    P2              58W / 285W |  10989MiB / 12282MiB |     62%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A      2968      C   /usr/local/bin/ollama                     10322MiB |
|    0   N/A  N/A      4837      G   /usr/lib/xorg/Xorg                          421MiB |
|    0   N/A  N/A      4988      G   /usr/bin/gnome-shell                         92MiB |
|    0   N/A  N/A    104107      G   ...seed-version=20240305-180126.934000      140MiB |
+---------------------------------------------------------------------------------------+

Some notes about merged #3060 - server becomes unavailable not only with "long promts", but also after some time when normally working with Ollama, with some small promts. After 1 hour or 20-30 newly-topic promts.
Logs about this issue attached in topic #3060

This should be much improved as of recent versions of Ollama. Will close for now but please do let me know if this isn't fixed and I can re-open

Not crashing on my side since couple of versions. Thanks

I'm adding a comment to this, based on advice in #4354. I am still experiencing lots of out of memory errors when it comes to ROCm with higher contexts and default batch size (usually 512). This seems to happen mostly on models that fill the entire VRAM, or would spill a bit over. The crashes often happen without using up the full system RAM (16 GB), so I'd expect things to work, even if they move slowly compared to when the model's in full VRAM.
Comparatively, my laptop that has 48 GB of RAM but no discrete GPU, can run Mixtral 8x7b at ~2 tokens per second fully on CPU and using up 30GB of RAM. But if I load, say, Deepseek Lite 16b at 32k context size, the runner crashes with an out of memory error before even starting to generate text. And it doesn't use up the system RAM either.
Should I post logs? Create a new issue?

Would like to prod this issue again, as I am still seeing this with GLM4 at 65k context size. Loads fine without much context, but has issues loading larger contexts. I even set the context size to 8k o_O.
Important bits:

It looks like GPU VRAM hits 100% but then can't spill over into memory for larger contexts. rocm-smi shows VRAM going 98%... 99%.. 100%, then crash.
Forcing GPU layers down to 15 out of 41 and disabling mmap and setting num_batch to 256 for GLM 4 makes VRAM hover around 35%, with 8k context size.
Leaving mmap disabled and num_batch at 256, and letting it load all 41 GPU layers into memory uses 69% VRAM.
Setting num_ctx to 60,000 will still make it try to load all layers into the GPU, and then it crashes because it runs out of VRAM.
Moving num_gpu down to 30 or even 20 allows it to load more context. But this is only delaying the inevitable. Long enough context will = crash.

Shouldn't ollama be calculating that it needs to load less layers into the GPU in this situation? Like I can adjust it manually, but if ollama receives num_ctx that'll make the model crash, shouldn't it start using system RAM instead?

Would like to prod this issue again, as I am still seeing this with GLM4 at 65k context size. Loads fine without much context, but has issues loading larger contexts. I even set the context size to 8k o_O.
Important bits:

It looks like GPU VRAM hits 100% but then can't spill over into memory for larger contexts. rocm-smi shows VRAM going 98%... 99%.. 100%, then crash.
Forcing GPU layers down to 15 out of 41 and disabling mmap and setting num_batch to 256 for GLM 4 makes VRAM hover around 35%, with 8k context size.
Leaving mmap disabled and num_batch at 256, and letting it load all 41 GPU layers into memory uses 69% VRAM.
Setting num_ctx to 60,000 will still make it try to load all layers into the GPU, and then it crashes because it runs out of VRAM.
Moving num_gpu down to 30 or even 20 allows it to load more context. But this is only delaying the inevitable. Long enough context will = crash.

Shouldn't ollama be calculating that it needs to load less layers into the GPU in this situation? Like I can adjust it manually, but if ollama receives num_ctx that'll make the model crash, shouldn't it start using system RAM instead?

If i may add to this, on windows it is working as intended.
1)Windows rx7800GRE(16GB) 100%GPU: llama3.1q8 loaded with num_ctx 16000, ollama swallowed vram and expanded to ram.
2)Ubuntu 22.04 rx5700xt (8GB)  13%CPU/87%GPU: llama3.1q8 gives oom when setting up context bigger than remaining 13% of gpu vram.

still very much happening...
using ollama-rocm-git 0.4.5.git+940e6277-1, on arch linux, via aur
see the log here: https://pastebin.com/YaUnz5Sg
setting n_ctx to 8k works fine

setting n_ctx to 8k works fine

how do you set it btw? i tried this but when the model loads i can still see that this string llm_load_print_meta: n_ctx_train = 32768 is still has 32k context instead of 8192

setting n_ctx to 8k works fine

how do you set it btw? i tried this but when the model loads i can still see that this string llm_load_print_meta: n_ctx_train = 32768 is still has 32k context instead of 8192 and it still crashes, but if i set up 32k context length in sillytavern it works but i guess it starting to offload to ram and becomes unresponsive

When i set context to 32k tokens, llama 7b q4 crashes on 32Gb vram system. Pagefault. All done in cli debian 12. I have two radeon 7600xt  cards 16gb each. One would think extra 20+gb is enough.


Query parameters depending on which index is selected

We need to be able to set some query parameters depending on the selected index. For instance, we're used to disable the typo-tolerance when you select the "sorted by price" index (otherwise you have very approximative results with low price first).
Any idea how to deal with that?

For instance, we're used to disable the typo-tolerance when you select the "sorted by price" index

For that specific example, we could also set the setting at indexing time.

Seems hard to make it implementable :) (searching for a solution)

We planned on having widgets emit event before doing the query, receiving the helper as parameter.
You could then plug your custom code to change the settings before the search is send. Would that work?

You can't change the configuration once it's started. But that can be fixed (everything can be fixed).
Even if we consider it's possible with events and change of configuration, it is a lot of code (with respect to the declarative aspect of the rest of the API) that the user has to create to get the proper behavior. We would need a good recipe book.

For that specific example, we could also set the setting at indexing time.

I would go for this for now then.

Even if we consider it's possible with events and change of configuration, it is a lot of code (with respect to the declarative aspect of the rest of the API) that the user has to create to get the proper behavior. We would need a good recipe book.

I would not worry too much, it's a pretty rare use-case. But I thought it was good to start chatting about it because we'll need it.

I would go for this for now then.

Yes for the sort by price it makes sense.
But here is another use case: I would love to use such widget to create a dropdown-menu filter:
Sort by:

...
v

By relevance
Only popular
Only whatever

The "Only popular" would target the same index than "Default", but add a numeric filter popularity>1000. I already implemented such thing. It can be another widget however.

Could be dealt with events modifying the helper as Tim said. If so it would be another pointer for #83
I do not see an easy way right now to have a declarative API in indexSelector to add something as "complex" as a numeric filter?

We could have a menu that is a partial state object setter. For example
var myConfigSetterMenu = configSetterMenu({
  config: {
    'By relevance': {index: 'index1'},
    'Only popular': {index: 'index2', numericFilters:{attr1:{'>': [1000]}}}
  }
});

Something like that maybe?

Needless to say that it would be great that the parameters are exclusive (especially for filters) to this widget and all the settings are consistent with each options (index and numericFilters for all the settings).

Yep like that :) I would rather speak about "filtersMenu" than "configSetter" but definitely in that way.
Then, if we accep all query parameters, we'll need to think how to merge regular refinements and such raw *Filter query parameter.

numericFilters:{attr1:{'>': [1000]}

The only drawback I see is that we will need to document a lot of the internal helper data format while right now we document the helper.methods().
So someone already using the helper would feel a bit lost I guess.

search.addWidget(
  instantsearch.widgets.filteringMenu({
    container: '#filtering-selector',
    filters: [
      { label: 'By relevance' },
      {
        label: 'Only popular',
        configure: function(helper) {
            helper.addNumericRefinement("popularity", ">", 1000);
        }
      },
    ],
    cssClass: 'form-control'
  })
);

Also exposing and advocating to use internal helper data structure will make major versions or even  modifying internal data structure while updating the helper.methods impossible because it will be "in the wild"

(we still need to think about how to "revert"):

Could be done either in the other label's configure OR as setup()/teardown() install()/revert() selected/unselected (which start to looks like events)

:horse: CLOSING BOT SAYS:

This is very old and not done, reopen if you have the need and want to fix it


fix: CameraModeArea limits, they only works in the active scene

feat: new on_active_scene component that emits a signal when the scenes becames active or non-active
Fix https://github.com/decentraland/godot-explorer/issues/78
How to use it?

Add the OnActiveScene.tscn to your scene.
Connects the signal on_scene_active to your code.
Do whatever you want, when the scene became active.

Codecov Report
Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (337b37f) 14.55% compared to head (e3351bf) 14.68%.

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

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #80      +/-   ##
==========================================
+ Coverage   14.55%   14.68%   +0.13%
==========================================
  Files          96       97       +1
  Lines       11542    11573      +31
==========================================
+ Hits         1680     1700      +20
- Misses       9862     9873      +11

Files
Coverage Δ

...land-godot-lib/src/scene_runner/godot_dcl_scene.rs
34.42% <100.00%> (+0.81%)
:arrow_up:

...land-godot-lib/src/godot_classes/dcl_scene_node.rs
70.83% <70.83%> (ø)

...raland-godot-lib/src/scene_runner/scene_manager.rs
5.41% <0.00%> (-0.04%)
:arrow_down:

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


Add pathways

Provided in https://easin.jrc.ec.europa.eu/api/cat/euconcern/

On hold until #9 is solved.


Execute button disappeared in 5.1.2 toolbar

I just installed 5.1.2 update and the triangle Execute button disappeared from the toolbar. Now I have to right click after highlighting my statement to execute.
I was trying to modify the toolbar but couldn't find a way to do it. I sincerely hope there is a way to do it (or bring back Execute button) -- otherwise I will have to revert to the previous version because not having Execute in my toolbar is majorly annoying, I really hope I am doing something wrong but the button disappeared in 5.1.2.

All execute buttons are now in the vertical toolbar on the left side of editor:

Well mine is an ORANGE triangle on an ORANGE background... Any way to change the color?

Oh, this is because of your connection type color.
Definitely an issue. Will try to fix this somehow.
Workaround: change connection type color to something less bright (connection properties->General->Connection type->Edit)

Oh that's true -- connection type !!  Thanks

But still, the question remains -- is there any way to put the Execute button on the top toolbar, which is gray and not subject to inadvertent camouflage?

No, it is not possible. We refused usage of main toolbar for editor actions. This was non obvious for many users, consumed too many horizontal space and generally was not very good looking (because main toolbar changed all the time).
I think we'll fix this issue by removing connection coloring for left vertical toolbar.

I use hotkeys instead of this buttons, so the vertical toolbar is now in my way, an ugly block in the middle of the screen. Is there a way to hide it?

No. it is not supported at the moment


Careena RW_LEGACY not starting TianoCore

Hi - if this is the wrong place to put issues, please let me know the right place and I'll report there.
I got a new CAREENA chromebook, never booted or logged in and entered developer mode.  There's an "enable debugging features" link on the initial welcome screen which I haven't seen on other chromebooks, and I clicked that and entered a root password.  Then ctrl-alt-f2'd into a shell with that newly entered password and got the mrchromebox script to work, and installed the RW_LEGACY firmware; everything looked OK.  The shell login mentioned enable_dev_usb_boot so I ran that and it said "success".
After rebooting however, it doesn't recognize USB sticks or SD cards that other chromebooks are OK with for booting; CTRL-U just beeps.  CTRL-L asks if I want 1. U-Boot or 2. TianoCore, however after that text is displayed, no keyboard input has any noticeable effect and I need to hold the power button 8 seconds to turn the whole thing off.
If there's some setting or something else to try, please let me know.  I know the AMD chipsets are new / not really supported but am very willing to try whatever / help poke around if there are promising directions on this chipset.
Also- thanks for all your work on this stuff!  I've been running real linux on cheapo chromebooks for 4 or 5 years :)

Hi - if this is the wrong place to put issues, please let me know the right place and I'll report there.

firmware-related issues go under the firmware issue tracker :)

There's an "enable debugging features"

don't touch this, only makes for problems. Unless you're building/debugging ChromeOS/ChromiumOS.  If it were needed my instructions would tell you to enable it.

The shell login mentioned enable_dev_usb_boot so I ran that and it said "success".

not relevant, only used to boot ChromeOS/ChromiumOS from USB

CTRL-U just beeps.

expected, you don't have a USB w/ChromeOS inserted

CTRL-L asks if I want 1. U-Boot or 2. TianoCore, however after that text is displayed, no keyboard input has any noticeable effect and I need to hold the power button 8 seconds to turn the whole thing off.

some AMD Chromebooks have issues with legacy/alt-OS mode, CAREENA appears to be one of them.  I have 3 here, 2 work and 1 freezes like you are experiencing. Issue is on Google's end unfortunately.

OK thanks, will keep an eye out for any developments.
I'd offer to test any new script / firmware on mine (sounds like you have a bunch of them though!)

Not sure if I should open an issue over on the firmware repo or if this is not useful, but --
I went back to chromeos developer mode (CTRL-D) and logged in, gave it a network connection and chromeos did some updates.  After updates happened, re-ran the mrchromebox script for RW_LEGACY, and now with CTRL-L I can get into TianoCore.  (The 1 / 2 options aren't displayed; just a white screen with "Alternative Firmware Menu" in the center and no options, but pressing 2 does get to the rabbit logo of TianoCore).
I've tried Debian & Lubuntu installers and they seem to choke on display issues (I get a kind of interlaced / mangled text mode that's still readable enough to see Xorg display errors).  Even with the mangled video, I managed to get into a terminal and run aplay and got sound to come out from the headphone jack (not speakers though).  Suspend also seemed to have the same TPM issue that Apollo Lake chromebooks have where it wipes the legacy boot functionality on resume.
Anyway just reporting the change; running google's chromeos update may also allow the CAREENA laptops which freeze to enter legacy boot.  I'm happy to open an issue at the other report & report what works / doesn't work with various things I try if that would be helpful.  If not, no problem.

on the AMD devices I've tested here, Ubuntu (19.04+) boots without issue, but internal storage is not usable/bootable. The suspend/resume issue is same as Kabylake etc -- need latest kernel with patch to support CR50 TPM, or disable suspend until merged into released kernel. Haven't tried Debian or Lubuntu so can't speak to those

Interesting -- will try Ubuntu 19.04.  With Lubuntu 19.04 (but not Lubuntu 19.10!) I am able to see the eMMC partitions and read the chromeos filesystem, but I haven't tried repartitioning it. (TianoCore can't see it so guess wouldn't be able to boot anyway)

(TianoCore can't see it so guess wouldn't be able to boot anyway)

possible to boot grub on USB/SD, and have root/boot partitions on eMMC. But untested :)


Restrict/Require fields during create/update with the GraphQL transformer

Is your feature request related to a problem? Please describe.
Currently the transformer assumes that all fields should be settable during create/update. It also assumes the nullability during create/update matches the type. These aren't always true.
Examples:

I may allow setting the projectId when creating a Task but not allow it to be changed when updating the Task.

The Task may have a field project: Project allowing the project to be null (making fields nullable by default seems to be best practice for GraphQL and helps the API/applications cope if the related object is deleted). During createTask() I may want to require the projectId.

I may define project: Project! and allow but not require projectId during update task which would leave the old value in place.

Describe the solution you'd like
I'd like to see two new field level directives
directive @create(
  allowed: Boolean,
  required: Boolean
) on FIELD_DEFINITION
directive @update(
  allowed: Boolean,
  required: Boolean
) on FIELD_DEFINITION

If they are not provided then the transformer should add the field to both the create and update inputs with the same nullability as the type. This is how it currently works.
project: Project @create(required: true) @update(allowed: false) would generate a create input object where projectId is now required and an update input object where projectId cannot be set.
Describe alternatives you've considered
Not using the transformer.
Additional context
The Github API is a public real world example of this requirement.

Another example of usage would be putting updatedAt and createdAt fields on a type so they can be read while preventing them being set by create/update mutations. Currently you can do this but you need to define the entire create/update input type.

@attilah @kaustavghosh06 lets add this as part of the upcoming model updates

@kaustavghosh06 @attilah  - is this WIP?


Cannot find module 'node:path' with new version

Hi!
Before new version of the plugin it workd fine, but now
var path = require('node:path');
var util = require('node:util');
var os = require('node:os');

calls a bug "Error: Cannot find module 'node:path'" in my VSCode
Changing var path = require('node:path'); → var path = require('path'); and other 2 rows fixes my issue.
Node version: 14.15.5
npm: 6.14.17
VSCode: 1.68.0
Thanks!

fixed by #9

Thanks! ☺


fix running bugs....

Solved the following two bugs：
1.
    |                                                                                ^ help: remove this semicolon

warning: unused imports: `Deserialize`, `Serialize`

Thanks a lot @jsmmmmm !


Typo?

During the initial Deploy to Heroku step, after clicking the Create App button, below SLACK_WEBHOOK_URL it says Discord Web Hook URL (which it also says above for DISCORD_WEBHOOK_URL). I am still just getting this setup for the first time, and I assume it is innocuous, but it is definitely confusing.

Thanks!

Yep!  This is going to be fixed in the next update that I will hopefully get out in the next day before Sunday's game.  It will completely remove the env variables as well.

v3.0.0 fixes this: https://github.com/LandonPatmore/yahoo-fantasy-bot/releases/tag/3.0.0


ZipAESTransform uses ECB.

AES ECB mode at line 80 is no longer considered secure.  Is there a more secure solution?

Well, the thing is that ECB by itself is not secure, but what WinZip AES encryption uses is CTR.
But since System.Security.Cryptography doesn't support CTR mode we have to implement it by hand. So the only reason we select ECB mode here is so that we can build our own mode on top of it, if that makes sense.
Although even if CTR would be considered insecure, we couldn't just replace it with something else. The encryption is part of the standard, and doing something else would mean that we wouldn't be able to read files created by any other library (and no other library would be able to read our files).

Thank you,


Release automation

Let us add (yet another!) GitHub Actions workflow such that:

Pushing a matching release tag would run tests, build the package, and publish the packages built on CI on PyPI.
This should also "activate" the corresponding version on readthedocs project. Currently this is a manual process, and I often forget to do this step.

PyPI now has the concept of trusted publishers and there's a GitHub Action for publishing packages on PyPI, both of which are useful.
Upside is that some more steps would be automated, which will eliminate some mistakes like forgetting to activate an API doc version on ReadTheDocs or forgetting to push a release tag to GitHub.  Downside is that fablib has already become a special snowflake in the FABRIC universe with all these annoying CI bureaucracy. ;-)

It probably should be possible to automate the GitHub release step too.  I missed this step when tagging 1.5.2, and only remembered about it when @kthare10 made the GitHub release.


wrong XPATHs Scrape tutorial

All the XPATHs on livingsocial_spider.py is wrong. So because of that the scrapy doesn't generate any data.

@caynan - wrt iPython notebooks - yes! during the long holiday weekend in two weeks, I have plans to "hack" all weekend on new coder (finally).  If you'd like to participate with me - like via IRC or something - let me know! even if it's for a few hours.  @merwok you interested at all?

@caynan - wrt iPython notebooks - yes! during the long holiday weekend in two weeks, I have plans to "hack" all weekend on new coder (finally).  If you'd like to participate with me - like via IRC or something - let me know! even if it's for a few hours.  @merwok you interested at all?

@econchick sounds like a plan for me :smile: I'm caynan on freenode, just ping me.

@econchick sounds like a plan for me :smile: I'm caynan on freenode, just ping me.

Hey @caynan.  A couple of things:

I took your PR code and adapted it in - thank you so much!  I also made a couple of changes (e.g. since there's no category of deals, I just removed it entirely, as well as added orig_price field and end_date field).
About the iPython NB - I've decided that I want to create IPyNBs for all the tutorials (tutorial language & code) for the "Workshop Kit" portion of the site (newcoder.io/workshop).  I am going to create a separate issue for that describing more in detail.  If you want, you can assign it to yourself (the whole issue, or particular tutorials).

I'll push a site & code update a little bit later.  Thanks!

Hey @econchick
I'd love to help with the IPyNB migration, should I just create a notebook containing the text and the codes as already in the tutorials?
Or should we try to do something like leaving cells blank for the user to fulfill?
:smile:


RabbitMQ transport

I'm working on a RabbitMQ transport, where messages would be published to an exchange, with a routing key of format schema.table.operation.  Is there interest in accepting this upstream when it's ready?

Absolutely! Once it's ready I'll see who can review it as I don't have operational experience with RabbitMQ. I encourage adding integration tests.
/cc @nehalrp

Great.  I'm almost done.  I have the performance where I like it (1 million messages in ~4 minutes, on my dev laptop).  I didn't add retry semantics (yet) because I wasn't sure what would be appropriate for RabbitMQ besides shutting the whole thing down and letting docker restart it.
Still working on the tests.  I'm not sure what refactorings will fall out of the testing, so I haven't pushed my branch yet.

PR here: https://github.com/Nextdoor/pg-bifrost/pull/19

Closing this as the PR was merged.


Provide Intent Oriented Syntax

I would like to have a syntax that focuses on intent to improve further on readability. So instead of
                    Responses
                        .WithStatusCode(200)
                        .WithBody(@"{ msg: ""Hello world!""}")

I would prefer
                    Responses
                        .Success
                        .WithBody(@"{ msg: ""Hello world!""}")

other example
                    Responses
                        .RedirectTo("/bar");

I think it may also be helpful when you want to simulate ill behaving servers

I would prefer method chaing instead of properties, something like:
Responses
    .WithSuccess()
    .WithBody(@"{ msg: ""Hello world!""}")

This way I find the alias/shortcut more obvious.

Makes sense to me. The next question is more: which use cases should be supported through shortcuts. Should we list broad categories (such as 2xx = with success, 3xx = WithRedirect, 4xx = WithRrror, 5xx=WithServerError) , or dig into more specifics (404=WithNotFound)?

Thanks for the feedback
The problem is HTTP defines quite a bunch of possible status code.
I think it is a good idea to list most common scenario as listed by dupdob and keep a generic WithStatusCode() method for hedge cases.
WDYT?

We definitely need both shortcuts for the most beaten paths as well as the ability to be very specific for the edge cases. In order to favor the 'pit of success' factor, one need to makes what is frequently used easy and what is less frequent possible. So I would propose:
Responses.WithSuccess() // ok for any 2xx code
Responses.WithOk() // ok if code = 200
Responses.WithSuccess().AndCode(2xx) // ok for code 2xx
Responses.WithError() // ok for any 4-5xx
Responses.WithNotFound() // ok for 404
Responses.WithInternalError() // ok for 5xx
Responses.WithSpecific().ForCode(xxx) // ok for code xxx
see the idea. Writing those samples, I realize I feel there is a wording issue with 'Responses'


Implement new builder pattern for serializing tables and unions

Checklist

[x] Updated CHANGELOG.md with relevant changes
[ ] Added tests for any new/fixed functionality
[x] Added/updated documentation for new/changed code
[x] Checked that README.md still makes sense (and updated it if necessary)

We are missing a few tests, this will be done in a follow-up PR. Added #156 to keep track of it.


Compiling cartographer & cartographer_ros with a customer install directory for protobuf3

I am trying to build/install cartographer and cartographer_ros with a custom location for protobuf3 while not adding the protobuf3 to the install folder. I do not want to add protobuf3 to my current catkin workspace directory as I have different packages depended on the system installation of protobuf2 (If i add protobuf3 to the install directory all works fine, but I need to use a custom location).
I have forked cartographer (see: fork). With this fork and the changes to the cmakelist I am able to compile cartographer but no longer able to compile cartographer_ros due to conflicting version of protobuf. See error:
 error: #error This file was generated by a newer version of protoc which is
 #error This file was generated by a newer version of protoc which is

I feel like I am missing something in the cmakelist of cartographer.

Protobuf has a compiler and a library, all have to match in both cartographer and cartographer_ros builds.
I think you can select which protobuf to use in the cmake flags
 Protobuf_INCLUDE_DIR             /usr/local/include
 Protobuf_LIBRARY_DEBUG           /usr/local/lib/libprotobuf.so
 Protobuf_LIBRARY_RELEASE         /usr/local/lib/libprotobuf.so
 Protobuf_LITE_LIBRARY_DEBUG      /usr/local/lib/libprotobuf-lite.so
 Protobuf_LITE_LIBRARY_RELEASE    /usr/local/lib/libprotobuf-lite.so
 Protobuf_PROTOC_EXECUTABLE       /usr/local/bin/protoc
 Protobuf_PROTOC_LIBRARY_DEBUG    /usr/local/lib/libprotoc.so
 Protobuf_PROTOC_LIBRARY_RELEAS   /usr/local/lib/libprotoc.so

Of course, you would install protobuf3 in a non-system folder, not in /usr/local.
Perhaps your solution is almost working, just look at the (hidden) cmake flags for both cartographer and cartographer_ros.
Yet another alternative solution is the install script here: https://github.com/googlecartographer/cartographer_ros/issues/625#issuecomment-358318701

Closing as answered


Create GETTING_STARTED.md

just a link to docs.astrnomer.io tutorial on SDK
Description
What is the current behavior?

What is the new behavior?

Does this introduce a breaking change?
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

We already have the same link in the README. You have added it in #1000 🤔 Do we really need both?

Mainly because https://astro-sdk-python.readthedocs.io/en/latest/ has nothing at all in Getting started?

Makes sense, thanks @kaxil.


Tenant ID getting mangled

On a fresh deployment, using the install utility and ARM template, the admin app is mangling the tenant ID. Specifically it's combining common with the actual tenant ID to produce something like the following (actual tenant ID redacted):
System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (BadRequest). ---> Microsoft.IdentityModel.Clients.ActiveDirectory.AdalException: {"error":"invalid_request","error_description":"AADSTS90002: Tenant commonactualtenantid not found. This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.\r\nTrace ID: 4cef0c66-fd72-4852-9378-308f8f142b00\r\nCorrelation ID: 815618e0-6ccb-41de-af08-96086ba8de9e\r\nTimestamp: 2018-08-22 22:01:58Z","error_codes":[90002],"timestamp":"2018-08-22 22:01:58Z","trace_id":"4cef0c66-fd72-4852-9378-308f8f142b00","correlation_id":"815618e0-6ccb-41de-af08-96086ba8de9e"}: Unknown error

Instead of using the actual tenant, or just using the common tenant, it's concatenating the two. I've attempted re-deploying, and manually modifying the appsettings.json on the service. The appsettings file has the correct tenant ID, but it continues to concatenate common to the front of it.

Hi @kudakeru, I'm sorry to hear that.
I'm a bit confused as to the sequence of events and what was modified where.
The appsettings.json from the service should not need to be modified at all. The configurable values override that and are stored in the settings key vault that was created.
As far as I know, the only place the common endpoint is used is in the InstallUtility for login. After that, it shouldn't be anywhere else, and it's not one of the parameters stored in Key Vault.
Can you please clarify what the sequence of steps were?

Thanks for taking the time. We started by running the install utility,
setting the necessary parameters in the ARM deploy template, and then
running the ARM template deployment. We ran into some permissions issues
because we were trying to use a keyvault in a different resource group, but
that was easy to fix. This was when we ran into the issue with the tenant
ID not being found.
In trying to troubleshoot that, I've attempted modifying the
appsettings.json file directly through the resource explorer in Azure, and
modifying the file via FTP. I've also tried a complete redeploy. The tenant
ID has always been set to the correct value, but for some reason it's still
trying to combine common with the actual tenant ID.
On Wed, Aug 22, 2018 at 5:30 PM, Oren Novotny<EMAIL_ADDRESS>wrote:

Hi @kudakeru https://github.com/kudakeru, I'm sorry to hear that.
I'm a bit confused as to the sequence of events and what was modified
where.
The appsettings.json from the service should not need to be modified at
all. The configurable values override that and are stored in the settings
key vault that was created.
As far as I know, the only place the common endpoint is used is in the
InstallUtility for login. After that, it shouldn't be anywhere else, and
it's not one of the parameters stored in Key Vault.
Can you please clarify what the sequence of steps were?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/onovotny/SignService/issues/45#issuecomment-415231980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjCH4I7GCwVW_5jLE1YHMgRTH6InCTJks5uTfeUgaJpZM4WIfrv
.


feat: add app_configuration model and generator

What type of PR is this?
/kind feature
What this PR does / why we need it:
Add app_configuration model and generator

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 28 (3.57%)  changed or added relevant lines in 2 files are covered.
7 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 72.199%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/cmd/spec/generator.go
0
27
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/cmd/destroy/options.go
7
84.08%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
5103

Relevant Lines:
7068

💛  - Coveralls

clean commit logs and fix ut coverage report in #451


document auto versus user in important concepts

See title.

Will be resolved when https://github.com/Vector35/binaryninja-api/commit/0f945f368210359d60654f2baa35e40539d8238f lands on dev


Print the entry point of the images

When building, print the entry point of the images for users who wants to customize the entry point. Without the entry point printed, it's not clear where the binary is stored without building a debug image.

I'm a weak -1 on printing this out during build, but I could be convinced. Aside from added spam in the logs, the bigger reason is that:

[ko] aims to make packaging, pushing, and referencing container images an invisible implementation detail of your Kubernetes deployment, and let you focus on writing code in Go.

If you have to care about what your image's entrypoint is, we've probably done something wrong. There currently isn't a way to change that location within the image at all, and we've sort of resisted adding one.
Would you accept adding a sentence to the README that documents the location of the binary in the image, in case a user happens to care?

The rationale behind this request is container orchestrators/products require you to provide the entry point if you want to override the default arguments. When I have to provide the binary name with the arguments, I need to know where the binary is.

Would you accept adding a sentence to the README

Yes, documentation is sufficient.

One more thing. It only takes one debug image to figure it that it's under /ko-app but given the binary name is generated from the package name, I thought that maybe it would be good to print it at ko publish but it's fair to say ko users shouldn't know what's in the image.

I thought that maybe it would be good to print it at ko publish but it's fair to say ko users shouldn't know what's in the image.

I think this could still be reasonable, but I'm a little concerned about spamming logs too much.
It's fairly straightforward (for me) to do:
$ crane config $(ko publish . 2>/dev/null) | jq .config.Entrypoint
[
  "/ko-app/ko"
]

... but I understand that this could be simpler for people who don't care about container tooling that much 😅


Improvised solution

This is a work in progress
ForkingBanner's wrapper was modified to  in order to avoid conflicts with .app-styles_Main__content > section and <div> styling in some pages.
A fix using !important was considered but discarded.

Chatted with @phoebemirman about the banner. She suggested putting the banner in App.tsx. It does make logical sense but I think there is an issue with the responsiveness stuff pushing the banner under the header and navigation. Is that what you were seeing?

Chatted with @phoebemirman about the banner. She suggested putting the banner in App.tsx. It does make logical sense but I think there is an issue with the responsiveness stuff pushing the banner under the header and navigation. Is that what you were seeing?

@bthaile I'm testing it right now. First attempt: it breaks the scrolls.


getting failed to decrypt rsa message error

hi sorry for my message , any suggestions? PC hoster can join fine, but the other PC cant

The other PC is trying to connect using the public key for the server.
How are they connecting? Via a ds3sconfig file or via an advertised server?


Unify expected behaviour in store specific READMEs.

I just noticed when writing the README for the Neo4j store that the sentence in the PgVector store is a little bit vague.
Yes, it's true that the document will be there but it is either to expect that it is the first in the collection or we should set the "top-k amount" to 1 in the example snippet, or?
https://github.com/spring-projects-experimental/spring-ai/blob/0a584f0dc2483ef9ad0741c8598998e489b64726/vector-stores/spring-ai-pgvector-store/README.md?plain=1#L141-L145
A little bit tweaked in the Neo4j store README:
https://github.com/spring-projects-experimental/spring-ai/blob/0a584f0dc2483ef9ad0741c8598998e489b64726/vector-stores/spring-ai-neo4j-store/README.md?plain=1#L114-L118

I think the testing of the vector stores is rather anemic , we sort of trust they implemented it right, but with the same data we are using, it is a bit vague indeed.  I'll rename this to be 'Investigate Documents Used for VectorDB testing'.  Perhaps some of the methods you used to test the neo4j vector store itself would be more generally applicable here?  @meistermeier ?

Thanks for your input, Mark. I think you are interpreting more into the issue than I intended to mention.
My point was only that a List<Document> contains the document. Just a little bit wording.
Given your input, I am thinking about if a AbstractVectorStoreTestBase containing the test dataset, invoking the similaritySearch methods, and asserting the result would make sense. Some kind of "cheap" TCK.
From my perspective an enforced >90% hit ("Spring") should always be first of the list.

I see your point, contains is better than assuming it would be first, but for now, I think we can spend time more effectevly on other areas.  Should issues come up with our vector db testing approach for new vector stores, we can revisit.  Thanks for the comment.


mleap enhancments

[x] Add support for Keras
[ ] Add support for PyTorch
[ ] Add support for DL
[ ] Add support for LSTM

when support pytorch model  save and load ？

Supporting pytorch is difficult because pytorch does not have any java bindings (to my knowledge at least).  The best option for supporting pytorch is probably to support something like ONNX and then have folks convert their pytorch models into ONNX before serializing.

Supporting pytorch is difficult because pytorch does not have any java bindings (to my knowledge at least). The best option for supporting pytorch is probably to support something like ONNX and then have folks convert their pytorch models into ONNX before serializing.

ok, if pytorch has  java bindings,do you know how to save pytorch save and load, maybe I could do it ,just tell me the method is ok

There currently isn't any pytorch support in mleap.  You'd need to create:

a new mleap transformer
a new mleap op
a new spark transformer
a new spark op

Basically look at everything which exists for tensorflow and need a new variant of that for pytorch.

There currently isn't any pytorch support in mleap. You'd need to create:

a new mleap transformer
a new mleap op
a new spark transformer
a new spark op

Basically look at everything which exists for tensorflow and need a new variant of that for pytorch.

thanks, If I success ,please  pick up me code


feat: Support for threads in Angular SDK

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


BUG: Give touch events more priority then pointer events

Fix for  #151

After testing I see that touch events not so robust as pointer events.


Add timeout of travisCI

Description
Less than 10 min for system contract tests.
Additional Information
https://travis-ci.com/cryptape/cita/builds/111543411

There is no timeout for a build; a build will run as long as needed to complete all the jobs, but will stop immediately if any job hits a timeout limit.

close it. and check #555


Issue with serializing callables for parallel processing.

I have a bunch of background tasks in a Symfony application and I'm trying to process it parallel using this library. My background tasks are Symfony services with an execute function.
The following code contains a sample implementation of my task engine.
        $noOfTasks = 100;
        $engine = $this;
        wait(each(
            Iterator\fromIterable($this->load_tasks_from_db($noOfTasks)),
            new LocalSemaphore(10),
            static function ($task) use($engine) {
                $service = $engine->container->get($task->getProcessor());
                yield Worker\enqueueCallable([$service, 'execute'], $task);
            }
        ));

Here when the $service contains a lot of dependencies Amp library throwing the following error
app.CRITICAL: The given data could not be serialized: Serialization of 'SimpleXMLElement' is not allowed
It's is coming from NativeSerializer, even if I try the following code also I'm getting the above error.
$service = $this->container->get($task->getProcessor());
try {
     \serialize($service);
} catch (\Throwable $exception) {
    dump(sprintf('The given data could not be serialized: %s', $exception->getMessage()));
}

This is not a problem with Amp library but my question is how we can execute callables parallelly if it contains a lot of dependencies?

Instead of passing and thus serializing your service, you can just send the data to process and create the service only inside the closure, so it'll be created in the child process / thread instead of being serialized.

Hi @kelunik -  I need to pass the callable with all the dependencies right? here my callable is a service from the container. I'm still not sure what you meant by 'create the service only inside the closure'. Could you please provide a sample code?
Thanks for the help!

Instead of getting the service from the container and using it as callable, create a new container / service instance inside the callable you pass to enqueueCallable.

create a new container / service instance inside the callable

In that case, I need to create a callable with a DI container inside it. That is also failing because the DI container inside the callable needs to be sterilized. Please see the below code
class MyCallable
{
    /** @var Container */
    private $container;

    public function __construct(ContainerInterface $container) {
        $this->container = $container;
    }

    public function process(Task $task) {

        $taskService = $this->container->get($task->getProcess());
        $taskService->execute($task);
    }
}

yield Worker\enqueueCallable([$myCallable, 'process'], $task);
app.CRITICAL: The given data could not be serialized: Serialization of 'Closure' is not allowed

Don't serialize DI container, create a new one in the Task.

Hi @enumag, Thanks for the help it's working perfectly!

Hi, just one more question instead of bootstrapping the application for each task, can we share the DI container across processes. I getting the following error when I bootstrap the application for each procesesses.
ERROR: fork() failed: Cannot allocate memory (12)

Starting the process failed

Instead of using a callable, you can implement the Task interface and store the kernel / container in the environment received as parameter.

@kelunik - could you please share a sample code or provide an example code link?

https://github.com/amphp/parallel/blob/107e093006376f95a1a95a72e211ef3eced4c400/lib/Worker/CallableTask.php is a very simple implementation powering the enqueueCallable API.

Personally I don't recommend using CallableTask. In my personal opinion it's a bit of an anti-pattern that can easily cause problems. Programmers tend to pass a callable that uses some services and those should not be serialized. Personally I have an abstract BaseTask where I implement the creation of new Container as posted above and some logic around that (methods to get a service or a parameter). Then I have custom Task classes which take some arguments the task needs (typically scalars or easily serializable value objects). Something like this:
abstract class BaseTask implements Task
{
	protected function createContainer(): ContainerInterface
	{
		if ($this->env['APP_DEBUG'] === '1') {
			Debug::enable();
		}

		$_ENV = $this->env;

		$kernel = new Kernel($this->env['APP_ENV'], (bool) $this->env['APP_DEBUG']);
		$kernel->boot();

		return $kernel->getContainer();
	}
}

final class ProcessFileTask extends BaseTask
{
	private string $file;

	public function __construct(string $file)
	{
		parent::__construct();

		$this->file = $file;
	}

	public function run(Environment $environment)
	{
		// here I try to grab DI container from $environment
        // if it doesn't exist there, I create a new one and store it there
        // the reason is that the Environment still lives in the Worker so if the Worker later gets another Task to process then the container will be there already

		if (! $environment->exists('container')) {
			$environment->set('container', $this->createContainer());
		}

		$container = $environment->get('container');

        // then I pull a service from DI container and use it
	}
}

to answer your question:

can we share the DI container across processes

No. Each process has it's own memory. There is no way to access a container from another process. "Sharing" it would basically mean serializing it to get a copy of it in the new process but please avoid this. Container is not meant to be serialized.
That said, you typically shouldn't need too many services from the container to process the Task so memory shouldn't be a problem. I actually suspect that your memory problems are caused by you accidentally trying to serialize the container.

Hi @enumag, my current implementation is the following.
<?php

$env = [
    'APP_ENV' => $this->container->get('kernel')->getEnvironment(),
    'APP_DEBUG' => $this->container->get('kernel')->isDebug(),
];

$taskProcessor = new TaskProcessor($env);

$engine = $this;
$jobs = 0;

wait(each(
    Iterator\fromIterable($this->fetchScheduled($amountOfTasks)),
    new LocalSemaphore($poolSize),
    static function (Task $task) use ($engine, &$jobs, $taskProcessor) {
        $jobs++;
        if (State::FETCHED !== $task->getState()) {
            return;
        }

        try {
            $task->setState(State::UNDERWAYS);
            $engine->store($task);
            yield Worker\enqueueCallable([
                $taskProcessor,
                'process'
            ], $task);

        } catch (TaskFailureError | Exception $exception) {
            $task->setError($exception);
            $task->setState(State::HASERRORS);
        }
        $engine->store($task);
    }
));

<?php

namespace TaskBundle\Task;

use AppKernel;

class TaskProcessor
{
    /* @var array */
    private $env;

    public function __construct(array $env)
    {
        $this->env = $env;
    }

    /**
     * @param Task $task
     */
    public function process(Task $task): void
    {

        $kernel = new AppKernel($this->env['APP_ENV'], $this->env['APP_DEBUG']);
        $kernel->boot();
        $container = $kernel->getContainer();

        $taskService = $container->get($task->getServiceName());
        $taskService->execute($task);
    }
}

Please edit your post to highlight PHP code.

Drop TaskProcessor, implement your own Task class as I suggested above and use enqueue($task) instead of enqueueCallable.


Mark legacy API with OBJC_PUBLIC

Fixes linker errors on MINGW when using the legacy API (-fobjc-runtime=gnustep-1.7 or -fobjc-runtime=gcc)

[ Updating the branch to pick up fixes to the CI scripts. ]


fix: missing json bodies in patch and put requests

Fixes https://github.com/supabase/postgrest-py/issues/7 and #30
Why are we monkey patching postgrest-py here? If we really need to hide the async reality and offer a synchronous interface, can we move it down to the postgrest-py layer so at least it's tested and kept in sync?

Agreed on moving the requests/sync stuff to the postgrest-py lib.

Why are we monkey patching postgrest-py here?

It was supposed to be a temporary measure to provide an easy interface for the supabase users so we could get a release quickly out of the door, but agreed moving this to postgrest would be preferable.


Classref: Enum constants are no longer sorted by value

Operating system or device - Godot version:
Any system, current master branch.
Issue description (what happened, and what was expected):
Most likely since #5350, all elements are sorted alphabeticallyl in the classref. This is however not what we want for enum constants, which should stay sorted by value, as it's a lot more meaningful.
See e.g. http://docs.godotengine.org/en/latest/classes/class_inputevent.html or (a lot more problematic, as different enums get mixed together) http://docs.godotengine.org/en/latest/classes/class_@global scope.html
CC @vnen and @bojidar-bg.

Well, it depends. Not sure if you understand the way they're sorted. Citing my PR:

Constants are sorted by value if they have the same PREFIX_ otherwise alphabetically.

And Global Scope (which has tons of constants) seems much better organized in the current way (though even sor by value is arguable if you look at JOY_ constants, where there are lots with the same value). There are smaller examples too like Animation. At least for me it makes more sense to organize that, since you can find for type first and for value within the type.
For Input it is a problem because constants don't share a PREFIX_. So either hard code a way or another for some cases or pick a favorite.

Check the ERR_ in Global Scope, they're clearly not sorted by value. See also how the BUTTON_ and BUTTON_MASK_ get mixed. IMO the previous natural sorting was much more meaningful for constants.

I don't know that happened to ERR_ (another paranormal activity). For BUTTON_ it's more obvious since they share the prefix.
Natural sort may be better (the way they show in editor help) but the XML merge seems broken since it was randomly reordering the constants (#5337).

constants should be left in the same order that they came from

they are already organized manually when registered, so no sorting should happen

Then the XML merging must be fixed. I'll try to take a look soon.


Add auto-glint-nocheck script

Background
Today, the primary strategy folks tend to use when adopting Glint in an existing codebase is to set up either an include or exclude list under glint.transform in their tsconfig.json. While this does allow for incremental adoption, it has a few downsides:

it's not obvious to someone reading the code whether a given template is typechecked or not
it's easy for the list (especially include) to fall out of sync as the codebase evolves
opting out of transformation disables all Glint support for the files in question, including things like hover info and go-to-definition that can function in many cases even with type errors

The introduction of the @glint-nocheck directive made it possible to opt templates out of typechecking on an individual basis while still allowing Glint to analyze them, but adding these directives by hand is tedious and not something most groups have anecdotally bothered with.
This Change
This change adds a new executable to the @glint/scripts package: auto-glint-nocheck.
Similar in spirit to lint-to-the-future, this script launches the Glint language server in your project, locates any templates that have type errors in them, and adds a @glint-nocheck directive to them.
For multi-line templates, this directive goes on the first line and includes an explanatory comment (default: {{! @glint-nocheck: not typesafe yet }}), while in single-line embedded templates, it's simply inserted with no comment directly before the template content.
Notes
A few other related changes are landing as part of this:

switching off esModuleInterop for the whole codebase for easier consumption from true ESM packages (which there's a good chance we'll migrate to more completely someday)
pulling out an unpublished @glint/test-utils package to host our testing Project abstraction for scaffolding test projects to test Glint against
adding a basic explicitly-unstable programmatic interface to @glint/core (this is currently completely undocumented and may stay that way, but at a minimum it's now there)

I'm also provisionally adding @glint/scripts to the tests we run under Windows since, like @glint/core and the Code extension, it's directly interacting with the outside world and subject to OS quirks.
Closes #269.

...did Prettier break some of the build/build-watch snapshots? 🤨

It looks like 😬


feat: set swarm orange as primary color

code is fine, but about UX part I would like to hear @agazso's opinion too.

We already discussed this. The guideline is that only one element should have the brand orange color, so this PR will need to be reworked. It is super low priority though. 🙂