Notes about architecture and structure

I've been working with the backend the last few weeks, and in that regard I have some notes and feedback I want to discuss.

Model concept
Currently we have no concept of database "models", they are merely validations. I don't know if we need these, but I've been fiddling with the idea of having and "internal" model, which is basically a combination of a Joi-schema and some helper methods and constants for that "model". Does not need to be a class, just a file exporting helpers for that entity. Like having a map of internal fields to database fields, and a way to parse from and to the database. These could for instance be in root of 'models/v2'.

The 'data' concept
I feel these cumbersome to use, as we have to parse the data anytime it's used. I feel like these can be grouped as a 'service' for each entity, and in combination with the 'models', it would be easier to use internally. With this I mean that we would never 'expose' the result of the database queries directly, they would be parsed to an internal structure, so we don't need to care about column names and collecting joined relations anytime data is fetched.

Validation
Currently we are validating in both routes and 'data', I belive this is overkill. It should probably be up to the route handlers to do validation through hapi. Internal wrong usage is developer error and we shouldn't use Joi for type-checking.

Transactions
I've been fiddling with the 'service'-idea, and I believe if we do this right we can cut down on the 'try-catching' of transactions. Knex supports using transactions in the same way you would've used knex(), so we can use these interchangeably. This means that we can use the transaction-handler syntax in route-handlers and compose service-methods by passing either the transaction or knex-object - with the benefit of automatic rollback. Rough concept:

// some handler
const createVersionAndAddToChannel = (trx => {
     const v = await Version.create(payload.version, trx);
     await Channel.addVersion({appVersionId: v.id, channelName: payload.channel, ...}, trx)
     return v;
})
const version = h.db.transaction(createVersionAndAddToChannel);

We probably still need some explicit transaction management due to the normalized structure of our database, and some entities never 'live alone'.

Error handling
I believe this can be simplified as well. Services or data-fetching does not necessarily need to 'try-catch' and check for everything. It's actually a good thing that they don't handle the errors if we use the transaction-handler idea. We could also probably use something like https://github.com/Vincit/db-errors with onPreResponse-hapi hook to format and check for different errors, and return a meaningful error message to the client.

Uuid and id seperation
This is causing some headache and potential performance loss. In simple cases where you just need ids to add a relation or insert something, you now need a query for each entity as we need the id to perform inserts. Ie. if I want to add a user to an organisation I would just need the userId and organsiationId. However, since our join tables are based on ids and we just have the uuids on the client, I would need to run a query to grab the organisation and get the id, and the same thing with the user (well not really - we do have this from the auth in the request). Feels wrong to me.

Thanks for the thorough analysis and input @Birkbjo
Here's my thoughts on the subject
Model + data concept:
Reading in between the lines this to me sounds like you would be in favor for an ORM solution?
I generally think that using an ORM lead to more "magic" code that can be hard to follow, or end up being too generic leading up to making small changes hard or time-consuming. They also tend to produce complex bad performant SQL-queries for the most simple things.
Validation:
Route validation can be performed both on incoming and outgoing data, making sure that a code change doesn't break the format of a response for example.
I'm generally in favor of catching errors in an early stage if possible, at the same time every "layer" of the architecture should if possible prevent any errors in between.
Usually I consider each layer of an application as an API towards eachother where any input coming from a layer on top should be validated when pushed downwards (for example from a route handler to the data layer). It's more work but consider the case that one developer takes responsibility for the data layer and expose features for another developer working on the business logic and a third one on the API and the route handlers there should be some validation and error handling in between those, this also makes isolated testing easier and the validation acts as a contract between different layers.
We have a previous decision about validation of config objects (as used in the data layer today), and I think Joi is an excellent library for resolving this: https://github.com/dhis2/notes/pull/41/files
It removes lots of manual logic when we can add required, allow null, specific string lengths, allowed values in arrays etc..
UUID/ID separation:
I don't think we'll ever see this as a real performance issue as the app store API as it won't contain millions of rows or will be a very write-intense service.
I agree that we could move the UUID to be the primary key, that would potentially make it easier to merge different databases without having a key-collision. It would also make clustering and synchronizing databases easier.
We initially had a discussion with a decision about not exposing the primary keys from the database that lead to the design we have today. Probably it would be doable to redesign and remove the incremental ids in a day or so.
Revisiting this today I can't really find a proper argument for keeping the incremental ID's. Maybe we should however revisit the question regarding if we want to expose internal database id's and re-use them as external.

We should also consider flattening project structure on the file system to avoid having so deep relative paths such as
const createLocalizedAppVersion = require('../../../../data/createLocalizedAppVersion')
@varl had some idea a while ago about this, please fill in.

Reading in between the lines this to me sounds like you would be in favor for an ORM solution?

Not necessarily, and I'm not proposing adding an ORM-library. It would be very light, and would basically just mean that we have a map between an internal structure and the database-columns - so the data can be mapped whenever something is grabbed from the database. I find it very annoying to handle the normalized structure of the data whenever a 'data'-fetch is done. Transformation of the data should in my opinion be done by the same function that queries the database, however we could use the existing simple 'data'-functions but have a service-layer above that transform the data to an internal structure. You would still do your own queries.

We have a previous decision about validation of config objects (as used in the data layer today), and I think Joi is an excellent library for resolving this: https://github.com/dhis2/notes/pull/41/files

I would think this was just for exposed API-functions. If we would do this everywhere we would basically use Joi as a type-checker, and then we could rather look into typescript.
Your counterpoint of the layers basically being exposed APIs is valid though, however right now the 'layers' are tightly coupled, as the route-handlers deal with the raw database output.
This is my main concern along with the huge handler-functions and something I wanted to solve with 'services' that transform the data into an internal structure so it's easier for business logic and route handlers to use the data. This would also mean that it would be easier to change database schema down the line.

I don't think we'll ever see this as a real performance issue as the app store API as it won't contain millions of rows or will be a very write-intense service.

Right, I'm just stuck in the performance mindset all the time, and I guess that's the origin of my objection to multiple runtime validations of the same object.
I will open a draft-PR to show my experiments. Note that the PR will have some other functionality I have explored (like filtering and paging).

Reading in between the lines this to me sounds like you would be in favor for an ORM solution?

Not necessarily, and I'm not proposing adding an ORM-library. It would be very light, and would basically just mean that we have a map between an internal structure and the database-columns - so the data can be mapped whenever something is grabbed from the database. I find it very annoying to handle the normalized structure of the data whenever a 'data'-fetch is done. Transformation of the data should in my opinion be done by the same function that queries the database, however we could use the existing simple 'data'-functions but have a service-layer above that transform the data to an internal structure. You would still do your own queries.

I agree that it would be nice to avoid having to work with the database result-sets.

We have a previous decision about validation of config objects (as used in the data layer today), and I think Joi is an excellent library for resolving this: https://github.com/dhis2/notes/pull/41/files

I would think this was just for exposed API-functions. If we would do this everywhere we would basically use Joi as a type-checker, and then we should rather look into typescript.

You got a point but I don't entirely agree since joi can also check for string lengths (ok TS can kind of solve this too by using phantom types), validate url, e-mail, allow specific values in arrays etc.. and it does this in runtime and not in compile time. But let's bring this up for a discussion in a meeting again then?

Your counterpoint of the layers basically being exposed APIs is valid though, however right now the 'layers' are tightly coupled, as the route-handlers deal with the raw database output.
I think this has to change, moving forward we should iterate the architechture and move that out of the handlers.

This is my main concern along with the huge handler-functions and something I wanted to solve with 'services' that transform the data into an internal structure so it's easier for business logic and route handlers to use the data.

I don't think we'll ever see this as a real performance issue as the app store API as it won't contain millions of rows or will be a very write-intense service.

Right, I'm just stuck in the performance mindset all the time, and I guess that's the origin of my objection to multiple runtime validations of the same object.

I believe it's great to always consider performance, but to a certain degree, otherwise we could have denormalized all tables also in the database if we just wanted the best performance possible to fetch data without any joins

I will open a draft-PR to show my experiments. Note that the PR will have some other functionality I have explored (like filtering and paging).

Looking forward to see that!

@varl me and @Birkbjo is considering dropping the numeric id in favor of just using uuid for primary keys, any objections against that?
We'll then use the same id both internally and externally which makes the code easier, less db queries looking up id vs uuid etc. Regarding security by obscurity with not exposing internal id's which we discussed in the project startup I believe using uuid v4 is hard/impossible enough to guess a series of with rows for

I agree with dropping id in favor of uuid. As long as we use UUID v4 then it is exceedingly hard to guess.
We need migration scripts for both up and down as usual.


USD ROP allow remapping explicit layer save paths to be remapped to AYON Entity URI

Changelog Description

Allow remapping to AYON Entity URI instead of resolved publish filepath for layer save paths directly written out from the USD ROP that also turn into their own publishable instance.
Additional info

Testing notes:
Enable Extract USD attribute use_ayon_entity_uri in settings.

Create a Solaris stage that generates an additional layer save path (explicit layer save path)
This layer save path will introduce an additional publish instance.
With the setting enabled that instance should be remapped to an AYON Entity URI
With the setting disabled that instance should be remapped to the resolved publish path (same as before this PR)

im not sure what is happening but it dose not create the output i would have expected.
i belive its only extracting 1 of the explicit save paths
here is an image to what i see not sure how i would test or debug things here.

What a test! :) Can you share a scene file?

im not sure what is happening but it dose not create the output i would have expected.
i belive its only extracting 1 of the explicit save paths
here is an image to what i see not sure how i would test or debug things here.

What a test! :) Can you share a scene file?

here is the scene used for testing.
but i will also say i dont think this is part of the current USD epic so im gonna postpone further testing for the next epic.
UB_ep2_layout_v002.zip

@MustafaJafar your specific test run confirms the loading, but not this PRs saving of explicit layer save paths and embedding that in the published USD file.

@Lypsolon I've checked your scene files just now - and your scene actually behaves correctly. It saves only one explicit layer save path. This is due to the MERGE node.
See here:

At the merge, there's only one layer still in my Scene Graph Layers. This is due to the default being a "Simple merge".
When I change the merge style:

Then I get this:

That's when the publisher should pick that up.

ahh sorry rucky mistake i will test again.
the merge node is getting me every now and then.

One small note.
something is printing the following
>>> We have preset for LOPLoadAssetLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for LOPLoadShotLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for USDSublayerLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for USDReferenceLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for SopUsdImportLoader
  - setting `use_ayon_entity_uri`: `True`

One small note. something is printing the following
>>> We have preset for LOPLoadAssetLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for LOPLoadShotLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for USDSublayerLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for USDReferenceLoader
  - setting `use_ayon_entity_uri`: `True`
>>> We have preset for SopUsdImportLoader
  - setting `use_ayon_entity_uri`: `True`

Correct - this is the discovery of the plugins in the Create Context and how it applies the project settings. It's verbose yes - but shouldn't be an issue for now.


SwiftDriver: add support for resolving the registrar via SDKROOT

This addresses a TODO to resolve the swift registrar via evaluation of
SDKROT environment variable.  The path is computed through an order
preference of:

-resource-dir
-sdk
SDKROOT
toolchain relative resource directory

This should enable the use of the swift driver to compile Swift code
without needing to explicitly pass the -sdk parameter on Windows.

@swift-ci please test


Fixed issue with parsing SSE event headers

Details:
According to SSE Spec at https://www.w3.org/TR/2009/WD-eventsource-20090421/#concept-event-stream-reconnection-time, retry header in event source response should be passed (and interpreted) as milliseconds. Current implementation was interpreting it as seconds.

@markpokornycos @arun251 For review

You're right -- the spec states that this should be in milliseconds.
In the year that's passed since your pull request submission (sorry for the delay!) this was resolved in version 4.0.0. We recommend bumping to that version to acquire the fix.


need for GRPC_ENABLE_FORK_SUPPORT=1 when used in applications that fork

For many applications (e.g., apache2, OpenVPN) use of this pkcs11 module for private keys in KMS requires to set GRPC_ENABLE_FORK_SUPPORT=1. Would it be possible to make this a configuration option? Users anyway need to setup a config file, would be easier if the fork support also could be enabled at the same place.

Apologies for the late reply, I was sure I had replied a while back but never did!
I'm not super convinced this would be a very helpful config option just because setting the config itself also relies on an environment variable (KMS_PKCS11_CONFIG), so GRPC_ENABLE_FORK_SUPPORT can easily be set at the same time / in the same file. eg. for apache, this new config option would just save 1 line in /etc/apache2/envvars
Let me know if I'm missing anything though.


Import & export

Goals:

[x] Import from and export to standard Python packages for network science. At least networkx and graph-tool. Optionally, NetworKit, igraph, SNAP.
[x] Use the above import & export functionality to load & save graphs and signals in standard formats such as:

GraphML
GML
GEXF (Gephi's format)
dot (Graphviz's format)

[ ] Further leverage the import & export infrastructure. For example, we may want to use networkx's graph generators, or visualization tools.

@cgallay will implement those features. Any feedback or comment from the community is welcome.

API
I'd propose to introduce FromNetworkX and FromGraphTool as sub-classes of Graph, such that a pygsp graph can be constructed from a networkx graph as graph = pygsp.graphs.FromNetworkX(graph_nx). The to_networkx and to_graphtool methods of a Graph object would then return a graph object of the respective package. That is, graph_gt = graph.to_graphtool().
For the second step, another sub-class, FromFile, will accept a path to a file and use networkx or graph-tool in the backend to load the graph. That is, graph = pygsp.graphs.FromFile('path/to/graph.format'). A graph will be saved as graph.save('path/to/graph.format').
In addition to the graph, we should import/export one or many signals. Signals are sometimes part of a graph, and it's useful to save them together (e.g., for visualization). In networkx, signals can be represented as node attributes (weights are edge attributes). In graph-tool, signals can be represented as vertex property maps (weights are edge property maps). In both implementation, signals can be named. I'd thus propose to introduce a Graph.signals attribute, which is initialized as an empty dictionary by default. Users can either populate the dictionary before exporting/saving, or retrieve the saved signals by name when importing/loading.
Considered options
While it's clear that export and save should be implemented with methods, I was not sure if the import and load should be implemented in the constructor or as a factory. Options:

graph = pygsp.graphs.Graph('/path/to/graph.format'): constructor accepts multiple objects, such as paths, numpy array (adjacency matrix), networkx and graph-tool graphs. That is convenient but the documentation might not be clear as Python lacks function overloading.
graph = pygsp.graphs.Graph.load('/path/to/graph.format'): a @classmethod factory is used to build and return the object as the __init__ constructor would do. Each factory builds a Graph from a different object.
graph = pygsp.graphs.load('/path/to/graph.format'): the factory is a module-level function instead of a class method. While that is more convenient for the user, it lacks a clear meaning that load will return a Graph object.
graph = pygsp.graphs.FromFile('/path/to/graph.format'): sub-class the Graph base class to overload the constructor. That's more consistent as we do it this way for graph models already. It's also more OOP.

Another option was for the importing/loading functions to return a dictionary of signals instead of storing it as the graph.signals attribute. Exporting would have been done as graph.to_networkx(myfeature1=mysignal1, myfeature2=mysignal2). If those signals are to be exported and saved, it's however clearer if they are part of the Graph object.
Implementation
Networkx and graph-tool should be lazily imported as we don't want them as dependencies. That is, import them in the function definition not the module.
Unit tests should be created to test the implementation. I propose to do a round-trip (to networkx, graph-tool, various graph formats) and verify that the graph and signals are preserved.
Again, any suggestion is welcome.

We of course could. That's what I discussed in the "Considered options" above. The main argument for me to go with sub-classes is to be consistent. Given that we already have pygsp.graphs.Sensor() and the like for graph models, pygsp.graphs.FromNetworkX(graph_nx) is more consistent than pygsp.graphs.Graph.from_networkx(graph_nx). In the end all the sub-classes of Graph only exists to overload the constructor (be it to take it from networkx, to load it from a file, to generate a network from a model, etc.). All the methods (and therefore the interface), is implemented in Graph itself (or parent classes such as GraphFourier and GraphDifference, which are only mint to modularize the code). See also my StackOverflow answer.

Here are some implementation details.
For Graph Tool:

The weight of the edges are stored as an edge property therefore for export, the method to_graphtool(...) will take an argument edge_property_name that will be used as a key for the edge property of the generated graphtool object. When importing a graph from graphtool the same argument will be used and the corresponding property will be used as a weight for the edges

Multiple edges are allowed in graphtool but not in pygsp therefore when importing a graph containing more than one edge between two vertexes I suggest that a warning is shown to the user letting him know that the sum was used to aggregate the multiple vertexes into one. For more flexibility, the user will have the possibility to set a custom aggregate function with the agg_mutli_edge_fn argument.

For Networkx:

a user can set some attributes per edge. By default when constructed by from_scipy_sparse_matrix the attribute is attribute name is weight. For export, the method to_networkx(...) will take an argument edge_property_name (for consistency with graphtool) where the weight of the edges will be stored. When importing the user will have to choose which attribute he wants to use as weight (see)

Please let me know if you like the implementation or give me feedback on how to improve. I will update this post with more implementation details as I code.

Implemented in #32 and #46.


1.1.6 release

With the fix for #115. Target date: 2020-08-24.

Releasing via Travis is busted at the moment, so I did it manually. https://pypi.org/project/mercantile/#files.


Add demo inference for EMDC

Description
Add demo ONNX inference for EMDC
Added data for easy demo test
Preview:

LGTM :+1:


Improved entrypoint test - check the response content

Description
Improved entrypoint test - check the response content
Type of change

REST API tests

Testing steps
To be checked on CI.
Checklist

[ ] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report
Patch and project coverage have no change.

Comparison is base (412b5d5) 4.38% compared to head (7744d93) 4.38%.

Additional details and impacted files
@@          Coverage Diff           @@
##           master    #401   +/-   ##
======================================
  Coverage    4.38%   4.38%
======================================
  Files          15      15
  Lines        1117    1117
======================================
  Hits           49      49
  Misses       1068    1068

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


Create MPLgen

feat: New illa app
📝 Description
Add a brief description.
💣 Is this a breaking change (Yes/No):

[ ] Yes
[x] No

🚧 How to migrate?
Don't need.
📝 Additional Information
lol

Hi illa,
When I previewed the app, the access to database was successful. When I tried with the link in the file committed in appearance the app does not have access to database, I am assuming because I have the free version.
Best Regards
Douglas

@navascogt Hello, the bug has been fixed and you can try again. I tried following your steps and there are no issues.We will review the PR as soon as possible in chronological order.

Hi @AruSeito, thanks!  Now the users table works fine!!! However, the view Orders (you can access pressing Order button) does not work, it has two queries, one to populate feature select control and one for the table, both are on orders table.
Thanks again


Use configClient to configure retention jobs

Add new DatasetCleaner that uses configClient to initialize DatasetFinders using importedBy tag
Add new constructor to NewestK, Timebased and Combine policies. This constructor takes a typesafe Config and initializes the policy

Tested in simulate mode for a few datasets
@tuGithub and @ibuenros can you review?

@ibuenros and @tuGithub  I addressed all PR comments. Please take another look.

Can not find BaseDatasetCleaner.java anymore in the files, did I miss anything?
Also for the ConfigClient initialization , why need to create one per data finder? Prefer to have only one in the JVM. we can talk about it next Monday

@tuGithub I removed BaseDatasetCleaner as per @ibuenros 's feedback. Basically moved that logic to MultiCleanableDatasetFinder.
For the config client we have a couple of options.

We can pass the configClient from the job to the finder
We can keep some sort of singleton static instance
I do not like #1 as we need to pass around the client in all finders. We can do #2

Option 2 is fine with me

@tuGithub added option2. Check gobblin.config.client.ConfigClientCache
@ibuenros addressed other comments

@tuGithub can you review this?

LGTM

LGTM


Dependency on @storybook/api or incompatibility with Storybook 6.5.16

Affected design types

[X] figma
[ ] figspec
[ ] link
[ ] image
[ ] iframe

Describe the bug
Hello! After installing version 6.5.16 of Storybook the addon has started giving problems.

error TS7016: Could not find a declaration file for module '@storybook/api'.

I understand that this is related to other bugs already reported.
Any temporary solution?
We need to update the Storybook version in order to upgrade to Angular 15.
Thank you
How to reproduce the bug?

Install last version of Storybook (6.5.16)
Use Figma token in mdx files

Expected behaviour
Story renders without errors
Environment

[X] Chrome / Chromium / Chromium based browsers
[ ] Firefox
[ ] macOS Safari
[ ] iOS Safari
[ ] Samsung Internet
[ ] Other

Affected versions
6.3.1
Storybook versions
6.5.16

I reinstalled and it worked.
Maybe some package was cached


cannot import name 'make_bounded_resize' from 'opendp.transformations'

Whenever I try to import any opendp library, I first get this error:
ImportError: cannot import name 'make_bounded_resize' from 'opendp.transformations' (/local_disk0/.ephemeral_nfs/cluster_libraries/python/lib/python3.9/site-packages/opendp/transformations.py)
and then when I rerun it, it works normally. Any idea what might be the issue or how to mitigate it?

What version of OpenDP are you on? Might you have OpenDP 0.6 on one interpreter, and 0.7 or 0.8 on another?

This sounds like it was a version issue vs the documentation. If you're still seeing this problem, please feel free to reopen!


Test combination of features in regression_test.sh

Should we be testing all possible combinations of feature flags in the regression_test.sh script (Or at least somewhere)? I don't think at the moment there are any feature attributes that depend on more than one feature, but it seems as if it should be tested before the release at the very least. The downside of all possible combinations is that these tests will take considerably longer to test. At the very least the urispec feature needs to be added to the regression_test.sh. I will make a PR to go the route desired.

yes, urispec is currently missing, also in github workflows, both need to be updated

Just to be clear, you are on board with testing all combinations of feature flags?

I think Due to the fact that all optional features are standalone(no inter dependencies) we only need test each feature plus all together . Do you see significant gains to test all combinations ?  But we can improve CI by using cargo-hack which is good for testing combination easier

I agree that its not needed given there are no interdependencies, but do you see that being likely in the future? Perhaps cargo-hack would be useful to have set up before a feature with interdependencies is implemented.


Make dicts on-the-fly, use list comprehensions

URL_BASE shortens URLs.  The first URL was API v2.9 and all others were 2.6?  Should they all be the same version or not?

I've double checked the document, it uses v2.6.


Reverts to dynamic version of OpenSSL if libcrypto.a not found

Issue #, if available:
Fixes issue #1926
Description of changes:
If BUILD_SHARED_LIBS=OFF and it fails to find a static version of OpenSSL, it reverts to the dynamic version of libcrypto.
Check all that applies:

[X] Did a review by yourself.
[ ] Added proper tests to cover this PR. (If tests are not applicable, explain.)
[ ] Checked if this PR is a breaking (APIs have been changed) change.
[ ] Checked if this PR will not introduce cross-platform inconsistent behavior.
[ ] Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

[X] Linux
[ ] Windows
[ ] Android
[ ] MacOS
[ ] IOS
[ ] Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Sorry, we are not able (yet) to integrate public PRs straight into the repo.
This PR is integrated into the main public branch as a part of today's release:
https://github.com/aws/aws-sdk-cpp/commit/62c00f7a7265e3567a90e4d47ce28a43d7812129
https://github.com/aws/aws-sdk-cpp/commit/e5cda3ff2a67d61a2cbe24b93629bac8cccc3b10
Thanks a lot for your contribution!


Create a make command to execute makemigrations

Is your feature request related to a problem? Please describe.
no
Describe the solution you'd like
I want a new make command to execute the makemigrations. Now it's difficult to execute makemigrations because you have to go inside of the container and execute the python manage.py makemigrations. The idea is to have a make command that will execute it inside the container and the migrations files will appear in your local. This will be automatically because we already have the volumes.
The problem is that we cannot execute the docker-compose run app python manage.py makemigrations because we need an entrypoint that enables python in the dockerfile.

Fixed by #131


Implement close() method

Since minimize(), maximize(), and unmaximize() are there, why not add close() as well?
Also this might help bitsdojo_window for reference

Added, next version will be released


fix(gsa): receive by setting lastcommit on streamstate (SPEC-532)

Description & motivation

Receiving stream into GSA currently throws a reference exception
Changes:

Set Streamstate LastCommit property on receiving.

To-do before merge:

Screenshots:

Validation of changes:

Manually tested

Checklist:

[ ] My pull request follows the guidelines in the Contributing guide?
[ ] My pull request does not duplicate any other open Pull Requests for the same update/change?
[ ] My commits are related to the pull request and do not amend unrelated code or documentation.
[ ] My code follows a similar style to existing code.
[ ] I have added appropriate tests.
[ ] I have updated or added relevant documentation.

References

Good spot of missing property assignment. However, going to close this PR because the change we make here should be based on use of the new ConnectorHelpers methods: https://github.com/specklesystems/speckle-sharp/blob/4f223dd7a6dbcfd0981d742982844216c0fe682b/DesktopUI2/DesktopUI2/ConnectorHelpers.cs#L20


Add Ability to create UUIDs with timestamp

UUID factory create() API does not allow us to pass an external timestamp, this means there is no way to test/validate isExpired() and other time related functions. Additionally we cannot inject specific time information. Line in question is here:
https://github.com/eclipse-uprotocol/up-cpp/blob/main/include/up-cpp/uuid/factory/Uuidv8Factory.h#L67C17-L67C23
Example of what is needed can be found in up-java: https://github.com/eclipse-uprotocol/up-java/blob/main/src/main/java/org/eclipse/uprotocol/uuid/factory/UuidFactory.java#L61
Another example implementation in up-rust: https://github.com/eclipse-uprotocol/up-rust/blob/main/src/uuid/uuidbuilder.rs

This is covered in the 1.5.8 API update for the UUID builder. This will be tracked with the generic implement UUIDBuilder task.


bug/discovery lock

Codecov Report
Attention: Patch coverage is 41.93548% with 18 lines in your changes are missing coverage. Please review.

Project coverage is 14.03%. Comparing base (9c5be22) to head (db139e1).

Files
Patch %
Lines

topology.go
0.00%
12 Missing :warning:

discovery.go
76.47%
4 Missing :warning:

replicaset.go
0.00%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##           master      #20       +/-   ##
===========================================
+ Coverage        0   14.03%   +14.03%
===========================================
  Files           0        9        +9
  Lines           0      620      +620
===========================================
+ Hits            0       87       +87
- Misses          0      528      +528
- Partials        0        5        +5

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


[Feature]: Flatpak support

Feature description
Now that we're planning on deprecating AppImage (#1082), we need to support FlatPak as an alternative agnostic distribution mechanism.
Implementation Suggestion
Electron Builder does not currently support publishing to FlatHub. FlatHub only allows packages that they can build on their infra and Electron Builder is not currently capable of supplying a manifest that would allow their infra to build the packages.
At a brief glance, it seems doable, though it is still a lot of legwork to set up. We'd need to pre-fetch all dependencies, including the Electron binaries, place them in a cache, and update electron-builder so that it can find these cached dependencies when run inside FlatHub's builders.
Another option is to copy VSCode's method and ship the entire DEB as an extra-data field and then have the build script just unpack this into the sandbox.
Separately, the permissions story for FlatHub is pretty tricky. We would likely want to add first-run script that would copy WSH into the main filesystem and then WaveSrv can use a socket to communicate with it.
Anything else?
No response

Any news on that ?

No news, probably won't get to this until the new year. If someone else wants to take this on, more than happy to hand-off.


First implementation of FFT on CUDA

TITLE
Description
Description of the pull request changes and motivation.
Type of change
Please delete options that are not relevant.

[x] New feature

Checklist

[x] This change requires new documentation.

Codecov Report

Merging #236 (76048a7) into main (ae10473) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #236   +/-   ##
=======================================
  Coverage   96.19%   96.19%
=======================================
  Files          83       83
  Lines        9438     9438
=======================================
  Hits         9079     9079
  Misses        359      359

Impacted Files
Coverage Δ

math/src/field/test_fields/u32_test_field.rs
0.00% <ø> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Closed in favour of #268, will cherry-pick some things from here


Add brotli support to CMake build

This looks for the rotlicommon and brotlienc libraries. If they are found, it links both the brotlicommon and brotlienc libraries to the compress plugin.

[[ci approve autest]]

[approve ci autest]

[approve ci centos]

[approve ci cmake]


added -nobs to html2text to remove the character-backspace-character as reported in issue #5

fix for issue #5


 G

Result: The cursor is drawn below the last buffer line (see screenshot below).
Move the cursor to the first line with gg, then press j.
Result: The cursor jumps straight to the 5th line.

Expected behaviour
I'm not sure what the correct behavior should be. Maybe: when a text-property
type is deleted with prop_type_delete('mytype'), all text-properties using this
type should be removed as well. If no bufnr is passed to prop_type_delete(),
this would mean removing all text-properties in all buffers.
Additional context
I encountered this bug after removing text-properties while the buffer was in
one state, and then running :undo to go back to an earlier state. It resulted
in text-properties re-appearing in the buffer. This got me thinking: in some use
cases this is desired while in other cases text-properties need to be removed
"permanently", i.e. after an :undo they shouldn't re-appear. An example would
be a plugin that provides some kind of syntax highlighting. If the plugin is
turned off, the text-properties need to be removed and shouldn't show up after
:undo.
There are several ways to accomplish this:

Use listener_add() and call prop_remove() whenever a text-property
re-appears.
Same as 1., but use TextChanged instead.
Use prop_type_delete() (currently has bugs).

Alternatives:

Add a new option to prop_add() (or prop_type_define()) that tells Vim
to add the text-properties only to the current buffer state.
Add a new option to prop_remove() that tells Vim to remove the
text-property from all buffer states, not just the current one.

 G

Result: The cursor is drawn below the last buffer line (see
screenshot below).
Move the cursor to the first line with gg, then press j.
Result: The cursor jumps straight to the 5th line.

In other words: although the text properties are not displayed, they are
counted for positioning the cursor.  That's a bug.

Expected behaviour
I'm not sure what the correct behavior should be. Maybe: when a
text-property type is deleted with prop_type_delete('mytype'), all
text-properties using this type should be removed as well. If no
bufnr is passed to prop_type_delete(), this would mean removing
all text-properties in all buffers.

That is not practical, there could be many text properties, deleting
them might take a considerable effort.  And it's not unlikely the buffer
is going to be closed, which means all the work would have been
a waste of time.

Additional context
I encountered this bug after removing text-properties while the buffer
was in one state, and then running :undo to go back to an earlier
state. It resulted in text-properties re-appearing in the buffer. This
got me thinking: in some use cases this is desired while in other
cases text-properties need to be removed "permanently", i.e. after an
:undo they shouldn't re-appear. An example would be a plugin that
provides some kind of syntax highlighting. If the plugin is turned
off, the text-properties need to be removed and shouldn't show up
after :undo.

Text properties are stored together with the text.  Undo and redo
applies to both.  This cannot be changed.

There are several ways to accomplish this:

Use listener_add() and call prop_remove() whenever a text-property
re-appears.
Same as 1., but use TextChanged instead.
Use prop_type_delete() (currently has bugs).

Using prop_type_delete() will make sure the text properties won't be
used.  The bugs related to this need to be fixed.

Alternatives:

Add a new option to prop_add() (or prop_type_define()) that tells Vim
to add the text-properties only to the current buffer state.

I don't know what "current buffer state" means.

Add a new option to prop_remove() that tells Vim to remove the
text-property from all buffer states, not just the current one.

What does "all buffer states" mean?
I don't think we need to do more than fix the display and cursor
position computations.  I'll use the repro case to find what I can now,
there most likely are a few more.  Please provide a repro case if you
find one, preferably in a form it can be used for a regression test.
--
hundred-and-one symptoms of being an internet addict:
211.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Thanks for the quick fix. With "buffer state" I meant the current state in the undo history or buffer history, while pressing u or <C-r>. Not sure what else to call it.
So what is the recommended way to permanently remove the text-properties during a vim session? So that the highlightings don't reappear after undo or redo? The easiest way seems to be with prop_type_delete().

This is what I expect to happen.  Let me repeat:
"Text properties are stored together with the text.  Undo and redo
applies to both.  This cannot be changed."
In other words: when saving the text for undo, the text properties are saved as well.
When restoring the text with an undo command, the text properties are also restored.
In a way the text properties are part of the text.
Making changes is a linear sequence of events.  Undo goes back through those events.
Adding and remove text properties is part of that.  It's not like you can create a parallel universe and jump between the two.
Depending on what added the text property, perhaps you can check the changed lines (no matter if it was a new change or an undo) and add/remove text properties for the current text.  I can't really think of what else would be done.


Adding IAM Actions doc

Signed-off-by: Mary Jinglewski<EMAIL_ADDRESS>:nut_and_bolt: Description: What code changed, and why?
To meet a documentation need for support and customers, we're adding a chart of IAM Actions, their end points, and their associated UI page to the Chef Automate docs site.
Related Resources
https://github.com/chef/release-engineering/issues/1064
:+1: Definition of Done
PR should be done when the details of this current chart are filled out as much as possible. @mjingle still needs to do a second run-through.
:athletic_shoe: How to Build and Test the Change
To view the docs change, pull in this PR and follow the instructions for make serve.
:white_check_mark: Checklist

[x] I have read the CONTRIBUTING document.
[ ] Tests added/updated?
[x] Docs added/updated?
[x] All commits have been signed-off for the Developer Certification of Origin.

see rel-eng #1064


Document best practices regarding code and specs

(Split from a discussion in #964)
The current CONTRIBUTING document is very short and generic. There are a  lot of best practices we're using in the project that are not mentioned anywhere. A non exhaustive list:

Disabling failing specs with NATFIXME, xit, xdescribe etc.
Coding styles, both C++ and Ruby

Also would be nice to document #874
There are probably other best practices that people are using that are not currently part of the project that might make it more convenient for testing and development, unsure what the best way to discuss that is besides submitting PRs.

I opened #1061 to improve our doc. Please let me know if you think I missed anything!

I didn't realize there was a rubocop config for the project until I read the changes in #1061
Would it be appropriate to add rubocop --auto-correct to the rake format task or is that too heavy handed?

Unfortunately, Rubocop breaks some stuff when it auto-corrects. I just now ran it on the whole project, and after the "corrections" I started seeing this error:
→ bin/natalie examples/hello.rb
/home/tim/pp/natalie/lib/natalie/compiler.rb:9:in `require_relative': /home/tim/pp/natalie/lib/natalie/compiler/macro_expander.rb:230: syntax error, unexpected string literal, expecting `end' (SyntaxError)
...init_function) : $stderr.puts "Expected #{path} to contain f...
...                              ^
        from /home/tim/pp/natalie/lib/natalie/compiler.rb:9:in `<top (required)>'
        from /home/tim/pp/natalie/lib/natalie.rb:1:in `require_relative'
        from /home/tim/pp/natalie/lib/natalie.rb:1:in `<top (required)>'
        from bin/natalie:15:in `require_relative'
        from bin/natalie:15:in `<main>'

In the past I had tried to use prettier to autoformat Ruby code, but I strongly disagree with many of its decisions and feel like it makes the code harder to read in many places.
I think for now, I'd prefer to have slightly-less consistent Ruby (even if that means people forget to run rubocop) than to have code auto-formatted that's hard to read or perhaps broken. 😄


Variable values surrounded by commas when css is rendered

Environment
System:

OS: macOS 12.4
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 66.24 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh

Binaries:

Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
Yarn: 1.22.18 - ~/.yarn/bin/yarn
npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm

npmPackages:

styled-components: ^5.3.0 => 5.3.1

Reproduction

https://codesandbox.io/s/styled-components-base-gc367
Steps to reproduce
const texture2Str = css`
  ${base}
  :before {
    background-image: url(${texture2img});
    mix-blend-mode: overlay;
    opacity: 0.6;
  }
`;

Create a css snippet, here used for a filter over the top of the image. Import a image or variable, I've reproduced this with multiple data types in the app.
Css rendered looks like this:

Expected Behavior
Image path renders correctly
Actual Behavior
Image path is rendered surrounded by commas

I can fix this issue by created the css as a separate string and then passing into the css snippet, but I don't think this should be needed and isn't a nice solution.
const texture3Str = `
  ${base}
  :before {
    background-image: url(${texture3img});
    mix-blend-mode: overlay;
    opacity: 0.6;
  }
`;

export const texture3 = css`
  ${texture3Str}
`;


seal: Remove ext_dispatch_call and ext_get_runtime_storage

Subset of: https://github.com/paritytech/substrate/issues/6355
We only want to provide a basic set of APIs because once seal  is deployed we cannot remove them. We can always add API later when necessary.
This PR therefore removes the following functions from the API because they either implement niche functionality or are difficult to reason about security wise:
ext_dispatch_call
This is difficult to audit as it can make arbitrary calls into the runtime. For that reason we do not want it to exist in our first deployment. In contrast to regular extrinsic dispatch we do not spawn a new runtime instance for each call executed in this way. This makes this more difficult to reason about. A good example where this is problematic would be a sequence of dispatches that DoS the memory allocator of the runtime.
ext_get_runtime_storage
Rather than having a blanket way of retrieving values from runtime storage we want runtime authors to make use of an upcoming mechanism called Chain Extensions. This will allow runtime authors to augment the API with their own functions that can supply contracts with information specific to their chain.

This looks fine, although I think we would need to rebase it on top https://github.com/paritytech/substrate/pull/6382

Sure. I will do this one it is in.

bot merge


No supported Nvidia GPU found。4070s not supported？

when i run infer-web.py.it shows "No supported Nvidia GPU found".i have installed torch and  cuda 12.6

4070 is supported, i in fact had the same problem, try reinstalling or closing terminal and re running RVC and Xtts finetune. There are some videos on youtube one of which I use my 4070 locally so yes it is possible and is supported

If an NVIDIA GPU driver is not available, the program will run in CPU mode instead.

4070 is supported, i in fact had the same problem, try reinstalling or closing terminal and re running RVC and Xtts finetune. There are some videos on youtube one of which I use my 4070 locally so yes it is possible and is supported

Actually,i dont know wether i forget some steps or do somting wrong,because i dont know is the project support RTX 4070 Super

If an NVIDIA GPU driver is not available, the program will run in CPU mode instead.

i know that, the terminal shows the tip.but i want to run with 4070s

i know that, the terminal shows the tip.but i want to run with 4070s

I understand. Is the RTX 4070 Super a GPU driver, I'm just curious?

I believe 4070 Super will work, as Kal said maybe its a driver issue?
which you can sort from "Geforce experience" app to download the gpu driver which nvidea will find for your system

i know that, the terminal shows the tip.but i want to run with 4070s

I understand. Is the RTX 4070 Super a GPU driver, I'm just curious?

it's another model of 4070，America don't have this model？

I know where i went wrong.Its my first time to use pytorch and cuda.So i dont know cuda is also a library like python,java.Both of them have different version.As a result pytorch doesnt support the newest cuda 12.6 that i installed previously.


DateTime serializes to UTC by default... good, but then how to deserialize back to local time zone?

Hi @schultek, thanks for the package! In #125, you explained that: "The default mapper for DateTime transforms it to UTC when encoded, so that there is no problem when the value is passed to some other program in a different local timezone." This is great, because that's how most databases store DateTimes as well.
However, I noticed when deserializing, the resulting DateTime object is still in UTC. You also explained that: "Fyi be aware that you always can make your own mapper for DateTime and use it globally for all DateTime fields, if that helps." OK, so I will do that by copying and modifying DateTimeMapper and using MapperContainer.globals.use(LocalDateTimeMapper()); as the docs suggest.
IMHO, it might be good to do something like this (convert back to local if encoding mode was to UTC):
  @override
  DateTime decode(dynamic value) {
    final dateTime = switch(value) {
      String value => DateTime.parse(value),
      num value => DateTime.fromMillisecondsSinceEpoch(value.round()),
      _ => throw MapperException.unexpectedType(value.runtimeType, 'String or num'),
    };
    return switch (encodingMode) {
      DateTimeEncoding.iso8601String => dateTime,
      DateTimeEncoding.utcIso8601String => dateTime.toLocal(),
      DateTimeEncoding.millisSinceEpoc => dateTime,
    };
  }

I think it might be less surprising to users of this package if this were the default behavior, as I used a date picker in my app, then on refresh (restore from JSON) it was switching to UTC and I realized it was in the mapper. Of course, another DateTimeEncoding value could be added, i.e. DateTimeEncoding.localUtcIso8601String... Maybe/maybe not...
What do you think?

How about adding a DateTimeDecoding value to choose from e.g. "unchanged", "asUtc" and "asLocal".
Then its independent of the encoding, ans also not a breaking change.

my expectation here is that dart_mappable does not change the timezone of dates that I give it to serialize

How about adding a DateTimeDecoding value to choose from e.g. "unchanged", "asUtc" and "asLocal".
Then its independent of the encoding, ans also not a breaking change.

yes please, need one here as well


Contrast with alternatives

While both SBCL and ABCL provide package-local nicknames, and ASDF provides a potentially portable solution,

http://www.sbcl.org/manual/#Package_002dLocal-Nicknames
http://abcl.org/releases/1.3.3/abcl-1.3.3.pdf (page 39)
https://github.com/fare/package-renaming

I wonder if you'd found some interesting reasons not to pursue the alternatives.  Of course, one's own solution is its own reward.  I'm just curious.

Pseudonyms are as portable as reader macros are and works without any
destructive operations on packages itself; RENAME-PACKAGE modifies the
original package.
I haven't dug into Fare's package-renaming just yet; this does sound
promising, especially because it works at the package-loading level and
is dug into ASDF itself. Thanks for pointing this out!
On 25.04.2016 19:28, itegebo wrote:

While both SBCL and ABCL provide package-local nicknames, and ASDF
provides a potentially portable solution,

http://www.sbcl.org/manual/#Package_002dLocal-Nicknames
http://abcl.org/releases/1.3.3/abcl-1.3.3.pdf (page 39)
https://github.com/fare/package-renaming

I wonder if you'd found some interesting reasons not to pursue the
alternatives. Of course, one's own solution is its own reward. I'm just
curious.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/phoe-krk/pseudonyms/issues/2

While I suspect the destructive RENAME-PACKAGE will have surprising side-effects, they're not clear to me.  Do you happen to have examples where RENAME-PACKAGE causes problems?  Is it strictly a concurrency concern?

Dependencies. When multiple package try to use a single package that you rename, you have to make changes in all of them. And what does it mean? Of course it means destructively modifying all other packages to depend on the package's new name.
And this doesn't anyhow ensure that any other package you want to load doesn't depend on the package you loaded; it literally breaks ASDF and Quicklisp as their dependency machine operate on system names.
RENAME-PACKAGE also has unpleasant undefined consequences as defined in the standard - http://clhs.lisp.se/Body/f_rn_pkg.htm

Found another project that does some contrasting of its own:
https://github.com/avodonosov/local-package-aliases

Ha ha ha! Exactly what I did from a slightly different perspective! :D
Thanks for finding this.


live_count isn't always accurate

Bug report
Describe the bug
The live_count on tables is only indicative, but we are using it on the frontend to determine the number of rows. We should see if there is a figure that is accurate always
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

insert thousands of rows into a database
query /tables
check live_count

Screenshots

Don't worry about the error he mentions, but this is the Dashboard after he has inserted 20m rows:

Relevant SO thread: https://stackoverflow.com/questions/2596670/how-do-you-find-the-row-count-for-all-your-tables-in-postgres
I see 2 options:

Stick with row count estimates, but run ANALYZE at some point (in FE, through /query? pg-api, in GET /tables?)
Get exact count with COUNT(*)

Getting updated count estimates should be enough though. Thoughts?

It's an interesting one - i think count(*) is a non-starter becuase it will be very expensive on large databases.
@steve-chavez I think PostgREST just brought out estimated counts in the headers right? What method is used to get accurate results?

@kiwicopple The method basically is: when the rows are small enough(configurable threshold) we use the exact count(*) otherwise if the rows are big(threshold surpassed) we use the planner count. Discussion and more details at: https://github.com/PostgREST/postgrest/issues/1378#issuecomment-531506803.

DBeaver fetches the first 200 by default but lets you manually trigger a count (I'm assuming exact count).
pgAdmin checks the count estimate (I think PostgREST uses LIMIT instead?), and it only counts the rows if the estimate is less than 2000 (configurable).
If we want to go with estimate counts, we should probably be more explicit that it's an estimate, not an exact count.

Yeah I think you're right Bobbie - should we change it to be more explicit? Then we can let the developer decide how they choose to get more accurate counts.
For Supabase, we can add the same logic to the Dashboard - if it's less than 2000 we will call count(*), and anything greater we can use the estimate


config.yml references default.css, not default.scss

Motivation
The following line looks like a slight typo in the config.yml file, since the skins are .scss files, not .css:
skin: "/assets/css/skins/default.css"
Suggestion
Even though the default will be used regardless, this should probably be:
skin: "/assets/css/skins/default.scss"
with an .scss extension, not .css

#357

If it’s changed to .scss it’ll 404 since Jekyll is converting the files to .css
.scss also won’t be read properly by this line in the head
https://github.com/mmistakes/so-simple-theme/blob/master/_includes/head.html#L27

In hindsight might have made more sense to abstract skin’s to names instead of paths to a file. default, light, etc.
Similar to what I do with my other theme.
https://mmistakes.github.io/minimal-mistakes/docs/configuration/#skin

Ok works for me. I'm not encountering an error so I'll close this out


Just fixed all of them upstream!


Remove unnecessary Clipper lib includes

Removes unnecessary Clipper lib includes.
Leftovers from previous refactoring or class splitting.

Thanks!


[AMORO-1548] Remove log4j 1.2.x

Why are the changes needed?

Close #1548
Scan the jar with DependencyCheck(https://github.com/jeremylong/DependencyCheck) and find some CRITICAL severity issues
Brief change log

Remove log4j 1.2.x vulnerabilities

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not documented)

LGTM


feature Request : Have Malloy as a python package

can we have Malloy as a python package, I would like to use it with Streamlit for interactive Reporting.

I will close it for now, not sure how the whole thing may works


Integrate raw wgpu textures into vello rendering pipeline

Closes #1861

This can be tested by dragging an image into the editor and adding an upload texture node:


Support ordering granularity different from query granularity for group-by queries

Related to #1926 or #1780.
This patch is first try to introduce ordering granularity which is not equal to query granularity for group by queries. By giving some granularity to limit spec, which is supposed to be bigger than query granularity,
For example, user can group-by a table with day-basis and extract some outstanding values within a week.

Addressed comments & added limitPerGroup attribute with some tests.

@navis Following up on this PR, any updates on addressing @vogievetsky's comments so we can get this in?

@fjy It's useful in some cases but as @himanshug commented, It can use much more memory than before. Maybe some threshold numbers might be needed. Ideas?

rebased

@navis can you provide some more context on what this is doing and the types of queries it meant to support?

@fjy Basically it's for regrouping/reordering the result of group-by query with different granularity with query granularity in-memory before forwarding it to client. For example, we can make a metric in day granularity. But if we need it to be sorted in a week we should do it in client or make nested-groupby query which is expensive than this (and still cannot solve some cases). We've used this once but proceeded to another way which is tied under complex tree of in-house patches.  You can close this anytime.


New-Command: outlook report mailappusageappsusercounts

Implements #1213

Coverage remained the same at 100.0% when pulling a44d9ad070baedf74e049105cae0c743e4d8bd84 on plamber:outlook-report-mailappusageappsusercounts- into 0e5efd9d93e854d43547e9e1396e619ace74e34d on pnp:dev.

Thank you very much Patrick @plamber ! This is not manually merged in dev.


Switching between buttons in Home Screen is very slow

After loading a bunch of content into the flatlists toggling between buttons becomes extremely slow.
https://user-images.githubusercontent.com/5271307/222214095-6c5e9f2b-1162-47c8-8a3a-38da2b7369c2.mp4

Fixed by Tyler with #277


[Feature Request] Ability to set a ca-file path for OpenSSL or MbedTLS

The SSL certificates file (for example it is /etc/ssl/certs/ca-certificates.crt on ubuntu) in android is not stable, which mean android changed the path in various android releases, I think the best thing to avoid problems about this is way to set a ca-file  path for pegasocks

Or even can include trusted certificates into C codes, something like this

Thanks @chux0519


Adding useApp() function

Adding a useApp() method to start up a Node.js http.Server-based application on a brand new port or utilize a running server.

Coverage decreased (-0.15%) to 94.81% when pulling 9da7d5230777188ebf24c5c6c00505ab3413cff7 on useApp into 88ce9f739acab12a29eeefa27c13958bf6119fbf on master.

Coverage decreased (-0.13%) to 94.83% when pulling e89ee4b428d7259ee3b49d273a8592b6508cfcec on useApp into 88ce9f739acab12a29eeefa27c13958bf6119fbf on master.

Coverage increased (+0.18%) to 95.14% when pulling 8d72a3afcfa8f8a78b71b284a0c8e449c034811d on useApp into 88ce9f739acab12a29eeefa27c13958bf6119fbf on master.


Fix cli formatting option to print yaml

Issue: https://github.com/rancher/rancher/issues/27661
Fixed the format specific bug by upgrading the version of urfave/cli
yogesh@Yogeshs-MacBook-Pro:~/go/src/rancher/cli$ ./cli inspect --type cluster local --format yaml
agentFeatures:
  dashboard: true
agentImage: rancher/rancher-agent:master-head
agentImageOverride: ""
allocatable:
  cpu: "0"
  memory: "0"
  pods: "0"
annotations:
  authz.management.cattle.io/creator-role-bindings: '{"created":["cluster-owner"],"required":["cluster-owner"]}'
  lifecycle.cattle.io/create.cluster-agent-controller-cleanup: "true"
  lifecycle.cattle.io/create.cluster-provisioner-controller: "true"
  lifecycle.cattle.io/create.cluster-scoped-gc: "true"
  lifecycle.cattle.io/create.mgmt-cluster-rbac-remove: "true"
  provisioner.cattle.io/ke-driver-update: updated
answers:
  clusterId: null
  projectId: null
  type: /v3/schemas/answer
appliedEnableNetworkPolicy: false
appliedPodSecurityPolicyTemplateId: ""
appliedSpec:
  agentImageOverride: ""
  answers:
    clusterId: null
    projectId: null
    type: /v3/schemas/answer
  clusterTemplateId: null
  clusterTemplateRevisionId: null
  defaultClusterRoleForProjectMembers: null
  defaultPodSecurityPolicyTemplateId: null
  description: ""
  desiredAgentImage: ""
  desiredAuthImage: ""
  displayName: ""
  dockerRootDir: /var/lib/docker
  enableClusterAlerting: false
  enableClusterMonitoring: false
  enableNetworkPolicy: null
  internal: false
  localClusterAuthEndpoint:
    enabled: false
    type: /v3/schemas/localClusterAuthEndpoint
  type: /v3/schemas/clusterSpec
  windowsPreferedCluster: false
authImage: ""
baseType: cluster
capabilities:
  loadBalancerCapabilities:
    healthCheckSupported: false
    type: /v3/schemas/loadBalancerCapabilities
  nodePoolScalingSupported: false
  pspEnabled: false
  type: /v3/schemas/capabilities
capacity:
  cpu: "0"
  memory: "0"
  pods: "0"
clusterTemplateId: null
clusterTemplateRevisionId: null
componentStatuses:
- conditions:
  - message: ok
    status: "True"
    type: Healthy
  name: controller-manager
  type: /v3/schemas/clusterComponentStatus
- conditions:
  - message: '{"health":"true"}'
    status: "True"
    type: Healthy
  name: etcd-0
  type: /v3/schemas/clusterComponentStatus
- conditions:
  - message: ok
    status: "True"
    type: Healthy
  name: scheduler
  type: /v3/schemas/clusterComponentStatus
conditions:
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: BackingNamespaceCreated
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: DefaultProjectCreated
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: SystemProjectCreated
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: InitialRolesPopulated
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: CreatorMadeOwner
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: Pending
- lastUpdateTime: "2020-06-30T19:02:57-07:00"
  status: "True"
  type: Provisioned
- lastUpdateTime: "2020-06-30T19:03:07-07:00"
  status: "True"
  type: Waiting
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: NoDiskPressure
- lastUpdateTime: "2020-06-30T19:02:52-07:00"
  status: "True"
  type: NoMemoryPressure
- lastUpdateTime: "2020-06-30T19:02:55-07:00"
  status: "False"
  type: AlertingEnabled
- lastUpdateTime: "2020-06-30T19:02:56-07:00"
  status: "True"
  type: SystemAccountCreated
- lastUpdateTime: "2020-06-30T19:04:25-07:00"
  status: "True"
  type: AgentDeployed
- lastUpdateTime: "2020-06-30T19:02:57-07:00"
  status: "True"
  type: Updated
- lastUpdateTime: "2020-06-30T19:02:57-07:00"
  status: "True"
  type: GlobalAdminsSynced
- lastUpdateTime: "2020-06-30T19:03:07-07:00"
  status: "True"
  type: Ready
- lastUpdateTime: "2020-06-30T19:04:25-07:00"
  status: "False"
  type: PrometheusOperatorDeployed
created: "2020-07-01T02:02:52Z"
createdTS:<PHONE_NUMBER>000
creatorId: user-ph5pg
defaultClusterRoleForProjectMembers: null
defaultPodSecurityPolicyTemplateId: null
description: ""
desiredAgentImage: ""
desiredAuthImage: ""
dockerRootDir: /var/lib/docker
driver: imported
enableClusterAlerting: false
enableClusterMonitoring: false
enableNetworkPolicy: null
id: local
internal: true
istioEnabled: false
labels:
  cattle.io/creator: norman
limits:
  cpu: "0"
  memory: "0"
  pods: "0"
localClusterAuthEndpoint:
  enabled: false
  type: /v3/schemas/localClusterAuthEndpoint
name: local
nodeCount: 1
nodeVersion: 0
requested:
  cpu: "0"
  memory: "0"
  pods: "0"
state: active
transitioning: "no"
transitioningMessage: ""
type: cluster
uuid: 57185828-595f-4557-8565-2323dbce6202
version:
  buildDate: "2019-09-18T14:27:17Z"
  compiler: gc
  gitCommit: 2bd9643cee5b3b3a5ecbd3af49d09018f0773c77
  gitTreeState: clean
  gitVersion: v1.16.0
  goVersion: go1.12.9
  major: "1"
  minor: "16"
  platform: linux/amd64
  type: /v3/schemas/info
windowsPreferedCluster: false

yogesh@Yogeshs-MacBook-Pro:~/go/src/rancher/cli$

@yogeshmundada this will most likely fix this issue as well, right? https://github.com/rancher/rancher/issues/27376

If possible, I think we should release a new CLI independent of Rancher to fix the parsing bugs that will break a lot of people's automation. What do you think @dramich ?

If possible, I think we should release a new CLI independent of Rancher to fix the parsing bugs that will break a lot of people's automation. What do you think @dramich ?

Yeah, that sounds good.

@deniseschannon I am testing if the other issue gets fixed.


TypeScript Language Server failing - VS Code getting modified - macOS

Type: Bug
After opening a TypeScript file in Visual Studio Code (V1.70.1) in my project on macOS Monterey V12.5 (21G72), a system dialog will occasionally briefly appear saying Verifying "Visual Studio Code.app" and then disappear, this results in the TypeScript Language Server failing and causes missing and incorrect type information in the TypeScript file.

It appears that something is modifying the application at random regular intervals (~every 10 minutes) as the Modified timestamp is frequently updated.

I have tried a system reboot and deleting the application (including deleting user data) and installing clean version of Visual Studio Code but the problem persists.
VS Code version: Code 1.70.1 (Universal) (6d9b74a70ca9c7733b29f0456fd8195364076dda, 2022-08-10T06:09:06.916Z)
OS version: Darwin x64 21.6.0
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz (8 x 2000)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 3

Memory (System)
16.00GB (0.09GB free)

Process Argv
--crash-reporter-id 43d0c62b-5756-49eb-8fe6-8555f5fa4c4b

Screen Reader
no

VM
0%

Extensions (10)

Extension
Author (truncated)
Version

ng-template
Ang
14.1.0

vscode-eslint
dba
2.2.6

gitlens
eam
12.1.2

vscode-great-icons
emm
2.1.86

vsc-material-theme-icons
equ
2.3.1

file-icons
fil
1.0.29

fluent-icons
mig
0.0.18

material-icon-theme
PKi
4.19.0

gitblame
wad
9.0.1

material-theme
zhu
3.15.2

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
wslgetstarted:30449410
cppdebug:30492333
pylanb8912:30545647
vsclangdc:30486549
c4g48928:30535728
d7fjc500:30543455
dsvsc012cf:30540253
azure-dev_surveyone:30548225

This sounds like something external to VS Code, such as misbehaving anti-virus software
Since we haven't see more reports of this and don't have any leads on what is going wrong, I'm close this issue


basemap library updated on GitHub

Hey feedstock maintainers. basemap has been updated with a fix for the way numpy 1.14 handles io. Could you please update so we get the latest in conda-forge?

@scollis the latest release is https://github.com/matplotlib/basemap/releases/tag/v1.1.0
I'll try to find the changes and patch it but it would be nice to have a new official release instead.

@scollis I could not find the commits to create a patch. Can you point me to those changes?

Ping @WeatherGod

This is the specific one that motivates my request: https://github.com/matplotlib/basemap/pull/386
Fixed issues with dep. warnings in my unit tests for Py-ART

I thought the feedstock just tracks master? Would it be enough if I made tags?

I thought the feedstock just tracks master?

Nope. We only do that in the last case scenario for abandoned projects that won't get a release anytime soon.

Would it be enough if I made tags?

Ideally an official release is better but we can use tags. However, I already backported that change and if @scollis is OK with that solution you don't need to worry about a new release for now.


Qt 5.12 update

Qt 5.12 is the new LTS release. The goal of this issue is to track the progress of upgrading meta-qt5 to Qt 5.12.

Is it possible it could just need to switch commit SHA hashes and give it a go? If so, I can test it if someone can point me to those sha's.

Which new module? If so, maybe we can build everything and give it a go, Qt modules are independent by nature, unless there's something im missing.

latest 5.12 is quite broken presently. There are exclusive commits now in both 5.12 & 5.12.1 branches in varying amounts depending on module. I'll try to compose an 'upgrade to 5.12.0' commit to master now that I got 5.11.3 done,

https://github.com/meta-qt5/meta-qt5/pull/143


htimediff

move function htimediff a blackstacl-core
documentar funcion htimediff en blackstack-core

This is done.


Feature Request: Search bar on "Your Server"

Hello it would be great to add a Search Bar here
http://f.cgm.rs/opera_2017-02-18_09-47-33.png
Would make life easier for a lot of us, also adding different filters to the search like NODE

Added in the new theme https://github.com/Pterodactyl/Panel/commit/b926d432e8011fd540e02f398037dda4420dea4a


On a Mac it appears you also need XCode command line tools installed

Suggest that the prerequisites include XCode command line tools for Mac when installing on MacOS. These can be installed with xcode-select --install. Without these installed the command az extension add --name connectedk8s fails.
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: df16df9a-a855-2512-5e26-baec15e3be88
Version Independent ID: c77f255b-57c9-7e2d-2b10-98a8fe538376
Content: Quickstart: Connect an existing Kubernetes cluster to Azure Arc - Azure Arc
Content Source: articles/azure-arc/kubernetes/quickstart-connect-cluster.md
Service: azure-arc
Sub-service: azure-arc-kubernetes
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

#reassign: @shashankbarsin who manages the content for Arc-enabled Kubernetes. I am mistakenly tagged in the metadata as the author for this content.

#reassign:JnHs

Hi @imercerwillow - first of all, let me apologize for the extremely long time it's taken to respond to this issue. Given that it has been so long and many updates have been made to connectedk8s and the CLI in general, I'm wondering if you can confirm this is still an issue with the current versions?

Hello again - since we haven't heard back, I'm going to close this issue now - hoping that this is no longer a problem, but please let us know if you have further feedback on this doc. Thanks!
#please-close


Use GitHub actions for the tests

Travis CI is no longer open-source friendly.

Thanks.
Something must be wrong with the actions. They seem to fail for some reason. Have not had time to check why...

They did work on my fork https://github.com/francoisfreitag/phpCAS/actions/runs/893744594.
I’ll investigate tomorrow if you didn’t solve it by then.


firefox opens in troubleshoot mode

when no instance of firefox is open (after quitting with cmd+q), firefox tries to open in troubleshoot mode
works fine when firefox is already open
is my config wrong? works fine when using google chrome
config:
cmd + alt - q : open -na "Firefox Developer Edition"

I found the problem: Firefox opens in troubleshooting mode when the Alt key is pressed at launch. Try changing the keybinding to something without Alt, such as ctrl + shift + q.

Thanks!


Partners component is off-center

The Community Partners component is off-center. It appears okay on mobile to medium viewports but bleeds out of the container on larger viewports. The text Community Partners also needs more padding from the previous section. I would like to write a pull request to fix this.

Hi @junelsolis Thanks for the report, please do!


Liga AC labs #7

An example with zero written explanation about concurrency in cats-effect.
Also relevant:
block Futures

Not to be merged.


pywal isn't in my path

I did a user install of pywal using pip3.
pip3 install --user pywal
This is successful, however when I open a new terminal and run wal or pywal it doesn't see it.
pip3 show pywal
Name: pywal
Version: 3.1.0
Summary: Generate and change color-schemes on the fly
Home-page: https://github.com/dylanaraps/pywal
Author: Dylan Araps
Author-email<EMAIL_ADDRESS>License: MIT
Location: /home/mikey/.local/lib/python3.6/site-packages
Requires:

I browsed to the location in this result.
pywal$ ls
backends      export.py    __main__.py  scripts       templates  wallpaper.py
colorschemes  image.py     __pycache__  sequences.py  theme.py
colors.py     __init__.py  reload.py    settings.py   util.py

It's as if I have all of the classes needed but not executable in order to run wal.
Also:
$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

When installing something through PIP with the --user option, you'll have to add the PIP install directory to your path (PIP tells you about this the first time but doesn't add it itself). The directory you have to add is $HOME/.local/bin. This is not a problem with Pywal.


[Feature Request] Zstandard Codecs to core OpenSearch

Is your feature request related to a problem? Please describe
Zstandard codecs (zstd & zstd_no_dict) were released in OS 2.9, and moved to a separate custom-codecs plugin repository.
We have had a stable GA for past five minor version releases for the Zstandard codecs, we should discuss on moving the codecs to core OpenSearch. This would help the users to use Zstandard codecs without having to install an additional plugin.
We also have the required library as a part of OpenSearch libs over here
Given the performance benefits we have seen, we can also explore the option of making codecs defaults for specific workloads (like timeseries etc.).
Describe the solution you'd like
Supporting Zstandard codecs in the core OpenSearch.
Related component
Indexing:Performance
Describe alternatives you've considered
No response
Additional context
No response

Out of curiosity, are there any perf tests results available?

zstd

Yes, https://opensearch.org/docs/latest/im-plugin/index-codecs/#benchmarking.

+1 on making this available within core (maybe even the default?).
We've observed ZSTD to provide better performance in quite a good amount of workloads while compressing better, and we already have required dependencies being loaded as part of the OpenSearch core. Also, since this has been part of the distribution we release for the past few versions, and we've not seen any issues, it makes a strong case to keep this available in core itself.
@backslasht @shwetathareja @Bukhtawar @dblock Thoughts on this?

Zstd codecs clearly emerge as winner optimizing for both compression and speed.
+1 on moving this to core.

+1 on moving to core


Does this crate only supports gRPC for querying contracts states?

I was trying to querying some data like cosmjs with a rpc, but it seems that cosmrs only supports gRPC.

There actually isn't any native gRPC support, and little RPC support in general, in CosmRS.
For Tendermint RPC (i.e. HTTP+JSON [rpc]), see https://docs.rs/tendermint-rpc/
Note: gRPC support is currently in Ocular: https://github.com/PeggyJV/ocular

@tony-iqlusion But how can I query some contract state?
In cosmjs lib, I can do:
  const queryClient = await CosmWasmClient.connect(RPC_URL);
   const queryMessage = {
    pairs: {
      limit: 10,
    },
  };

  const queryResult = await queryClient.queryContractSmart(
    '<MY_ADDRESS>',
    queryMessage
  );

I can't find a way to do it with a rust crate. I'm a little bit confused, as I can't find some examples.
I'm more used to EVM networks and still learning how to interact with cosmos blockchains like SEI, JUNO, etc.

I'm not sure of a solution. If you'd like to contribute the relevant RPCs to CosmRS, we'd accept them.

@tony-iqlusion I find a way to do this.
Maybe I'ill open a PR with some examples of queries/msgs.


Allow skipping to future rounds from QUALITY phase

Update the core protocol implementation to allow skipping to future rounds from QUALITY phase. This reduces the conditions to requiring an instance to only fully execute DECIDE phase. Otherwise, the instance may jump ahead as long as all queued messages are processed.
As a result, the implementation no longer needs to check for QUALITY phase transition on receiving alarms.
Fixes #278

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.72%. Comparing base (f7a099e) to head (ca5d2d6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #279      +/-   ##
==========================================
- Coverage   70.72%   70.72%   -0.01%
==========================================
  Files          33       33
  Lines        2453     2446       -7
==========================================
- Hits         1735     1730       -5
+ Misses        583      582       -1
+ Partials      135      134       -1

Files
Coverage Δ

gpbft/gpbft.go
82.75% <100.00%> (+0.12%)
:arrow_up:


Dark grey font on dark background is very hard to read

There is a dark grey text color that appears in a variety of places that is very difficult to read against the dark blue background.
Example: http://i.imgur.com/wwzalF4.png
Seen in:

Profile descriptions during search results
In the "change" trends window
Usernames and some news descriptions in Moments capsules

I'm happy to submit a PR.

Should have been fixed by #18


C++ interface for providing columns by name

Similarly to the possibility to hand over dictionaries that specify column names in the Python API, it would be useful to have support for maps or a compile-time solution that allows doing this in C++. This helps mitigate issues where columns are handed over in the wrong order.

A partial implementation was discussed also in https://github.com/cms-nanoAOD/correctionlib/issues/8#issuecomment-768395908

Somewhat surprising, the python highlevel correction does not accept keyword arguments, even though it would be a trivial addition:
https://github.com/cms-nanoAOD/correctionlib/blob/35039dbeeebe6f0731610d0abd82050e6a35fd25/src/correctionlib/highlevel.py#L88-L90


[6/x] change venft enable logic in project tools drawer

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #1654

PR #1655

PR #1656

PR #1657

PR #1658

PR #1659   👈

This comment was auto-generated by Graphite.


Add flake8 to travis built.

PR looks ok (especially when travis finds existing PEP8 violations :smile: )
Let's merge it after #1234


Can you provide an example that can run accurately

I can't use it normally in the nuxt3 project

same here with Next14, did u find an alt?

I gave up this plan and decided to let the backend developer handle this business.


Documentation should conform to that of the python-project template

Short description of the changes:

Long description of the changes:

Check list for the pull request

[ ] I have read the [CONTRIBUTING]
[ ] I have read the [CODE_OF_CONDUCT]
[ ] I have added tests for my changes
[ ] I have updated the documentation accordingly

Check list for the reviewer

[ ] I have read the [CONTRIBUTING]
[ ] I have verified the proposed changes
[ ] best software practices

[ ] all internal functions have an underbar, as is python standard
[ ] clearly named variables (better to be verbose in variable names)
[ ] code comments explaining the intent of code blocks

[ ] All the tests are passing
[ ] The documentation is up to date
[ ] code comments added when explaining intent

Manual test for the reviewer

References

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (next@569ac33). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             next      #37   +/-   ##
=======================================
  Coverage        ?   82.36%
=======================================
  Files           ?       20
  Lines           ?     2280
  Branches        ?        0
=======================================
  Hits            ?     1878
  Misses          ?      402
  Partials        ?        0

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


Move npm libs under a definitions/npm/ namespace

We've talked on the Flow team about potentially moving even internal libdefs into flow-typed one day.
Additionally there are some JS libraries out there that just aren't on npm.
In order to preserve future option value for these circumstances, I figured we should just move npm-package libdefs into their own directory namespace to leave room for non-npm libdefs in the future.

The only downside to waiting and doing this later is that people will have npm install -g-ed the old version of the CLI -- which won't understand the new directory structure.
In that case we could just bump the minimumCLIVersion number (which would prevent those users from rebasing until they upgraded) -- but I figured we could save everyone the thrash if we just do it now.

So what is blocking the merge of this repo?

Nothing really, just wanted to give other collabs a chance to see it before I merged


Question about "pending:" print statements

Hey, awesome library. I've got a low-priority question. I'm seeing this in my console when dismissing a view controller back to one of my views where I have a collection view with EasyAnimation running in the cells:
pending: bounds from NSRect: {{0, 0}, {0, 0}} to Optional(NSRect: {{0, 0}, {414, 0}})
pending: position from NSPoint: {0, 0} to Optional(NSPoint: {207, 1})
pending: bounds from NSRect: {{0, 0}, {0, 0}} to Optional(NSRect: {{0, 0}, {414, 0}})
pending: position from NSPoint: {0, 0} to Optional(NSPoint: {207, 0})
pending: bounds from NSRect: {{0, 0}, {0, 0}} to Optional(NSRect: {{0, 0}, {8, 13}})
pending: position from NSPoint: {0, 0} to Optional(NSPoint: {402, -0.5})
pending: position from NSPoint: {207, 1} to Optional(NSPoint: {207, 1})
pending: opacity from 1 to Optional(1)
pending: bounds from NSRect: {{0, 0}, {0, 0}} to Optional(NSRect: {{0, 0}, {141.66666666666666, 253}})
pending: position from NSPoint: {0, 0} to Optional(NSPoint: {70.833333333333329, 126.5})

I am not so worried about the statements printing, but I'm unsure how to react. Does this necessarily mean I'm misusing animations in some way, or is EasyAnimation just letting me know what's going on?

This is debug info, it's been fixed - just get the latest pod version next week to get rid of it

Hey,
When is the next release?

Nothing in particular is scheduled, if I merge any PRs we'll certainly release them

referring to the debug info issue someone stated here , it is still there :)

oh, I'll look into that, thanks for noticing


Release tracking PR: v0.12.0

In preparation for release add a changelog entry and bump the version.
(Includes a patch up front to upgrade the version of upload-artifact and download-artifact actions to fix the fuzz CI job.)

Do you want #200 to go into this @apoelstra?

@tcharding yeah -- I'm actually pretty close to having error correction working but it'll require a few more breaking changes.
In particular I need to add a few more fields to the Checksum trait which will break all users that implement that. This is an annoying but ultimately mechanical fix (you need to use the PrintImpl object and print it then copy/paste the result into your code). This might actually be the only breaking change other than #200, but I'm not sure.
I'm tempted to hold off on this release until correction is done, but if the LDK people really want these latest PRs then I'd like to get #200 in and also I'll PR the new Checksum changes, without the rest of error correction, and I'll try to do the rest without further breakage.

Converting to draft to give you a minute to work on the error corrections stuff.

Are we urgently waiting on a release? I still have some error correction API work to do and I think it may be breaking.

No rush at all, my bad.


Library for Line Chart Race?

I found and used a Bar Chart Race library for Python which I found very useful.
Is there a similar library for Line Chart (Graph) Race?
Thanks

Check out sjvisualizer


Decoding is inconsistent across output formats

Run ./build/tools/djxl ./third_party/testdata/jxl/spline_on_first_frame.jxl ./out.{format}

{format}
result
debug messages

jpg
OK

exr
OK

png
wrong image (intermediate frame)

apng
"Failed to write decoded image."
"Cannot encode using Codec::kUnknown"

gif
"Failed to write decoded image."
"Encoding to GIF is not implemented"

pnm
"Failed to write decoded image."
"Cannot encode using Codec::kUnknown"

psd
"Failed to write decoded image."
"PSD encoding not yet implemented"

pgx
"Failed to write decoded image."
"PGX encoder ignoring metadata - use a different codec", "PGX: must be grayscale"

pfm
"terminated by signal SIGILL (Illegal instruction)"
JXL_ASSERT: io.frames.size() == 1

abracadabra
"Failed to write decoded image."
"Cannot encode using Codec::kUnknown"

At least, for "gif" and unknown we should have more meaningful report.

Seems to be more consistent now. Do you think more is needed, @eustas?

{format}
result
debug messages

jpg
OK

exr
OK

png
OK

apng
OK

gif
can't decode to the file extension '.gif'

pnm
can't decode to the file extension '.pnm'

psd
can't decode to the file extension '.psd'

pgx
SelectFormat failed DecompressJxlToPackedPixelFile failed
JXL_FAILURE: no appropriate format found

pfm
OK

abracadabra
can't decode to the file extension '.abracadabra'

pgm
SelectFormat failed DecompressJxlToPackedPixelFile failed
JXL_FAILURE: no appropriate format found

Yup! Thanks.


node:events:505       throw er; // Unhandled 'error' event

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
hugo server --port 8300 --disableFastRender
node:events:505
throw er; // Unhandled 'error' event
^
Error: spawn C:\Users\10016\IdeaProjects\bootstrap\node_modules\hugo-bin\vendor\hugo.exe ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
at onErrorNT (node:internal/child_process:476:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
at onErrorNT (node:internal/child_process:476:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -4058,
code: 'ENOENT',
syscall: 'spawn C:\Users\10016\IdeaProjects\bootstrap\node_modules\hugo-bin\vendor\hugo.exe',
path: 'C:\Users\10016\IdeaProjects\bootstrap\node_modules\hugo-bin\vendor\hugo.exe',
spawnargs: [ 'server', '--port', '8300', '--disableFastRender' ]
Reduced test cases
Download the latest release
Clone the repo: git clone https://github.com/twbs/bootstrap.git
Install with npm: npm install<EMAIL_ADDRESS>Install with yarn: yarn add<EMAIL_ADDRESS>after this yarn start or npm start
same error get
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome
What version of Bootstrap are you using?
5.1.2

FWIW I understood you cloned the repo and  installed Bootstrap through npm. I don't know what you're trying to do but this is incorrect, for sure.
Either you use our sources and run the local docs site (using Hugo) in order to contribute, or you install Bootstrap as a dependency and use it, but you can't do both.

ijust got the same error.... but i changed the port. have a look
i had the port: 3000 firstly.

then i changed to another port: 8080.

and this disappeared. perhaps it ll work on your problem.


Fixed Issue #993

Related Issue
None
Fixes:  #993
Description
I have changed Faq to FAQ in Quick Links in Footer Section
Issue:- #993
Type of PR

[x] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
Here is a screenshot,
Before

After

Checklist:

[x] I have made this change from my own.
[ ] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

Hey @RitiChandak
Please add labels to this PR.
Thank you for assigning me this issue.

@RitiChandak
Please add level label to it


Planning Documentation/Templates for Future Automation of Evals

Because
the goal is to improve the automation of future evaluation tasks (as opposed to updating current evaluations to become automatic), brainstorming of what components could be used to increase the automaticness of running the evaluations should be considered.
This issue will focus on what formats/templates/common practices should be adhered to allow for better automation into this process.
Done when

[ ] A template for future tasks in general, using goldretriever, having the same invocation should be created. This can then be followed for future tasks. Importantly, some error handling, especially at the level of basic sanity tests like outputting the same number of expected files should be present.
[ ] A template for readmes should be created to describe before full automation how to run the apps.
[ ] A template for reports generated by the eval should be created. However, the similarity of each task's report is still in discussion. It is still to be determined how much of the report can be automatically generated.

Additional context
Questions to consider for moving towards automation:

How does one make the process more automatic than downloading the eval repo, placing the mmif predictions in the correct place and running the code?

Should the evaluation code be wrapped in a docker app that also contains the needed environment and modules to run it?
Perhaps one could run one app, select the task for which to evaluate for, and the app could handle the rest?

Where should generated mmifs or other system outputs be placed. Should any of that be automatic?

What other todos and concerns should improve this process flow?

How does one make the process more automatic than downloading the eval repo, placing the mmif predictions in the correct place and running the code?

It seems like the invocation of evaluation could be automatically triggered if a new commit of prediction mmifs is placed in a certain place, for instance, inside a subdir/task-dir of the aapb-evaluations repository. This could trigger an action that will run evaluation code automatically.


Adding dev-spaces extension under the aks module

use-dev-spaces

Installs AZDS cli tool (if doesnot exist)
Creates and Selects Dev Spaces resource
remove-dev-spaces
Deletes the resource

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/saurabsa/azure-cli-extensions.git@saurabsa/DevConnectExtension#subdirectory=src/$EXT&egg=$EXT"

@saurabsa almost there, just add yourself as codeowner :)


custom-built font refuses to load, pre-built counterpart works fine

the iosevka font works great on vscode. though, for iosevka, there are a bunch of neat customization options you get to switch on/off when you build it manually. so i did!
the font works as intended in other editors like sublime text and notepad, but when i enter the name of the font into vscode settings, it doesn't seem to recognize it exists (exhibits same behavior as if i typed in gibberish or a font i haven't installed)
i've built a version of the font with no additions whatsoever, and that one doesn't seem load either.
it looks like vscode doesn't seem to acknowledge manually built fonts. any ideas?

VSCode Version: 1.41.1
OS Version: Windows 10 Education (64-bit)

Steps to Reproduce:

install this font (iosevka-custom-regular.zip)

change font to Iosevka Custom

Does this issue occur when all extensions are disabled?: Yes

note: just fired up vscode insider and it works there. this is no longer a problem to me but it may still be worth looking into

Please remove it immediately and make it your top priority. To me this is almost equally offensive as a swastika.

Please remove it immediately and make it your top priority. To me this is almost equally offensive as a swastika.

what?


Synchronize aborts

Fix attempting to nip in bud possible race conditions and catching possible illegal state exceptions. Only one crash, nothing major.
https://fabric.io/zulip2/android/apps/com.zulip.android/issues/57bb9cdeffcdc0425018ab04

Automated message from Dropbox CLA bot
@koziodigitalinc, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

lgtm. Thanks!


np.genfromtxt time consumption

Dear Scivision,
I put your latest release v1.6.1 in a profiler. After getting rid of xarrax.concat and .merge, the new bottle neck is the 'np.genfromtxt' function:
darr = np.genfromtxt(BytesIO(raws.encode('ascii')), delimiter=[Lf, 1, 1]*hdr['Nobs'])

I know np.genfromtxt is handy, but not the fastest. Did you checkout pandas.read_csv or pandas.read_fwf? Alternatively, a specialized self-written read function may be quickest. I think it is worth spending some extra thoughts on this one, since it is the center-piece of the whole software.

The current master commit has implemented the full ~20x speedup over v1.6.0, which is an additional 2x speedup over v1.6.1, by using a pure Python implementation instead of np.genfromtxt

I see you actually changed quite a lot in the code to achieve this, but you managed to improve the speed by moving away from np.genfromtxt.
Thanks for the update!


It's impossible to prevent change of url in ontap handler

Not sure if that's a bug, but docs encourage usage of ontap instead of onclick to wrap both mouse and touch events.
I would like to handle my links without having them change my url, which I usually can do with e.preventDefault(). But in case of ontap doing inEvent.preventNativeDefault() does nothing, since ontap is fired on mouseup event. So I ended up with binding onclick and preventing change on url there. Any thoughts?

Preventing links by using a handler for the onclick event and calling e.preventDefault() is what's intended.
The cross platform ontap, ondown, onup etc. events are intended to handle the majority of use cases, but there are times like this when a specific native event should be used. In this case, we've opted not to generate our ontap event based on the onclick event. We've done this to normalize behavior across desktop and mobile platforms: onclick is sometimes not called on mobile and even on desktop the various browsers differ on when and how to fire a click event. We recently added the preventNativeDefault method to our cross platform events as a convenience to call preventDefault on the native event that spawned the cross platform event. It's currently most useful for the ondown and onmove events.