Fix Integration Failure

Codecov Report
Base: 93.36% // Head: 93.36% // No change to project coverage :thumbsup:

Coverage data is based on head (9866dba) compared to base (2185338).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##           master      #83   +/-   ##
=======================================
  Coverage   93.36%   93.36%
=======================================
  Files          77       77
  Lines        4566     4566
  Branches      422      422
=======================================
  Hits         4263     4263
  Misses        181      181
  Partials      122      122

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

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


Create IBM BigSQL 4.2_odpi_v1.0.1

Hive is not (yet) an ODPi component so it shouldn't be referenced in compliance with this version of the spec.

Looks good.


Replace tx_in.tx_out_id by tx_in.tx_out_hash

Summary. This is expected to:

reduce sync time
cause a schema change which will significantly affect users downstream (BLOCKED: decide with product team/users)
needs a migration which doesn't require resync
increase disk size a bit

Currently for each tx_in:

a query is done to the tx table, to find the id by the tx hash
the result is used to do a query to the tx_out table to find the ada amount. This is used to calculate the tx.deposits
if there is a redeemer on this input, a query may be done again to the tx_out table to retrive the address, which is the script hash

Even if these queries are backed by indexes, they still cause big delays, since all these tables tx_in, tx_out, tx have tens or hundreds of millions of entries.
Alternatively we could simply insert the hash, as it is found in the input. This by itself wouldn't make the first query unnecessary, as its result is also needed by the second query.
To avoid the seconds query, we could use the ledger event which gives us the deposits. This ledger event will have to change in the ledger, as it currently doesn't include the tx_hash (BLOCKED: investigate this with ledger team). When disable-ledger is used, this event is not created, so we would have to either do the queries and pay the performance cost or make deposits nullable and add it to https://github.com/input-output-hk/cardano-db-sync/blob/master/doc/configuration.md#--disable-ledger (BLOCKED: decide with product team/users).
The third query rarely happens, as only a small percentage of inputs have a redeemer attached, so we can keep it.

I did some benchmarks and it seems these queries until epoch 329 are execute 82171515 times (equal to the number of queries at this moment) and they cause an average delay of 0.000298774193s. This is a total delay of 24550s which is a bit less than 7 hours. For comparison the total sync time to this point is 89340s.
So these queries takes more than 25% of sync time.

This should improve syncing time, at the cost of more disk space, and may also slow some queries. We should perhaps establish baselines for each query. There are 45 tables, and users can construct their own queries against the tables. So the bast course of action would be to ask users about the queries they are running. We could ask DevOps team and Rhys (Cardano GraphQL) as well. We could do a survey of external users to find out the queries they use, such as SPOs that run DBSync (Vitor may know). CExplorer.io uses DBSync. Jide Fashola @ Cardano Foundation may know what queries exchanges do with DBSync.

The lookup for tx hash (as against tx ID) could have quite large footprint in memory, which would make querying balances for transactions much slower.
Additionally, for koios (and it's clients):

we also had to create stake snapshots (set, mark and go against each account) , a job that has to iterate through every account balance in past 2 epochs
live stake distribution (refreshed every 30 mins) built as cache

Since these have to iterate balance for every account frequently, this will likely take a higher toll on resources. This is just to call out that this change will have expensive impact to query layers (while sync occurs once and is managed via snapshots).

Seems this might be of questionable benefit, without being able to more accurately predict performance impact across various use cases.
Here's a question though: would there perhaps be a benefit to leaving the ID and also adding the hash?

The tx_in table s already one of the largest tables (in epoch 372):
select count (*) from tx_in ;
   count
-----------
 135099657
(1 row)

A hash is 32 bytes, so this is at a minimum, right now, is a 4Gig increase in the table size, and this is for a table that will continue to be one of the fastest growing tables.

You no longer need tx_in join against tx_out tbh, there is now already an additional field in tx_out called consumed_by_tx_in_id.

@WubbleWobble - You no longer need tx_in join against tx_out, there is now already an additional field in tx_out called consumed_by_tx_in_id.

Brilliant - thanks for that! Glad I commented now :)


Partial instruction update

At least change python.org URLs to pypi.org and note that we should be using twine...

Coverage decreased (-0.06%) to 38.125% when pulling e38d37539a071aec8342ae2d3c656c772d3178cb on zimeon:master into a4d1d22f1c445bbbe525bf981b3d1368b6eb51e3 on IIIF:master.


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/source-wg-leads
/assign knative-sandbox/source-wg-leads
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/pkg 2bd91f7...82f3a9f:
  > 82f3a9f Add triggers to the downstream test (# 2236)
  > e957ee5 Drop several deprecated APIs. (# 2228)
bumping knative.dev/eventing-redis 778e887...49ff377:
  > 49ff377 upgrade to latest dependencies (# 208)
  > 824e8c9 Update community files (# 209)
bumping knative.dev/eventing ea5ed9a...9b1f09c:
  > 9b1f09c upgrade to latest dependencies (# 5681)
  > 51319db Add heartbeats image to released images (# 5680)
bumping knative.dev/eventing-kafka 24ac96b...75b06f9:
  > 75b06f9 upgrade to latest dependencies (# 840)

/lgtm
/approve


Blade directive not work even expression true

I am using Laravel 5.1.x and Entrust 1.7.0.
I have a user named Admin and has role admin
I try to use
@role('admin')
something
@endrole
base on document it should show word something
but it show nothing (blank) and dont have any error message
Thank in advance

This isn't great, but it was quick...
@if(Entrust::hasRole('administrator'))

i had try this but not work

That's odd.  It worked immediately for me with no special setup.  I'm using version zizaco/entrust 1.7.0 and my role is called "administrator".

What is your laravel version?

This worked to me too, and my Laravel version is 5.4.9

Laravel 5.3.29 for me

I'm having the same issue both on 1.7.0 and dev-master.
It seems that the blade compiler is broken. The compiled view has a syntax error, something like:
if (Entrust::hasRole'administrator')), note the missing opening bracket.


Unify docker images prisma and prisma-prod

Is your feature request related to a problem? Please describe.
We have 2 different images for local prisma and actual production deployments. The difference between those are:

the prod image can disable the Management API by setting managementApiEnabled: false in the server config
the prod image always tries to connect to a RabbitMQ specified by the rabbitUri property.

Describe the solution you'd like
We should only have one Prisma image that:

respects the managementApiEnabled setting
decides whether to use RabbitMQ or not depending on the presence of the rabbitUri property.

Describe alternatives you've considered
None
Additional context
I stumbled upon this issue while i advised people on a production setup for Prisma in this issue. They were trying to disable the Management API for the local image which was not possible.

@mavilein - This would indeed be easier to understand.
I have two followup questions:

Are there any other differences between the two?
Do you not recommend using prisma in production (when protected by a management API secret)? If not, how come?

@mavilein Do we still need to use prisma-prod?

decides whether to use RabbitMQ or not depending on the presence of the rabbitUri property

If we have 1 "primary service" for deployments (managementApiEnabled: true) and 1 "secondary service" for actual requests (managementApiEnabled: false), do we need RabbitMQ? Will the secondary server notice schema changes without it?

@frandiox : Yes you need it. The RabbitMQ is used to propagate datamodel changes from the management server to secondary ones.

@mavilein I'm creating an Helm chart for Prisma-Prod.
I was looking for the Dockefile that generates the -heroku suffix.
Due to secrets handlinkg in kubernets I would need a pruduction like docker image with the -heroku suffix:
https://github.com/helm/charts/issues/13530#issuecomment-570154690
Unfortunatly I didn't find anything on this repo, I would create my own production like image with the heroku env handling.


Patch 1

Hi @rtaiello, it looks like you're trying to merge the dev branch with the master branch, but the branch is not yet ready for merging. Please push to the dev branch instead!


add 买道传感科技（上海）有限公司 to powered-by page

Please answer these questions before submitting pull request

Why submit this pull request?
[ ] Bug fix
[x] New feature provided
[ ] Improve performance

New feature or improvement

Describe the details and related test reports.

add 买道传感科技（上海）有限公司 to powered-by page

ref #443

Coverage remained the same at 13.804% when pulling cb8daf9cace12f7d5cc9f2fa86aaab3c396ebcf2 on Ahoo-Wang:patch-1 into 59d472509168dabb3970c5dea0f586effc4f0600 on apache:master.


Feature Request - Assembly author check

Mod Assemblies can have the author name attached to the info of the assembly. My proposal is to check if the Author name contains data and use that with priority over package guid parsing.
(I made a dumb mistake with naming my guids and now I cant change them, but all of my mods have author data)

Consider it done


Remove font path variables for _variables.scss

Remove https://github.com/CityOfVernonia/core/blob/main/css/_variables.scss#L10-L12
Has no effect. Paths must be set in application before importing @arcgis/core/assets/esri/themes/base/core.

Also add...
--calcite-sans-family: #{$font-family};
to both of these classes...
https://github.com/CityOfVernonia/core/blob/main/css/cov.scss#L8-L25


schemas feature request

Feature request:
schemas ( https://github.com/apache/pulsar/blob/701f3ea7e3541f61f064167043de04e8a2db5c0f/pulsar-client-schema/src/main/java/org/apache/pulsar/client/api/Schema.java  )
If I want to pass arbitrary/dynamic Json schemas that are not POJOs - is there a way to pass something dynamic there?
I would like to create a Json schema that specifies a https://json-schema.org/ , or maybe a Map<String, String> properties
All examples I’ve seen are JSONSchema.of. Or is possible to describe the new schema over JSON? It seems that yes: https://pulsar.apache.org/docs/en/concepts-schema-registry/#supported-schema-formats but I don’t see any example or they are not exposed.

After discussion, the way to do what I want is to:

1 - create a schemaless topic
2 - use the POST /admin/v2/schemas/:tenant/:namespace/:topic/schema endpoint to set a schema straight after that ( http://pulsar.apache.org/docs/en/admin-api-schemas/#pulsar-admin )
3 - use AUTO_PRODUCE_BYTES as mentioned above

@nha @merlimat
sorry for asking.
In my case, I have some raw json string data send to topic and can't hard code pojo class, I want to use the pulsar schema feature to validation the structure. I have a topic "my-topic" and associated with json schema in below, then I try to transmission some message.
var producer = client.newProducer(Schema.AUTO_PRODUCE_BYTES();
producer.send("{\"y\": 1}".getBytes()); // here! the value is 1(number) not string.

var reader = client.newReader(Schema.AUTO_CONSUME())
var message = reader.readNext();
I got {"y": 1}

my question is how pulsar schema works? The message should be rejected.
{
  "version": 1,
  "schemaInfo": {
    "name": "my-topic",
    "schema": {
      "type": "record",
      "name": "Data",
      "namespace": "com.iot.test",
      "fields": [
        {
          "name": "value",
          "type": [
            "null",
            "string"
          ]
        }
      ]
    },
    "type": "JSON",
    "properties": {
      "__alwaysAllowNull": "true"
    }
  }
}


Tap tactile tick box for message selection is too small in folder list

Android 4.4.2
HTC One M8
K9 5.007
In folder listing view.
When I want to select one message, the first message I want to select, I need to tap on the small box on left on line. For following messages, I can tap anywhere in the line, near the box, or not.
The issue is that I have to tap exactly in the middle of the tick box. If I tap just above, below, or left of the box, by a few pixels, the message will open, in the read view. The graphic of the tick box is fine, but the tactile space should not be exactly matching the graphics; the tactile zone should be larger than the graphics, and selection should start when I tap any place near the box; the tactile zone should be as large as the height of the message line (this height may vary with DPI). The graphic box is centered vertically; the tactile zone should spread over the full height of line, and at least as large as the height. But maybe, the tactilke zone should (maybe, debatable) go to the left edge.

You're right. But the checkboxes will be removed with the design overhaul.
Currently you can select a message in the list by swiping from left to right. Subsequent messages can be selected with a single tap.


Use Cases for Button and E2E Tests

Changelog

Added new use cases for button component
Added detox tests for these new use cases

Note : @anku255 can you run these tests and check if they all pass.

I have fixed the tests and they are all passing on iOS. Include this screenshot in your PR description -


Python 3.12 and numpy

Hi!
We might as well start thinking about python 3.12. I tried playing around with 3.12.03b for a bit and I don't think it is compatible with numpy <=0.24 (due to distutils being removed in 3.12) -- so I think it would be a good idea to think about bumping the recommended numpy version (which is at the moment pinned at <0.24).

I assume that you refer to numpy <= 1.24.
The version set for numpy was set to match the version of spb.
But agreed, support for 3.12 is a must going forward!

I am working on upgrading to SPB ~=2.4, which should be out in a release soon.
Wrt. quiver vs plot_vector, as noted here, the plot_vector only handles 2D or 3D vector fields. Because of this, the functionality behind quiver (plotting single vectors) is still needed and should be updated if needed.
However, as stated by @tuhe, Python 3.12 does not work currently because of distutils through numpy (tested in 3.12.0b4). It seems that updates will be coming, but I will be supporting 3.8-3.11 for now.

I just hacked a version of dtumathtools that works with 3.12 for the purposes of the Programming course. All I did was bump up everything to the latest version. I don't know how full your test coverage is, but apart from the plotting features, all the tests pass, so maybe it was an idea to split the package into two, separating the volatile GUI stuff out in a separate dtumathplot package?

We will first bump a new release in the coming semester. We don't want to push students into upgrading python, or have students running different versions of everything (it is tedious to debug since there may be additional unknowns).
But, this is great for the coming release.
Lastly, we will not split the package into two. The whole point is that the dtumathtools is a complete package for the students, with all necessary dependencies, including plotting facilities.

Agree with @zerothi in that this is "the one package that students need".
With respect to the test coverage, all functionality (lines of code) that was presented throughout the 21/22 demos for the course are being checked in the current tests.

Hi! For the spring semester, it would be ideal to support 3.12 in intro to programming since many will install it by default. Do you plan to update the version on pypi to lift the version pin (<= 0.24) on numpy, or is 3.12/numpy still causing issues with your other packages?

Yes! It would be ideal to support 3.12, and have an update out on pypi before the new semester! Think we just need to find versions that work (eg. like this). Will start off a branch with the spring semester to try to find package versions that work. Maybe @zerothi can note/remember what else we wanted for the spring semester (eg. version numbering 2024.1)

This has been fixed in #24, closing


SQL Client Upgrade from 5.1.1 to 5.1.2 or Later Causes Selenium Tests to Run Slower

Describe the bug
Our team has narrowed down the reason for our build timeouts to this newer version of SQL Client.
Below are images of tests with timestamps related to this package.
v5.1.1 - Before upgrading

v5.1.2 - After upgrading

After a second run of the same tests, the time looks so much better. Could there be something being cached?

To reproduce
This is how our test SQL Connections are constructed. We use Selenium for unit testing. Below shows the SqlConnectionStringBuilder:
		var sqlConnectionStringBuilder = new SqlConnectionStringBuilder
		{
			DataSource = ".",
			InitialCatalog = nameOfSccServer,
			Encrypt = true,
			MultipleActiveResultSets = false,
			PersistSecurityInfo = false,
			TrustServerCertificate = true,
			ConnectTimeout = 30
		};

Here are more timestamps taken using dotTrace. It's a tool that shows the call stack made during a test run along with time stamps.
Below shows the call DbConnectionPool.TryGetConnection is much slower in the newer package

Expected behavior
The time results from the second run is what would be expected.
Further technical details
Microsoft.Data.SqlClient version: (found on the nuget or Microsoft.Data.SqlClient.dll)
.NET target: net8.0
SQL Server version: SQL Server 15.0.2101.7
Operating system: Windows 11 Pro Version 22H2

Likely a dup of https://github.com/dotnet/efcore/issues/33399 (caused by #1983). The mitigation will probably be #2433.

Likely a dup of dotnet/efcore#33399 (caused by #1983). The mitigation will probably be #2433.

@roji, I am a bit confused. Do we need to revert #1983?

@JRahnama I don't think so, I'm not sure what @kf-gonzalez2's reasoning is...

Is it not a question of getting #2433 finished and approved?

The behavior change of #1983 was not intended in the 5.x line, particularly in the 5.1 backport. I consider it a breaking change. So the plan is to revert it in 5.x and bring it into 6.x where it will also include the connection override options to disable connection retries in order to maintain fast fail functionality.

Hotfix version 5.2.1 is released. Can you test with that version please?

Verified that the EF regression is fixed in 4.2.1.

@ajcvickers assume you mean 5.2.1 ?

It seems to have been fixed now. Thanks everyone!


[zingmp3] Update for new player url

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Bug fix
[ ] Improvement
[ ] New extractor
[ ] New feature

Zing MP3 changes their player so the IE stopped working. This PR fixes it.

Hello.

Help? @scw @JackDanger

What can we do to have this PR merged? 😭


cannot find package "github.com/go-ozzo/ozzo-validation/v4"

Hi,
I am trying to install the package and getting error when i run the following command
go get github.com/go-ozzo/ozzo-validation/v4
ERROR
Lucians-MacBook-Pro:jeoga_go khanakia$ go get github.com/go-ozzo/ozzo-validation/v4
package github.com/go-ozzo/ozzo-validation/v4: cannot find package "github.com/go-ozzo/ozzo-validation/v4" in any of:
	/usr/local/Cellar/go/1.14.2_1/libexec/src/github.com/go-ozzo/ozzo-validation/v4 (from $GOROOT)
	/Volumes/D/www/go/src/github.com/go-ozzo/ozzo-validation/v4 (from $GOPATH)
	/Volumes/D/www/go/src/github.com/khanakia/go_code/jeoga_go/src/github.com/go-ozzo/ozzo-validation/v4
Lucians-MacBook-Pro:jeoga_go khanakia$

Thanks for reporting the issue! I have fixed the README. go get github.com/go-ozzo/ozzo-validation should be fine.

@qiangxue
There is one more issue when installing the go get github.com/go-ozzo/ozzo-validation
It is not installing the pkg dependecy github.com/asaskevich/govalidator because of which validation giving error.
So how to auto install the pkg depedency ?

Actually the instruction on using go get to install packages is a bit outdated. If you use go mod, it will help you automatically install all needed dependencies.

@qiangxue I do not understand can you point me the exact commands please it will be helpful. Thanks

https://blog.golang.org/using-go-modules

I have checked that article already. I am not talking about building modules.
I am talking about ozzo-validation which requires govalidator as dependency. So when i do go get github.com/go-ozzo/ozzo-validation it does not installs the govalidator automatically.

If you are using go modules, then you don't need to explicitly "go get" the dependent modules as they will be automatically retrieved when you build your project.

But what about using the ozzo-validation in normal project where i do not have modules. So will i have to install the govalidator manually always ?
github.com/asaskevich/govalidator

I was talking about normal projects that have dependent modules such as ozzo-validation. If you use "go mod" to manage the dependent modules, you don't need to manually install the dependent modules.

I am getting an error while using go mod command please check the below error
Lucians-MacBook-Pro:jeoga_go khanakia$ go mod download github.com/go-ozzo/ozzo-validation
module github.com/go-ozzo/ozzo-validation: not a known dependency

That's not a right way of using go mod. Please check the blog article above in detail.

I understand I will read the article in more detail. Thanks :)


Support CopyTo::partition_by in datafusion proto

Which issue does this PR close?
Closes #9248
Rationale for this change
Support serialization/deserialization CopyTo::partition_by in datafusion proto
What changes are included in this PR?
Code, tests
Are these changes tested?
Yes
Are there any user-facing changes?

Thanks @PhVHoang


Add did:ethr and EIP-712-based linked data proof type

Based on: #94
Implements did:ethr. There are some some differences compared to the did:ethr spec, due to updates to DID Core and using EcdsaSecp256k1RecoveryMethod2020, as mentioned in https://github.com/decentralized-identity/ethr-did-resolver/issues/99; and to add a second verification method using a new experimental linked data proof type based on EIP-712.
The linked data proof type based on EIP-712 is named Eip712Method2021. The signing payload includes the URDNA2015-canonicalized linked data document (credential) and options (proof) rendered as an array of RDF statements where each statement (quad/triple) is an array of 3 or 4 strings.
Eip712Method2021 is not yet fully implemented here as the EIP-712 hashing is incomplete. So it can only be used via external signing, and does not yet have verification working.

Hi, is this ready for review? The CI seems to have failed--but also we have just merged in #94.

@wyc ready for review. I just pushed a fixup commit to try to fix the CI failure.

Rebased.


Slicing LEDBoard

It seems the LEDBoard .leds property is now a generator, rather than a list. Great for iterating over but I have to cast it to a list to be able to slice it:
from gpiozero import PiLiter

lite = PiLiter()

for led in list(lite.leds)[::2]:
    led.on()

Is there a better way?

Hmmm, given that neither CompositeDevices nor CompositeOutputDevices (and therefore LEDBoards) can have subordinate devices added or removed (or changed) post-construction, I guess there's no reason that the list-of-leds couldn't be generated just once during construction, stored as a tuple, and then returned from the leds property? @waveform80 ?
@bennuttall Another way of doing what you're doing above would be:
from gpiozero import PiLiter

lite = PiLiter()

lite.on(0, 2, 4, 6)

Or the last line could be replaced with lite.on(*range(len(lite))[::2]) if you wanted to make it more generic.
Or given that PiLiter doesn't contain any LEDCollection sub-instances (unlike SnowPi, which does), you could probably do:
from gpiozero import PiLiter

lite = PiLiter()

for led in lite[::2]:
    led.on()

Yeah, with could just construct it as a tuple after the super call in LEDCollection.__init__ then serve it as a static property

That's really cool, I had no idea these composite devices worked as iterators. That's much neater than accessing via lite.leds.
I'm pleased about #338 but the object itself being an iterator is much handier.

So which composite devices work like this, and which don't?

They all do.  Your example isn't working for me on v1.2 (but works on master). I can create an LED object on MockPin(2) but can't create a PiLiter() by specifying gpiozero.devices.pin_factory = MockPin. Guess that got fixed since the release.

Yeah, before master pin_factory is DefaultPin (the name change is to make clear things like construction of remote pins by default with a function or lambda). The change to make composite devices into sequences was ... erm 1.2 I think? Can't remember off the top of my head but it's in the base class so yeah, it applies to everything.
Finally coming to a close on picamera 1.11 btw, so I'll start looking at the servo stuff next week with a bit of luck!

Great!


fix: Applies RFC 5336 and 4343 for emails that do not have specific rules

Some mail providers are case sensitive. So the default rule cannot be lowercase ;-)


Replace Color diagnostic mode with Albedo

Hi,
This is my attempt to make Albedo diagnostic override. I just copied compute_light call from physical shader. Looks like it's working but it takes longer than other diagnostic modes.

Hi @est77 ,
I took version with BSDFSample from case RaySpread:. It seems working but I'm not sure if we need to keep two break conditions. I just don't know what are they checking.
One is this:
if (!ray.m_has_differentials)
   break;

And other one is this:
if (!sample.m_incoming.has_derivatives())
   break;

The RaySpread mode tries to visualize the size of the ray differentials.
The checks are there to test if the differentials exists or not.
You don't need the checks for the albedo mode.


Finally implement mkv support

matroska/mkv output is desirable for some devices. There's a provision for it in the config, but several files assume mp4 output. Allow that to be configured.

Implemented and tested. Seems to work as expected. Shouldn't even need to wait for queues to drain as task format wasn't changed. Workers will need rolling updates though.


yarn build: ReferenceError: window is not defined

Change
"@vuepress/plugin-google-analytics": "^1.0.0-alpha.0",
=>
"@vuepress/plugin-google-analytics": "^1.0.0-alpha.0.32",


Asks to display results in pager without results

Seems pretty unintuitive to show the results when there are none, and gives another step to get back to searching.

Thanks for pointing this out! You're absolutely right, that is pretty unintuitive. Should be pretty easy to fix though.


tailwind

add html and css and tailwind

Files that were overloading the program were removed, and the system now can open the CSS file with no problem, reviewed and merged to the main branch.


HTTP Request body DFG in Python

Add DFG edge from HTTP endpoint to Python VariableDeclaration that is initialized with the request body
Update to Kotlin 1.6

Add DFG edge from HTTP endpoint to Python VariableDeclaration that is initialized with the request body
Update to Kotlin 1.6

I have adjusted this to look for the member call request.json instead of a variable declaration and then set the DFG target according to the target of this call expression.


Text coordinates seems mixed up

I'm running the text command with --output-type json --json-output-details full to get hold of the coordinates for the text in my PDF. It seems to me that the coordinates in the resulting JSON is mixed up
  {
    "Text": "PLAN 10-12, ÖVERSIKT",
    "PointPosition": {
      "Left": 1544.311767578125,  //actualy Top
      "Top": 2186.447021484375, //actually Right
      "Right": 1559.35302734375, //actually Bottom
      "Bottom": 2050.65478515625  //actually Left
    }
}

When the mixup is sorted out, I'm still wondering how accurate I can assume the coordinates to be. Should they be spot on, or are the values approximate?
The blue rectangle is drawn with the corrected coordinates (commented as "actually" above). I'm guessing that the last T is cut off due to the italic font?

I don't write Go at all, but I had a look to see if I could spot any mixup. I see that getRect and getCharBox in go-pdfium has different call signatures, i.e. the order of left, top, rigth, bottom differs. Maybe this has to do with the mixup?
https://github.com/klippa-app/go-pdfium/blob/cb317c4f8e1d175c1a736dabd2ff4d9c0a4ec615/internal/implementation_cgo/fpdf_text.go#L137C1-L137C1
https://github.com/klippa-app/go-pdfium/blob/cb317c4f8e1d175c1a736dabd2ff4d9c0a4ec615/internal/implementation_cgo/fpdf_text.go#L262
Also, when I tested to apply the output and adjust for the mixup, it seems as the origin is at the top-left. But the pdfium docs states that the output is in "pdf user space", i.e. origin is bottom-left. I couldn't find the code where this transformation takes place in go-pdfium. I'm a bit lost. Maybe I have just misunderstood the output? How should I interprete the output coordinates?

Oh, I understand now.
The corrdinates are actually "pdf user space". But this space has to be rotated if the PDF page is rotated, which it is in my case.
I don't think I can get hold of the rotation from pdfium-cli. I tried the info command, but there is not information about rotation.
It feels as I'm in a dead end here. I think this has to be solved from within pdfium-cli or go-pdfium. Otherwise I would need to get hold of the page rotation.

@jerbob92 Is there anything I can help with to go further with this. Until this is solved I cannot use pdfium-cli for text extraction, so I have to "resort" to Poppler's pdfToText.
I can rotate the coordinate system myself, but I need the rotation in order to do this. Is the page rotation easily available in pdfium? Maybe it´s just a matter of adding the rotation to the output from pdfium text?
N.B, the rotation can differ between pages, so this output is needed for each page.

I'm not sure if this helps, but I found the following in the pdfium C library.
fpdf_edit.h
// Get the rotation of |page|.
//
//   page - handle to a page
//
// Returns one of the following indicating the page rotation:
//   0 - No rotation.
//   1 - Rotated 90 degrees clockwise.
//   2 - Rotated 180 degrees clockwise.
//   3 - Rotated 270 degrees clockwise.
DLLEXPORT int STDCALL FPDFPage_GetRotation(FPDF_PAGE page);

Yes, this is perfect.
With the rotation I can rotate the coordinate system and actually have use for the coordinates from the text command.


microchip xec: Introduce I2c slave support

This patchset introduces i2c_slave support for microchip i2c driver

I'm not sure this code is following section <IP_ADDRESS> Table 5-4 Re-enabling the Slave Receiver in the spec.  If the slave receiver is not being re-enabled after a STOP was issued then that could account for AAS not being set when the external master starts another transaction.  You could try writing 0xC1 to control per Table 5-4 in our wait_for_bus_idle routine just before it returns 0(success).

@scottwcpg are you referring to functions wait_bus_free() and/or wait_completion()? These are called only when the i2c controller is a Master (polling mode). When the i2c controller is configured as a slave, almost everything happens under i2c_xec_bus_isr() in the interrupt context. Also, the configuration you are talking about is already a part of restart_slave() function which gets called whenever the i2c controller is configured as a slave.

@rgundi I'm interpreting the MCHP spec. section <IP_ADDRESS> as required whenever a STOP is generated by the controller in Master mode or by an external controller issuing a STOP.  With respect to seeing data that's not there, if you read the I2C Data contains what ever is on the bus when clocks are present (generated by the controller in master mode) or from the external master.  If AAS is not set the I2C Data register will have something in it and it is not surprising the value is the address. The problem appears to be the controller is not ACK'ing its slave address.  This is why I believe section <IP_ADDRESS> in the spec. applies.  If the CONTROL register does not have the ACK bit (bit 0) set then it will not ACK a matching slave address.  Also, do you have the idle interrupt enabled (bit 29) in the CONFIG register? I don't recommend enabling the idle interrupt because the controller will fire the interrupt every time it's idle resulting in an interrupt when you may not want one.

@pabigot #28837 is very much valid. It's just that i wasn't sure how to push the rest of this patch for review while #28837 was under review. I thought that review would get approved faster and i could simply rebase this patch while i was addressing the review comments. I will take out this commit once #28837 gets merged.
I will modify the first commit making it explicit that it applies only to this driver.
I haven't verified this with tests/drivers/i2c/i2c_slave_api. But, it is part of an application (not open sourced) and i can confirm it is working there.

I haven't verified this with tests/drivers/i2c/i2c_slave_api. But, it is part of an application (not open sourced) and i can confirm it is working there.

That's fine, but unless this is a private SOC that nobody else can ever use, it should be verified with the in-tree test as well.

I haven't verified this with tests/drivers/i2c/i2c_slave_api. But, it is part of an application (not open sourced) and i can confirm it is working there.

That's fine, but unless this is a private SOC that nobody else can ever use, it should be verified with the in-tree test as well.

Oh. This is definitely NOT a private SoC nobody is going to use. I can confirm the SoC contains multiple I2C ports. I read the README.txt and i see that SCL and SDA on one port need to be shorted to the corresponding ones on the other. Also, i guess i may need an overlay for the specific board i am using. May i know what else is required?

i see that SCL and SDA on one port need to be shorted to the corresponding ones on the other. Also, i guess i may need an overlay for the specific board i am using. May i know what else is required?

That should be all that's necessary.  Use the existing overlays as a model.

#28837 is merged and i have rebased this. Also, have modified the commit messages as per suggestion by @pabigot.

AFAICT the changes in 947db1afc5 "drivers: i2c_mchp_xec: fix build errors when slave mode is disabled" are fixing problems introduced in earlier commits in the PR. Please integrate the changes into those commits.
Done
Also please confirm the test passes on the hardware (it's not one I can independently verify).
This is Work in progress. Will keep you posted.

AFAICT the changes in 947db1afc5 "drivers: i2c_mchp_xec: fix build errors when slave mode is disabled" are fixing problems introduced in earlier commits in the PR. Please integrate the changes into those commits.
Done
Also please confirm the test passes on the hardware (it's not one I can independently verify).
This is Work in progress. Will keep you posted.

This is Work in progress. Will keep you posted.

OK.
Please also re-order the commits so the binding update for GIRQ flags is before the driver update that requires those properties.

This is Work in progress. Will keep you posted.

OK.
Please also re-order the commits so the binding update for GIRQ flags is before the driver update that requires those properties.

Please also re-order the commits so the binding update for GIRQ flags is before the driver update that requires those properties.
Done. Also squashed relevant commits to have only 3 now.

Please also re-order the commits so the binding update for GIRQ flags is before the driver update that requires those properties.
Done. Also squashed relevant commits to have only 3 now.

Looks reasonable, just waiting on confirmation the test passes https://github.com/zephyrproject-rtos/zephyr/pull/29475#issuecomment-753926363

Looks reasonable, just waiting on confirmation the test passes https://github.com/zephyrproject-rtos/zephyr/pull/29475#issuecomment-753926363

Test program fails.
*** Booting Zephyr OS build zephyr-v2.4.0-3006-g72998f07e6b1  ***
Running test suite test_eeprom_slave
START - test_eeprom_slave
I: Found EP0 EEPROM_0 on I2C Master device I2C0 at addr 54
I: Found EP1 EEPROM_1 on I2C Master device I2C1 at addr 56
I: EEPROM EEPROM_0 Attached !
I: EEPROM EEPROM_1 Attached !
I: Start full read. Master: I2C1, address: 0x54
E: Device is registered as slave
Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/i2c/i2c_slave_api/src/main.c:60: run_full_read: (ret not equal to 0)

Failed to read EEPROM
FAIL - test_eeprom_slave
Test suite test_eeprom_slave failed.
PROJECT EXECUTION FAILED
I looked at the registers for I2C contoller's 0 and 1 and the port is set for 4 and 5 respectively.  I thought the test used ports 0 and 1?  The boards/arm/mec1501_modular DTS file has port_sel 0 and 1 for controllers 0 and 1 respectively.

Test program fails.
*** Booting Zephyr OS build zephyr-v2.4.0-3006-g72998f07e6b1  ***
Running test suite test_eeprom_slave
START - test_eeprom_slave
I: Found EP0 EEPROM_0 on I2C Master device I2C0 at addr 54
I: Found EP1 EEPROM_1 on I2C Master device I2C1 at addr 56
I: EEPROM EEPROM_0 Attached !
I: EEPROM EEPROM_1 Attached !
I: Start full read. Master: I2C1, address: 0x54
E: Device is registered as slave
Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/i2c/i2c_slave_api/src/main.c:60: run_full_read: (ret not equal to 0)

Failed to read EEPROM
FAIL - test_eeprom_slave
Test suite test_eeprom_slave failed.
PROJECT EXECUTION FAILED
I looked at the registers for I2C contoller's 0 and 1 and the port is set for 4 and 5 respectively.  I thought the test used ports 0 and 1?  The boards/arm/mec1501_modular DTS file has port_sel 0 and 1 for controllers 0 and 1 respectively.

More debug. In my EVB test setup I have a non-Zephyr firmware in SPI flash loaded by MEC152x Boot-ROM. This firmware (chromiumos EC code) uses I2C controller's 0 and 1.  If I download the Zephyr slave I2C test via JTAG and run it I observed the I2C controller's are not reset and re-configured.  Putting a break point on i2c_xec_configure shows it is never called.  The first I2C transaction the test does is:
device_get_binding
i2c_slave_driver_register - This calls the driver and the slave address is programmed but this API assumes the driver has previously configured the controller which is not true in this case.
i2c_burst_read - Calls driver i2c_write_read which sets up a call to driver i2c_transfer which assumes the driver has  previously configured the controller.

Does the driver need logic to detect it has not been configured and force a configure call similar to the SPI drivers?

More debug. In my EVB test setup I have a non-Zephyr firmware in SPI flash loaded by MEC152x Boot-ROM. This firmware (chromiumos EC code) uses I2C controller's 0 and 1.  If I download the Zephyr slave I2C test via JTAG and run it I observed the I2C controller's are not reset and re-configured.  Putting a break point on i2c_xec_configure shows it is never called.  The first I2C transaction the test does is:
device_get_binding
i2c_slave_driver_register - This calls the driver and the slave address is programmed but this API assumes the driver has previously configured the controller which is not true in this case.
i2c_burst_read - Calls driver i2c_write_read which sets up a call to driver i2c_transfer which assumes the driver has  previously configured the controller.

Does the driver need logic to detect it has not been configured and force a configure call similar to the SPI drivers?

@pabigot Could you please comment on Scott's findings?
@scottwcpg Are you running this on mec1501modular_assy6885 or did you make modifications to run this on an EVB?

@pabigot Could you please comment on Scott's findings?
@scottwcpg Are you running this on mec1501modular_assy6885 or did you make modifications to run this on an EVB?

@pabigot Could you please comment on Scott's findings?

The test overlay looks right, so I suspect Scott's hypothesis is correct that it's a driver bug.

@pabigot Could you please comment on Scott's findings?

The test overlay looks right, so I suspect Scott's hypothesis is correct that it's a driver bug.

@pabigot Could you please comment on Scott's findings?

The test overlay looks right, so I suspect Scott's hypothesis is correct that it's a driver bug.

I had a relook at this driver as well as several other i2c drivers in the repo. Some noteworthy points below.

Most i2c drivers have the bus speed hardcoded at build time (via DTS). Some i2c drivers like mchp, esp32, npc etc have it configurable in runtime. There seems to be no uniformity in this.
Currently only i2c_ll_stm32.c supports i2c slave. I see that i2c_stm32_init has a call to i2c_stm32_runtime_configure. Not sure if that’s the right thing to do as some i2c drivers (refer point 1 above) may have configurable i2c frequency values.
In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

@pabigot @scottwcpg your comments please.

@pabigot Could you please comment on Scott's findings?

The test overlay looks right, so I suspect Scott's hypothesis is correct that it's a driver bug.

I had a relook at this driver as well as several other i2c drivers in the repo. Some noteworthy points below.

Most i2c drivers have the bus speed hardcoded at build time (via DTS). Some i2c drivers like mchp, esp32, npc etc have it configurable in runtime. There seems to be no uniformity in this.
Currently only i2c_ll_stm32.c supports i2c slave. I see that i2c_stm32_init has a call to i2c_stm32_runtime_configure. Not sure if that’s the right thing to do as some i2c drivers (refer point 1 above) may have configurable i2c frequency values.
In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

@pabigot @scottwcpg your comments please.

Most i2c drivers have the bus speed hardcoded at build time (via DTS). Some i2c drivers like mchp, esp32, npc etc have it configurable in runtime. There seems to be no uniformity in this.

It's probably due to following Linux where this is a controller property that can be defaulted from devicetree, but changed at runtime if necessary.

Currently only i2c_ll_stm32.c supports i2c slave. I see that i2c_stm32_init has a call to i2c_stm32_runtime_configure. Not sure if that’s the right thing to do as some i2c drivers (refer point 1 above) may have configurable i2c frequency values.

I suspect it's justifiable given 1.

In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

Yes, please try that.

Most i2c drivers have the bus speed hardcoded at build time (via DTS). Some i2c drivers like mchp, esp32, npc etc have it configurable in runtime. There seems to be no uniformity in this.

It's probably due to following Linux where this is a controller property that can be defaulted from devicetree, but changed at runtime if necessary.

Currently only i2c_ll_stm32.c supports i2c slave. I see that i2c_stm32_init has a call to i2c_stm32_runtime_configure. Not sure if that’s the right thing to do as some i2c drivers (refer point 1 above) may have configurable i2c frequency values.

I suspect it's justifiable given 1.

In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

Yes, please try that.

In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

Yes, please try that.

Done. @scottwcpg Please run the test with the updated changes.

In light of point 2, we can add a line to i2c_xec_init() invoking the function i2c_xec_configure() with speed set to I2C_SPEED_STANDARD. It should be alright since this is something that is already being done in i2c_nios2.c.

Yes, please try that.

Done. @scottwcpg Please run the test with the updated changes.

Tried the latest code.  Test fails on first call to driver from test function run_full_speed calling i2c_burst_read.
The call into driver i2c_xec_transfer return -EBUSY from the if (data->slave_attached) statement line 434. Test code is trying to read I2C address 0x54 which is the registered slave address of I2C controller 0.  What is interesting is the device pointer appears to be correct: name="I2C1".  The if logic is checking struct i2c_slave_config.slave_attached flag.  I thought it should check if the addr parameter passed to i2c_xec_transfer matches one of the two slave addresses programmed into the current controller.  The test program is passing address 0x54 and I2C1 has slave address 0x56 so it's OK for I2C1 to communicate with 0x54.  NOTE: These I2C controllers can have two slave addresses (bits[7:0] and bits[15:8]) of the controller own address register.  The driver is currently only using one slave address (bits[7:0]).

Tried the latest code.  Test fails on first call to driver from test function run_full_speed calling i2c_burst_read.
The call into driver i2c_xec_transfer return -EBUSY from the if (data->slave_attached) statement line 434. Test code is trying to read I2C address 0x54 which is the registered slave address of I2C controller 0.  What is interesting is the device pointer appears to be correct: name="I2C1".  The if logic is checking struct i2c_slave_config.slave_attached flag.  I thought it should check if the addr parameter passed to i2c_xec_transfer matches one of the two slave addresses programmed into the current controller.  The test program is passing address 0x54 and I2C1 has slave address 0x56 so it's OK for I2C1 to communicate with 0x54.  NOTE: These I2C controllers can have two slave addresses (bits[7:0] and bits[15:8]) of the controller own address register.  The driver is currently only using one slave address (bits[7:0]).

Tried the latest code. Test fails on first call to driver from test function run_full_speed calling i2c_burst_read.
The call into driver i2c_xec_transfer return -EBUSY from the if (data->slave_attached) statement line 434. Test code is trying to read I2C address 0x54 which is the registered slave address of I2C controller 0. What is interesting is the device pointer appears to be correct: name="I2C1". The if logic is checking struct i2c_slave_config.slave_attached flag. I thought it should check if the addr parameter passed to i2c_xec_transfer matches one of the two slave addresses programmed into the current controller. The test program is passing address 0x54 and I2C1 has slave address 0x56 so it's OK for I2C1 to communicate with 0x54. NOTE: These I2C controllers can have two slave addresses (bits[7:0] and bits[15:8]) of the controller own address register. The driver is currently only using one slave address (bits[7:0]).

The intention of "if (data->slave_attached)" is to ensure i2c_xec_transfer() is never executed while it is configured as a slave. The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

Tried the latest code. Test fails on first call to driver from test function run_full_speed calling i2c_burst_read.
The call into driver i2c_xec_transfer return -EBUSY from the if (data->slave_attached) statement line 434. Test code is trying to read I2C address 0x54 which is the registered slave address of I2C controller 0. What is interesting is the device pointer appears to be correct: name="I2C1". The if logic is checking struct i2c_slave_config.slave_attached flag. I thought it should check if the addr parameter passed to i2c_xec_transfer matches one of the two slave addresses programmed into the current controller. The test program is passing address 0x54 and I2C1 has slave address 0x56 so it's OK for I2C1 to communicate with 0x54. NOTE: These I2C controllers can have two slave addresses (bits[7:0] and bits[15:8]) of the controller own address register. The driver is currently only using one slave address (bits[7:0]).

The intention of "if (data->slave_attached)" is to ensure i2c_xec_transfer() is never executed while it is configured as a slave. The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

Even on two separate controllers?

The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

Even on two separate controllers?

I guess if the MEC device can't support the test the options are to fix the test, add a separate board-specific test, or merge this without the ability to verify it continues to work as Zephyr evolves.  The last option doesn't seem like a good plan.  I would think fixing the test and/or driver so they work together should be possible, but without access to hardware I can't say how to make it happen.

I guess if the MEC device can't support the test the options are to fix the test, add a separate board-specific test, or merge this without the ability to verify it continues to work as Zephyr evolves.  The last option doesn't seem like a good plan.  I would think fixing the test and/or driver so they work together should be possible, but without access to hardware I can't say how to make it happen.

The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

Even on two separate controllers?

Yes. The problem is i2c_slave_driver_register() is being called for both the controllers right at the beginning of the test. This is putting both the controllers into slave mode. So, the xec driver cannot function as a master. It will be interesting to see what happens if the test is modified to call i2c_slave_driver_register() only on the controller which needs to be the slave.

The design that we have right now will simply not work for this test. It currently doesn't support simultaneous master and slave.

Even on two separate controllers?

Yes. The problem is i2c_slave_driver_register() is being called for both the controllers right at the beginning of the test. This is putting both the controllers into slave mode. So, the xec driver cannot function as a master. It will be interesting to see what happens if the test is modified to call i2c_slave_driver_register() only on the controller which needs to be the slave.

I hacked the test to register/unregister the follower based upon test flow.  Attached archive containing the test main.c and UART capture from my MEC152x EVB.  NOTE: I'm building using board mec1501modular_assy6885 since that's what the test is configured for.  The EVB has jumpers to connect I2C0 and I2C1 pins.
xec_i2c_slave_api_test_mod_results.zip

I hacked the test to register/unregister the follower based upon test flow.  Attached archive containing the test main.c and UART capture from my MEC152x EVB.  NOTE: I'm building using board mec1501modular_assy6885 since that's what the test is configured for.  The EVB has jumpers to connect I2C0 and I2C1 pins.
xec_i2c_slave_api_test_mod_results.zip

Since the test incorrectly assumes the controllers support both roles without configuration, I'm modifying it to have that be controllable.  I'll have a PR or commit for that shortly for testing.

Since the test incorrectly assumes the controllers support both roles without configuration, I'm modifying it to have that be controllable.  I'll have a PR or commit for that shortly for testing.

@scottwcpg Could you please grab #31458 and see whether the driver passes now?  Dual-mode is not on by default, it's only enabled for automated testing on ST devices.  Thanks.

@scottwcpg Could you please grab #31458 and see whether the driver passes now?  Dual-mode is not on by default, it's only enabled for automated testing on ST devices.  Thanks.

Hi @pabigot
Thanks! It works.
I applied PR31458 on top of PR29475.  Attached a zip of the UART capture.
uart1_cap01.zip

Hi @pabigot
Thanks! It works.
I applied PR31458 on top of PR29475.  Attached a zip of the UART capture.
uart1_cap01.zip

Thanks @pabigot and @scottwcpg . This can hopefully be merged now. Right in time before the window closes. @franciscomunoz @albertofloyd @nashif, please review.

Thanks @pabigot and @scottwcpg . This can hopefully be merged now. Right in time before the window closes. @franciscomunoz @albertofloyd @nashif, please review.


[BUGFIX] - add missing fields

No related tasks.
Changes
added missing fields in /community/{id}/managers
New

Tests

@obernardovieira createdAt added from the manager's table.
when this change is in production, I will ask @psoaresbj to use the createdAt from the manager level instead of the user


Add support for creating, altering, and dropping indices

Right now, creating indices is only being done automatically from the CREATE TABLE statements. This pull request aims to change that and allow adding indices to existing tables.

Optional support for ALTER INDEX (maybe configurable?)

Parser changes:

[x] Support for functional indices: is_functional flag in key_dic
[x] Support for partial indices: is_partial flag in key_dic
[x] Support for fulltext or spatial indices: is_fulltext or is_partial flag in key_dic
[x] Support for detecting index type: index_type in key_dic as either BTREE or HASH.
[x] Support CREATE INDEX
[x] Support ALTER TABLE ADD INDEX
[x] Support ALTER TABLE RENAME INDEX
[x] Support ALTER TABLE DROP INDEX
[x] Support DROP INDEX

Open questions

What should the default for index_type be? I'm setting it to None for now.

@the4thdoctor I accidentally carried over an older change in the pg_lib.py module, but it's relevant here because it adds support for CREATE INDEX statement to pg_engine.
Can you take a look at it and let me know if it's okay to be kept in?

Support for CREATE INDEX and ALTER TABLE ... ADD INDEX is added.
One open issue there is that the index_name is not being captured in the case of ALTER TABLE ... ADD INDEX.
That's because by default, even when parsing indices in CREATE TABLE, the index name is not captured and the index_name key instead tells about the kind of index it is: e.g. PRIMARY, UNIQUE, OTHER, INDEX, etc.

@the4thdoctor we had discussed the ordering for subcommands in alter table statements, that additions of columns should come before additions of indices, and removing indices should come before removing columns. But that would have some edge cases, e.g.
ALTER TABLE table_name
    DROP COLUMN column1,
    RENAME COLUMN column2 TO column1,
    ADD COLUMN column2 VARCHAR(50);

If we change the order here and add column2 first, that will throw an error because it already exists.
Can we use the same order in which the commands appeared in the MySQL query? That should already be accurate, I think.

@the4thdoctor we had discussed the ordering for subcommands in alter table statements, that additions of columns should come before additions of indices, and removing indices should come before removing columns. But that would have some edge cases, e.g.
ALTER TABLE table_name
    DROP COLUMN column1,
    RENAME COLUMN column2 TO column1,
    ADD COLUMN column2 VARCHAR(50);

If we change the order here and add column2 first, that will throw an error because it already exists.
Can we use the same order in which the commands appeared in the MySQL query? That should already be accurate, I think.

If you can manage easily this particular case please go for it. Thanks.

This is already taken care of. We use the same order as the MySQL commands we receive.

Thanks  and sorry for bein MIA for a while.
I'll test today or tomorrow then I'll merge the PR and will make a long overdue release with your contribution.

Apologies for the long delay, I've checked the PR and the previous tests are running fine.
I'm merging it.
Ta!


Update docs to include more information on how models can be updated

We should include some examples here of how people might mutate models. It depends on the modeling solution, but may help put things in context.
https://linkedin.github.io/RocketData/pages/080_updatingModels.html

https://linkedin.github.io/RocketData/pages/080_updatingModels.html#how-are-models-actually-updated
#23


podman inspect : docker compatibility

Some headscratching today led to a quick script comparing the output of podman inspect against docker. Results:
Only in docker:
   .Config.OnBuild
   .GraphDriver.Data.DeviceId
   .GraphDriver.Data.DeviceName
   .GraphDriver.Data.DeviceSize
   .HostConfig.Binds
   .HostConfig.CpuShares                 <--- podman calls it CPUSShares, note extra 'S'
   .HostConfig.Links
   .HostConfig.LogConfig.Config
   .HostConfig.LogConfig.Type
   .HostConfig.RestartPolicy
   .HostConfig.VolumeDriver
   .HostConfig.VolumesFrom
   .NetworkSettings.GlobalIPv6Address    <--- podman calls it '...Addresses', plural; also, podman value is array
   .NetworkSettings.Networks
Case mismatch between docker and (podman):
   .HostConfig.CpuCount (CPUCount)
   .HostConfig.CpuPercent (CPUPercent)
   .HostConfig.CpuPeriod (CPUPeriod)
   .HostConfig.CpuQuota (CPUQuota)
   .HostConfig.CpuRealtimePeriod (CPURealtimePeriod)
   .HostConfig.CpuRealtimeRuntime (CPURealtimeRuntime)
   .HostConfig.CpusetCpus (CPUSetCPUs)
   .HostConfig.CpusetMems (CPUSetMems)
   .HostConfig.Dns (DNS)
   .HostConfig.DnsOptions (DNSOptions)
   .HostConfig.DnsSearch (DNSSearch)
   .HostConfig.NanoCpus (NanoCPUs)
   .Id (ID)
Type difference between docker and (podman):
   .Config.User : scalar (hash)
   .ExecIDs : scalar (array)
   .HostConfig.CapAdd : scalar (array)
   .HostConfig.CapDrop : scalar (array)
   .HostConfig.ConsoleSize : array (scalar)
   .HostConfig.Devices : array (scalar)
   .HostConfig.SecurityOpt : scalar (array)
   .HostConfig.Ulimits : scalar (array)
   .NetworkSettings.Ports : scalar (array)

I don't know if any of these are important or worth fixing; although I think maybe at least the extra 'S' in CPUSShares deserves a fix or explanation.

CPUSShares sounds like a typo.
The IPv6 address/addresses reflects us potentially having multiple IPs in a single container (well, we don't have ANY IPv6 stuff right now, but CNI theoretically can do more than one).
The case changes were all deliberate to stop linter warnings IIRC. We can swap them back and nolint if we want to fix.
I don't know why Docker has ports, CapAdd/CapDrop, security-opt, and similar as scalars. IMO the way we're doing things makes a lot more sense in these cases.

If ours make sense, then stick with it, Fix spelling issue though. Only reason this could potentially cause issues would be if someone used a --format command, but I willing to live with the risk if our change is justifiable.


JSX parser unexpected token ">="

When a = is immediately preceded by a JSX "tag" it is interpreted as a single token rather than separate tokens. I'm seeing this issue on React.NET v1.4.0 while using JsxBundle() to bundle my JSX.
Repro JSX code
var Test = React.createClass({
	render: function() {
		return <i>=</i>;
	}
});

Working example (using in browser JSXTransformer.js) http://jsfiddle.net/a1k1mhge/

This looks like a bug with React 0.12, I can replicate the same issue on JSFiddle if I switch to using JSXTransformer 0.12: http://jsfiddle.net/a1k1mhge/1/. Please try upgrading to ReactJS.NET 1.5, as it upgrades React from 0.12 to 0.13 and should resolve this issue.
Thanks!


Crash when start owner on Cloud host.

ENV:  Alibaba ECS cloud   ubuntu 18.04
Command:   sudo crust logs chain
logs:
sudo crust logs chain
2021-04-04 02:32:53  Crust
2021-04-04 02:32:53  ✌  version 0.11.1-4c3dc21-x86_64-linux-gnu
2021-04-04 02:32:53  ❤  by crustio, 2019-2021
2021-04-04 02:32:53  📋 Chain specification: Crust Maxwell
2021-04-04 02:32:53  🏷 Node name: jxowner
2021-04-04 02:32:53  👤 Role: AUTHORITY
2021-04-04 02:32:53  💾 Database: RocksDb at /opt/crust/data/chain/chains/crumwl/db
2021-04-04 02:32:53  ⛓  Native runtime: crust-1 (crustio-crust-1.tx1.au1)
2021-04-04 02:32:53  🔨 Initializing Genesis block/state (state: 0xd605…389e, header-hash: 0xb19e…d41f)
2021-04-04 02:32:53  👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
====================
Version: 0.11.1-4c3dc21-x86_64-linux-gnu
0: sp_panic_handler::set::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panicking.rs:595:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panicking.rs:495:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/sys_common/backtrace.rs:141:18
4: rust_begin_unwind
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panicking.rs:493:5
5: core::panicking::panic_fmt
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/core/src/panicking.rs:92:14
6: core::panicking::panic
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/core/src/panicking.rs:50:5
7: raw_cpuid::CpuId::get_extended_feature_info
8: cranelift_native::builder
9: wasmtime_jit::native::builder
10: wasmtime::runtime::Config::new
11: sc_executor_wasmtime::runtime::create_runtime
12: sc_executor::wasm_runtime::create_wasm_runtime_with_code
13: sc_executor::wasm_runtime::create_versioned_wasm_runtime
14: sc_executor::wasm_runtime::RuntimeCache::with_instance
15: <sc_executor::native_executor::NativeExecutor as sp_core::traits::CodeExecutor>::call
16: sp_state_machine::execution::StateMachine<B,H,N,Exec>::execute_aux
17: sp_state_machine::execution::StateMachine<B,H,N,Exec>::execute_using_consensus_failure_handler
18: <sc_service::client::call_executor::LocalCallExecutor<B,E> as sc_client_api::call_executor::CallExecutor>::call
19: <alloc::sync::Arc<dyn sc_client_api::call_executor::ExecutorProvider+Executor = E> as sc_finality_grandpa::GenesisAuthoritySetProvider>::get
20: sc_finality_grandpa::aux_schema::load_persistent
21: crust::service::new_partial
22: crust::service::new_full
23: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
24: std::thread::local::LocalKey::with
25: tokio::runtime::thread_pool::ThreadPool::block_on
26: tokio::runtime::context::enter
27: sc_cli::runner::Runner::run_node_until_exit
28: crust::command::run
29: crust::main
30: std::sys_common::backtrace::__rust_begin_short_backtrace
31: std::rt::lang_start::{{closure}}
32: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/core/src/ops/function.rs:259:13
std::panicking::try::do_call
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panicking.rs:379:40
std::panicking::try
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panicking.rs:343:19
std::panic::catch_unwind
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/panic.rs:396:14
std::rt::lang_start_internal
at /rustc/c97f11af7bc4a6d3578f6a953be04ab2449a5728/library/std/src/rt.rs:51:25
33: main
34: __libc_start_main
35: _start
Thread 'main' panicked at 'assertion failed: res.eax == 0', /opt/cache/registry/src/github.com-1ecc6299db9ec823/raw-cpuid-7.0.3/src/lib.rs:295
This is a bug. Please report it at:
https://github.com/crustio/crust/issues/new

Which cloud are you using? Could you provide some information? As a workaround to solve this issue, you can go to modify the docker-compose.yml in /opt/crust/crust-data/build/ path and remove the --wasm-execution and compiled from the args of chain and use sudo docker-compose up -d crust to try again.

close this issue since we cannot do too much for this.


Notify maintainers by email when official builds fail to get published

For example, this official build of a package I maintain, "silently failed" hours ago:

And I only noticed it after I manually went through builds on buildbot.flathub.org.
It'd be great if we (package collaborators) could get an email informing us of such failures, similarly to what GitHub Action does when a workflow run fails.
Thank you.

This is tracked sepereately on the main repo. It will be moat likely be solved when buildbot is replaced with Github actions.

Thanks for the link!


Tech Insights plugin is now hosted in backstage community.

Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Oh no. I just realized that this has a DCO problem as well. Gonna close it due to inactivity and make a new one


Bellman Ford [java]

This issue is about Bellman Ford.

[x] Issue Title is in the form Algo/DS Name [Language].
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
[x] This Algo/DS is worth adding to this repository.
[x] Assign this issue to me (I want to work on this).

[x] I ensure that I am not already assigned to 2 or more issues.

[ ] I will send my PR only after I'm assigned to this issue by any maintainer.
[x] I understand that I will be unassigned from this issue if I fail to send a PR for this within a week.

@iiitv/project-maintainers I want to work on this issue

@Chirag-Mathur GFI 👍


Add command to set kube_node_ip

Summary
A command should be added to README.md to export KUBE_NODE_IP.
Explanation
Currently, the instructions to configure wsk show:
wsk property set --auth $AUTH_SECRET --apihost https://[kube_node_ip]:$WSK_PORT

kube_node_ip is nondescript, and could be set in a similar way to $AUTH_SECRET and $WSK_PORT. Please see issue #8 for request to simplify commands.

Assigning @Tomcli per @animeshsingh's suggestion.

Done - closing it


added run command

Added option to execute custom shell commands (e.g.  scripts) during device init.
Syntax is similar to cloud init.
@kenan435, @zreigz

@cheld This is great! Gonna have a look at it this evening!

@floreks could you please make a review
To run tests:
git clone ...
make compile
make test
make test-shell

@Govinda-Fichtner do you need anything to have the PR merged?

@Govinda-Fichtner PTAL

@cheld Thanks you for taking the time to create this PR!


Motivation and Context

Cleaning up README
How Has This Been Tested
Visually.
Types of changes

[x] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@dhruvbatra Please "squash" your commits when merging by clicking the dropdown next to the merge button.

My bad.


[BUG] - tile of issue

Describe the bug
A clear and concise description of what feature is not working.
Impact
Please describe the impact this bug is causing.
To Reproduce
Steps to reproduce the behavior:

What environment you are running the pipeline in (i.e. HPC, local, cloud etc).
local
What version of the pipeline you are using
The command that was run to cause the error
Ubuntu, nextflow
If you used a custom config file please provide it
The text of the error itself - screenshots are great for this!

WARN: To render the execution DAG in the required format it is required to install Graphviz -- See http://www.graphviz.org/ for more info.
Error executing process > 'PHOENIX:PHOENIX_EXTERNAL:AMRFINDERPLUS_UPDATE (update)'
Caused by:
Process PHOENIX:PHOENIX_EXTERNAL:AMRFINDERPLUS_UPDATE (update) terminated with an error exit status (127)
Command executed:
mkdir amrfinderdb
amrfinder_update -d amrfinderdb
tar czvf amrfinderdb.tar.gz -C $(readlink amrfinderdb/latest) ./
cat <<-END_VERSIONS > versions.yml
"PHOENIX:PHOENIX_EXTERNAL:AMRFINDERPLUS_UPDATE":
amrfinderplus: $(amrfinder --version)
amrfinderplus_db_version: $(head amrfinderdb/latest/version.txt)
END_VERSIONS
Command exit status:
127
Command output:
(empty)
Command error:
.command.sh: line 3: amrfinder_update: command not found
Work dir:
/home/siddra/phoenix/work/51/6bf5a48a4a484ead61f0ef61be686d
Tip: you can replicate the issue by changing to the process work dir and entering the command bash .command.run

Include the files that caused the error

(if the file(s) contains something you don't want public open an issue with a brief description AND then email<EMAIL_ADDRESS>with the title QH ISSUE # so we can track the problem. DO NOT send PII!

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Logs
If applicable, please attach logs to help describe your problem. These would be the .command.err, .command.out, .command.sh and/or the .nextflow.log files associated with the run/process that failed. The .nextflow.log  file is in directory you ran the pipeline from. The .command.XXX files are found in <directory you ran pipeline from>/work/XX/xxxxxxxxxxxxxx here the x and X are a random string of letters/numbers associated with the process. As the pipeline runs on CLI you will see the beginning of these strings to the left of the process that is running.
Additional context
Add any other context about the problem here. If you have done any internet sleuthing already please link to any relevant posts on the topic.

Hi @Siddra2021, thanks for opening the issue its a good first step. However, you need to fill out the "To Reproduce" section at minimum or we will be unable to assist you. After you have filled that out please delete the rest of the template that is not being used. Also, edit the title to provide a general idea of what your error is so that others can reference this issue if they have a similar error. The idea here is that you need to provide enough information for us to be able to reproduce your error. I need to know how you are running the pipeline to assist you. Thanks!


New method of running

OK, I have done an experiment to try and shave off about 4 seconds or so of startup time.  Results may vary based on CPU power, etc.    I've changed the task component to a regular .cfm file that is directly invoked, bypassing the normal CommandBox bootstrap.  I've also updated the readme to show how to call it now.
box -clishellpath=/path/to/TestRunner.cfm

All of the rest of the conventions as far as the test files and such should work the same.  I just had to add a bit of boilerplate code to it to do what I needed.  Please give this a try and see if it improves the execution time. I do think you'll need the absolute path to the testrunner.cfm file.

3-4s speed up on my laptop :rocket:
I'll let you know when this is deployed.

Sweet, sounds good.

Deployed


We need enhance -Include/-Exclude to support wildcards

Sample to remove all x64 subdirectories:
    Get-ChildItem -Path ./  -Directory -Include "*x64*" -Recurse | Remove-Item -Force

From @mklement0:
We want that it to work against the full path. For the leaf component it is already work.

Can you be more specific? Your Get-ChildItem command works for me on both Windows and Unix.
(As an aside:  you misspelled -Recurse)

I only split discussion to discuss one branch.

@iSazonov: Thanks for fixing the typo.
I still don't understand what needs enhancing / isn't working (except that without -Recurse, the behavior is surprising - see #3304).

@iSazonov: Thanks for fixing the typo.
It is only after looking at the linked issue that I understood what this is about:
You want the wildcard to be matched against the full path vs. just the leaf component (which is how it currently works), correct? If so, could you please make that clear in the initial post?

@iSazonov is this already being implemented or can I give it a try?

@raghav710 Feel free to grab!

@iSazonov could you help me get started? I was searching the GetChildrenCommand.cs and FileSystemProvider.cs but couldnt find the exact location to make the changes. Thanks!

@raghav710 I'd start with https://github.com/Windos/PowerShell/blob/a464c578a2d96da7e23df7597670fe8780c89c84/src/System.Management.Automation/engine/SessionStateContainer.cs

@iSazonov I havent spent time on this. If there is any deadline for this feature, let me know so I can fastrack it if required (or someone who has time can take this up). Thanks! :)


Extract bundled from category_theory and generalize to Sort

Extracted bundled from category_theory.category
Extracted bundled.map from category_theory.functor
Renamed str to inst
Added bundled decidable_eq.

See this Zulip thread.

No complaints from me.

@semorrison You complained that this wasn't as useful as you hoped, because you quickly needed to bundle more than 1 thing. We have lift_on_2 etc... Would it make sense to also have bundled_2 and bundled_3?

@semorrison You complained that this wasn't as useful as you hoped, because you quickly needed to bundle more than 1 thing. We have lift_on_2 etc... Would it make sense to also have bundled_2 and bundled_3?

No, I don't think so. It's already a pity that using bundled means we don't get a custom name; once it's a more complicated object, I think it's worth the boilerplate in order to achieve a short name. CpltTopRing is a much better name than bundled_3 ring topological_ring complete or whatever it would be.

One thing I don't like about using sigma this way is that I think it's
very natural to provide an instance of category for both subtype and for
sigma, that ignores the condition/data --- this is a good way to think
about full subcategories. (In practice, when mathematicians talk about full
subcategories, they are sometimes actually talking about things based on
sigma, rather than subtype.)
On Mon, Oct 8, 2018 at 6:58 PM Sean Leather<EMAIL_ADDRESS>wrote:

@spl commented on this pull request.
In data/bundled.lean
https://github.com/leanprover/mathlib/pull/390#discussion_r223274939:

@@ -0,0 +1,53 @@
+/-
+Copyright (c) 2018 Scott Morrison. All rights reserved.
+Released under Apache 2.0 license as described in the file LICENSE.
+Authors: Scott Morrison, Johannes Hölzl, Reid Barton, Sean Leather

+Bundled type and type class instance.
+-/
+
+universes u v
+
+/-- bundled is a type bundled with a type class instance for that type.  I suppose it's just a matter of taste. See #407
https://github.com/leanprover/mathlib/pull/407 for the use-sigma-instead
option.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/leanprover/mathlib/pull/390#discussion_r223274939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdLBKuqnF4XrKWlT4pk1Z4mzgl4Vzc5ks5uiwWYgaJpZM4XJz0o
.

@semorrison Any thoughts on the above?
After the discussion here, I lean toward removing bundled and using structures instead. It now doesn't make sense to me to extract it because it doesn't add anything new to mathlib that doesn't already exist, e.g. sigma. But you don't want to use sigma, and understandably so. Therefore, it seems like bundled is in this funny position of saving a few lines of code even though it might be preferred to have better names that you get with a structure.
At the very least, if nothing changes, I think bundled should receive a comment describing its purpose.

I was just having a look at using explicit structures. It does cost some extra lines, see https://github.com/leanprover/mathlib/compare/master...semorrison:bundled#diff-cb0303b820034e5eac971e1af1738978. I'm not hugely concerned by these, although @johoelzl and @rwbarton might have other opinions.
I'm wondering how to get the best of both worlds. We want to define the structure ourselves, but then get the instance coercing it back to Type, and the instance providing the category as cheaply as possible.
Perhaps something similar to a derive handler?
I think for now lets:

Leave bundled in category_theory/.
Add some better documentation explaining its purpose and usage, and the reasons for not using Sigma.
Keep the renaming str -> inst that you proposed.
Think some more (perhaps back on zulip) about how to write some infrastructure to build the coercion and category instances cheaply and pleasantly.

I'm not convinced the savings are worth it. It's literally three lines to set up ring as a category with the coercion and instance. You can multiply that by maybe ten for all the different algebraic classes and it's still smaller than most lean files.

The keyword is pleasantly.

The link in https://github.com/leanprover/mathlib/pull/390#issuecomment-428484696 didn't work for me, but https://github.com/leanprover/mathlib/compare/master...semorrison:bundled did.
I don't think a tactic or derive is always the best solution for every duplicate line of code. You have to weigh the tradeoff of having and maintaining a tactic with maintaining the explicit code. In this case, there doesn't seem to be that many uses of bundled, which is part of the reason I lean towards using structures.
That said, until there is consensus on what to do (or until someone likely other than me moves forward with a concrete action), I'm willing to stick with the status quo modulo the few cosmetic changes that Scott suggested.
Does anybody else want to chime in? I'll wait a few days.

Hm, I think bundled should be confined to category_theory. In most other cases either we want a structure or just talk about subtypes.
Also I think the universes are wrong now with the generalization. The elaborator doesn't like Sort (max (u+1) v) when it needs some Type ?

Okay, I'm back. I looked into this again in more detail, and I've now come up with an alternative proposal that I'm liking a lot better. (See https://github.com/leanprover/mathlib/compare/530e1d13e0925e05146b320e44f9e9a145f8d7ad...spl:529be340358412d0b3c37a6fe1989e1c20814d28 for the diff at this point in time.)
First, I agree that taking bundled out of category_theory is not the right approach. But I do think it could be better placed. I realized that bundled is closely tied to concrete_category. So why not put those in the same place? I created category_theory/concrete_category.lean for that.¹
Second, regarding naming, I've been reading a bit (reminder: I'm not a category theorist), and references (e.g. nLab) generally describe a “concrete category” as a category equipped with a faithful functor. But the current concrete_category alone is not that, is it? It doesn't have the faithful from category_theory.embedding.
Abstract and Concrete Categories describes “constructs” as “categories of structured sets and structure-preserving functions between them” (p. 22).
So, given that, I wonder if some renaming would be in order. It seems to me that bundled is actually the above construct and concrete_category² is more like preserves_structure.³ Also, calling the structure-preserving property hom (∀ {α β : Type u}, c α → c β → (α → β) → Prop) is confusing to me due to the name overloading with category.hom. So far, I've only come up with maps³ as an alternative; there may be something better.
I guess there are two questions here:

Are you happy with the current reorganization (modulo comment changes)?
Would you like to see different names for concrete_category and bundled?

The change from the first step can naturally be done before the second question is even answered.

Footnotes:

Note that the comments in category_theory/concrete_category.lean have not yet been updated to reflect the change.

Note that renaming concrete_category to something else opens up the name for use as the commonly defined concrete category.

There are many naming alternatives for preserves_structure. It could also be called maps_structure or, more concretely, maps_id_comp, or something along those lines. Here's an idea that uses (for me) a more natural argument order and links the name to map which is generally a structure-preserving operation:
variables {C : Type u → Type v}
structure maps_id_comp (maps : out_param $ ∀ {α β}, (α → β) → C α → C β → Prop) :=
(id : ∀ {α} (a : C α), maps id a a)
(comp : ∀ {α β γ} (a : C α) (b : C β) (c : C γ) {f g}, maps f a b → maps g b c → maps (g ∘ f) a c)

+1 for the file reorganization. I think this helps "tell the story" of concrete categories better. I would even go further and move concrete_functor and forget (from category_theory.types) to the new file as well.
Regarding naming: concrete_category is a good name, but not for the thing that currently has that name. Your suggestion maps_id_comp seems fine to me; I don't think there is a standard name for this exact concept. The thing which is a concrete category is the category bundled c, not c itself. (Categories of the form bundled c are exactly the concrete categories in the sense of categories equipped with a functor to Set, at least for a mathematician's meaning of "are".) We could potentially add a class concrete_category that equips a category with a faithful functor to Set and make bundled c an instance. (I'm not sure how useful such a class would be in practice, but it could serve a kind of "expository" purpose, I suppose?)
On "concrete category" vs "construct": The terminology used in the book you linked to (Definition 5.1) never caught on--everyone uses "concrete category" for what that book calls a "construct", namely, a category equipped with a forgetful functor to Set.
I think the current name bundled is okay, and at least it reads well in simple cases like bundled group. Putting it in category_theory.concrete_category should make its purpose pretty clear.
On hom: maybe expressing the type as ∀ {α β}, c α → c β → set (α → β) would be clearer? Or how about renaming to is_hom?
On str: This is supposed to correspond to the usual mathematical usage of "structure". Informally, we use the word like: a group G (G : bundled group) is a set (α : Type u) together with a group structure (str : group α). It can also be given a formal meaning in the context of category theory as explained on the nLab. inst is okay too, I guess, but str seems like the most apt name to me.


Readonly user and "Cannot modify 'max_execution_time' setting in readonly mode."

What happened:
Using clickhouse-datasource 2.1.1, when running SELECT 1 query with a readonly user I get the error:
error querying the database: clickhouse [execute]:: 500 code: Code: 164. DB::Exception: Cannot modify 'max_execution_time' setting in readonly mode. (READONLY) (version <IP_ADDRESS> (official build))

What you expected to happen:
I expected a readonly user to query the data without any errors as with version 2.1.0 of the plugin.
How to reproduce it (as minimally and precisely as possible):

Install version 2.1.1 of the clickhouse-datasource plugin
Configure the datasource with a readonly user
From the explore panel select the datasource and run the query SELECT 1
See the error message

Anything else we need to know?:
There is no error when using clickhouse-datasource version 2.1.0 or before.
I've been trying to figure out where this could come from. I think that somewhere in this plugin or its go dependencies the max_execution_time parameter is set by default within the query.
Extract from the clickhouse-server logs (clickhouse datasource 2.1.1):
2023.03.17 09:37:26 [] {} <Trace> HTTPSHandler-factory: HTTP Request for HTTPSHandler-factory. Method: POST, User-Agent: grafana/9.3.6 clickhouse-datasource/2.1.1 clickhouse-go/2.7.0 (lv:go/1.19.7; os:linux), Length: 14, ...
2023.03.17 09:37:26 [] {} <Trace> DynamicQueryHandler: Request URI: /?database=default&default_format=Native&max_execution_time=64
2023.03.17 09:37:26 [] {} <Error> DynamicQueryHandler: Code: 164. DB::Exception: Cannot modify 'max_execution_time' setting in readonly mode. (READONLY),

Extract from the clickhouse-server logs (clickhouse datasource 2.1.0):
2023.03.17 12:31:37 [] {} <Trace> HTTPSHandler-factory: HTTP Request for HTTPSHandler-factory. Method: POST, User-Agent: grafana/9.3.6 clickhouse-datasource/2.1.0 clickhouse-go/2.5.1 (database/sql; lv:go/1.19.7; os:linux), Length: 8, ...
2023.03.17 12:31:37 [] {} <Trace> DynamicQueryHandler: Request URI: /?database=default&default_format=Native
2023.03.17 12:31:37 [] {} <Debug> executeQuery: SELECT 1 (stage: Complete)

Environment:

Grafana version: 9.3.6
Plugin version: 2.1.1

Installing 2.1.0 instead of 2.1.1 fixed this for me. In case anyone else comes across this, the version can be specified in the helm chart by adding it after the plugin name and a space in the plugin list.

I am also encountering this issue. I have downgraded to v2.1.0 and now its fine.

@jkaflik we had it in a blog post, but it should be a part of the docs, for sure:

additional_table_filters are passed in SETTINGS with the query itself. This is not permitted for read-only users unless readonly=2. This is not ideal, and we would not recommend setting this for public instances of ClickHouse. We recognize improvement is required here. Stay tuned.

Hi @jkaflik and @mshustov and thanks for the comments and pointers.
Reading the provided resources and digging into Clickhouse documentation on constraints I found:

readonly=0: No read-only restrictions.
readonly=1: Only read queries are allowed and settings cannot be changed unless changeable_in_readonly is set.
readonly=2: Only read queries are allowed, but settings can be changed, except for readonly setting itself.

I understand there is no bug in the clickhouse-datasource plugin. Just an error in my Clickhouse configuration.
I managed to fix the error by updating the config.xml and users.xml files:
<!-- config.xml -->
<clickhouse>
  <access_control_improvements>
    <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
  </access_control_improvements>
</clickhouse>

<!-- users.xml -->
<clickhouse>
  <profiles>
    <readonly>
      <constraints>
        <max_execution_time>
          <changeable_in_readonly/>
          <min>0</min>
          <max>180</max>
        </max_execution_time>
      </constraints>
    </readonly>
  </profiles>
  <users>
    <guest>
      <profile>readonly</profile>
    </guest>
  </users>
</clickhouse>

Another shorter solution would be as you suggested to set the readonly flag to 2. However as this was stated in the blog post, this is not ideal for a public instance.
Since my issue is solved, I'm closing it. Thanks again for the answers and pointers.

@jkaflik Probably, it should be included in sort of documentation.
@mshustov but it should be a part of the docs, for sure

I was thinking about your comments. Would it help if I provide an update of the README file with the solution I used?

@pnax, that would be much appreciated


DLL libs not excluded from main bundle

Thanks for the amazing work on this!
At my company we have a build system which is based off AngularClass/angular2-webpack-starter. I've pulled in the latest changes which incorporate this plugin. When I run it I am seeing that the Angular is included in both the main bundle and the DLL bundle. I expect the libraries in the DLL bundle to be excluded from the main bundle.
The main difference in our build system implementation is that it is packaged as an internal NPM lib and included in our projects as a devDependency. I'm wondering if something with this approach could be causing this issue. Any thoughts?

Found the issue. https://github.com/shlomiassaf/webpack-dll-bundles-plugin/blob/master/src/DllBundlesPlugin.ts#L24. If I change this to the project root, everything works as expected. Can this be configurable?

Try installing 1.0.0-beta.3
And in the option provide a context.
Should do the trick.
Let me know if it works, I didn't test it... blind try

https://github.com/shlomiassaf/webpack-dll-bundles-plugin/commit/5f95f362b87812b3ecf079ae8400bbfeed0812e1#diff-09377062f408640cd6246947929130e4R80
if (!this.options.context) instead?

I can confirm this is fixed. I didn't realize I had the same issue until today.


Button docs fix

Merge after migrate21
Fixes Button's and Fab's Documentation

the sample code is rendered as  instead of .

@filoozom, didn't get you?
I see this

Oh, strange. I'm getting this:

try npm i may be...


Testing/cli

CLI testing, with improved code coverage.
Not all methods appear testable, especially those which look for keyboard input.

This is dependent on PR #1053


updates on ci

use best practices for github actions
split the job for have more clarity: ci (build/test) and golangci-lint for lint
add windows tests
test with go 1.22 and 1.23

cc @vladimirvivien

@cpanato thank you very much for this.

@cpanato windows not playing nice.

@vladimirvivien fixed

@cpanato LoL you are basically forcing Windows support.
This is good as it's been on the roadmap for the longest.
I will create/push some changes with Windows support in mind, then come back to this to make it work.

@vladimirvivien ptal

is it flaky?

@cpanato I thought I fixed the flake.
I will take another look this weekend.


feat: add go sdk tests

Which issue does this PR close?
Part of #685
Rationale for this change

What changes are included in this PR?

Add go sdk tests

Write  2 rows, read back, and drop table at last.

Are there any user-facing changes?
No

How does this change test
CI

Codecov Report

Merging #686 (ed6f5bf) into main (f0b687b) will increase coverage by 0.00%.
The diff coverage is 9.09%.

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

@@           Coverage Diff           @@
##             main     #686   +/-   ##
=======================================
  Coverage   67.54%   67.55%
=======================================
  Files         281      281
  Lines       44302    44301    -1
=======================================
+ Hits        29925    29927    +2
+ Misses      14377    14374    -3

Impacted Files
Coverage Δ

cluster/src/config.rs
75.00% <ø> (-2.78%)
:arrow_down:

components/logger/src/lib.rs
27.98% <0.00%> (ø)

server/src/config.rs
38.09% <ø> (+0.88%)
:arrow_up:

server/src/grpc/storage_service/mod.rs
45.11% <0.00%> (-0.02%)
:arrow_down:

server/src/grpc/storage_service/write.rs
39.42% <0.00%> (+0.21%)
:arrow_up:

server/src/http.rs
0.00% <ø> (ø)

analytic_engine/src/manifest/details.rs
95.47% <28.57%> (-0.47%)
:arrow_down:

analytic_engine/src/row_iter/merge.rs
89.18% <0.00%> (+0.17%)
:arrow_up:

components/skiplist/src/list.rs
99.09% <0.00%> (+0.22%)
:arrow_up:

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


Hotfix/returning all filtering issue

Selecting all now returns filter options after a pre-search filter

code looks fine; tested by running a search with filters, then search results come back, I went back to select all types/sources, and checked if getting sources/types again would populate the full list again. looks good


Fix typo in translation inputs

Codecov Report
Patch and project coverage have no change.

Comparison is base (8e5d8e0) 85.08% compared to head (183b634) 85.08%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff            @@
##           develop      #20   +/-   ##
========================================
  Coverage    85.08%   85.08%
========================================
  Files            8        8
  Lines          342      342
  Branches        45       45
========================================
  Hits           291      291
  Misses          12       12
  Partials        39       39

Flag
Coverage Δ

macos-latest
?

ubuntu-latest
85.08% <ø> (ø)

windows-latest
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/adapter/parameters.ts
85.00% <ø> (ø)

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

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


fix: initial schemas

Forgot to update w/ new migrations when upgrading the image versions in https://github.com/supabase/cli/commit/2990b5729f73f687fc352fe5baf6d86f973028fa

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 29.436%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1450

Relevant Lines:
4926

💛  - Coveralls


CC0068 is being reported in VB even though it is disabled in the ruleset file

The following code is triggering CC0068 even though it is disabled in the ruleset file.
Private Sub Form_Load(ByVal sender as Object, ByVal e as EventArgs) Handles Me.Load
End Sub

Same thing from #470, this would be a problem on Roslyn itself. CodeCracker does not control this infrastructure.

@ giggio CodeCracker does control this to an extent because this diagnostic is nested with 13, 14 and 80, right?

@giggio You are correct that this is not a CodeCracker issue.  It's user error.  I did not have one of the projects in the solution using the same ruleset file as the rest.  Whoops.


Enabling WPF Crash Support in the UI?

I started investigating using App Center for crash reporting and implemented some sample code.  I created a "UWP" app in App Centre and tried using the provided Guid, but could not see any results for a Crashes.GenerateTestCrash().  Does there need to be something else for a WPF (Framework 4.8) application?
The documentation for WPF/Winforms states:
"The WPF and WinForms UI hasn't been released yet. If you would like to try out the analytics and diagnostics SDK, please reach out to our support team and we can enable this experience for you."
I was not sure if this was the correct place to reach out. I did not see any other support links in the App Center UI.
Thanks,

Hi @TimberRaft - can you start a support ticket in App Center with your email address so I can enable the UI for you? Thanks!

Thanks for the response.
My question is where in the App Center?  The only menu item  is “Submit an Issue” which puts me back here?

Hi @TimberRaft thanks for your patience! We just globally enabled the feature flag so you should be able to create a new WPF/WinForms app in the App Center UI.
Closing this issue but let me know if you have any questions or issues. Thanks!


Directive Resolver generation for typescript-resolvers seems to have broken in 1.12.x

Describe the bug
See here for a reproduction: https://codesandbox.io/s/inspiring-nobel-7wbf9?fontsize=14&hidenavigation=1&theme=dark
... codegen is sent to console.
Up to 1.11.x, directive resolvers were successfully generated for typescript given a directive definition.  After upgrading to 1.12.x, no directive resolvers seem to be generated.  This seems to be the case at least in the cases of a directive on OBJECT or FIELD_DEFINITION, I did not test any of the others.

My GraphQL schema:

  directive @testDirective on FIELD_DEFINITION
  type Query {
    foo: Boolean @testDirective
  }

  schema {
    query: Query
  }

Expected behavior
A directive-resolver is generated for @testDirective in the output.
Environment:

OS:
@graphql-codegen/1.12.2:

Could you try to parse SDL using parse and pass DocumentNode instead of using printSchema ?Because printSchema might remove directives.

@ardatan: updated case above, still same result where types for directive aren't generated.

@SirensOfTitan You say only directive resolvers are missing but I noticed that all resolver typings are missing. So I checked the configuration;
const { codegen } = require("@graphql-codegen/core");
const { parse } = require("graphql");
const typescriptPlugin = require("@graphql-codegen/typescript");
const typescriptResolversPlugin = require("@graphql-codegen/typescript-resolvers");
const schema = `
  directive @testDirective on FIELD_DEFINITION
  type Query {
    foo: Boolean @testDirective
  }

  schema {
    query: Query
  }
`;

async function output() {
  const output = await codegen({
    config: [],
    filename: "foo",
    schemaAst: parse(schema),
    plugins: [
      // Each plugin should be an object
      {
        typescript: {}
      },
      {
        typescriptResolvers: {}
      }
    ],
    documents: [],
    pluginMap: {
      typescript: typescriptPlugin,
      typescriptResolvers: typescriptResolversPlugin
    }
  });
  console.log("Parsed", schema);
  // @ts-ignore
  console.log("output", output);
}

output();

Each plugin needs to be defined as different objects in an array like above.

Closing. @SirensOfTitan feel free to comment if it's still doesn't work.


added an onInvalid callback prop to the Form.tsx component

We had a few merge conflicts seems this got lost I will add it back in