Don't install unneeded dependencies for lint

Linting is currently the longest-running CI workflow, and it installs all the requirements needed for running the system, which is wasteful.
https://github.com/hasadna/anyway/blob/dev/.github/workflows/Tests.yml#L23-L37
We can either

Merge it with pytest, black, or both; or
Add a dedicated requirements file

@elazarg can you elaborate?

@atalyaalon I have updated the description.

https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/

This is a great idea! I wonder why do you think we should migrate to another framework (since the actual tests are far slower than the pylint/eslint/black)?.
GitHub Super Linter was announced less than a month ago, we might want to let it "mature" a bit before starting to rely on it by removing other linters.

I'm not sure we should use SuperLinter, but I think we should definitely consider it.
I don't think I understand you comment about migrating to another framework.

I meant moving from working with pylint directly to moving to the super linter


chore: 🤖 Changed test to include linting

In order to make contributing easier, the test command now also runs
lint. If you want a continuous test runner for development, run yarn test:dev

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:


Failed to Parse address with PLACE as posttype when state name is absent

Parsing result of the following address is incorrect.
413 N 133RD PLACE PHOENIX 85018

However, slight change to the following forms worked.
413 N 133RD PL PHOENIX 85018
4135 N 33RD PLACE PHOENIX AZ 85018

Can this be handled via training?

Interesting find! New training will indeed help here. Do you have a few more examples of this pattern from real-world data on hand?

@jeancochrane
We have quite a few of them.  For the most part the two examples show the pattern that fails unless PLACE is not replaced with PL:
130 N 49TH PLACE	SCOTTSDALE	85200
100 OWL PLACE	FLAGSTAFF	86000

But strangely, the following entry works without needing the change
22000 E  DESERT KNOLL PLACE ORA VALLEY  85700

This pair is simply bizarre!  Give it a try, - replacing PLACE with PL does not make any difference.  It seems the NLP engine is dependent on the value of the zip code.
322 N 56TH PLACE	CAVE CREEK	85000
322 N 56TH PLACE	CAVE CREEK	85334


Add GitHub action to update dependencies periodically/manually

This won't touch the deploy directory

Will use dependabot


Provides the ability to natively load 3d tiles resources while making it easy for developers to create digital twin projects with Cesium.

We only accept feature requests that are discussed on the BabylonJS forum
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The use of 3D engine to develop digital twins in China is very hot, there may be tens of billions of markets in the future, and almost all projects need to be displayed with browsers, Babylon has great potential, but in the Chinese platform, there is very little relevant information, especially the lack of complete sets, zero-based series of videos, I hope you can open some official accounts, release some teaching video collections, in addition, China's digital twin projects, often design a large area, including sites, buildings, such as smart cities, Even including indoor scenes, so that the model is often very large, then use Babylon to load, the speed is very slow, can not meet the needs of users, a possible way is to use the model's tile data format to load, such as 3d tiles such a format, but Babylon does not seem to natively support the loading of files in these formats, I hope you can add the function of supporting such files, especially do not have the problem of breaking the surface, at the same time, GIS information such as terrain often needs to be operated in the project, Babylon doesn't seem to be easy to use, such as some of Cesium's capabilities, such as I want to put the project model on the earth of Cesium, users can browse from the earth to the ground, which is very common in China's digital twin projects, I hope you can think of some ways to make it easy for developers to achieve similar effects, and finally, I really hope you can open a demo video, just use Babylon to make a smart city, including indoor and outdoor, while doing and explaining, This is not only convenient for other beginners, but also contributes to the future metaverse
Describe the solution you'd like
A clear and concise description of what you want to happen.
The desire was to provide the ability to load tile resources natively, while making it easy for developers to create digital twin projects using Cesium. The former seems to have some plugins that can do it, but a lot of problems, especially broken surfaces, the latter is even more difficult, I hope you can help solve it
Discussion
You must provide a link to the forum post where the initial discussion happened

Please use the forum for feature requests

Please use the forum for feature requests

Please tell me the address of the forum

Forum.babylonjs.com :)


OTA update with deconz

Hey @mjuhanne, thx a lot for this custom FW.
Currently running 7x fyrturs/kradjil with original firmware 2.2.009. They are working reliable but a bit noisy. Especially in the sleeping room this is annoying, and I want to give your firmware a try.
I am running the blinds without the repeaters in my zigbee network on deconz/Phoscon and updated all 7x with the OTAU plugin to 2.2.009 over the air.
In the Readme you are describing of flashing with STLink, this I want to avoid because of demounting and mounting.
Is it possible to flash/get '.zigbee' and '.ota.signed' files and flash them with deconz OTAU plugin without demounting the blind's?
Thx

Ah, now I'll see.
That's two independent firmware/CPUs.
One for wireless module (zigbee) and one for the motor control, which you reverse engineered.
Is there any sort of bootloader on the STM32 motor module which we can use to OTA update?

Hello!
OTA update of the STM32 motor module has been crossed my mind few times before but I haven't yet made any effort to develop it until now.
TLDR; OTA update IS possible, but unfortunately I don't know any way to force it from original firmware without first disassembling the motor module and flashing the custom firmware first via ST-Link.

Firmware of STM32F030 can be updated via UART (in addition to the Serial-Wire Debug interface that's mentioned in Readme file).  But it seems that Ikea (or the manufacturer of the motor module, which I think has been outsourced) did not want to (or see the need to) have the possibility to update the STM32 firmware after initial firmware writing during assembly.    A testament to this is that the re-programming via UART requires controlling both RESET and BOOT0 pins and while the former is there on the SWD header, the latter pin is not even connected anywhere!
I proceeded by carefully soldering a wire to the BOOT0 pin of the STM32 itself, and I was able to update the firmware with ESP32 (see here), so now we know that OTA update IS possible.
Now, to make things easier, it should be possible to jump to the boot loader programmatically using custom UART command so BOOT0 pin (and consequently RESET pin as well) would not be needed. But if something happens with firmware upload, the module would be bricked since there's no way to force launching the boot loaded without those pins.  In theory one could make safeguards by modifying the ResetHandler so that boot loader is always launched if main program is not correctly run after certain timeout, but will get quite complicated fast.  The safest way would be to run the SWD wires outside module anyway (as it's done currently) in order to flash the firmware with ST-Link in case the module gets bricked.
I did make extensive reverse engineering of the original motor module firmware as well, and I did not find any commands that would hint of the possibility to update it via UART (such as jumping to the boot loader) so flashing the custom firmware with ST-Link is anyway required at least initially.

Thanks for your analysis and findings.
Sad that IKEA (or/and the manufacturer) did'nt find it usefull to also add OTA for the motor module.
For me i must think about if i dissasamble all my blinds (currently they are in warranty).
Maybe later :-)

@popy2k14 FYI, the motor module firmware has been enhanced with possibility to do OTA update (currently via the Fyrtur ESP32 module). Unfortunately one still needs to disassemble the motor unit and flash a custom firmware first. Subsequent updates can be then done as OTA update.

thx for the info and your efforts.
Sadly, i don't want to change the zigbee module to an esp32 because it works really good here (except the noise :-) )
Also don't want to disassemble it during the warranty.
Maybe i will open/flash the blinds at a later point int time :-)


Investigate pluggable pattern for extending the runtime

As a starting point, we want to try to separate out the Console callbacks in the runtime constructor and the NAPI object wrap of the Console into its own "module" and the TestApp is responsible for adding it if needed.
Future runtime objects will all be done using this kind of pattern.

We should also discuss how to replace an existing implementation of something that has a browser implementation in Babylon.js. For example, if we wanted to replace the WebRequest class, how do we create a tree-shaked js file that doesn't include WebRequest.


Fix: Wrong expiry date check + domain without info

Summary
Idk if there is a issue about this.
When I tried to solve this issue, I saw that maybe the PR #7 that tried to fix .br domains, was accepted even though it didn't work.
So I figure out that the problem is in the expiry date check, which does not check correctly when the variable was only initialized (in this case has a value less than 0).
Pay attention
This PR as it is, because how .br and .ua domains is trying to get expiry date. So maybe it's better to approve PR #8.
Checklist

[x] Tested and/or added tests to validate that the changes work as intended, if applicable.
[ ] Updated documentation in README.md, if applicable.

My bad, I already fixed the test with 9f681448ab8ddddba0ffef04ece33c02d25c6cde
Still, after the change, the tests worked on #8 so 🙌
Thank you for your contribution!


Add Line and Polygon Overlay

originally submitted as
https://github.com/thatcher/openseadragon/issues/3

This is now implemented by:
https://github.com/openseadragon/svg-overlay


[Samples][Java] Fix disparities of 03.welcome-user sample

Related to microsoft/botbuilder-java#1165
Proposed Changes
We compared the documentation/code migration/behavior of the 03.welcome-user sample between Java and C# and we found disparities and fixes that this PR includes.

Update README
Update the order or the activities in WelcomeUserBot that are sent just like C#
Add missing comments
Clean-up autogenerated files/folder related to Eclipse (e.g. target/.classpath)
Add package-info.java file

Testing
Welcome user sample working as expected

Hi @tracyboehrer & @LeeParrishMSFT, we created this PR fixing some disparities that we found in the 03.welcome-user sample.


Do we want to guarantee deepcopied attributes when converting ?

A reminiscence of #28:
# python >= 3.3, rough timing
import time

from attr import attributes, attr
from attr.validators import instance_of

def decode_if_needed(v):
    if isinstance(v, bytes):
        return v.decode()

@attributes
class Arch(object):
    name = attr("name")

@attributes
class ConvertedArch(object):
    name = attr("name", validator=instance_of(str), convert=decode_if_needed)

def timeit(func):
    times = []
    for i in range(10000):
        start = time.perf_counter()
        func()
        times.append(time.perf_counter() - start)
    return "Min cost across 10000 iterations: {:.2f} us".format(min(times) * 1e6)

print(timeit(lambda: Arch("x86")))
print(timeit(lambda: ConvertedArch(b"x86")))

Min cost across 10000 iterations: 1.40 us
Min cost across 10000 iterations: 43.72 us

Now, the fix may not be as trivial as #28, because I can see how it may be part of the API that the original attribute is not touched when using convert, and not using fields to iterate in https://github.com/hynek/attrs/blob/master/src/attr/_make.py#L447 would break that promise. As I have not seen any test related to this, maybe that promise could be relaxed ?

Eh could you rephrase + elaborate please?  I have a nasty head cold and can’t entirely follow. :)

Let me try again :)
As in #28, the speed difference is because we iterate over the attr descriptors using fields, which makes a deepcopy for every field.
In #28, we've fixed it by iterating using inst.__class__.__attrs_attrs__. I was about to prepare a PR to do the same here, but then realized that the deepcopy may have bene intentional in this case. If not, I will be happy to prepare a PR to fix this.

Um this would only matter, if someone would modify the attribute list in their container, right? (which they never should)

Ok, let me prepare a PR then.
What is the rationale for using deepcopy in fields then ?

I find there’s a difference between a public API like fields and misbehaving in an converter.  But maybe I’m wrong. :)

do you think you can get it done by say Wed?  I’d like to push out a release before PyCon

looks like I could ! Too bad I could not make it up this year at PyCon...

aw :(


Convert lat/lang to DD/MM/SS on boarding page

Related Issue

Fixes #450
Checklist:

[ ] I have read the contributor's guide.
[ ] I linked an issue in the previous section
[ ] I have commented on the linked issue
[ ] I was assigned the linked issue (not required)
[ ] I have tested the change to the best of my ability against the sandbox or a local build.

Optional items:

[ ] My change adds new text and requires a change to translations.
[ ] My change requires a change to the documentation.
[ ] I have submitted a PR to the documentation repo.
[ ] I was not able to test... (explain below, e.g. you did not have permissions to test a specific feature)
[ ] This change depends O-FISH Realm repository changes (explain below)

Before

After

Seconds should be rounded to 2 decimal places.

So this coordinate should be calculated as: 1° 5' 26.00"


Update internal CI to run on regular pool

Overview
In preparation for some upcoming changes, this PR moves us back off the custom one-off pool and back onto the "regular" shared pool of VMs.
Adding the workspace clean step seems to have fixed the issues we were previously seeing.

/azp run


ENH: Add SimpleExample.ipynb

This is a Jupyter lab that runs the al_bench tool through the bare minimum to show how it works.

Plots will require the ability to parse the al_bench output, which we do not do currently.  I am going to go ahead and merge this pull request and do the output / plots under a new pull request.


add close channel in defer func

Closed for no response for a long time.
Recreate a new pull request on your will :)
Forked repo will be deleted.


Training fails with torch.jit.script

I pulled the latest code and now training fails with error:
raise NotSupportedError(base.range(), "slicing multiple dimensions at the same time isn't supported yet")
torch.jit.frontend.NotSupportedError: slicing multiple dimensions at the same time isn't supported yet
@torch.jit.script
def fused_add_tanh_sigmoid_multiply(input_a, input_b,n_channels):
n_channels_int = n_channels[0]
in_act = input_a+input_b
t_act = torch.nn.functional.tanh(in_act[:, :n_channels_int, :])
~~~~~~ <--- HERE
s_act = torch.nn.functional.sigmoid(in_act[:,n_channels_int:, :])
acts = t_act * s_act
return acts

Thanks for letting us know,. We reverted the PR while working on a solution.

@dchaws Please pull from master and update your pytorch to 1.0

operation failed in interpreter:
@torch.jit.script
def fused_add_tanh_sigmoid_multiply(input_a, input_b, n_channels):
n_channels_int = n_channels[0]
in_act = input_a+input_b
~~~~~~~~~~~~~~~ <--- HERE
t_act = torch.tanh(in_act[:, :n_channels_int, :])
s_act = torch.sigmoid(in_act[:, n_channels_int:, :])
acts = t_act * s_act
return acts
pytorch 1.1

update to pytorch-1.0.0 but another question appears ,"ImportError: torch.utils.ffi is deprecated. Please use cpp extensions instead."


zerohub client

make sure client is properly implemented

implement j.client using our new config mgmt

learn how to do it in template for client

@rkhamis  isn't this the same as #6?

It seems to be using the right classes already. I went over most of the client's functions, and they are working fine.
I added a test.

Verification steps:

cl = j.clients.zhub.get("test")

cl.username = "abdelrad"

cl.token = "$MY_TOKEN"

cl.authenticate()

cl.save()

cl.upload('/tmp/my-upload-file.tar.gz')

cl.list('abdelrad')

cl.rename('my-upload-file.flist', 'my-super-flist.flist')

cl.repositories()

cl.delete_flist('my-super-flist.flist') works fine now , without changing anything.
cl.promote('abdelrahman', 'psql.flist', 'abdelrad')
cl.merge("test_merge", ["abdelrad/abdelrad.flist", "abdelrad/influxd.flist"])


Allowing the translation of the legend of the fieldset in the render function in the FormCollection Helper.

In the render function of the Zend/Form/View/Helper/FormCollection, the legend of the fieldset is not being translating.
I think, the code snippet should be like this---
// Every collection is wrapped by a fieldset if needed
if ($this->shouldWrap) {
$label = $element->getLabel();
if (!empty($label)) {
    $label = $escapeHtmlHelper($label);
    if (($translator = $this->getTranslator()) !== null) {
        $label = $translator->translate(
            $label, $this->getTranslatorTextDomain()
        );
    }

    $markup = sprintf(
        '<fieldset><legend>%s</legend>%s</fieldset>',
        $label,
        $markup
    );
}

}
No what do you think? I have faced this problem while working with the translation. Please suggest me if you have any.
Thank You.

This was added in #3532


docs(ja): update Formatter in japanese

Summary
Fixes part of updated tasks

Test Plan

@chansuke Thank you for your work. We split the formatter page to three at #1098 . Could you update for this?

@unvalley
Thank you so much for your comment. I've separated and also added option-philosophy translation.

@nissy-dev I appreciate for your review. I've fixed & squashed the commits.


Fork, Commit, Merge - Easy Issue 4 (Dart)

Fork, Commit, Merge - Easy Issue 4 (Dart)
Implement a Function That Returns a String Describing Its Data Type
Note: You don't have ask permission to start solving the issue or get assigned, since these issues are supposed to be always open for new contributors. The actions-user bot will reset the file back to previous state for the next contributor after your commit is merged. So you can just simply start working with the issue right away!
Issue created by Faiznurullah.
How to get started
Open the tasks/dart/easy directory from the root of your project.
Then open a file called type_data_check.dart and start implementing your solution!
Description
Implement a function called typeDataCheck that accepts a parameter of any type and returns a string describing its data type.
Acceptance Criteria:

The program must be written in Dart.
It should define a function called typeDataCheck, that accepts a parameter of any type and returns a string describing its data type.
Don't use any functions available in Dart itself, make your own function for this case.

How to run
You can run dart run tasks/dart/easy/type_data_check.dart in Terminal to check if it works as expected.

To work with this issue, you need to have Dart installed to your local machine.
Check out README.md for more instructions of installing Dart and how to make a pull request.
Feel free to ask any questions here if you have some problems!
Also, kindly give this project a star to enhance its visibility for new developers!

Hello @nikohoffren can I work upon this issue?

Hello @nikohoffren can I work upon this issue?

Sure! As it says on the description: You don't have ask permission to start solving the issue or get assigned, since these issues are supposed to be always open for new contributors. The actions-user bot will reset the file back to previous state for the next contributor after your commit is merged. So you can just simply start working with the issue right away!


[LAPACK][CUSOLVER] Add getri batch funcs

This adds getri batch funcs as well as getri (which calls getri_batch). The GetriBatch funcs are in CUBLAS, not CUSOLVER so some CMake changes were necessary.
Fixes # (GitHub issue)
https://github.com/oneapi-src/oneMKL/issues/229
Clang-formatted and tests passing locally.
I have not included the group funcs in this PR. Should I do so?

Clarification: I have not added the group USM functions since I don't want to give the user the impression that the group getri is calling some cublas<T>getriBatchedGroup or something similar. I can implement it so that it calls the getri_batch in this PR, although it will be easy enough for the user to do the same. Let me know your thoughts

Have all comments been addressed?

Can we get this merged.


go-config dependency issue

go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid pseudo-version: version before v0.1.0 would have negative patch number

micro/go-config is no longer supported please use go-micro/config

Hi @asim. I'm following the docs here, https://micro.mu/docs/go-config.html#sample-config are these out of date now? I can't find a reference that shows go-config usage with the package path you are mentioning.

@chmorgan aas @asim says, go-config is no more maintained.
It's been moved to go-micro/config

@asim, @milosgajdos83 what is the proper import?
I was using:
    "github.com/micro/go-config"
    "github.com/micro/go-config/source/file"

which is the cause of the above message, but if I switch this to import:
    "github.com/go-config/config"
    "github.com/go-config/config/source/file"

I get:
build bitbucket.org/chmorgan/solar_control/src/basiccontroller: cannot load github.com/go-config/config: git ls-remote -q origin in /Users/cmorgan/go/pkg/mod/cache/vcs/147e6d321d2e56acee364e13da41fea4b714e6757f710388ee519842fd55e97b: exit status 128:
remote: Repository not found.
fatal: repository 'https://github.com/go-config/config/' not found
What is the proper import?

Please read the doc https://micro.mu/docs/go-config.html#new-config
The import path is clearly stated as
github.com/micro/go-micro/config

@asim it was close enough to the old path that I thought it was the same one or that you were suggesting it didn’t have the micro prefix, there are a number of projects moving to short url modules these days.
Thank you for the clarification and pointer to the docs with the correct import path.


Still possibly overflow

Add some fixes to https://github.com/vim/vim/pull/3999

I'll add some fix about local_bufsize.

Codecov Report

Merging #4002 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4002      +/-   ##
==========================================
+ Coverage   79.13%   79.14%   +<.01%
==========================================
  Files         105      105
  Lines      141111   141111
==========================================
+ Hits       111669   111679      +10
+ Misses      29442    29432      -10

Impacted Files
Coverage Δ

src/ex_cmds2.c
84.89% <0%> (-0.1%)
:arrow_down:

src/screen.c
80.3% <0%> (-0.03%)
:arrow_down:

src/window.c
83.53% <0%> (ø)
:arrow_up:

src/terminal.c
78.25% <0%> (+0.04%)
:arrow_up:

src/ui.c
50.22% <0%> (+0.07%)
:arrow_up:

src/gui.c
58.05% <0%> (+0.15%)
:arrow_up:

src/ex_cmds.c
81.85% <0%> (+0.24%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bbd854d...4244cee. Read the comment docs.


Spike into using database 'views'

It would be nice to have some interim feedback on whether this exploration looks like its going in a good direction.
Database 'views' are like virtual tables made from pre-defined queries. The intent here is to tidy up some of the back-end logic by putting commonly used information about groups of packets into a single reusable piece of code. Since the intention of the view is to gather what's used for displaying information about packet groups, I've provisionally called it 'packet_group_display_view'.
This reduces (to zero) the amount of SQL needed in repositories, and it also simplifies away the need to ingest information about packet groups (beyond their name) in the packet ingestion phase, i.e., we don't need to store a group's latest display name, description etc. in the database. (We probably can’t get rid of the packet groups table entirely to replace it with ephemeral views, since we use its persistence to do role permissions. See packit db diagram.)
There is also in this branch a new column on the packet table, 'description', which is populated on ingestion so that it can be referred to by the view.
I hewed to this Baeldung guide about 'Spring Data JPA Repository for Database View' so that our Kotlin backend can have a repository for the view in the way we're used to it doing for tables. Hence, there is a file ViewRepository that is a base class for repositories that deal with views rather than tables.
Views come in two types: ‘standard’ and ‘materialized’, where, as I understand it, the latter basically uses a (manually refreshed?) cache while the former runs the query every time it's referenced. We could move to materialized to save on queries - would require refreshing the cache periodically. See here for more.

I was a bit surprised to see no Dto for PacketGroupDisplay. Is the idea that we'll only have a Dto if it differs from the Entity (Model) class, otherwise we'll just use that as our transfer class?

It's more that I haven't wrapped my head around what a DTO is for.

I think I still prefer PacketGroupSummary as a name tbh - it does form a summary, and whether the front end chooses to display it or stick it in an excel file isn't the concern of the api. But could live with either.

Makes sense. Using 'display' as I change the code helps me keep track of what code is new vs old, but I can switch it all over to 'summary' once I've done all the changes.

Helpful links for trying out materialized views in spring boot:

General overview https://www.baeldung.com/sql/databases-views-simple-complex-materialized#materialized-view
How to add a refresh function to a repository https://ishansoninitj.medium.com/views-materialized-views-and-spring-data-jpa-05faeb8c0c67

Honestly, unless we have factual evidence of SQL requests slowing us down (and I doubt it is), I don't think there is much benefit to using views, whether they are materialized or not.
My main concern with using views is that it makes the code more stateful. If today you want to change what information is computed / displayed by the API, that's a simple Kotlin change. This change is built and deployed pretty straight forwardly.
With views, if you want to make a change in the future, you now have to think about migrations, and instead of just writing code you have to think it terms of difference with the previous one and ALTER VIEW, etc... Deployment becomes more complicated, and if we ever for any reason need to rollback a deployed change we are in a world of pain. I can only imagine that materialized view will be even worse in that regard. Then if I want to understand what a view does, there isn't a single file I can look at and understand what is going on, I have to piece information across many migrations.
Sure all these issues exist with the main table schema, but storage schema (probably) change less often than logic, and the storage is not something we really have other options for, whereas for logic keeping it in Kotlin seems like a reasonable option.

Honestly, unless we have factual evidence of SQL requests slowing us down (and I doubt it is), I don't think there is much benefit to using views, whether they are materialized or not.
My main concern with using views is that it makes the code more stateful. If today you want to change what information is computed / displayed by the API, that's a simple Kotlin change. This change is built and deployed pretty straight forwardly.

I suspect performance may become an issue once we get a decent number of packets in some of these instances, but the main problem we were trying to solve was code readability iirc.
Good points on migration transparency  - the danger is that we just transfer unreadability to the sql files - and rollback (urgh). Maybe we could have a policy of not altering views but instead dropping and recreating them? But you'd still have the issue of logic fragmented across parts of the system.
If we wanted to back out of this approach and instead try to make the SQL queries embedded in the Kotlin more readable I'm not sure there any options beyond string interpolation for repeated sub-queries or WITH clauses - but we could do that!

Thanks for the thoughtful comments @plietar .

With views, if you want to make a change in the future, you now have to think about migrations, and instead of just writing code you have to think it terms of difference with the previous one and ALTER VIEW, etc... Deployment becomes more complicated, and if we ever for any reason need to rollback a deployed change we are in a world of pain. I can only imagine that materialized view will be even worse in that regard. Then if I want to understand what a view does, there isn't a single file I can look at and understand what is going on, I have to piece information across many migrations.

These are reasonable points. It suggests that instead of defining a view, we move the query it contains into the Kotlin back end, wrapped in some function. Then we re-use that function, enjoying the same benefits (such as re-usability and not having to ingest packet group information) as we would get from a view, while avoiding the risk of db migration headaches.

Honestly, unless we have factual evidence of SQL requests slowing us down (and I doubt it is), I don't think there is much benefit to using views, whether they are materialized or not. [...] If today you want to change what information is computed / displayed by the API, that's a simple Kotlin change.

The intended benefit is about simplifying our work, rather than about making the app more performant. Having this pre-defined query (whether view or not) was an alternative to making ingestion complicated. To be specific: as we were introducing display names and descriptions at the packet-group level, ingestion was going to derive these from the packets, and store them in columns on the packet_groups. But this 'persistent columns' idea didn't work in the case of packet groups that already existed (those would need to be backfilled) (not so much a problem today but it would set the precedent for future such issues); it involved some duplication of data across tables; and it didn't feel totally future-proof because Rich had mentioned some features like parameterised display names that would mean that the semantics of the display_name column would change. That last one, I now realise, is an equally good argument against fossilising the current logic (namely, get properties from the latest packet) in a view.
I want to now investigate how we can do a reusable query without engraving it into the db.

fossilising the current logic (namely, get properties from the latest packet) in a view.

With migrations, you should be able to avoid fossilising the logic itself, as that can change, so long as you supported the view's schema while the code was using it. But, as I say, you'd still have the logic fragmented across sql/kotlin.

With migrations, you should be able to avoid fossilising the logic itself, as that can change, so long as you supported the view's schema while the code was using it.

I'm not sure what this means. The logic that would be fossilised in the view would be the bit about relying on the latest packet for the info.

So if you still wanted to provide packet display rows, but wanted to change the logic used to actually generate them (e.g. not going to the last packet to get display name, but deriving display name in some other way), I think it would work to add a migration which dropped the view and then recreated it with the new logic. (It should be fine to do this with views, even materialised views, as they're derived from the actual data tables.)
As I mentioned in the previous comment (the one replying to Paul) the drop and recreate approach might be preferable when changing views in other ways (e.g. add a column) anyway, to avoid the logic fragmentation issue he mentions.
(However I haven't ever tried this with migrations and views, so I'm not sure it would definitely work!)

I want to now investigate how we can do a reusable query without engraving it into the db.

Here is an alternative proposal: https://github.com/mrc-ide/packit/pull/149
Let me know your thoughts @EmmaLRussell !

A second alternative, which avoids both the split logic of using a view, and the ickiness of big SQL strings in kotlin annotations, would be to use something like jooq. That examines your db query and generates classes which you can then use to write validated SQL-like queries (which are compiled to actual SQL) as kotlin code.
One nice thing about that is that you can write shared subqueries once and re-use them e.g. return from a helper method and chain that result within the query that uses them. Here's an example of a nested query in jooq: https://www.jooq.org/doc/latest/manual/sql-building/table-expressions/derived-tables/
We've used jooq with Spark, but it works with Spring too: https://www.baeldung.com/jooq-with-spring
Here's an example of some of our jooq code in the wild: https://github.com/vimc/montagu-api/blob/c0a655d87955acc059c336c197deddbcdaf4a1f9/src/app/src/main/kotlin/org/vaccineimpact/api/app/repositories/jooq/JooqBurdenEstimateRepository.kt
The downside of jooq is that it can be a bit heavy - you need to remember to regenerate the classes, which get spat out as a pile of rather gruesome java. But I think the issue we're having here might demonstrate that we're starting to want to do sufficiently complex things with the database that might merit the advantages it can provide.
Would suggest moving this discussion out of the motivating ticket, do the simple kotlin implementation for that, and discuss further in the new year.


exercises/01 fails when run in docker against ibex

As noted at the Sonata Hackathon exercise/01.compartmentalisation doesn't run in the dev docker, although it does work if compiled and run on the Sonata board.   I tested against the latest commit (771f2bb - Jun 3rd) in case any of the recent changes to the dev contained had fixed it, but it still fails for me.
Digging in a little the line that fails in Ibex is generating the secret in secret.cc
    secret = static_cast<int32_t>(rdcycle64());

Replacing this with, for example, makes everything run fine
    //secret = static_cast<int32_t>(rdcycle64());
    secret=666;

Commenting out the code in secret.cc which waits for the uart (so the call to rdcycle64()  is in effect the first call in the therad) also makes no difference.
Adding a compartment_error_handler() gives the error as:
JavaScript compartment: Detected PermitAccessSystemRegistersViolation(0x18).  Register PCC(0x20) contained invalid value: 0x2004ba08 (v:0 0x2004a7c0-0x2004cb40 l:0x2380 o:0x0 p: G R-cgm- X- ---)

Calling rdcycle64() in any of the examples with IBEX works fine, so I'm assuming there is some difference in the build that I'm missing, but the only thing I spotted is that exercise xmake.luna has:
option("board")
    set_default("ibex-safe-simulator")

whereas the examples use
option("board")
    set_default("sail")

I'm happy to dig further  if someone can point me in the right direction.

I suspect that the recent(ish) changes to the AccessSystemRegisters permissions in Ibex may have broken mcycleh access.  The test suite uses mcycle but not mcycleh (it doesn't run long enough to overflow a 32-bit cycle counter.  @kliuMsft, can you check?

If the board is sail then they're not using the Ibex simulator, they're the instruction simulator generated from the Sail formal model.

Ah, Ok thanks.  I tried changing one of the examples to the ibex simulator and then doing "xmake config --sdk=/cheriot-tools/; xmake clean; xmake; xmake run" - but that didn't fail which made me think this was the wrong track.  Looks like I need to "rm -rf  .xmake .cache" to really get back to a clean state ?
And the exercise needs the simulator because the sail model doesn't have a uart - is that right ?
(Sorry for the questions - still feeling my way around here some)

You shouldn't need it, but sometimes rm -rf .xmake build is necessary.

And the exercise needs the simulator because the sail model doesn't have a uart - is that right ?

The Sail UART is output only, yes.

Kunyan confirms that this is an Ibex bug.  The refactoring of the PermitAccessSystemRegisters logic accidentally missed mcycleh.

The dev container is updated with the fix so this should work now.

Yep - runs fine now, thanks


updated farcaster social link

What changed? Why?

updated farcaster social link to a page that can be viewed in a logged-out state

Notes to reviewers
How has it been tested?
locally

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


HWDB not automatically updating

Previously: libratbag/piper#109
ratbagctl info event4 outputs:
event4 - Logitech Gaming Mouse G502
               SVG:
      Capabilities: query-configuration, resolution, switchable-resolution, profile, switchable-profile, disable-profile, button, button-keys, led
 Number of Buttons: 11
    Number of Leds: 2
Number of Profiles: 3
Profile 0: (disabled)
Profile 1: (disabled) (active)
Profile 2: (disabled)

Notice that the SVG line is missing, despite being clearly installed: https://gist.github.com/PlasmaPower/e8ed4680689726b89f20e53d64dece75
/usr/share/libratbag/gnome/logitech-g502.svg: SVG Scalable Vector Graphics image
This causes piper to crash.

Also, in journalctl: ratbagd error: Unable to fetch SVG for event4

Fixed it!
sudo systemctl-hwdb update
sudo udevadm control -R
sudo udevadm trigger
sudo systemctl restart ratbagd

Not sure if all of that was necessary. I'll keep the issue open for now, because I think this should be documented somewhere.

I had rebooted before this. I think that should've updated the hwdb, but maybe it didn't.

nope, rebooting doesn't update the hwdb, that's a manual command. once you run systemctl-hwdb update, a reboot should then work fine after that.
This should get better with #268 but mean you could submit a PR for a meson.add_install_script that toggles the hwdb on install (if root, and warns otherwise), I think that would make sense.

I'll close this issue, and instead comment on the AUR package.


feat: add mike-engel/jwt-cli

mike-engel/jwt-cli: A super fast CLI tool to decode and encode JWTs built in Rust

Thank you!

$ zipinfo jwt-cli-0.3.0-x86_64-pc-windows-msvc.zip
Archive:  jwt-cli-0.3.0-x86_64-pc-windows-msvc.zip
Zip file size: 22 bytes, number of entries: 0
Empty zipfile.

v4.51.0 is out 🎉
https://github.com/aquaproj/aqua-registry/releases/tag/v4.51.0


Bug: Recommendation card in user profile routes to wrong location

Describe the bug
Upon clicking the recommendation card in the user profile it opens a new tab with the URL https://app.opensauced.pizza/hot/repositories/filter/some_owner/some_repo?range=30
And there is no repo list available unless we click on dashboard tab.
So possible fix is to replace repositories path from the URL and add dashboard path instead which will select the dashboard tab as default and the page will have list of repos.
Steps to reproduce

Go to Profile page
Select Recommendations tab
If you have any recommended repo then you can click on the card and it will route you to new tab and opens a new URL

Browsers
No response
Additional context (Is this in dev or production?)
No response
Code of Conduct

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

Contributing Docs

[X] I agree to follow this project's Contribution Docs

I have already fixed it so if this bug is real then I would like to raise a PR.

@sourabpramanik there's definitely a bug here. Feel free to raise a PR. Please make sure to include a gif or short video showing the fix.

@sourabpramanik there's definitely a bug here. Feel free to raise a PR. Please make sure to include a gif or short video showing the fix.

Will do. Thanks @BekahHW


Terminate process red button on Console view does not work

When debugging an Bazel target, there are 2 red buttons, both should stop the process being debugged:

One is part of the debugger.  This one works
One is part of the Console window that shows process output.  This one needs to be fixed

The error message I see with the Console red button is "vm does not support termination"


redeploy images on docker hub

Hello, thanks for a great work making sure these images so easy to use.
Is it possible to redeploy them to docker hub to allow to pickup latest Rust (1.70.0 as of this writing)?

Done.

Thanks so much!


Fix Date Dialog extra right space on android 7.0+

thanks

Any idea when it will be merged to Master and published?
Thank you in advance!


double-beep: Watch apollocannabis.ca

double-beep requests the watch of the watch_keyword apollocannabis\.ca. See the MS search here and the Stack Exchange search here.

apollocannabis\.ca has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Shree in Charcoal HQ


Add README.md and package.json to Slider

Add README.md and package.json for slider.
R: @jelbourn @kara

LGTM aside from those few comments


FoundationEssentials: support symbolic link operations on Windows

This adjusts the symbolic link paths to be supported on Windows. The symbolic link destination computation is particularly gnarly as it requires re-defining the device driver interface in a shim header to access that and then performing aliasing contortions to gain access to the trailing VLA to get the value.

@swift-ci please test

@jmschonfeld anything else that needs to be addressed here?


Backlog & Cleanup

This is a tracking issue for things we need to do later after AMIP is running without NaNs.

[ ] abc
[ ] abc
[ ] abc

I think we can close this :)


Error when running scenario_runner on a non-full element map

carla version:0.9.12
scenario version:0.9.13
Before I used scenario_runner, I had already use the python API unload_map_layers operation on the map (Town05_opt) through the client, and got a map with only basic elements, and then when I went to run the .xosc type file, a fault error occurred, resulting in the server also crashed. I noticed that scenario_runner seems to reload the map after loading the .xosc, is the critical error related to this?
(it works great in integrated elements maps)

This problem can be reduced to another problem. When I use town05_opt and simplify the map, and then create a new client to connect world, the server side will crash.


ACN Avon coin withdraw

Please tell me how to take withdraw of my ACN(Avon coin) from github
mango771/avoncoin this link is on exchange to get withdraw

mango771/avoncoin  is fake github, is not our official github,
our official  github is here, and our only exchange now is livecoin.net.

you can join us at https://avoncoin.slack.com/

Can you invite me to join you?

can you send me more details about yourself before we send you the invite.
On Sun, 26 Mar 2017 at 9:32 AM, phamvanhoang<EMAIL_ADDRESS>wrote:

Can you invite me to join you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/acncoin/Avoncoin-Project/issues/1#issuecomment-289256765,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX9VWF8t-3isS11kw9LDP9TMxpLB45--ks5rpeM8gaJpZM4MFC6S
.

My name is : Pham Van Hoang
birthday : 1995
Nation: Viet Nam
Vào 27-03-2017 19:07, "acncoin"<EMAIL_ADDRESS>đã viết:

can you send me more details about yourself before we send you the invite.
On Sun, 26 Mar 2017 at 9:32 AM, phamvanhoang<EMAIL_ADDRESS>wrote:

Can you invite me to join you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/acncoin/Avoncoin-Project/issues/1#
issuecomment-289256765>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AX9VWF8t-
3isS11kw9LDP9TMxpLB45--ks5rpeM8gaJpZM4MFC6S>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/acncoin/Avoncoin-Project/issues/1#issuecomment-289360100,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZVSi1B98BzhZPBODjOrXDy82hvsKHdtks5rp07WgaJpZM4MFC6S
.

Hello
My Name               Maddy
Country                  India
I purchased acncoin on c-cex exchange. they gave a link as i already told.
But nothing in this link & I had returned my none coin. After sometime i
know that there is some issue between  acncoin and c-cex. Please tell me
how can i get my acncoin from c-cex.
please reply me as soon as possible
On Mon, Mar 27, 2017 at 11:23 AM, acncoin<EMAIL_ADDRESS>wrote:

can you send me more details about yourself before we send you the invite.
On Sun, 26 Mar 2017 at 9:32 AM, phamvanhoang<EMAIL_ADDRESS>wrote:

Can you invite me to join you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/acncoin/Avoncoin-Project/issues/1#
issuecomment-289256765>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AX9VWF8t-
3isS11kw9LDP9TMxpLB45--ks5rpeM8gaJpZM4MFC6S>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/acncoin/Avoncoin-Project/issues/1#issuecomment-289360100,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYmfhaQUC7c6wK87lv8X6pxNeEA6bc3Mks5rp07WgaJpZM4MFC6S
.


Bringing more wallet logins to ClubConnect

Hi All, I was just in a deso room in Club connect, and a lot of people were thinking how to bring this app forward.
A couple of things that were discussed.
Different wallets.. So far etherium is able to login.. what else is possible
-Tezos, Bitcoin, Cardano, Verus, Deso
-what languages, what is compatible with what?
-prevent scams, people fishing for data.
-could having a free NFT in a wallet allow for login?
-Interesting to look at Sylo communication network and wallet  network? is that open source?
-could trezor be interested?
-where is the data stored? who pays?
-what about apple and google play? now its open source?
-any universities interested to be a part of this?
-what does this app do, that other apps don't do?
-what type of encryption?
-have club connect, truly given up everything? My understanding is that a project can be open source, yet the magic ingredients can be maintained by a core team?
-what of all the capital already invested in the project?
-will Shaun and Igor meet and discuss things, or are they busy looking for new unicorns?
-my best understanding of open source can be found here. https://freebeer.org/blog/
-Also.. Bill Gates owns the service github, i mean microsoft...

There’s too many issues with this app that were never fixed in my opinion. Lost interest and doesn’t do well with large volume in a room

I thought the idea of aviators moving around the screen, people able to move to different parts of the screen to communicate in different places. People able to communicate with a camera..The interface and the direction it had was interesting, at the very least. Consider the budget of clubhouse, when looking at what was achieved. Can imagine a fair amount of time, to bring it together… yet I’m not a coder. Be interesting to see if anything springs from here.  https://github.com/Connect-Club/connectclub-web/issues/1

@jam2ja you should check out Slava and Kanshi’s all they created. I get clubhouse is an audio only, but the sound quality of more then 15 people is awful. Clubhouse we continue to use just because of the sound quality. This is not on DeSo or have anything to do with DeSo at all. We attempted to host connect club for the DeSo online anniversary and it did not do well. We were promised updates that didn’t happen for over a year. There are other projects I can send you that are like this in the making. However, I have messaged this group in discord and haven’t heard anything back in months. I believe this project is going to wrap up as the team stopped believing in themselves and stopped the updates

It could be, as you say. Consider though:  The idea of different wallets being able to connect/interlink, through something like club connect is interesting. Some sort of interoperability that allows different wallets to connect.. I don’t know the technical inns and outs though. Seems like a good idea. When these app builders have to build out in a proprietary way, it’s hard work. Maybe new people will join their team as it’s not a VC project, many of the cryto projects are, even though they are open source. Anyway, a lot of details/variables to explore for those that have the time.


fix(new-pnpazurecertificate): Update sample URL

Old URL led to an archived repository.

Docs Build status updates of commit 8c00443:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-pnp/New-PnPAzureCertificate.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@get-itips

Hello @tigattack
how are you?
Even though the PnP documentation articles are on this repository, I need to kindly redirect you to open PnP cmdlets issues/pull requests here, in that repository, where a member of the PnP community will be able to correct the article/review your PR with your feedback.
The documentation for PnP cmdlets is then synced from that repo into this one.
Thank you!

OK, thanks.


Question about --routine-vacuum parameter

Hello,
I'm still testing your tool to beat some bloat in my database on test lab. There is a critical table in my db and autovacuum is running every ~ 20-30 min. If autovacuum is not running for a long time => queries (customers) to that table experiencing a problems.
From pgcompacttable man:
-R
--routine-vacuum
    Turn on the routine vacuum. By default all the vacuums are off.

Based on above statement I conclude that during default pgcompacttable run autovacuum will not be able to run for that table.
If I will pass additional parameter -R this allow autovacuum to be run during pgcompacttable work, right? I can't check it on my test lab, that why I want to get some confirmation that I understood it correctly.
Am I right? If yes - then how you actually "blocking" autovacuum run during pgcompacttable run? I thought you are temporary setting autovacuum_enabled = off, but looks like it's not. Can you share this trick?
Thank you.

Uhh, looks like I misunderstood this parameter meaning. I've ran pgcompacttable with and without -R option.
Without:
[Wed Jun 22 15:20:22 2022] (bench_db) Connecting to database
[Wed Jun 22 15:20:22 2022] (bench_db) Postgres backend pid: 7580
[Wed Jun 22 15:20:22 2022] (bench_db) Handling tables. Attempt 1
[Wed Jun 22 15:20:22 2022] (bench_db:public.pgbench_accounts) Start handling table public.pgbench_accounts
[Wed Jun 22 15:20:32 2022] (bench_db:public.pgbench_accounts) Vacuum initial: 221948 pages left, duration 9.886 seconds.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 1.249 seconds.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Statistics: 221948 pages (277190 pages including toasts and indexes), it is expected that ~48.880% (108469 pages) can be compacted with the estimated space saving being 847.419MB.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Processing forced.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Update by column: bid.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Set pages/round: 5.
[Wed Jun 22 15:20:34 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 4439.
[Wed Jun 22 15:21:34 2022] (bench_db:public.pgbench_accounts) Progress: 31%,  33880 pages completed.
[Wed Jun 22 15:22:34 2022] (bench_db:public.pgbench_accounts) Progress: 61%,  66360 pages completed.
[Wed Jun 22 15:23:34 2022] (bench_db:public.pgbench_accounts) Progress: 91%,  99430 pages completed.
[Wed Jun 22 15:24:20 2022] (bench_db:public.pgbench_accounts) Vacuum final: cannot clean 110511 pages, 221948 pages left, duration 25.849 seconds.
[Wed Jun 22 15:24:20 2022] (bench_db:public.pgbench_accounts) Analyze final: duration 0.196 second.
[Wed Jun 22 15:24:21 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 1.116 seconds.
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Reindex forced: public.pgbench_accounts_pkey, initial size 55178 pages(431.078MB), has been reduced by 66% (287.531MB), duration 11 seconds.
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Processing incomplete.
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Processing results: 221948 pages (240386 pages including toasts and indexes), size has been reduced by -296.000KB (287.219MB including toasts and indexes) in total. This attempt has been initially expected to compact ~48% more space (108246 pages, 845.675MB)
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Finish handling table public.pgbench_accounts
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Handling tables. Attempt 2
[Wed Jun 22 15:24:33 2022] (bench_db:public.pgbench_accounts) Start handling table public.pgbench_accounts
[Wed Jun 22 15:24:39 2022] (bench_db:public.pgbench_accounts) Vacuum initial: 221948 pages left, duration 6.153 seconds.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 1.172 seconds.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Statistics: 221948 pages (240386 pages including toasts and indexes), it is expected that ~48.770% (108256 pages) can be compacted with the estimated space saving being 845.751MB.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Processing forced.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Update by column: bid.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Set pages/round: 5.
[Wed Jun 22 15:24:40 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 4439.
[Wed Jun 22 15:25:40 2022] (bench_db:public.pgbench_accounts) Progress: 83%,  90260 pages completed.
[Wed Jun 22 15:26:01 2022] (bench_db:public.pgbench_accounts) Vacuum final: cannot clean 110331 pages, 221948 pages left, duration 7.839 seconds.
[Wed Jun 22 15:26:01 2022] (bench_db:public.pgbench_accounts) Analyze final: duration 0.147 second.
[Wed Jun 22 15:26:02 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 0.988 seconds.
[Wed Jun 22 15:26:11 2022] (bench_db:public.pgbench_accounts) Reindex forced: public.pgbench_accounts_pkey, initial size 18374 pages(143.547MB), has been reduced by 0% (0.000B), duration 8 seconds.
[Wed Jun 22 15:26:11 2022] (bench_db:public.pgbench_accounts) Processing incomplete.
[Wed Jun 22 15:26:11 2022] (bench_db:public.pgbench_accounts) Processing results: 221948 pages (240386 pages including toasts and indexes), size has been reduced by -296.000KB (287.219MB including toasts and indexes) in total. This attempt has been initially expected to compact ~48% more space (108119 pages, 844.686MB)
[Wed Jun 22 15:26:11 2022] (bench_db:public.pgbench_accounts) Finish handling table public.pgbench_accounts
[Wed Jun 22 15:26:11 2022] (bench_db) Processing incomplete: 1 tables left.
[Wed Jun 22 15:26:11 2022] (bench_db) Processing results: size reduced by -296.000KB (287.219MB including toasts and indexes) in total.
[Wed Jun 22 15:26:11 2022] (bench_db) Disconnecting from database
[Wed Jun 22 15:26:11 2022] Processing incomplete: 1 databases left.
[Wed Jun 22 15:26:11 2022] Processing results: size reduced by -296.000KB (287.219MB including toasts and indexes) in total, -296.000KB (287.219MB) bench_db.

[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 1.088 seconds.
[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Statistics: 191558 pages (232085 pages including toasts and indexes), it is expected that ~42.030% (80510 pages) can be compacted with the estimated space saving being 628.986MB.
[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Processing forced.
[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Update by column: bid.
[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Set pages/round: 5.
[Thu Jun 23 10:37:07 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3832.
[Thu Jun 23 10:37:25 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1153.0 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:37:25 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 187723 pages left, duration 0.586 seconds.
[Thu Jun 23 10:37:25 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3755.
[Thu Jun 23 10:37:42 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1166.9 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:37:42 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 183968 pages left, duration 0.587 seconds.
[Thu Jun 23 10:37:42 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3680.
[Thu Jun 23 10:37:59 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1165.0 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:37:59 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 180288 pages left, duration 0.582 seconds.
[Thu Jun 23 10:37:59 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3606.
[Thu Jun 23 10:38:07 2022] (bench_db:public.pgbench_accounts) Progress: 14%,  1855 pages completed.
[Thu Jun 23 10:38:15 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1163.6 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:38:16 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 176678 pages left, duration 0.577 seconds.
[Thu Jun 23 10:38:16 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3534.
[Thu Jun 23 10:38:32 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1164.4 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:38:33 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 173143 pages left, duration 0.576 seconds.
[Thu Jun 23 10:38:33 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3463.
[Thu Jun 23 10:38:49 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1173.6 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:38:49 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 169678 pages left, duration 0.579 seconds.
[Thu Jun 23 10:38:49 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3394.
[Thu Jun 23 10:39:05 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1172.3 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:39:05 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 166283 pages left, duration 0.576 seconds.
[Thu Jun 23 10:39:05 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3326.
[Thu Jun 23 10:39:07 2022] (bench_db:public.pgbench_accounts) Progress: 28%,  445 pages completed.
[Thu Jun 23 10:39:21 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1169.1 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:39:21 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 162953 pages left, duration 0.580 seconds.
[Thu Jun 23 10:39:21 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3260.
[Thu Jun 23 10:39:36 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1173.0 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:39:36 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 159693 pages left, duration 0.575 seconds.
[Thu Jun 23 10:39:36 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3194.
[Thu Jun 23 10:39:51 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1172.7 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:39:51 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 156498 pages left, duration 0.569 seconds.
[Thu Jun 23 10:39:51 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3130.
[Thu Jun 23 10:40:06 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1167.4 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:40:06 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 153368 pages left, duration 0.565 seconds.
[Thu Jun 23 10:40:06 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3068.
[Thu Jun 23 10:40:08 2022] (bench_db:public.pgbench_accounts) Progress: 43%,  285 pages completed.
[Thu Jun 23 10:40:20 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1168.6 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:40:20 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 150298 pages left, duration 0.562 seconds.
[Thu Jun 23 10:40:20 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 3006.
[Thu Jun 23 10:40:34 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1173.4 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:40:35 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 147288 pages left, duration 0.558 seconds.
[Thu Jun 23 10:40:35 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2946.
[Thu Jun 23 10:40:48 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1175.7 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:40:48 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 144338 pages left, duration 0.560 seconds.
[Thu Jun 23 10:40:48 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2887.
[Thu Jun 23 10:41:02 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1163.3 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:41:02 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 141448 pages left, duration 0.570 seconds.
[Thu Jun 23 10:41:02 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2829.
[Thu Jun 23 10:41:08 2022] (bench_db:public.pgbench_accounts) Progress: 57%,  1150 pages completed.
[Thu Jun 23 10:41:15 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1174.6 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:41:16 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 138618 pages left, duration 0.556 seconds.
[Thu Jun 23 10:41:16 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2773.
[Thu Jun 23 10:41:28 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1177.0 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:41:29 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 135843 pages left, duration 0.554 seconds.
[Thu Jun 23 10:41:29 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2717.
[Thu Jun 23 10:41:41 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1155.7 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:41:42 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 133123 pages left, duration 0.555 seconds.
[Thu Jun 23 10:41:42 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2663.
[Thu Jun 23 10:41:54 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1163.9 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:41:54 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 130458 pages left, duration 0.550 seconds.
[Thu Jun 23 10:41:54 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2610.
[Thu Jun 23 10:42:06 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1170.6 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:42:07 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 127848 pages left, duration 0.552 seconds.
[Thu Jun 23 10:42:07 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2557.
[Thu Jun 23 10:42:08 2022] (bench_db:public.pgbench_accounts) Progress: 71%,  115 pages completed.
[Thu Jun 23 10:42:19 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1174.2 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:42:19 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 125288 pages left, duration 0.551 seconds.
[Thu Jun 23 10:42:19 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2506.
[Thu Jun 23 10:42:31 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1169.9 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:42:31 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 122778 pages left, duration 0.551 seconds.
[Thu Jun 23 10:42:31 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2456.
[Thu Jun 23 10:42:42 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1168.9 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:42:43 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 120318 pages left, duration 0.546 seconds.
[Thu Jun 23 10:42:43 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2407.
[Thu Jun 23 10:42:54 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1167.4 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:42:54 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 117908 pages left, duration 0.545 seconds.
[Thu Jun 23 10:42:54 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2359.
[Thu Jun 23 10:43:05 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1161.9 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:43:06 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 115548 pages left, duration 0.545 seconds.
[Thu Jun 23 10:43:06 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2311.
[Thu Jun 23 10:43:08 2022] (bench_db:public.pgbench_accounts) Progress: 86%,  370 pages completed.
[Thu Jun 23 10:43:16 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1174.4 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:43:17 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 113233 pages left, duration 0.537 seconds.
[Thu Jun 23 10:43:17 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2265.
[Thu Jun 23 10:43:27 2022] (bench_db:public.pgbench_accounts) Cleaning in average: 1169.8 pages/second (0.004 seconds per 5 pages).
[Thu Jun 23 10:43:28 2022] (bench_db:public.pgbench_accounts) Vacuum routine: 110968 pages left, duration 0.543 seconds.
[Thu Jun 23 10:43:28 2022] (bench_db:public.pgbench_accounts) Set pages/vacuum: 2220.
[Thu Jun 23 10:43:34 2022] (bench_db:public.pgbench_accounts) Vacuum final: 109837 pages left, duration 1.492 seconds.
[Thu Jun 23 10:43:34 2022] (bench_db:public.pgbench_accounts) Analyze final: duration 0.165 second.
[Thu Jun 23 10:43:35 2022] (bench_db:public.pgbench_accounts) Bloat statistics with pgstattuple: duration 0.659 seconds.
[Thu Jun 23 10:43:42 2022] (bench_db:public.pgbench_accounts) Reindex forced: public.pgbench_accounts_pkey, initial size 40471 pages(316.180MB), has been reduced by 54% (172.633MB), duration 6 seconds.
[Thu Jun 23 10:43:42 2022] (bench_db:public.pgbench_accounts) Processing complete.
[Thu Jun 23 10:43:42 2022] (bench_db:public.pgbench_accounts) Processing results: 109837 pages left (128244 pages including toasts and indexes), size reduced by 702.430MB (875.266MB including toasts and indexes) in total.

[Thu Jun 23 10:43:42 2022] (bench_db) Processing results: size reduced by 702.430MB (875.266MB including toasts and indexes) in total.
[Thu Jun 23 10:43:42 2022] (bench_db) Disconnecting from database
[Thu Jun 23 10:43:42 2022] Processing complete: 1 retries to process has been done
[Thu Jun 23 10:43:42 2022] Processing results: size reduced by 702.430MB (875.266MB including toasts and indexes) in total, 702.430MB (875.266MB) bench_db.

Closing.

Hello
No, we do not block autovacuum. By default pgcompacttable run vacuum manually before (specifying --no-initial-vacuum will skip this vacuum) and after processing of the table. If --routine-vacuum specified, few additional manual vacuum will be called during table processing. Usually autovacuum does this job well.

By default all the vacuums are off.
Really wrong description. I'll try to rewrite it.


Remove Notfications with Object in activityDeleted()

So by going through $instance->activityNotify() and then getting the notification feed IDs you can remove the $instance activity from each notification feed.
This makes sense because otherwise there will be notifications pointing to nothing, and they won't be enrichable either.

Hi @pfeiferchristopher!
Sorry for the late reply.
In fact, we will automatically remove those from all notification feeds. So there is no need to add this. But we appreciate your PR!
Closing this for now. Feel free to still reply here.


Release Python's Global Interpreter Lock

Release Python's Global Interpreter Lock (GIL) when calling into JS Callbacks from Python.
Also release the GIL after each call into Python from JS, to allow python threading and multiprocessing library to function properly.
This is also a prerequisite for reliable python3 asyncio support coming to bun_python.

Fixes Issue #1

All tests passing.

lgtm

A bun test that checks if ThreadpoolExecutor is behaving correctly within bun_python would be nice to detect any regression in future.
https://docs.python.org/3/library/concurrent.futures.html#threadpoolexecutor

it seems doesn't work

I think it may related to bun's runtime behavior
the thread may never working since you cannot fork the runtime


Critical rest client fixes

There are a number of small but critical issues with the v2 rest client preventing it from working

fix typo in header name
fix headers not being added to http request
fix error message being swallowed
fix empty data message signing (credit to https://github.com/Investabit/bitfinex-api-go/commit/7d487f0d091d8f4e46374f0df030339ed21c87f7)

@brobits @prdn I broke these out from anything else, should be straightforward to review.

:+1: straightforward


feat!: Normalize dictionaries.

Element -> DictionaryElement

Distinguish it from every other kind of "element".

ElemField/ElemValue -> Field/Value

We no longer prefix struct members. A field is a field, a value is a value.

I think this is the last naming issue.

I commented on a function name misspelling that needs to be fixed, but apart from that LGTM!


Distinguish between Stim source and name

There's some ambiguity over what a Stim name means. Right now it defaults to the filename, but it's probably a good idea to separately track the source file and name. This becomes an issue mainly in the context of graphs, where we might want to propagate the initial source file to a Stim as it flows through the graph (e.g., annotated text extracted from a VideoStim should retain some indication of the original video file).

Per discussion, we should handle this by propagating the filename forward through the graph (probably in the Converter) unless it's explicitly passed to the initializer.


fixed navbar and hero section

Description
fixed the container and hero section updating and correction the portions of content and adding transitions.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] I have made this from my own
[ ] I have taken help from some online resourses
[ ] My code follows the style guidelines of this project
[ ] 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
[ ] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

Great contribution to GSSOC'24! 🎉


ipld: Unexport GetShares function

It is only used internally to ipld pkg

@renaynay, we don't have a root-level ipld pkg anymore. We have one in share/ipld but even it doesn't have the GetShares func, so WDYM?


Fix provider-local controller-registration generation

How to categorize this PR?

/area testing
/kind bug
What this PR does / why we need it:
This PR fixes provider-local controller-registration generation.
Introduced with - #8250
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

/retest


use Method getters rather than deprecated static fields

cc: @vkedia

@pongad The dependent issue https://github.com/googleapis/gapic-generator/issues/1856  was recently closed as fixed, would it be possible to rerun the tests?

This is still failing. I'll figure out why as part of GCJ release this week.

@pongad did you get a chance to look into this?

Conflict because we moved the file. @carl-mastrangelo I opened a new PR for this. Let me know if it looks OK to you.

Superseded by #3299


[WIP]C API Enhancement

Description
The goal is to add support to the C API to enable APIs for using MXNet as a model server application. For example, the regular MXPredCreateEx API assumes it will be given the param_bytes and param_size which are the raw params file data. But in this application the params data wont be available, instead arrays of pre-processed data will be provided in the input_data argument with the corresponding input_shape_data for each tensor.
We also add a new env var MXNET_GPU_MEM_POOL_LIMIT to allow users to limit the amount of memory MXNet can use for tensor allocations. Previously MXNet assumed it gets to use all the GPU memory (minus the amount reserved). For example, in the past you could say for 16GB of GPU memory reserve 5% (0.8GB) for other use and MXNet would use the remaining 15.2GB for tensor data. But with this PR you can tell MXNet to only use 4GB (by specifying 25%) so the rest of the GPU memory could be used for other applications (ie. non-MX pre/post-processing, or duplicating instances of MX sharing the same GPU for higher utilization in a model server).
C API changes
These are the public facing C API changes.
MXGetBytesInUse
size_t MXGetBytesInUse(int dev_type, int dev_id);

A new API that returns the amount of memory used by MXNet for the given context (dev type & ID)
C Predict API changes
These are the changes to the public facing C Predict API
DType
enum DType {
    kDTypeFloat32 = 0,
    kDTypeFloat64 = 1,
    kDTypeFloat16 = 2,
    kDTypeUInt8 = 3,
    kDTypeInt32 = 4,
    kDTypeInt8 = 5,
    kDTypeInt64 = 6
};

A new enum to expose MXNet data types (previously CpredictAPI always used mxfloat for everything)
MXPredCreateEx2
A new API, similar to MXPredCreateEx but does not require param_bytes/param_size (ie. the void* pointer to param data file loaded from disk).
int MXPredCreateEx2(const char* symbol_json_str,
                              int dev_type, int dev_id,
                              const char** input_keys,
                              const void** input_data,
                              const int* input_dtypes,
                              const mx_uint* input_shape_indptr,
                              const mx_uint* input_shape_data,
                              const mx_uint num_input_nodes,
                              PredictorHandle* out);

Instead takes params the same as inputs via the input_* arguments (ie. input_keys, input_data, etc.). This will be used when there is no params file on disk (imagine that the param tensor data is already in memory somewhere and sent from a client to a model server).
MXPredCreatePartialOutEx
A new API, similar to MXPredCreatePartialOut but does not require param_bytes/param_size (ie. the void* pointer to param data file loaded from disk).
int MXPredCreatePartialOutEx(const char* symbol_json_str,
                                       int dev_type, int dev_id,
                                       const char** input_keys,
                                       const mx_float** input_data,
                                       const mx_uint* input_shape_indptr,
                                       const mx_uint* input_shape_data,
                                       const mx_uint num_input_nodes,
                                       const mx_uint num_output_nodes,
                                       const char** output_keys,
                                       PredictorHandle* out);

Instead takes params the same as inputs via the input_* arguments (ie. input_keys, input_data, etc.). This will be used when there is no params file on disk (imagine that the param tensor data is already in memory somewhere and sent from a client to a model server).
MXPredCreatePartialOutEx2
A new API, similar to MXPredCreatePartialOutEx but allows specifying input_dtypes instead of requiring inputs to be in mxfloat type.
int MXPredCreatePartialOutEx2(const char* symbol_json_str,
                                        int dev_type, int dev_id,
                                        const char** input_keys,
                                        const void** input_data,
                                        const int* input_dtypes,
                                        const mx_uint* input_shape_indptr,
                                        const mx_uint* input_shape_data,
                                        const mx_uint num_input_nodes,
                                        const mx_uint num_output_nodes,
                                        const char** output_keys,
                                        PredictorHandle* out);

It also changes the type for input_data to void* instead of mxfloat.
MXPredGetOutputNames
A new API, that returns the list of output node names for a predictor object.
int MXPredGetOutputNames(PredictorHandle handle,
                                   mx_uint *out_names_length,
                                   const char ***out_names);

MXPredGetInputShape
A new API, that returns the shape of an input node.
int MXPredGetInputShape(PredictorHandle handle,
                                   const char* key,
                                   mx_uint** shape_data,
                                   mx_uint* shape_ndim,
                                   int* key_found);

MXPredGetInputType
A new API, that returns the dtype of input node.
int MXPredGetInputType(PredictorHandle handle,
                                  const char* key,
                                  int* dtype,
                                  int* key_found);

MXNDListGetEx
A new API, like MXNDListGet but also returns the dtype.
int MXNDListGetEx(NDListHandle handle,
                            mx_uint index,
                            const char** out_key,
                            const void** out_data,
                            int* out_dtype,
                            const mx_uint** out_shape,
                            mx_uint* out_ndim);

Storage Class changes
Changes to the core storage class.
GetMemoryInUseInBytes
A new API in the storage class that returns the number of bytes allocated thus far.
size_t GetMemoryInUseInBytes(const Context &ctx);

The function returns 0 and prints a warning message if an instance of a storage class for that context has not been constructed yet (ie. if there were no allocations for that context yet). Otherwise it returns the amount of memory allocated in bytes.
A default implementation of the function throws an error if not implemented for that particular subclass of Storage. This PR only implements the function for GPUPooledStorageManager.
GPUPooledStorageManager Class changes
Changes to the GPUPooledStorageManager subclass.
free_list_size_
A new class variable that accounts for the amount of free memory in the internal memory pool. It is used to calculate the amount of memory actually used as Tensor data by MXNet.
float type for reserve_
Changes the reserve_ variable from int to float so users can specify more granularity (ie. 3.5%) for how much memory to reserve for non-tensor GPU allocations (ie. descriptors).
memory_limit_percentage_
A new class variable to allow users to artificially limit the amount of memory available to MXNet for tensor data via the MXNET_GPU_MEM_POOL_LIMIT environment variable. For example, on a machine with 16GB of GPU memory, can limit MXNet to 4GB so that users can run 4x copies of MXNet in separate processes and share the same GPU for model serving efficiency improvements. Basically changes the internal accounting from using the real total memory returned by CUDA to the user-constrained amount.
The enforcement of the limit works like this whenever a new tensor is being allocated. If the size of the new tensor plus the total amount of memory already is use is greater than the limit we throw an error.
if (used_memory_ + size > mem_limit_in_bytes)
   LOG(FATAL) << "memory limit reached ...

Checklist
Essentials

[ ] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

I find some changes in this PR confusing. It would be great to have description on what use cases this PR aims to support.

I find some changes in this PR confusing. It would be great to have description on what use cases this PR aims to support.

Still working on the description :-D
Once we finish getting the code in order will update the description and remove WIP and ask for feedback.

cc @andrei5055 for storage manager changes.

Thanks for the contribution! Some of the changes will be useful for 2.0 too. One general question I have is whether there's opportunity to clean up the current c predict APIs in 1.x so that we can offer a clean version for 2.0 too. If you are open to it, it would be great to see a proposal on how a clean c predict API could look like given the opportunity to break backward compatibility.

Thanks for the contribution! Some of the changes will be useful for 2.0 too. One general question I have is whether there's opportunity to clean up the current c predict APIs in 1.x so that we can offer a clean version for 2.0 too. If you are open to it, it would be great to see a proposal on how a clean c predict API could look like given the opportunity to break backward compatibility.

While helping with this PR, I noticed a lot of similarity in the TVM/DLR APIs:
https://github.com/neo-ai/neo-ai-dlr/blob/main/include/dlr.h
or
https://github.com/neo-ai/neo-ai-dlr/blob/main/include/dlr_tvm.h
Maybe we can use those as a reference as well in this exercise.
Cleaning up the C Predict API is a great idea, at the same time we should think about other C/C++ APIs like the MXGetBytesInUse or MXLoadLib that we want to include in our C interface moving forward.


Game crahses/closes when paused for too long

I love Max Payne 3 and thanks to your fusion fix it's even more enjoyable. But there is one annoying problem. When you pause the game, it crashes after 2-4 minutes. It would mean a lot if you look into this problem. We, the fans of this game are here to help you by contributing!
Regards

Create a folder called "CrashDumps" inside the game's main directory, next to the .exe, reproduce your crash again, and then look into the folder and see if it generated any .log or .dmp file. Zip them up, upload and post here.
If it doesn't give out a crash dump, it's gonna be trickier.

I can't get the game running without crashing anymore. Or, actually, I could play for a few days, although problem was that most of the times the game started minimised, a few seconds pass, and it crashes.
Now after the R* launcher window (which was minimised on start too) I can't catch the game icon on taskbar pop out.
So I did as @RecklessGlue540 asked, here's the crash dump from the last attempt to start the game.
CrashDumps.zip

Create a folder called "CrashDumps" inside the game's main directory, next to the .exe, reproduce your crash again, and then look into the folder and see if it generated any .log or .dmp file. Zip them up, upload and post here. If it doesn't give out a crash dump, it's gonna be trickier.

Here is the .zip file. The game crashed in the pause menu after 4-5 minutes.
CrashDumps.zip

Steam clean install + Fusion Fix: can't reproduce.

Steam clean install + Fusion Fix: can't reproduce.

I already clean installed and using your latest fusion fix, still crashing when paused for some minutes.

Does it crash without fusion fix? If not, which ini option crashes exactly?

Does it crash without fusion fix? If not, which ini option crashes exactly?

It crashes without fusionfix as well.

Maybe it's a driver bug, I don't think I can do anything about it, judging from crash dumps.

Getting the same issue here with the same error in the crash dump as MeowX001 has:
0xC0000005: Access violation reading location 0x00000060.

Getting the same issue here with the same error in the crash dump as MeowX001 has: 0xC0000005: Access violation reading location 0x00000060.

There's nothing I can do,
>	MaxPayne3.exe!015768fc()	Unknown	No symbols loaded.
 	[Frames below may be incorrect and/or missing, no symbols loaded for MaxPayne3.exe]		Annotated Frame
 	socialclub.dll!63610381()	Unknown	Non-user code. Cannot find or open the PDB file.
 	socialclub.dll!635d24da()	Unknown	Non-user code. Cannot find or open the PDB file.
 	socialclub.dll!635d4288()	Unknown	Non-user code. Cannot find or open the PDB file.

call stack shows this. And the crashing function could be anything. As I said, I could not repro on my end.

Getting the same issue here with the same error in the crash dump as MeowX001 has: 0xC0000005: Access violation reading location 0x00000060.

There's nothing I can do,
>	MaxPayne3.exe!015768fc()	Unknown	No symbols loaded.
 	[Frames below may be incorrect and/or missing, no symbols loaded for MaxPayne3.exe]		Annotated Frame
 	socialclub.dll!63610381()	Unknown	Non-user code. Cannot find or open the PDB file.
 	socialclub.dll!635d24da()	Unknown	Non-user code. Cannot find or open the PDB file.
 	socialclub.dll!635d4288()	Unknown	Non-user code. Cannot find or open the PDB file.

call stack shows this. And the crashing function could be anything. As I said, I could not repro on my end.

The crash occurs fast if you are in chapter 13. I could be wrong about this info cause the crash can happen on any level after pausing. Can you please pause the game while in chapter 13 for the last time? Sorry for bothering you.

That also happens to me.
Maybe it's in-game DX11 related bug.

That also happens to me. Maybe it's in-game DX11 related bug.

Yeap, a friend helped me to discover that. You have to run the game in DX9 to avoid this crash. That's the only solution we could find.


Added progress reporting during image pulls

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "add_progress" git@github.com:wsong/swarm.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Added progress reporting for image imports and loads as well.

It seems like Jenkins doesn't like that we're now importing the docker/docker/pkg/term library (which is apparently used in the vendor/github.com/docker/docker/pkg/jesonmessage library); it seems like we're not using the right type of build machine, maybe?
We can switch to just vendoring in the jsonmessage structs directly, if you guys would prefer.

@wsong It'd help if you can describe your design first. What is it trying to achieve, any change to CLI/API?
The build fails because docker/docker/pkg/term uses cgo which requires gcc to build.
# github.com/docker/swarm/vendor/github.com/docker/docker/pkg/term
exec: "gcc": executable file not found in $PATH
Build step 'Execute shell' marked build as failure

Our goal here is just to show incremental progress notifications during very large image pulls, loads or imports.

Sounds cool. Can you describe the expected output?
FYI, there is some similarity with https://github.com/docker/docker/pull/31144.
Swarm doesn't support cgo for now.

The output should be more or less the same as doing a docker load against a plain engine. If you do this without Swarm, you see messages like "Pulling image..." on the CLI. This PR just passes those images through Swarm to the client.

IIRC, Swarm doesn't want to support cgo because it introduces a lot of overhead (and maybe cross platform compilation problem). @vieux might have more insight in this.

That's fine. Should I just vendor in the jsonmessage structs? We just need them to deserialize the JSON we get back from the daemon.

That sounds good to me.

All right, reverted vendor/ changes and just copy-and-pasted the structs in. PTAL.

Looks like engine 1.9 reported progress in a different format, requiring us to deserialize the progress messages differently (in particular, it looks like they didn't have line breaks in between messages).
Would you guys be okay with just logging a warning if we fail to deserialize a progress message? This issue should only occur with very old engines, and users will just miss out on incremental progress indicators. They should still see any errors.

Would you guys be okay with just logging a warning if we fail to deserialize a progress message?

I think this is a good compromise.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "add_progress" git@github.com:wsong/swarm.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353995864
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

LGTM
ping @nishanttotla @allencloud.


Feature Request: modifyable beamStateHistory for complex deep linking

It would be nice if one were able to inject/push new entries into the beamStateHistory.
Use Case:
a BeamLocation that generates a stack of pages based an multiple data sources, like calling URI, global state, database requests... etc.
This dynamic stack of pages could receive a clearly identifying, dynamically generated URI per page. Being able to push these generated URIs into the beamStateHistory list (in a user defined order) would make the pop() / back() functions work like the user actually navigated through these pages, making complex deep linking possible
sample code
// ... 'step' is set from State or other source
          if (state.uri.path.startsWith('/login/signup/${SignupStep.Name.index}') ||
              step.index >= SignupStep.Name.index)
            pageStack.add(BeamPage(
              key: ValueKey('login-signup-step-name'),
              child: LoginSignupStepName(),
NEW -> historyNamed: ''/login/signup/${SignupStep.Name.index}'
            ));
          if (state.uri.path.startsWith('/login/signup/${SignupStep.Date.index}') ||
              step.index >= SignupStep.Date.index)
            pageStack.add(BeamPage(
              key: ValueKey('login-signup-step-date'),
              child: LoginSignupStepDate(),
NEW -> history: state.copyWith(
                    pathBlueprintSegments: ['login', 'signup', ':step'],
                    pathParameters: {'step': SignupStep.Date.index},
                  ),
            ));
        }

beamStateHistory and beamLocationHistory are now public


More regression refactoring

More work on #1680

Codecov Report

Merging #1708 (c71232e) into master (349db4c) will not change coverage.
The diff coverage is n/a.

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

@@            Coverage Diff            @@
##             master    #1708   +/-   ##
=========================================
  Coverage     57.58%   57.58%
  Complexity     1032     1032
=========================================
  Files           173      173
  Lines          9781     9781
  Branches       1344     1344
=========================================
  Hits           5632     5632
  Misses         3675     3675
  Partials        474      474

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 349db4c...9b4f1eb. Read the comment docs.

@MXueguang This is a huge patch, but most changes are cosmetic, so a quick sanity check will suffice. I have verified regressions still work.


Can't See Errors when Redirected for App TXs with Deposits

Problem
When app redirects to sign tx, if it fails the error is flashed on UI but redirect happens too fast.
Expected Behavior
User (or most likely dev) can see the error and read the message.
Steps to reproduce

Sign into app
Create tx with attached deposit (these redirect to wallet)
TX fails (maybe set it up to fail)

@marcinbodnar @Patrick1904 Curious to know why the error here is displayed on its own screen vs other errors in the app which use the toast pattern that displays briefly and then is automatically dismissed. Was this txn error implemented first?

@mattlockyer can you share a screen recording of this issue? I'm having trouble reproducing it just through the UI

Click Buy
Redirected to Wallet

If there is an error with the TX, the error will flash up on the UI
BUT the user is redirected to app RIGHT AWAY. They do not get to read the error.

A video isn't going to be any different.
I mean I can write a contract that fails all the time and show you. But it is exactly as I described.
Do you need an example that will fail that you can run on your machine?

@corwinharrell this is how a sign error currently looks. I encountered this timeout error (stayed on the page though) while buying a card on: https://berry.cards. It seems that the purchase still went through so we need to do better error handling of this in general and not just assume all of it failed.

@mattlockyer @Patrick1904  the problem here is with recent Mixpanel changes - at this moment, if signAndSendTransactions action fails, redirection is still executed - previously it was redirecting only on success. Checkout handleAllow in Sign.js component.

Removing the Needs design label here since design is present and it appears to just be an issue with timing and Mixpanel changes. @Patrick1904 I assume this can be addressed without the need for additional design given the context provided by @marcinbodnar above?

Thanks for investigating @marcinbodnar. I pushed a fix here: https://github.com/near/near-wallet/pull/1515

Thanks for investigating @marcinbodnar. I pushed a fix here: #1515

Great, thanks @Patrick1904


Online demo

It'd be great if there were an online demo with just a field where users could input a sentence or paragraph and see what the current functionality and output of lexed looks like.

I'm planning to setup a demo to demonstrate this package as well as other natural language packages that I have on this organization.
I'll post a link here once I'm done.


Error getaddrinfo EAI_AGAIN running docker and using --net=host

ElasticDump version: 6.0.1
Elasticsearch version: 7.0.0
Node.js version: 8.10
Command:
docker run -v $HOME/data:/data/ --net=host --rm -ti taskrabbit/elasticsearch-dump \ --input="https://$USER:$PWD@$path.aws.found.io:xxxx" \ --input-index=index \ --searchBody='{"query": { "bool": { "must": [{ "term" : { "field" : x } },{ "range": { "date": {"gte": "now-1d"}}}]}}}' \ --limit 100 --output ./data/mydata.json

And the output is:
Fri, 31 May 2019 01:48:22 GMT | starting dump Fri, 31 May 2019 01:48:43 GMT | Error Emitted => getaddrinfo EAI_AGAIN xxxxx xxxxx:443 Fri, 31 May 2019 01:48:43 GMT | Total Writes: 0 Fri, 31 May 2019 01:48:43 GMT | dump ended with error (get phase) => Error: getaddrinfo EAI_AGAIN xxxxx xxxxx:443
Also, when I don't use the container and run the elasticdump locally to the same inputs, it throws a similar error, but instead of "EAI_AGAIN", it says "ENOTFOUND"

If it failed both places, then I'm not sure what to say. EAI_AGAIN/ENOTFOUND. Can you try curling the URL before and see what the results are ?

EAI_AGAIN is a DNS lookup timed out error
ENOTFOUND site not found.

I am so sorry, I decided to change the password to one without special characters... and indeed it was the password that was messing up with the command. I will close this issue.
Again, sorry for the trouble.

It was no trouble at all. Thanks for using elasticdump 🙂

@FeTaka  how you solve this issue because i am also facing same issue
Tue, 23 Aug 2022 09:31:56 GMT | starting dump
Tue, 23 Aug 2022 09:32:16 GMT | Error Emitted => getaddrinfo ENOTFOUND http
Tue, 23 Aug 2022 09:32:16 GMT | Error Emitted => getaddrinfo ENOTFOUND http
Tue, 23 Aug 2022 09:32:16 GMT | Total Writes: 0
Tue, 23 Aug 2022 09:32:16 GMT | dump ended with error (get phase) => Error: getaddrinfo ENOTFOUND http