Modifies the resource to use root_group attribute.

/cc @tas50 @pburkholder
This modifies the cookbook to use the Ohai attribute for obtaining the root group of the system. It fixes some errors that we've been observing on the AIX and Solaris platforms. This should close out #25.

That's a welcome change.  Thanks


Issue when integrating with the mimalloc allocator

The mimalloc allocator https://github.com/microsoft/mimalloc has gained some attention recently and looks to be a promising malloc replacement. However I ran into an issue when trying to integrate with the VMA.
VMA wants to use an aligned malloc. mimalloc supplies mi_malloc_aligned but there is an issue when interacting with VmaCreateStringCopy. mi_malloc_aligned asserts when the given alignment is less than sizeof(void*). When creating a copy of a string VMA uses an alignment of 1.
To work around this I made a distinction in vk_mem_alloc.h between aligned an unaligned allocations. The VMA_SYSTEM_MALLOC define was renamed to VMA_SYSTEM_ALIGNED_MALLOC and a new VMA_SYSTEM_MALLOC was added that maps to the system malloc by default. The only usage of this unaligned malloc is in VmaCreateStringCopy.
The modified version can be found here:
vk_mem_alloc.zip
I'm not quite knowledgeable enough of the inner workings of the VMA to comfortably post this as a PR as I have no idea if it's a "good idea". It's also been mangled by my personal .clang-format settings which I have yet to undo. If this is an acceptable solution for upstream I can turn this into a pull request. Or if someone else wants to solve this in a different way that's fine by me.

If the allocator you want to use doesn't allow an alignment that is accepted by any other, then I would say it should be submitted as a bug to that project.
I think an easy solution would be to just give larger alignment, i.e. calculate alignment = max(alignment, sizeof(void*)) before passing it to mimalloc. It should just work.
Some side notes:

I cannot diff your file with base VMA code because it looks like you changed the majority of the code. It looks reformatted. Probably some automated tool reformatted all the code without your knowledge and consent. I recommend to disable such tools when cooperating with other people on some code.
You seem to base on official VMA release 2.3.0 which is very old code. I recommend to use latest from master branch. It is pretty stable and contains recent fixes and improvements.

Thanks for the solid feedback. You're right, It should probably be reported to mimalloc. Your solution is also a lot simpler and is probably what I'll end up doing (after I update my copy of the VMA).
I usually try to keep my code formatted with clang-format. I should probably add some filters to my config to not format header libraries like this.
This is probably safe to close :)


chores: Add comment (daily refactoring)

Codecov Report
Patch and project coverage have no change.

Comparison is base (98dad9c) 100.00% compared to head (9e25e21) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #48   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          178       178
=========================================
  Hits           178       178

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

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

Impacted Files
Coverage Δ

template_analysis/__init__.py
100.00% <ø> (ø)

template_analysis/symbol.py
100.00% <ø> (ø)

template_analysis/template.py
100.00% <ø> (ø)

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


Use correct channel in Firestore autoconfiguration

Fixes #2254.

I don't think so; trace triggering it was just incidental -- any dependency with its own grpc channel that happens to be autoconfigured earlier would trigger it.
I'll wait for the build to be green before merging.


Add a config option for despawn time, as some servers change it

There are some servers that change the item despawn time (for example, emc.gs has 15 minutes instead of 5). Added a config option for that.

Manually pulled in the changes in this PR.


Address recursivity in  GraphQL functionality

Currently, the GraphQLView does not work recursively (to be fair, like other traits).
The problem occurs with the following example:
#[derive(RootView, GraphQLView)]
pub struct Counter<C> {
    pub value: CollectionView<C, u64, RegisterView<C, u64>>,
}

But actually the following will work
#[derive(View, GraphQLView)]
pub struct ContainerView<C> {
  pub intro_val: RegisterView<C,u64>,
}

#[derive(RootView, GraphQLView)]
pub struct Counter<C> {
    pub value: CollectionView<C, u64, ContainerView<C>>,
}

So, we have a reasonable solution to a common problem. But do we consider it an acceptable solution?

Let me think about this. Part of the problem is that there is no such trait as GraphQLView yet.

We might be able to implement async_graphql::OutputType directly for all basic view constructions (register, etc) and async_graphql::ObjectType for some of them (like maps and collections). Then:

GraphQLView would be defined as pub trait GraphQLView: View + async_graphql::ObjectType {}
#[derive(GraphQLView)] would only concert user-defined views.


New housegroup and transaction structure for house interaction

The houseround table has been replaced by a persistent housegroup table and more transient transaction records. The houseround structure and transaction structure need to be added to the player app.
This is based on issue https://github.com/averbraeck/housinggame-common/issues/15 in the common project.

All code now uses the new HouseGroup and Transaction tables and classes for house interaction.


sinkv2(cdc): add interface EventSortEngine

Signed-off-by: qupeng<EMAIL_ADDRESS>What problem does this PR solve?
Issue Number: ref #5928
What is changed and how it works?
Add a new interface named EventSortEngine.
Check List
Tests

No code

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
None

Codecov Report

Merging #7412 (fe16d05) into master (39d0ee4) will increase coverage by 0.0107%.
The diff coverage is 66.2790%.

Additional details and impacted files

Flag
Coverage Δ

cdc
67.5663% <70.5426%> (-0.0124%)
:arrow_down:

dm
52.0107% <ø> (+0.0025%)
:arrow_up:

engine
60.9685% <63.7209%> (-0.0617%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #7412        +/-   ##
================================================
+ Coverage   59.8674%   59.8781%   +0.0107%
================================================
  Files           800        803         +3
  Lines         91913      92274       +361
================================================
+ Hits          55026      55252       +226
- Misses        32103      32212       +109
- Partials       4784       4810        +26

/merge

/run-engine-integration-test


db.plugin is not a function

I included the database but the plugin in not working
var db = new PouchDB('dbname');
db.plugin(require('pouchdb-quick-search'));

Sorry, I'd need more details in order to help you out... browser, environment, did you npm install, etc.? What's not working?

^^ You need to declare the plugin on the pouch db import, rather than on the DB instance:
var PouchDB = require('pouchdb');
PouchDB.plugin(require('pouchdb-quick-search'));

I'm having something similar with the MemoryPouchDbService. I use pouchdb-browser and the memory plugin, both 6.3.*. It's failing in an ng test environment


Update Site settings “info”

Automatically generated by Netlify CMS

👷 Deploy Preview for playful-arithmetic-cae7f2 processing.

Name
Link

🔨 Latest commit
143677967a8e626f186646ad25094787ca06ceca

🔍 Latest deploy log
https://app.netlify.com/sites/playful-arithmetic-cae7f2/deploys/6619522d15f6e6000875118d


favicon is some guy named Spencer

Need to change the favicon

This is great. I couldn't find the picture of Spencer so I figured I needed to delete it or something.


Getting error while doing make of "keystored "

Hi Michal,
I took latest code from all the git-repos and trying to make the libraries..
I had also cleaned up all the old lib related to these from my box (/usr/lib64, /usr/local/lib64) etc ..
But while installing keystored I am getting the some dependency error as shown below...
-sh-4.2$ cmake -D CMAKE_BUILD_TYPE:String="Debug" ..
-- The C compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.27.1")
CMake Warning at CMakeLists.txt:57 (message):
keystored pkg-config file copied into a directory not searched by
pkg-config.
CMake Warning at CMakeLists.txt:58 (message):
For netopeer2-server configuration to work, pkg-config search path must
include "/usr/local/lib64/pkgconfig" or keystored keys directory will have
to be set manually to "/usr/local/etc/keystored/keys".
-- Found sysrepo: /usr/local/lib64/libsysrepo.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/haripriyap/gitcode_devel/Netopeer2/keystored/build
-sh-4.2$ make
Scanning dependencies of target keystored
[100%] Building C object CMakeFiles/keystored.dir/keystored.c.o
Linking C shared library libkeystored.so
[100%] Built target keystored
-sh-4.2$ sudo make install
[100%] Built target keystored
Install the project...
-- Install configuration: "Debug"
-- Installing: /usr/local/lib64/pkgconfig/keystored.pc
-- Installing: /usr/local/etc/keystored/keys
CMake Error at cmake_install.cmake:56 (message):
Command sysrepoctl list failed:
/usr/local/bin/sysrepoctl: error while loading shared libraries: libyang.so.0.12: cannot open shared object file: No such file or directory
make: *** [install] Error 1
============================
-sh-4.2$ ldd /usr/local/bin/sysrepoctl
linux-vdso.so.1 =>  (0x00007fffc6963000)
libsysrepo.so.0.6 => /lib64/libsysrepo.so.0.6 (0x00007fef41a51000)
libyang.so.0.13 => /lib64/libyang.so.0.13 (0x00007fef41744000)
librt.so.1 => /lib64/librt.so.1 (0x00007fef4153b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fef4131f000)
libredblack.so.0 => /lib64/libredblack.so.0 (0x00007fef4111b000)
libev.so.4 => /lib64/libev.so.4 (0x00007fef40f0c000)
libprotobuf-c.so.1 => /lib64/libprotobuf-c.so.1 (0x00007fef40d03000)
libc.so.6 => /lib64/libc.so.6 (0x00007fef40941000)
libyang.so.0.12 => not found                                            ==========>> ??
libm.so.6 => /lib64/libm.so.6 (0x00007fef4063e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fef4043a000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fef401d8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fef41e50000)
-sh-4.2$
======================
But while installing libyang,  I got only the following .so...
Install the project...
-- Install configuration: "Debug"
-- Installing: /usr/local/lib64/libyang.so.0.13.13
-- Installing: /usr/local/lib64/libyang.so.0.13
-- Installing: /usr/local/lib64/libyang.so
-- Up-to-date: /usr/local/include/libyang/libyang.h
-- Up-to-date: /usr/local/include/libyang/tree_schema.h
-- Up-to-date: /usr/local/include/libyang/tree_data.h
-- Up-to-date: /usr/local/include/libyang/extensions.h
-- Up-to-date: /usr/local/include/libyang/xml.h
-- Up-to-date: /usr/local/include/libyang/dict.h
-- Installing: /usr/local/lib64/pkgconfig/libyang.pc
-- Installing: /usr/local/bin/yanglint
-- Removed runtime path from "/usr/local/bin/yanglint"
-- Up-to-date: /usr/local/share/man/man1/yanglint.1
-- Installing: /usr/local/lib64/libyang/nacm.so
-- Removed runtime path from "/usr/local/lib64/libyang/nacm.so"
-- Installing: /usr/local/lib64/libyang/metadata.so
-- Removed runtime path from "/usr/local/lib64/libyang/metadata.so"
-sh-4.2$
Please let me know if I am missing anything here.
Thanks in advance.
-Rosy

Hi Rosy,
I will help you this time, but having some basic experience with developing software on Linux, you should have been able to resolve this. It is complaining, while executing sysrepoctl, that it cannot find libyang.0.12 because you already have libyang.0.13, so what does this tell you? That your installed version of sysrepoctl is linking with an old version of libyang. So, simply recompile and install sysrepo and it should be fixed.
Regards,
Michal

Hi Michal,
Thanks for your reply. No problem, It got resolved.
I was recompiling but somehow the old sysrepoctl  was not getting overwritten. So once I removed that manually from my box it got resolved.
Regards,
Rosy


DTM-13100 Report rule completion when rule.actions is undefined.

Currently, if a Launch library container has a rule that does not have an actions property defined and the rule executes, two things fail to happen:
There is no log message emitted to the console saying that the rule completed.
Launch monitoring hooks don't notify monitors that the rule completed.
This particularly affects users of the Sandbox when they're developing an event type. If they use the library sandbox editor to create a rule that uses their event type, but they don't add an action to the rule (currently there's no built-in action type provided by the sandbox that they could use), there's no way of knowing if their event type is actually running rules like they would expect, because no log message ever shows up saying the rule was run.

Coverage decreased (-0.2%) to 97.932% when pulling bb8b90c48384b2f4762009eafcc6c1b662952ce0 on actions-undefined-report-completion into 09c907a2e0096846d29a36a3846400d9dbbaf842 on master.

Should we add a test for this?

Yes. I've added tests.

Looks good.


Add prompt before shutdown

Small edit of the Poweroff app to add a prompt and prevent accidental shutdown

Thanks!


Python3 support

Does LUI support python3?

It appears it did not by default; the only thing stopping it from doing such is in a few areas where you wrap unicode like such
unicode(text)
Because string literals are unicode by default in Python3. Feel free to grab my code from my project repo
I also got the listbox widget I made in there if you would like to grab it, feel free to.


Failed when launching vizviewer

During the process of starting vizviewer, the following error was given:
Trace: http://<IP_ADDRESS>:9001/localtrace

Viewed on: http://<IP_ADDRESS>:9001

Error: RPC framing error
onRpcResponseMessage@http://<IP_ADDRESS>:9001/v25.0-cca3e0ce7/frontend_bundle.js:82366:19
onRpcResponseBytes@http://<IP_ADDRESS>:9001/v25.0-cca3e0ce7/frontend_bundle.js:82326:18
onMessage@http://<IP_ADDRESS>:9001/v25.0-cca3e0ce7/frontend_bundle.js:82656:15

v25.0-cca3e0ce7 cca3e0ce7300e9ab1616888edfd92238fbc27378
UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0

like that: (I don't have a google account, so I create an issue here)

But there is no error message in my terminal:
PS E:\Data\OSM> vizviewer E:\Data\OSM\result.json
Running vizviewer
You can also view your trace on http://localhost:9001
Press Ctrl+C to quit

When I used vizviewer for the first time, the Windows firewall asked me, and I allowed it.
The html file I generated using vietracer filename.py -o result.html can be opened normally.
I install viztracer with command pip install viztracer[full], and using python 3.11.2. Viztracer's version is 0.15.6
The result.json maybe a little big? It's 106MB large, perhaps because it's was used to read a 300MB+ dataset?

It is a known and unfixable issue that Firefox does not work well with large trace log. Please use Chrome.
html report is basically deprecated (at least not maintained) at this point.
Could you try Chrome and see if it works?

Could you try Chrome and see if it works?

Yes, it works well on Chrome, thank you!
I didn't try to use "Firefox" as the keyword when I searched for similar issue before, it is a duplicate of #208, #237 and #317, so I am very sorry that I created a duplicate issue.
I noticed that we currently haven't a feature that can specify to use Chrome while open "http://<IP_ADDRESS>:9001/", I've thought about webbrowser and selenium, but neither looks like a good solution：
webbrowser need a given chrome path, and this can vary greatly depending on the operating system. selenium is too heavy for just open a browser (chromedriver is also needed to be installed). Do you have any suggestions about open with Chrome?

Not really. Currently vizviewer uses webbrowser to open trace logs. Firefox works for smaller trace files, but I don't know any good way to prioritize Chrome.


Localizing the layout does not work

I tried putting the layout file into multiple localizable paths, neither of them seems to work

/source/localizable/layouts/layout.erb
/source/layouts/localizable/layout.erb

middleman doesn't find the layout in both cases

What about just not putting it in a localizable folder?

yeah, pretty sure this doesn't work. Work around might be something like a default layout.erb with the contents:
<% wrap_layout(I18n.locale) do %>
  <%= yield %>
<% end %>

Where you have a layout for each locale, something like en.erb

@tdreyno I solved it by moving the localizable parts to partials.

@eaigner You can call I18n functions inside your layout, even though it is not in the localizable folder.

I'm doing some issue-gardening 🌿🌷🌾 and came across this issue.
Sorry that this has lingered for quite a while! I think things are working as intended, and that this issue can be closed. Feel free to disagree and if so a PR with a failing test plus a fix would be a great start.


[feature] #2003: Introduce Parity Scale Decoder tool

Description of the Change

Added new derive-macro DumpDecoded and corresponding trait
New derive is used on pretty all data_model types. Exceptions: those, which don't implement Debug + Decode, and generics
Added tools/parity_scale_decoder
Added some binary samples for testing and demo

Issue

Closes #2003

Benefits

With this tool we can debug incompatibility issues
Useful for SDK developers

Possible Drawbacks
That's the tricky part... Here I use 3 different procedurals macros and 2 of them should be executed in order. Rust have no guarantees for that and that's the problem. See here for details. Right now it works on my machine and I think it should be fine for others too.
Order:

Derive macro. Used in data_model multiple times. Generates implementation and adds type name at the global vector
generate_dump_decoded_map!(). Used in data_model once. Takes names from global vector and creates global Map with Type Name -> dump_decoded() ptr reflection
get_dump_decoded_map!(). Used in parity_scale_decoder. Just a getter for global map from step 2.

This approach allows not to hardcode every type by hand inside parity_scale_decoder... At least while it's working. If sometime we will have a trouble with it, we can rewrite it using the less (or more?) elegant way, see the last section.

Usage Examples or Tests
See README.md

Alternate Designs
Hardcode types-map by hand
Pros:

Safe
Clear what types are presented

Cons:

Inflexible
A lot of code

Use include!(data_model)
Just an idea. Not even sure it's possible

Another thing to note
We should be care when choosing #1983 implementation so that it don't rely on macro exectuion order as this one

See alternative implementation in #2080

All of codeowners (including me) decided that #2080  implementation is better. I'm closing this PR


Fix spurious TestBatchCustody test failure

Description

Do not test for the state of the byzantine node.
Motivation and Context

TestBatchCustody configures replica 0 to only receive messages, but to be unable to send messages.  In a sense, this is byzantine behavior.  Depending on message order, replica 0 may apply all blocks, or it may stay in a view change and not apply the transactions.  Given that replica 0 can be considered byzantine, we should not expect any specific state.  Therefore we should ignore its state when considering whether the test failed or was successful.
This test issue had been introduced in #1277.
How Has This Been Tested?

Repeated unit tests, bdd tests.
Checklist:

[x] I have added a Signed-off-by
[x] Either no new documentation is required by this change, OR I added new documentation
[x] Either no new tests are required by this change, OR I added new tests
[x] I have run goimports, go vet, and golint. I have cleaned up all valid errors and warnings in code I have added or modified. These tools may generate false positives.  The goal is clean, consistent, and readable code.

Signed-off-by: Simon Schubert<EMAIL_ADDRESS>

LGTM. Thanks


Remove TypeAttractor and address more build warnings

This changeset removes the workaround related to TypeAttractor, as it appears no longer be required.
Also, more Gradle task dependencies has been introduced to eliminate warnings in build logs.

@alexander-yevsyukov PTAL.


name router-view not support children routers

Version
2.2.6
Reproduction link
https://jsfiddle.net/gfdegb6o/
Steps to reproduce
click /home link
What is expected?
baz
foo
baz
What is actually happening?
foo
foo
baz

This is a vue-router issue. You posted it to the wrong place.
Your usage is wrong: none of your first-level route components contain a <router-view>, so the /home route will be the same as /. Your "expected behavior" doesn't even make sense.


Update gallery to RNW 0.64 release

RNW is currently previewing the 0.64 release. As of right now the 5th preview us up:

react-native-windows_v0.64.0-preview.5

It would be useful to validate the 0.64 previews with this gallery app (see issue #23). Let's get a build of gallery on 0.64 ready so we can start testing it.

See branch 'v0.64.0-preview.5' for version of app with RNW v0.64.0-preview.5

See branch 'v0.64.0-preview.5' for version of app with RNW v0.64.0-preview.5

0.64 is finally released so we should update from preview and merge that branch to main.


failing make test-e2e

Thanos, and Golang version used:
thanos master branch last commit 02ab6b84908e5458699655ab064a78afc0f9da9b
go version go1.14.4 darwin/amd64
mac 10.15.5
docker version 19.03.8
What happened:
running make test-e2e  gives following error
unexpected error: the service querier-1 is not ready; err: Get "http://localhost:32808/-/ready": dial tcp [::1]:32808: connect: connection refused

unexpected error: failed to get mapping for port as container e2e_test_receive_replication_with_outage-receive-1 exited: exit status 1: docker container receive-1 failed to start: exit status 1

unexpected error: failed to get mapping for port as container e2e_test_query-receive-1 exited: exit status 1: docker container receive-1 failed to start: exit status 1

unexpected error: failed to get mapping for port as container e2e_test_receive_hashring-receive-1 exited: exit status 1: docker container receive-1 failed to start: exit status 1

even though  make docker is successful , can someone point me a direction?

I would look on docker container logs before the error happens. Anything interesting being printeD? (:

I checked the docker log before but didn't find anything that stands out
level=info ts=2020-07-07T02:51:53.619Z caller=main.go:231 msg="Starting Alertmanager" version="(version=0.20.0, branch=HEAD, revision=f74be0400a6243d10bb53812d6fa408ad71ff32d)"
level=info ts=2020-07-07T02:51:53.620Z caller=main.go:232 build_context="(go=go1.13.5, user=root@00c3106655f8, date=20191211-14:13:14)"
level=info ts=2020-07-07T02:51:53.624Z caller=cluster.go:161 component=cluster msg="setting advertise address explicitly" addr=<IP_ADDRESS> port=9094
level=info ts=2020-07-07T02:51:53.642Z caller=cluster.go:623 component=cluster msg="Waiting for gossip to settle..." interval=2s
level=info ts=2020-07-07T02:51:53.705Z caller=coordinator.go:119 component=configuration msg="Loading configuration file" file=/shared/data/am/1/config.yaml
level=info ts=2020-07-07T02:51:53.714Z caller=coordinator.go:131 component=configuration msg="Completed loading of configuration file" file=/shared/data/am/1/config.yaml
level=info ts=2020-07-07T02:51:53.725Z caller=main.go:497 msg=Listening address=<IP_ADDRESS>:8080
level=info ts=2020-07-07T02:51:55.610Z caller=cluster.go:648 component=cluster msg="gossip not settled" polls=0 before=0 now=1 elapsed=2.0015497s
level=info ts=2020-07-07T02:52:03.612Z caller=cluster.go:640 component=cluster msg="gossip settled; proceeding" elapsed=10.0036739s
level=info ts=2020-07-07T02:52:24.791Z caller=main.go:536 msg="Received SIGTERM, exiting gracefully..."

honestly I am pretty stumped on this, It seems like the docker container shuts down before the test is ran ,  I feel like I am missing some basic setup, am I suppose to export certain variables somewhere? before I run make test-e2e
 unexpected error: the service querier-1 is not ready; err: Get "http://localhost:33337/-/ready": dial tcp [::1]:33337: connect: connection refused

I recently got the integration test suite running on Mac OS 10.15.6 Catalina ran into a similar issue.
First, if you haven't yet, I highly recommend reinstalling Docker for Mac from scratch after upgrading to Catalina. Be sure to remove all of the system files. This is a helpful guide: https://nektony.com/how-to/uninstall-docker-mac
Second, the make docker command will build a docker image with the binary built using your OS. So the docker image produced on Mac OS X when running make docker will result in a error message that looks like:
$ docker run thanos
exec user process caused "exec format error"

Instead you are going to want to build the image using the following make command:
make docker-multi-stage

This will create an image with the proper OS and Arch.


fix(expect-utils): Treat ImmutableJS Lists as Sets

Summary
Fixes #12752
Test plan
I could add a test case for iterableEquality, but I'd need to introduce immutable as a dev dependency. Let me know if you'd like to. Otherwise, this relies on the fact that immutable's List implements a similar API to native Set objects, importantly, .has().

I could add a test case for iterableEquality, but I'd need to introduce immutable as a dev dependency. Let me know if you'd like to.

Yes please, a dev dep is perfectly fine! (we already have one in pretty-format 🙂 )

Seems this broke some other tests we have, actually

Thanks, I'll add the new tests and look at the errors on the existing tests a little later on.

Didn't read the logic carefully enough for Sets, it isn't checking order (which makes sense). So instead we don't do the entries check if the objects are Lists.


Fix and test cases for unstable tokenization schemes like phi3

Some models like phi-3 have unstable tokenizers that aren't reversible in select circumstances. This can cause stability issues with guidance's attempt to stay on distribution and retokenize before prompt inputs. I don't believe we have a choice but to skip this step under malformed tokenizers.
This isn't really in a merge-ready state, but is a bandaid fix and some reproducible tests to start a discussion. If we expect this to be a trend, we should formalize the exception process, but if it's a small number of models, the hack in TransformersEngine and Engine classes may be the minimal code change we need.
(Following a discussion with @slundberg and @paulbkoch -- tagging for your awareness)

test failures appear unrelated.


Delay before showing progress

One thing I have noticed is that if a task completes very quickly sometimes it takes longer to display the fidget than the task itself.
Perhaps it would be nice to have an option to time delay showing the fidget, and only after that time if it is still running show progress.

Can you give an example of such a task? I can see how this might be useful, but adding some kind of "high pass filter" logic could significantly complicate the logic of the current implementation.
In particular, the $progress endpoint receives messages that comprise a task, and we can't tell from individual messages whether the task is short- or long-lived. So we'd have to start little one-shot timers every time we receive a start message, and cancel those timer threads on subsequent report messages, but let the timer expire if we receive an end message. Or we could do the same thing but implemented using timestamps rather than threads.
But then I worry that doing so much to distinguish between message types is only going to make it more complicated to handle language servers that don't seem to conform to the progress protocol as precisely.

In the lsp i'm developing, https://github.com/ratmice/nimbleparse_lsp which builds a lex/yacc grammar, on grammar edit, it starts a server side task, which then parses a bunch of test cases.
The behavior is a lot better than I thought, (I had accidentally running with a delay on the server side so that I could even see the progress in vscode), but still when editing fidgets sometimes stack up, when the server abandons a task and starts up a new one due to a new edit that has arrived.

Oh neat! How does VScode respond when it's flooded with short-lived notifications?

The delay doesn't seem particularly stable, e.g. between 200ms up to as high as 400 ms, I have seen no progress,
I'm guessing that rather than a delay it might just be putting things onto a data structure, and popping them off as the achieve WorkDone, and then if they get pushed and popped, before some refresh rate the statusline/fidget never notice perhaps.
Anyhow I wonder if something like that might be a design achievable without the timer/thread cancelation,
I'm still pretty much a lua/nvim noob though, so I can't really judge!
But by all means close this if you don't think there is a feasible design within the constraints of fidget!

I'd like to keep this open, because it's a great suggestion. I'm currently (and slowly) working on a rewrite/reimagining of this plugin as a modular reactive UI library; I think your idea of a notification debouncer could work well in that context!

I think this need is addressed in 893ceb3, which introduces a setting that doesn't create a new notification if the message indicates it's already done.
It builds off the update_only feature I added to the notifications API in 7880df0133556697a8efee0278b52c6add32df8a, which drops notifications that aren't updating an existing item. If a task is so short-lived that it is already done by the time we first process it, then setting progress.ignore_done_already = true means Fidget won't create a new notification just to announce the completion of that short-lived task.
This works even better now that polling is sample-driven (rather than primarily event-driven, as it was prior to the rewrite), because it means that the logic of waiting for some time to wait for a burst of events to accumulate is baked into the semantics of the system. You can simply lower the progress.poll_rate to tell Fidget to wait longer before deciding to display anything. Because this is independent of notification.poll_rate, it is still responsive to asynchronous notification events, and can still have smooth animations.
For instance, here the same demo as in the README.md, but with progress.poll_rate = 0.5 and progress.ignore_done_already = true:
https://github.com/j-hui/fidget.nvim/assets/11800204/05660c4e-b216-412a-aafe-77266cd4eb62
Sorry for blabbing a little, but I'm just really happy about how straightforward that feature was to implement after redesigning the plugin's execution model (: Thanks for your patience!


Add source - example, source properties

There is no description or example of what properties a to-be-added-source should have.

Podrobnosti dokumentu
⚠ Neupravujte tuto část. Vyžaduje se k propojení problémů docs.microsoft.com ➟ GitHub.

ID: d5a5e2ab-44a7-a652-d3d4-c7e0bfa246ab
Version Independent ID: bdbeae08-947d-2413-3053-ca66f0a9d90e
Content: source Command
Content Source: hub/package-manager/winget/source.md
Product: dev-environment
Technology: ****
GitHub Login: @KevinLaMS
Microsoft Alias: kevinla

Thank you for your feedback. The 'source' command is currently intended for internal use only, and we have added a note to clarify this in the article. If this policy changes, we'll update the article to provide more prescriptive guidance about using it.


python3Packages.scikit-fuzzy: init at unstable-2020-10-03

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[x] other Linux distributions

[NA] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[NA] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I'm not the biggest fan of having many downstream packages of scikit. They usually release subtle breaking changes. The codebase surface is massive. And they've caused me several hours of looking into why certain bumps are breaking builds/tests.

I would like to add https://github.com/jcreinhold/intensity-normalization, which needs scikit-fuzzy, to all-packages.nix, but if more scikit packages aren't desirable then I can perhaps add these to an overlay instead ...?  On the other hand, this package is fairly small, has few dependencies, and the tests run in a few seconds.

Result of nixpkgs-review pr 100090 run on x86_64-linux 1

2 packages built:

python37Packages.scikit-fuzzy
python38Packages.scikit-fuzzy

Result of nixpkgs-review pr 100090 run on x86_64-darwin 1

2 packages built:

python37Packages.scikit-fuzzy
python38Packages.scikit-fuzzy


Bug for WebUI 1.6.0

Loading CLIP Interrogator 0.5.4...
load checkpoint from H:\Stable Diffusion\models\BLIP\model_base_caption_capfilt_large.pth
Loading CLIP model...
Loaded CLIP model and data in 7.43 seconds.
The size of tensor a (8) must match the size of tensor b (64) at non-singleton dimension 0

same

Yes. Any model

Duplicate of #64 and #59.

@RunawayOrange I've update the extension now can you give it a try and confirm is fixed for you.

@RunawayOrange I've update the extension now can you give it a try and confirm is fixed for you.

I can confirm. This is fixed for me now.


Deleting an option in Fauxton causes it to be forced to empty instead, overriding local.ini!

From @alenl on September 25, 2018 16:28

If you click on the trashcan icon by some option, it will not remove that option from local.d/10-admin.ini, but will set the option line to:
That_Olde_Option =
So, if that option has an actual value assigned in local.ini , it will be overwritten with nothing.
Expected Behavior

Deleting an option from the Fauxton list would remove the option-value line completely from the admin file, which would make the value from local.ini take over.
Current Behavior

Right now it puts an empty assignment, which is not the same as doing nothing.
Possible Solution

I suggest deleting the line from 10-admin.ini completely. The fact that it is not done that way seems like a small oversight, and simple to fix - but with big and very confusing effects to the admin-user of Fauxton.
Steps to Reproduce (for bugs)
Below, when I say "observe the realm", I mean execute this:
curl -is https://couch-test-server:6984/ | grep realm

(Or whatever protocol/port you use.)
and check the output.

Have a test server that uses WWW authentication and requires authorized user .
(This is the simplest test, because WWW-Authenticate realm is a string that can be set to anything and is easily obtainable from the browser.)
In local.ini, set [httpd] WWW-Authenticate = Basic realm="set_in_local"
observe the realm is now "set_in_local"
In Fauxton [httpd] WWW-Authenticate = Basic realm="set__in_Fauxton"
observe the realm is now "set_in_Fauxton"
Click on the trashcan icon for the WWW-Authenticate in Fauxton
observe the realm is now "server". (This originates from the internal defaults.)
Check contents of etc/local.d/10-admin.ini and notice the line
WWW-Authenticate=

Context

When doing any changes, it can be very confusing. If you add a new option in Fauxton, and then remove it, you'd expect that the state of the configuration is as it was before. Alas, it is something completely different! Now that I know about this, I simply will not be using that trashcan icon, because this is definitely no what I wanted to do. But it was super-confusing before I realized what's going on.
Your Environment

Version used: 2.2.0 (installed on Ubuntu 16.04)
Browser Name and version: Firefox 62.0/x64
Operating System and version (desktop or mobile): desktop
Link to your project: N/A

Copied from original issue: apache/couchdb-fauxton#1127

From @popojargo on September 25, 2018 16:54
When you delete a config option in Fauxton, we call the  DELETE /_config/{section}/{key}. This should be moved to https://github.com/apache/couchdb as it concerns the API behavior

This is actually a duplicate of #777.
To fix this requires a complete rewrite of the config system, which is being pondered in #1595.
There is absolutely not agreement within the team about any of the proposals in #1595 yet, so fixing this is way down the line.

This issue seems tied to the behavior of delete markers which is not necessarily related to writing to the last file in the config chain. Let's re-open it as it may be possible to fix without completely re-writting the config system.

https://github.com/apache/couchdb/pull/4813 has been merged, which removes support for delete markers (e.g. lines likekey = in .ini files), so DELETE /_config/{section}/{key} will now delete the entire line. Hopefully, this will be less surprising and confusing for users.


[REQ] add a (GH-compliant) license file

Hi there, 1st of all thanks for this awesome work !
Since we've 'doxed' it in our HyMPS project (under AUDIO section \ Treatments page \ Phasing), can you please add a GH-compliant license file for it ?
As you know, expliciting licensing terms is extremely important to let anyone better/faster understand how to reuse/adapt/modify sources (and not only) in other open projects and vice-versa.
Although it may sounds like a minor aspect, license file omission obviously causes an inconsistent generation of the relative badge too:

(badge-generator URL: https://badgen.net/github/license/davidteren/unphased)
You can easily set a standardized one through the GH's license wizard tool.
Last but not least, let us know how we could improve - in your opinion - our categorizations and links to resources in order to favor collaboration between developers (and therefore evolution) of listed projects.
Hope that helps/inspires !

Thanks, works now !


Revert "Merge pull request #2238 from coreinfrastructure/update_font_…

…awesome_and_url"
This reverts commit a204e06bfd5ccc2a2ebb52e103c1d8d41f95d035, reversing changes made to 9b481a68962857ace13649e5ba4f1bd0bffaa98a.
Unfortunately this update of Font Awesome leads to many broken icons. This is probably fixable, but we have a serious problem in production, so we need to revert this for now and return to it later.

I'm hoping this is temporary. Something weird is happening with login in production, at least sometimes.

Sorry, I wrongly assumed that fontawesome was a backwards compatible change. I'll check out the icons and see

No problem. They even documented it that way, it just wasn't true :-(.


Build simpleperf failed

Hi,
I want to build simpleperf for riscv. But it will have build FAILED as below:
$ source build/envsetup.sh
$ lunch aosp_cf_riscv64_phone-userdebug
$ mmma system/extras/simpleperf -j30
$ mmma system/extras/simpleperf -j30
============================================
PLATFORM_VERSION_CODENAME=VanillaIceCream
PLATFORM_VERSION=VanillaIceCream
PRODUCT_INCLUDE_TAGS=com.android.mainline
TARGET_PRODUCT=aosp_cf_riscv64_phone
TARGET_BUILD_VARIANT=userdebug
TARGET_ARCH=riscv64
TARGET_ARCH_VARIANT=riscv64
TARGET_CPU_VARIANT=generic
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.4.0-91-generic-x86_64-Ubuntu-18.04.5-LTS
HOST_CROSS_OS=linux_musl
BUILD_ID=AOSP.MASTER
OUT_DIR=out
============================================
[  0% 2/509] //system/extras/simpleperf:libsimpleperf_profcollect_rust rustLink rust/lib.rs
FAILED: out/soong/.intermediates/system/extras/simpleperf/libsimpleperf_profcollect_rust/android_riscv64_dylib/unstripped/libsimpleperf_profcollect_rust.dylib.so
echo "module libsimpleperf_profcollect_rust missing dependencies: libsimpleperf_profcollect" && false
module libsimpleperf_profcollect_rust missing dependencies: libsimpleperf_profcollect
[  0% 3/509] //system/extras/simpleperf:libsimpleperf_profcollect_rust strip libsimpleperf_profcollect_rust.dylib.so
FAILED: out/soong/.intermediates/system/extras/simpleperf/libsimpleperf_profcollect_rust/android_riscv64_dylib/libsimpleperf_profcollect_rust.dylib.so
echo "module libsimpleperf_profcollect_rust missing dependencies: libsimpleperf_profcollect" && false
module libsimpleperf_profcollect_rust missing dependencies: libsimpleperf_profcollect
22:57:40 ninja failed with: exit status 1

#### failed to build some targets (4 seconds) ####

In prebuilts/rust/ folder, I check out to aosp/simpleperf-release branch, but it still have the same build  failed as above.
$ cd prebuilts/rust/
$ git pull
$ git co aosp/simpleperf-release

Simpleperf currently uses the outdated llvm in external/llvm which doesn't have any reasonable RISC-V support.
@yabinc is working on migrating simpleperf to a newer llvm.  ETA is ~1-2 months.  It's tracked in the google-internal issue-tracker, but will post here once it's complete.

Does this mean there is ongoing effort to update the LLVM version in external/llvm? If so, do you know what version is being updated to? We are also interested as this, as it will be required to build the radeonsi driver in external/mesa3d.

Does this mean there is ongoing effort to update the LLVM version in external/llvm? If so, do you know what version is being updated to? We are also interested as this, as it will be required to build the radeonsi driver in external/mesa3d.

"yes and no".
the plan (aiui) for simpleperf is to switch to the toolchain version of llvm.
the plan for qemu is to move to a newer version of llvm (but not the "renderscript" version you see in external/ --- that would require ). the qemu work is actually pretty advanced internally (aiui) but the work to move that out to upstream and/or AOSP has (aiui) yet to start.

Simpleperf currently uses the outdated llvm in external/llvm which doesn't have any reasonable RISC-V support.

@yabinc is working on migrating simpleperf to a newer llvm. ETA is ~1-2 months. It's tracked in the google-internal issue-tracker, but will post here once it's complete.

Hi @pirama-arumuga-nainar ,
OK, I got it. Thanks for the update.

(for googlers, http://b/267670561 "Switch simpleperf to prebuilt llvm libraries to build it on riscv" is the internal bug mentioned above.)

you can build system/extras/simpleperf/ for riscv64 now. (the internal bug is still open to clean up a workaround, but functionally this work is done.)
unfortunately, you can't use simpleperf on qemu for lack of perf events.

Hi @enh-google ,

you can build system/extras/simpleperf/ for riscv64 now. (the internal bug is still open to clean up a workaround, but functionally this work is done.)

Thanks for the fix. I'll try it.

unfortunately, you can't use simpleperf on qemu for lack of perf events.

Can I ask, if is it related to the architecture code needed to port in simpleperf for RISC-V perf events?
As far as I know, the Linux perf tools at least can support the general hardware events on qemu.

Can I ask, if is it related to the architecture code needed to port in simpleperf for RISC-V perf events?

i don't actually know, since i'm not very familiar with qemu (and our perf events expert isn't around today). i'd assume qemu doesn't support them though, because what use would they be? i assume you're thinking of the virtualized case, where the perf events are fairly meaningful?

OK, I got it. Thanks.

Will the android/riscv64 build of simpleperf eventually be included in the NDK? I don't see it in the latest build artifact from https://ci.android.com/builds/branches/aosp-master-ndk/grid?legacy=1.

Yes, we'll eventually add these to the NDK.  There's still some pending work to package this in the NDK.

In https://r.android.com/2848836, @yabinc added a simpleperf binary for riscv64.


bump dcos-log sha

High-level description
bump dcos-log sha
this PR includes:

make dcos-log respect journald files rotation

Corresponding DC/OS tickets (obligatory)
These DC/OS JIRA ticket(s) must be updated (ideally closed) in the moment this PR lands:

DCOS_OSS-2132 - respect systemd files rotation

Related tickets (optional)
Other tickets related to this change:

N/A

Checklist for all PRs

[X] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[X] Read the DC/OS contributing guidelines
[X] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[X] Change log from the last version integrated (this should be a link to commits for easy verification and review): diff
[X] Test Results:jenkins#305
[X] Code Coverage (if available): jenkins#305

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and review process
What is the review process and when will my changes land?
All PRs require 2 approvals using GitHub's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner. Once a PR has 2 ship-it's, no red reviews, and all tests are green it will be included in the next train.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee


ComposeMapCells in ndt map locator

When I try to use ndt locate.  I am really confused about the ComposeMapCells function in lidar_locator_ndt.cc。Why we should split a cell into several small areas, but not use the whole cell?  And it seems some small area exceed the cell ranges . so we got negative x y values, which will be filtered next.
And finnally how many cells we really used to do the NDT align? —— It seems the code only one will be used

Simply put, the ndt map is divided into some grids.
when the car is running on the road we take the current car as the center and load a grid within a certain range (for example 10m), that is why ComposeMapCells is needed.


fix(auto-imports): remove pnpm workspaces to re-enable vscode auto-imports

What is it?

[ ] Feature / enhancement
[x] Bug
[ ] Docs / tests

Description
Seems that using pnpm workspaces inside of nx is causing issues with vscode auto-imports. Perhaps @dmitry-stepanenko could confirm?
Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

Looks like tailwind:lint is failing because of that change :thinking:

This is not complete as we need to

Move all of the dependencies inside of each project's package.json into the root package.json
Verify that all of the packages are being built correctly (also the website)
Find an automatic script that will allow us to sync the packages inside of each project with the root version numbers

Hmmm I see.
I'm not sure I'd be very productive at finding the script for maintaining package versions.
Although the design kits don't need package versioning since it's copy&paste, and we wouldn't need to have @qwik-ui/utils if we used the cva & clsx libraries (so no package versioning here either).
For me only headless is necessary as a versioned package as of now. If you can agree with me to use the cva & clsx libraries, then it simplifies the problem. https://discord.com/channels/990511757091033108/1144897805903724564/1184777208187867136

So I managed to "fix" this by removing old tailwind-kit code.
This is a good step towards a clean repo.
I'd say let's merge this and figure out later the script for package versioning.
(fluffy button is the same as the other PR I just opened, used it in here so that preview wouldn't complain about type errors)

Ups, I pushed a rebase and removed all the changes... I'm so clumsy with git x). Closing for now. I'll make another PR.


Add new filter for swig

A new feature for swig filters, convert a string to object JSON
Example
my_str = '{"key":"value"}';
{{ my_str|json_parser }}
=> {key: value}

This repository has chosen to disable pull requests.