Why mask is inverted in comp_range and hypot_g?

The blob's mask is marking the coordinates of the included pixels?
dert__ = frame[-1][y0:yn, x0:xn, :]
        map = np.zeros((height, width), dtype=bool)
        for seg in e_:
            for P in seg[2]:
                for y, x, i, dy, dx, g in P[2]:
                    map[y, x] = True
        map = map[y0:yn, x0:xn]

The def comp_range(blob):   # compare rng-distant pixels within blob: a component of intra_blob
is about the pixels within the blob.
What's the purpose of the map's negation?
p__ = ma.array(blob.dert__[:, :, 0], mask=~blob.map)  # apply mask = ~map
 dy__ = ma.array(blob.dert__[:, :, 1], mask=~blob.map)
 dx__ = ma.array(blob.dert__[:, :, 2], mask=~blob.map)

Is it in order to compare with adjacent border-line pixels (within higher rng)?
Probably I am missing something in the picture, but it's stated "within the blob", however wouldn't that inversion cause skipping for the pixels/patterns within the blob due to the masked array, now the items would be False?
I see the negation is done also in intra_blob.hypot_g
Could you explain its purpose as well?
Thanks!
@boris-kz  @khanh93vn
def hypot_g(blob):  # redefine master blob by reduced g and increased ave * 2: variable costs of comp_angle

  mask = ~blob.map[:, :, np.newaxis].repeat(4, axis=2)  # stack map 4 times to fit the shape of dert__: (width, height, number of params)

https://github.com/boris-kz/CogAlg/blob/d2974597577b4db27510db2accd28fc6314f4c49/frame_2D_alg/comp_range.py#L11

I recall that this is to exclude pixels that were already processed on
previous stages of intra_blob. So that only additional blob-marginal pixels
will be processed for comp_angle, and incremental-distance pixels for
comp_range (excluding already compared lesser-distance pixels. Sorry for
sloppy comments. Khanh?
On Thu, Mar 21, 2019 at 4:10 PM Todor Arnaudov<EMAIL_ADDRESS>wrote:

The blob's mask is marking the coordinates of the included pixels?
dert__ = frame[-1][y0:yn, x0:xn, :]
map = np.zeros((height, width), dtype=bool)
for seg in e_:
for P in seg[2]:
for y, x, i, dy, dx, g in P[2]:
map[y, x] = True
map = map[y0:yn, x0:xn]
The def comp_range(blob): # compare rng-distant pixels within blob: a
component of intra_blob
is about the pixels within the blob.
What's the purpose of the map's negation?
p__ = ma.array(blob.dert__[:, :, 0], mask=~blob.map)  # apply mask = ~map
dy__ = ma.array(blob.dert__[:, :, 1], mask=~blob.map)
dx__ = ma.array(blob.dert__[:, :, 2], mask=~blob.map)
Is it in order to compare with adjacent border-line pixels (within higher
rng)?
Probably I am missing something in the picture, but it's stated "within
the blob", however wouldn't that inversion cause skipping for the
pixels/patterns within the blob due to the masked array, now the items
would be False?
I see the negation is done also in intra_blob.hypot_g
Could you explain its purpose as well?
Thanks!
@boris-kz https://github.com/boris-kz @khanh93vn
https://github.com/khanh93vn
def hypot_g(blob):  # redefine master blob by reduced g and increased ave * 2: variable costs of comp_angle
mask = ~blob.map[:, :, np.newaxis].repeat(4, axis=2)  # stack map 4 times to fit the shape of dert__: (width, height, number of params)
https://github.com/boris-kz/CogAlg/blob/d2974597577b4db27510db2accd28fc6314f4c49/frame_2D_alg/comp_range.py#L11
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/boris-kz/CogAlg/issues/24, or mute the thread
https://github.com/notifications/unsubscribe-auth/AUAXGa0iv0e4rkj1uolUvgQ0NQC8qK4-ks5vY-dBgaJpZM4cCRqz
.

The blob's mask is marking the coordinates of the included pixels?

Yes, blobs are of arbitrary shapes so when slicing the global map of pixels to get blob.dert__, most likely it'll include pixels that are not belong to the blob. So I used a boolean array to indicate that.
At first I used numpy fancy indexing for in-blob computations, but later switched to masked array for less code, fancy indexing is saved for more specific computations.
In fancy indexing, computations take place where boolean value is True so blob.map is True where pixel is included in blob. Masked array, on the other hand, only carry out computations where mask is False so  it is inverted to become mask.
Actually, mask should be apply immediately when blob is formed, as blob.map have no other purpose.

Thanks! I got that the box is a bounding box, while the blob's segments are "hairy" and the inversion is to invert the processed regions and process the other ones, but I've missed the inverted behavior of masked array and fancy indexing.

Actually, mask should be apply immediately when blob is formed, as blob.map have no other purpose.

OK, and that way it could be done once in place, currently it's called for each derivative channel and creates new variables with the same content.
...
I see also a mask inversion in form_P and master_blob of generic_branch, which in form_P is done to a variable called "mask", which as far as I follow the code is the .mask attribute of the new_dert__ (and a sliced dert_) which is defined as a masked array:
def master_blob(blob, branch_comp, new_params=True):
if blob.new_dert__[0].mask.all():

Unlike the map which is a regular numpy array, but is then used to create a mask of a masked array.
def form_P_(y, master_blob):    # cluster and sum horizontally consecutive pixels and their derivatives into Ps
    rng = master_blob.rng
    dert__ = master_blob.new_dert__[0]
    P_ = deque()  # initialize output
    dert_ = dert__[y, :, :]  # row of pixels + derivatives
    P_map_ = ~dert_.mask[:, 3]  # dert_.mask?

Code-reading wise in the beginning this was confusing to me with the nt_blob dert_.map and their inversions, and now it's inverted again.
I think it would be helpful to mark explicitly in comments when a map is used for fancy indexing and when it's mask with the negated behavior, mostly for the the first-time encounter with the code.
Also if there is a sequence of negations (if done once in place initially) and then there's a hard to follow branching of inversions (haven't gone so deep yet), a flag may help avoid the map being in the wrong state.
Or then the negation should be done each time to a new variable and the original map itself should  remain in its default state.
As of intra_blob:
Is this the entry point?
def intra_blob_root(frame):  # simplified initial branch + eval_layer

Todor, entry point is frame_blobs, it calls intra_blob_root. Which is under
revision, we should talk if you want to get into it
On Fri, Mar 22, 2019, 4:02 AM Todor Arnaudov<EMAIL_ADDRESS>wrote:

Thanks! I got that the box is a bounding box, while the blob's segments
are "hairy" and the inversion is to invert the processed regions and
process the other ones, but I've missed the inverted behavior of masked
array and fancy indexing.
Actually, mask should be apply immediately when blob is formed, as
blob.map have no other purpose.
OK, and that way it could be done once in place, currently it's called for
each derivative channel and creates new variables with the same content.
...
I see also a mask inversion in form_P and master_blob of generic_branch,
which in form_P is done to a variable called "mask", which as far as I
follow the code is the .mask attribute of the new_dert__ (and a sliced
dert_) which is defined as a masked array:
def master_blob(blob, branch_comp, new_params=True):
if blob.new_dert__[0].mask.all():
Unlike the map which is a regular numpy array, but is then used to create
a mask of a masked array.
def form_P_(y, master_blob):    # cluster and sum horizontally consecutive pixels and their derivatives into Ps
rng = master_blob.rng
dert__ = master_blob.new_dert__[0]
P_ = deque()  # initialize output
dert_ = dert__[y, :, :]  # row of pixels + derivatives
P_map_ = ~dert_.mask[:, 3]  # dert_.mask?
Code-reading wise in the beginning this was confusing to me with the
nt_blob dert_.map and their inversions, and now it's inverted again.
I think it would be helpful to mark explicitly in comments when a map is
used for fancy indexing and when it's mask with the negated behavior,
mostly for the the first-time encounter with the code.
Also if there is a sequence of negations (if done once in place initially)
and then there's a hard to follow branching of inversions (haven't gone so
deep yet), a flag may help avoid the map being in the wrong state.
Or then the negation should be done each time to a new variable and the
original map itself should remain in its default state.
As of intra_blob:
Is this the entry point?
def intra_blob_root(frame): # simplified initial branch + eval_layer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/boris-kz/CogAlg/issues/24#issuecomment-475527207, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUAXGUpQaDx3LIIb3z96eYBeRR4uVyNiks5vZI4UgaJpZM4cCRqz
.

On Fri, Mar 22, 2019 at 12:59 PM Boris Kazachenko<EMAIL_ADDRESS>wrote:

Todor, entry point is frame_blobs, it calls intra_blob_root.

Aha, I see - the commented code in frame_blobs.py global part.

Which is under revision, we should talk if you want to get into it

OK, after I study the code offline for a bit more.
—

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/boris-kz/CogAlg/issues/24#issuecomment-475577032, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AWSP2L4-7PhaCQVvmmazNqllKvJhja01ks5vZLeOgaJpZM4cCRqz
.


TCP speed limitation with big file transfer

Note: the issue was created automatically with bugzilla2github tool
Bugzilla Bug ID: 99
Date: 2016-10-05 11:11:55 +0200
From: Sorin Vultureanu<EMAIL_ADDRESS>To:   Sorin Vultureanu<EMAIL_ADDRESS>Last updated: 2016-11-22 15:37:40 +0100
Bugzilla Comment ID: 186
Date: 2016-10-05 11:11:55 +0200
From: Sorin Vultureanu<EMAIL_ADDRESS>The webserver performance is limited by this, intermittently I am able to get 260MB/s of traffic using one core, other times it reduces speed because of the filling of so->so_snd and synchronisation needed.

I think this should be fixed now, can you confirm @sovu ?

wget <IP_ADDRESS>:2048/file.txt
--2017-04-10 13:01:05--  http://<IP_ADDRESS>:2048/file.txt
Connecting to <IP_ADDRESS>:2048... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: 'file.txt.16'
file.txt.16             [  <=>               ] 100.00M   381MB/s    in 0.3s
2017-04-10 13:01:06 (381 MB/s) - 'file.txt.16' saved [104857600]


Add new text file

Yep, good work! Make sure this change doesn't make it back into your master branch for future exercises.

Just to clarify, the pull request was supposed to go into master, right?
You just mean don't merge this into master on my local, right?
Thanks,
Gary
On Jul 11, 2016 10:38 PM, "Joseph Mastey"<EMAIL_ADDRESS>wrote:

Yep, good work! Make sure this change doesn't make it back into your
master branch for future exercises.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jmmastey/level_up_exercises/pull/1183#issuecomment-231929229,
or mute the thread
https://github.com/notifications/unsubscribe/AMrS5y8TWtNuz0X6HRjpIxvWD90l4Ks_ks5qUwwZgaJpZM4JJ_IT
.

Yep, exactly that.
Joseph Mastey
@jmmastey http://twitter.com/jmmastey|<EMAIL_ADDRESS>|<PHONE_NUMBER>
| http://josephmastey.com | http://leveluprails.com
On Tue, Jul 12, 2016 at 5:30 PM, Gary Cuga-Moylan<EMAIL_ADDRESS>wrote:

Just to clarify, the pull request was supposed to go into master, right?
You just mean don't merge this into master on my local, right?
Thanks,
Gary
On Jul 11, 2016 10:38 PM, "Joseph Mastey"<EMAIL_ADDRESS>wrote:

Yep, good work! Make sure this change doesn't make it back into your
master branch for future exercises.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/jmmastey/level_up_exercises/pull/1183#issuecomment-231929229
,
or mute the thread
<
https://github.com/notifications/unsubscribe/AMrS5y8TWtNuz0X6HRjpIxvWD90l4Ks_ks5qUwwZgaJpZM4JJ_IT
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jmmastey/level_up_exercises/pull/1183#issuecomment-232201850,
or mute the thread
https://github.com/notifications/unsubscribe/AASbu-Xu9S3Q_iVibWjLRiYAdZfqp_H7ks5qVBVzgaJpZM4JJ_IT
.


Implement overloadable assignment operator traits for Mut

objective
Implement the overloadable assignment operator traits for Mut.
motivation
At the moment:
#[derive(Component, AddAssign, Deref, DerefMut)]
pub struct NewType(u32);

pub fn update(mut query: Query<&mut NewType>) {
    query.for_each_mut(|mut nt| {
        *nt += NewType(1);
        nt.0 += NewType(1);
        /* nt += NewType(1); // Error: cannot use `+=` on type `Mut<'_,NewType>` */
    });
}

After implementing AddAssign on Mut, like so:
impl<'a, T, U> AddAssign<U> for Mut<'a, T>
where
    T: AddAssign<U>,
{
    fn add_assign(&mut self, rhs: U) {
        *self.value += rhs;
    }
}

We can write:
#[derive(Component, AddAssign)]
pub struct NewType(u32);

pub fn update(mut query: Query<&mut NewType>) {
    query.for_each_mut(|mut nt| {
        nt += NewType(1);
    });
}

Couldn't you just implement Deref on the components where you need it? When using a crate like derive_more, you can derive Deref and you'll have pretty much the same result without any code added to bevy.

I don't exactly what your code is doing as you don't provide definitions for the types included in your example but I played around with what I think it looks like.

Why the right had side changed? velocity: &Velocity so this PR shouldn't impact it.
Have you tried explicitly dereferencing the left hand side? It looks like your .0 is already implicitly using DerefMut I wonder if an explicit usage would allow this to compile.

Given all that your example becomes *position += velocity * time.delta_seconds() which I think is just as good as the one without the dereference. Especially since Mut does not have a trivial DerefMut (it does change tracking).
Having at least one example of a tuple struct in a unit test would also help gauge the value add by explicitly showing how it simplifies things. Although to be fair when I tried to I ran into operator hell completely ignoring this PRs changes so might not be worth the effort.

The difference is that you would go from writing this
pub fn update(
    time: Res<Time>,
    mut query: Query<(&mut Position, &Velocity)>,
) {
    query.for_each_mut(|(mut position, velocity)| {
        position.0 += velocity.0 * time.delta_seconds();
    });
}

to this
pub fn update(
    time: Res<Time>,
    mut query: Query<(&mut Position, &Velocity)>,
) {
    query.for_each_mut(|(mut position, velocity)| {
        position += velocity * time.delta_seconds();
    });
}

It's just about not having to write .0 everywhere on a struct that is just a wrapper to a number.

I understand the end goal, I was trying to unify comments about needing Deref and comments about how dropping .0 worked with this PR. In my quick testing Deref was doing nothing.
pub fn update(
    time: Res<Time>,
    mut query: Query<(&mut Position, &Velocity)>,
) {
    query.for_each_mut(|(mut position, velocity)| {
        *position += velocity * time.delta_seconds();
    });
}

Works today assuming that the "no .0" version works.

Works today assuming that the "no .0" version works.

I'm not sure what you mean here because this doesn't work today.
You can't do this without implementing the operators you are using on your tuple component. Velocity is a custom type and it doesn't implement any of that by default therefore you are forced to use .0 to modify the data.
I asked about Deref/DerefMut because I thought it could be used in this context. Trying it out locally, it doesn't seem to work, but I remember cart mentioning using this for wrapper types when he was talking about adding the derive(Component) to bevy. Which is why I brought it up.
For the record since there seems to be confusion here. The PR is about using these kinds of types:
#[derive(Component)]
struct Velocity(f32);

#[derive(Component)]
struct Position(f32);

You can't use the containing value without either using .0 or implementing something.

I'm not sure what you mean here because this doesn't work today.

Then why a PR that explicitly says "with this PR this code compiles"...

For the record since there seems to be confusion here.

The confusion was around what requirements on the end user would allow Deref to work but I don't think auto deref applies in this case as it doesn't seem to be triggering in my testing.

You can't use the containing value without either using .0 or implementing something.

With the proper operators that would allow the given example to work with this PR the example I gave would compile without this PR.
#[derive(Component)]
struct Time();
impl Time {
    pub fn delta_seconds(&self) -> f32 {
        0.0
    }
}

#[derive(Clone, Copy)]
struct Vec2(f32, f32);

impl std::ops::AddAssign<Vec2> for Vec2 {
    fn add_assign(&mut self, rhs: Vec2) {
        self.0 += rhs.0;
        self.1 += rhs.1;
    }
}

impl std::ops::Mul<f32> for Vec2 {
    type Output = Vec2;
    fn mul(self, rhs: f32) -> Vec2 {
        Vec2(self.0 * rhs, self.1 * rhs)
    }
}

#[derive(Component, Clone, Copy)]
struct Position(Vec2);
#[derive(Component, Clone, Copy)]
struct Velocity(Vec2);

impl std::ops::AddAssign<Velocity> for Position {
    fn add_assign(&mut self, rhs: Velocity) {
        self.0 += rhs.0;
    }
}

impl std::ops::Mul<f32> for &Velocity {
    type Output = Velocity;
    fn mul(self, rhs: f32) -> Velocity {
        Velocity(self.0 * rhs)
    }
}

fn update(time: Res<Time>, mut query: Query<(&mut Position, &Velocity)>,) {
    query.for_each_mut(|(mut position, velocity)| {
        *position += velocity * time.delta_seconds();
    })
}

Thus this PR isn't about remove .0 but is instead about removing the dereference of position.
While I am all for the original plan this one seems less impactful to me, especially given that some consider non-trivial derefs to be something that should be explicit.

The difference is that you would go from writing this
pub fn update(
    time: Res<Time>,
    mut query: Query<(&mut Position, &Velocity)>,
) {
    query.for_each_mut(|(mut position, velocity)| {
        position.0 += velocity.0 * time.delta_seconds();
    });
}

to this
pub fn update(
    time: Res<Time>,
    mut query: Query<(&mut Position, &Velocity)>,
) {
    query.for_each_mut(|(mut position, velocity)| {
        position += velocity * time.delta_seconds();
    });
}

It's just about not having to write .0 everywhere on a struct that is just a wrapper to a number.

Yes that's it.
Hadn't slept for two days and then spent hours learning git so I could work out how to send a second pull request and kept running out of harddrive space whenever I tried to compile anything and went on a completely dumb tangent implementing every operator even though they work already with deref / derefmut.
Updated my example to something clearer.

Thus this PR isn't about remove .0 but is instead about removing the dereference of position.
While I am all for the original plan this one seems less impactful to me, especially given that some consider non-trivial derefs to be something that should be explicit.

Yes. I got this idea from a discussion on ergonomics in the Discord about Mut where they were complaining about writing .0 everywhere and not being to deconstruct Mut types in function parameters.
It seemed like it was a good idea at the time but you are right about it only removing the deference, and that not necessarily being a good thing when it also triggers change detection.

Closing due to inactivity and apparent lack of consensus. @ickshonpe please re-open an issue if this is still relevant in 2024.


License

Hey,
Great library, any plans to add a license?

Hi, I added a license - https://github.com/drozhzhin-n-e/vue-pinch-zoom/commit/650d02f458f8a521892b58d16d560d9400bfc792

Thanks a lot! Once again - great job on the library!

@adamlachmann thank!


Fix #17767: Make Formatter::formatNumber method protected

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Tests pass?
✔

Fixed issues
#17767

Thanks!


Add DefaultListener to tcp.Mux

This change allows for TCP connections with unregistered first bytes coming in to the tcp.Mux to be passed-through to a default listener, replaying the first byte, as though the Mux was never there.
As written in the comment, this can be useful for serving HTTP debug/status info on the same port as the internal maintenance port.

👍


Any plan to add Chinese support?

I can volunteer to add country translations for Chinese.

Please submit a PR. We are always willing to add data!


Adding target to upgrade pip-tools in template

Description:
Adding new target to upgrade template pip-tools.txt when upgrading edx-cookiecutters requirements.
JIRA:
XXX-XXXX
Merge checklist:

[ ] All reviewers approved
[ ] CI build is green
[ ] Changelog record added
[ ] Documentation updated (not only docstrings)
[ ] Commits are squashed

@jmbowman I reran upgrade here. Is there anything else that needs done?

@jmbowman I reran upgrade here. Is there anything else that needs done?

Looks like there are some pylint warnings to fix, but seems ok other than that.

Looks like there are some pylint warnings to fix, but seems ok other than that.


Add Breadcrumbs

Add Breadcrumbs
Indicate the current page's location within a navigational hierarchy.

hmmm I'm not thinking to add this know but if you want to contribute check this i have some components not done yet you can build it , Design URL
:  https://www.figma.com/file/ittKeDQi6i4x5qgwmVAPhM/Meraki-UI-Community
Thanks for PR :smile: @mohanad1213


Suggestion for the documentation

I've been using NLog a lot recently but not since a long time (about 6 months). I use it almost daily at my job. I like it a lot. Simple and effective. I would like to share my experience and maybe the challenge I encountered.
First, I was always searching for a way to change the log file at runtime. Here is the solution I found and that could be added to Wiki/Examples.
using NLog.Targets;
FileTarget target = LogManager.Configuration.FindTargetByName(targetName) as FileTarget;
target.FileName = filename;
Secondly, it would be good if we could specify a different config file. I know it would be a challenge to implement this because the LogManager.GetCurrentlClassLogger is a static function and it has to know where the file is I think. Probably, we would need to call a init function before writing.
Third, for the file target, I did not find any way to create a log file for every execution and roll it. So I usually put a size or date criteria. Seems to be the same request as https://github.com/NLog/NLog/issues/213.
And last, in Wiki/Configuration File/Variable, I would find it interesting if you add a way to set variable from the code. I don't know how to do it either.
Thank you ! I don't have any expectations after this message. I mean, I know you receive probably a lot of issue. But I was interested sharing this with you because last time I did, you add it to the wiki and I was happy to contribute.

@houdelou  I don't completely understand the above post, but please make a PR to https://github.com/NLog/NLog.github.io or just edit the wiki. Thanks!
Closing it now, because it's unclear where to continue. Feel free to re-open.


Remove create-job command from external API

This is an open discussion that JD and I were having recently.  In short, create-job it would be replaced with run-pipeline <pipeline_name>. Other *-job commands would remain(?).
There are a number of reasons to potentially do this.
Currently, there are tons of "dead" output repos hanging around from every job that was run. if the same job gets run again, it creates another repo. Job outpur repos seems substantially less organized and manageable than pipeline output repos. @jdolinder is the transform for the job also saved somewhere? if so, then it's already basically a pipeline except they "live off in the ethereal pachyderm world" instead of fully being pipelines that users can later productionize and reference.
Adding run-pipeline also gives us a easy way to start a pipeline that isn't being triggered by new input data (e.g. web scraper). Similarly, if the user updates the image on DockerHub, no new data has come in, but the pipeline should clearly be rerun (without incrementality optimizations).
This idea is a little half-baked right now. We should think about it more.

Few clarifications on this, I don't think we ever want to completely remove create-job from the API, what we do want to do is obviate it's use for standard operations making it a poweruser feature.
@JoeyZwicker in your mind under this scenario what's the pipeline workflow that's the equivalent of what create-job does now? create-pipeline followed by run-pipeline? I was expecting it to just be create-pipeline which automatically runs the job once but not more (see #246). Your other justification for run-pipeline makes sense. But I think it's orthogonal so should be separate issue.
Transforms are saved inside of persist.JobInfo and persist.PipelineInfo which get serialized to RethinkDB

I was expecting it to just be create-pipeline which automatically runs the job once but not more (see #246).
I was thinking this. We don't want user to make two commands to run a pipeline.

I can't think of another strong use case for run-pipeline that not my second reason, but I feel that there is one. I'll think on it more.


edit(file = '') is broken on VS 2017

Also, issue opening markdown

https://github.com/Microsoft/RTVS/commit/49c60b01937430798d1f6218947741d875be2189


[Bug] Google API for Unity Archive page did not update for non-en languages

[REQUIRED] Please fill in the following fields:

Unity editor version: _____
Firebase Unity SDK version: _____
Source you installed the SDK: _____ (.unitypackage or Unity Package Manager)
Problematic Firebase Component: _____ (Auth, Database, etc.)
Other Firebase Components in use: _____ (Auth, Database, etc.)
Additional SDKs you are using: _____ (Facebook, AdMob, etc.)
Platform you are using the Unity editor on: _____ (Mac, Windows, or Linux)
Platform you are targeting: _____ (iOS, Android, and/or desktop)
Scripting Runtime: _____ (Mono, and/or IL2CPP)
Pre-built SDK from the website or open-source from this repo: _____

[REQUIRED] Please describe the question here:
I'm not 100% sure if the people who are working here are able to help with this, but the TGZ files under "https://developers.google.com/unity/archive#cloud_firestore_for_firebase" are not updated since version 9.1.
It would be great when this could be passed on internally and that in the future, this is updated in a timely manner.
As a workaround, copying the 9.1 link and replace 9.1.0 with 9.3.0 (or the latest version) in the URL works, so the files are there, just the website was not updated in a while.

Update: it seems that the English version of the page has the latest version, but eg. the German one stops at 9.1.

Thanks for bringing this to our attention, @Nyankoo. I've observed that the documentation you provided isn't consistent with all languages. I'll be relaying this to the team, and you may refer to this ticket for updates.

It looks like this issue has been fixed for some time now. I'll go ahead and close this thread. Thanks!


Hypothesis: Use the page description as a search query to drive related content for the page

Description
Let's test whether using the description as a search query is enough to drive relevant content. In this approach, we will only be sending the description of the page as the query parameter. Lets avoid any filtering and boosting of fields to test if the description is enough on its own.
Relevant links

Swiftype Search docs

Done with seach-research branch


Add integration testing

Add dockerfiles etc to enable integration testing of Gaia-rs

Finsihed in https://github.com/rumos-io/gears/pull/75


Tag bot does not work

The Tagbot github  action log is GitHub returned a 5xx error code.

https://discourse.julialang.org/t/tagbot-github-action-runs-successfully-but-a-new-release-does-not-show-up-on-github-releases/80770

Should be solved by adding\
permissions:
  contents: write

to the .yml file.


feat: add multilevel ens subdomain support

Env:
HOSTNAME=bzz-link.local ENS_SUBDOMAINS=true

/etc/hosts:
<IP_ADDRESS>               bzz-link.local
<IP_ADDRESS>      darkobas.bzz-link.local
<IP_ADDRESS> blog.darkobas.bzz-link.local

Testnet:
mainnet: false,
'data-dir': join(location, 'data-dir-testnet'),
'swap-enable': false,
'swap-endpoint': '',
'resolver-options': goerliEnsResolver,
bootnode: '/dnsaddr/testnet.ethswarm.org'

Sample ETH domains:
darkobas.eth -> http://darkobas.bzz-link.local:3000/
blog.darkobas.eth -> http://blog.darkobas.bzz-link.local:3000/

What about #308 ? It is trying to tackle the same right?

Manual tests:
Testnet:
darkobas.bzz-link.local
blog.darkobas.bzz-link.local

Mainnet:
swarm.bzz-link.local
bah5acgzaoa6tiahfzsngxi7wectssmk745unxzbupnfm4knkrkmgzs7ipb4a.bzz-link.local

@darkobas2 can you please let us know if this PR solves your issue? Thank you

@darkobas2 can you please let us know if this PR solves your issue? Thank you

Hi. Yes this works now for me. thank you!

Yep, I'll try to craft something tomorrow which we can use test complex behaviour.

While that would be great as well, I was more thinking along side of extending the unit tests for the Bzz.link support with the usecase of multilevel ENS domains ;-) We can tackle the complex testing in separate PR...


Build location table

Setting up and styling the locations table on the left side of the screen

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


⚠ Bofrost.gr has degraded performance

In 00924dd, Bofrost.gr (https://www.bofrost.gr) experienced degraded performance:

HTTP code: 200
Response time: 13305 ms

Resolved: Bofrost.gr performance has improved in 2da2641.


chore: Trim CI set by default

The goal of this change is to run a trimmed-down CI on PRs by default, but allows opt-in the full CI as necessary.
Specification
The CI workflow runs in “quick” mode if it was triggered from a pull request, and that pull request does not have the full-ci label set.
In “quick” mode the build matrix contains fewer jobs. At the moment only:

Linux-release, to get the PR releases.

In non-quick mode everything should be as before.
Implementation notes
I created a configure job that combines all the previous set- jobs, I guess this is faster than firing up separate jobs.
The matrix is calculated in this job; this seems to be the cleanest way to get a dynamic matrix going (experiments using exclude failed). The downside is that the matrix is now in JSON rather than Yaml syntax. The upside is that we can (later) make it’s calculation simpler, e.g. set default shell values etc.
I was not able to make it so that CI runs when the full-ci label is added, but don’t do anything otherwise. I think it can be done with another workflow listening to labeled and then triggering this one, but let’s do that separately. For now, add the label and then push (or close and reopen).
The checks
  if: matrix.build-stage2 || matrix.check-stage3
  if: matrix.check-stage3

were dead code, we did not have these fields in the matrix anymore, so I replaced them with
  if: matrix.test-speedcenter

Note that the CI step only tests that the benchmarks still work, it is not a part of the !bench pipeline. So I think we can leave that check to the merge queue.

Ah, great! Removed from quick

The downside is that the matrix is now in JSON rather than Yaml syntax.

One upside is that we could now actually factor out common configuration :) ?

That’s what I meant to say :-)

But all the comments are gone :( ?

Ups. While converting I thought “I need to put comments back in”, and then thought got lost… will fix.

As expected the PR release only has linux:
https://github.com/leanprover/lean4-pr-releases/releases/tag/pr-release-2986
I’ll rebase this on nightly-with-mathlib to see if the mathlib test job works as expected.


Client Id

I want to know how clientId is generated?
Is it unique in multiple server ( Distributed Deployment )? that means If we have 3 server and I have clientId A in server 1 , is it possible some one or me have A as client id in server 2 or 3 ?
Is it unique in time , that means If my clientId is B and I close connection is it possible later some one or me have B as client id?

Here are the codes to generate clientId in Lib/Context.php.
$client_id = bin2hex(pack('NnN', $local_ip, $local_port, $connection_id));

$locol_ip is $gateway->localIp(defined in start_gateway.php) witch is unique in your server clusters.
$local_port is internal communication port(related $gateway->startPort in start_gateway.php) witch is unique for every gateway process in one server.
$connection_id is the real socket id in gateway process witch is self-increasing when connection coming and is unique in one gateway process.
The max value for $connection_id is<PHONE_NUMBER> (unsigned int), and connection_id will be set to 1 again when it reached the max value, this will not be happen in several tens of years.
So,  clientId is unique in multiple server ( Distributed Deployment )
When a clientId is used the clientId will not be used again for a long time(several tens of years or even longer) in runtime.

Ok , Thanks


Add non ZTS build version

What happened?
I'm trying to install New Relic agent but the installation process stops with the following error:
An unsupported PHP ZTS build has been detected. Please refer to this link:
https://docs.newrelic.com/docs/apm/agents/php-agent/getting-started/php-agent-compatibility-requirements/
view compatibilty requirements for the the New Relic PHP agent.

Newest versions of NewRelic agent no longer support PHP builds with ZTS.
I figured out that you use a ZTS PHP build as base image. Using ZTS is something mandatory to Frankenphp or can you provide builds of your image without ZTS?
Build Type
Docker (Debian Bookworm)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
N/A

Relevant log output
An unsupported PHP ZTS build has been detected. Please refer to this link:
https://docs.newrelic.com/docs/apm/agents/php-agent/getting-started/php-agent-compatibility-requirements/
view compatibilty requirements for the the New Relic PHP agent.

This isn't technically possible. FrankenPHP uses threads and goroutines, which require ZTS builds.


Runtime Error in Match halfway

Thanks for your works!
When I'm running pipeline_Aachen.ipydb,  error occurs at the step Match the database images halfway.
The error information is listed as follows, my device GTX 1080Ti &&  Memory 15.6GB:
RuntimeError                              Traceback (most recent call last)
 in ()
----> 1 match_features.main(matcher_conf, sfm_pairs, feature_conf['output'], outputs)
~/anaconda3/lib/python3.6/site-packages/torch/autograd/grad_mode.py in decorate_no_grad(*args, **kwargs)
47         def decorate_no_grad(*args, **kwargs):
48             with self:
---> 49                 return func(*args, **kwargs)
50         return decorate_no_grad
51
~/code/Hierarchical-Localization/hloc/match_features.py in main(conf, pairs, features, export_dir, exhaustive)
97         data['image1'] = torch.empty((1, 1,)+tuple(feats1['image_size'])[::-1])
98
---> 99         pred = model(data)
100         grp = match_file.create_group(pair)
101         matches = pred['matches0'][0].cpu().short().numpy()
~/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
~/code/Hierarchical-Localization/hloc/utils/base_model.py in forward(self, data)
20         for key in self.required_data_keys:
21             assert key in data, 'Missing key {} in data'.format(key)
---> 22         return self._forward(data)
23
24     @abstractmethod
~/code/Hierarchical-Localization/hloc/matchers/superglue.py in _forward(self, data)
23
24     def _forward(self, data):
---> 25         return self.net(data)
~/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
~/code/Hierarchical-Localization/SuperGluePretrainedNetwork/models/superglue.py in forward(self, data)
251
252         # Multi-layer Transformer network.
--> 253         desc0, desc1 = self.gnn(desc0, desc1)
254
255         # Final MLP projection.
~/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
~/code/Hierarchical-Localization/SuperGluePretrainedNetwork/models/superglue.py in forward(self, desc0, desc1)
136             else:  # if name == 'self':
137                 src0, src1 = desc0, desc1
--> 138             delta0, delta1 = layer(desc0, src0), layer(desc1, src1)
139             desc0, desc1 = (desc0 + delta0), (desc1 + delta1)
140         return desc0, desc1
~/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
~/code/Hierarchical-Localization/SuperGluePretrainedNetwork/models/superglue.py in forward(self, x, source)
117
118     def forward(self, x, source):
--> 119         message = self.attn(x, source, source)
120         return self.mlp(torch.cat([x, message], dim=1))
121
~/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
~/code/Hierarchical-Localization/SuperGluePretrainedNetwork/models/superglue.py in forward(self, query, key, value)
104         query, key, value = [l(x).view(batch_dim, self.dim, self.num_heads, -1)
105                              for l, x in zip(self.proj, (query, key, value))]
--> 106         x, prob = attention(query, key, value)
107         self.prob.append(prob)
108         return self.merge(x.contiguous().view(batch_dim, self.dim*self.num_heads, -1))
~/code/Hierarchical-Localization/SuperGluePretrainedNetwork/models/superglue.py in attention(query, key, value)
85 def attention(query, key, value):
86     dim = query.shape[1]
---> 87     scores = torch.einsum('bdhn,bdhm->bhnm', query, key) / dim**.5
88     prob = torch.nn.functional.softmax(scores, dim=-1)
89     return torch.einsum('bhnm,bdhm->bdhn', prob, value), prob
RuntimeError: CUDA out of memory. Tried to allocate 256.00 MiB (GPU 0; 10.91 GiB total capacity; 9.09 GiB already allocated; 19.62 MiB free; 10.09 GiB reserved in total by PyTorch)
1%|          | 888/85515 [00:30<2:20:31, 10.04it/s]
Could you give some suggestions?Thanks a lot!

10GB reserved by PyTorch is not normal. Are of you really running the latest commits of this repo? I recently pushed a fix https://github.com/cvg/Hierarchical-Localization/commit/77002d67d0a7114c640788433eb76353e7b160ad that reduces the memory requirements of SuperGlue.

10GB reserved by PyTorch is not normal. Are of you really running the latest commits of this repo? I recently pushed a fix 77002d6 that reduces the memory requirements of SuperGlue.

Oh I did use the original version,now it works normally!
By the way, did you test the model based on SuperPoint-Pairs from NetVLad and covisibility constraint (Here is Sift-Pairs from Colmap model)? Maybe the result of localization can be more accurate.

Using NetVLAD for the SfM pairs should work well too, but is less robust if there are too many self-similarities.


Add support for find command

Closes #38
TODOs

[ ] Add unit tests
[ ] Better sorting of modules after filter

Codecov Report
Base: 27.00% // Head: 26.79% // Decreases project coverage by -0.20% :warning:

Coverage data is based on head (f1d9524) compared to base (651786c).
Patch coverage: 0.00% of modified lines in pull request are covered.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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

lol i think we have a lot of overlaps in our PRs

we gonna have a lot of merge conflicts lmao


Extension for integration with Tornado.

Hi,
I added an extension to work with Tornado's locale module and RequestHandler's arguments.
Kindly let me know if there is something that should improve the code.

does it support py3
wtforms-tornado
@puentesarrin

class SumForm(Form):
    a = IntegerField(validators=[validators.required])
    b = IntegerField(validators=[validators.required])

if __name__ == '__main__':
    data = {'a': [r'1'], 'b': [r'2']}
    form = SumForm(data)
    form.validate()

got some error, i cant fix it!


rename package to include xpanse

I can tackle this quickly if you want.

Thank you. we are on it.


⚠ Bofrost.be has degraded performance

In 5e4bb85, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1267 ms

Resolved: Bofrost.be performance has improved in bbe44db after 6 minutes.


Error in unpacking archive of SROIE dataset

Fixing the unpacking archive of SROIE dataset.

Test:
https://github.com/mindee/doctr/blob/51c42373bbd989808ebc23ef0709dee5a706c3ec/tests/pytorch/test_datasets_pt.py#L272
needs also an update:
(mock..., None, "sroie2019_train_task1.zip")

Same for the Tensorflow test case :)

Hey @HamzaGbada :wave:,
i saw that we have the same issue for CORD dataset are you interessted to fix this also maybe ?
Same changes would be required like in this PR :)

Hey @HamzaGbada wave,
i saw that we have the same issue for CORD dataset are you interessted to fix this also maybe ? Same changes would be required like in this PR :)

@felixdittrich92 SURE


Add libaio-dev to the e2e runner for async_io

Resolves the inference warning messages on cuda nodes. Here are the original errors which you can view in e2e action / Run e2e test job:
 [WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
 [WARNING]  async_io: please install the libaio-dev package with apt
 [WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.

Those are resolved once  libaio-dev is installed. Fedora displays the same but I haven't figured out the right incantation to get the order of operations fixed with it yet as I'm still putting together a fedora workflow on external runners. I've tested the change on external GH runners  if you want to view the results here. Ty.
Checklist:

[x] Commit Message Formatting: Commit titles and messages follow guidelines in the
conventional commits.
[ ] Changelog updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

Please update docs/gpu-acceleration.md, too.

@nerdalert feel free to remove the hold label once it's sorted!

@nerdalert the e2e.yml job was removed in https://github.com/instructlab/instructlab/pull/1651 - if you want I'd welcome updating this for the equivalent e2e AWS-based jobs

PR seems abandoned and the E2E ecosystem has changed quite a bit since this was opened - closing this.


Prevent query from running again if not necessary

Whenever I push a new screen on top of another one that has a query the bottom one also updates it's content.
However, when I pop to this screen the query is not rerun (I don't know if this was wanted).
Anyway, I think the old implementation is really bad because if I have 10 screens on top on one another (user opens a post then opens creator's page then open another post) then I will have 10 queries running all the time.
I don't know if it was intentional to depend on another part of the library to change (like if you changed the client link) but then it would have to be done in another way.
I've been using it like this and haven't found any problems so far.
Describe the purpose of the pull request.
Breaking changes

Broke ... because ... .

Fixes / Enhancements

Fixed ... was ... .
Added ... .
Updated ... .

Docs

Added ... .
Updated ... .

Codecov Report

Merging #352 into beta will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             beta     #352   +/-   ##
=======================================
  Coverage   58.55%   58.55%
=======================================
  Files          32       32
  Lines        1274     1274
=======================================
  Hits          746      746
  Misses        528      528

Flag
Coverage Δ

#graphql_client
59.29% <ø> (ø)
:arrow_up:

#graphql_flutter
29.03% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

If you can wait I can submit tests for what I'm saying.

I actually removed something similar in #110 because I thought didChangeDependencies would only be called when the GraphQLProvider (and thus client) was replaced, but apparently all widgets get didChangeDependencies called when pushing a route
I guess we need to save the a client reference in the state, and add a comparison to the conditional there

What's the hold? Is this ready yet?

@serendipity1004 Sorry, my last comment wasn't clear enough.
We need to add a reference to the Client as well as corresponding didChangeDependencies checks in Query and Mutation. Otherwise the widget observables will never reattach to a new Client, such as in the hot-reload scenario I encountered (https://github.com/zino-app/graphql-flutter/pull/110#issuecomment-427435474)

Please reword your commit messages to align with our contributing guidlines.

I agree with @micimize.  We need to store the current client in the widget and check if the client has changed in didChangeDependencies. We also have to fix Mutation and Subscription.
I have a fix in https://github.com/fredericp/graphql-flutter/commit/7c52fe7052f06f76193b600e5b8cb609f73e12f0 maybe we can update the PR or make another one.