Changed sonatype url to https in build.gradle in TFLite pose estimation example for Android

Otherwise gradle sync fails in Android Studio Arctic Fox | 2020.3.1. Patch 4

I just signed the CLA. Please rescan the PR

Thanks for the pull request. We've updated all samples to use HTTPS in this commit so I'll close this one.


Porting custom functions

@ktf seems to compile just fine, though arrow 1.0 needs an extra dependency utf8proc (available in homebrew).

could you do a PR in alidist for it?


windowsPb: Move msvs2022 install into own block

[x] commit message has one of the standard prefixes
[ ] faq.md updated if appropriate
[ ] other documentation is changed or added (if applicable)
[ ] playbook changes run through VPC or QPC (if you have access)
[ ] VPC/QPC not applicable for this PR
[ ] for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

Ref https://github.com/adoptium/infrastructure/issues/3246#issue-1985631066
The vs2022_layout_ready does not get registered when the Transfer VS2022 Layout File task is skipped (due to msvs2022 already being installed). Then when ansible tries to evaluate when: (vs2022_layout_ready.stat.exists) in the Get SHA256 checksum of the file task it hits an error:
TASK [MSVS_2022 : Get SHA256 checksum of the file]

fatal: [build-azure-win2012r2-x64-4]: FAILED! => {"msg": "The conditional check '(vs2022_layout_ready.stat.exists ) and (windows_version.stdout_lines[0] | regex_search('^(10\\.|11\\.|2016|2019|2022)'))' failed. The error was: error while evaluating conditional ((vs2022_layout_ready.stat.exists ) and (windows_version.stdout_lines[0] | regex_search('^(10\\.|11\\.|2016|2019|2022)'))): 'dict object' has no attribute 'stat'\n\nThe error appears to be in '/tmp/awx_2108_g14r8155/project/ansible/playbooks/AdoptOpenJDK_Windows_Playbook/roles/MSVS_2022/tasks/main.yml': line 34, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Get SHA256 checksum of the file\n  ^ here\n"}

Moving the install code into its own block should fix this like it did with https://github.com/adoptium/infrastructure/pull/3244

Works as expected https://awx2.adoptopenjdk.net/#/jobs/playbook/2119?job_search=page_size:20;order_by:-finished;not__launch_type:sync


CORS Error When Loading OPNVKarte Basemap

When attempting to load the OPNVKarte basemap in JupyterGIS, a CORS (Cross-Origin Resource Sharing) error is encountered, preventing the tiles from being fetched and displayed.
Access to fetch at 'https://tileserver.memomaps.de/tilegen/4/11/7.png' from origin 'http://localhost:8888'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

GET https://tileserver.memomaps.de/tilegen/4/11/7.png net::ERR_FAILED 200 (OK)

Apologies in advance as I know that the project is WIP but one more reason to open this issue is that I'm facing the same problem in arjxn-py/jupytergis#1, see this commit in which i just did a hacky workaround but definitely not for production.

ProxyHandler defined in #104 should come in handy to fix this as well. But since it'd still not work with JupyterLite, would we want to also add a note or warning if we decide to use that upon agreement?

I guess that in the case of jupyterlite we can rely on cors-anywhere for now? We could think of making our own deployment of a cors-anywhere-like server

I guess that in the case of jupyterlite we can rely on cors-anywhere for now? We could think of making our own deployment of a cors-anywhere-like server

Oh yes, this sounds promising. I didn't actually thought about serving that ourselves but it's definitely can be explored and I would be up for it.

Closing as completed since this issue is no longer there


Does this validate response domain?

I dig trought your code and it looks like it doesnt validate domain from which the response are reaceaved(callbackUrl).
So in theory, anybody could make a request by themselves and accept/complete the payment, without even paying?

It doesn't validate domain name, but it validates SS1 and SS2 signatures. You can read more about them here: https://developers.paysera.com/en/payments/current#macro-callback-structure


Execute custom script before amplify push for all resources

Note: If your feature-request is regarding the AWS Amplify Console service, please log it in the
official AWS Amplify Console forum

Is your feature request related to a problem? Please describe.
The ability to run a custom script before amplify push for functions is very useful and empowering. It's frustrating that the same functionality is not supported for all resources.
There are many ways that this could add utility to people's projects, my particular use case is uploading an S3 file before deploying CloudFormation for a AWS Step Function custom resource. The CloudFormation for that resource allows the state machine definition to be read from S3 which would allow me to define the state machine in an external file and upload it to S3 before amplify push.
Describe the solution you'd like
The solution I'd like to see is having the support for function pre push script to be supported for all resources.
Describe alternatives you've considered
Every particular example where this would be useful will probably have many alternatives for getting this done, but it comes with it's own headaches. For me, either I work with an escaped json string in CloudFormation or I manually make sure that the S3 file is up to date before I push my changes
Additional context
Add any other context or screenshots about the feature request here.
How functions support this:
My package.json for a project that has 3 functions (catalog, user, and order handler):
{
  "name": "client-webapp",
  "version": "0.1.0",
  "private": true,
   ...
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "build:qa": "REACT_APP_STAGE=qa react-scripts build",
    "build:prod": "REACT_APP_STAGE=prod react-scripts build",
    "amplify:catalog": "cd amplify/backend/function/catalog/src && npm i && node_modules/.bin/tsc && cd -",
    "amplify:user": "cd amplify/backend/function/user/src && npm i && node_modules/.bin/tsc && cd -",
    "amplify:orderhandler": "cd amplify/backend/function/orderhandler/src && npm i && node_modules/.bin/tsc && cd -",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
...
}

This would be very useful 👍🏼

+1 Post push also will be useful, for example to create dynamodb global tables such are not supported by a CloudFormation
yet, in order to keep all processes automated.

Any progress on this?

@Leandros there is this https://docs.amplify.aws/cli/project/command-hooks/#adding-a-command-hook

Hey folks :wave: as @kylekirkby noted (thank you for that!) this feature has since been released with command hooks! Closing issue 🙂


The default-expand-all property of [Feature Request] table can be set dynamically, rather than traversing the assignment expand-row-keys to achieve full deployment.

Existing Component
是
Component Name
el-table
Description
table的default-expand-all属性可以动态设置，而不是通过遍历赋值expand-row-keys来实现全部展开。
The table's default-expand-all property can be set dynamically instead of traversing the expand-row-keys assignment to achieve full expansion. -- by Google Translate
https://jsfiddle.net/u0f3rxjp/

Sorry, we have no plan to support this feature.


clickhouse: add cookbook recipe on how to integrate postgresql with terraform

https://aiven.atlassian.net/browse/DOC-99

@dewan-ahmed , this is now ready for review. Please have a look - thank you

I'll review this on Monday.

https://github.com/aiven/devportal/pull/1591/commits/69f244fd5a4515df5d05040dc11479017f38e939 resolves the _toc.yml conflict.

Hi, here are the review suggestions:

Please use version = "~> 3.9.0" instead of version = ">= 3.7"
"This article shows by way of example..." phrase has been used already in the two other ClickHouse recipes. To avoid monotonous reading, please rephrase this sentence.
I missed to note in the previous two ClickHouse recipes but all of our cookbook recipes include Mermaid diagrams. Kindly include Mermaid diagrams for this recipe and you can create separate PRs to add diagrams to the other ClickHouse recipes.
I believe google-us-east4 is the correct region name.
The Terraform code didn't show syntax highlighting. Kindly check.
Please create a card on the cookbook.rst landing page for this recipe.
The resultant database doesn't show any tables. For a validity of the story, it would be nice if there was a source table that shows up on the destination database using the integration.

@dewan-ahmed , thank you for the feedback :-) Addressed all your comments except the syntax highlighting - I'm not able to find what's wrong. Could you please help me identify the missing bit? All seems fine when I check.

Thanks @wojcik-dorota. I'm looking into why the syntax highlighting is not working. Tomorrow I'll propose a revised version of the Mermaid diagram.

Hi @wojcik-dorota @aris-aiven I'm proposing a new Mermaid diagram.

The new diagram is much simpler, shows only one Aiven for ClickHouse block instead of two and points to the new database for the service integration.
If this looks OK, please use or you can keep the previous diagram - your call. One thing I'll point out is that I see the usage of table and database on this recipe whereas all three entities show up as databases on the Aiven console - sensor_dims, iot_measurements, and service_postgres-gcp-us_sensor_dims_public. If all of these are databases, please update accordingly (for example, line#9).

Thank you, @dewan-ahmed :-) will follow up accordingly!

Thank you, @dewan-ahmed :-) will follow up accordingly!

All good from my end @wojcik-dorota - thanks a lot for your patience with the review process.
A suggestion to rebase this branch (we're suggesting this for all open PRs) since https://github.com/aiven/devportal/pull/1620 just went in and we can fix any warning/error produced as a result. I can merge the PR right after.

Great! Thank you @wojcik-dorota & @aris-aiven


LavaSrc Spotify issue

Hello. I have an issue with the Spotify source by the LavaSrc package. It always says:
[ ERROR ] Error: Lavalink Node SearchQuerySource: 'spotify' is not available

when I try to play / search a song on Spotify. I already contacted the maintainer of the LavaSrc plugin and he told me that LavaSrc is set up correctly and should work fine so he told me to ask here. Does anymbody know a possible solution?

use spsearch

use spsearch

can you send me a link to it please?

manager.search({
   query: "Hello by Adele",
   source: "spsearch"
})

Also you might wna check out my own client which is maintained, efficient, feature rich and op:

lavalink-client

This repository isn't maintained anymore


feat: Update main with changes that have been in testing

Now that @EyeCantCU 's kernel signing is working, this PR will ship all the enhancements we've made in the testing branch.
Note that this will require everyone using Secure Boot to have added the akmods mokutil key -- most should have already due to degraded functionality without it.

So, this means, if you use SecureBoot and don't have the ublue MOK, the kernel won't boot at all?

So, this means, if you use SecureBoot and don't have the ublue MOK, the kernel won't boot at all?
Or, will the ublue signature be added to the pre-existing signature, so the user would have an experience similar to current without the ublue MOK, only our kmods would fail to load?

We use the same key pair here as what's used in akmods. If people had the key enrolled before, it will continue to function as it was. If not, they already would have had to have had secure boot disabled. It shouldn't impact anyone

Unfortunate requirement of using the fsync kernel since it's not signed by fedora. That being said we'll update our documentation and further telegraph this change.

Certainly good you can sign the kernel and make this possible at all! Probably just good to have well documented. I tend to think a potential total failure to boot is a bit harsher than "degraded experience". :-)

Certainly good you can sign the kernel and make this possible at all! Probably just good to have well documented. I tend to think a potential total failure to boot is a bit harsher than "degraded experience". :-)

Yeah, at the very least we know anyone using features like displaylink or utilizing a Nvidia graphics card has already enrolled that key.
I think what I will do is put an additional week buffer on this (this change was mentioned in the last release at the top), and add a message to the terminal during that time warning people about it.
If this bites anyone after that at least it's as easy as turning off secure boot for them.

I should also mention that they will still have their previous deployment as well, so they're not completely dead. Ideally they would boot into the previous deployment that then has that warning in the terminal.

I should also mention that they will still have their previous deployment as well, so they're not completely dead. Ideally they would boot into the previous deployment that then has that warning in the terminal.

Awesome point and also great to document!
atomic systems saving the day again!

New installs need to have the key. Maybe kickstart should also have the enroll key like nvidia.
Already without the key display link was broken and you would have an error showing.
Maybe for the next week-month have a service that checks if key was enrolled with mokutil --list-enrolled. If not stage enrolled key. UX for that might be hard on a deck though.

New installs need to have the key. Maybe kickstart should also have the enroll key like nvidia.
Already without the key display link was broken and you would have an error showing.
Maybe for the next week-month have a service that checks if key was enrolled with mokutil --list-enrolled. If not stage enrolled key. UX for that might be hard on a deck though.
if ! $(mokutil --list-enrolled | grep -qv "Universal Blue"); then
        echo "Key not Enrolled"
        mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
        exit 0
fi
echo "Key already Enrolled"

Though you probably need to do something to pass something to mokutil for the password on import.

Good news is the deck doesn't ship secure boot enabled at all, so no need to worry about UX there.


Ensure correct work UUID

The problem discussion started at https://github.com/ydb-platform/ydb/issues/9799
Summary:
The SDK was send and receive UUID with bug: sdk byte order has differences to the server byte orders. It was not detected by unit tests and read-write tests (the SDK read same UUID, which was written).
Nobody saw the problem a lot of time, because UUID can't be stored on the server until last version. Now if the sdk send UUID to the server it and read it with YQL (cast to string) or other SDK (for example python) - readed UUID has differences from written.
Fix way in SDK:

Create dedicated minor migration version: 3.86.x, where old code work as is. In the version I add additional functions - for explicit read/write UUID with old behavior and for read/write with correct format. At the point need to explicit select way for every read/write UUID (old with bug or new).
Next dedicated minor version (3.87.x-3.88.x) break compatibility of old code as soon as possible: write code will be break at compile time and scan values code will be failed at runtime. All old code for work with UUID will be broken.

Migration for customers:
If you didn't use UUID before migration version: use good way functions. No need to do anything.
If you used the UUID and your code broken to compile or you have runtime error "ydb: uuid storage format was broken in go SDK..." you have to do change your code.

Change work with uuid with explicit old behavior (functions and type wrappers with ...Issue1501). See tests in migration version (add link).
Migrate your data and replace usage old-style work for new-style. For prevent mistakes and confusions when needs work with the data in other was than go sdk.

Migration example:
v3.86 - old-style code work with bug, no new code in sdk
Old code
		// test old behavior - for test way of safe work with data, written with bagged API version
		var (
			scope = newScope(t)
			ctx   = scope.Ctx
			db    = scope.Driver()
		)

		idString := "6E73B41C-4EDE-4D08-9CFB-B7462D9E498B"
		id := uuid.MustParse(idString)

		var idFromDB uuid.UUID
		err := db.Table().DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
			res, err := tx.Execute(ctx, `
DECLARE $val AS UUID;

SELECT $val
`, table.NewQueryParameters(table.ValueParam("$val", types.UUIDValue(id))))
			if err != nil {
				return err
			}
			res.NextResultSet(ctx)
			res.NextRow()

			var resBytes [16]byte
			err = res.Scan(&resBytes)
			if err != nil {
				return err
			}
			idFromDB = resBytes
			return nil
		})
		require.NoError(t, err)
		require.Equal(t, id, idFromDB)

upgrade ydb sdk to v3.87, old code still work
Same code
		// test old behavior - for test way of safe work with data, written with bagged API version
		var (
			scope = newScope(t)
			ctx   = scope.Ctx
			db    = scope.Driver()
		)

		idString := "6E73B41C-4EDE-4D08-9CFB-B7462D9E498B"
		id := uuid.MustParse(idString)

		var idFromDB uuid.UUID
		err := db.Table().DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
			res, err := tx.Execute(ctx, `
DECLARE $val AS UUID;

SELECT $val
`, table.NewQueryParameters(table.ValueParam("$val", types.UUIDValue(id))))
			if err != nil {
				return err
			}
			res.NextResultSet(ctx)
			res.NextRow()

			var resBytes [16]byte
			err = res.Scan(&resBytes)
			if err != nil {
				return err
			}
			idFromDB = resBytes
			return nil
		})
		require.NoError(t, err)
		require.Equal(t, id, idFromDB)

v3.87 upgrade code, without upgrade the sdk
Change function types.UUID to types.UUIDWithIssue1501Value for send value and use type types.UUIDBytesWithIssue1501Type for scan uuid value with old style.
After the changes code continue to work without change behavior
Update code to explicit work in old style
		// test old behavior - for test way of safe work with data, written with bagged API version
		var (
			scope = newScope(t)
			ctx   = scope.Ctx
			db    = scope.Driver()
		)

		idString := "6E73B41C-4EDE-4D08-9CFB-B7462D9E498B"
		id := uuid.MustParse(idString)

		var idFromDB uuid.UUID
		err := db.Table().DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
			res, err := tx.Execute(ctx, `
DECLARE $val AS UUID;

SELECT $val
`, table.NewQueryParameters(table.ValueParam("$val", types.UUIDWithIssue1501Value(id))))
			if err != nil {
				return err
			}
			res.NextResultSet(ctx)
			res.NextRow()

			var resBytes [16]byte
			var resWrapper types.UUIDBytesWithIssue1501Type
			err = res.Scan(&resWrapper)
			if err != nil {
				return err
			}
			resBytes = resWrapper.AsBytesArray()

			idFromDB = resBytes
			return nil
		})
		require.NoError(t, err)
		require.Equal(t, id, idFromDB)

Update SDK
Then you can upgrade the SDK without change the behavior and you have a time for data migration.
Data migration
Is is very dependency from project, purposre - rewrite uuid, stores in old style with bug to good uuid format. Which will be consistency with other SDKs and server YQL.
Change the code for work in new style - will work from v3.87 and later
During migration data for load/store good UUIDs and after migration use new-style code
New style code

		var (
			scope = newScope(t)
			ctx   = scope.Ctx
			db    = scope.Driver()
		)

		idString := "6E73B41C-4EDE-4D08-9CFB-B7462D9E498B"
		id := uuid.MustParse(idString)
		var resID uuid.UUID
		err := db.Table().DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
			res, err := tx.Execute(ctx, `
DECLARE $val AS UUID;

SELECT $val
`, table.NewQueryParameters(table.ValueParam("$val", types.UuidValue(id))))

			res.NextResultSet(ctx)
			res.NextRow()
			err = res.ScanWithDefaults(&resID)
			if err != nil {
				return err
			}
			return nil
		})
		require.NoError(t, err)

		require.NoError(t, err)
		require.Equal(t, strings.ToUpper(idString), strings.ToUpper(resID.String()))

it would be a good way to provide a set of examples illustrating the problem and the practice of correction.
step by step, specifying specific versions for migration.

@hurd54 done

What if data migration takes months, are we gonna be blocked to upgrade to newer version of sdk?
How sugar features like struct from result set binding are going to distinguish broken uuid from unboken ones?

Is is ok - you can use custom type as long as you need with special types similar to types.UUIDWithIssue1501Value(id)
What is go-native - database/sql?

Can you write small example of your code for check your case?

Is is ok - you can use custom type as long as you need with special types similar to types.UUIDWithIssue1501Value(id)

for example right now I have helper like this to map uuid into struct fields
type ScanUUID = *[16]byte

// And I can use it like this.
named.Required("event_id", ydbutil.ScanUUID(&r.EventID))

After upgrading I will have to rewrite all places with
var resWrapper types.UUIDBytesWithIssue1501Type
err = named.Required("event_id", &resWrapper)

r.EventID = resWrapper.AsBytesArray()

The closes example would be your sugar.UnmarshallRow (https://github.com/ydb-platform/ydb-go-sdk/blob/master/sugar/query.go#L17C6-L17C19)
If my struct use uuid.UUID field it won't be able to scan it as 'old uuid'

The closes example would be your sugar.UnmarshallRow (https://github.com/ydb-platform/ydb-go-sdk/blob/master/sugar/query.go#L17C6-L17C19)
If my struct use uuid.UUID field it won't be able to scan it as 'old uuid'

Do you use native sdk or database sql code?
Custom types in with native code can implement Scanner interface for override unmarshal behavior.
Example for uuid case:
https://github.com/ydb-platform/ydb-go-sdk/blob/9f8e82eeb817aea4b14eb920dfa81e59bbc312d7/tests/integration/table_regression_test.go#L493-L517
I didn't tested the behavior of custom type with database/sql, I can do it and  guide for code fix code with minimal work.

If my struct use uuid.UUID field it won't be able to scan it as 'old uuid'.

if your code use uuid.UUID with database/sql - it should be break after upgrade https://github.com/ydb-platform/ydb-go-sdk/issues/1515
for native sdk uuid.UUID can scan as 'new style' uuid only, but old versions of the native SDK can't scan uuid.UUID at all.

for native sdk uuid.UUID can scan as 'new style' uuid only, but old versions of the native SDK can't scan uuid.UUID at all

they can, as bytes array. So code is clean, you scan your struct field by field with no boilerplate code.
something like this
upload := MultipartUpload{}
	var storageClass int8
	err := res.ScanNamed(
		named.Required("a", &upload.A),
		named.Required("b", ydbutil.ScanUUID(&upload.B)),
		named.Required("c", &upload.C),
		named.Required("d", &upload.D),
	)

you don't need any helper variables to move fields from one representations to another one

Custom types in with native code can implement Scanner interface for override unmarshal behavior

we use native sdk. Unfortunately it doesn't seem to allow any custom unmarshallers

What about implement custom unmarshaler for ydbutil.ScanUUID type?
I can research it in details at start of next week.


"Extraneous module ignored with nested atomic" on require

After upgrading to 1.1.3 I'm getting the following output every time I require the gem in ruby 2.3.1. As far as I can tell it's a treetop related issue:
rb(main):001:0> require "dns/zonefile"
Extraneous module ignored with nested atomic: "(\n     host space ms_age ttl klass \"CNAME\" space target:host /\n     host space klass ms_age ttl \"CNAME\" space target:host /\n     host space ms_age ttl \"CNAME\" space target:host /\n     host space klass \"CNAME\" space target:host \n    ) {\n      def to_s\n        \"\#{host} \#{ttl} \#{klass} CNAME \#{target}\"\n      end\n\n      def record_type\n        \"CNAME\"\n      end\n    }"
Extraneous module ignored with nested atomic: "(\n     host space ms_age ttl klass \"SRV\" space priority:integer space weight:integer space port:integer space target:host /\n     host space klass ms_age ttl \"SRV\" space priority:integer space weight:integer space port:integer space target:host /\n     host space ms_age ttl \"SRV\" space priority:integer space weight:integer space port:integer space target:host /\n     host space klass \"SRV\" space priority:integer space weight:integer space port:integer space target:host\n    ) {\n      def to_s\n        \"\#{host} \#{ttl} \#{klass} SRV \#{priority} \#{weight} \#{port} \#{target}\"\n      end\n\n      def record_type\n        \"SRV\"\n      end\n    }"
Extraneous module ignored with nested atomic: "((\"IN\" space) / '') {\n      def to_s\n        text_value.strip\n      end\n    }"
Extraneous module ignored with nested atomic: "( \"[AGE:\" [\\d]+ \"]\" space / '' ) {\n      def to_s\n        text_value\n      end\n    }"
Extraneous module ignored with nested atomic: "((time_interval space) / '') {\n      def to_i\n        respond_to?(:time_interval) ? time_interval.to_i : nil\n      end\n      def to_s\n        respond_to?(:time_interval) ? time_interval.to_s : ''\n      end\n    }"
Extraneous module ignored with nested atomic: "(\n      \"(\" space* data:txt_data space* \")\" /\n      data:txt_data\n    ) {\n      def to_s\n        data.to_s\n      end\n    }"
Extraneous module ignored with nested atomic: "( '\"' ( '\\\"' / [^\"] )* '\"') {\n      def to_s\n        text_value\n      end\n    }"

This should be fixed as off Treetop 1.6.6. See thread here: https://github.com/cjheath/treetop/pull/29

Confirmed fix.

@craigw you can close this one now as updating to the latest treetop version closes this issue.

Thank you 👍 ⭐


IPHONEOS_DEPLOYMENT_TARGET issue

Here is my config: https://www.dropbox.com/s/o10vsr2r5kcke5o/project.yml?dl=0
I included IPHONEOS_DEPLOYMENT_TARGET setting into CommonSettings:
IPHONEOS_DEPLOYMENT_TARGET: '8.0'

then I include them into each configuration on project level:
configurations:

    *cfgDebug:
        type: debug
        profiles:
        - general:debug
        - ios:debug
        overrides:
            *CommonSettings

    #---

    *cfgRelease:
        type: release
        profiles:
        - general:release
        - ios:release
        overrides:
            *CommonSettings

but when I'm trying to generate the project, I'm getting strange error as follows:
[Xcodeproj] Consistency issue: build setting IPHONEOS_DEPLOYMENT_TARGEThas multiple values:{"Debug"=>"10.2", "Release"=>"8.0"}`
Any ideas why?

'IPHONEOS_DEPLOYMENT_TARGET' produces really strange issues.

Errors happen even when I remove this setting from CommonSettigns and put on framework target level explicitly for each configuration.

but it works well as soon as I comment/remove these properties at all.

Hi @maximkhatskevich, this is most likely due to your targets including profiles which set a default deployment target of 10.2. If you need a specific deployment target, make sure to override it on all of your configurations at a project and a target level.

Adding this property into each of the blocks with overrides  (under each Build Configuration on project level, framework target level and unit tests target level) really helped to solve the issue. Thank you!

Good to hear! 🚀


Update trait-qualification-reference.md

Added a line to Onboarded Traits section to highlight that there is a 4-hour wait time after creating a trait before sending an inbound file.

I merged the PR. Thanks, @jeftaylor79 !


youtube-dl fails to use proxy

$ http_proxy="<IP_ADDRESS>:3128" youtube-dl http://www.youtube.com/watch?v=z4KV7e8kwbI
[youtube] Setting language
WARNING: unable to set language: <urlopen error [Errno 111] Connection refused>
[youtube] z4KV7e8kwbI: Downloading video webpage
ERROR: unable to download video webpage: <urlopen error [Errno 111] Connection refused>
--> of course it doesn't work if you don't use the proxy server ...

Seems like this could be a bug in urllib or urllib2. Have you tried a simple script to test your proxy?
#!/usr/bin/python
import urllib2
import sys
url = sys.argv[1]
response = urllib2.urlopen(url)
html_string = response.read()
print html_string

As per the documentation, try to put the "http://" prefix before the host name.
http://rg3.github.com/youtube-dl/documentation.html#d5

Mmm, urllib2 seems ok with leaving out the http://. On which platform (Python version, Linux distribution) are you running youtube-dl? Can you update youtube-dl to 2012-02-26 and test with the new --verbose option? What does that output?

I just peeked at the code in urllib2 and you're completely right. It should go even as far back as Python 2.5. However, I distinctly remember having problems if I omitted the http:// prefix when I tested the feature after adding it. Could it be a subtle problem in youtube-dl's code? It could still be interesting to test with the prefix just in case.


Laravel 11 compatibility

Hi!
There are some compatibility issues revolving around illuminate/support when trying to install the package in a Laravel 11 app.
I've noticed that you modified the composer requirements to address that.
Could you please push these changes out in a release?
Thanks.

@rennokki it would be nice if you could release a new version, thanks

@leo108 please take over in a fork, so we are decoupled from this repo.


After connect, nothing show, no files, no folder

Do you read the FAQ?

[ x] Yes.
[ ] I am going to read now.

sorry was a configuration on my server not the sftp extension, closed


Actually Additions rice on terran soil drops cheese

General Information
Describe the bug:
Act. Additions rice from terran soil drops cheese, for some reason
To Reproduce:

Place terran soil, grow rice on it
Right-click harvest(with Quark)

Expected behavior:
As well as normal drops, you will get cheese

Environment Versions
Roots 3.0.9; Actually Additions r149
Mystic Mods Versions

MysticalLib: 1.3.4
Mystic World: 1.4.3

Other Versions:

Conflicting mod (if regarding mod integration):
Other mods you think could cause issues:
Forge: <IP_ADDRESS>47
Minecraft: 1.12.2
Modpack (if available):

Logging Information
Please Use gist, paste.ee, pastebin or some other log sharing service
Pretty sure that's not needed in this case, right?
Crash Report (if available):

Latest Log (if necessary):

Additional Information
Screenshots (if available):

Additional context (optional):

That version of Roots is horrendously out of date. The most recent version is 3.0.20, which fixes this issue. Thanks for reporting it though! If you're playing in a pack, I'd recommend either manually updating Roots (if the pack isn't being updated), see if there is a pack update, or pester the pack author to update.

Oh sorry for disturbing then

No, it's fine, thank you so much for taking the time to report the issue!


Codeunit 90 modify event on procedure PostItemCharge

Hi,
We need a modify event on Codeunit 90 procedure  PostItemCharge :
...
  PostItemJnlLine(
              PurchHeader, PurchLineToPost, 0, 0, QuantityBase, QuantityBase,
              PurchLineToPost."Appl.-to Item Entry", "Item Charge No.", DummyTrackingSpecification);

             // > Modify event
            OnPostItemChargeOnAfterPostItemJnlLine((PurchHeader, PurchLineToPost,TempItemChargeAssgntPurch);
            // >Modify event
        end;
    end;

....
  [IntegrationEvent(false, false)]
    local procedure OnPostItemChargeOnAfterPostItemJnlLine((PurchaseHeader: Record "Purchase Header"; PurchaseLine: Record "Purchase Line",TempItemChargeAssgntPurch: Record "Item Charge Assignment (Purch)")
    begin
    end;

...

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


feat(fuzzy): add a proper fuzzy search algorithm

Hi, it's me again :)
fuzzy_finder is actually not fuzzy searching.
Although we have a fuzzy_finder command, mapped to / in filesystem source by default, my understanding of fuzzy is not what is currently implemented.
Suppose we want to match the path lua/neo-tree/sources/filesystem/commands.lua, the current behavior basically does a regex search with spaces substituted with .*, which does not match:

commands filesystem

when the order is reversed

flsys cmds

when the names are abbreviated

In my opinion (and due to the popularity of telescope.nvim), I think most of neovim users think that the term fuzzy corresponds to the algorithm used in programs such as fzf, fzy which successfully matches the examples above.
Feature Request
TLDR; workaround this
The code already tries to use the fzf command line tool here but it fails to run since fzf requires an interactive shell to work properly, as mentioned in this issue.
One solution would be to launch fzf inside an interactive shell but that would be a massive overhead for each fuzzy search (per keypress!).
Therefore, I implemented the fzy algorithm with lua (mainly in this file: BIG CREDITS TO fzy-lua) which can be used to filter and sort the files based on the search query.
Behavior
https://user-images.githubusercontent.com/41065736/215294405-4a6e6742-ebee-492c-b017-c39a26cfc82a.mp4

NOTE:  - 0.00pts after the filenames is the score of each path and is ONLY shown for demonstration for this PR. This PR does not contain the code to show the points. In order to mimic the video, please add the following code.

Modified lua/neo-tree/ui/renderer.lua
@@ -228,6 +228,11 @@ create_nodes = function(source_items, state, level)
     }
     local indent = (state.renderers[item.type] or {}).indent_size or 4

+    -- TODO: Only for debug. Remove
+    if state.fuzzy_finder_mode ~= nil then
+      nodeData.name = string.format([[%s - %spts]], nodeData.name, state.fzy_sort_result_scores[nodeData.path])
+    end
+
     local node_children = nil
     if item.children ~= nil then
       node_children = create_nodes(item.children, state, level + 1)

Discussions

I have taken the fzy algorithm code mostly from fzy-lua. Their license is MIT and I have added credit on top of the file filter_fzy.lua. Is this ok for you @cseickel?
I did not expose any commands to use this feature yet. It is now specified through state.find_command == "fzy-lua". I would like to ask your opinion on the command name and whether this should be the default behavior of fuzzy_finder.
TODO: docs and readme. Therefore, this PR is draft.

Usage
I would be more than happy if someone could test my implementation. (Especially on Windows. I can only test on Linux...)
If you are using lazy.nvim,
return {
  "pysan3/neo-tree.nvim.git",
  branch = "feat-fzy-finder", -- BRANCH NAME
  dependencies = {
    { "MunifTanjim/nui.nvim" },
    { "kyazdani42/nvim-web-devicons" },
  },
  cmd = { "Neotree" },
  config = {
    filesystem = {
      window = {
        mappings = {
          ["/"] = "modified_filter", -- add a keybind
        },
      },
      commands = {
        modified_filter = function(state)
          local filter = require("neo-tree.sources.filesystem.lib.filter")
          state.find_command = "fzy-lua" -- specify the algorithm here
          filter.show_filter(state, true, true) -- same as command "fuzzy_finder"
        end,
      },
    },
  }
}

I am looking forward to any feedbacks ;)
pysan3

Oh I didn't notice the state of the plugin.
I would love to help but I unfortunately haven't got the time at least this year. I'd be more than happy to take the role from next year (if that is an option).
Back to this PR, could you @cseickel tell me how feature requests are considered for now?
I think it would be nice to make this PR the first example dealt by people commented over at the discussion?
I can't wait to see this plugin evolve even more towards the future and I'd love to hear you opinion.
Best,

Oh I didn't notice the state of the plugin.

The one thing I am most reserving my available time for is PR review. That's really the priority for me. Even if we get a volunteer to be the new lead, it would take time for me to become comfortable that they will manage the project the way I'd want it to be managed, so I will keep the ship on course for now.

Back to this PR, could you @cseickel tell me how feature requests are considered for now?

For now, I will continue as before.
My comments on this PR:
I definitely would love a better fuzzy search, and I especially like the fzy algorithm. The problem we have to overcome is performance. Recursively scanning the filesystem with plenary is just too slow for any reasonably large folder, so you would need a different source to feed into the fzy scoring system.
Of course, I did try it out and it works remarkably well in a smaller directory. I just worry about how it will scale. I would suggest that the first stage come from the existing fd/find route but with a search pattern that will return more results. It can even go so far as to just search for a regex that would "must contain at least one of each of the non-space characters typed into the box." As a test input, I would use some larger mono-repo. I always go with the linux repo for stress testing this sort of thing.
With regards to licensing, I think it must be best to include the fzy project as a dependency rather than copying the file wholesale. If you did copy the file, I would copy the contents of  the entire license file to the top of the file you are copying as a block comment.
As far as the command, something this significant will definitely have a period of bugs to shake out, and should therefore be opt-in. Maybe it becomes the default in 3.0. I would either make it a separate command, or add a config option to the existing mapping to enable the fzy matching method.

I would suggest that the first stage come from the existing fd/find route but with a search pattern that will return more results

I cant imagine that reaching out over shell to either find or fd would be faster than using the in built c binding to luv. I think the biggest hurdle is just going to be generically "Big filesystems suck".  But I still don't think it will perform better for simple tree walking than staying in lua/c and avoiding stream processing.

Welp, I threw together a test (you will need plenary, as well as my spawn wrapper if you want to run it yourself). I have it scanning my usr directory which apparently contains about 620k items (not huge, but large enough that the tests don't finish immediately)
Code
local shell = require("netman.tools.shell")
local luv = require("luv")
local plenary = require("plenary.scandir")
local start_dir = '/usr/'

local paths = { {path=start_dir} }

local count = 0
-- I don't know if defining these outside the
-- while loop actually helps performance, but it shouldn't
-- whereas its possible that continually redefining
-- these in the loop might get memory painful overtime
local head = nil
local head_path = nil
local head_type = nil
local head_stat = nil
local head_fd = nil
local child_info = nil
local test1 = function()
    local duration = luv.hrtime()
    while #paths > 0 do
        count = count + 1
        -- Pops the head off the paths table. At start, this causes the table to be empty
        head = table.remove(paths, 1)
        head_path = head.path
        if not head.type then
            head_stat = luv.fs_stat(head_path)
            if(head_stat) then
                head_type = head_stat.type
            else
                -- Some how we didn't get any stat results for head. Head probably doesn't exist.
                goto continue
            end
        else
            head_type = head.type
        end
        if head_type ~= 'directory' then
            -- Don't need to walk head_type, still should store its info though?
            goto continue
        end
        head_fd = luv.fs_scandir(head_path)
        if(head_fd) then
            while true do
        --         -- Iterate through each item returned by luv.fs_scandir_next until there is nothing left to iterate over
        --         -- add each item to the paths if its a directory only
                child_info = {luv.fs_scandir_next(head_fd)}
                if not child_info or #child_info == 0 then
                    break
                end
                count = count + 1
                if child_info[2] == 'directory' then
                    table.insert(paths, {path=string.format("%s/%s", head_path, child_info[1]), type='directory'})
                end
            end
        end
        ::continue::
    end
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test2 = function()
    local duration = luv.hrtime()
    plenary.scan_dir_async(start_dir, {
        hidden = true
    })
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test3 = function()
    local duration = luv.hrtime()
    shell:new({"/usr/bin/find", "/opt/"})
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test4 = function()
    local duration = luv.hrtime()
    shell:new({"/usr/bin/fd", ".", "/opt/"})
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

print(string.format("Scanning %s", start_dir))
print("Doing Sync Libuv test")
local test1_time = test1()
print("Doing Async Plenary Test")
local test2_time = test2()
print("Doing Spawn Test with find")
local test3_time = test3()
print("Doing Spawn Test with fd")
local test4_time = test4()
print(string.format("    Test 1 (libuv sync scan) took approximately %s ms to scan %s items", test1_time, count))
print(string.format("    Test 2 (plenary async scan) took approximately %s ms to scan %s items", test2_time, count))
print(string.format("    Test 3 (spawn find scan) took approximately %s ms to scan %s items", test3_time, count))
print(string.format("    Test 4 (spawn fd scan) took approximately %s ms to scan %s items", test4_time, count))

Results
Scanning /usr/
Doing Sync Libuv test
Doing Async Plenary Test
Doing Spawn Test with find
Doing Spawn Test with fd
    Test 1 (libuv sync scan) took approximately 528.469989 ms to scan 619357 items
    Test 2 (plenary async scan) took approximately 0.158897 ms to scan 619357 items
    Test 3 (spawn find scan) took approximately 0.06071 ms to scan 619357 items
    Test 4 (spawn fd scan) took approximately 0.004345 ms to scan 619357 items

So I was incorrect. Running with find and fd (even through a shell) is faster. Substantially when comparing fd to plenary's async.

Thanks for running those benchmarks @miversen33, it's definitely good to know those results.

I think preferring a cli tool (such as find or fd) is fine, though we need to also consider windows (which does not have native find). Either including a way to reach into a windows tool that is "comparable" to cli (I don't know windows well enough to know what this is) or simply fall back to plenary if find/fd is not present on the host system.

Windows does have some utilities, and the default external filter code will actually find the best available even on Windows and use it. I think that on windows, the cost of the plenary scan is significantly worse than on linux or mac, so it's even more important to use the find or where utility on Windows.

Those results didn't make sense to me. It turns out I forgot to run the shell command in the tests (notice the shell:new but no :run after :upside_down_face: )
So my results above are garbage.
To sanity check this, I removed my spawn wrapper and used the job functions provided by plenary.
Below are the actual results (along with updated code)
local luv = require("luv")
local plenary = require("plenary.scandir")
local job = require("plenary.job")
local start_dir = '/usr/'

local paths = { {path=start_dir} }

local count = 0
-- I don't know if defining these outside the
-- while loop actually helps performance, but it shouldn't
-- whereas its possible that continually redefining
-- these in the loop might get memory painful overtime
local head = nil
local head_path = nil
local head_type = nil
local head_stat = nil
local head_fd = nil
local child_info = nil
local test1 = function()
    local duration = luv.hrtime()
    while #paths > 0 do
        count = count + 1
        -- Pops the head off the paths table. At start, this causes the table to be empty
        head = table.remove(paths, 1)
        head_path = head.path
        if not head.type then
            head_stat = luv.fs_stat(head_path)
            if(head_stat) then
                head_type = head_stat.type
            else
                -- Some how we didn't get any stat results for head. Head probably doesn't exist.
                goto continue
            end
        else
            head_type = head.type
        end
        if head_type ~= 'directory' then
            -- Don't need to walk head_type, still should store its info though?
            goto continue
        end
        head_fd = luv.fs_scandir(head_path)
        if(head_fd) then
            while true do
        --         -- Iterate through each item returned by luv.fs_scandir_next until there is nothing left to iterate over
        --         -- add each item to the paths if its a directory only
                child_info = {luv.fs_scandir_next(head_fd)}
                if not child_info or #child_info == 0 then
                    break
                end
                count = count + 1
                if child_info[2] == 'directory' then
                    table.insert(paths, {path=string.format("%s/%s", head_path, child_info[1]), type='directory'})
                end
            end
        end
        ::continue::
    end
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test2 = function()
    local duration = luv.hrtime()
    plenary.scan_dir_async(start_dir, {
        hidden = true
    })
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test3 = function()
    local duration = luv.hrtime()
    job:new({
        command = "/usr/bin/find",
        args = {"/opt"}
    }):sync()
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

local test4 = function()
    local duration = luv.hrtime()
    job:new({
        command = "/usr/bin/fd",
        args = {".", "/opt/"}
    }):sync()
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

print(string.format("Scanning %s", start_dir))
print("Doing Sync Libuv test")
local test1_time = test1()
print("Doing Async Plenary Test")
local test2_time = test2()
print("Doing Spawn Test with find")
local test3_time = test3()
print("Doing Spawn Test with fd")
local test4_time = test4()
print(string.format("    Test 1 (libuv sync scan) took approximately %s ms to scan %s items", test1_time, count))
print(string.format("    Test 2 (plenary async scan) took approximately %s ms to scan %s items", test2_time, count))
print(string.format("    Test 3 (plenary find scan) took approximately %s ms to scan %s items", test3_time, count))
print(string.format("    Test 4 (plenary fd scan) took approximately %s ms to scan %s items", test4_time, count))

Scanning /usr/
Doing Sync Libuv test
Doing Async Plenary Test
Doing Spawn Test with find
Doing Spawn Test with fd
    Test 1 (libuv sync scan) took approximately 580.085922 ms to scan 619357 items
    Test 2 (plenary async scan) took approximately 0.012304 ms to scan 619357 items
    Test 3 (plenary find scan) took approximately 118.025346 ms to scan 619357 items
    Test 4 (plenary fd scan) took approximately 96.017473 ms to scan 619357 items

The long short, my initial gut reaction was correct, shelling out is far more expensive than simply using plenary's async scan. I just don't know how to read my own code I guess lol, and apparently needed to lay in bed for a while before realizing the error in my test.
Tagging @cseickel

Test 1 (libuv sync scan) took approximately 580.085922 ms to scan 619357 items
Test 2 (plenary async scan) took approximately 0.012304 ms to scan 619357 items
Test 3 (plenary find scan) took approximately 118.025346 ms to scan 619357 items
Test 4 (plenary fd scan) took approximately 96.017473 ms to scan 619357 items

I think you made another mistake there. If you thik about it, async should always take a little longer than sync because of the extra overhead. Parallel is faster than either, but I don't think Plenary's async is parallel. Either way there is no way that it would be so much faster.
I think what you are timing here is the time it takes to declare and start the async scan. There is no callback to report the time after the async code actually completes.
local test2 = function()
    local duration = luv.hrtime()
    plenary.scan_dir_async(start_dir, {
        hidden = true
    })
    -- The scan has not actually run yet...
    duration = (luv.hrtime() - duration) / 1000000
    return duration
end

As an aside, our async scan is actually parallel in that it fires off an async scan for each sub-folder in the path we are scanning. It is more efficient than plenary in general but till nowhere near fd speeds.
One last point, is that the fd is used to search, not just list all of the files. It should be returning a filtered list as the results of some search term. It also is able to do so while omitting gitignored items if that's what your settings specify, which is an incredibly expensive operation that plenary is incapable of doing correctly.

Thank you for the explanation and taking your time to review this PR.

The problem we have to overcome is performance. Recursively scanning the filesystem with plenary is just too slow for any reasonably large folder,

I am also aware of this problem, and I do see issues over on plenary side about the lack of speed.
However, my take is that exposing a real fuzzy finder at least as an option would be better than having none.
And since the size of the repo, as well as the PC spec varies from user to user, I think we can hand it to the user to decide which algorithm should be used with a big caution in the documentation.

With regards to licensing, I think it would be best to include the fzy project as a dependency rather than copying the file wholesale. If you did copy the file, I would copy the contents of the entire license file to the top of the file you are copying as a block comment.

fzy-lua is not a neovim plugin and does not have the repo/lua/<repo-name> structure so I am not sure if plugin managers can handle it correctly. As well as how should I require it?
I think packer can handle these via luarock but I wasn't sure lazy had any option.
I took the copy-paste route and have added the whole license as a block comment. Could you check if this is OK?
https://github.com/nvim-neo-tree/neo-tree.nvim/blob/cdc87151ab4d4d8ef6545e6200c22aac58e04c34/lua/neo-tree/sources/filesystem/lib/filter_fzy.lua

Thank you so much @miversen33 for the detailed tests but I found some mistakes here and there, listed below. But your code lead me to a very efficient code that can compete against the other options.
My opinion when I was implementing this was that since the search feature is not something that is always running, I thought performance would not really be something to really care.
However, seeing all the analysis (below), I think it is worth rewriting it to use the outputs of shell commands for the case of fd. And since there is already a very well written code to invoke the shell commands here, I am thinking of refactoring this part a bit so that I can reuse the mechanism for the input of fzy. But lua actually did surprisingly well.
Besides, it seems to be that the telescope guys are taking a pretty similar approach, so although tinkering with lua was quite fun I think this is the right path to take.

I am not bright in time scanning but when I printed out duration inside on_exit, plenary.scan_dir_async seems to take like a huge amount of time. (around x100 of find)
But when I switched to plenary.scan_dir (without async), it actually managed to compete against the shell commands pretty well.
Moreover, I tweaked the code written by @miversen33 and was able to perform better than find. Couldn't beat fd tho cuz it seems to parallel the queue (which is noted in -j option in fd --help)
Also, the analysis done by @miversen33 was scanning /opt for fd and find which should be a mistake I guess? And the options for each command were not precisely aligned with what was implemented in test1 like follow link and ignore hidden files.

test1: Changed to only count the number of "file"s
test2: ????
test3: find /usr -type f
test4: fd . /usr -t=f -HI --color=never

Here are the final results. I can assure the programs are doing the same things (except for test2) because the number of files are exactly the same. (I did not get output from plenary.scan_dir. I don't know why...)
Scanning /usr/
Doing Sync Libuv test
Doing Sync Plenary Test
Doing Spawn Test with find
Doing Spawn Test with fd
    Test 1 (libuv sync scan) took approximately 966.847855 ms -- No warmup will slow it down to like 3000 ms
    Test 2 (plenary sync scan) took approximately 1229.072352 ms
    Test 3 (plenary find scan) took approximately 1246.537361 ms
    Test 4 (plenary fd scan) took approximately 836.98088 ms
luv.fs_scandir: done, count: 429128
find: done, count: 429128
fd: done, count: 429128

Code:
local luv = require("luv")
local plenary = require("plenary.scandir")
local job = require("plenary.job")
local start_dir = '/usr/'

local test1_count = 0

local test1 = function()
  local stack_index = 1
  local stack_path = { start_dir }
  local type_hash = {
    file = 1,
    directory = 2,
  }
  local stack_type = { type_hash["directory"] }
  local count = 0
  local duration = luv.hrtime()
  while stack_index > 0 do
    -- array[#array] access is faster. So using stack instead of queue
    local head_path = stack_path[stack_index]
    local head_type = stack_type[stack_index]
    stack_index = stack_index - 1
    if head_type == 1 then -- "file"
      count = count + 1
    elseif head_type == 2 then -- "directory"
      local head_fd = luv.fs_scandir(head_path)
      if (head_fd) then
        while true do
          local name, type = luv.fs_scandir_next(head_fd)
          if not type then
            break
          end
          stack_index = stack_index + 1
          stack_path[stack_index] = string.format([[%s/%s]], head_path, name)
          stack_type[stack_index] = type_hash[type]
        end
      end
    else
      -- symlinks etc are ignored
    end
  end
  duration = (luv.hrtime() - duration) / 1000000
  test1_count = count
  return duration
end

local test2 = function()
  local duration = luv.hrtime()
  plenary.scan_dir(start_dir, {
    hidden = true,
    on_exit = function(result)
      print(string.format([[plenary.scan_dir: done, count: %s]], #result))
    end,
  })
  duration = (luv.hrtime() - duration) / 1000000
  return duration
end

local function count_output_lines(name)
  return function(j, _)
    print(string.format([[%s: done, count: %s]], name, #j:result()))
  end
end

local test3 = function()
  local duration = luv.hrtime()
  job:new({
    command = "/usr/bin/find",
    args = { start_dir, "-type", "f" },
    on_exit = count_output_lines("find"),
  }):sync()
  duration = (luv.hrtime() - duration) / 1000000
  return duration
end

local test4 = function()
  local duration = luv.hrtime()
  job:new({
    command = "/usr/bin/fd",
    args = { ".", start_dir, "-t=f", "-HI", "--color=never" },
    on_exit = count_output_lines("fd"),
  }):sync()
  duration = (luv.hrtime() - duration) / 1000000
  return duration
end

-- warmup
test1()
test2()
test3()
test4()
test1()
test2()
test3()
test4()

print(string.format("Scanning %s", start_dir))
print("Doing Sync Libuv test")
local test1_time = test1()
print("Doing Sync Plenary Test")
local test2_time = test2()
print("Doing Spawn Test with find")
local test3_time = test3()
print("Doing Spawn Test with fd")
local test4_time = test4()
print(string.format("    Test 1 (libuv sync scan) took approximately %s ms", test1_time))
print(string.format("    Test 2 (plenary sync scan) took approximately %s ms", test2_time))
print(string.format("    Test 3 (plenary find scan) took approximately %s ms", test3_time))
print(string.format("    Test 4 (plenary fd scan) took approximately %s ms", test4_time))

print(string.format([[luv.fs_scandir: done, count: %s]], test1_count))

--[[
Scanning /usr/
Doing Sync Libuv test
Doing Sync Plenary Test
Doing Spawn Test with find
Doing Spawn Test with fd
    Test 1 (libuv sync scan) took approximately 966.847855 ms to scan 0 items
    Test 2 (plenary sync scan) took approximately 1229.072352 ms to scan 0 items
    Test 3 (plenary find scan) took approximately 1246.537361 ms to scan 0 items
    Test 4 (plenary fd scan) took approximately 836.98088 ms to scan 0 items
luv.fs_scandir: done, count: 429128
find: done, count: 429128
fd: done, count: 429128
--]]

@pysan3
Ya I was noticing some more issues with my tests this morning but got a bit sidetracked with work. I planned on revisiting them afterwards, but it looks like I dont have to!
My main concern is just ensuring that large scans are thought through thoroughly (boy that's a tongue twister). As @cseickel pointed out, my plenary async scan test is inaccurate (I couldn't get it to cooperate this morning when toying with it a bit either), so I am glad someone was able to properly get that tested out.
It does seem like reaching out to an external binary (such as find/fd/where) is the way to go here and nice find on how telescope handles this!
Just for clarity sake, could you elaborate on the warmup section of your above test? I can't imagine that is something that should be done in "production" code (running your search twice seems counterintuitive from an end user standpoint).
Also, I am not seeing in this commit, a way to cancel the fuzzy find command should the end user want to. Example, I execute a fuzzy find over my entire root directory, looking for anything containing the letter e. That would take forever, do we have a mechanic to "cancel" that find right now? I know underlying you can do this with spawn, and since we have plenary, I believe plenary jobs have wrapped this "cancel" ability as well.
I do agree that a true fuzzy finder is a fantastic idea :) But I don't know that I like the idea of "let the user figure out if it works for them or not". We should try to ensure that it "works" for your average user, even if it is an optional command. Otherwise it won't get used.

Just for clarity sake, could you elaborate on the warmup section of your above test?

I was kinda just having fun with lua to see what happens when I push it to its limit. And because SSD and OS have caching mechanisms, it would not measure the time accurately enough without a warmup.
The decrease in time in the lua case comes from (in my opinion) being literally test 1 and not test 4, and due to the jit compiler. I haven't gone much into this part but in my understanding, lua code should execute faster from the second run.
I was not planning to put this in the neo-tree code but just for the sake of fair comparison.

a way to cancel the fuzzy find command should the end user want to.

I see that. Yes, I believe we have no way to stop the computation except from killing neovim entirely and it hangs entire neovim which is indeed a problem. Neovim devs seem to be working on this but I'm not sure about the progress.
I guess we could add a code to simply error out when a certain time has elapsed (which can be configured) to avoid a sudden hang but we should ask @cseickel if that is a good idea.
Or we can wrap the whole function with luv.new_thread() or luv.new_async() I guess? Unfortunately I don't have much knowledge here.

With luv.spawn, we can do timeout handling as well as cancellation handling without needing to wait on the async issue to become resolved and mainstream.
I have an example of how to do this with luv.spawn in netman's shell wrapper, found here
I will research this evening, I am almost certain that Plenary jobs have a similar mechanic which would be great as Neo-tree is already using plenary. But if worst comes to worst, it is possible to do this via the low level luv.spawn

Thank you very much for your information. I haven't dealt with coroutines and stuffs in neovim so this is very helpful.

I will research this evening,

Are you planning on extending the fd / find? If so, it would be very nice if you could also wrap the old search function since I think it does not have a safety mechanism as well.
BTW, did you test my test1 on your machine? It seems to be (at least on my end) that pure lua implementation performs the fastest when it comes to smaller repos. (I mean even with the whole $HOME dir).
If this is the same in your case, I believe the first priority should be on smaller repos, hence not using shell commands but lua with a safety mechanism.
Anyways I would like to ask @cseickel on which route we should take.

Some quick results on my machine with your test @pysan3
Scanning /usr/
Doing Sync Libuv test
Doing Sync Plenary Test
Doing Spawn Test with find
Doing Spawn Test with fd
    Test 1 (libuv sync scan) took approximately 405.157384 ms
    Test 2 (plenary sync scan) took approximately 704.815711 ms
    Test 3 (plenary find scan) took approximately 270.366907 ms
    Test 4 (plenary fd scan) took approximately 395.056319 ms
luv.fs_scandir: done, count: 511415

I find it very interesting that find is significantly faster on than anything else on my machine, but it is the slowest on yours. There's quite the discrepancy in results here :/

Are you planning on extending the fd / find? If so, it would be very nice if you could also wrap the current search function since I think it does not have a safety mechanism as well.

I had not planned on overhauling or extending anything just yet, but rather to research how to cancel a plenary job. It looks like it should be as simple as calling :stop on the job handle provided (per the job doc).
That means the bigger questions that need answered (imo) are

Do we prefer shelling out or refining the lua route?
How do we present a "cancel" option to the end user when they execute a command. Is this functionality already in neo-tree and I just missed it?

Thank you @miversen33 for doing the tests.
It's quite interesting that we all have a very different results and I'm not sure what is the correct way to take.
But I think we can abstract the find_files function to utilize all methods and even expose a config option to the user.

It looks like it should be as simple as calling :stop on the job handle provided

Thank you so much. Yes this seems to be the answer.

How do we present a "cancel" option to the end user when they execute a command. Is this functionality already in neo-tree and I just missed it?

I believe on a nui input, user can press <Esc> to abort but I don't think there is any mechanism to cancel any command execution but I'm not exactly sure.
In case of plenary.job, I think this would work but this will overwrite the keybind, and I doubt this is a clean solution.
local Job = require("plenary.job")

local myjob = Job:new({
  command = "find",
  args = { "/usr", "-type", "f" },
  on_stdout = function(err, line)
    vim.pretty_print([[stdout:]], line)
  end,
  on_stderr = function(err, line)
    vim.pretty_print([[stderr:]], line)
  end,
  on_exit = function(code, signal)
    vim.pretty_print([[CODE: exit:]], code)
    vim.pretty_print([[SIGNAL: exit:]], signal)
  end,
})

myjob:start()

vim.keymap.set("n", "<Esc>", function()
  myjob:_stop()
end, {
  buffer = ...,
})

Do we prefer shelling out or refining the lua route?

I am thinking of implementing all of them because either way has its benefits and cons.

pure lua

should be the fastest for small dirs
pretty tedious to implement gitignore and other filters

plenary.scandir

supports gitignore and some filters (imcompletely)
not so fast

find, fd, ...

has rich filters
we can copy from existing code and telescope
less performance decrease on larger repos
overhead of spawning a shell, especially in smaller repos

But I would also like to hear from @cseickel for his opinion.

I am thinking of implementing all of them because either way has its benefits and cons.

Actually, I don't think there are actually any benefits to the libuv and plenary options. One big driver of that is that they only seem viable if you don't bother with handling gitignore. Plenary's gitignore is way to naive and just doesn't work for anything but the simplest case. We have implemented it ourselves by calling git directly to get the ignored files per folder. It's really the only reasonable way to get this right in lua.
fd and find will do this for you, and will do it correctly and insanely fast. If you combine that with the fact that even just recursively listing all files is fast before doing any filtering, it just doesn't make sense to bother with a hand made solution. In reality you should be using fd/find to also do a first stage filter so that the results you need to iterate over and score are reduced as well, which is a further speed up.

pure lua

should be the fastest for small dirs
pretty tedious to implement gitignore and other filters

Why would it be fastest for small directories? Besides, who cares what is fastest for small directories? Small directories are never a problem so no need to make any decisions based on what is best for them. You need to optimize for the slow cases only.

plenary.scandir

supports gitignore and some filters (imcompletely)
not so fast

Plenary is a great library for a lot of things, just not for scanning a file system. Plenary.scandir is banned from this project. It's slow and inaccurate.

find, fd, ...

has rich filters
we can copy from existing code and telescope
less performance decrease on larger repos
overhead of spawning a shell, especially in smaller repos

I don't think there is actually any meaningful overhead for calling the external process. You don't actually spawn a shell, at least not in the way that we call it.
I would reuse the existing code in filter_external.lua and provide a way to adjust the filter to cast a super wide net that is suitable for feeding to the fzy methods, then inject that fzy code as an extra intermediate step to what is already there.

Thanks for your comment.
Ok, so I will

refactor filter_external.lua to use fd / find for fzy as well
add docs and help

Tho I am against reusing the current implementation and simply sticking fzy after the fd / find since it needs to spawn the command for every keypress while searching. (To be exact, only the last query is executed when multiple are in the queue.)
The current implementation is built to spawn a new fd process everytime because fd is what is doing the filtering but when we use fzy, we only need the result of fd . -t f (--hidden) (--no-ignore) and can reuse it while user continues narrowing down.
And as far as I know, caching result of fd is not doable with the current call stack.

The current implementation is built to spawn a new fd process everytime because fd is what is doing the filtering but when we use fzy, we only need the result of fd . -t f (--hidden) (--no-ignore) and can reuse it while user continues narrowing down.

That's true, now that you mention it. I guess you can store the original listing of files in memory and just keep re-using if that is the most performant way to do it.

With the latest commit, I have implemented the fzy algorithm that uses file list taken from fd and other commands.
Besides, I have written the document and added filesystem commands fuzzy_sorter and fuzzy_sorter_directory, as well as a default keybind ["#"] = "fuzzy_sorter", as mentioned in the README.
With this, I think the feature is implemented so I will mark this PR as ready for review.
@cseickel, @miversen33 I can't thank you enough for the help!
And I would be happy to hear any feedbacks. (Better command name and better default keybind?)

Awesome. I'll check this out and use it for work today.

@pysan3 @miversen33 Sorry I haven't provided any updates. I have been using it and I think it works well for my repos. I definitely prefer it to the old fuzzy search.
I haven't looked at the code close enough to approve it, and I haven't tried to test it with bigger repos so I can't give it my blessing as of yet. I'll try to give it a closer look this weekend.

FYI - I experienced a bug just now where all of my trees were sorted in a random, yet consistent manner. That means that they stuck with their odd sort order across refreshes and changing the working directory, but I couldn't figure out what the logic was. I couldn't get them right again until I restarted nvim. I don't know for sure if this was caused by using the fzy search, but it seems like a likely suspect.

I do indeed overwrite the sorting function at the start of the filtering here and restore the old function at the end of search around here.
I didn't find any edge cases with this logic but if the sort is aborted, I guess the reset_search is never called hence not restored for some reason?

Thank you very much for your reviews.
I'll definitely look at them tomorrow and update those points.
I'll ping you when I'm finished.
Can't wait for it to be merged ;)
BTW, what do you mean by default? Since we already map it to #, do you mean to remap it to /? Or should we not map it to anything now and on v3.0 overwrite the fuzzy_finder command?

BTW, what do you mean by default? Since we already map it to #, do you mean to remap it to /? Or should we not map it to anything now and on v3.0 overwrite the fuzzy_finder command?

I meant that for now we can add it as an additional command, but in 3.0 we will remove the old fuzzy finder from the default mappings and use this one as the command mapped to /.
Unless we drop / as a mapping, which is a different conversation, but the point is that this will be the recommended option.

@cseickel Thank you for your reviews and sorry being late.
As I have commented on individual comments, these are the changes I made.

use sort_function_override instead of modifying config.sort_function ( 2e5ee31 )

sort_by_score -> set_sort_by_score as well

use get_find_command to decide the proper find command. ( d0919a5 )

As I mentioned in other places, I did not want the filter_files_external function to require state as an argument.
Meaning that it is responsible for the code that is calling this function to decide the find_command beforehand.

Search for fdfind before fd. ( 5a21092 )

I believe I received a notification where someone pointed out that it will false detect a different fd command on Ubuntu based distros. (I can't find that comment anywhere tho)

Let's merge it! 🎉


Generic Linux support

Summary of the new feature / enhancement
Support generic Linux distributions with a bootstrap that does not rely on a distribution-specific binary
My motivation is for the Julia binary package build system, but it would be useful for a variety of thin containers
Proposed technical implementation details (optional)
No response

There is already powershell-7.2.0-preview.8-linux-x64-fxdependent.tar.gz

thanks.
is it possible to use it in a "vanilla" linux container/sandbox?
what about the required .NET framework? is there a portable / distribution-agnostic version?


Heavy saving in poedit 2.3.1

Hello, I would like to report heavy saving in the latest version.
Whenever I do Ctrl+S I am unable to continue editing for about a minute. I can click menu buttons like Help but I am unable to get the editor to edit text.
Using the save button gives me back the opportunity to edit.. but an extra mouse movement and clicking wastes precious time when translating.

Please read this document (which GitHub asked you to do when you created this issue), follow the instructions therein and provide the missing detailed information. Thanks!

Closing as non-reproducible due to OP going incommunicado.


fio failed to install

Installing 'fio' (3.20) [64bit]
The remote server returned an error: (403) Forbidden.
URL https://bsdio.com/fio/releases/fio-3.20-x64.zip is not valid

This issue belongs in the Main bucket. Unfortunately, we cannot move this issue on this end, so it is being closed.
If this is still an issue, please create a new issue in the Main bucket via https://github.com/ScoopInstaller/Main/issues/new?body=Moved+from+https%3A%2F%2Fgithub.com%2Flukesampson%2Fscoop%2Fissues%2F4113

I added:
https://github.com/ScoopInstaller/Main/issues/1598


Extension title is too dark and card size is too small.

Hi,
I believe the recent updates to the repo caused some issues with the extension=activity, in particular when the theme is set to dark.
As you can see in the image below, the title is too dark, I think it would be better if it was a bit brighter.
Also, the last row in the activity is getting chopped off.

I will try making a pull request to fix those issues. However, I can't work on it till the weekend probably, but if you fix them before, that'd be great!
Thanks for the project!
Lucas

@lnogueir
Thanks for your report.
The chopped last row problem is caused by the change of the default font. You can set font option to Arial (font=Arial) to fix that.
The color of extension title should be the same with username. The problem is caused by wrong config of auto theme (style). I will fix it as soon as possible.

The color of extension title should show normally now. https://github.com/JacobLinCool/LeetCode-Stats-Card/commit/542e2519e0fcf42b8d2902fa62a7e90f1eff6764

Looks just how I want with font=sans-seriff. Feel free to close this.
Thanks!


feature request: add material design icons

It would be great to be able to provide material design icon name the same way as emoji icons. To prevent accidental overlap with already used tags I propose to add mdi: prefix to those icons.

Could you clarify what's happening with the overlap? Are you saying that you'd like to use a tag that maps to an emoji already, or that you'd like to include an additional set of icons (material icons)?

I would like to have another, way bigger, set of icons and use it the same way as it is already done for emojis - though tags. Many emoji names will overlap with material design icons. To prevent that we can add mdi: prefix, for example to use existing emojis you specify email tag and to use meterial design icon it will be mdi:email.

Honestly, right now, I don't think I'd like to expand the tag-to-icon mapping further. The standard emojis are very expressive and the soon-to-be-available per-notification icons will help customize the notifications even further.
I'll leave this ticket open for a while. Please upvote :+1: if you want this done.


:memo: Fix/Add config section of deployment on kubernetes

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

What type of changes will we make to the documentation?
Typo, layout, grammar, spelling, punctuation errors, etc.
Affects Version(s)
master
Improving the documentation
The kyuubi on kubernetes config section states Kyuubi do not recommend using this way on Kubernetes. This can perhaps be stated as Kyuubi does not recommend using this way on Kubernetes.
Are you willing to submit PR?

[X] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
[ ] No. I cannot submit a PR at this time.

Please assign this issue to me.  Thanks

@mans2singh thanks for being interested in Kyuubi project, for minor features/improvements/bug fixes, it's fine to send PR directly as long as you fill detailed in the PR description.
And for issues without assignees(or no progress since the last event for a long time), if you don't have further questions about the issue itself, you don't need to wait for the assignment, just leave a comment like below and then can prepare your PR.

I'm going to start working on this issue, it supposes to be completed in a few hours/days/weeks

To be clear, the community appreciates all contributors' efforts, and won't blame contributors if they do not complete the work in time, the estimated time just lets other contributors know the issue is likely available to pick if the last contributor has no updates for a while.


[RUNTIME] Support Limited Save to Module without OpenCL Cross Compile

Currently we require a local opencl module in order to be able to save a module. This is not strictly necessary.  Since we only need the SaveToBinary feature which can be supported without enable OpenCL in local env (the execution won't work).  This is likely to make life easy for local env who do not have OpenCL  like in case of #641

[ ] Support a GPUSourceModule that support SaveToBinary and GetSource
[ ] Return GPUSourceModule when CL/CUDA  is not enabled.

Shall we just add SaveToFile and SaveToBinary to tvm::codegen::SourceModule or add a new class in tvm::runtime?

@merrymercy We can create a tvm::codegen::DeviceSourceModule that subclass SourceModule(let us not put it in runtime as it creates new files into runtime).
The reasoning behind this is that DeviceSourceModule might save different from source(if it is a host side c++ file)


[bug] Fix custom image path when a build repository is defined

This issue affects the build step, specifically the path creation of an image to push when a repository and image name are specified.
Example Config:
{
    "plugins": {
        "docker-compose": {
            "build": "app",
            "config": "some/directory/docker-compose.yml",
            "image-repository": "gcr.io/project/repo",
            "image-name": "app:latest"
        }
    }
}

Problem/Solution:
The resulting image path would end up malformed.
Before fix:
${image_repository}:${image_name}
gcr.io/project/repo:app:latest
After fix:
${image_repository}/${image_name}
gcr.io/project/repo/app:latest

Oh dear, thanks for the bug report and fix! We'll look at getting this tested and merged. Thanks @SpencerSharkey

Apologies for the confusion! image-name is unfortunately named. It's actually used as the tag part of the image name:

The name to use when tagging pre-built images. If multiple images are built in the build phase, you must provide an array of image names.

In your case, is there a specific reason you want latest as the tag? That will mean that your steps all build and consume the same image (app:latest). It needs to be unique to a given build. The default is ${BUILDKITE_PIPELINE_SLUG}-${service_name}-build-${BUILDKITE_BUILD_NUMBER}, which is created in https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/3438eb9a60f11add15134531fd0fd7205c51c928/lib/shared.bash#L164-L175.

I'm going to close this for now, as we haven't heard back! Let us know if we can help solve the underlying problem!


(APS-14) Hide withdrawn assessments

Now assessments can be withdrawn, we need to hide them on the assessments and application listing pages.

We're going to do this filtering on the frontend, so closing this


trouble shooting some problems

package '@repo/backend' has conflicts in the following paths:
/Users/kevin/foo/packages/backend
/Users/kevin/foo/apps/gen2/isolate/packages/backend
Struggling with logging/debugging
Do I need to manually delete the isolate folder before each call to isolate?
PNPM used partially and then NPM used to pack...
$ npx isolate
debug Using isolate-package version 1.13.2
debug Found tsconfig at: ./tsconfig.json
debug Workspace root resolved to /Users/kevin/foo
debug Isolate target package (root)/apps/gen2
debug Isolate output directory (root)/apps/gen2/isolate
debug Detected package manager pnpm 8.15.7
debug Detected pnpm packages globs: [ 'apps/*', 'packages/*', 'services/*' ]
debug Registering package ./apps/gen2
debug Registering package ./packages/typescript-config
debug Registering package ./packages/firebase-admin
debug Registering package ./packages/eslint-config
debug Registering package ./packages/connectrpc
debug Registering package ./packages/common
debug Registering package ./packages/backend
debug Using PNPM pack instead of NPM pack
debug Packed (temp)/repo-backend-0.0.0.tgz
debug Packed (temp)/repo-common-0.0.0.tgz
debug Unpacking (temp)/repo-backend-0.0.0.tgz
debug Unpacking (temp)/repo-common-0.0.0.tgz
debug Moved package files to (isolate)/packages/common
debug Moved package files to (isolate)/packages/backend
Error: Command failed: npm pack --pack-destination "/Users/kevin/foo/apps/gen2/isolate/__tmp"

    at ChildProcess.exithandler (node:child_process:422:12)
    at ChildProcess.emit (node:events:517:28)
    at maybeClose (node:internal/child_process:1098:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:303:5)

Declared using pnpm but then uses npm pack.
Trying to introduce into firebase monorepo, but need to keep the firebase.json at the root and use codebase for different functions services.

@kevpie  Thanks for bringing this under my attention. The part with npm was definitely a bug, and I have addressed it in #73
I have published 1.14.0-0 under the next tag, so you can install it with pnpm add isolate-package@next -D
I don't have time to test it right now, so please give it a try and let me know if it works.
Any existing isolate directory is cleared at the start of the process, so no need to manually remove it. Keeping the firebase.json in the root is not something I have tested myself, but it should be no problem, as it is mainly a matter of pointing source to the correct location.

Thank you!
I hope to start working again on this soon.  I really appreciate your
efforts around this challenge in the Firebase ecosystem.
On Thu, Apr 18, 2024 at 12:19 PM Thijs Koerselman @.***>
wrote:

@kevpie https://github.com/kevpie Thanks for bringing this under my
attention. The part with npm was definitely a bug, and I have addressed it
in #73 https://github.com/0x80/isolate-package/issues/73
I have published 1.14.0-0 under the next tag, so you can install it with pnpm
add @.*** -D
I don't have time to test it right now, so please give it a try and let me
know if it works.
Any existing isolate directory is cleared at the start of the process, so
no need to manually remove it. Keeping the firebase.json in the root is not
something I have tested myself, but it should be no problem, as it is
mainly a matter of pointing source to the correct location.
—
Reply to this email directly, view it on GitHub
https://github.com/0x80/isolate-package/issues/72#issuecomment-2064199502,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABH5GW222Z37ACVJKUI4XDY57P6XAVCNFSM6AAAAABGLQ7UPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRUGE4TSNJQGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Kevin Pierce
@.***
717-1341

I'm going to assume this is solved. Feel free to reopen if you have more info.


Avoid false drops in query

False drops of points in query may happen in random tests because of floating point round off errors. From the original SRTree source code (HnSRTreeNodeObject.cc):
		/*
		* NOTE:
		*
		*    Dec.13,2000 Norio KATAYAMA
		*
		*    Here ``getUpperBoundMaxDistance()'' is used for spheres
		*    in order to prevent false drops caused by round-off
		*    errors. As for rectangles, it is not necessary to use
		*    ``getUpperBoundMaxDistance()'' because the distance
		*    obtained by ``getMaxDistance()'' is guaranteed to be
		*    equal to or greater than the distance to the farthest
		*    point.
		*
		* Additional Note:
		*
		*    The above comment is satisfied only when the distance to
		*    a point is always measured by ``getDistance()'' and when
		*    bounding rectangles have the same precision with points.
		*    It is better to use ``getUpperBoundMaxDistance()'' instead
		*    of ``getMaxDistance()''.
		*/

This can be reproduced by simply running the random tests several times.


feat: createVP accepts VCS instead of VC IDs

Changed RPC method
Fixed RPC method request parameters type
Fixed dApp
Fixed combobox bug on dApp

This PR also fixes the following issues:

#217

I will merge it after I merge some other things and create a new release.


[Shaders] runtime compilation of shaders from strings, w/o asset bundle

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use cases

User Uploaded Shaders (our use case). Our app renders midi music.  We want to support custom "themes".  i.e. fully custom shaders uploaded by the user as text strings.
Runtime shaders. Some shaders are easier to make at runtime, based on dynamic properties.
Single file shader examples. If the shader can be a Dart string, simple shader examples can be single files.

Proposal
AFIACT, shaders must be provided at compilation time. See Docs: https://docs.flutter.dev/ui/design/graphics/fragment-shaders
flutter:
  shaders:
    - shaders/myshader.frag

FragmentProgram.fromAsset('shaders/myshader.frag');

Proposal: implement runtime compilation, i.e.FragmentProgram.fromString('shaders/myshader.frag');

We're not going to add support for this, as we don't plan to ship multi-megabyte shader compilers by default with the engine. There has been some discussion about providing a specification for the format the engine accepts so that developers can choose to bundle a shader compiler if they are willing to pay the code size cost, but this is blocked by us stabilizing the asset format after we ship Impeller on Android.

Thanks for the very quick response.
Glad to see this is on your radar. Is there an issue for tracking this work? I looked for one but did not find it.

Ahh yes, my bad: https://github.com/flutter/flutter/issues/124759

thanks. I'll close this issue in favor of that one!


Handle out-of-order image uploads

If somebody only uploads image #2, don't save that as image 2, save it as image 1.

Confirming that this is an issue if I create a new bottle and upload images 1 and 3, but not 2.

Seems to also be an issue when deleting a bottle, as I see an image left over in S3. it was {bottle_id}_3.png, which was the second image uploaded.
This shouldn't really be an issue if the functionality is implemented properly... but it wouldn't hurt to remove images that "start with" {bottle_id}.


[Request]GoProne integration

Someone made a mod that allows players to immediately enter crawling mode upon the push of a button.  Looks pretty simple too.  Could we also see that added to Aqua Acrobatics?

Seeing this get implemented would be nice!
There's a fork of Ido that seems to do something similar,
hopefully this could help with implementing such a feature into Aqua Acrobatics.

This feature is added in 1.10.0, but is disabled by default since it's not a vanilla feature, and requires the server to also be updated.


Fixed broken org.yaml due to missing entries in org members. Added manual test.

The problem was that one of the newly added team members was not an admin or member of Kubeflow org. Fixed the membership. Updated README as well to include manual tests.
Fixes https://github.com/kubeflow/internal-acls/issues/148

This change is

/assign @abhi-g
/assign @jlewi

Thanks
/lgtm
/approve


Remove usage of the word "allocate" in reference to local memory

See https://stackoverflow.com/questions/68869806/how-is-performance-affected-by-using-numba-cuda-local-array-compared-with-numb. As I am new to CUDA computing, I don't know if my suggested edits are correct and am merely passing on the implication in the linked SE post. In the CUDA docs under local memory, I didn't see any use of the word "allocate", so perhaps this is a correct suggestion. If the original usage is fine, please reject this pull request.

Reference an existing issue

#7328

I think the changes are removed now, and I accepted the see also edit. It's been very useful to see your suggestions to the PRs. Thank you! Let me know if there's anything else on this one I need to do.

Many thanks for the update, and your contribution to Numba! This looks good to me now.


add check to 256 color about vim

Hi!
I added a patch about check to 256 color about Vim.
This patch use a lot of famous colorscheme.
Please check this Pull Request!
like this

https://github.com/morhetz/gruvbox/blob/cb4e7a5643f7d2dd40e694bcbd28c4b89b185e86/colors/gruvbox.vim#L21-L23

https://github.com/dracula/vim/blob/c8c0a9325407c487fd702eca39d987d67123c98b/colors/dracula.vim#L28-L30

Thanks @kazukazuinaina! 💟

@whatyouhide
Thanks for code review and Merge!


Remove Deno bundle support for esbuild

Deno is to remove bundle so it seems strange to add it into the solution when nx already has esbuild support and its what is recommended<EMAIL_ADDRESS>

We added deno emit executor to take place in of bundle now.
https://github.com/nrwl/nx-labs/pull/185


docs(pe): update plugin version DOC-377

Resolves Jira: DOC-377

https://s.armory.io/llu5AWA1

looks good to me.


Create workflow for finalizing release

Right now, this is all manual, this upgrades everything we can to automation

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

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

Yep, agreed - typically the pattern I'm following for this stuff is merge an initial pass at the workflow, try it/fix any issues, then update docs


Offering help to add NativeScript support

Hi friends,
As a follow-up to https://github.com/Microsoft/code-push/pull/435, I'd like to offer our help adding support for NativeScript in the AppCenter CLI. As a matter of fact, I (and others in the NativeScript team and community) would be happy to submit a PR to add support - and maintain the integration later as well. The goal here is to bring a world-class app-updating feature to the NativeScript ecosystem.
Our "Plan B" would be forking this repo and adding support, then publishing the fork to a new package on npm. We'd also have to use some sort of clone of the server bits. Suffice to say, we're not looking forward to going this route though.. so please let us know if you're interested in this proposal.
Thanks in advance for considering supporting NativeScript once again!

+1

+1

Hey @EddyVerbruggen @yilmazyavuz and @Sharpie360, thanks for leaving us this comment! We'll respond shortly.

@amchew is there an ETA on when we might expect an update? We have a lot of folks interested in this. Thanks!

@amchew any news? This would be a perfect gift for my birthday 26/08 <3

@jdnichollsc take a look at NativeScript AppSync
It's a fork of CodePush for {N}!

Hi all! Apologies for the delayed response. @EddyVerbruggen, @yilmazyavuz, @rabbitwerks, @rdlauer, @jdnichollsc yes we always welcome community contributions, so feel free to do so You can make PR with your contributions, see an example here: https://github.com/microsoft/appcenter-cli/pull/627. Thanks!

@EddyVerbruggen @rdlauer Ok, the moon station has copied us, how can I help you guys? MissionControl: {N} => 🚀🚀🚀 => AppCenter 💯

The addition of this capability would make AppCenter significantly more valuable.

As we do not have plans to add support for this feature in the next year, I'm closing the issue.


Add _ignored argument to SchemaValidator

Change Summary
This PR adds a new _ignored keyword argument to the SchemaValidator. The goal is to have a key that is going to be ignored, and it will allow compatibility with the logic implemented in https://github.com/pydantic/pydantic/pull/6820/.
Related issue number

Related to https://github.com/pydantic/pydantic/pull/6820/

Checklist

[ ] Unit tests for the changes exist
[ ] Documentation reflects the changes where applicable
[ ] Pydantic tests pass with this pydantic-core (except for expected changes)
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Is there a reason we need to store this in the Rust type? Could PluggableSchemaValidator just save this field in __init__?

Ok. This is not needed! 👀
Thanks @davidhewitt :)


the module is not compatible with tf v0.15.0

what

added version constraint limiting the compatiblity to < 0.15.0

why

tf v0.15.0 introduces sensitive output limitations
Please refer to my other pr for a fix (requires bumping minimum compatibility to >= 0.14.0):  #134

I've been using this in terraform 1.0 and it works fine for me.
Do you have a reproducible example ?

Please re-open if you have more information


Prepare for release 0.4.0: Updating version number

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Add Configurability - Api Surface section

Relates to https://github.com/dotnet/roslyn-analyzers/pull/3987

@Evangelink : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Tagging @mavasani for the merge green light

#sign-off


[3396] - Fix failing geocoding.spec.ts

Context
The location autocomplete no longer displays "UK" in each location suggestion - https://github.com/DFE-Digital/find-teacher-training/pull/356
Changes proposed

Fixes failing geocoding.spec.ts. The spec no longer asserts that the location suggestion has "UK"

 [S] Remove ", UK" from location autocomplete


[Event Request] codeunit 1000 "Job Calculate WIP" - OnBeforeCalcWIP

New Event in codeunit 1000 "Job Calculate WIP"
[IntegrationEvent(false, false)]
local procedure OnBeforeCalcWIP(var JobTask: Record "Job Task"; JobWIPTotal: Record "Job WIP Total"; JobComplete: Boolean; var RecognizedAllocationPercentage: Decimal; var JobWIPTotalChanged: Boolean)
begin
end;

local procedure CalcWIP(var JobTask: Record "Job Task"; JobWIPTotal: Record "Job WIP Total")
var
    JobWIPMethod: Record "Job WIP Method";
begin
    OnBeforeCalcWIP(JobTask, JobWIPTotal, JobComplete, RecognizedAllocationPercentage, JobWIPTotalChanged);
    if JobComplete then begin
        JobTask."Recognized Sales Amount" := JobTask."Contract (Invoiced Price)";
        JobTask."Recognized Costs Amount" := JobTask."Usage (Total Cost)";
        exit;
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 47191.