Feature: kong version bump 0.10.4 to 0.11.0

official changelog here: https://github.com/Kong/kong/blob/master/UPGRADE.md#upgrade-to-011x

'kong' package has changed to 'kong-community-edition'
applies changes to custom kong conf in upgrade path: https://github.com/Kong/kong/blob/master/UPGRADE.md#upgrade-to-011x
migrations are now applied manually and require stopping the kong service

I went through the output of pr-base-update and it ran as expected.

this PR needs to accommodate the fix made to 0.10 to remove the custom config after it was merged in


Revert "Bluetooth: gatt: ccc changed cb after connection cb"

This reverts commit 6bb75a53d12d3c7afd9dad628dfab40a2d79a089.
This fixes GATT that was uninitalized when application received
bt_conn_cb->connected callback. As the result, the bt_gatt_is_subscribed
was not working as expected when called from bt_conn_cb->connected.
The _bt_gatt_ccc->cfg_changed callback does not carry information about
the device that subscribed for notifications but rather is says the
app when it should start/stop broadcasting notifications.
This leads to the conclusion that the bt_gatt_ccc->cfg_changed can be
called before bt_conn_cb->connected callback.
Fixes: #42829
Signed-off-by: Mariusz Skamra<EMAIL_ADDRESS>

The change was introduced in https://github.com/zephyrproject-rtos/zephyr/pull/13473 which fixed https://github.com/zephyrproject-rtos/zephyr/issues/13316. Does reverting the commit re-introduce the issue from https://github.com/zephyrproject-rtos/zephyr/issues/13316?

The change was introduced in #13473 which fixed #13316. Does reverting the commit re-introduce the issue from #13316?

I think the #13316 is not an issue, but rather the API was misused


HAWQ-1687. Fix travis broken due to missing apr-1-config

Create for hour,
need to add apr-util libarary in hawq travis

I cannot set assignee, reviewers etc , so weird

+1


Add tests for scmp tool

Currently there are no tests for SCMP tool and it is very easy to brake the application with different changes.
At a minimum, 3 tests should be added for echo, traceroute and recordpath.

The tests should use the Go integration suite (more information here: https://github.com/scionproto/scion/blob/master/go/lib/integration/README.md).
For an example integration test that uses the above suite, please see https://github.com/scionproto/scion/blob/master/go/examples/pingpong/pp_integration/main.go.


CoffeeScript support

Can you advice how can I add coffeescript templates for package?

There is a mantra.cson file where you can defin any template. Look at the
documentation where is a full example for typescript.if you can please do
then PR with mantra.cson file for coffeescript.
Thanks!
On Wednesday, March 2, 2016, Roman<EMAIL_ADDRESS>wrote:

Can you advice how can I add coffeescript templates for package?
—
Reply to this email directly or view it on GitHub
https://github.com/mantrajs/mantrajs-atom-package/issues/19.

--
Tomi Trescak / Researcher
<EMAIL_ADDRESS>/ 0487 261 213
[image: Facebook]  https://www.facebook.com/tomi.trescak[image: Twitter]
https://twitter.com/tomitrescak[image: Google Plus]
https://plus.google.com/112630384447746070397[image: Youtube]
https://www.youtube.com/user/tomiiiino[image: Linkedin]
https://www.linkedin.com/pub/tomas-trescak/34/b92/801?domainCountryName=&csrfToken=ajax%3A3648494742469937801
[image: skype]

I meant to do this but thought I'd wait for ES6 module syntax, etc.


Logs at INFO, should be DEBUG level

asp.net 2.0  is logging items at INFO level which it should not.  It should be DEBUG or even TRACE.
Many developers are asking how to turn off the built in logging due to the excessive nature of it at such a high level.
Here is an example log:
2018-01-11 12:31:43.6913|INFO|Microsoft.AspNetCore.Hosting.Internal.WebHost|Request starting HTTP/1.1 GET http://[::]:5068/
2018-01-11 12:31:44.3189|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Executing action method XXXX.api.Controllers.ApiMetaController.Index (XXXXX) with arguments ((null)) - ModelState is Valid
On a busy site in production the log is going to be absolutely swamped with every request.  Are those "INFO" level items of information? I believe they are DEBUG or TRACE level.

+1. Info logs are too noisy. Setting the level for Microsoft.* to Warning is always one of the first things I do.

We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.

Too soon, please keep this open, it's a nuisance and needs to be fixed.

@WhatFreshHellIsThis this issue was closed because there wasn't a consensus on what work should be done and whether it would be worth the change.


[UBS Tariffs Page] Popup window 'Deactivate card confirmation' doesn't allow to 'Deactivate'.

Environment: Windows 10 Pro, Chrome 111.0.5563.65.
Reproducible: always
Build found: 01.05.2023
Preconditions

https://www.testgreencity.ga/ is opened.
User is logged in as a Super Admin<EMAIL_ADDRESS>password: Test-User123).
There is at least one active 'Tariff card'.

Mockup: https://www.figma.com/file/JvDAu4MHnh1Vxc5FaokyiA/ITA-UBS-styles?node-id=20764%3A63817
Steps to reproduce

Go to the 'Тарифи' page.
Click on the tool “Gear”.
Choose point “Деактивувати”.
Select any pricing card or some courier, station, region, or city on a new pop-up window named “Деактивувати”.
Click on the button “Деактивувати”

Actual result

The new pop-up window appeared with all selected points as text in 1 language and only the button 'Скасувати'.
Such text is visible in the upper right corner of the popup window: 'Введіть наступні дані АНГЛІЙСЬКОЮ мовою".

Expected result
The new pop-up window named “Підтвердити деактивацію” appeared with all selected points as text in 2 languages and the buttons 'Деактивувати' and 'Скасувати'.
User story and test case links
E.g.: "User story #3851
Test case"
Labels to be added
"Bug", Priority ("pri: "), Severity ("severity:"), Type ("UI, "Functional"), "API" (for back-end bugs).


error: not found: object AssemblyKeys

I'm trying to add assembly task to sbt, but when I run the reload command I get this error.
I'm using:
scala 2.10.1
sbt 0.12.2
This is my build.sbt
import AssemblyKeys._

seq(assemblySettings: _*)

This is my plugins.sbt
resolvers += Resolver.url("sbt-plugin-releases-scalasbt", url("http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/"))

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.0.0")

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.8.6")

FWIW, its 2015 and a build.sbt for a project I hadn't worked on for a while had these lines. My current environment is Scala 2.10.4 and SBT 0.13.7 on Mac OSX 10.9.5. The build.sbt was a working one in my previous machine which had Scala 2.10.2 and SBT 0.13.1 (I think). In any case, putting this comment here in case someone else has a similar problem.
import AssemblyKeys._

assemblyKeys

and when trying to do a "sbt clean compile" I was getting the following error:
/Users/palsujit/Projects/solr4-extras/build.sbt:1: error: not found: object AssemblyKeys
import AssemblyKeys._
       ^
/Users/palsujit/Projects/solr4-extras/build.sbt:3: error: not found: value assemblySettings
assemblySettings
    ^
[error] Type error in expression
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?

Removing these lines still allows you to run "assembly" from the sbt prompt. Also note that the current README.md in this project (Aug 1 2015) has no reference to these lines, so I suspect that it is no longer necessary to explicitly declare these in the build.sbt anymore as long as the plugin is registered in $PROJECT_ROOT/projects/assembly.sbt (or in ~/.sbt/0.13/plugins/plugins.sbt - thats where I have all my global plugins declared).

@sujitpal See https://github.com/sbt/sbt-assembly/blob/master/Migration.md#upgrading-with-bare-buildsbt

Thank you that explains it. I should have looked at the migration guide.


upgrade microsoft.net.compilers to 2.4.0

Upgrade all projects that have Microsoft.Net.Compilers to version 2.4.0

@BenedekFarkas related to your changes?

@sebastienros  Thanks for helping update.

@sebastienros yes! Unfortunately, I think it would be easier if we rejected the PR (sorry @aaronamm), because this is just one part of the upgrade process of the Dynamic Compilation changes we already made on 1.10.x. Btw 1.10.x includes Microsoft.Net.Compilers 2.9.0 (the current latest version), 2.4.0 is a year old.
So we'll upgrade dev to 2.9.0 as well soon.

@aaronamm yep, 1.10.x (or actually, probably the commit on 1.10.x that will be marked as the 1.10.3 release) will be merged to dev (and btw the minor version branch is more or less regularly merged into the major version branch), so most of this work is already done (on 1.10.x), there's only a couple more modules on dev that aren't on 1.10.x.
On the other hand, Microsoft.Net.Compilers is needed anymore separately (it's completely removed on 1.10.x now), because Microsoft.CodeDom.Providers.DotNetCompilerPlatform ships with it included (since version 2.0.0 I think).
1.10.x has the 2.0.1 version, so that includes the 2.10 compiler package (but a newer one has been released recently, so probably DotNetCompilerPlatform will have a new release soon as well).
So thanks and sorry, I'll close this PR, but we can coordinate on other updates (such as the other thread I just commented to).

Thank you ^^


Fix issue where newly published rc's cannot be fetched with full version string

For examples, the following was not working:
http://localhost:9393/metadata?v=12.4.0.rc.0&prerelease=false&nightlies=false&p=el&pv=6&m=x86_64
The other way to fix https://github.com/chef/opscode-omnitruck/pull/105

I prefer shipping https://github.com/chef/opscode-omnitruck/pull/105.

we're going all in on #105


use-cases: extract shared-development-server into actual article?

From https://github.com/iterative/dvc.org/pull/637#pullrequestreview-293443095

Do we need blog-like articles in a semi-static website? UPDATE: We even have a blog now...
How about extracting the more user manual-like information from the existing use cases into user guides and write actual articles to replace our use cases? These can be published in our blog, Medium, etc. (handled like a devrel matter like any other article).

UPDATE: Jump to summary: https://github.com/iterative/dvc.org/issues/654#issuecomment-738557458

OUTDATED:

by "use case" we really mean "case studies" - these are actual (mini) guides with some steps to address specific scenarios. A "use case" is a more general problem solved by the system, they typically map directly to features in a system, so really the current some of the [User Guide](https://dvc.org/doc/user-guide docs are closer to actual use cases in my understanding.

Related to #425; Could work on them together 🙂

and maybe even rename User Guide to User Manual. Same concept but a little better naming because we can call each document inside a "guide" without causing confusion with the parent section (the manual).

Some comments from @shcheklein:
From https://github.com/iterative/dvc.org/pull/637#pullrequestreview-293500033 (regarding the list of guides in /user-guide/index.md)):

I hope that we'll have a proper third level soon to cluster some of these by topics. Not for this PR for sure...

From https://github.com/iterative/dvc.org/pull/637#discussion_r329336744 (regarding reorganizing "External Data" guides):

The idea is to eventually (and I was waiting for the engine to properly support 3 levels) - is to have one single Manage External Data second level section, that will include External Outputs, External Dependencies, External Cache, Shared Cache (or a better title to explain cases like #565, #455), and other related articles.

From https://github.com/iterative/dvc.org/pull/637#discussion_r329337401:

Regarding the User Guide - there are sections like "Large Files Optimization" - it's not a use case by itself, it's a technical description how to fine fine tune DVC in certain situations. I think UG should include things like Pipelines -> How to Edit, How to Create, etc. And Updating Tracked Files is very similar in my mind to those.

How about extracting the more user manual-like information from the existing use cases into user guides and write actual articles to replace our use cases? These can be published in our blog, Medium, etc.

Another option is to describe a Use Case (or Case Study or whatever we call them) as an interactive Katacoda example (if this is possible). A working concrete example is easier to understand than wordy explanations with hypothetical situations.

Online interactive tutorials are complimentary and are not replacements for "wordy explanations". They make it easier things to run, sometimes easier to understand. But they still require explanations around them - motivation, what's happening, etc.

We definitely want interactive tutorials also, but the case studies are not meant to be that detailed. They contain real-life problems but don't provide exact end-to-end commands to solve them (which would make the documents longer as well as harder to maintain). They just show the core actions and DVC commands needed to address a class of problems. At least this is how Use Cases are designed at the moment.

Just found a good example of something closer to my definitions of use case vs. case study

A "use case" is a more general problem solved by the system, they typically map directly to features...
by "use case" we really mean "case studies"

See https://www.hashicorp.com/products/terraform:

vs.

Except here, case studies are actual real-life "success stories", told in hindsight (explaining how the tool was used).

@jorgeorpinel exactly, that's why I don't the "case study" term - it's has a very well defined meaning - a real-life "success story".
Terraform use cases (with some adjustment that they are not published in the docs) look more or less as what we are trying to do with our Use Cases. Our cases a bit lower level since they are part of the docs, but the idea is the same. The should be describing a high level problem, then a high level solution (with links to the implementation details).

The main point here is that our Use Cases should not feel like tutorials. I think it's fine to give some examples, or some code snippets, but mostly the should be focused around the problem. Thus for example we have images, but we never did them executable.
Our user guide is very far from describing use cases.

I agree that "case study" is not the best term and that our first 2 use cases could be seen as high-level enough. I guess it's just the last one, https://dvc.org/doc/use-cases/shared-development-server, that I don't see as a use case. This one I would still recommend to get out the docs into a blog post perhaps. I think it's too specific, not a general problem that DVC as a product is designed to solve, just something you happen to be able to setup with DVC.
I would also rename the 2nd one "Sharing Data and Model Files" (using infinitive tense).

Same for "Updating Tracked Files" in the user guide (for consistency). Added to https://github.com/iterative/dvc.org/issues/720#issuecomment-544627027

@jorgeorpinel agreed. Sharing dev server probably should be renamed and generalized into - resource optimization or something similar. It's definitely stands out. But we need to come up with a better name place for it.

Summary of discussion above

How about extracting the more user manual-like information from https://dvc.org/doc/use-cases/shared-development-server into user guides and write actual articles to replace our use cases? These can be published in our blog, Medium, etc. (handled like devrel [material])
I think it's too specific, not a general problem that DVC as a product is designed to solve, just something you happen to be able to setup

agreed. Sharing dev server probably should be renamed and generalized into - resource optimization or something similar
our Use Cases should not feel like tutorials. I think it's fine to give some examples, or some code snippets, but mostly the should be focused around the problem. Thus for example we have images

Note: also https://dvc.org/doc/user-guide/managing-external-data shouldn't link to https://dvc.org/doc/use-cases/shared-development-server#configure-the-external-shared-cache for instructions to config an external cache, as shared external caches are not compatible with external outputs (see https://github.com/iterative/dvc/issues/4520#issuecomment-774649551).


Feature request: monitoring widget

I love the app! One feature I miss is observing my sensor's data in the home screen of my phone with an android widget. Currently I have another app "Asia air quality" that has such widget. It's not tied to my sensor, but to a official public one. I hope you like the idea.

Hello,
we like the idea and we already heared it a few times. Now we're going to implement this into our app, but it can last a few weeks. Thanks for your feature request.

We added this feature (https://github.com/mrgames13/Feinstaub-App/commit/205db5494cbcf20581e5e18535ee33695dab6265). We will test it and release the update the next few days.


Interrupt version of input with SDK not working

I did some tests and did not managed to get async version to generate interrupts, so I do not know if someone did test it with SDK?
Normal read function if working nicely. This is simple receiver test with WS leds.
https://www.youtube.com/watch?v=sD5nIOLsvXA&feature=youtu.be
I hope that I can port my firefly board to RP2040, as initial Atmega chip is not available for a long time...
https://kitspace.org/boards/github.com/intergalaktik/firefly/

By "with the SDK" you mean without the Arduino framework?

Well yes, that was my question, and tnx for answer :)

Can you try setting DMX channel 512 (the last one) to some value other than 0 in your sending software to avoid short frames?

Sure I can try, I did not use full 512 bytes as I have 100 RGB leds on bigger panel so it could be that.
And I am using QLC+ with one board that just have FTDI >> RS485 at some point I would like to replace that with RP2040 USB >> RS485

Nice LED-boards by the way ;)

Tnx!
Unfortunately chip shortages kills all the fun :)
My next evil plan is to make new version more modular so I can just change module if some chip starts to be unavailable.

Sure I can try, I did not use full 512 bytes as I have 100 RGB leds on bigger panel so it could be that. And I am using QLC+ with one board that just have FTDI to RS485 at some point I would like to replace that with RP2040 USB to RS485

Yeah, with QLC+ it's easy, just go to "Simple Desk", "scroll" to the side and pull the last slider up ;)
If you want RP2040 USB to RS485 you might want to check out https://github.com/OpenLightingProject/rp2040-dmxsun. It always generates full DMX frames on all universes / RS485 outputs.

I now have two pico boards, one is loaded with OUTPUT, second with LEDs is loaded as INPUT
I have now more then 512 values and they should all be filled with value 20
When I use blocking dmxInput.read(buffer); function everything is working.
And when I set async I am still not able to get any interrupts, and nothing changes on INPUT device.
https://gist.github.com/goran-mahovlic/6f173cfc83d0db7202b8254fd14a96da

If you want RP2040 USB to RS485 you might want to check out https://github.com/OpenLightingProject/rp2040-dmxsun. It always generates full DMX frames on all universes / RS485 outputs.

I did find that project but did not test, maybe it is right time to do so :)

Ups, I was missing function pointer - https://gist.github.com/goran-mahovlic/6f173cfc83d0db7202b8254fd14a96da#file-dmx_in_out-cpp-L86 It is working now, thank you! Will close this issue...


Need to support RELEASE version for openboard and enterprise

Openboard community version is Board
Enterprise version is iBoard

mr #1739


Fix issue request #49

This is fixing Issue #49 which adds multicore support to the paired demux command.  Previously cutadapt did not support multicore runs but v3.0 does with the -j CORES parameter.
This speeds up demux dramatically by the factor of the number of cores. A single Miseq run takes 3-4 hrs on a single-threaded run and ~20mins with 96 cores.
This addition just adds the parameter --p-cores but if this is left off it should default to 1.  An option is to default to 0 which would use all available processors, but I think it is safer to leave as 1 for default.

Hey @hyphaltip, sorry we lost track of this a bit. We've got a release coming up soon, and it would be great to have this added. Are you able to fix some of the lint errors? If not, we could fix those and take it across the finish line.

i have fixed lint errors now - thanks for pointing out (I don't think I saw these back in the original pull requests)

Thanks @hyphaltip!
There's some test failures now, but I think they are quite simple to resolve, the _build_demux_command now has the cores parameter, which isn't what the tests were prepared for. We could add a default of =1 for that particular helper so that the test call-sites look the same, but odds are the assertions will need to be updated as there is indeed a new and meaningful parameter. So it might be best to just update the tests to expect cores and assert something about the passed argument.

Let me know your preference. Sorry I think I wasn't running the test suite properly. I can also just add cores=1 default for the tool?

Let's update these tests, that'll be the ideal way to handle this.
These are the current failures:
  FAILED tests/test_demux.py::TestDemuxUtilsSingleEnd::test_build_demux_command
  FAILED tests/test_demux.py::TestDemuxUtilsPairedEnd::test_build_demux_command
  FAILED tests/test_demux.py::TestDemuxUtilsPairedEnd::test_build_di_demux_command

You should be able to assert that the cores passed match the resulting build command, which should be a list of arguments.
And an easy way to run the tests is to use our Makefile, I usually grab the latest development environment or just any one that is handy and which I don't care too much about, then in almost any repo we have you can run:
make dev   # to install
make test  # to run tests

I tried again, moved arguments around so they are consistent and tests should pass now except for these types of warnings:
skbio/sequence/_sequence.py:28: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working
    collections.Sequence, SkbioObject):

../qiime2-dev/lib/python3.8/site-packages/skbio/io/format/gff3.py:217
  /bigdata/stajichlab/jstajich/projects/qiime2/qiime2-dev/lib/python3.8/site-packages/skbio/io/format/gff3.py:217: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working
    from collections import Iterable


Handle link preview DOSes better

Right now, when users with many followers (eg @tantek) post, they incur the infamous Mastodon DOS: mastodon/mastodon#4486, mastodon/mastodon#21861. Here's an example for https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo .
We ended up forwarding 20-30qps to tantek.com for 5-10m, which overwhelmed it. Most of those requests hit our 15s timeout, and some didn't connect at all, so we served a lot of 504s and 502s to Mastodon requests for /r/https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo and /tantek.com and a bit of<EMAIL_ADDRESS>Ugh.

^ This idea of extending cache items on failures is doable, but complicated to add to flask_util.cached. Also, our HTTP request timeout is 15s, so all incoming requests in that 15s window would incur overlapping HTTP requests, until the first one times out and we start serving from cache again. We could add a lock to only do the first re-request, but that's even more complicated.
For now, I've bumped up the cache size from 500 to 3k and expiration from 10s to 60s.

Also switching all of these endpoints to cache 502s and 504s instead of re-requesting.

Also started caching more errors: snarfed/webutil@b9fcfecfba3a532dd931ace678784bee6802daf5

Waiting for @tantek's next 100DoIW post to stress test this, then hopefully I'll close. For now. 🤷

New post just now, we did ok, but not nearly as well as I'd hope.

Caching worked, it served most of the requests for /r/https://tantek.com/2023/026/t1/indieweb-priorities-balance and /r/tantek.com, but those cached requests still took 2-4s each to serve since so many hit at the exact same time, so they evidently sat in the pending queue for a while. Seems surprising, needs more investigation.

One thing to keep in mind, when I see requests under load that should have been cached but weren't, they were probably served by a different instance, so its cache was still cold since it's not shared.

Two more spikes this morning:

repost of https://snarfed.org/2023-01-21_49123 at ~8:13a PT
more for https://tantek.com/2023/026/t1/indieweb-priorities-balance, probably also due to a repost

Same pattern of requests for both, roughly equal number for the /r/ URL and the author's actor. Notably though, the snarfed.org spike didn't see all the 5xxes due to timeouts, and hence had much better cache hit rate.

^ #392 should help a lot here.

All of these requests are served from the datastore now! Closing as fixed.


Problem with React Types 18

After migrating to React 18, I'm getting Typescript compilation error:
TS2786: 'DatePicker' cannot be used as a JSX component.
Its instance type 'ReactDatePicker<never, undefined>' is not a valid JSX element.
To Reproduce
Create an instance of DatePicker:
export default function Test() {

    return (
        <>
            <DatePicker
                portalId='portalroot'

                dateFormat="d-MMMM-yyyy"
                onChange={(date: Date) => {
                    Log(`new Date ${date}`)
                }}
            />
        </>
    );
}

with the following line in the devDependencies in package.json
    "@types/react": "^18.0.15",
Expected behavior
successful compilation
**Desktop

OS: Win 11
Browser Chrome

Additional context
Reverting the React types to 17.0.47 removes the problem (even whilst using React 18.2.0)

I'm using React Type 17.0.33 and getting the same error here

This is probably due to the React 17 type definition file being mixed in with your project.
In react-datepicker type definition package, the dependecy of the React type definition looks like this.
    "dependencies": {
        "@popperjs/core": "^2.9.2",
        "@types/react": "*",
        "date-fns": "^2.0.1",
        "react-popper": "^2.2.5"
    },

Check how your yarn.lock (or package-lock.json) resolves @types/react@*.
If it references version 17 as shown below, it should be modified to refer to version 18.
"@types/react@*":
  version "17.0.38"

I got the same problem but I just fixed adding the resolutions prop into my package.json and run yarn
"resolutions": {
   "@types/react": "18.0.8",
   "@types/react-dom": "18.0.3"
 },

I'm still not quite sure why it works but I'm keen to hear any thoughts
I noticed that after running yarn, it made this change on yarn.lock

Fixed it for me too, thanks!


Should we stop using auto-generated docs?

The idea behind auto-generated documentation is a very good one, but in practice it has caused the documentation site to feel splintered and difficult to navigate.
I propose that we move from auto-generated docs to manually maintaining pages as party of the github.io site.
Some advantages:

It gives us greater control over the documentation as a whole
It means that we're not including documentation source in the individual repos (which is then downloaded as part of those packages)
It provides greater visual consistency between the component documentation and the github.io site
We an add some other documentation nice to haves (to be detailed in future issues)
Potentially ends the circular dependency weirdness of cf-core and cf-component demo

The only disadvantage that I can come up with, is that we will have to update the documentation site when we update a package. If we fail to do this, the docs could become outdated.
Thoughts? CC @cfpb/front-end-team-admin

I want to follow this issue because the auto-generated docs were one of the biggest things I struggled with when I first started contributing to CF. The way our docs are generated (and the usefulness of our docs in general) is a huge barrier to entry and we don't do a good job of documenting our documentation process.
Here are some of the issues I have with the auto-generated docs right now:

Small issues can break topdoc without any useful errors for debugging
It's very difficult to find where something is if it's split among multiple components. (I struggle the most with information that's in typography or core)
If a certain pattern uses multiple components, it can be difficult to add that to the documentation.
There are so many modules that the "guess the module" game is taking more time and even more of a barrier for newcomers.

One more thing, anytime any piece of CF gets updated the other modules will have a diff with documents and demos, which means we're constantly checking in the newest changes there and seeing this. Even if we're checking in a change that has nothing to do with those recently merged PRs.

Another thing. Our demos are filled with errors from our accessibility testing and fixing it one place takes forever, much less fixing it in all the repos. Switching over to the 18F colors will help, but it'd be much less stressful to maintain in one place.

Yes kill it
We should integrate CF documentation in the Design Manual where it belongs, like the US Web Design Standards.

Goals for Design Manual Docs:

Docs are still updated and maintained in one place (CF)
Markup code snippest are imported to Design Manual for easy reference
Design Manual links to related components docs in CF for more detailed implementation notes

I think @cfarm describes a good hybrid approach. Full documentation can live here while copy and paste-able markup can also exist in the design manual for easy reference.

I can dig it, @cfarm. I think that's actually something we wanted to do back in the day, just couldn't get around to it.

"that" = somehow semi-automagically getting markup snippets from CF into the DM.

Yinz have any thoughts on implementation details? How do you see docs living here and being consumed elsewhere (i.e. in the design manual)?
Proposal: Have a docs.md, snippets.md and preview.html in each component directory. They can be pulled into the design manual via a Grunt task. Using cf-buttons as an example:

preview.html contains markup of all the buttons in their various states. It's rendered at the top of the manual's buttons page.
snippets.md contains code samples for copying/pasting. It is parsed and rendered into an expandable below the rendered buttons.
docs.md contains optional component usage notes.

The above works for the USWDS layout but doesn't actually work with our layout. Our docs and previews are side-by-side. Sooooo this isn't a great proposal but I'd love to find a hybrid solution to avoid having to manually update the design manual every time we change a component. Things'll get stale real quick.

Yinz

Well played.
I agree that manually updating the design manual is less than ideal, though @contolini's proposal would still require some manual intervention to get the design manual to build with updates (unless I'm mis-understanding).
Q: How often does just the markup of a CF component in the design manual change? Is something like above worth the initial overhead? I want to avoid any solution that overcomplicates things in an attempt at simplicity.

Making manual updates in two places is what I'd like to avoid. If we're only manually updating one place -- the design manual -- then I don't think we need any automagic processes like the one I described above.

Sorry for the lack of implementation details, but it seems like it would be helpful to pipe preview.html as a stub into an automated test that checks for adherence to the specifics Design mocked up.

Sorry for the lack of implementation details, but it seems like it would be helpful to pipe preview.html as a stub into an automated test that checks for adherence to the specifics Design mocked up.

:heart_eyes:

Superseded by the two new doc improvement paths #242 and #243).


Health Check > When Unhealthy > Re-Start

"Re-Start" as an in between of "Take no action" and "Re-create"
Subsequently, perhaps even a more complex "Re-start [X] times, then Re-create when at least [Y] is healthy".
These is actually my instance debugging steps, for several installation where re-create, is a less then ideal option. Especially if it re-downloads its "cluster data" in GB's
A mock-up is as bellow

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


App crash when targeting sdk level 27

Bug Report
Current behavior
When targeting SDK level 27 the app crashes every time when disconnecting from Session.
Steps to reproduce
Set target SDK level to 27 and build one of the example apps(cordova-android-support-gradle-release may be needed and set to 26.+)
Example Project
https://github.com/opentok/opentok-cordova-samples
What is the current bug behavior?
App crashes on disconnect.
What is the expected correct behavior?
That the app doesn't crash.
 Will look further into it and report my findings, or make a PR.

@wolfenrain @mark-veenstra Thanks for reporting this. I just build a basic application and ran it on the emulator and was not able to reproduce this issue.
I called the unsubscribe method after the session had been disconnected and it still didn't crash.
Is this happening on a specific device?

@msach22 as seen in the PR, it triggers "randomly" when you close the Session, apparently then it will still receive certain events because the session is still disconnecting. So it is not necessary because of the unsubscribe. More a stream/connection dropped because the other side disconnects session as well at the same time
Hope that explained some, I will be gone for the weekend so will try to explain more if needed

@wolfenrain Thanks for the update, I will investigate further and update you on my findings!

@msach22 Did you manage to find anything else that may be involved with this?

@wolfenrain I am still unable to reproduce this behavior


asyncio error while loading weights

I'm trying to run the example from the docs on saving / loading model weights. My first notebook run worked just fine but subsequent runs failed with the following error:
File /opt/miniconda/envs/multienv/lib/python3.10/asyncio/locks.py:234, in Condition.__init__(self, lock, loop)
...
ValueError: loop argument must agree with lock

Here is my code:
import numpy as np
import jax
from jax import random, numpy as jnp

import flax
from flax import linen as nn
from flax.training import checkpoints, train_state
from flax import struct, serialization

import orbax.checkpoint
import optax

key1, key2 = random.split(random.key(0))
x1 = random.normal(key1, (5,))
model = nn.Dense(features=3)
variables = model.init(key2, x1)

tx = optax.sgd(learning_rate=0.001)
state = train_state.TrainState.create(
    apply_fn=model.apply,
    params=variables['params'],
    tx=tx)

state = state.apply_gradients(grads=jax.tree_map(jnp.ones_like, state.params))
config = {'dimensions': np.array([5, 3])}
ckpt = {'model': state, 'config': config, 'data': [x1]}

from flax.training import orbax_utils

orbax_checkpointer = orbax.checkpoint.PyTreeCheckpointer()
save_args = orbax_utils.save_args_from_target(ckpt)
orbax_checkpointer.save(CKPT_DIR, ckpt, save_args=save_args)

raw_restored = orbax_checkpointer.restore(CKPT_DIR)

System information

OS Platform and Distribution: Linux (Github Codespaces)
Flax, jax, jaxlib versions (obtain with pip show flax jax jaxlib:

flax: 0.8.0
jax: 0.4.23
jaxlib: 0.4.23+cuda12.cudnn89

Python version: 3.10
GPU/TPU model and memory:

+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla V100-PCIE-16GB           On  | 00000001:00:00.0 Off |                  Off |
| N/A   29C    P0              36W / 250W |  12440MiB / 16384MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

CUDA version (if applicable): 12.3

Hey! I ran this code locally and it works:
import jax
import numpy as np
import optax
import orbax.checkpoint
from jax import numpy as jnp
from jax import random

from flax import linen as nn
from flax.training import train_state

key1, key2 = random.split(random.key(0))
x1 = random.normal(key1, (5,))
model = nn.Dense(features=3)
variables = model.init(key2, x1)

tx = optax.sgd(learning_rate=0.001)
state = train_state.TrainState.create(
  apply_fn=model.apply, params=variables['params'], tx=tx
)

state = state.apply_gradients(grads=jax.tree_map(jnp.ones_like, state.params))
config = {'dimensions': np.array([5, 3])}
ckpt = {'model': state, 'config': config, 'data': [x1]}

from pathlib import Path

from flax.training import orbax_utils

CKPT_DIR = Path('CKPT_DIR').absolute()

orbax_checkpointer = orbax.checkpoint.PyTreeCheckpointer()
save_args = orbax_utils.save_args_from_target(ckpt)
orbax_checkpointer.save(CKPT_DIR, ckpt, save_args=save_args)

raw_restored = orbax_checkpointer.restore(CKPT_DIR)

Are you running this on colab?

No I'm using Codespaces @cgarciae. Your code is bringing up the same error as well

I remember that before you used to monkey patch asyncio so orbax worked on jupyter/colab, maybe something similar is happening here? As a note this code runs ok in colab.

You should post an issue on the orbax repo.


Dropwizard hibernate: using transactional and DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT in parallel requests generates the error "Cannot commit when autoCommit is enabled."

When we have DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT in our handling mode configuration and we try to use a resource with transactional = true,
if we make two parallel calls to this service we take the error "Cannot commit when autoCommit is enabled."
Can't use DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT and have a resource with transactional = true?
Or It's a bug?
Sample code:
@Path("/test")
public class TestTransactionalWithAfterStatement {

	private PersonDAO dao;

	public TestTransactionalWithAfterStatement(PersonDAO dao) {
		this.dao = dao;
	}

	@Produces(MediaType.APPLICATION_JSON)
	@GET
    @Timed
    @UnitOfWork
    @Path("/{id}/name/{name}")
    public Long sayHello(@PathParam("id") int id, @PathParam("name") String name) throws InterruptedException {
		Person person = new Person(id, name);
		long number = dao.create(person);
		Thread.sleep(10000);
		return number;
    }

}

Hibernate config:
properties:
    charSet: UTF-8
    hibernate.dialect: org.hibernate.dialect.PostgreSQLDialect
    hibernate.jdbc.fetch_size: 1000
    hibernate.jdbc.batch_size: 30
    hibernate.connection.autocommit: false
    hibernate.connection.isolation: java.sql.Connection.TRANSACTION_READ_COMMITTED
    hibernate.temp.use_jdbc_metadata_defaults: false
    hibernate.connection.handling_mode: DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT

If we switch to DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION then it works...

No answer to this issue until now...

@irineuruiz Have you tried posting your questions on the dropwizard-user mailing list?
https://groups.google.com/g/dropwizard-user

@irineuruiz Did you try setting @UnitOfWork(flushMode = MANUAL or COMMIT)?


VNode error

Please answer these questions before submitting your issue.

Why do you submit this issue?
[x ] Question or discussion
[ ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question

What do you want to know?

what does it means?sometimes it happend.

Bug

Which version of SkyWalking, OS, and JRE?

Which company or project?

What happened?
If possible, provide a way to reproduce the error. e.g. demo application, component version.

Requirement or improvement

Please describe your requirements or improvement suggestions.

Read FAQ.


HDDS-9674. Read from non-datanode host should consider topology

What changes were proposed in this pull request?
Client's node (place in the topology) is looked up via SCMNodeManager.getNodesByAddress.  But SCMNodeManager only knows about datanodes.  If the request comes from a host which does not run Ozone Datanode, then read will not be topology-aware.  While read cannot be host-local in this case, it still could benefit from being rack-local.
Examples where such non-datanode hosts may occur:

edge nodes (client-only)
dedicated metadata nodes (OM, SCM, etc.)
Docker/Kubernetes containers running only one service

https://issues.apache.org/jira/browse/HDDS-9674
How was this patch tested?
Added unit test.
Manually tested on ozone-topology environment:

added s3g container in docker-compose.yaml with address <IP_ADDRESS>
added scm (in rack1) and s3g (in rack2) in topology network-config
changed test.sh to run basic/basic.robot and s3/objectputget.robot
enabled debug logging for KeyManagerImpl

OM log shows datanodes in the same rack were sorted to head of list for both scm and s3g:
DEBUG om.KeyManagerImpl: Sorted datanodes [8fa9bb3e-3ff4-4f9b-a71e-0ffffcd70be5(ozone-topology_datanode_5_1.ozone-topology_net/<IP_ADDRESS>), 04478345-c6ef-4c2b-a688-8819babd5db7(ozone-topology_datanode_2_1.ozone-topology_net/<IP_ADDRESS>), a8a8f57f-a0dc-41e5-9bcc-f7278f0ba7c3(ozone-topology_datanode_4_1.ozone-topology_net/<IP_ADDRESS>)] for client <IP_ADDRESS>, result: [04478345-c6ef-4c2b-a688-8819babd5db7(ozone-topology_datanode_2_1.ozone-topology_net/<IP_ADDRESS>), a8a8f57f-a0dc-41e5-9bcc-f7278f0ba7c3(ozone-topology_datanode_4_1.ozone-topology_net/<IP_ADDRESS>), 8fa9bb3e-3ff4-4f9b-a71e-0ffffcd70be5(ozone-topology_datanode_5_1.ozone-topology_net/<IP_ADDRESS>)]
DEBUG om.KeyManagerImpl: Sorted datanodes [8fa9bb3e-3ff4-4f9b-a71e-0ffffcd70be5(ozone-topology_datanode_5_1.ozone-topology_net/<IP_ADDRESS>), 04478345-c6ef-4c2b-a688-8819babd5db7(ozone-topology_datanode_2_1.ozone-topology_net/<IP_ADDRESS>), a8a8f57f-a0dc-41e5-9bcc-f7278f0ba7c3(ozone-topology_datanode_4_1.ozone-topology_net/<IP_ADDRESS>)] for client <IP_ADDRESS>, result: [a8a8f57f-a0dc-41e5-9bcc-f7278f0ba7c3(ozone-topology_datanode_4_1.ozone-topology_net/<IP_ADDRESS>), 8fa9bb3e-3ff4-4f9b-a71e-0ffffcd70be5(ozone-topology_datanode_5_1.ozone-topology_net/<IP_ADDRESS>), 04478345-c6ef-4c2b-a688-8819babd5db7(ozone-topology_datanode_2_1.ozone-topology_net/<IP_ADDRESS>)]

CI:
https://github.com/adoroszlai/ozone/actions/runs/6882001098

@tanvipenumudy @vtutrinov @ibrusentsev can you please take a look?

@adoroszlai thanks for the PR, LGTM+

No objections, LGTM

@ChenSammi please review

Thanks @ibrusentsev, @sodonnel, @tanvipenumudy, @vtutrinov for the review.


MSbuild doesn't complete Stage 2

Empire Version
Master
OS Information (Linux flavor, Python version)
Kali Server
Windows 10 Client
Expected behavior and description of the error, including any actions taken immediately prior to the error. The more detail the better.
Working empire agent after running msbuild launcher.xml
Screenshot of error, embedded text output, or Pastebin link to the error
(Empire: agents) > [] Agent D4XWNYRS returned results.
[] Valid results returned by <IP_ADDRESS>
[] Sending POWERSHELL stager (stage 1) to <IP_ADDRESS>
[] New agent RP2Y9CVX checked in
[+] Initial agent RP2Y9CVX from <IP_ADDRESS> now active (Slack)
[*] Sending agent (stage 2) to RP2Y9CVX at <IP_ADDRESS>
Stops there and the agent loses connection
Unhandled Exception: System.Management.Automation.CmdletInvocationException: Cannot validate argument on parameter 'Seconds'. The -22 argument is less than the minimum allowed range of 0. Supply an argument that is greater than or equal
to 0 and then try the command again. ---> System.Management.Automation.ParameterBindingValidationException: Cannot validate argument on parameter 'Seconds'. The -22 argument is less than the minimum allowed range of 0. Supply an argument
that is greater than or equal to 0 and then try the command again. ---> System.Management.Automation.ValidationMetadataException: The -22 argument is less than the minimum allowed range of 0. Supply an argument that is greater than or e
qual to 0 and then try the command again.
Any additional information
It seems as if exceptions are causing it to crash completely instead of continuing like in powershell. Is there any way to change the automation dll to continue on exceptions?

OK I found it it was because the stager retries was 0. After setting it to like 100, it works.

I found that this is caused by the exe crashing when there is an unhandled exception thrown by PowerShell. By default, powershell will ignore errors. This is due to the fact that it uses pipeline.Commands.AddScript(cmd). However, the PowerShell class does not have this problem. The same problem exists in SharpPick.
Here is the SharpPick modifications I made:
https://github.com/TheKevinWang/SharpPick
I also modified the xml file to use this method:
https://gist.github.com/TheKevinWang/b80eb6430861f0511c71f9d221a8debd
I was able to get the dropbox module to work. However, a lot of modules still don't work in this kind of run environment.

@passwordleak I'll take a look at this. I would suggest not using the Dropbox module.  The agent receives and processes commands without issue

Are you setting Obfuscate to True when generating the xml?

Are you using the dropbox module? From the screenshot, it seems like you're using the http listener.  I got the http module working just fine, however the dropbox module didn't work. The xml file provided by @TheKevinWang did work for me though.
I have the Obfuscate set to false.

@passwordleak I wasn't able to reproduce the issue you were having with the dropbox listener.

@passwordleak I'm going to close this out for now. If you are able to reproduce this again, please let me know.


window.history.state freezes after restarting the browser when using initialLocation (address bar doesn't change for new routes)

Steps to reproduce
This will only happen when you set an initialLocation for GoRouter, in our case to keep the last location the user visited.
It sometimes needs many tries until it's reproducible so might just happen random. It seems that something is breaking the window.history.state so it doesn't get updated anymore.

Open several routes in a row by clicking through many widgets.
Restart the browser.
Try to open a different route and look at the address bar. For me the URL in the address bar doesn't change anymore although I can still open different pages. Neither using the Navigator nor GoRouter will update that.

When this happens, neither Navigator nor GoRouter can update the window.location anymore.
I have found a workaround for this, in case someone has the same problem and needs to solve it somehow, just call this on web app start:
window.history.pushState(
  {
    'serialCount': 0,
  },
  initialLocation, // replace with what you want as initialLocation
  null,
);

Expected results
URL in the address bar should change when I go to different routes.
Actual results
After clicking through several pages and then restarting the browser, the URL in the address bar doesn't change anymore (only when initialLocation is set).
Code sample
To be honest I wasn't able to reproduce this in a small sample app. Even for the app that I work on in my job I can sometimes only reproduce it after some tries.
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.24.3, on Ubuntu 22.04.5 LTS 6.8.0-45-generic, locale de_DE.UTF-8)
    • Flutter version 3.24.3 on channel stable at /home/malin/bin/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2663184aa7 (vor 6 Wochen), 2024-09-11 16:27:48 -0500
    • Engine revision 36335019a8
    • Dart version 3.5.3
    • DevTools version 2.37.3

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/malin/AndroidSDK
    • Platform android-34, build-tools 30.0.3
    • ANDROID_HOME = /home/malin/AndroidSDK
    • ANDROID_SDK_ROOT = /home/malin/AndroidSDK
    • Java binary at: /opt/android-studio/jbr/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 14.0.0-1ubuntu1.1
    • cmake version 3.22.1
    • ninja version 1.10.1
    • pkg-config version 0.29.2

[✓] Android Studio (version 2021.2)
    • Android Studio at /usr/local/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] Android Studio (version 2022.2)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 76.3.1
    • Dart plugin version 222.4582
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.94.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.82.0

[✓] Connected device (3 available)
    • SM G970F (mobile) • RF8M22KPTEE • android-arm64  • Android 12 (API 31)
    • Linux (desktop)   • linux       • linux-x64      • Ubuntu 22.04.5 LTS 6.8.0-45-generic
    • Chrome (web)      • chrome      • web-javascript • Google Chrome 130.0.6723.58

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Hi @mErrenst

Restart the browser.

Do you mean to close and reopen browser? Can you provide more specific steps to reproduce along with a complete and minimal sample code so that I can verify this issue on my end? And a demo video would be appreciated. Thanks!

@huycozy I mean close (all windows of the browser) and reopen the browser.
And I'm really sorry but I tried to reproduce it in a minimal sample app but wasn't able to. Probably this only happens in more complex apps.
What I can provide is our GoRouter config:
GoRouter(
      navigatorKey: goRouterNavigatorKey,
      observers: [
        SentryNavigatorObserver(),
      ],
      initialLocation: SplashScreen.initialRoute,
      refreshListenable: StreamListenable(client.onLoginStateChanged.stream),
      redirect: rootRedirector,
      routes: [
        GoRoute(
          path: '/',
          redirect: rootRedirector,
          routes: columnMode ? _tabletRoutes : _mobileRoutes,
        ),
        ..._homeRoutes,
      ],
      debugLogDiagnostics: true,
    );

I already tried to strip off all config except for the initialLocation which is set in a widget.
When this happens, it will happen again even when just refreshing the page until I remove the complete route from the URL in the addressbar (just leaving the domain) or call window.history.pushState(). If I remove just parts of the route and press enter it works again until reload or restart.
Bildschirmaufzeichnung vom 22.10.2024, 13:27:33.webm

Thanks for your update. Maybe this is related to logic inside your redirection rootRedirector?
Without a minimal sample code or consistent steps, the issue unfortunately is unactionable. For the issue to be workable, it needs to be reproducible with a completed and minimal reproducible code sample that doesn’t include 3rd party plugins or complex production code. Please try to narrow the project code down until you see a pattern to reproduce the issue consistently. Please also check Provide reduced test cases, thank you!

Maybe #132464 is related since GoRouter doesn't correctly recognize the initial state


Should wizard put project ID in appengine-web.xml?

@patflynn keeps telling me that the project ID should not be in appengine-web.xml and instead supplied at deploy time. However the App Engine docs don't agree:
https://cloud.google.com/appengine/docs/java/config/appref
In fact, they state that this element is "required", not merely allowed. OTOH the schema indicates it's optional:
<xs:element type="xs:string" name="application" minOccurs="0"/>

The docs may be out of date. Resolve this (if necessary by fixing the docs)
If we indeed don't want to include the project ID, then we should pull it out of the wizard dialog for creating new projects.

If we indeed don't want to include the project ID, then we should pull it out of the wizard dialog for creating new projects.

Or maybe find a different way to specify it?  It can be used for auto-populating the deploy dialog.

fixed. we don't include it.


ARTEMIS-4782 ActiveMQConnectionFactory - Add getBrokerURL method

This is turning into a bit of a head-ache. It's definitely not as straight-forward as it first appeared due to URL parsing, conversion, etc. I'm shelving this for now.


typescript-wallet-sdk: adding last missing code examples

adds typescurpt code examples for these missing sections of the Build A Wallet section:

fee-bump
sponsoring
modifying accounts

will hold to merge after https://github.com/stellar/typescript-wallet-sdk/pull/46

Preview is available here:http://developers-pr224.previews.kube001.services.stellar-ops.com

In examples I see every builder is created like this
const txBuilder = await stellar.transaction({
  sourceAddress: sourceAccountKeyPair,
  baseFee: 100,
});

baseFee is optional, right? Can you omit it everywhere?

A bit unrelated, but can you change timeout in submitWithFeeIncrease from 180 to 30 to match documentation description?

This will create and sign the transaction that originated from the sourceAccountKeyPair. Every 30 seconds this function will re-construct this transaction with a new fee (increased by 100 stroops), repeating signing and submitting

baseFee is optional, right? Can you omit it everywhere?

Ya not sure why it wasn't, I changed here if you could approve plz:
https://github.com/stellar/typescript-wallet-sdk/pull/49

Preview is available here:http://developers-pr224.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr224.previews.kube001.services.stellar-ops.com


Make stemcells configurable by deployment

Description
This PR replaces #3232 and makes stem cell containers configurable from the runtime manifest. See the changes to runtimes.json for an example (or the new tests). It is possible to have multiple stem cells per runtime kind. For example:
{ "runtimes": {
    "node": [
      {
        "kind": "nodejs:6",
        "image": {
          "name": "nodejsaction"
        },
        "stemCells": [{
          "count": 1,
          "memory": "128 MB"
        }]
      }, {
        "kind": "nodejs:8",
        "default": true,
        "image": {
          "name": "nodejsaction"
        },
        "stemCells": [{
          "count": 1,
          "memory": "128 MB"
        }, {
          "count": 1,
          "memory": "256 MB"
        }]
      }
    ]...

This PR improves #3232 with stricter types on the StemCell configuration, filters configrations for runtimes for the ones that exists to make it easier to work with stem cells in the invoker.
Closes #2401.

Related issue and scope

[x] There is an open an issue to propose and discuss this change (#2401)

My changes affect the following components

[ ] API
[x] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[x] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[x] Tests
[x] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[x] Enhancement or new feature (adds new functionality).
[x] Breaking change (a bug fix or enhancement which changes existing behavior).

Labelled breaking change because it will require downstream changes to enable stem cells.
It's plausible we should warn or fail startup if no stemcells are defined.
Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[x] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[x] I updated the documentation where necessary.

Codecov Report

Merging #3669 into master will increase coverage by 0.09%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master    #3669      +/-   ##
==========================================
+ Coverage   74.49%   74.58%   +0.09%
==========================================
  Files         126      126
  Lines        5990     6004      +14
  Branches      390      393       +3
==========================================
+ Hits         4462     4478      +16
+ Misses       1528     1526       -2

Impacted Files
Coverage Δ

...ain/scala/whisk/core/invoker/InvokerReactive.scala
0% <0%> (ø)
:arrow_up:

...rc/main/scala/whisk/core/entity/ExecManifest.scala
96.62% <100%> (+0.52%)
:arrow_up:

.../scala/src/main/scala/whisk/core/entity/Size.scala
97.82% <100%> (+0.2%)
:arrow_up:

...scala/whisk/core/containerpool/ContainerPool.scala
85.88% <100%> (ø)
: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 ed71ee0...d78d599. Read the comment docs.

@tysonnorris I haven't had a chance to open PR against the downstream repos which will be affected (no stem cells by default).
Also, it appears the commit message possibly because of subsequent commits whose messages were amended to the message did not properly credit @Himavanth.


Use slim-sprig instead of mastermind-sprig

which has a ton of dependencies. The small sprig is completely sufficient for our needs and does not create ton of transitive dependencies to all metal-go consumers.

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

Comparison is base (d2ef8ac) 21.87% compared to head (941ea6e) 21.87%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #148   +/-   ##
=======================================
  Coverage   21.87%   21.87%
=======================================
  Files           1        1
  Lines          64       64
=======================================
  Hits           14       14
  Misses         44       44
  Partials        6        6

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


Pagination widget

Create proper pagination widget.
Needs to hide redundant pages for long lists.
Use it on the email audit page first: https://app.timeoff.management/audit/email/
Ideally it needs to be like here https://bootsnipp.com/snippets/featured?page=17
Or at least like on GitHubs commits page with "Older" and "Newer" buttons: https://github.com/timeoff-management/application/commits/master

For now implemented simple version where system shows only Prev, current and Next link in pagination widget. The idea: is there are too mane pages - customer needs to use filter to narrow down the result set.


Handle convertPatternInExpr.

This is a second attempt at #976 , but now with support for Expr, List, and Not in addition to Sel.
This is used for queries like the following:
SELECT * from foo where field in (select substring(?, 1, seq) from seq_1_to_19);
SELECT a, b from foo where foo.a in (select a from bar where bar.b = ?);
SELECT a, b from foo where foo.a in (?, ?);
SELECT a, b from foo where foo.a not in (?, ?);
SELECT a, b from foo where ? in (foo.a, foo.b);
The support is heavily based on that found in the fork found at:
https://github.com/xiazemin/sqlc.git
However it should be noted that this is not just a straight copy and
paste job, there are several pieces from that branch for features that
don't exist in the main sqlc repository, the sqlc repository has changed
a bit since the fork, and the fork version does not handle the latter
case at all.

@asterikx pinging you on this one given the conversation on the previous merge request.

Well, oops.  Please hold off on reviewing this, the code it generates won't compile, as noted in the pipeline checks.
I'll take a crack at resolving that sometime in the next week, I hope.

Alright, so a bug in the golang code generator has been fixed, I'm not sure how easy it would have been to trigger this previously, but it is far too easy to trigger it with this change set.
And after merging the code with master, a logical conflict (lack of support for DefaultSchema in the pre-merge code) has been fixed.
At this point I think this should be good to go.

@zelch This code is now out of date with main. Also, there are still no tests for PostgreSQL. Do you still have time to work on getting this across the line? If not, I'll close it out and work on IN support in a different PR.

I can definitely get it back up to date with main.
As far as Postgres tests, I'm afraid that I only implemented support for dolphin.  Adding support for the postgresql engine would definitely be good to do, but I'm not sure that I'm going to have time in the immediate future to tackle it.

Great, let's get it updated and then we can merge in support as-is.

Done, and it is passing all tests.


Icon generator outdated

[x] Too many touch icons are created (see Apple information)
[x] Meta tags are included twice in code
[x] On dev server, "android-chrome-192x192.png" file included but not existing

Idea to replace with https://github.com/haydenbleasel/favicons

Idea: Combination with builds for App Store deployment > create icons in build folder and use these during App / Play Store builds.

Replaced by own building routine


TypeScript module resolution

According to this https://github.com/Microsoft/TypeScript/issues/2568#issuecomment-308792266
looks like you need to change this entry in package.json from
"typings": "dist/index.d.ts" to "types": "dist/index.d.ts"
I try to reference redux-zero/svelte in ts module but it does not work.
I had to change import statement import { getActions } from 'redux-zero/dist/svelte' to make it work.

I'm experiencing the same issue, when trying to import Provider module from redux-zero/react.

I think you can do either import redux-zero/dist/react or change "typings": "dist/index.d.ts" to "types": "dist/index.d.ts" in package.json under node_modules/redux-zero.
second option only works until npm update in my testing.

Hi @Kiho
Thanks a lot to noticing this!
Do you want to take this bug?

Hi @matheusml, I will submit PR.

I tested more and found my second solution does not work, my setup for test was wrong.
So I have to use first solution for my self now. one thing I know is if I move up files in /svelte/svelte to  /svelte then works but I am not sure how I can make that at build time.
Thanks.

While you're fixing typings, the interface for at react/interfaces/Store.d.ts contains an unsubscribe field that looks like it became private in commit d7bce4d786c25a6b7264b835378f7ae8df8c4bc0. If I remove it (and shuffle the typings around as @Kiho points out) then my app compiles. I'm happy to make a separate issue and submit a PR for that.

@dnlsngr thanks for that!
Yes, please open a PR for that :100:

I'm getting
node_modules/redux-zero/react/index"' has no exported member 'Provider'.

The provider is not exported, only:

not

Hi @QuantumInformation
We're using it inside our examples folder, with the React counter example, and as you can see it's working just fine:

I'm not really sure what you're doing wrong here. Maybe rm -rf node_modules and  npm install again.

I'm using it with TypeScript

Hi @matheusml,
I made PR to fix svelte definition files but I did not touch react side because issues with interfaces.
I think, apply code below and deploy interfaces folder may work, but it might be better to move that under react. it should be OK to reference that in react from all other sub react components.
And don't have time to play with react this time.
  getConfig('./src/react/index.ts', 'react/index', {
    "dist/react": "react",
    "dist/interfaces": "interfaces",
    verbose: true
  }),

Just to make it clear.
It works just fine to use this with JavaScript:
import { connect, Connect, Provider } from 'redux-zero/react'

or this with TypeScript:
import * as ReactReduxZero from 'redux-zero/react'

But this, with TypeScript, is currently not working:
import { connect, Connect, Provider } from 'redux-zero/react'

I my knowledge, import * as ReactReduxZero from 'redux-zero/react' only works if there is no need to resolve types in down stream or
you may end up doing something like this const rzr: any = ReduxZeroReact
Btw, if you want to include same thing for react in my PR then I need to deploy interfaces folder to node_modules. please clarify.
I think all the complexity here came from tree structure of d.ts files which is not combined by typescript when build.

You're 100% right @Kiho
I just made a new PR that's solving this.


Overriding the default 'type' command and then calling the default 'type' command results in significantly slower execution time

VSCode Version: 1.27.1
OS Version: Windows 10 1809
Machine processor: AMD A8-4555M APU Quad core clocked at 1.6GHz
Graphics card: AMD Radeon HD 7600G

Does this issue occur when all extensions are disabled?: Yes (Aside from VSCodeVim - where the potential problem in the extensions API has been detected)
Steps to Reproduce:

Override the 'type' command with vscode.commands.registerCommand
Call the default 'type' command instead of the custom command
Note the difference in execution time in calling vscode.commands.executeCommand('type', ...)  when no custom type command has been registered, vs. calling vscode.commands.executeCommand('default: type', ...) (when a custom command has been registered/is overriding the default 'type' command). On my machine, the difference in execution time is consistently an order of magnitude (roughly 20ms vs 200ms) larger every time the executeCommand('default: type', ...) is called after overriding.

I have included some of my machine details here just-in-case - although I do doubt that they play any part in the issue here.
One of VSCode's most popular plugins, VSCodeVim/Vim, has an issue experienced by a fair share of the VSCodeVim community, as can be seen in an issue raised over a year ago in their repo -  VSCodeVim/Vim#2021. Typing in an editor window whilst this plugin is enabled results in an unbearably slow character render time, for a range of slower (and perhaps sometimes slighty-faster-than-slow) machines. During a screen-share a little while ago with @shawnaxsom, a contributor to the VSCodeVim community, we boiled the problem down to the 'type' command being overridden, and then having the default type command executed afterwards. For example, from my understanding of the VSCodeVim extension, the 'type' command is overridden like so:
vscode.commands.registerCommand('type', async ...
The default 'type' command is then called when needed, with code like this:
await vscode.commands.executeCommand('default:type', { text });
We measured the time taken for an ordinary (non-overridden) execution of the type command (which was roughly 20ms on my machine), vs. then calling 'default: type' command, which was always roughly 10x slower. Even though I am not familiar with the extensions API, this is puzzling, since these two calls should be doing exactly the same thing, yet calling executeCommand('default: type', ...) results in a much slower execution time of the default type command. I guess it has been an assumption that the source code in the VSCodeVim extension has been responsible for the severe typing slowness (or, it has only been occurring on slow machines, since it does not occur for everyone using the extension), but our screenshare led us to the conclusion that it appears to be this part of the extensions API which seems to be responsible. I imagine, also, that the much-slower execution time also occurs on faster machines, but it is simply not noticeable due to the fact that the faster processing/graphical power prevents the comparably slower call to the 'type' command being made visible rendering-wise. Even though it shouldn't matter, It is perhaps worth mentioning too, that even if the overridden (type) command is doing minimal work, as far as I know (I think we also tested this), the significant execution time difference still occurs.

I apologise profusely for letting this issue go dead by not responding a couple of months ago; I had a prolonged emergency situation and never got round to testing and reporting back on the effects of the provided minimal extension. I was reminded by the issue reference yesterday and have got round to trying it out.
Big surprise. The simple extension provided incurs very-almost the same performance penalty as VSCodeVim (with Vim and all other extensions disabled, of course). This came as a shock to me, because I did think that perhaps it was VSCodeVim after all. I have made extra sure that there is nothing else interfering. The basic 'hello world' predictably has no effect on typing, but simply adding the few lines of code to override the type command and execute the default type command within, has a very large effect on rendering/performance. As you say @alexandrudima, it is perhaps due to the frame being missed and the rendering occurring at the next frame.
I have not attempted to apply the diff to vscode for measuring typing (rendering) latency via going through the extension host; if this would be helpful, I could report back on this. Unremarkably, too, the measured extension host latency is around 2-3ms. Quite the shock indeed.. if there is anything I can do to assist and test, please do let me know.

Is there anything I can do to assist with this?

The number of thumbs up on this issue is deceptive. It's the second most highly upvoted issue for VSCodeVim: https://github.com/VSCodeVim/Vim/issues/2021

This particular issue is affecting many extensions. Those of us who like the excellent auto-completion on vscode and the powerful features of a modal editor like vim find this a deal breaker :(
Bumping this would be greatly appreciated!

In our latest Insiders Build, we have added a new experimental setting that would allow to execute the vim extension in a dedicated extension host process.
Configure the following in your settings.json and then reload window or restart:
"extensions.experimental.affinity": {
	"vscodevim.vim": 1
},

You can double check that vim is loaded in a separate process using F1 > Developer: Show Running Extensions:

I came to this comment by suggestion from the extension documentation and I don't understand anything... How can I configure vim with Jump?

@JuanQuiro Hi, Jump's author here, you can paste the following config into your VSCode settings.json:
{
  "extensions.experimental.affinity": {
    "wenfangdu.jump": 1
  }
}

@JuanQuiro Hi, Jump's author here, you can paste the following config into your VSCode settings.json:
{
  "extensions.experimental.affinity": {
    "wenfangdu.jump": 1
  }
}

In our latest Insiders Build, we have added a new experimental setting that would allow to execute the vim extension in a dedicated extension host process.

FWIW:

I tried this, for vscode-vim
It seemed worse — typing lots of characters quickly on opening VS Code caused some to end up in front of the cursor
Removing the setting from settings.json didn't seem to remove it — I was still seeing output in Output -> Window that vim was in a different process after running "Reload Window" (also after quitting and restarting VS Code)
I ended up wiping ~/Library/Application Support/Code, which then took a while to restore settings

Possibly I should have tried restarting the machine, if it was in a process outside VS Code?

So — I wouldn't recommend trying this unless you really need it.
If this is wrong, very happy to be corrected by someone knowledgeable about the code  — clearly one person having a bad experience shouldn't be weighed that much.


image upload plugin

Describe the changes you have made in this PR -
1> integrating image upload plugin in trumbowyg
2> using imgur api as a image host for upload requests
3>integrating resizimg plugin for resizable images
4>integrating jquery-resizable plugin as a dependency
Screenshots of the changes (If any) -

Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

Awesome! Do you think we can have support for multiple fonts?

Awesome! Do you think we can have support for multiple fonts?

Hii @satu0king  trumbowyg has a plugin for font family which support 13 different types of font family!
here is the link https://alex-d.github.io/Trumbowyg/demos/#plugins-fontfamily

Awesome! Do you think we can have support for multiple fonts?

Hii @satu0king trumbowyg has a plugin for font family which support 13 different types of font family!
here is the link https://alex-d.github.io/Trumbowyg/demos/#plugins-fontfamily
shall I proceed for the PR for this...

Sure go ahead


testClient in Deno cannot run normally unless add --no-check parameter

What version of Hono are you using?
3.11.12
What runtime/platform is your app running on?
deno
What steps can reproduce the bug?
import {Hono} from "hono";
import {test as it} from "node:test";
import {testClient} from "hono/testing";
// import {expect} from "chai";

it("hono testClinet", () => {
    it("should return the correct search result", async () => {
        let app = new Hono();
        app.get("/search", (c) => c.json({hello: "world"}));
        const res = await testClient(app)["search"].$get();
        // expect(await res.json()).equal({hello: "world"});
    });

});

❯ deno test test/hono_test.ts
Check file:///Users/chen/gemini-openai-proxy/test/hono_test.tso_test.ts
error: TS2571 [ERROR]: Object is of type 'unknown'.
        const res = await testClient(app)["search"].$get();
                          ~~~~~~~~~~~~~~~
    at file:///Users/chen/gemini-openai-proxy/test/hono_test.ts:10:27

❯ deno test --no-check  test/hono_test.ts
running 1 test from ./test/hono_test.ts
hono testClinet ... ok (0ms)

ok | 1 passed | 0 failed (3ms)

What is the expected behavior?
No need to add --no-check, the tests can run normally.
What do you see instead?
No response
Additional information
For those who encounter the same problem, you can now add the "--no-check" parameter to make the test run normally.
deno test --no-check

Hi.
If you write it as the code below, it will work.
it("should return the correct search result", async () => {
    let app = new Hono().get("/search", (c) => c.json({hello: "world"}));
    const res = await testClient(app)["search"].$get();
    // expect(await res.json()).equal({hello: "world"});
});

This is not a bug! You should write the code as mentioned above.
const app = new Hono().get('/search', (c) => c.json({ hello: 'world' }))

Closing.

It's pretty weird to mocking up all the endpoints manually rather than using existing ones, what's the point of testing then?


Notifications Page is lack luster

Is your feature request related to a problem? Please describe.
The notifications Webpage is completely lack lustered with no functioning of buttons and lack of better user experience on the frontend side. The page is not visually appealing.
Describe the solution you'd like
To make the webpage user friendly and appealing.
Providing some popups.....Showing each of the notifications received by the user in card or box like format on the webpage, whenever the user login . As to provide easy accessibility to the notifications without the inconvenience of finding the notifications on their mails each time.
And also as unread notifications are building up on the user's profile, will provide a dot or something like that on the tab....As of what we get on slack or WhatsApp when some notifications of ours are left to be read. And as soon as we read the messages that dot or no. disappears.
Additional context

Are you working on this? (Yes/No)
Yes

Hey @gr455 @tachyons @vedant-jain03 @Prerna-0202 can you provide some suggestions on what is been required to be done on this page. Since I know this is in the project list of gsoc2022 too, so I needed some feedback on what you all expect the content to be on this page .
I have mentioned some suggestions on my issue above.
I don't know how I'll do this, but will definitely make the page better😂.
Thank You

Hey @bhutani2002, Thanks for raising an issue but this is  duplicate of #2321


copy command

This PR adds a new copy command to scan for *.gir files and copy them to a new directory. We want to use this to copy the newest GIR files found on the developer machines to this repository.
To copy all the latest GIR files from your machine into this repository just run yarn copy:girs .
Changes

Moved XML parsing to DependencyManager to be able to compare the library versions of the found dependencies
Allow glob patterns for GIR directories to search in
Allow glob patterns for GIR ignore list
New copy command
General clean-up like removing unused code
Split module loading and parsing to omitted the parsing for the list and copy commands
Logger output improved and more used
Compare GIR library versions and use the latest one
Copied the GIR files of my machine into this repository
Bump version 4.0.0-beta.3
Published ts-for-gir v4.0.0-beta.3 of this PR with the next tag
Published all generated types of this PR with the next tag
Added a helper shell script to find all Fedora packages which contains at least one *.gir file

@ewlsh Should be finished now, feel free to also update the GIR files from you machine 👍

@ewlsh ping

Positive feedback for the packages published of this PR on https://github.com/gjsify/gnome-shell/issues/39 👍

@ewlsh That would be great, as I don't have much time at the moment, then this could already be merged and I will do that later


Fix the Method of Plotting the Best Fit Line

🥇 Generic Pull Request 🥇
Elizabeth Consulting International Inc
Purpose & Objective

[ ] This PR satisfies the PR checklist.

Demo of the new line of best fit:

If you look below, you can see the actual mean of the data. The line of best fit is no longer hardcoded with the actual mean of the data as the y-intercept.


[New Port Request] Served

Library name: Served
Library description: Served is a C++ library for building high performance RESTful web servers. Served builds upon Boost.ASIO to provide a simple API for developers to create HTTP services in C++.
Source repository URL: https://github.com/meltwater/served
Anything else that is useful to know when adding (such as optional features the library may have that should be included):
Requires boost.asio and Ragel(already ported to vcpkg) is optional. I have already compiled it on Windows with cmake and Visual Studio 2019, however you do need to specify NOGDI for the preprocessor due to a identically named macro (its called ERROR).

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.


Dapr has incorrect component configurations when network flag is specified on init

Expected Behavior

dapr quickstarts work as expected
Actual Behavior

Dapr has incorrect component configurations when network flag is specified on init
It has configurations either as
localhost:6739 (all versions prior to 1.0.0-rc2) or dapr_redis:6739 (proposed fix for #418 issue after 1.0.0-rc2).
When --network argument is specified on init, no ports are exposed https://github.com/dapr/cli/blob/v0.8.0/pkg/standalone/standalone.go#L215
Since no ports are exposed, dapr sidecar for dapr applications cannot connect to the right containers be it redis, zipkin or placement.
This is a scenario where a custom network is specified, no ports are exposed locally.
Without custom docker network specified:
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS                              NAMES
a93725b076f8        daprio/dapr         "./placement"            42 minutes ago      Up 42 minutes             <IP_ADDRESS>:50005->50005/tcp           dapr_placement
96dbb8b93f5e        openzipkin/zipkin   "start-zipkin"           42 minutes ago      Up 42 minutes (healthy)   9410/tcp, <IP_ADDRESS>:9411->9411/tcp   dapr_zipkin
e3a40ccbd225        redis               "docker-entrypoint.s…"   42 minutes ago      Up 42 minutes             <IP_ADDRESS>:6379->6379/tcp             dapr_redis

Note: <IP_ADDRESS>:50005->50005/tcp  for placement and similar ones for others.
With docker network:
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS               NAMES
592dcf2bc8dd        daprio/dapr         "./placement"            21 seconds ago      Up 20 seconds                                 dapr_placement_mynet
305274bd5a5e        redis               "docker-entrypoint.s…"   32 seconds ago      Up 31 seconds             6379/tcp            dapr_redis_mynet
0682ffd22c12        openzipkin/zipkin   "start-zipkin"           32 seconds ago      Up 31 seconds (healthy)   9410-9411/tcp       dapr_zipkin_mynet

Note: no port forwarding.
Steps to Reproduce the Problem

create a custom docker network
run dapr init --network mynet
check the configuration files.
This issue does not affect dev-containers since the app itself is running inside a container in the same docker network and DNS resolution is provided by docker in that scenario.
https://github.com/microsoft/vscode-dev-containers/blob/master/containers/dapr-dotnetcore-3.1/.devcontainer/docker-compose.yml

Release Note

RELEASE NOTE:

Is the --network mynet option used when daprd sidecar is intended to run inside the network mynet?

Is the --network mynet option intended for the case that daprd sidecar runs inside the network mynet?

@yaron2  is the network option only intended for the scenario that @tcnghia mentioned?

@mukundansundar Regardless of the answer to https://github.com/dapr/cli/issues/545#issuecomment-742108165, I think you are correct that we will need to also update components/configurations to refer to dapr_zipkin_mynet, dapr_placement_mynet, etc.

@tcnghia even if the components/configurations refer to the right hosts, still it will not work on an app outside of the same dockerNetwork ... Unless we know if an when to port forward and what name to use for the hosts (localhost if port forward is enabled), container network alias if not.
I think we might need a flag that enables port forward even if a docker network is specified.
If we go with that option, should it port forward to a random port or the same ports as it does now? Or should it be a user configured parameter for each container?

I took a look at this with Mukundan. I think this issue should be de-prioritized for the following reasons:

We are not sure if port forwarding is the right thing to do. When a user inits dapr withing a docker network, it might be intentional about not having the ports exposed. On top of that, the components configuration would work either within the network or outside, the same config cannot work for both (localhost vs dapr_redis DNS resolution, for example).
We don't have a user's scenario being blocked by this.

@mukundansundar and I agreed to move this outside v1.
I would also go further and recommend this to be a P2 until there are users blocked by this or we envision a real world scenario where this issue becomes a must.

I took a look at this with Mukundan. I think this issue should be de-prioritized for the following reasons:

We are not sure if port forwarding is the right thing to do. When a user inits dapr withing a docker network, it might be intentional about not having the ports exposed. On top of that, the components configuration would work either within the network or outside, the same config cannot work for both (localhost vs dapr_redis DNS resolution, for example).
We don't have a user's scenario being blocked by this.

@mukundansundar and I agreed to move this outside v1.
I would also go further and recommend this to be a P2 until there are users blocked by this or we envision a real world scenario where this issue becomes a must.


filters fails to install using setuptools

When trying to install filters using setuptools, the following error raises:
> python setup.py install
Searching for filters
Reading https://pypi.python.org/simple/filters/
Downloading https://pypi.python.org/packages/5d/53/f864ccaa1206a833f710e6110c4f5e8e29c9050fd3f48a00533e39017953/filters-1.1.7.tar.gz#md5=6159bc598ec6b0579a0d52a1ae7eaaaf
Best match: filters 1.1.7
Processing filters-1.1.7.tar.gz
Writing /var/folders/3j/vxqr19lj17q456l889dysjm00000gn/T/easy_install-mXxSVz/filters-1.1.7/setup.cfg
Running filters-1.1.7/setup.py -q bdist_egg --dist-dir /var/folders/3j/vxqr19lj17q456l889dysjm00000gn/T/easy_install-mXxSVz/filters-1.1.7/egg-dist-tmp-OKCA_f
error: Setup script exited with error: can't copy 'LICENSE': doesn't exist or not a regular file

setup.py contained an unnecessary reference to LICENSE, and MANIFEST.in was missing.
I committed a potential fix for this issue, but needs more testing.  So far the only way I can reproduce this issue is if filters is downloaded from PyPI; I haven't figured out how to reproduce from a local archive yet.

Hey Pedro!  v1.3.0 was just released, and it potentially contains a fix for this issue.  When you have a chance, could you verify if this issue is still reproducible?