gen grpcServer happen invalid type

this is my build
func WireApp() *conf.GrpcServer {
	wire.Build(
		wire.Struct(new(conf.GrpcServer), "*"),
		conf.NewGrpc,
		conf.ZapProvider,
		conf.GormProvider,
		service.ProviderSet,
	)
	return &conf.GrpcServer{}
}

this is NewGrpc
func NewGrpc(logger *zap.Logger) *grpc.Server {
	svc := grpc.NewServer()

	loadMiddleware(logger, svc)

	return svc
}

gen grpcServer happen invalid type， why?
func WireApp() *conf.GrpcServer {
	logger := conf.NewZapConfig()
	invalid type := conf.NewGrpc(logger)
	grpcServer := &conf.GrpcServer{
		Grpc: invalid type,
	}
	return grpcServer
}

error info
wire: 20:10: expected ';', found 'type' (and 3 more errors)
wire: grpc-layout/cmd: generate failed
wire: grpc-layout/cmd: wrote D:\program\3-项目\1-基础架构\2-go架构\2-grpc架构\cmd\wire_gen.go
wire: at least one generate failure

i find problem ，because my path has chinese charater

the problem is fix , i don't know why，i refresh  the wire import in go mod，then it's work ，it's very weird


Mass. Question, 4 - Legalize Marijuana : Clicking on See Full results takes the user to the incorrec

View your issue at Applause Testing Services - https://my.applause.com/u/a#!&view=issues&subview=issues&productId=15105&bugId=2316633
---- ACTION DETAILS ----
Action Performed:

Open URL:http://elections.dev.passenger.bostonglobe.com
Navigate to map in Elections 2016
Navigate to Mass. Question, 4 - Legalize Marijuana  and click on See full results and observe

Expected Result:
Clicking on See full results takes the user to the correct page.
Actual Result:
See full results takes the user to the incorrect page.
(The actual page is quickly skipped)
Additional Info:
null
Error Code/Message:
---- ENVIRONMENT ----
Antivirus:Kaspersky,Language:English ,Operating System:Windows,Web Browser:Firefox,Desktop Accessories:Microphone,Desktop Accessories:Speakers,Desktop Accessories:Headset,Operating System Version:10
---- UTEST PROPERTIES ----
uTest Bug Id: 2316633
Title: Mass. Question, 4 - Legalize Marijuana : Clicking on See Full results takes the user to the incorrec
Status: Pending Rejection
Type: Functional
Frequency: Every Time
Severity: High
Product: Elections (dev)
Test Cycle: Boston Globe Elections Exploratory Cycle
---- UTEST Attachment ----
Bug2316633_Recording #251.mp4 : https://utest-dl.s3.amazonaws.com/9716/15105/120249/null/bugAttachment/Bug2316633_Recording %23251.mp4?AWSAccessKeyId=AKIAJVVOIXUIFRTEEEKQ&Expires=1793825514&Signature=wCvVqVOQEgAs%2FxsVFgzav0QDugU%3D

another hitting the paywall wooo


Python 3

Hey I am a big fan of this library, does someone know if there is going to be a release for python 3 at some point?

You can use it with Python 3, you have to make few modifications to few files. I am looking at only BBG data download and for that you need to put braces around print statements in v3api.py. Also change "basestring" to "str".

I am also interested in this working for Python 3.x can we make a plan going forwards to get this working?
For Python 3.5 you also need to change iteritems to items.

I adapted the code to python 3.4 an works pretty well for Historical data.

how were you able to get BLPAPI to work with Python 3.5?

@dpsugasa Is the code on your GH working for 3.6? did you issue a PR?

No the code on my GH is the same as the original. I modified the files on
my PC only. I only use the library for BBG access and those files are easy
to change; just follow the recommendations in the "issues". From memory you
only need to update the files in the bbg folder. Most of the changes are
just adding parentheses to print function. One or two
items/iteritems changes also.
Let me know if I can help any further.
On Fri, May 19, 2017 at 12:10 AM zglin<EMAIL_ADDRESS>wrote:

@dpsugasa https://github.com/dpsugasa Is the code on your GH working
for 3.6? did you issue a PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bpsmith/tia/issues/11#issuecomment-302565744, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZekSOLIJogy8l0JaU0ai8LMBpMXzZYmks5r7M_dgaJpZM4JjFzb
.

@dpsugasa how did you install the blpapi on python 3.6? I spoke with the help desk and they only have a experimental release for 3.5, nothing yet for 3.6.  Any help would be appreciated

the blpapi works on 3.6. If the bloomberg installer won't let you install
because you have 3.6, I would downgrade to 3.5, install the api, and then
re-upgrade to 3.6. bloomberg isn't particularly helpful with their api in
my opinion.
On Mon, May 29, 2017 at 3:11 PM STguerin<EMAIL_ADDRESS>wrote:

@dpsugasa https://github.com/dpsugasa how did you install the blpapi on
python 3.6? I spoke with the help desk and they only have a experimental
release for 3.5, nothing yet for 3.6. Any help would be appreciated
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bpsmith/tia/issues/11#issuecomment-304670129, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZekSDFTGVpMrdI1qcxP0KMP3l1qw4xwks5r-tIHgaJpZM4JjFzb
.

I am working with Python 3.6. After modifications as "put braces around print statements",  "basestring" to "str" and " iteritems to items", I still get this error "'dict' object has no attribute 'iteritems'".  It shows error in this line "433                        overrides=','.join(['%s=%s' % (k, v) for k, v in self.overrides.items()]))". Any idea?

Make sure you have changed all the files in the BBG portion of the module;
there are 3 or 4 files if my memory serves correctly. My repo has all the
changes if you need to compare.
On Mon, Jul 24, 2017 at 8:13 PM, wangjuestam<EMAIL_ADDRESS>wrote:

I am working with Python 3.6. After modifications as "put braces around
print statements", "basestring" to "str" and " iteritems to items", I still
get this error "'dict' object has no attribute 'iteritems'". It shows error
in this line "433 overrides=','.join(['%s=%s' % (k, v) for k, v in
self.overrides.items()]))". Any idea?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bpsmith/tia/issues/11#issuecomment-317525561, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZekSGzBIBDUrryZlYbWKim3-OO4Sm_rks5sROzvgaJpZM4JjFzb
.

Thanks! I am able to run tia on python version 3 now.

excellent!
On Tue, Jul 25, 2017 at 3:29 PM wangjuestam<EMAIL_ADDRESS>wrote:

Thanks! I am able to run tia on python version 3 now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bpsmith/tia/issues/11#issuecomment-317755824, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZekSIcbZPJYHvFRp0lx_qYdS2z_pH-_ks5sRfvWgaJpZM4JjFzb
.

I've updated the whole project with 2to3 to be Python 3 compliant. It is NOT Python 2 compliant, however.
Python 3 compatible repo:
https://github.com/PaulMest/tia/
Install with
$ pip install git+git://github.com/PaulMest/tia.git@066549f834791b024c1d8eb595e0d18fa1e3c1c5#egg=tia

or
$ pip install git+https://github.com/PaulMest/tia.git@066549f834791b024c1d8eb595e0d18fa1e3c1c5#egg=tia

or put one of these into your requirements.txt file
# Using git/SSH
git+git://github.com/PaulMest/tia.git@066549f834791b024c1d8eb595e0d18fa1e3c1c5#egg=tia

# Using https
git+https://github.com/PaulMest/tia.git@066549f834791b024c1d8eb595e0d18fa1e3c1c5#egg=tia

hi I am still struggling with tia installation. running on python 3.6.10 I fixed all the print and basestring issues but get this error - any idea whats going on? is it to do with the 3.6.10 version?
Traceback (most recent call last):
File "", line 58, in
File "", line 48, in BDP
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 94, in getitem
return self.get_attributes(flds, **self.overrides)
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 90, in get_attributes
frame = self.mgr.get_attributes(self.sids, flds, **overrides)
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 148, in get_attributes
return self.terminal.get_reference_data(sids, flds, **overrides).as_frame()
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 745, in get_reference_data
return self.execute(req)
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 711, in execute
self.logger.info('executing request: %s' % repr(request))
File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 433, in repr
overrides=','.join(['%s=%s' % (k, v) for k, v in self.overrides.iteritems()]))
AttributeError: 'dict' object has no attribute 'iteritems'

hi I am still struggling with tia installation. running on python 3.6.10 I fixed all the print and basestring issues but get this error - any idea whats going on? is it to do with the 3.6.10 version?
Traceback (most recent call last): File "", line 58, in File "", line 48, in BDP File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 94, in getitem return self.get_attributes(flds, **self.overrides) File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 90, in get_attributes frame = self.mgr.get_attributes(self.sids, flds, **overrides) File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\datamgr.py", line 148, in get_attributes return self.terminal.get_reference_data(sids, flds, **overrides).as_frame() File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 745, in get_reference_data return self.execute(req) File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 711, in execute self.logger.info('executing request: %s' % repr(request)) File "C:\Users\kamathp\Anaconda3\envs\PA36\lib\site-packages\tia\bbg\v3api.py", line 433, in repr overrides=','.join(['%s=%s' % (k, v) for k, v in self.overrides.iteritems()])) AttributeError: 'dict' object has no attribute 'iteritems'

@pksw2016 not sure if this is still relevant to you, but .iteritems() was replaced with .items() so you can just write:
overrides=','.join(['%s=%s' % (k, v) for k, v in self.overrides.items()]))


Download Fort image (.jpg)

Short Description

At every Fort spin, the phone client request the Fort image is downloaded and displayed at the phone. I couldn't find any download request at the Bot code.
If I were working at Niantic, I would find all the Bot users, using this.
Possible solution

Add the Image download at the Fort Spin.
How it would help others

It would mimic the Official App much better.

Well the server still sends the image. We just don't do anything with it.

Ok! Thank you!


Changing namespaces breaks System.Type serialization

Overview
System.Type cannot be serialized on its own, this is usually done by serializing the AssemblyQualifiedName. This is based on the namespace a type is in. Every time the namespace changes, serializations break. This happens for using ASMDEFs at all as well.
There should be a mechanism that somehow reserializes those in case of such changes or make the type namespace independent.
I found by running the InteractionsGallery scene and in particular InteractableReceiverList with its List Events is affected, but I'm pretty sure this is not the only place this will happen.
Expected Behavior
serialized types do not break
Actual Behavior
they break
Steps to reproduce
run InteractionsGallery on UWP with XR, attach a debugger prior to starting if you will. The scene will throw two NullReferences.

Unity Editor Version
2018.3.9f1
Mixed Reality Toolkit Release Version
mrtk_development

Related to #3672

See response to https://github.com/Microsoft/MixedRealityToolkit-Unity/issues/3672
I'll take a peek at this this week.

@Alexees do you think that Lars's pull request https://github.com/Microsoft/MixedRealityToolkit-Unity/pull/3750 would mitigate some of the pain you've been experiencing?

@chrisfromwork I guess so. But from the looks of it, you still need to fail to know what needs fixing, right?

Closing as #3750 will mitigate this


Response for preflight has invalid HTTP status code 401

Im not sure I understand why this is failing.
Here's the error I receive when attempting to make a request against a protected part of my API:
OPTIONS http://xx.xx.xx.xx:5000/it/comments/save 401 (Unauthorized)
Failed to load http://xx.xx.xx.xx:5000/it/comments/save: Response for preflight has invalid HTTP status code 401.

My Ajax request:
$.ajax({
    url: 'http://xx.xx.xx.xx:5000/it/comments/save',
    crossDomain: true,
    headers: { 'Authorization': 'Bearer ' + jwtToken },
    method: 'POST',
    dataType: 'json',
    data: payload,
    success: function(response) {
        console.log(response)
    },
    error: function (XMLHttpRequest) {
        console.log(XMLHttpRequest.responseText)
    }
});

I should note that if I use Postman to make a request against a protected part of my API, and providing a valid JWT Token, then everything works great.
This leads me to believe this is related to some CORS issue. Although I feel like I've configured everything correctly. I have tried many different apache configurations and ajax request methods (ie.:)
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open("POST", "http://xx.xx.xx.xx:5000/it/comments/save");
xhr.setRequestHeader("Authorization", "Bearer " + jwtToken);
xhr.setRequestHeader("Cache-Control", "no-cache");
xhr.send(payload);

I've also tried setting the headers before the request, (ie:)
$.ajax({
    url: 'http://xx.xx.xx.xx:5000/it/comments/save',
    ...
    beforeSend: function(xhr) {
        xhr.setRequestHeader('Authorization', 'Bearer ' + jwtToken);
    }
    ...
});

This is my Apache configuration -- note im using a bit of trickery to limit the allowed origins as opposed to simply using Header set Access-Control-Allow-Origin "*" -- which I will note that I also tried.
<VirtualHost *:5000>

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/api/public

        <IfModule mod_headers.c>
                SetEnvIfNoCase Origin "http?://(www\.)?(xx.xx.xx.xx|xx.xx.xx.xx|xx.xx.xx.xx)(:\d+)?$" AccessControlAllowOrigin=$0
                Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
                Header set Access-Control-Allow-Methods "POST, GET, DELETE, OPTIONS"
                Header set Access-Control-Max-Age "7200"
                Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
                Header set Access-Control-Allow-Credentials "true"
        </IfModule>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        <IfModule mod_dir.c>
            DirectoryIndex index.php index.pl index.cgi index.html index.xhtml index.htm
        </IfModule>

</VirtualHost>

This is my middleware setup -- i should note I am operating over http:// not https:// (for dev) hense the secure = false.
$app->add(new \Slim\Middleware\JwtAuthentication([
    "secret" => SECRET,
    "secure" => false,
    "rules" => [
        new \Slim\Middleware\JwtAuthentication\RequestPathRule([
        // degenerate access to URI's
        "path" => [
            "/test"
        ],
        // allow access to specific URI's without a token
        "passthrough" => [
            "/test/hello"
        ]
        ])
    ],
    "error" => function ($request, $response, $arguments) {
        $data["status"] = "error";
        $data["message"] = $arguments["message"];
        return $response->withStatus(401)
            ->withHeader("Content-Type", "application/json")
            ->write(json_encode($data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT));
    }
]));

As a broad overview, when a user signs into my system, I generate a JWT token and store it in their session. I dont know if its relevant, but the server that generates the JWT token is a different server then where my API lives. I have made sure to use the same secret key on both servers. Then, when a user performs an action where an ajax request to the API is required, I pull that JWT token from the session and pass it in the Authorization header in the form of Bearer <token>. This is when I receive the errors above.
Is anyone able to shed some light on what I'm doing wrong here?

I have found the answer. I needed to add a new request method rule for all OPTIONS requests as such:
$app->add(new \Slim\Middleware\JwtAuthentication([
    "secret" => SECRET, # the secret key
    "secure" => false, # true to enable HTTPS only
    "rules" => [
        new \Slim\Middleware\JwtAuthentication\RequestPathRule([
            // degenerate access to URI's
            "path" => [
                "/test"
            ],
            // allow access to specific URI's without a token
            "passthrough" => [
                "/test/hello"
            ]
        ]),
        new \Slim\Middleware\JwtAuthentication\RequestMethodRule([
            "passthrough" => ["OPTIONS"]
        ])
    ],
    "error" => function ($request, $response, $arguments) {
        $data["status"] = "error";
        $data["message"] = $arguments["message"];
        return $response->withStatus(401)
            ->withHeader("Content-Type", "application/json")
            ->write(json_encode($data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT));
    }
]));


Implementing a reconnection logic after MemcacheUnexpectedCloseError

In the occasion of a memcached server restart, on the first access attempt after server restarted, we get "MemcacheUnexpectedCloseError" and the request fails, then the next following access (a totally different request) goes through properly.
What am I missing here? Do I need to implement some reconnection logic on failure? Any hints on doing so if that's the case?

Well, after a connection breaks, contrary to what you stated, it doesn't attempt to reconnect on its own, and that's my main issue.

In the occasion of a memcached server restart, on the first access attempt after server restarted, we get "MemcacheUnexpectedCloseError" and the request fails, then the next following access (a totally different request) goes through properly.

As you noted, "the next following access [..] goes through properly". That is pymemcache re-establishing the connection automatically for you.

I'll try to clarify a bit more.

Operation is normal.
Memcached server restarts.
First operation after restart fails with "MemcacheUnexpectedCloseError". It fails.
Second operation goes fine.

My expectation is on step 3 it reconnects and let the operation go through taking into consideration the overhead of the reconnection.

I will also try to clarify more.
There are many ways to use memcached, and there is no one-size-fits-all error handling solution that will work for everyone. Because of that, pymemcache reports errors to users, and expects users to handle those errors appropriately for their use case. As a convenience, if you continue to make requests through the pymemcache Client, it will attempt to reconnect a closed socket for you. That just saves you the trouble of needing to create a new Client instance, or call an explicit "reconnect" API. The automatic retries are not designed to paper over issues connecting to memcached. I believe that explicit errors are the best way for this API to communicate with its users when an issue occurs.
In my opinion, it would be a bad idea for pymemcache to add automatic retries into the core Client library. I strongly prefer that users of the library see exceptions rather than high latency (as would happen with a retry/backoff loop). I tried to outline some of the possible ways that errors can be handled in my long post above. The error case you mentioned is a good candidate for automatic retries, but it is not the only kind of error experienced by memcached users (and it is very unlikely to be the only kind of error you experience, particularly if your request rate increases over time).
If you want automatic retries then it would be relatively easy to add a configurable Client wrapper that automatically retried requests. We would be happy to review that as a submission if you are so inclined.

Hello,
We face similar issue in Openstack.
We think that retry mechanisms on the pymemcache can help to solve this kind of problem.
Indeed on Openstack we recently introduced a cache backend [1] based pymemcache through the dogpile.cache lib [2].
Sometime servers need to be restarted (maintenance, network issues, etc...) and that lead us to similar scenario.
As we are few customers facing the same issue, maybe the solution could be to implement a centralized scenario, based on  optional retry conveniences on the lib side. Without modifying the default behaviour we could pass an option to indicate that we want retry when MemcacheUnexpectedCloseError are thrown. That would provide to the community of pymemcache a standardized way to handle such errors.
What if the wrapper is internal to pymemcache?
What if the errors management is standardized and uniformed?
What if pymemcache users design their failing strategy by passing option?
If we standardize and design retry strategies that cover of 20% of the possible server problems and who lead to 80% of the issues faced by users, then, it will only remaining the exotic use cases. As you said these exotic cases could remains under the responsibility of the users. I guess that the major part of users will be happy with the 20% of proposed strategies.
Thoughts?
[1] https://opendev.org/openstack/oslo.cache/commit/b00b3b23b42652dc7e9af8ec54a7f117b6999895
[2] https://github.com/sqlalchemy/dogpile.cache/commit/a2e25bc743a48d91705d944e52aa667ebff10943

Interesting, I honestly gave up after reading the last clearly-rejecting and pushy reply without even understanding the issue.
Disappointedly, I guess I have to join the Openstack team to be able to report an issue and get traction.
@4383 thanks in due.

@4383
I don't want the core Client library to be opinionated about how errors are handled, and I've tried to explain why in my previous comments in this issue. That means I generally want users to build their own error handling strategies. The "right way" to make your own error handling strategy is by writing a small wrapper class that has the same API as the Client class. For example, you could write a RetryingClient class that delegates calls to an underlying Client and does retries when it sees MemcacheUnexpectedClose. If you have it take a client object as an argument you could even do cool things like rc = RetryingClient(Client(...), ...), or rc = HashClient(Client(...), ...), so users of either Client or HashClient could use your wrapper.
If you build such a wrapper and test it, I would love to include it in pymemcache along side the PooledClient and HashClient libraries that were contributed by other users. Take a look at those two classes for examples of how to build a wrapper, and please send a PR if you end up taking this approach.
Having said that, I would like to have one more try at convincing you that a simple retry strategy may not be what you want. If a memcached server goes down for a while (say, five minutes), then a retry strategy is going to cause all of your requests to be hung waiting for that server for potentially a long time (depending on your retry policy, the connect_timeout and TCP's retry configuration). Since you are likely using memcached to reduce the latency of your requests and increase your availability, that failure scenario is sub-optimal. You generally don't want a memcached outage to cause a site outage. When possible, I would advocate ignoring memcache exceptions and using a low value for connect_timeout and timeout. That will increase the load to whatever datastore is behind your memcached instance (when there is an outage), so you also have to watch out for that. The other way a memcached outage causes a bigger outage is by causing too much load to be sent to a backend datastore, so you may also need a way to throttle requests going to your data store. You need that anyway, most of the time, so it shouldn't require any unnecessary work.
Separately, if you're planning to use memcache in a larger deployment, you may want to consider HashClient, which will allow you to distribute your data across more servers, both increasing availability and decreasing the load on the individual memcached servers.

@cayolblake
I invested a lot of time trying to explain how pymemcache handles errors (and why it does it that way) and I resent being called "pushy" as a result of that effort. I recognize that tone doesn't come across very well on the internet, but I was in no way attempting to reject your issue. I wrote you long comments in an earnest attempt at substantive conversation.

@cgordon thank you for your time and thank you for your fully detailed and useful comments.
I'll spend time on your different propositions, and I'll try to back with more updates from our side ASAP.


(2) [ID Tool] Add, remove, and reorder grants table columns

We recently got a walkthrough from Pari, a former state budget officer, of what she looks for when she's looking at grants. She gave us some new information about which data are most important and which aren't.
On both the My Grants and the All Grants view, let's make some changes to the table columns:

Here are the changes, and why:

Remove the Grant ID column. We don't need both Grant ID and Grant Number — both are unique identifiers, but grants.gov uses the Grant Number more (although they call it the "Opportunity Number").
Rename Grant Number to Opportunity Number. This matches what's on grants.gov and is more consistent for the user. Although I didn't wireframe it, this column can also be dark, just like Grant ID is now.
Keep Title, Viewed By, and Interested Agencies the same.
Remove the Agency Code column. We don't think it's important enough to show in this table. They can click through if they need to.
Move Status to the right of Interested Agencies.
Move Opportunity Category to the right of Status.
Add Award Floor and Award Ceiling to the right of Cost Sharing. We don't currently have these columns, but they are important to budget officers — they tell them how much they could expect to get if the grant is awarded! These columns should also be sortable.
Remove Created At and Updated At. These are debug columns that reflect the state of the database row, not the state of the grant — it's for developers, not the end user.

Pari actually says to get rid of the Posted Date column, too.

This applies to both the "My Grants" and "Grants / Browse Grants" tabs.

Current state:

Desired state:

cavukovic is taking this on (waiting to add him to the repo before we can officially assign him to the bug)


Common description

Some of the descriptions

Excalidraw is a virtual collaborative whiteboard tool that lets you easily sketch diagrams that have a hand-drawn feel to them.
Excalidraw is a whiteboard tool that lets you easily sketch diagrams with a hand-drawn feel.
Virtual whiteboard for sketching hand-drawn like diagrams.
Excalidraw is a virtual collaborative whiteboard tool to sketch diagrams with hand-drawn look & feel.

Should be used on

[x] Twitter
[ ] Blog
[ ] How to
[x] GitHub
[ ] OpenCollective
[ ] README.md
[ ] index.html

Lets pick one and use it everywhere

On OpenCollective as well.

Is this still actionable @Fausto95 @lipis or do we close this?

Just created some PR, I'll close this when they get merged

I recall we discussed about the description in the index.html(about being too long or something like that), so I will leave it as is.
I don't have an Open Collective account, so I can't change the description there.
I think this issue is fixed now.

Perfect! Thanks.


Folding / unfolding is not being read out by screen reader

VS Code Version: 1.6.1
OS Version:1607
NVDA version:-2016.2.1
Steps to Reproduce:
1.Open VS code editor.
2.Navigate to one of the editor.
3. Navigate to a Bracket present in the file and see the matched bracket highlighted and observe NVDA announcement.
4. Navigate to the Name which you want to change and Press Options button or Right Click and select Change all Occurrences and Hit Enter and change the Name to Desired Name and observe NVDA announcement.
(Note- Options key is available only in Personal Computer and Not on Laptops)
5. Press f1 and type "Fold" or "Unfold "command in command pallet and Hit Enter and observe NVDA announcement.
Expected result:
NVDA should provide information when two brackets are matched or after changing multiple occurrence or after folding/unfolding
Actual Result:
NVDA is not reciting any information when two brackets are matched or after changing multiple occurrence or after folding/unfolding.
Observation: NVDA announces the command written ">fold" in command pallet when Keyboard focus goes to the options Displayed by Command Pallet
User Impact:
Screen Reader user doesn't get to know when two brackets are matched or after changing multiple occurrence or after folding/unfolding.
Attachments:

Reading every time a bracket gets matched can be too noisy.
However reading something when we fold / unfold I think makes perfect sense
@aeschli could we do some annoucment when a region folds / unfolds, like the start and end of a region?
Assigning to july, and also to myself (in case you do not have time could you provide some code pointers)

When detecting a screen reader, we enter 'accessibility mode' and turn folding off.
Maybe we also need to disable the commands in the command menu?

@aeschli oh yeah I forgot about that.
Yeah just disable the commands in the command palette via context key.


SVG data in CSS?

If there is more than 1 webpage using the same social icons, I think SVG would be better in the CSS?

for responsive site, do the icons ever need to be resized, or do the colours ever need changing etc?
I prefer svg's inline (in the html) so they classes and css can change them like normal DOM.

I kinda like the SVG-in-CSS approach because it'll also work much better for emails I think? I'd appreciate a PR implementing a first idea!

the only downside with the base64 approach is if the same icon is need twice, but with a slight styling tweak (e.g. smaller for mobile), you then have 2 sets of base64 icons in the css.  Which is why inline is better.
I think the base64 to treats its as svg, so a background image no better than inline for emails (i would expect!)
but like i say, if you're not changing the icons, ever, then it's not a problem.

@tomByrer the big reason to use inlined svgs here is it means we can style them with css. As @peter-mouland says, this it lets you change colors, sizes, etc. In the case of sharingicons.io, using inlined css is how it supports the four styles set in the "icon" section of the UI (outline, outline in circle, solid, solid in circle via the the stroke and fill values). Sure there are other ways around it (sites have been using similar design elements since well before svg was widely supported) but this is both the most compact and the most flexible.

Oh missed the email aspect of this question. I haven't tested this. As of December, svg support in email was spotty. This is something to look into. Do we have anyone here who's paying for Litmus or Email On Acid?

Styling via CSS is a solid point.
Sorry, not email testing here, aside from manual.

Closing this and moving the email question over to #61


Upgrade to ubuntu 24.04 and python 3.13

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

Project coverage is 95.07%. Comparing base (4c34c44) to head (81c9154).
Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #155   +/-   ##
=======================================
  Coverage   95.07%   95.07%
=======================================
  Files         369      369
  Lines       12391    12391
  Branches     1296     1296
=======================================
  Hits        11781    11781
  Misses        481      481
  Partials      129      129

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


Update anatomy-of-an-item.md

Deploy preview for angry-elion-ffa09b ready!
Built with commit e429158151d9cfb3a86f823d66198490186c1ffb
https://deploy-preview-55--angry-elion-ffa09b.netlify.app

Thank you, @krvajal !


CppInterOp Integration

Binder seems to work. We will investigate the failures as they seem specific to the container setup.


[Bug]: Compatibility with GA4 consent and services

Expected Behavior
You can choose between different categories, and only the categories you select will appear as granted in the Google Analytics consent mode.

Current Behavior
Even if you check only certain categories, they will all appear in the modes consent because this does not filter out the cookie.services section.

Steps to reproduce
Setup following CookieConsent, then configure Google Analytics with consent mod depending on cc_cookie
CookieConsent.run({
guiOptions: {
consentModal: {
layout: "box",
position: "bottom left",
equalWeightButtons: true,
flipButtons: true
},
preferencesModal: {
layout: "box",
position: "right",
equalWeightButtons: true,
flipButtons: false
}
},
categories: {
necessary: {
readOnly: true
},
analytics: {},
ads: {}
},
language: {
default: "fr",
autoDetect: "browser",
translations: {
fr: {
consentModal: {
description: "Chez Stores-et-rideaux.com, nous utilisons les cookies nécessaires pour faciliter votre navigation.",
acceptAllBtn: "ACCEPTER ET FERMER",
acceptNecessaryBtn: "Refuser",
showPreferencesBtn: "Personnaliser"
},
preferencesModal: {
title: "Choisir les cookies à accepter",
acceptAllBtn: "Tout Accepter",
acceptNecessaryBtn: "Refuser",
savePreferencesBtn: "Accepter et fermer",
closeIconLabel: "Close modal",
serviceCounterLabel: "Service|Services",
sections: [
{
title: "Essentiels",
linkedCategory: "necessary"
},
{
title: "Analytics",
linkedCategory: "analytics"
},
{
title: "Ads",
linkedCategory: "ads"
},
]
}
}
}
});
});
Proposed fix or additional info.
I finished by create a new cookie, to edit it myself and remove the services part. I think that google see the services part and use it too for gtag consent mod. When I remove manually the service part in cc_cookie it works fine (thats's why I'm able to reproduce it)
I've seen stories everywhere about services for categories, but nothing about the general service that encompasses all categories. I based myself on the github and the doc.
https://cookieconsent.orestbida.com/reference/api-reference.html
Version
3.0.0-rc.15
On which browser do you see the issue?
Chrome

Not sure I understand. How did you set up gtag? What does the plugin's cookie have to do with gtag?

Do you mean that we manage the sending of gtag with granted ourselves?

Yes, since the plugin doesn't come with any pre-configured service. The fact that you are actually getting some consent info means that you are actually loading the gtag script.
Also, there is no relation between the plugin's own cookie (cc_cookie by default) and the ones gtag/ga4 reads, so I don't see how you're getting a list of the accepted categories in the first place.
Here is an example setup of GTM with google consent mode v2.
You might have to change a few things, based on your needs. For example, if you don't use google ads, simply delete the script with the data-service="Google Ads" attribute.

Thank you for the quick answers to my problem. I managed to find the solution.
For those of you in the same situation, I took the problem the other way round and looked at the GA4 settings.
I changed the data search to a regular expression that only takes into account items inserted in categories

Thanks for your help


Fix Marshaling of Dialogue

Marshaling of Dialogue was incorrect.
Unmarshaling was filling both SingleAsn1Type and DialoguePDU, so marshaling back was writting both which is incorrect.
Issues found with unit tests were fixed, thanks :-)
Next PR is to support marshaling of nested/recursive IEs!

It seems there is an issue with your golangci-lint pipeline: https://github.com/wmnsk/go-tcap/actions/runs/8440015877/job/23120006589?pr=17#step:3:81
The golangci-lint version used does not seem to work with the golang toolchain used. You are probably hitting a bug similar to https://github.com/golangci/golangci-lint/issues/4273. golangci-lint's version to be used in the pipeline should be updated.

Thanks a lot for your comments and suggestions!
I'll add a test case and apply your suggestions.

Suggestions applied, and test case (DialoguePDU containing a dummy UserInformation) added.
Thanks!


Enhancement: Add support for R

Jupyter notebook is a brilliant interactive computing notebook environment for many languages.  At present, the kernel of jupyter notebook can provide support for R.
It couldn't be better if support like linting, auto-completion and formatting for R can be added in this extension!

Thanks for the suggestion.
We'd love to support R as well as Python, Julia, and others, but generally the jupyter extension isn't going to provide language specific features. Instead we expect other extensions to do that work. This one might be a good place to log a suggestion to support notebooks:
https://github.com/MikhailArkhipov/vscode-r


Post data fixes

Takes care of a number of small issues... from fixing post sorting, to having data for properly displaying icons when posts are gilded, archived or locked.  There'll be some additional fixes on 2X, but this is a prerequisite.
👓 @phil303 @nramadas

:fish:


Request: admin access for origami-core

Could the Origami-Core GitHub team have admin access to the repository? We try and ensure that components have the same labels for GitHub issues etc.


Animated Delay is not exported

On:
https://github.com/RealOrangeOne/react-native-mock/blob/4c33a4de618b7a3c4cb8922884ae5dd7cc4218bf/src/api/Animated/AnimatedImplementation.js#L1162
Results in:
Error: Uncaught [TypeError: _reactNative.Animated.delay is not a function]

Working on how to run my fork locally, but the error in my code is gone with this PR.


Update & extend "expected" fixtures

This addresses several problems with the expected fixtures:

We should be testing, in all decoding implementations, decoding both with and without "advanced" encodings. This starts generating a expected.mlt (which does not used advanced encodings) and an expected.advanced.mlt (which does). In a followup PR I'll work to make sure both implementations work with both of these correctly. Currently both implementations have lacking functionality hidden behind disabled tests.
We previously started adding a root mltmetadata.pbf per tile source (.e.g bing) directory. But the metadata is currently different per tile. So this addresses that problem by generating new metadata per tile and renaming the several mltmetadata.pbf the JS tests had started depending on
In order to make it easier to view the metadata (and know if/how it may change if the tiles are updated) I've also checked in the yaml-ish representation of it (made with protoc --decode)
Some tiles fail to encode currently, so this dumps a .failed record in the expected directory as a signal of the problem

Note: if folks like this proposed structure, I'll followup by adding a script to this PR to regenerate things. Currently my draft script depends on #123 and looks like:
trap "exit" INT

set -euo pipefail

tiles=$(find ./test/fixtures -type f \( -name "*.mvt" -o -name "*.pbf" \))

for fixture in ${tiles}; do
    expected_path=$(echo $fixture | sed 's/fixtures/expected/g' | sed 's/\.[^.]*$//')
    mlt_path=${expected_path}.mlt
    meta_path_pbf=${expected_path}.mlt.meta.pbf
    meta_path_dump=${expected_path}.mlt.meta.yaml
    geojson_path=${expected_path}.geojson
    if [ ! -f "${expected_path}.advanced.mlt" ]; then
        echo "Processing: $fixture"
        # temporarily move into the java directory so that the fsst so is found
        cd ./java
        set +e
        RESULT_ERROR=$(java -jar ./build/libs/encode.jar -mvt ../${fixture} -mlt ../${expected_path}.advanced.mlt -advanced 2>&1 >/dev/null)
        RETURN_CODE=$?
        set -e
        cd ../
        if [[ ${RETURN_CODE} != 0 ]]; then
            echo "Failed to encode MLT file: ${RETURN_CODE} $RESULT_ERROR"
            mkdir -p $(dirname ${expected_path}.advanced.mlt.failed)
            echo $RESULT_ERROR > ${expected_path}.advanced.mlt.failed
            continue
        fi
        java -jar ./java/build/libs/meta.jar   -mvt ${fixture} -meta ${meta_path_pbf}
        java -jar ./java/build/libs/encode.jar -mvt ${fixture} -mlt ${expected_path}.mlt
        protoc --decode=mlt.TileSetMetadata spec/schema/mlt_tileset_metadata.proto < ${meta_path_pbf} > ${meta_path_dump}
        # vt2geojson -z 0 -x 0 -y 0 ${fixture} > ${geojson_path}
        # GZIP=-9 tar -czvf ${geojson_path}.tar.gz ${geojson_path}
        # rm ${geojson_path}
    fi
done

failed=$(find ./test/expected -type f \( -name "*.failed" \))
if [ -z "$failed" ]; then
    echo "All fixtures encoded successfully!"
    exit 0
else
    for fixture in ${failed}; do
        echo "Failed to encode MLT file: "
        cat $fixture
    done
fi

@springmeyer are you checking in both yaml and pbf?  It seems redundant for each test file to have two representations checked in.  Perhaps just the yaml one should be enough? BTW, those yaml files look very strange - are they actually yaml or something else?

@springmeyer i would actually prefer that yaml-ish output to be checked in -- this way we can see the difference between versions, and it would be useful when reviewing. Checking in binary blobs is almost always the worst option because we cannot easily inspect how they changed with versions, and if the change is valid or not.  Just lets rename the files to some other extension so as not to assume they are yaml (or are they?).

@nyurik renamed from yaml to to txt in 974ca75. I think .txt is reasonable: I cannot find documentation in the protobuf library about the format and the tool that generates it just calls it "text": https://github.com/protocolbuffers/protobuf/blob/bbf52275dbad317bad3421f3c69b5f3759eb2b23/src/google/protobuf/compiler/command_line_interface.h#L385

As far as whether to check in the pbf or not, here are the considerations I see:

The pbf format is required throughout the codebase. I think that changing to a different format, while good to consider overall, is out of scope for this PR
The pbf format can be dynamically generated by the protoc command. So we could consider having the test frameworks in java and js call out to protoc dynamically. But I'm hesitant to do that, as the protoc tool is a binary C program and adding tooling to download versions of it seems a little too complicated compared to just checking in stable versions.

These are valid concerns, and at the same time having tons of unreadable and hard to parse opaque blobs in git is pretty bad. Also, I do agree that shelling out is sub-optimal.
Since this is really an integration test (i.e. back-to-back type of test, rather than a small internal test for one of the compressions, etc), how about we simply dump all generated pbfs to the test/output/java/* dir, add the test/output dir to .gitignore, and simply add an extra bash step after running the tests to dump all pbf files as .txt, and use diff command to compare txt to the expected values?  I am more than happy to help with these automation steps.
This way we:

actually see why test result differs in CI logs or in console, instead of simply getting "binary diffs do not match" - and having to run the tool by hand to see how results differ
are always certain what our tests generate (.txt becomes the source of truth)
can inspect any changes between versions by looking at git diff
do not have to worry of yet another set of "unknown binary blobs" (that was the recent XZ attack path - so the fewer bin blobs, the safer we are)
we can download protoc util on the fly in the CI - possibly as part of the same script that runs it

I am more than happy to help with these automation steps.

Go for it! I'll happily hand over this PR to you.

@nyurik you were going to take a look at this PR. What is the status in your mind? I see:

nyurik force-pushed the dane/fixture-expected-update  branch from 7744178 to 5d5835a 5 days ago

But I'm unsure what you thought the next steps were? Maybe we should voice on this briefly today?

@nyurik thanks for the clarification. I agree too that "this way we can just store the text versions in git." is a desirable goal. I'd like that too and so I'm going to close this and take a look at doing that in a separate PR. The most important point of attention is the input MVT tiles not the metadata, so that is what I'm going to explore storing as only text. Will revisit when I have the attention to give it.


[Perf regression] pprof flame graphs reveal Link is now very expensive.

Calculations for 600 entities that used to take < 500 milliseconds now take 10+ minutes. Did some profiling and found some interesting bottlenecks. Main culprit - DetectCycleIfLinked

You'll find the pprof file here if you want to dig in more
 go tool pprof -http=: [filename]

I've tweaked Link to not have a dedicated DetectCycleIfLinked call, and instead just checks for duplicate IDs in the propagate height change pass. Let me know if that helps, otherwise can dig in more.

~75% improvement. ~12mins -> ~3mins ..

It's still spending a lot of time in Link, specifically in calculating heights.
I used to calculate height on observation using a full depth pass, but switched to doing it on link to make the depth calculation simpler, it may bear reverting that. I'll look more later today.

I'm actually surprised how expensive maps are in go. Wow. Maybe we can do without it and use slices? .. It seems maps are useful only for Remove, RemoveKey, HasKey, Has ..
Maybe we manage both map and list - using the map for the lookups. Remove will be painful for the slice though

Actually maybe a linkedlist instead

Took a stab at refactoring the node lists as arrays, if you want to give it a shot it's on a branch will--node-slices

It got much worse. The simple formula, f(t) = f(t-1) (bind(t) -> bind(t-1)) is exhibiting an interesting behavior in this case.
Time to compute(t )= ~2 * Time to compute(t-1) .. It's basically getting very slow with time. We seem to be doing twice as much work somewhere in the code.

goos: darwin
goarch: arm64
pkg: github.com/wcharczuk/go-incr
Benchmark_Stabilize_withPreInitialize_512-12                        3544            334136 ns/op
Benchmark_Stabilize_withPreInitialize_1024-12                       1701            686518 ns/op
Benchmark_Stabilize_withPreInitialize_2048-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_withPreInitialize_4096-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_withPreInitialize_8192-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_withPreInitialize_16384-12                        58          17498667 ns/op
Benchmark_ParallelStabilize_withPreInitialize_512-12                5242            206747 ns/op
Benchmark_ParallelStabilize_withPreInitialize_1024-12               2972            413081 ns/op
Benchmark_ParallelStabilize_withPreInitialize_2048-12               1344            878369 ns/op
Benchmark_ParallelStabilize_withPreInitialize_4096-12<PHONE_NUMBER> ns/op
Benchmark_ParallelStabilize_withPreInitialize_8192-12<PHONE_NUMBER> ns/op
Benchmark_ParallelStabilize_withPreInitialize_16384-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_deep_2_32-12                                  130470              8657 ns/op
Benchmark_Stabilize_deep_4_64-12                                   61016             19832 ns/op
Benchmark_Stabilize_deep_4_96-12                                   37338             32200 ns/op
Benchmark_Stabilize_deep_4_128-12                                  25688             45757 ns/op
Benchmark_Stabilize_deep_8_256-12                                   9468            105664 ns/op
Benchmark_Stabilize_deep_8_512-12                                   4216            243333 ns/op
Benchmark_Stabilize_nestedBinds_64-12                               3104            364077 ns/op
Benchmark_Stabilize_nestedBinds_128-12                              1585            762989 ns/op
Benchmark_Stabilize_nestedBinds_256-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_nestedBinds_512-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_nestedBinds_1024-12                               82          14884032 ns/op
PASS
ok      github.com/wcharczuk/go-incr    33.639s```

this is on `main`

now in the branch:

```$ go test -bench=.                                                                                go-incr will--node-slices U
goos: darwin
goarch: arm64
pkg: github.com/wcharczuk/go-incr
Benchmark_Stabilize_withPreInitialize_512-12                        5047            235604 ns/op
Benchmark_Stabilize_withPreInitialize_1024-12                       2192            521280 ns/op
Benchmark_Stabilize_withPreInitialize_2048-12                       1087           1070649 ns/op
Benchmark_Stabilize_withPreInitialize_4096-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_withPreInitialize_8192-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_withPreInitialize_16384-12<PHONE_NUMBER>0 ns/op
Benchmark_ParallelStabilize_withPreInitialize_512-12                6321            194922 ns/op
Benchmark_ParallelStabilize_withPreInitialize_1024-12               3174            379615 ns/op
Benchmark_ParallelStabilize_withPreInitialize_2048-12               1224            826760 ns/op
Benchmark_ParallelStabilize_withPreInitialize_4096-12<PHONE_NUMBER> ns/op
Benchmark_ParallelStabilize_withPreInitialize_8192-12<PHONE_NUMBER> ns/op
Benchmark_ParallelStabilize_withPreInitialize_16384-12<PHONE_NUMBER> ns/op
Benchmark_Stabilize_deep_2_32-12                                  165904              6728 ns/op
Benchmark_Stabilize_deep_4_64-12                                   84187             14356 ns/op
Benchmark_Stabilize_deep_4_96-12                                   52000             23269 ns/op
Benchmark_Stabilize_deep_4_128-12                                  34252             33929 ns/op
Benchmark_Stabilize_deep_8_256-12                                  12408             94424 ns/op
Benchmark_Stabilize_deep_8_512-12                                   5383            208085 ns/op
Benchmark_Stabilize_nestedBinds_64-12                            8714553               135.3 ns/op
Benchmark_Stabilize_nestedBinds_128-12                           8460531               135.3 ns/op
Benchmark_Stabilize_nestedBinds_256-12                           8174994               138.7 ns/op
Benchmark_Stabilize_nestedBinds_512-12                           7199878               145.5 ns/op
Benchmark_Stabilize_nestedBinds_1024-12                          6166285               163.8 ns/op
PASS
ok      github.com/wcharczuk/go-incr    34.881s

there is a fair bit of work now for unobserves; specifically we have to plumb the graph for anywhere that still references a node to prevent a specific breakage i've added some regression tests for (see the other issue), i'll get creative with how to approach this is the perf is still bad

#9 to address

Dropped to ~2:30min

Example of what I meant
func Benchmark_Stabilize_connectedGraph_with_nestedBinds_1024(b *testing.B) {
	benchmarkConnectedGraphWithNestedBinds(1024, b)
}

func benchmarkConnectedGraphWithNestedBinds(depth int, b *testing.B) {
	ctx := context.Background()
	fakeFormula := Var(Root(), "fakeFormula")
	observed := make([]ObserveIncr[*int], depth)
	g := New(
		GraphMaxRecomputeHeapHeight(1024),
	)
	for x := 0; x < b.N; x++ {
		for i := 0; i < depth; i++ {
			o := makeSimpleNestedBindGraph(g, depth, fakeFormula)
			observed[i] = o
		}
		err := g.Stabilize(ctx)
		if err != nil {
			b.Error(err)
			b.FailNow()
		}
		for _, o := range observed {
			if o.Value() == nil {
				b.FailNow()
			}
		}
	}
}

func makeSimpleNestedBindGraph(graph *Graph, depth int, fakeFormula VarIncr[string]) ObserveIncr[*int] {
	cache := make(map[string]Incr[*int])
	var f func(bs *BindScope, t int) Incr[*int]
	f = func(bs *BindScope, t int) Incr[*int] {
		key := fmt.Sprintf("f-%d", t)
		if _, ok := cache[key]; ok {
			return WithinBindScope(bs, cache[key])
		}
		r := Bind(Root(), fakeFormula, func(bs *BindScope, formula string) Incr[*int] {
			if t <= 0 {
				out := 0
				r := Return(bs, &out)
				r.Node().SetLabel("f-0")
				return r
			}
			return Map(bs, f(bs, t-1), func(r *int) *int {
				out := *r
				return &out
			})
		})

		r.Node().SetLabel(fmt.Sprintf("f(%d)", t))
		cache[key] = r
		return r
	}
	o := f(Root(), depth)
	return Observe(Root(), graph, o)
}

Thanks for the test case!
So this is still super expensive, but I've tuned things a bit to get that specific test to be a little faster.
I think there is still a lot of work to do, and separately I'm looking into how to integrate an adjustHeightsHeap.
Lemme know how this performs on latest main.

OK the refactor is in, I'll be tuning things and adding tests over the weekend, but so far it looks a little better.
One quick note about the above test; it creates a lot of nodes, specifically because it mutates a graph over and over within the benchmark N loop, even refactoring it not to do that, it still creates a quadratic number of nodes which becomes kind of bad past 256^3 (e.g. 16 million nodes).
there is some improvement though, and hopefully you see times come down a bit more.

Times have indeed significantly come down. We back to milliseconds 🙌  but in some cases however it spikes back up to minutes. I think these test cases repro the issue. It seems the order in which you do the calculations can significantly affect perf.
Formulas
	f = func(bs *incr.BindScope, t int) incr.Incr[*int] {
		key := fmt.Sprintf("f-%d", t)
		if _, ok := cache[key]; ok {
			return incr.WithinBindScope(bs, cache[key])
		}

		r := incr.Bind(incr.Root(), fakeFormula, func(bs *incr.BindScope, formula string) incr.Incr[*int] {
			if t <= 0 {
				out := 0
				r := incr.Return(bs, &out)
				r.Node().SetLabel("f-0")
				return r
			}
			bindOutput := incr.Map(bs, f(bs, t-1), func(r *int) *int {
				if r == nil {
					return nil
				}
				out := *r + 1
				return &out
			})
			bindOutput.Node().SetLabel(fmt.Sprintf("map-f-%d", t))
			return bindOutput
		})

		r.Node().SetLabel(fmt.Sprintf("f(%d)", t))
		cache[key] = r
		return r
	}

	// burn(t) = f(t)
	burn := func(bs *incr.BindScope, t int) incr.Incr[*int] {
		return incr.Bind(bs, fakeFormula, func(bs *incr.BindScope, formula string) incr.Incr[*int] {
			return f(bs, t)
		})
	}

	// cashbalance = cashbalance(t-1) - burn(t)
	var cash_balance func(bs *incr.BindScope, t int) incr.Incr[*int]
	cash_balance = func(bs *incr.BindScope, t int) incr.Incr[*int] {
		return incr.Bind(bs, fakeFormula, func(bs *incr.BindScope, formula string) incr.Incr[*int] {
			if t <= 0 {
				out := 0
				r := incr.Return(bs, &out)
				return r
			}
			return incr.Map2(bs, cash_balance(bs, t-1), burn(bs, t), func(c *int, b *int) *int {
				if c == nil || b == nil {
					return nil
				}
				out := *c - *b
				return &out
			})
		})
	}

	// monthofrunway = if burn > 0 then cashbalance / burn else 0
	months_of_runway := func(bs *incr.BindScope, t int) incr.Incr[*int] {
		return incr.Bind(bs, fakeFormula, func(bs *incr.BindScope, formula string) incr.Incr[*int] {
			zero := 0
			predicateIncr := incr.Map2(bs, burn(bs, t), incr.Return(bs, &zero), func(val *int, cmp *int) bool {
				if val == nil || cmp == nil {
					return false
				}
				return *val > *cmp
			})
			return incr.Bind(bs, predicateIncr, func(bs *incr.BindScope, predicate bool) incr.Incr[*int] {
				var out int = 0
				if predicate {
					return incr.Map2(bs, cash_balance(bs, t), burn(bs, t), func(c *int, b *int) *int {
						if c == nil || b == nil {
							return nil
						}
						out = *c / *b
						return &out
					})
				}
				return incr.Return(bs, &out)
			})
		})
	}

Tests
Test 1: Calculate months_of_runway then burn.
t.Run("month_of_runway = if burn > 0: cash_balance / burn else 0.  Then in the next iteration, burn is calculated and we'd expect that it is quicker because calculating months of runway should have cached some burn results.
Test 2: Calculate burn then months_of_runway
	t.Run("month_of_runway = if burn > 0: cash_balance / burn else 0.

If you pull latest main, I've added this case as an "example" under examples/integration.
Specifically, if you look at the main.go file in there, I've changed the burn function slightly:
	// burn(t) = f(t)
	burn := func(bs *incr.BindScope, t int) incr.Incr[*int] {
		key := fmt.Sprintf("burn-%d", t)
		if _, ok := cache[key]; ok {
			return incr.WithinBindScope(bs, cache[key])
		}
		o := incr.Bind(bs, fakeFormula, func(bs *incr.BindScope, formula string) incr.Incr[*int] {
			return f(bs, t)
		})
		o.Node().SetLabel(key)
		cache[key] = o
		return o
	}

The change specifically is to "cache" the result of the burn nodes, similarly to how we cache the result of the f nodes.
The resulting speeds are then roughly equivalent first,second vs. second,first.
Digging in deeper, there actually was a bug in how the "ShouldRecompute" state of bind nodes was propagated; it wasn't considering if you just re-bound the same node that the computation should stop (instead it continued, causing children to recompute even though the parent technically didn't change).
With the fixed version of ShouldRecompute, and the above change, I think you'll be in good shape.
Going to close this out.

Ok so the above is technically true, but there was another bug.
Because we link the bound nodes to the bind itself, and then that remains the only link to the nodes that take the bind, we can get into situations where the bound node recomputing will cause the bind to re-bind unnecessarily, as we only care about running the bind function if the bind's input changes.
I've tweaked Bind to only consider the changedAt of the input node when it stabilizes, and this should fix the above without needing to use the cache trick.
I've also reflected this in the integration example.


yarn release does not work on linux: GNU/sed syntax?

I assume my sed version on Linux treats passed arguments differently than on OS X-based sed.
OK: sed -i 's|replace this with|pattern|' file
File not found: sed -i '' 's|replace this with|pattern|' file
$ yarn release
yarn run v1.3.2
$ yarn build_ui && yarn fix_asar && build --draft
$ webpack
Hash: effcf9a2630188edd252
...
$ sed -i '' 's|run(cmd, args|run(cmd.replace("app.asar", "app.asar.unpacked"), args|' node_modules/ipfsd-ctl/src/exec.js
sed: can't read s|run(cmd, args|run(cmd.replace("app.asar", "app.asar.unpacked"), args|: No such file or directory
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
$ ls node_modules/ipfsd-ctl/src/exec.js
node_modules/ipfsd-ctl/src/exec.js

Fixing the second argument lets yarn release run fine. The built .deb package installs just fine too.
It works definitely on Ubuntu 17.10. :fireworks: :champagne: @bhstahl

#41 contains a commit which fixes this issue on linux. @bhstahl Please try on OS X before merging

@bhstahl fixed it on my branch:
check it out:  https://github.com/hexagon6/Partyshare/releases
There is a Partyshare.deb for download available now :smile:
Adjust travis-ci settings if you want to Pull this in for BusterLabs, since a Github API-token needs to be added.

Wahoo! I'm going to take a quick stab at seeing if I can remove that fix asap step first (https://github.com/BusterLabs/Partyshare/issues/14) since that would be ideal


Source IP not preserved in HTTP headers

Bug description
Brief overview: In our current implementation of Istio, the ingress gateway sits behind one of our partner's reverse proxies, i.e. the client owns the domain name, which gets resolved to their reverse proxy, which in turn forwards traffic to our ingress gateway IP. In turn, the ingress gateway acts as reverse proxy itself, routing traffic to either an Azure Web App (the web frontend) or an API service (running on Kubernetes).
While this system works fine, we've found that since migrating to this new implementation (before requests would go directly from the partner's reverse proxy to Azure or Kubernetes), we lost track of the client source IP in the HTTP headers. These were recorded in the X-Forwarded-For header, which should normally contain the client IP and the partner gateway's IP appended to the right, e.g.:
X-Forwarded-For: (client IP),(partner gateway IP)
Now, only the rightmost IP (that of the partner gateway) gets preserved. This is an issue for us as our IP blocking system uses the data it extracts from XFF as a filtering logic, and with all requests seemingly originating from the same IP, it is rendered pretty useless.
After consulting a few similar issues (namely #7607 and #10875) I have made the following changes to my deployment:

Changed the externalTrafficPolicy setting to Local in the ingressgateway config
Tried setting the useRemoteAddress setting of the Envoy config to false by using an EnvoyFilter, however HTTP requests begantiming out after applying the filter
Finally managed to push the setting by modifying the source code and recompiling a custom version of Pilot's discovery container image, which I then deployed from my DockerHub to my Pilot deployment in Kubernetes.

So far, all regular HTTP requests yield the partner's gateway IP in their X-Forwarded-For headers. Requests sent with custom XFF headers (e.g. via Reqbin) retain their custom data, however this is not the case for the majority of our clients.
Any idea how I could go about enforcing XFF header preservation in Istio beyond these two settings? Also, is there an easier way to push the useRemoteAddress setting in Envoy besides building a custom Pilot image? In a different thread (#15236) someone mentioned injecting a custom environment variable via helm - is this possible?
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
X-Forwarded-For headers containing the source IP of the client that made the request.
Steps to reproduce the bug
Publish a web application via Istio; for better accuracy, use an intermediate proxy to reach the web application (Fiddler can provide this functionality, also any transparent web proxy that you can find online).
Set the externalTrafficPolicy to Local in the ingress-gateway section of install/kubernetes/helm/istio/charts/gateways/values.yaml
The useRemoteAddress setting should also be switched to false - if you need a custom Pilot image with this setting you can use bogdansucila/istio_test:v1 (in v2 and v2.1 I played around with the xff_num_trusted_hops setting, v1 should only have this one modification to the defaults); I hear the setting can also be injected via an environment variable with helm, but I haven't tested this yet.
Version (include the output of istioctl version --remote and kubectl version)
Istio: 1.1.0
Kubernetes: 1.12
How was Istio installed?
Using helm
Environment where bug was observed (cloud vendor, OS, etc)
Azure Kubernetes Service (AKS)
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

someone mentioned injecting a custom environment variable via helm - is this possible?

You can pass this into helm with --set pilot.env.PILOT_SIDECAR_USE_REMOTE_ADDRESS
This is only in 1.2.2 by the way

I believe this is fixed with the above. If not feel free to reopen

https://blog.opstree.com/2020/04/07/preserve-source-ip-in-aws-classic-load-balancer-and-istios-envoy-using-proxy-protocol/


Driver: Error Resource temporarily unavailable Cannot lock port

Problem/Motivation
I migrated to a new raspberry PI install using Aeotec 7 Z hat
I moved the config folder from HA to the new install (except the database)
I installed Zwave JS  2 MQTT, it was working fine at first
I copy the previous network key, some device was working other wasn't. so I remove the 3 other devices that wasn't working and add them again.
since reboot I have "Driver: Error Resource temporarily unavailable Cannot lock port" I removed the add-on for a day and only used the Zwave integration which still allow me to add some device, then tried again 24 hours after, same message.
history
Expected behavior
load Zwave devices
Actual behavior
display "Driver: Error Resource temporarily unavailable Cannot lock port"
history
Steps to reproduce
Open Zwave 2 MQTT webinf
Proposed changes

2021-05-27T17:50:52.414Z CNTRLR « [Node 026] Association group #1 has name "Lifeline"
2021-05-27T17:50:52.414Z CNTRLR » [Node 026] Association group #1: Querying command list...
2021-05-27T17:50:52.452Z CNTRLR » [Node 026] Association group #2: Querying name...
2021-05-27T17:50:52.516Z CNTRLR « [Node 026] Association group #2 has name "Control"
2021-05-27T17:50:52.516Z CNTRLR » [Node 026] Association group #2: Querying command list...
2021-05-27T17:50:52.560Z CNTRLR » [Node 026] Association group #3: Querying name...
2021-05-27T17:50:52.596Z CNTRLR « [Node 026] Association group #3 has name "Alarm"
2021-05-27T17:50:52.597Z CNTRLR » [Node 026] Association group #3: Querying command list...
2021-05-27T17:50:52.631Z CNTRLR » [Node 026] Association group #4: Querying name...
2021-05-27T17:50:52.669Z CNTRLR « [Node 026] Association group #4 has name "Tamper"
2021-05-27T17:50:52.671Z CNTRLR » [Node 026] Association group #4: Querying command list...
2021-05-27T17:50:52.704Z CNTRLR » [Node 026] Association group #5: Querying name...
2021-05-27T17:50:52.745Z CNTRLR « [Node 026] Association group #5 has name "Tilting"
2021-05-27T17:50:52.746Z CNTRLR » [Node 026] Association group #5: Querying command list...
2021-05-27T17:50:52.780Z CNTRLR » [Node 026] Association group #1: Querying info...
2021-05-27T17:50:52.819Z CNTRLR « [Node 026] Received info for association group #1:
                                  info is dynamic: false
                                  profile:         General: Lifeline
2021-05-27T17:50:52.820Z CNTRLR » [Node 026] Association group #2: Querying info...
2021-05-27T17:50:52.857Z CNTRLR « [Node 026] Received info for association group #2:
                                  info is dynamic: false
                                  profile:         Control: Key 01
2021-05-27T17:50:52.857Z CNTRLR » [Node 026] Association group #3: Querying info...
2021-05-27T17:50:52.894Z CNTRLR « [Node 026] Received info for association group #3:
                                  info is dynamic: false
                                  profile:         Notification: Access Control
2021-05-27T17:50:52.896Z CNTRLR » [Node 026] Association group #4: Querying info...
2021-05-27T17:50:52.933Z CNTRLR « [Node 026] Received info for association group #4:
                                  info is dynamic: false
                                  profile:         Notification: Home Security
2021-05-27T17:50:52.933Z CNTRLR » [Node 026] Association group #5: Querying info...
2021-05-27T17:50:52.969Z CNTRLR « [Node 026] Received info for association group #5:
                                  info is dynamic: false
                                  profile:         Control: Key 02
2021-05-27T17:50:52.984Z CNTRLR   [Node 026] Interviewing Central Scene...
2021-05-27T17:50:52.986Z CNTRLR » [Node 026] Querying supported scenes...
2021-05-27T17:50:53.021Z CNTRLR « [Node 026] received supported scenes:
                                  # of scenes:           1
                                  supports slow refresh: false
2021-05-27T17:50:53.023Z CNTRLR   [Node 026] Interviewing Notification...
2021-05-27T17:50:53.024Z CNTRLR » [Node 026] querying supported notification types...
2021-05-27T17:50:53.077Z CNTRLR « [Node 026] received supported notification types:
                                  · Access Control
                                  · Home Security
2021-05-27T17:50:53.079Z CNTRLR » [Node 026] querying supported notification events for Access Control...
2021-05-27T17:50:53.118Z CNTRLR « [Node 026] received supported notification events for Access Control: 22, 23
2021-05-27T17:50:53.118Z CNTRLR » [Node 026] querying supported notification events for Home Security...
2021-05-27T17:50:53.160Z CNTRLR « [Node 026] received supported notification events for Home Security: 3
2021-05-27T17:50:53.163Z CNTRLR » [Node 026] enabling notifications for Access Control...
2021-05-27T17:50:53.209Z CNTRLR » [Node 026] enabling notifications for Home Security...
2021-05-27T17:50:53.242Z CNTRLR   [Node 026] Interview stage completed: CommandClasses
2021-05-27T17:50:53.245Z CNTRLR   [Node 026] Interview stage completed: OverwriteConfig
2021-05-27T17:50:53.246Z CNTRLR » [Node 026] requesting node neighbors...
2021-05-27T17:50:53.261Z CNTRLR « [Node 026] node neighbors received: 1, 3, 10
2021-05-27T17:50:53.262Z CNTRLR   [Node 026] Interview stage completed: Neighbors
2021-05-27T17:50:53.264Z CNTRLR   [Node 026] Interview completed
2021-05-27T17:50:53.265Z CNTRLR   [Node 026] The node is ready to be used
2021-05-27T17:50:54.287Z CNTRLR » [Node 026] Sending node back to sleep...
2021-05-27T17:50:59.431Z CNTRLR   [Node 026] The node did not respond after 1 attempts.
                                  It is probably asleep, moving its messages to the wakeup queue.
2021-05-27T17:50:59.435Z CNTRLR   [Node 026] The node is now asleep.


Starting docke containers failed

This issue tracker is only for issues related to Frappe-Manager. Please use https://github.com/rtcamp/frappe-manager/discussions for support questions.
Describe the bug
Docker containers fail to start
To Reproduce
Steps to reproduce the behavior:

Run command 'fm -v create frappe'
See error

Expected behavior
That containers would start
System information (please complete the following information):

[ 0.9.0] fm --version
[No LSB modules are available.
Distributor ID:	Pop
Description:	Pop!_OS 22.04 LTS
Release:	22.04
Codename:	jammy
] lsb_release -a
[Client:
Version:           24.0.6-rd
API version:       1.43
Go version:        go1.20.7
Git commit:        da4c87c
Built:             Wed Sep  6 16:41:53 2023
OS/Arch:           linux/amd64
Context:           desktop-linux

Server: Docker Desktop 4.26.1 (131620)
Engine:
Version:          24.0.7
API version:      1.43 (minimum version 1.12)
Go version:       go1.20.10
Git commit:       311b9ff
Built:            Thu Oct 26 09:08:02 2023
OS/Arch:          linux/amd64
Experimental:     false
containerd:
Version:          1.6.25
GitCommit:        d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
runc:
Version:          1.1.10
GitCommit:        v1.1.10-0-g18a0cb0
docker-init:
Version:          0.19.0
GitCommit:        de40ad0
] docker version

[Docker Compose version v2.2.3 ] docker-compose version or docker compose version

Attach log
Please attach logs from ~/frappe/logs/fm.log for faster resolution.
fm.log
Additional context
Add any other context about the problem here.

Please run this command fm create frappes and share the contents of the fm.log once again.

Please run this command fm create frappes and share the contents of the fm.log once again.

I get the same error.
fm.log

@mazizij Update docker compose cli and it will start working.

@Xieyt , thanks it is working.


After selecting an emoji, the app doesn't work

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open app> open any chat
Enter any emogi from emogi picker
Try to send another msg

Expected Result:
After selecting the emoji, the app should work perfectly
Actual Result:
App does not work after selecting an emoji
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[x] iOS / native -  iPhone 13 pro
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reprodcution
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/231007853-90abb39e-8e8b-413a-a687-776a7541e83d.MP4
Expensify/Expensify Issue URL:
Issue reported by: @harshad2711
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681058360921509
View all open jobs on GitHub

@muttmuure Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Can't reproduce, unexpected outcome is very generic


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/996 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-archive-test-target.git

Docs Build status updates of commit 9d6734b:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: RepositoryUnauthorizedWithSourceCommit] Git data access to 'https://github.com/opstest2/docs-archive-test-source' (branch: Release_Archive_main_2022-01-06-08-03-03) is not authorized.. It looks like this might be the first time user: v-alji submitted a pull request to this repo. Before user can run builds in a pull request, he/she can enable 'v-alji' GitHub account in Docs by visiting Docs Portal (https://ops.microsoft.com). After enabling his/her account (v-alji), close and then reopen this pull request to start another build.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


times.BirthDate does not function on linux

Closes #27
use ModTime

Thanks! Will need to test further the whole UTC fix thing with footage from Hero4,5,6,7 cameras.

Thanks! Will need to test further the whole UTC fix thing with footage from Hero4,5,6,7 cameras.

Yeah . If it turns out to be only hero 5 session, will have to change on camera detect


design r0.5

[x] populate FPGA self-programming passives
[x] document U2, U14 part selection: Diodes Inc. 74AUP2G126RA3-7
[x] do not populate SWD/JTAG connectors J5, J6
[x] add ATSAMD11D14A-MNT as alt part for U6
[x] populate Pmod connectors J7 and J11
[x] improve D9 footprint
[x] give D9 a 3d model
[x] document D9 substitution(s)
[ ] maybe nudge J3 position
[ ] maybe improve U2, U14 paste layer
[x] make resistor precision notation (value field) consistent
[x] add part selection for Pmod connectors J7 and J11
[x] clarify USB3343-CP part number
[x] update U1, U12, U13 part number (see #171)
[x] update D1, D8 part number to reduce reverse leakage

Work in progress is here: https://github.com/mossmann/luna/tree/hw-r0.5

I decided against:

maybe nudge J3 position
maybe improve U2, U14 paste layer


A final, simpler API for 1.0

As I was working on the docs for 1.0 release, I realized that 1.0 API can be much simpler so I just rewrote everything. Here's a few snippets before and after to justify that.
Registering a drag source for a known type
Before
@DragDrop(
  register =>
    register.dragSource(ItemTypes.BOX, BoxSource),

  boxSource => ({
    connectDragSource: boxSource.connect(),
    isDragging: boxSource.isDragging()
  })
)
export default class Box {

After
@DragSource(ItemTypes.BOX, boxSource, (connect, monitor) => ({
  connectDragSource: connect.dragSource(),
  isDragging: monitor.isDragging()
}))
export default class Box {

Registering a drag source for a dynamic type
Before
@DragDrop(
  (register, props) =>
    register.dragSource(props.type, BoxSource),

  boxSource => ({
    connectDragSource: boxSource.connect(),
    isDragging: boxSource.isDragging()
  })
)
export default class Box {

After
@DragSource(props => props.type, boxSource, (connect, monitor) => ({
  connectDragSource: connect.dragSource(),
  isDragging: monitor.isDragging()
}))
export default class Box {

Registering a drop target for a known type
Before
@DragDrop(
  register =>
    register.dropTarget(ItemTypes.BOX, BoxTarget),

  boxTarget => ({
    connectDropTarget: boxTarget.connect()
  })
)
export default class Container extends Component {

After
@DropTarget(ItemTypes.BOX, boxTarget, connect => ({
  connectDropTarget: connect.dropTarget()
}))
export default class Container extends Component {

Registering a drop target for a dynamic type
Before
@DragDrop(
  (register, props) =>
    register.dropTarget(props.accepts, BoxTarget),

  boxTarget => ({
    connectDropTarget: boxTarget.connect()
  })
)
export default class Container extends Component {

After
@DropTarget(props => props.accepts, boxTarget, connect => ({
  connectDropTarget: connect.dropTarget()
}))
export default class Container extends Component {

Registering a mixed drag source and drop target
Before
@DragDrop(
  register => ({
    cardSource: register.dragSource(ItemTypes.CARD, CardSource),
    cardTarget: register.dropTarget(ItemTypes.CARD, CardTarget)
  }),

  ({ cardSource, cardTarget }) => ({
    connectDragSource: cardSource.connect(),
    connectDropTarget: cardTarget.connect(),
    isDragging: cardSource.isDragging()
  })
)
export default class Card {

After
@DropTarget(ItemTypes.CARD, cardTarget, connect => ({
  connectDropTarget: connect.dropTarget(),
}))
@DragSource(ItemTypes.CARD, cardSource, (connect, monitor) => ({
  connectDragSource: connect.dragSource(),
  isDragging: monitor.isDragging()
}))
export default class Card {

This is going to be the final API for 1.0. It is now frozen, and I'm only going to work on documentation, examples and bringing back some missing warnings and invariants.

This should be on NPM as<EMAIL_ADDRESS>

Also:
@configureDragDropContext(HTML5Backend)

is now
@DragDropContext(HTML5Backend)

Yeah right. And DragDropLayer is now DragLayer.
Documenting these folks now..


Type 'typeof MyCollectionProperties' has no properties in common with type 'ValidationPipeOptions'.

Hi,
I can't pass the ValidationPipe to the Query decorator because of the following error:
Type 'typeof MyCollectionProperties' has no properties in common with type 'ValidationPipeOptions'.

The code is the same as found in the README.md.
Some dependencies that might be useful for debugging:
    "@nestjs/common": "8.0.0",
    "@nestjs/core": "8.0.0",
    "typescript": "4.3.5"
    "@forlagshuset/nestjs-mongoose-paginate": "1.0.2", // another minor thing: the forlagshuset is mispelled in the README.md file

Many thanks,
Peter

Hi @peternagy1332
Thanks! and very sorry for replying late. Could you please try version v1.1.0 but it should be also version with the version you tested. Could you please dump your project so that we can see the whole structure.
Cheers
Deepak
PS: Thanks for heads up! readme is now fixed.


Why was argInt removed?

argInt was removed as a breaking change in the version bump 0.1 -> 0.2, but there was no note in the changelog on what it was replaced with/ why it was removed, can you please clarify on that?
Thanks in advance.

My apologies for not noticing a7d4f9af169302f889b3b8e62f37bd488e517bbd before writing the 0.2 changelog entry.
While I wasn't the one who wrote this commit, I can make an educated guess behind its intent. The size of an Int or Word in Haskell is not necessarily the same size as an int or unsigned int in C, respectively, which makes it easy to mix up the two. For instance, an Int is 8 bytes on a 64-bit Linux GHC, but an int is 4 bytes on a 64-bit Linux GCC. This could lead to confusing behavior at runtime if a user supplied an Int value that could not fit into the size of an int.
For these reasons, I think the right thing to do is to avoid the use of arg{Int,Word} and ret{Int,Word} and instead use functions that precisely specify the size of the argument on the C side. (e.g., if your function takes an integer argument 4 bytes large, use argInt32.) Unfortunately, I made a 0.2 Hackage release before we could introduce a proper deprecation cycle, so perhaps the best thing to do is to retroactively adjust the changelog to mention this.

I've retroactively added the rationale for this change to the changelog in dd4c54aa8f417aa436d1ac795ec647fe8fe05fd8. Is this a satisfactory resolution, @MangoIV? If you'd like, I could upload a new minor release of libffi to Hackage with these changes so that the changelog on Hackage displays these changes.

Thank you, yes, this is enough information. I don't care for the new hackage upload, as I have my clarification but I guess it would be helpful for other, I guess this remains your decision. Thank you for resolving this so quickly!


Add support for joining overlay networks with CNI

This change adds a new field under container in each pod called networks that allows the user to specify which overlay networks to join by name:
container:
  networks:
    dcos: {}

An empty dictionary must be passed for the body right now, due to the fact that we only currently support joining networks by name, but was designed this way to allow backwards-compatible addition of e.g. port mappings in the future.
This was tested by creating a container that joins the dcos virtual network included by default in DC/OS installs and verifying that the IP for interface eth0 is in the <IP_ADDRESS>/24 subnet.

@mesosphere-ci retest this please

@mesosphere-ci retest this please


Adding TODO list.

Is there any functionality from the Telegram API or design-based yet not supported/planned/in progress?
If so, it might be beneficial to point it out explicitly in the README.md/milestones - therefore, potential customers can track the progress and developers contribute.

I've created issues for missing banana features (namely, #12 and #13)


Expose an API to retrieve the global state of the alarm system

Is your feature request related to a problem? Please describe.
ElmoClient retrieves the state of all inputs and sectors. Furthermore, it can arm/disarm a combination of sectors. What is missing is retrieving the state to understand if:

The alarm system is triggered
The alarm system has anomalies
The alarm system has been compromised

Describe the solution you'd like
Expose an API to get the global state so that the results can be exposed to home automation integrations (e.g. as a binary_sensor.
Describe alternatives you've considered
The external integration may map some inputs to identify them as "the alarm is triggered if these are on". But that's suboptimal and forces users to do extra configuration that may not be trivial.
Additional context
n/a

The API (url: https://connect.elmospa.com/api/statusadv) exposes the following values:
    "PanelAnomalies": {
        "HasAnomaly": false,
        "PanelTamper": 0,
        "PanelNoPower": 0,
        "PanelLowBattery": 0,
        "GsmAnomaly": 0,
        "GsmLowBalance": 0,
        "PstnAnomaly": 0,
        "SystemTest": 0,
        "ModuleRegistration": 0,
        "RfInterference": 0,
        "InputFailure": 0,
        "InputAlarm": 0,
        "InputBypass": 0,
        "InputLowBattery": 0,
        "InputNoSupervision": 0,
        "DeviceTamper": 0,
        "DeviceFailure": 0,
        "DeviceNoPower": 0,
        "DeviceLowBattery": 0,
        "DeviceNoSupervision": 0,
        "DeviceSystemBlock": 0
    },
    "PanelLeds": {
        "InputsLed": 2,
        "AnomaliesLed": 1,
        "AlarmLed": 0,
        "TamperLed": 0
    },

We may try to mock this response and see how the API behaves.


Fix security vulnerability from old version of com.fasterxml.jackson.core and com.fasterxml.jackson.dataformat

See https://github.com/ExpediaDotCom/haystack-pipes/network/alert/pom.xml/com.fasterxml.jackson.core:jackson-databind. This is for https://nvd.nist.gov/vuln/detail/CVE-2018-7489.

This was fixed but I forgot to close the issue. Closing now.


handle lots of errors

add error page template (pretty sparse for now, but has binder logo and footer and matches fonts/css)
use jinja templates to accomplish consistent pages (harder to do with tornado's own templates with don't allow block.super() )
never set an error code on eventsource endpoints because EventSource can't handle errors at all (error code and message are not available to javascript). Instead, send a phase: failed message.
catch eventsource errors client-side and treat them like a failed build (message about failed build will appear in build window)
informative error when github spec is invalid (too many or too few parts)
better error (not 500) message when ref cannot be resolved

This looks like an awesome start. I feel like @yuvipanda will be in the best position to comment on the code itself.
Is this ready for a review? Or are you hoping to hit a few more things first?

I think it's ready for review!
On Tue, Aug 29, 2017 at 2:08 PM, Chris Holdgraf<EMAIL_ADDRESS>wrote:

This looks like an awesome start. I feel like @yuvipanda
https://github.com/yuvipanda will be in the best position to comment on
the code itself.
Is this ready for a review? Or are you hoping to hit a few more things
first?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/binderhub/pull/91#issuecomment-325747310,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23sE9r8T3B_p5Wy_TZhRUXuI9CiSgks5sdFOfgaJpZM4PDqBG
.

--
Yuvi Panda T
http://yuvi.in/blog

Yup, this should be ready to go. There are a few more things I want to look at, but not in this PR.

ok cool - I can review the wording etc...it'll be a bit harder for me to spot-check the machinery of actually catching the errors.


Automatic PR from RestAPI-PR1814

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/1814

Codecov Report

Merging #1516 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1516   +/-   ##
=======================================
  Coverage   54.34%   54.34%
=======================================
  Files        3571     3571
  Lines       87947    87947
=======================================
  Hits        47799    47799
  Misses      40148    40148

Impacted Files
Coverage Δ

...azure/mgmt/batchai/models/file_server_reference.py
100% <ø> (ø)
:arrow_up:

...atchai/azure/mgmt/batchai/models/scale_settings.py
100% <ø> (ø)
:arrow_up:

...hai/azure/mgmt/batchai/models/jobs_list_options.py
50% <ø> (ø)
:arrow_up:

...tchai/azure/mgmt/batchai/models/image_reference.py
100% <ø> (ø)
:arrow_up:

...azure/mgmt/batchai/models/user_account_settings.py
100% <ø> (ø)
:arrow_up:

...e/mgmt/batchai/models/cluster_create_parameters.py
100% <ø> (ø)
:arrow_up:

...zure-mgmt-batchai/azure/mgmt/batchai/models/job.py
100% <ø> (ø)
:arrow_up:

...i/azure/mgmt/batchai/models/environment_setting.py
100% <ø> (ø)
:arrow_up:

.../models/clusters_list_by_resource_group_options.py
50% <ø> (ø)
:arrow_up:

...mt/batchai/models/virtual_machine_configuration.py
100% <ø> (ø)
:arrow_up:

... and 24 more

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 061663c...f0b749d. Read the comment docs.

null is already equivalent to nextLink in Python, nothing to do here


cookieSessionStorage does not clear sessionStateKey and sessionCodeVerifierKey after OAuth2 success

Title: cookieSessionStorage retains sessionStateKey ("oauth2:state") and sessionCodeVerifierKey ("oauth2:codeVerifier") indefinitely
Description:
There seems to be an issue with the cookieSessionStorage implementation where sessionStateKey ("oauth2:state") and sessionCodeVerifierKey ("oauth2:codeVerifier") are not removed as intended.
Steps to Reproduce:

When using cookieSessionStorage, the sessionStateKey ("oauth2:state") and sessionCodeVerifierKey ("oauth2:codeVerifier") should be cleared after a successful OAuth flow.

However, these keys are not cleared and persist in the session indefinitely.

Relevant Code:

The code that unsets the session key: Remix Auth OAuth2 - index.ts, Line 247

On strategy success, the session is reread from the request, causing both keys to remain in the session: Remix Auth - strategy.ts, Line 160

Expected Behavior:

After a successful OAuth2 flow, the sessionStateKey ("oauth2:state") and sessionCodeVerifierKey ("oauth2:codeVerifier") should be cleared from the session storage.

Actual Behavior:

The session contains both keys forever, leading to unexpected behavior and potentially security concerns.

Possible Solution:
Somehow reuse session from authorisaztion call in sucess call.

Latest version doesn't integrate directly with SessionStorage anymore so this is responsibility of the app now


fix BufferControlBlock may block all fragment handle threads leads …

…to be out of work
Proposed changes
Issue Number:  https://github.com/apache/doris/issues/16203
Problem summary
BufferControlBlock may block all fragment handle threads leads to be out of work
modify include:

BufferControlBlock cancel after max timeout
StmtExcutor notify be to cancel the fragment when unexcepted occur

more details see issue https://github.com/apache/doris/issues/16203
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.25 seconds
load time: 512 seconds
storage size:<PHONE_NUMBER>2 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230130060636_clickbench_pr_86872.html

very very great work


Support "In Question" type introduced in Xit 1.1

The specification for Xit has been updated to include a new item status: "In Question" denoted by a question mark:
[?] Create mockup for client
xit-extended does not currently support this.

If I have time, I'll try to add it myself, and will open a PR if I do! But I don't have experience with vscode extensions, so it might take me a shake - don't wait up for me lol

I have made the changes, but publishing is not working. It will be published as soon as that issue solved.


Switch from extensions API group to apps for deployments, daemonsets

Switch from extensions API group to apps for deployments, daemonsets. Similar to #2548
Expected Behavior

1.16 will disable the extensions API group by default. Calico uses it, so installations will fail once 1.16 is out (i'm testing the beta).
Current Behavior

Failure to install due to extensions API group usage.
Possible Solution

apps/v1 has been available for quite a while, but calico does not use it. Pod priority class will also replace the critical scheduling annotation. I'm happy to make the PRs, but I stared at the templated docs for a while and couldn't figure out where the content came from, e.g. https://github.com/projectcalico/calico/blob/master/v3.8/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
Steps to Reproduce (for bugs)

Build 1.16 cluster
Install any calico release

Context

I'm testing Kubernetes 1.16.0-beta.1.
Your Environment

Calico version: any
Orchestrator version (e.g. kubernetes, mesos, rkt): Kubernetes 1.16.0-beta.1
Operating System and version: Ubuntu 16.04
Link to your project (optional):

For completeness: apps/v1 is available from Kubernetes 1.9 and apps/v1beta2 is available from Kubernetes 1.8.

@alexeldeib are there particular resources you think should be updated?
I believe we have updated all Calico resources in v3.8 to use the latest stable APIs as of this PR: https://github.com/projectcalico/calico/pull/2629
Did we miss something?

You’re correct, my apologies! I was looking at daemonsets and deployments. I thought I was pulling latest, but was actually one version off. All is well :)


[dubbo-5971]fix tag router override issue #5972

What is the purpose of the change
fix tag router select wrong provider issue and delay export test delay time
fix-#5971
Brief changelog
org.apache.dubbo.rpc.cluster.support.ClusterUtils#mergeUrl
org.apache.dubbo.config.ServiceConfigTest#testDelayExport
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[x] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

@zhouhaopeng  There is some failed at the ci progress.

感觉这个逻辑不对，不应该去修改providerUrl，应该去修改consumerUrl的值。
应该修改org.apache.dubbo.registry.integration.RegistryDirectory#mergeUrl， 对overrideDirectoryUrl的赋值过程修改。 过滤掉providerUrl的Tag_key参数。
org.apache.dubbo.registry.integration.RegistryDirectory#overrideDirectoryUrl

去掉这个remove，就是为了让providr端的tag覆盖consuemr端的配置

@zhouhaopeng ci没通过啊。

暂时先关闭，如果有疑问可以重新reopen下

感觉这个逻辑不对，不应该去修改providerUrl，应该去修改consumerUrl的值。
应该修改org.apache.dubbo.registry.integration.RegistryDirectory#mergeUrl， 对overrideDirectoryUrl的赋值过程修改。 过滤掉providerUrl的Tag_key参数。
org.apache.dubbo.registry.integration.RegistryDirectory#overrideDirectoryUrl

去掉这个remove，就是为了让providr端的tag覆盖consuemr端的配置

Is provider tag config overriding consumer's  a best choice? In my opinion, consumer keeping no tag config  is better in some case that  just few provider set tag for test or other special purpose.
Thanks for your answer!

[image: image.png]
official document show provider config has a higher priority than
consumer side.
lmj<EMAIL_ADDRESS>于2020年9月15日周二 上午9:45写道：

感觉这个逻辑不对，不应该去修改providerUrl，应该去修改consumerUrl的值。
应该修改org.apache.dubbo.registry.integration.RegistryDirectory#mergeUrl，
对overrideDirectoryUrl的赋值过程修改。 过滤掉providerUrl的Tag_key参数。
org.apache.dubbo.registry.integration.RegistryDirectory#overrideDirectoryUrl
去掉这个remove，就是为了让providr端的tag覆盖consuemr端的配置
Is provider tag config overriding consumer's a best choice? In my opinion,
consumer keeping no tag config is better in some case that just few
provider set tag for test or other special purpose.
Thanks for your answer!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/dubbo/pull/5981#issuecomment-692410506, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIZUKHQ6SFTPWOMXGYRJG7TSF3BLNANCNFSM4MDTCCFQ
.

official document show consumer config has a higher priority than provider
side.
hp zh<EMAIL_ADDRESS>于2020年9月15日周二 下午5:29写道：

[image: image.png]
official document show provider config has a higher priority than
consumer side.
lmj<EMAIL_ADDRESS>于2020年9月15日周二 上午9:45写道：

感觉这个逻辑不对，不应该去修改providerUrl，应该去修改consumerUrl的值。
应该修改org.apache.dubbo.registry.integration.RegistryDirectory#mergeUrl，
对overrideDirectoryUrl的赋值过程修改。 过滤掉providerUrl的Tag_key参数。
org.apache.dubbo.registry.integration.RegistryDirectory#overrideDirectoryUrl
去掉这个remove，就是为了让providr端的tag覆盖consuemr端的配置
Is provider tag config overriding consumer's a best choice? In my
opinion, consumer keeping no tag config is better in some case that just
few provider set tag for test or other special purpose.
Thanks for your answer!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/dubbo/pull/5981#issuecomment-692410506, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIZUKHQ6SFTPWOMXGYRJG7TSF3BLNANCNFSM4MDTCCFQ
.


Support customization of "cache affecting data"

For context:
https://react-server.slack.com/archives/discussion/p1478769782000401
https://react-server.slack.com/archives/discussion/p1478826404000414
General idea: there are some advanced usages where you might want to customize the key that goes into the request data cache. One is discussed above.
This is potentially a little trickier than it sounds, because we're currently defining equality based on only the fields in _getCacheAffectingData: https://github.com/redfin/react-server/blob/master/packages/react-server/core/ReactServerAgent/Request.js#L257-L266. In the cache, we examine those at https://github.com/redfin/react-server/blob/master/packages/react-server/core/ReactServerAgent/Cache.js#L274-L278
One approach may be to generalize our equality checking, and then provide a builder method on the request chain to either modify or replace the "cache affecting data" object.

As this code https://github.com/redfin/react-server/blob/master/packages/react-server/core/ReactServerAgent/Cache.js#L417-L418 states, there is implicit dependency from Cach on Request, even though there is no explicit require/import from each other.
I suppose the "key customization" logic should resides in Cache.

The cache structure is two level. The first level is indexed by key urlPath according to _findEntry https://github.com/redfin/react-server/blob/master/packages/react-server/core/ReactServerAgent/Cache.js#L401-L412
If cache key is customizable, the _findEntry method should be updated.