ci:icons-for-release-please

What
ci:icons-for-release-please

Codecov Report

Merging #3062 (7a6b783) into develop (e427d9d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           develop   #3062   +/-   ##
=======================================
  Coverage     6.48%   6.48%
=======================================
  Files          246     246
  Lines        12153   12153
=======================================
  Hits           788     788
  Misses       11365   11365

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


WIP: Fixes to drawing_classifier that get surfaced by unit tests.

Closing this, since after further thought, this PR should be part of the Unit Tests PR.


docs: update install steps adding info about recursive sub-modules cloning

need adjust installation steps adding valid git cloning steps with sub-module support.
it seems like such info should be updated:
git clone https://github.com/qaprosoft/qps-infra.git ...
git clone --recurse-submodule https://github.com/qaprosoft/qps-infra.git

./setup.sh -> ./zebrunner.sh setup

done: https://github.com/zebrunner/zebrunner/commit/7ae8ed669885462401d1617a3fa051323d89a123

will be verified later.

Verified. Fixed.


500 from "Too many open files" (pipes)

Description
Regularly, the file descriptor table for the gitea process fills up with anonymous pipes, reaching soft limits resulting in 500 errors when opening a repo's page.
Gitea Version
1.16.6
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/coomdev/acea5b993a347a6395f9afb92de2fc0e
Screenshots
No response
Git Version
2.36.0
Operating System
Archlinux (kernel 5.17.5)
How are you running Gitea?
Running from the default package manager install from pacman (Pacman v6.0.1), as a systemd service (250.5).
Database
MySQL

Could you upgrade to v1.16.7 and try again?

Ah yes, I forgot to resync my repos when checking if 1.16.7 was available.
I will reopen it this occurs again (this usually takes a few days)


Re-implement the tag editing component

The tag editing component is one of the more complex pieces of the Ghost admin interface, and it was largely 'ported' to Ember, as opposed to rebuilt in a more ember-y fashion. Unfortunately, it is largely broken, particularly on mobile, and needs a bit of a rethink.
The component consists of two main pieces: 1) the suggestions popover, which uses our ember popover component and I believe is working well across all devices, and 2) the tag input, which really needs some love. Any attempt to fix bugs with the current implementation promptly results in a game of whack-a-mole as other things break. I believe it needs rethinking and rebuilding from scratch.
This issue exists as a statement of intent that we will rebuild this, either on it's own if someone feels like taking it on, or possibly as part of the work on a new editor. All known bugs with this component are going to be closed as wontfix against this issue, pending the rewrite.

This tag component will be moving to the PSM at some point in the future. It's also a horrible, horrible mess and needs rewriting to be a more independent component.
One of the major things I'd like to change, is to have the tag component manage the tag models itself. Rather than sending off all of the tags with the post to be saved, I think it is cleaner, safer and more restful to save the tags independently when they are updated.
To do this, I need to add new API endpoints, as we don't just need CRUD on a tag, but on a tag for a post. The restful way to do this would be to use a nested resource:
POST /posts/:id/tag/
Is different from
POST /tag/
In that it should create a relationship between the given tag and the given post, as well as creating the tag if it doesn't exist yet.
I did a bit of research into how to do this with EmberData, given that this is quite a complex concept, and turned up a lot of information which said that nested resources were not supported. In a conversation with @novaugust he also expressed a concern of how EmberData was meant to know the difference between creating a tag, and creating a tag for a specific post.
I turned up this solution, which it seems reasonably sane especially considering that we do want both the concepts of creating a tag and creating a tag & relating it to a post to exist in the admin UI:
http://discuss.emberjs.com/t/current-way-to-handle-nested-resources/7477/4
I'm keen to get started speccing the issues to create the new API endpoints, so that the ember work can be done, but before I do I want to check that this is definitely a feasible and sensible path to go down, or if there are other / better suggestions.
@novaugust @jaswilli @rwjblue your advise would be most welcome here!

I feel weird having two endpoints for making tags. I'd love if we could
keep it at just one endpoint, but include information on the tag if it's to
be linked to a post. So, always ping /tag, but just include an optional
post id with it if it's for a post. Meow?
On Sat, Apr 11, 2015 at 10:03 AM, Hannah Wolfe<EMAIL_ADDRESS>wrote:

This tag component will be moving to the PSM at some point in the future.
It's also a horrible, horrible mess and needs rewriting to be a more
independent component.
One of the major things I'd like to change, is to have the tag component
manage the tag models itself. Rather than sending off all of the tags with
the post to be saved, I think it is cleaner, safer and more restful to save
the tags independently when they are updated.
To do this, I need to add new API endpoints, as we don't just need CRUD on
a tag, but on a tag for a post. The restful way to do this would be to use
a nested resource:
POST /posts/:id/tag/
Is different from
POST /tag/
In that it should create a relationship between the given tag and the
given post, as well as creating the tag if it doesn't exist yet.
I did a bit of research into how to do this with EmberData, given that
this is quite a complex concept, and turned up a lot of information which
said that nested resources were not supported. In a conversation with
@novaugust https://github.com/novaugust he also expressed a concern of
how EmberData was meant to know the difference between creating a tag, and
creating a tag for a specific post.
I turned up this solution, which it seems reasonably sane especially
considering that we do want both the concepts of creating a tag and
creating a tag & relating it to a post to exist in the admin UI:
http://discuss.emberjs.com/t/current-way-to-handle-nested-resources/7477/4
I'm keen to get started speccing the issues to create the new API
endpoints, so that the ember work can be done, but before I do I want to
check that this is definitely a feasible and sensible path to go down, or
if there are other / better suggestions.
@novaugust https://github.com/novaugust @jaswilli
https://github.com/jaswilli @rwjblue https://github.com/rwjblue your
advise would be most welcome here!
—
Reply to this email directly or view it on GitHub
https://github.com/TryGhost/Ghost/issues/3800#issuecomment-91871825.

@novaugust from a wider API design view point, having another API endpoint for tags is correct, I believe, because GET /posts/:id/tags would return all of the tags for a particular post. Which is different to GET /tags/ and different to GET /posts/?include=tags which are the endpoints we have now.
Also sending the post with the tag in order to save, ends us up in a similar position to what we have now where we save all tags with the post, where the model code is playing a guessing game, saving the tag first and then trying to figure out what to do with the relationships. The intention is to make the endpoints much more explicit, if possible.

I'd love to get a bit more feedback on this. I'm working on a full spec for what the API should look like and deciding which way to go on this is blocking me a bit. Not sure if I should break it out into a separate discussion issue, I really want to get a bit of clarity on whether or not we can or should support nested resources in the API.
@sebgie I think from an API perspective it does make sense to move to /posts/3/tags/ and similarly /posts/3/next/ instead of /posts/3/?include=next. However from an ember perspective I really need a bit of insight on whether using namespaces will work for us?
Alternatively /tags/?post_id=3 could work as a filter for the tag list, but it doesn't feel right. When you put it in context with the idea that we ideally need to move to nesting for next & previous as well, it starts to look more sensible & consistent, I believe.
From http://discuss.emberjs.com/t/current-way-to-handle-nested-resources/7477/3:
adapter.set('namespace',/posts/${post.id});
Seems sane, although a bit complex.
Perhaps putting a spec up with 2 versions would be easier to frame the conversation?

I would say build the api you want to have; keep in mind that Ember won't be the only client consuming it, so we shouldn't be around it. We can make ember-data do what it needs to do to get the right endpoints =) Nesting really shouldn't be an issue; what gets weird is having nesting + first-level, but I reckon we could figure it out

I don't see any problems with /posts/:id/tags or /posts/:id/next.  We can change the tags relationship on the Post model from embedded to the "traditional" array of ids and it never needs to know about /posts/:id/tags.
If the tag editor wants to get/set the tags linked to a post we can build something to do those requests using ajax.  Even post- JSON-API 1.0 and Ember-Data 1.0 I don't think there's going to be a way to manipulate a resource's links without calling through that resource, so if we want to do that using ajax outside of Ember Data seems totally reasonable to me.

@sebgie I think from an API perspective it does make sense to move to /posts/3/tags/ and similarly /posts/3/next/ instead of /posts/3/?include=next.

There is a huge difference between the examples above:

/posts/3/?include=tags - will return post with id = 3 and include information about associated tags
/posts/3/tags/- will return all tags that are associated with the post but not the post itself

For the tag editing component I think that we'll need both versions of the endpoint. /posts/3/tags/ is used to get all tags and even more important to save the tags without sending the full post back to the server.  /posts/3?include=tags/ for the front end or third party API requests?

keep in mind that Ember won't be the only client consuming it

@novaugust :+1: :heart:

All good points, thanks :heart_eyes: I feel a bit better now about speccing this out. Watch this space!

This is now required as a part of Zelda

There are a couple of big parts to getting this done:

rebuild the component in editor
update the API to handle tag saving/adding/removing better
reimplement the suggestions system to use typeahead/whatever gets used in #5343

Reference material: It would be great if the new field could work exactly like adding tags to a story on pocket.co

raises hand for ember part
@ErisDS Once I'm done with the inline-errors stuff, I can take a crack at the ember side of things.

Whilst I think about it - one of the key things we want to do when we've got a new version of this component is introduce drag & drop re-ordering, so that's worth keeping in mind for whoever starts re-architecting this.

jquery ui has the sortable functionality built in, so probably going to use that.

After doing some basic experimentation with typeahead.js, I'm not sure how useful it will be in this case. I'm running into some style issues with it because it kind of expects bootstrap css to exist. It may be just me, but IMO I think it would be good to just use Bloodhound, which is what typeahead uses under the hood to run its search queries, and then just use the pre-existing popover component to do the suggestions.
The searching I've done seems to say it's rather difficult to customize the suggestion menu rendering, and doing so ends up re-writing a bunch of stuff. There's a limited ability to customize the classes of said suggestion menu and the read-only input used to "type ahead" and show suggestions, but I'm not sure if it would be enough in this case.

This is effectively closed by #5553 / 2c5d2d6.
#5648 is open for bugfixes / cleanup.


Should there be namespace.col for filtering?

 Not necessarily available for all implementations (e.g. Ibis)
use namespace.col('a') if you want a (possibly lazy) expression which you intend to use for filtering, like df.get_rows_by_mask((namespace.col('a') - namespace.col('a').mean()) > 0)

Longer proposal
I'm a bit concerned about some operations just not being available in lazy cases in general, such as
mask = df2.get_column_by_name('a') > 0
df1.get_rows_by_mask(mask)

~Polars~ Ibis at least doesn't allow this, filtering by a mask is only allowed if the mask is a column which comes from the same dataframe that's being filtered on - so
mask = df1.get_column_by_name('a') > 0
df1.get_rows_by_mask(mask)

would be allowed instead. ~Such comparisons are intentionally not implemented in polars, see https://github.com/pola-rs/polars/issues/10274 for a related issue (__eq__ between two different dataframes)~
I'd like to suggest, therefore, that we introduce namespace.col, so that the above could become
mask = namespace.col('a') > 0
df1.get_rows_by_mask(mask)

And then there doesn't need to be any documentation like "this won't work for some implementations if the mask was created from a different dataframe"
This would also feel more familiar to developers:

pyspark already has this:from pyspark.sql.functions import col
df.filter(col("state") == "OH")

polars already has this (same as above, but from polars import col)
pandas may add it (see EuroScipy 2023 lightning talk by Joris)
ibis has _
siuba also has _

EDIT: have tried clarifying the issue. Have also replaced Polars with Ibis in the example as the Consortium seems more interested in that

Polars at least doesn't allow this. In the implementation I've put together, filtering by a mask is only allowed if the mask is a column which comes from the same dataframe that's being filtered on

This feels like an arbitrary limitation of Polars that I haven't seen in other implementations where my inclination would be to say that this should be addressed in Polars as opposed to having the limitation built into the standard.
From my perspective, there shouldn't be two APIs to return a Column where someone should be able to write code in a single way that plays nicely in both eager and lazy executions paradigms.

I'd like to suggest, therefore, that we introduce namespace.col, so that the above could become

It looks a lot less obvious to me what this would do, namespace.col('a') > 0 is meaningless by itself.

This feels like an arbitrary limitation of Polars that I haven't seen in other implementations

It seems like that to me too. Of course if there is a good reason for this, it'd be great to surface that so we can think about how to take it into account.

From my perspective, there shouldn't be two APIs to return a Column where someone should be able to write code in a single way that plays nicely in both eager and lazy executions paradigm.

+1 for this principle. That may mean forbidding some things that don't work in lazy mode, or whatever else is needed to make things uniform across execution paradigms (eager/lazy, and distributed too).

my inclination would be to say that this should be addressed in Polars

It's intentionally not implemented, see here https://github.com/pola-rs/polars/issues/10274#issuecomment-1664342380

That may mean forbidding some things that don't work in lazy mode

As in forbidding them across the board, or noting that they may not work in lazy cases?
If the former, then I'd suggest getting rid of Column and only having namespace.col - it's a lot cleaner to work with.
If the latter, then I'll document what the expectations should be for Column in lazy cases

It's intentionally not implemented, see here https://github.com/pola-rs/polars/issues/10274#issuecomment-1664342380

That is about this not being supported:
>>> df1 = DataFrame({'a': [1,2,3], 'b': [4,5,6]})
>>> df2 = DataFrame({'a': [1,2,3], 'b': [4,5,7]})
>>> df1 == df2

That seems like a very different and broader limitation (perhaps with the same root cause?). It looks to me like we need a good description from Polars here about the types of operations that it doesn't want to support in lazy mode. Because these are not things that can't be supported in lazy mode, only choices - the reasons for which may be interesting to see.

perhaps with the same root cause

yup, this is it - we're trying to compare objects from different dataframes, and polars-lazy wants us to join them beforehand

limitation of Polars that I haven't seen in other implementations

Polars takes query optimisation to another level compared with other implementations. In dask, for example:
df = read_file(...)
df = df.select_columns(...)
df = df.rename(...)

then column selection can be pushed down to the reading stage, but all you need to do is swap operations around and the optimisation no longer happens, it now has to read the entire file:
df = read_file(...)
df = df.rename(...)
df = df.select_columns(...)

Whereas as in polars, you can chain together dozens of calls and get serious optimisations - I'd suggest this talk if you're interested https://www.youtube.com/live/aEaa1uI64zE?feature=share&t=6073

we need a good description from Polars here about the types of operations that it doesn't want to support in lazy mode

There's no Series / Column in lazy mode. If you want to use a column for filtering, or for creating a new column, or to sort by, you need to use the expressions API. Polars initially tried copying the pandas API, but then changed course because they found it limiting
In my implementation, I've worked around this by returning pl.col('a') for df.get_column_by_name('a') and keeping track of the id of the dataframe it was taken from. This is fine for now, but should probably be documented

From my perspective, there shouldn't be two APIs to return a Column

Sorry to nitpick, but just to clarify - namespace.col wouldn't return a Column, but an expression (which you can think of as a function which takes a dataframe as input and returns a column as output)

I haven't seen in other implementations

I just tried Ibis out, and it looks like they don't allow it either?
In [1]: >>> import ibis
   ...: >>> from ibis import _
   ...: >>> ibis.options.interactive = True
   ...: >>> con = ibis.sqlite.connect("geography.db")
   ...: >>> con.tables
Out[1]:
Tables
------
- countries
- gdp
- independence

In [2]: countries = con.tables.countries

In [3]: gdp = con.tables.gdp

In [4]: countries = con.tables.countries.head(5)

In [5]: gdp = con.tables.gdp.head(5)

In [6]: countries.filter(gdp.country_code=='ABW')
---------------------------------------------------------------------------
RelationError: Predicate doesn't share any roots with table

But I'm quite new to Ibis - if I've misunderstood how to use it, then sorry, and please do correct me, thanks 🙏

@kkraus14 here you'd brought up lack of row ordering / sortedness in some implementations?
If rows are unordered, then surely columns from different dataframes can't be compared, and need to have been joined beforehand?

@kkraus14 here you'd brought up lack of row ordering / sortedness in some implementations?
If rows are unordered, then surely (as far as I understand) columns from different dataframes can't be compared, and need to have been joined beforehand?

If it was allowed it would be undefined behavior since there's no guaranteed ordering. Disallowing this is a reasonable behavior.
I see the point you're making though where even if there's no defined or guaranteed row ordering, within a DataFrame there is a guarantee that the columns have the same row ordering.
Doing something like constructing two columns from lists which then implies ordering in both situations and comparing them is quite common where I'm not sure we can get rid of that as a use case to support.

Such comparisons are intentionally not implemented in polars, see pola-rs/polars#10274 for a related issue (__eq__ between two different dataframes)

The rationale given there is "They would need to block predicate and slice pushdown. I don't want that complexity in the query optimizer. Data should be joined first before it can be compared" - which is more than a little too terse for me to understand the real reason. However, I thought about it some more and translated it to a shape requirement, which I hope is correct.
For comparisons, shapes should match exactly. For lazy dataframes, the number of rows is in general unknown until the previous computation graph is executed. However, it's not like nothing is know about shapes. I think they can have 3 states:

unknown shape
unknown shape, but with a known relation to the shape of other dataframes
known shape

Once dataframes are joined, we go from (1) to (2). And only once .collect()/.compute() is called we go to (3).
Here the check needed is "are the shapes the same", which can be done with (2). And it's a needed check, because the library has to raise an exception if there's a shape mismatch. That exception could also be delayed though, I'm not quite sure what would be wrong with that.

So, it may look like an arbitrary limitation, but it allows for optimisations that otherwise wouldn't be possible

Based on experience with PyTorch, which went way further down this path: it's not that it otherwise wouldn't be possible, but more that it'd be more effort. It can be understood from first principles what's actually not possible vs. what works in principle but may be difficult. This kind of thing should be in the latter bucket, while things like "bool() forces me to have an actual Python scalar" are in the former bucket.
That doesn't mean I'm saying that Polars is doing anything wrong here - not at all, they are doing very interesting and meaningful work. But we do have to recognize that a decision like raising an exception on == is made for pragmatic reasons rather than a fundamental "this really cannot work in lazy mode". And it still matters for designing a standard to understand the difference between these things.

Doing something like constructing two columns from lists which then implies ordering in both situations and comparing them is quite common where I'm not sure we can get rid of that as a use case to support.

This is indeed common. I'm curious about the recommended solution for that in Polars, for the simple df1 == df2 case. What's the actual .join or other operation to apply there?
I have a sense that I have a lack of intuition for "dataframe as a SQL front-end", while I do have it for "a 2-D labeled array with per-column dtypes:.

within a DataFrame there is a guarantee

@kkraus14 I'm asking about the case when the columns are not within the dataframe.
Do you agree that that's not possible for ibis?
If so, we can agree that we need to either document what the guarantees are, or
consider changing the API?
This is why I'm suggesting the namespace.col syntax
It makes it clear that the columns need to be part of the same dataframe, and
that if they're not, you need to do a join
Note that Ibis also has this syntax (but for them it's _):
df.filter(_.ymax == _.zmax)

@kkraus14 I'm asking about the case when the columns are not within the same dataframe.

Yes I understand, but there's also cases when the columns are not part of any DataFrame and are just standalone columns.
I.E.
import polars as pl

# Assume these aren't just nicely defined like this but something yielded you Python lists
my_list_1 = ['a', 'b', 'c']
my_list_2 = ['c', 'b', 'a']

out = pl.Series(my_list_1) == pl.Series(my_list_2)

I've commonly seen this type of pattern in the wild and even Polars supports it in the eager implementation.

Do you agree that that's not possible for ibis?

Yes, this is not possible for Ibis currently because Ibis is an API and not an actual implementation. It was historically built for interfacing to SQL databases which don't have a concept of constructing dataframes / columns the same way that DataFrame libraries typically do. This has changed over time with Ibis backends for Pandas, Polars, DataFusion, etc.

If so, we can agree that we need to either document what the guarantees are, or consider changing the API?
This is why I'm suggesting the namespace.col syntax
It makes it clear that the columns need to be part of the same dataframe, and that if they're not, you need to do a join

I don't think we should constrain columns to having to belong to a DataFrame, nor should a column only be able to belong to a single DataFrame. I think the idea behind the namespace.col functionality you're proposing makes sense, but it would definitely add non-trivial complexity to the standard where I'd love some other opinions here.

Thanks for your response

I've commonly seen this type of pattern in the wild

Sure, is that a reason to include something? I've also seen GroupBy.__iter__ - not just in the wild, but in libraries which I used to consider potential users of the Standard - but you veto-ed it
This bring us back to #201 . I'd like to suggest:

level 0: only high-performance methods which are guaranteed to work for lazy or eager engines. No Column, no DataFrame.__eq__ or other dataframe comparisons, column operations can only be done with namespace.col
level 1: only high-performance methods, not guaranteed for all dataframes. So, there is Column, there are dataframe comparisons, and you can filter one dataframe based on the columns of another
level 2: not-necessarily high-performance methods, like Groupby.__iter__

So then support could be:

level 0: everything
level 1: excludes polars-lazy, ibis
level 2: possibly only includes polars-eager and pandas

There would also need to be some way of moving between levels - for example, to go from level 0 to level 1, polars-lazy could call .collect. To go from level 1 to level 2, cudf could interchange to polars-eager.

There's something I really need to get off my chest: I sense a general attitude of "we know what's best, we'll define the API, and if this goes against some library's design, then that's their problem". I thought the goal was to agree on a minimal API which all dataframe libraries could support, and was hoping for a more collaborative attitude
You asked pandas to support the API. I was collaborative, and have driven the  progress which has happened over the last 6 months:

first tagged version
EuroScipy2023 talk
entrypoints to the standard available in both pandas and Polars
fully-tested implementations available for both pandas and Polars
libraries (scikit-learn and skrub) trying it out

You couldn't have done this without me. You need a pandas maintainer (it's been stated many times that whatever pandas does, other libraries will follow) and I'm the only pandas maintainer you've been able to find who's been willing to enthusiastically drive progress.
It would not have made it into pandas without me - this isn't one of those "everybody's replaceable" tasks.
But my enthusiasm is at risk of waning.
I'm also a Polars maintainer, and am asking the API be designed in such a way that polars-lazy can support it. I was expecting a similarly collaborative attitude, but instead the response has generally been

calling some decisions "arbitrary limitations"
saying that polars-lazy should just implement things because the Consortium has decided that they need to be in the Standard
being OK with polars-lazy just not being Standard-compliant

I'm not saying that my API suggestions are the right ones. I might be wrong about everything.
But I am expecting a collaborative attitude, which is inclusive of Polars, especially if you're expecting that I keep driving progress

Sure, is that a reason to include something? I've also seen GroupBy.__iter__ - not just in the wild, but in libraries which I used to consider potential users of the Standard - but you veto-ed it

I shared my concerns and opinions, but I do not think I nor anyone else really has veto power. There's been multiple instances where I proposed things or expressed my opinions / experience and a decision was made to go in a different direction. If there's consensus that things like GroupBy.__iter__ should be in the standard, so be it.

There's something I really need to get off my chest: I sense a general attitude of "we know what's best, we'll define the API, and if this goes against some library's design, then that's their problem". I thought the goal was to agree on a minimal API which all dataframe libraries could support, and was hoping for a more collaborative attitude

I can't speak for others, but that is not my intended mentality or attitude in working with this group. I have been doing my best to share my experience in building performance-oriented DataFrame libraries that take advantage of hardware acceleration and all of the API challenges that I've encountered in doing so. This often comes across as me pushing back against a lot of APIs that are somewhat common, but I really just hope to drive a future in the ecosystem where hardware acceleration of DataFrames can be similar to that of arrays.
Building a minimal API that "all" (there's always going to be outliers...) DataFrame libraries could reasonably support is the goal, but in my opinion it's reasonable to push on libraries to make changes / enhancements when possible in order to deliver what we as a group think is the best user experience in using this API.

I'm also a Polars maintainer, and am asking the API be designed in such a way that polars-lazy can support it. I was expecting a similarly collaborative attitude, but instead the response has generally been

calling some decisions "arbitrary limitations"
saying that polars-lazy should just implement things because the Consortium has decided that they need to be in the Standard
being OK with polars-lazy just not being Standard-compliant

I apologize if the way I communicated things came across as making statements as opposed to my intention of asking questions / gathering information. I obviously don't have the same background / understanding of Polars and Polars-lazy that you do. A lot of the back and forth we've had has been around me trying to understand the boundaries of where things don't work because they haven't been implemented yet versus where things can't work today because of the current design of Polars-lazy versus where things will never be able to work because of the nature of lazy evaluation / computation.
Do you think it's unreasonable for things to be included in the API if there's not support in Polars-lazy today, but there's a reasonably clear path to implement them? I'm specifically talking about things where there's functionality gaps as opposed to things that fundamentally change the design of how it functions. I believe we've encountered this same situation with a couple of other libraries, i.e. cudf, and the response was generally to address the implementation in said library.

You asked pandas to support the API. I was collaborative, and have driven the progress which has happened over the last 6 months:

first tagged version
EuroScipy2023 talk
entrypoints to the standard available in both pandas and Polars
fully-tested implementations available for both pandas and Polars
libraries (scikit-learn and skrub) trying it out

You couldn't have done this without me. You need a pandas maintainer (it's been stated many times that whatever pandas does, other libraries will follow) and I'm the only pandas maintainer you've been able to find who's been willing to enthusiastically drive progress. It would not have made it into pandas without me - this isn't one of those "everybody's replaceable" tasks. But my enthusiasm is at risk of waning.

I don't think anyone has said it nearly enough, but thank you for all of the work you're doing related to this effort @MarcoGorelli. You are absolutely correct this wouldn't be possible without you and everything you're doing.

This bring us back to #201 . I'd like to suggest:

level 0: only high-performance methods which are guaranteed to work for lazy or eager engines. No Column, no DataFrame.__eq__ or other dataframe comparisons, column operations can only be done with namespace.col
level 1: only high-performance methods, not guaranteed for all dataframes. So, there is Column, there are dataframe comparisons, and you can filter one dataframe based on the columns of another
level 2: not-necessarily high-performance methods, like Groupby.__iter__

So then support could be:

level 0: everything
level 1: excludes polars-lazy, ibis
level 2: possibly only includes polars-eager and pandas

There would also need to be some way of moving between levels - for example, to go from level 0 to level 1, polars-lazy could call .collect. To go from level 1 to level 2, cudf could interchange to polars-eager.

I have concern we're going to be adding a ton of complexity for users of this API if we go this route and it will result in either people only using level 0 and then moving to a library of choice like Pandas or Polars when they need to break out of level 0, or writing code that only works with level 2 libraries.
I took a pass and these are the APIs I identified where there's maybe some question of how to handle for a lazy implementation:
DataFrame APIs:

shape --> Looks like this isn't supported by Polars-lazy today? It looks like the number of columns isn't lazy but the number of rows is. Any ideas here? I think we could imagine this as a Tuple of "LazyScalar" objects?
get_column_by_name / col --> Can we support both lazy and eager execution in a way we're happy with in a single function?
insert_column --> Polars-lazy allows doing this via with_columns, but as far as I can tell only allows doing it with expressions from the same table, literals, or pl.Series objects which aren't lazy?
get_column_names --> Outside of Polars-lazy, you could imagine a lazy library choosing to have actual column names be lazily resolved as well. Do we wish to support that? I.E. something like one hot encoding yields a data dependent number and names of columns.
sorted_indices / unique_indices / any_rowwise / all_rowwise / etc. --> What type should this return? Polars-lazy doesn't have a Column class today and returns a 1 column DataFrame.
__eq__ (and other binary operators) --> Polars-lazy and Ibis don't support these today across different tables, could they / should they? How much value do these operations add at the DataFrame level versus the column level?
to_array_object --> Any concerns here? Does this trigger computation for something like Polars-lazy which presumably doesn't have a corresponding lazy array implementation (please correct me if I'm wrong)?

Column APIs:

__len__ --> Does Python allow ducktyping this? Looks like Polars-lazy has a len() function that returns a 1 row column in this case currently? Would feel very reasonable to me to abandon __len__ if it can't be ducktyped and just have a len() method or just use shape.
get_value --> Some kind of "LazyScalar"? Looks like Polars-lazy returns a 1 row column in this case currently (via pl.Expr.take)?
any (and other reductions) --> Some kind of "LazyScalar"? Looks like Polars-lazy returns a 1 row column in this case currently?
to_array_object --> Same as DataFrame

Based on this list, the biggest things that stick out to me are:

How to handle scalars, whether we want an explicit collect type of method, or whether they should allow computation to implicitly happen through methods like __int__ and __bool__. Lazy and eager implementations starkly differ in this regard. We could also just punt on Scalars entirely and just yield Columns and force the user to call explicit APIs to get a scalar out of the Column.
Inserting Columns into DataFrames / constructing DataFrames from Columns, where it looks like Lazy and Eager DataFrames differ quite a bit in this regard again. I personally think the restrictions that Polars-lazy and Ibis enforce here are quite reasonable and are very friendly from a performance perspective, but there's definitely a lot of code out there that uses the eager paradigms.

Thanks for your response
If there's no support in Polars lazy for something, and there is a reasonable path forwards, then it's reasonable to include it. For example, I'm working on a PR to sort out the return dtypes for __pow__.
What I don't think is acceptable is to include something which has been explicitly rejected by Polars. The most glaring example is LazyFrame.__eq__ : https://github.com/pola-rs/polars/issues/10274#issuecomment-1664342380, so I have a PR to remove this from the Standard here: https://github.com/data-apis/dataframe-api/pull/242
Here's what rubbed me the wrong way: if the Consortium wants to dispute a library's decision to intentionally not implement a feature, then the onus is on the Consortium to articulate why that library should implement that feature. Not the other way round.
What's the benefit of allowing df1 == df2? Do we have a single use-case in mind?
I suggest we start by resolving this one. Then, we can move on to the rest

it would definitely add non-trivial complexity to the standard

I've tried putting together a proposal: https://github.com/data-apis/dataframe-api/pull/247
It's a lot simpler than I was expecting, and adds very little complexity. I'll give a demo at today's call, just sharing in case anyone wanted to take a look beforehand


runtime: remove llvm/DataTypes.h, llvm-c/DataTypes.h

Inline the standard headers that they included and remove the extra
include path.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @mikeash @jckarter

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - fd5924e6a58a753f9c23fe2e90f502a75caf11e6

Build failed
Swift Test Linux Platform
Git Sha - fd5924e6a58a753f9c23fe2e90f502a75caf11e6

@swift-ci please test

@swift-ci please test

@swift-ci please test Windows platform


Trouble Getting the tinymce css to show in the Django Admin

Hey there.  As the title suggests, I am having trouble seeing the tinymce's associated CSS files.
In order to help diagnose this problem, let me give you some background on my project.  To start I pip installed the django-tinymce into my project.  From there, I added 'tinymce'  to my installed_apps in my settings.py and updated the urls.py accordingly.  Also in my settings.py I added the code listed beneath this message.  On my Post model I added a field, content = HTMLField().  So when I go to the admin in the browser, and navigate to the model in question - all the fields render.  Except the tinymce editor does not load the corresponding CSS files.
http://debug.example.org/tiny_mce/themes/advanced/skins/default/ui.css
http://debug.example.org/tiny_mce/themes/advanced/skins/default/content.css
http://debug.example.org/tiny_mce/plugins/spellchecker/css/content.css
Any and all help would greatly be appreciated.  Thanks for reading.  Take care and have a good day.
Sincerely,
JG
xxxxxxx
STATIC_JS_DIR = os.path.join(STATIC_ROOT, "js")
TINYMCE_JS_ROOT = "../static/django-tinymce/tinymce/static/tiny_mce"
TINYMCE_JS_URL = os.path.join(TINYMCE_JS_ROOT, "tiny_mce.js")
TINYMCE_DEFAULT_CONFIG = {
'plugins': "table,spellchecker,paste,searchreplace",
'theme': "advanced",
'cleanup_on_startup': True,
'custom_undo_redo_levels': 10,
}
TINYMCE_SPELLCHECKER = True
TINYMCE_COMPRESSOR = True
xxxxxxx

Also in addition to the above statement, I moved the "django-tinymce" folder inside the static directory.

What helped in my case is to add underscore, as it is in the folder
TINYMCE_JS_URL = STATIC_URL + 'tiny_mce/tiny_mce_src.js'
mind the tiny_mce/ not tinymce/


ATLAS-3098: Missing getTypesDef with AtlasRelationshipDef param in AtlasTypeUtil.

In AtlasTypesDef.java Atlas team introduced the AtlasTypesDef .ctor with the List parameter but in AtlasTypeUtil the getTypesDef method does not accept 5 parameters.
I think we can use directly the AtlasTypesDef contructors so this Bug in my opinion is a minor issue. Any way I submitted the pull-request

Resolved by ATLAS-3099.


Fix bug that made final sigmas appear as medials

Thanks to @jcuenod it was detected that the BETA to CSV Unicode converter failed to convert final sigmas when the BETA code was immediately before a closing square bracket (],) which happens with some variants (issue #5). This is what Jude 5 looked like before this fix:

{Ν ὑμᾶς ἅπαξ τοῦτο ὅτι ὁ κύριος > [ὑμᾶσ] πάντα ὅτι [ὁ] κύριος ἅπαξ }

After this fix, this is what it looks like:

{Ν ὑμᾶς ἅπαξ τοῦτο ὅτι ὁ κύριος > [ὑμᾶς] πάντα ὅτι [ὁ] κύριος ἅπαξ }

Notice that the medial sigma in [ὑμᾶσ] was replaced by the correct form of the letter.
The strategy we used to fix this unwanted behaviour was to add a space between each word and any closing square brackets when the final letter is a sigma (an s in BETA code) before the conversion to Unicode. After the conversion is done, we remove the space.
We additionally include a commit that reformats the converter.py script with the black utility, to improve the readability and uniformity of the code.
Closes #5

@emg Hey Ulrich, I'm bumping this in case the notification got buried in your inbox again :joy:

@emg Hey Ulrich! Did you get a chance to review this PR?

Hi.  I was trying to merge #11 into this, and by sheer chance, both our patches touch Mark 16:8.
https://github.com/byztxt/byzantine-majority-text/blob/master/csv-unicode/with-variants/MR.csv#L667
Unfortunately, it seems this patch slightly breaks the formatting in this one place: [[ ""σηορτερ ενδινγ"" ]] -> [[ ""σηορτερ ενδινγ""]] - a space is lost before the ] at the end.
I think a workaround for this would be to replace ']' with '  ]' (two spaces before).
'  ]' doesn't occur anywhere in the beta code, so two spaces can be added and removed without breaking anything.

I can take a look at this next week and update the pull request. Thanks a lot @countingpine for your brilliant contributions!

Yes, @countingpine – thanks a lot for your work. I appreciate it, too.
And thanks for your attitude, @normansimonr – thanking @countingpine and praising his contributions. That is the spirit of encouragement. I commend you for it.
Thanks, @normansimonr – I look forward to your looking into it, and I look forward to your PR.

Thanks for your kind words everyone.
On another note, I've just realised: the English characters - "shorter ending" - probably shouldn't be translated at all!
I'm not sure of the best way to represent that in the final text.
But to simply keep the English words, the best way would probably be to swap it for something unique and unchangeable, and swap it back again after conversion.

Thanks for catching this, @countingpine. Excelent work:

On another note, I've just realised: the English characters - "shorter ending" - probably shouldn't be translated at all!

I'm not sure of the best way to represent that in the final text.
But to simply keep the English words, the best way would probably be to swap it for something unique and unchangeable,    and swap it back again after conversion.

Yes, that is one of the techniques for doing this. Both transformations must be done in code, of course, without the intervntion of human hands. I think that's what you mean, right?
Could I ask you to find out whether there are any other instances of English characters that need this kind of transformation, and document your findings here?
Then we can figure out who writes the code.
Many thanks, everyone! I am enjoying the conversation with you. And I highly appreciate your help.

Thanks, I'm enjoying this conversation too.
I myself am only really starting to learn Greek (which is how I stumbled upon this project), but I'm happy to help where I can.
I've done a search for " marks, and they appear in three places:

Mark 16:8 ("+" [[ "shorter ending" ]])
Rom 16:23 (a)delfo/s "+ [14.24-26]").
Rev 4:8 (a(/gios "9x")

It looks like the 2005 PDF keeps all three unconverted, so I would say the quotes are supposed to indicate "literal" sections of text.
I've also found these strings appearing in Revelation: _AX, _DAD, _IB, _KD, _MB, _RMD, _XC.  The PDF simply converts these to Greek like everything else, so that might not need any special handling?
I can open one or two bug reports for them if that would be helpful.  I think fixing either (if needed) would be too non-trivial to tag onto this Pull Request.
I think now the best way to conclude this particular PR is to fix the sole, minor regression (the removal of the space between ending"" and ]]), and merge with the main branch, and maybe open a bug report or something to track things that shouldn't be translated.
I can do the merge and the minor fix if that would be helpful, but of course this is @normansimonr's good work, and I don't want to presume to step on his toes.

@countingpine Awesome, great research! Yeah, feel free to update this PR. I agree that the issue about the stuff that must be left untranslated should take its own PR. BTW, we're thinking of creating a TEI-XML version of the ByzText as well (see #12.) Would you like to join us in giving it a shot?

@countingpine Yes, awesome research, dude! You PE/TRA! :-). (Or perhaps, being a verb, one would say "SU\ PE/TREIS". Although I am not sure that the noun PE/TRA was ever made into an actual Greek verb in spoken parlance, though doubtless it could be done ;-) .)
Yes, I agree with @normansimonr – @countingpine, please add new issues for the things to leave untranslated. Many thanks.
I also think we should add the missing documentation :-). Things like the literal strings and the _XC abbreviations should be documented somewhere. I don't think they are documented at present. I will open an issue for this.

Hi.  I've uploaded a patch at https://github.com/countingpine/byzantine-majority-text/tree/pr6 .
It applies black to the master branch (incorporating my last patch) to bring it in line with the PR here.
It adds a fix for the  ] issue to this PR.
Then it merges both, so it is a child of both master and this PR.
I don't know if it can be applied from here - maybe if @normansimonr pushes it to his master - but otherwise I can just make a new PR, and obsolete this one.

@countingpine Brilliant! Yeah, I guess the most hassle-free way to do it is just deprecate this one and make a new PR from your fork. Then we can review and @emg can merge afterwards.

Closed in favour of #14


improvement: change submitRing to external

Currently it is 'public', changing it to 'externa'l will avoid copying argument data to save some gas.

I'm getting this error after the change.

/Users/d/Projects/loopring/protocol/contracts/LoopringProtocolImpl.sol:224:25: CompilerError: Stack too deep, try removing local variables.
        uint ringSize = addressList.length;

Don't know how to resolve. Need some help from the community.

The different behaviour between public and external seems to be that array parameters in external functions take up 2 slots on the stack instead of 1 for public functions.
I'm not convinced this is going this save any gas, at least not in the way the data is used now. All arrays are passed to internal functions, which need all data to be in memory. So I don't think there's going to be a case where data would only be read from the calldata. Though if more functionality is placed inside the submitRing function it could help I suppose.

Thank you. I'm not sure about if there is any gas savings but what makes me curious is why it doesn't compile when I change it form public to external. Maybe because  array parameters in external functions take up 2 slots on the stack instead of 1 for public functions.?

Yeah, that's right. That's the behaviour I see by experimenting a bit. I did not find anything yet in the documentation nor have i checked the assembly. I'll get back to you on this if I find out exactly why the extra stack space is needed.

There's a limit of 16 local variables on the stack.

But I didn't introduce addition local variables...

Local variables also include function arguments and return values. A bit confusing, I know, but that's how everyone seems to define it. Probably doesn't matter for Solidity what type of variable it is, they all get pushed on the stack.


[accumulo] README was incorrectly referencing aerospike-binding

Not sure this is really worthy of a pull-request, but the accumulo README(s) were (presumably) incorrectly referencing the aerospike-binding.

Thanks for the catch!


Better handling of params from CLIMAParameters

We may want to extract the constants from the earth_param_set = EarthParameterSet() and store those, rather than extract them each time.
E.g. right now we have a struct parameter = Parameters(;.... earth_param_set = earth_param_set), and then to get e.g. rho_liq we need to
using CLIMAParameter.Planet: rho_liq
rho_liq = rho_liq(parameters.earth_param_set)

instead of
rho_liq = parameters.rho_liq

or
rho_liq = parameters.global_constants.rho_liq

see also:
https://clima.github.io/CLIMAParameters.jl/previews/PR63/parameter_structs/

TO do: decide if we should store k_om, k_quartz, k_minerals, similar for heat capacities, as useful for computing k_solid.
Also - should we store c_ds instead of rhoc_ds? just needs to be clear...

Add documentation on parameters

Make sure other models using param struct make sense.


Don't force redundant update on cert_expiry startup

Description:
Cert Expiry sensors are updated when the entities are created, but also a redundant call when HA finishes starting up. This removes the latter update as it was unnecessary and potentially causes issues.
Related issue (if applicable): may fix #26740
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

I'm guessing the receiving server didn't like to accept multiple connections from the same source in quick succession, rejecting the new connections and causing the entity to fall into a bad state. It sounds like they updated fine at the next 12 hour update.

Yeah I think we shouldn't update twice close like we do now. But which update should we remove?

The self-connecting scenario is one I hadn't considered. Probably should swap back to updating when HA is fully started. I'll do that shortly.

Yeah. Let's create the entity as available and and remove the update during entity addition. Keep the update on home assistant start.
The entity will then be created with unknown state. When the first update happens, either on home assistant start or 12 hours after creating the entity, the entity will get correct state.
I guess we could add some more complex logic in async_added_to_hass that checks the run state of home assistant. If it's already running, we schedule an update immediately. If home assistant is setting up, we schedule an update on home assistant start event.

To solve the problem with importing the config yaml, we could schedule the import on home assistant start event.

Do you want to change config yaml import scheduling in a separate PR?

I removed that since it didn't seem necessary anymore with the conditional updates when the entities are added. Do you think something is still needed there?

You're right, I forgot the import would attempt to validate the configuration. If it was checking itself this would cause the import to fail. Updated the import step to delay until HA is fully started.


check if status is not nil before deciding that all hosts have responded

Currently, the total == responded line in query.go will resolve to true if the Fleet server has not returned any data, as 0/0 hosts are returning any information. However, this may not necessarily mean that Fleet should exit, as the values also resolve to zero if the websocket responses have not been return yet. Forcing status to also be not nil allows us to keep the connection ongoing until responses are returned.
This contribution was co-researched with @4ndygu

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Héctor Navarro Martín seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @zwass! Is it possible for us to submit under an Apache 2.0 license? We're asking as this is committed under our work identities, and it may be easier for us to commit using that rather than getting legal to review and our lead to approve the CLA. If not, we can move forward with that other process :).

The project requires signing the CLA in order to accept submissions. I know this can be an onerous process and we appreciate you taking the time to get it approved.

Due to pending CLA, I am replacing this with #2184.


Windows git bash child processes see wrong PATH environment variable

Nevermind, this is the website issues tracker not the git issues tracker. Might want to make that clearer on the website and offer a link to the git issues tracker...

seems this should be closed @peff . solved by introducing the issue template https://github.com/git/git-scm.com/pull/944


Remote Command Implementation Agnostic

Removed support for akka remoting
Updated signatures to allow for custom remoting logic
Unit tests for both local and 'remote' cases
Joda time to latest

Note that the changes to support SNAPSHOT builds are in this PR now too


Crashes

I'm getting crash after implemeting i.e after disabling the animation and other shifting stuff
bottomNavigationView.enableItemShiftingMode(false);
bottomNavigationView.enableAnimation(false);

same here can anyone solve this problem. Here is the full problem.
https://stackoverflow.com/questions/51618340/bottomnavigationviewex-null-pointer-exception

It is possible that this solution is suitable for disabling the animation, but not for disabling the shift mode.

@DhruvUpadhyaya @bimsina Fixed in #118

You can as well use the fix on our fork:
implementation 'com.github.stanwood:BottomNavigationViewEx:41e335d'

I am sorry to be late. Please use version 2.0.0 if support lib >= 28.
Version 27 is abandoned.
For AndroidX, please add config into gradle.properties
android.useAndroidX=true
android.enableJetifier=true


Open DropdownMenu with two different buttons

I have a very simple dropdown menu. By clicking on the NewIcon button, the user sees a drop-down menu. Everything is simple here.
    <DropdownMenu.Root open={isOpen} onOpenChange={setIsOpen}>
      <DropdownMenu.Trigger>
          <NewIcon/>
      </DropdownMenu.Trigger>

      <DropdownMenu.Portal forceMount>
              <DropdownMenu.Content>
             ........here some components
              </DropdownMenu.Content>
      </DropdownMenu.Portal>
    </DropdownMenu.Root>

However, I would like to also call this dropdown menu with another button (which is located in another component) on the same page.
For example, below is another component that renders the "Edit information" button. Tell me how to click on this button to open the dropdown menu
   <div>
    <Button>
       Edit information
    </Button>
  <div>

You can create a content component to reuse across multiple buttons
const SomeDropdownContent = () => {
              <DropdownMenu.Content>
             ........here some components
              </DropdownMenu.Content>
}

//

    <DropdownMenu.Root open={isOpen} onOpenChange={setIsOpen}>
      <DropdownMenu.Trigger>
          <NewIcon/>
      </DropdownMenu.Trigger>

      <DropdownMenu.Portal forceMount>
          <SomeDropdownContent />
      </DropdownMenu.Portal>
    </DropdownMenu.Root>

//

    <DropdownMenu.Root>
      <DropdownMenu.Trigger asChild>
          <Button>
             Edit information
          </Button>
      </DropdownMenu.Trigger>

      <DropdownMenu.Portal forceMount>
          <SomeDropdownContent />
      </DropdownMenu.Portal>
    </DropdownMenu.Root>


Add base structure for dev-1.0.0

This PR is to keep track of the work which is related to #36
This PR will add some basic structures like:

base files for Documentation site [#45]
clean-up of directories
prepare for moving helm-chart out of this repository [#43]
clean-up of GoLang code

Since this is serves the base structure go get started could you review the changes @rimusz?


Version missing in 2.0rc2

Expected behavior and actual behavior.
geoalchemy2 fails because the version comparison fails:
if parse_version(shapely.__version__) < parse_version("1.7"):  # pragma: no cover

Shapely doesn't provide a usable version:
>>> shapely.__version__
'0+unknown'
>>> shapely._version.get_versions()
{'date': None, 'dirty': None, 'error': 'unable to compute version', 'full-revisionid': None, 'version': '0+unknown'}

shapely.__version__ should return 2.0rc2.
cfg.versionfile_source in _version.py is wrong:
$ grep cfg.versionfile_source shapely/_version.py
    cfg.versionfile_source = "pygeos/_version.py"
        for i in cfg.versionfile_source.split("/"):

pygeos/_version.py does not exist in the source tree.
Steps to reproduce the problem.
On Debian unstable with experimental sources:
apt install -t experimental python3-shapely
python3 -c 'import shapely; print(shapely._version.get_versions())'

Operating system
Debian unstable
Shapely version and provenance
2.0rc2 Debian package.

versioneer doesn't work for package builds, it doesn't provide a way to set the version like setuptools_scm:
https://github.com/python-versioneer/python-versioneer/labels/fallback

I was scheming to propose setuptools_scm a few weeks ago (https://github.com/mwtoews/shapely/tree/setuptools-scm), but held back as to accumulate too many changes / delay any further. Is it worthwhile pushing this thru for another rc?

Yes, rc3 should include a fix this issue.
The changes in #1654 may suffice.
The _version.py in the GitHub tarball should be correct then.

Yes, certainly will do a rc3 with this fix

@sebastic I suppose the reason you run into this is because you use the github created archive for debian packaging? (for example on https://github.com/shapely/shapely/releases/tag/2.0rc2, the "Source code (tar.gz)" download link, not the sdist that was uploaded (first link "shapely-2.0rc2.tar.gz")).
Is the reason for that because there are additional files you need that are not included in the sdist?
(I would always recommend to start from the sdist if possible, since that is the official release artifact, and also has proper versions without relying on the file name)

The tag tarball is present for all GitHub projects, only a subset also publish release assets.
The generated files in sdist are of little value for Debian packages, those are regenerated during the package build. Many projects are also not good at maintaining MANIFEST.in, making the sdist unusable due to missing test files, etc.

Makes sense!

The generated files in sdist are of little value for Debian packages

I don't think there are generated files in our case (except for the _version.py file in question, where it is actually useful)

These are the generated files in the release tarball:

PKG-INFO
shapely.egg-info/*

The package clean targets removes them before starting the build where they are regenerated when using setuptools, and with the use pybuild-plugin-pyproject PEP517 .dist-info is generated instead.

Ah, OK, I was thinking about generated files in the package itself (eg generated C files that some packages might include).
In any case, 2.0 rc3 has been ragged!

Good to hear, thanks!


Suppress -Wunqualified-std-cast-call

-Wunqualified-std-cast-call was added to Clang in
https://reviews.llvm.org/D119670, which using this project when building
with -Werror. This change ignores this error as a stopgap; eventually
the unqualified std::move() instances should be qualified.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Upon further reflection, it's easier to just fix these.


GenerateLDFlags function doesn't work on OSX

The getBuildDateTime helper function, which is called by mage.GenerateLDFlags, doesn't work under OSX. The date command is a little bit different on OSX than on Linux and doesn't support the -d flag, therefore on OSX we get this error when trying to use mage.GenerateLDFlags: date: illegal option -- d
The exact problem is here: https://github.com/kubernetes-sigs/release-utils/blob/1bf6b4c5d954414cf0485ec5006d7bd020c956f3/mage/version.go#L62

Hm, we can probably generate the date from native golang libraries other than relying on GNU date.

Already created a fix for it using GNU date: https://github.com/rappizs/release-utils/commit/e92530446975addaad9e949ad1d584a91083979e, but I agree that maybe some native go solution would be better.

Yeah, like this: https://github.com/kubernetes-sigs/release-utils/pull/91

Thanks @saschagrunert!


Repro and fix for #5740 - handle git sync of empty repositories/no previous .insomnia folder

changelog(Fixes): Fixes an issue where cloning repositories that are empty or previously unused by insomnia didn't suggest users to create an empty insomnia project.
TODO

[x] reproduce issue in a smoke test
[ ] add a fix/workaround

Investigation
Seems that when we added routes for git we didn't re-include the previous code paths that handled the "empty repo" or "repo without previously a .insomnia cases.
const noDocumentFound = (gitRepo: GitRepository) => {
  return (dispatch: any) => {
    showAlert({
      title: `No ${strings.document.singular.toLowerCase()} found`,
      okLabel: 'Yes',
      addCancel: true,
      message: `No ${strings.document.singular.toLowerCase()} found in the repository for import. Would you like to create a new one?`,
      onConfirm: () => dispatch(createWorkspaceWithGitRepo(gitRepo)),
    });
  };
};

// (...)

// If no workspace exists, user should be prompted to create a document
if (!(await containsInsomniaWorkspaceDir(fsClient))) {
  dispatch(noDocumentFound(repoSettingsPatch));
  trackSegmentEvent(SegmentEvent.vcsSyncComplete, { ...vcsSegmentEventProperties('git', 'clone', 'no directory found'), providerName });
  return;
}

Closes #5740

Closing this one in favour of #5779


Is there any way to use shared tensorflow lite library on Android to reduce the aab size?

MediaPipe Solution (you are using): Face Detection\Face Mesh
Programming language : C++/Android Java
Are you willing to contribute it (Yes/No): Yes

I have a use case that need to use tensor-flow lite shared library from maven in Android, but I also want to use the Mediapipe solutions. Is there any compile option that can compile the Mediapipe with shared tensor-flow lite library? Thank you.

Hi @junnikokuki ,
Did you get a chance to check this closed issue https://github.com/google/mediapipe/issues/77

Yes, but my request feature is totally different. Currently the Mediapipe will compile the tensorflow lite lib into the jni so file, but I want to use the tensorflow lite library in a shared way. That is Mediapipe (and other model using tensorflow lite library) can use a shared tensorflow lite so file.

Unfortunately, It's currently not supported. We do see this as a great feature to have and will prioritize this work.

@junnikokuki , we don't have this shared feature as of now, we will share with internal team as a feature request.

@junnikokuki , we don't have this shared feature as of now, we will share with internal team as a feature request.

@sureshdagooglecom Is this feature under implementation? Could you please let know the ETA for the same?


While statement require a do keyword after conditions

Thank you for the PR!
I think we need some more evaluation test on vm/evaluation_test.go for success/fail in while and do statements.
Any suggestions? @st0012

@hachi8833 We already have vm's success tests for while statement. And if we are talking about the syntax failure, I don't think we should test that in vm

@amohamedali great job! thx 😄


Normalization range points not allowing custom points for data set

Hello,
I am using Larch version 0.9.71 XAS viewer (GUI).
I load in a data set (see image attached, edit: data is not for In L2 but it usually defaults to this) and start the normalization process. The normalization energy range only moves by the increments (~4 eV increments) allowed using the interface up and down arrow. As shown in the image, the default value is 2.99 and it allows manually input lower values, but not values higher than 2.99 neither with the arrows nor user input values. This issue persists with other data groups within similar energy range, and leads to some weird/very slanted normalized mu(E) as the only resulting option independently from the normalization points.
My aim with this data set is to do Linear Combo. Thus, LC would use this distorted Normalized or Flattened arrays for fitting. Thank you.

@mrvejar The arrows on the normalization ranges should increment the energies by 5 eV.  In general, you should be able to enter any specific value you want.
However, the normalization range is limited:  the end value ("norm2") does need to be in the data range, and the first value ("norm1") needs to be at least 10 eV below that.   I guess that difference could be reduced, but I'm not sure it is really a good idea.
With only 20 eV of total energy range, the "standard" pre-edge and normalization procedures in XAS Viewer are going to be pretty error-prone.  There really is not enough of a pre-edge measured to fit a line to, and it is not at all clear to me that "extrapolate intensity well past main edge" to get a normalized spectrum would be possible.
I sort of think you may need to come up with some other methods for baseline removal and scaling.

I see, thank you for that explanation. In this case, the ~20 eV range data is all I have to work with (Pu M4 edge), for LCF. Could this difference be reduced below 10 eV? or maybe allow for the "raw" array to be used for LCF? I have used Larch LCF for L3 edge data and it works amazing. In fact, I really like that I can do multiple fits and sort them. Hence, I would like to use Larch for LCF for this M4 edge data as well.


Add MatrixFTCoronagraph to docs and release notes

@neilzim let's remember this for the release

Right, just to clarify - inside docs/ we want a statement at the top of relnotes.rst under 0.4.1, and a new .rst for the MatrixFTCoronagraph subclass?

Sure that would work. Looking at this now I see the SemiAnalyticCoronagraph docs (which are very brief) are a mention of its existence in classes.rst and then an example in examples.rst. So you could also do that. But I do like the idea of a new page. Maybe we make a 'coronagraphs.rst' and we can put there some discussion of both the SemiAnalyticCoronagraph and the MatrixFTCoronagraph?

Yeah that sounds good.

Hi @neilzim can you give me an estimate for when you might be able to work on this? This and #142 are the only remaining issues for the next release.

@mperrin I will finish this by the end of Thursday.

Ok, I'm satisfied with my draft for the new coronagraphs.rst. I added it to the list under the Contents of index.rst. However, Travis CI is failing on the following warning:
checking consistency... /home/travis/build/neilzim/poppy/docs/coronagraphs.rst:: WARNING: document isn't included in any toctree
Any idea on how to fix this?

Look in index.rst for the toctree block and add a line for coronagraphs, I believe

The build with the new docs is fixed.


Error while using another world

Im getting an error while passing another world as an argument in the mavros_posix_sitl.launch. Im using PX4 with Ros melodic and Gazebo 9.
roslaunch px4 mavros_posix_sitl.launch world=iris_vision is the command that Im using.

@Kush0301 There is no such world as iris_vision : https://github.com/PX4/sitl_gazebo/tree/master/worlds


Investigate non-git editing interface

There are editors like TinaCMS https://tina.io/ that allow for visual editing without git. Investigate using it with the site.

Looks like Tina does have basic support for Jekyll, going to try it! https://tina.io/guides/tinacms/non-react-based-ssg/guide/


Updated PHP.ini JIT settings. Extend opcache warmup

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.742%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3148

Relevant Lines:
3254

💛  - Coveralls


Unable to pull public image from Docker hub

I have 3 public docker images in Docker Hub. One of them knodir/click does not show up when I do sudo docker images search on my local Ubuntu 14.04 machine, while two others show up. I can't pull that image either. When I do sudo docker pull knodir/click it gives error FATA[0000] Tag lastest not found in repository knodir/click. Is this a bug of Docker Hub?

Hi.
Hub issues are handled by Docker's support: https://support.docker.com/
Now, if the image is private, did you do docker login before trying to pull?

It is a public image. I double checked after login; still get the same error.
I reported this to the Docker support. Thanks for pointing to there!

Mm, looking at https://registry.hub.docker.com/u/knodir/click/tags/manage/ it seems there is no tag there.
Did you push anything to that image?

Yes. First I did not add any tag since :latest is added by default (was so
in my other images). But after getting 'Tag latest was not found' error
message, I explicitly did sudo docker push knodir/click:latest. This did
not help either. I guess the tag I provide is being ignored during push.
On 13 February 2015 at 21:07, Olivier Gambier<EMAIL_ADDRESS>wrote:

Mm, looking at https://registry.hub.docker.com/u/knodir/click/tags/manage/
it seems there is no tag there.
Did you push anything to that image?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/10789#issuecomment-74362079.

Ok, since no tags are showing on the hub website, I would assume a bug there. Let me know how it works with the support (or cc me over there).


How about some idea for hprose(especially for hprose-java) H.A

hprose is perfect for its simplicity and performance but lack of some H.A way like dubbo or commonrpc as for the latter on please pay a visit to http://git.oschina.net/284520459/commonrpc/wikis/home.  I think hprose could add some support like hprose-ha to provide H.A support and I dare say it's better enhance for it than multiple languages support.

This is a good idea, and many people ask me to add those features. I have already had this plan many years ago. But I have no time to do it. Do you want to help me to implement it?

@andot, it's better you could make some interfaces for us to learn or implement and hope more could provide their solutions for based on such branch to make the special one.

Tell me the details of which interfaces you want, or I don't know how to provide what you want.
for example: https://www.python.org/dev/peps/

@andot, commonrpc has provide some idea for ha support to be integrated with zookeeper but I could not quite grasp that which just gave birth to some idea that came across. if you have spare time you could find some idea for zookeeper integration. currently there's some datagrid solution as hazelcast which provides self-defned service support which I could say to do some work for hprose integration but just some idea. in all, I think hprose could make more integration with zookeeper or data-grid to make it horizontal.

for commonrpc, please take a vist to  http://git.oschina.net/284520459/commonrpc and especially for the commonrpc-manager chapter.

I don't want to integrate any other things in hprose, because I hope it has no dependence.
Hprose is an open source project, any one can use and modify it. So if you want to integration some thing, you can do it by yourself.
If you have some difficulties to integrate something, such as lacking the necessary interface in hprose, you can write out your desired interface to me.

@andot, maybe you misunderstood what I talked about and suggested. my suggestion is to add some integration like zookeeper for H.A use cases and it would be provided officially to reduce the error while not fully understand the hprose rpc design. I think it would not induce any overload modification to hprose itself but just some enhancement for it will turn and support the H.A to become distributed rpc solution.

I know what you said. but I don't want to add some thing like this:
import org.apache.zookeeper.ZooKeeper;

in hprose.
I hope hprose has no dependence.

@andot, my suggestion is to provide hprose-ha project for us to put into practice in our project or you could add some abstract definition for us to extend or implement without strong rely on zookeeper or not no matter what the actual name is but the purpose for hprose distributed expand.

If you want to start a hprose-ha project, I can add you into this organization. Then you can create hprose-ha project in https://github.com/hprose by yourself.
If you want me to add some abstract definition to extend or implement without strong rely on zookeeper or something, you need provide the the details of them. otherwise, I don't what abstract definition should be added.
If you know how to do that, you can also do it by yourself, then push your request to this project. I will be glad to merge it. Thank you.

都是中国人, 就别彪英语了吧😢

嗯，如果谁有时间可以研究一下 dubbo，只要写一个简单的 dubbo 适配器，比如叫：dubbo-rpc-hprose，这些 HA 的特征就都有了，不需要自己从头开始写。


[Dependency Injection] How can I get IServiceProvider outside controller ?

Hi everyone,
I try to work with native dependency injection of ASP.NET Core 1.0. I work with rc1 update 1 version.
I have an n-tiers application. I would like to get IServiceProvider into DataLayer to obtain my DbContext by service with AddTransient.
Many examples show how to get my DbContext with my controllers like this :
public MyController(IDbContext dbContext) { }
This exemple works very well. But I don't want to use this method because I have to pass my DbContext through my layers.
My question is : How can I get IServiceProvider outside ASP.NET Core scope ?
Thank you for your help.
Greg

There is no static service provider if that's what you're asking for. I'm not sure what you're asking for actually. Can you clarify with a sample?

Hi David,
Thank you for your answer.
In my Startup.cs, I have this code into ConfigureServices method :
public void ConfigureServices(IServiceCollection services) {   services.AddMvc();   services.AddInstance<IConfigurationRoot>(Configuration);   services.AddTransient<IMyDbContext, MyDbContext>(); }
I add my DbContext with AddTransient because I want one DbContext per request.
But in my code, I don't want to use controllers like this :
`public class MyController : Controller
{
private IConfigurationRoot configuration;
public MyController(IConfigurationRoot configuration)
{
this.configuration = configuration;
}
}`
Because my controller create new instance of service and service create new instance of repository which use MyDbContext. With this controller, I have to pass "configuration" through my layers until Repository.
To avoid this case, I would like to get IServiceProvider directly into Repository.
How can I do this ?
Can I use another DI/IoC like Unity, simple injector or autofac ? If yes, do you know a simple implementation ?
Thank you for your help.
Greg

You should look at options https://docs.asp.net/en/latest/fundamentals/configuration.html?highlight=options#using-options-and-configuration-objects to flow things from configuration into your repository. You don't need the IServiceProvider even though it does flow through the container so you can get it in the ctor of your repository. You shouldn't need it in this case though.

I read the options documentation but I'm not sure this is what I want.
I would create my DbContext per request with AddTransient.
My objective is to share my DbContext with several repository without pass the DbContext in parameter of the constructor.

That is what dependency injection is all about. If your repository is dependant upon a DbContext instance,  it should be passed into the constructor of the repository.

I read the options documentation but I'm not sure this is what I want.
I would create my DbContext per request with AddTransient.
My objective is to share my DbContext with several repository without pass the DbContext in parameter of the constructor.

You should use AddScoped to create your context so it uses the same context within the HttpRequest scope. AddTransient creates a different context each time you request it from the service provider.


update glfw to 3.2.1

Hello,
Thanks for your effort in maintaining the package.
The latest GLFW version is 3.2.1. Just want to check if there are any plans to upgrade the bindings.
Thanks

Hey, yes, this is the next thing on the roadmap.

Hello,
Just want to check if the bindings are generated? Is this something that anyone else can do?
Thanks

The bindings aren't generated, but it looks like 3.1.2 doesn't have any API changes, so it should be fairly easy to update the local copy of glfw to that version. I don't have time right now, but you could give it a go.

Thanks. Updated my local branch to the latest glfw source files, removed some erroring out functions and it compiles and the bug is fixed.

submitted pull request @cloudhead

3.2 has vulkan support! would love to start experimenting with this.

Actually looking at this again, are we talking about 3.2.1 or 3.1.2. maybe there's some confusion here.

I'm working on moving us to 3.2.1 now, which is the latest release. The bug that was brought up was fixed in 3.1.2 though, which is an old release.

You can track this here: https://github.com/bsl/bindings-GLFW/pull/44


Dark mode on TeslaMate Dashboard

The title kind of says it all. Any way to implement it? :)
I think it would look good with Grafana already being in dark mode as well. (Just a thought and not a very important feature of course.)

Yeah, a dark mode would be awesome! Shouldn't be that difficult to implement. I'll see what I can do.

Fixed in https://github.com/adriankumpf/teslamate/pull/461

PR #461 never got merged, so this issue is still open. Is this issue still worked on?


Test failure: SpawnChildProcess_DoesNotInheritListenHandle

This issue was made automatically. If there is a problem contact ryanbrandenburg.
This test failed with the following error:
System.ComponentModel.Win32Exception : No such file or directory

Other tests within that build may have failed with a similar message, but they are not listed here. Check the link above for more info.
This test failed on release/2.2.
CC muratg

This comment was made automatically. If there is a problem contact ryanbrandenburg.
Please use this workflow to address this flaky test issue, including checking applicable checkboxes and filling in the applicable "TODO" entries:

Is this actually a flaky test?

No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)
Yes, proceed below...

Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

[ ] File a bug against the product (TODO: Link to other bug)
Is it possible to change the test to avoid the flakiness?

Yes? Go to the "Change the test!" section.
No?

[ ] Disable the test (TODO: Link to PR/commit)
[ ] Wait for other bug to be resolved
[ ] Wait for us to get build that has the fix
[ ] Re-enable our test (TODO: Link to PR/commit)
[ ] Close this bug

Is it that the test itself is flaky? This includes external transient problems (e.g. remote server problems, file system race condition, etc.)

Is there is a way to change our test to avoid this flakiness?

Yes? Change the test!

[ ] Change the test to avoid the flakiness, for example by using a different test strategy, or by adding retries w/ timeouts (TODO: Link to PR/commit)
[ ] Run the test 100 times locally as a sanity check.
[ ] Close this bug

No?

Is there any logging or extra information that we could add to make this more diagnosable when it happens again?

Yes?

[ ] Add the logging (TODO: Link to PR/commit)

No?

[ ] Delete the test because flaky tests are not useful (TODO: Link to PR/commit)

This comment was made automatically. If there is a problem contact ryanbrandenburg.
There were 3 failures with about the same error on release/2.2 at 4:29:52 PM:

SpawnChildProcess_DoesNotInheritListenHandle
SpawnChildProcess_DoesNotInheritListenHandle
SpawnChildProcess_DoesNotInheritListenHandle

Related to https://github.com/aspnet/KestrelHttpServer/pull/2944

All failures on Linux. These agents don't have the process we tried to launch (vi). We can skip this test on linux.


Feat: (API Gateway) Globals Api Cors should allow headers as well

Description:
When I use
Globals:
  Function:
    Timeout: 30
  Api:
    EndpointConfiguration: REGIONAL
    Cors: "'*'"
    Auth:
      DefaultAuthorizer: MyLambdaRequestAuthorizer
      Authorizers:
        MyLambdaRequestAuthorizer:
          FunctionPayloadType: REQUEST
          FunctionArn: !GetAtt AuthorizerFunction.Arn
          Identity:
            Headers:
              - Authorization
            ReauthorizeEvery: 100 # seconds

The headers for Access-Control-Allow-Origin and Access-Control-Allow-Methods are added to the swagger doc for the preflight OPTIONS requests, but headers for Access-Control-Allow-Headers are not added. This is a blocker for Twitch extensions because they send signed JWTs in a header named Authorization so Twitch Extension authors are forced to define their entire API via swagger.
Even when using a Lambda Authorizer and specifying an Authorization header, the requests are rejected because Authorization isn't included in an Access-Control-Allow-Headers header. I end up having to specify the whole swagger document myself, which makes SAM's API generation feature significantly less useful.
Steps to reproduce the issue:

sam init ....
add the api description shown above
deploy the template
Attempt to send a request to the deployed api with an Authorization header

Observed result:
"Authorization" is not listed in Access-Control-Allow-Headers and the request is blocked.
Expected result:
{
  statusCode: 200,
  body: "GREAT SUCCESS!!!!"
}

In the example, you’re using the shorthand form of enabling CORS. Have you considered using the object form? The form taking only a single string – the origin – is (AIUI) for common or simple cases, which it looks as though you don’t have.

Wow! That looks like it solves my problem. But I still think the short form should work when I add the Auth information. The SAM Macro has all of the information it would need to add that header and it can easily be inferred that if I say both “I want CORS” and “expect this header” then I would want that header from a CORS request as well.

Thanks for the feedback @rhboyd. We will look into how SAM can simplify this experience.


Feature/token refactor

@hillairet This looks like a big PR, most of the changes are just moving files around in testing to support the tests for the two new tokens.
This is what I have at the moment, these were just quick tests to be sure that what I changed works, but I think it could just be one unit test with different parameters for the online and offline tokens:

Let me know your preference for layout!

Cool looks like we are getting there.
We have to be careful not to retest the same code and double our tests code base.
The graphql and rest methods belong to Token, not OfflineTokenABC or OnlineTokenABC. So there is no point testing the GraphQL and Rest code twice. You can create a class in your test code inheriting from Token and testing Rest and GraphQL directly. We don't need to test python's abstract classes mechanisms.
Testing the initialization is fine though with abstract classes, not sure what we are really testing.
Also let's not make the directory structure more complicated and deep than it needs to be:
/tests
     |- token
            |- test_initialization.py    # for the initialization of OfflineToken and OnlineToken
            |- test_graphql_base.py
            |- test_graphql_operation_name.py
            |- test_graphql_throttling.py
            |- test_rest.py

Also instead of shared.py you should use pytest fixtures which will be much better than having from ...shared import xxx

This should be stable now, there is one error in the typing
spylib/token.py:235: error: Argument "headers" to "post" of "AsyncClient" has incompatible type "Dict[str, Optional[str]]"; expected "Union[Headers, Dict[str, str], Dict[bytes, bytes], Sequence[Tuple[str, str]], Sequence[Tuple[bytes, bytes]], None]"

This comes from the AsyncClient.post() method, and doesn't match their docs for what the expected input is.
I have opened a discussion with the devs on httpx as it is not clear what the input should be, but I will update this as soon as I know what's going wrong.

@hillairet this is something I noticed when developing using this using the current design:

Since we aren't defining the init for the classes it is using the default text for a pydantic object. I know the hope was to not have to do this, but can we add in the init as it helps by showing the expected arguments?

Also should we include a fix for #34 in this? Or leave it for a different PR?

@hillairet this is something I noticed when developing using this using the current design:

Since we aren't defining the __init__ for the classes it is using the default text for a pydantic object. I know the hope was to not have to do this, but can we add in the __init__ as it helps by showing the expected arguments? Unless you know a trick to get this functionality without it?

Please make an issue for this and let's do that later. This PR doesn't have to be perfect or complete.


No Metadata in ObjectInfo when using ListObjectsV2?

Is this expected behaviour?
Do i have to do an additional call to StatObject for each object i get from ListObjectsV2 to get the Metadata?
ObjectInfo from ListObjectsV2 looks like this:
minio.ObjectInfo{
  ETag:"\"df135eb93f1d6eabae1615cae9d093f2\"",
  Key:"test",
  LastModified:time.Time{wall:0x19b089c0, ext:63648316455, loc:(*time.Location)(nil)},
  Size:25,
  ContentType:"",
  Metadata:http.Header(nil),
.......

But it looks like this if i do StatObject:
minio.ObjectInfo{
  ETag:"df135eb93f1d6eabae1615cae9d093f2",
  Key:"test",
  LastModified:time.Time{wall:0x0, ext:63648316455, loc:(*time.Location)(nil)}, Size:25,
  ContentType:"application/octet-stream",
  Metadata:http.Header{"X-Amz-Meta-Ttl":[]string{"24h"}},
.....

S3 doesn't provide metadata under list operations @jonaz we just comply with the AWS S3 Spec. Stat is instead supposed to return metadata.
http://docs.aws.amazon.com/AmazonS3/latest/API/v2-RESTBucketGET.html  sample output
<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Name>quotes</Name>
  <Prefix>E</Prefix>
  <StartAfter>ExampleGuide.pdf</StartAfter>
  <KeyCount>1</KeyCount>
  <MaxKeys>3</MaxKeys>
  <IsTruncated>false</IsTruncated>
  <Contents>
    <Key>ExampleObject.txt</Key>
    <LastModified>2013-09-17T18:07:53.000Z</LastModified>
    <ETag>"599bab3ed2c697f1d26842727561fd94"</ETag>
    <Size>857</Size>
    <StorageClass>REDUCED_REDUNDANCY</StorageClass>
  </Contents>
</ListBucketResult>

thanks for quick response @harshavardhana
Im closing this and adding a call to StatObject


Blank page on this URL: http://grch38.genomenexus.org/variant/7:g.140453136A>T

Not sure it is temporary:

But probably the frontend should handle the error?

@zhx828 looks like something related to transcript switch is not handled well, will fix soon. Thanks!

not deployed yet, but will be deployed soon. Thanks for reporting!


Support multi-zone use of capability registry assets

Signed-off-by: AryaArunB<EMAIL_ADDRESS>Notes for Reviewers
This PR fixes #6814
please  see if this fixes this issue, thanks!
Signed commits

[x] Yes, I signed my commits.

@aryabyte21 Thank you for your PR!
Can you provide the steps you took to ensure that the MeshModels are being served correctly?
I just received the error attempting to run the dev server that is also a proxy server as well.
make ui
cd ui; npm run dev ; cd ..;

><EMAIL_ADDRESS>dev
> eslint . --fix && NODE_OPTIONS='--openssl-legacy-provider' node ui_dev_server.js

node:internal/modules/cjs/loader:1042
  throw err;
  ^

Error: Cannot find module 'next/zone'
Require stack:
- /home/phxvlabs-io/go/src/github.com/experiments/meshery/ui/ui_dev_server.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1039:15)
    at Module._load (node:internal/modules/cjs/loader:885:27)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/home/phxvlabs-io/go/src/github.com/experiments/meshery/ui/ui_dev_server.js:5:18)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Module._load (node:internal/modules/cjs/loader:922:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:82:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/phxvlabs-io/go/src/github.com/experiments/meshery/ui/ui_dev_server.js'
  ]
}

I have an upcoming change for next.config.js to see if I can get MeshModel components to show up through Next.js itself, but it's buggy. I'm still testing it and hope to have a PR today.

@aryabyte21  Let's discuss the update of this PR on the Meshery Dev call. Please add this as an agenda item in the meeting minutes if you would. :)

@aryabyte21, thanks for engaging with us!

@aryabyte21, thanks much for this effort. I think that the project has successfully circumnavigated this particular need for now. Let's close out this PR and re-open should the need arise again. Thanks again for contributing. Let's get you onto a new issue. 👍


gitpush command

hello im trying to implement the g4c it clones and commit correctly but in the push it says that its forbidden

i confused how we can set up the author in with g4c at first i thought that we need to create the Secret.g4c.json but im not sure where i have to create it exactly can anyone help with this ?

If it helps, I think you can't use User name and password to push to GitHub any more..

And g4c does not support SSH


build failing

failing to build the project:
In file included from src/platform/pico/sleep.c:9:
/home/pi/.platformio/packages/framework-arduino-mbed/cores/arduino/mbed/targets/TARGET_RASPBERRYPI/TARGET_RP2040/pico-sdk/common/pico_stdlib/include/pico/stdlib.h:11:10: fatal error: pico/stdio.h: No such file or directory
   11 | #include "pico/stdio.h"
      |          ^~~~~~~~~~~~~~
compilation terminated.
*** [.pio/build/pico/src/platform/pico/sleep.c.o] Error 1

I am a bit lost with platfom.io and pipico. Could you point me, how to compile?
Might be nice to have binary builds in releases.

Thanks for this comment, I'd just about forgotten about this quirk. So, I don't know what the issue is, but I do know that if you open the offending stdlib.h file in the mbed core and comment out line 11 (the #include "pico/stdio.h" line), it will compile.
I'm not quite to the point of wanting to make binary releases; the book parser is still very fragile and I wouldn't want folks to think this is even pre-alpha software just yet. But the tweak above should get you building; let me know if it works!

Great, that helped... :-)
was not aware of such a trick. Thank you (I feel that src/platform/pico/* files should come from platformio, ant they shouldn't be part of the project...). Need to diff them to check, if there are some changes.


Is it a go-live version?

Gregg Boer said it, but I can't find any "more official" info about it.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ea58ea8f-40b9-514f-298d-e75624ea3f71
Version Independent ID: dd877b18-c9ec-e01d-d0f6-1d203e65b066
Content: TFS is now Azure DevOps Server
Content Source: https://mseng.visualstudio.com/DefaultCollection/TechnicalContent/_git/tfs-docs-pr?path=%2fdocs%2fserver%2ftfs-is-now-azure-devops-server.md&version=GBlive&_a=contents
Product: devops-server
Git Login: douge
Microsoft Alias: douge

It's confirmed in this post by Jamie Cool.


Mouse cursor invisible after adjusting shader uniforms via editor

Godot version:

Commit 723e2e9654615fcfd858786d687d22b9fdfc1fd6
OS/device including version:

OS: Fedora Linux 4.18.9-200.fc28.x86_64 , Doubt it's GPU related.
Issue description:

What happened: Adjusting shader parameters in the editor while the shader code is updating, and the cursor is hidden to adjust the value, causes the cursor to be stuck in the hidden/unusable state until restarting the program.
Expected : Cursor should reappear if the the parameter changes while the value is being changed.
Steps to reproduce:
Create a shaderMaterial on a node.
Create a Shader resource.
Open shader editor, add a uniform float and a working fragment() to the shader.
Click and drag the the shader uniform in the Shader Param section of the inspector using the mouse, immediately after making changes to the shader code that update it or cause throw errors.
Minimal reproduction project:

test.zip
Side note:
Not reproducible in 3.0 because you can't have both Shader Params in the inspector and the Shader code editor open simultaneously.

Godot version:
Godot master 89f8b84, alpha 1, 2.
OS/device including version:
Xubuntu 16.04.5 LTS, Nvidia GTX 750 Ti
Reproduced with DynamicFont.

mouse_cursor_bug.zip


how can add buttons to notification?

how can add buttons to notification?

This feature is not available yet. I'm planning to develop it in the next weeks, or sooner if you need. Feel free to contribute to the package if you want, using this documentation: https://pub.dev/packages/flutter_local_notifications#notification-actions

Does an alarm notification arrive in the background?

I have made some modifications and I am trying to upload the code but it does not allow me

As explained in the README.md, in order to contribute you have to fork the repository and submit a pull request.

I pull request

Thank you for your contribution !
I'm very busy at the moment so give me a few days to review your PR. In the meantime, you can use your fork instead of my alarm package as a dependency in your project.

Thank you, but how can I make the alarm ring even if the application is destroyed?

In iOS, if the app is killed, there is no way the alarm could ring...
However, I'm planning to add a feature that would send a notification like "The app has been killed. Please open the app or the alarm will not ring" at the moment the user kills the app. This way, the user will be aware the alarm will not ring if he doesn't re-open the app.

Here's an example of the app Alarmy that shows this kind of notification when the iOS app is killed:

I think if a schedule notification is sent it would be better

Can you elaborate ? I'm not sure to understand.

I mean that the schedule notification is sent instead of the normal notification because the scheduled notification will appear even if the application is destroyed

In iOS, when a user sets an alarm, a notification is scheduled. If the app is killed, the notification will still show, but the audio of the alarm will not be played. That's why I would like to show a notification to warn the user at the moment he kills the app.
Let me know if it's not the answer you were expecting.

You are right...
I didn't notice before but on Android too if you kill the app, the alarm will never ring.
I don't have a solution for this at the moment. However, the feature that I was talking about earlier that shows a notification when the user kills the app is being developed.
Furthermore, a workaround that the app Alarmy uses is that in the case the user kills the app, when the alarm is supposed to ring, we show multiple notifications with sound that could replace the alarm sound.

You are right... I didn't notice before but on Android too if you kill the app, the alarm will never ring. I don't have a solution for this at the moment. However, the feature that I was talking about earlier that shows a notification when the user kills the app is being developed. Furthermore, a workaround that the app Alarmy uses is that in the case the user kills the app, when the alarm is supposed to ring, we show multiple notifications with sound that could replace the alarm sound.

There is a good solution for Android see this : https://stackoverflow.com/questions/65475678/how-to-launch-app-like-googles-alarm-app-using-alarm-manager-in-flutter
I have tested it and it works fine, you just need to fork Android Alarm_manager_plugin and make these changes

Since version 3.0.0, alarms can ring even if app was terminated.


[question] Custom id/primary key

Hello! I've been looking through the docs and I couldn't find how to define a model and datagrid that can use a primary key which is not named "id". For example, we have a Location resource with
code: zipcode, primary key
name: some string

The REST endpoint is still /locations/:code/ and works ok, acting on the code attribute.
Is this possible? Thanks!

From what I know, admin-on-rest requires an id field for each item. It can be integer or string, but it is definitely required. It may be much easier to change backend or your restClient to rename code field into id.

I'm looking for this too. Something like backbone's idAttribute would be really nice here.
It looks like this would take a bit of work. The rest server(s), reducers and actions seem to be closely tied to the "id" key. However, I'm not very familiar with this project yet so it would be nice to hear from someone who is.

https://github.com/marmelab/admin-on-rest/issues/373

And the tutorial for doing this is online: https://marmelab.com/admin-on-rest/FAQ.html#can-i-have-custom-identifiers-primary-keys-for-my-resources

Thank you!
On 16 May 2017 at 08:56, Francois Zaninotto<EMAIL_ADDRESS>wrote:

And the tutorial for doing this is online: https://marmelab.com/admin-on-
rest/FAQ.html#can-i-have-custom-identifiers-primary-keys-for-my-resources
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/marmelab/admin-on-rest/issues/670#issuecomment-301705193,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeeLfOiFYOrtpXa7kxvu0qrVW39Ac1Uks5r6VbKgaJpZM4NaLXA
.