Feature/636: Table Pagination

Adds pagination to the Table component and updates store for Stages to take a limit parameter set in the page.

Caveats:

There is still a hard limit on how many items are loaded from the database (but it is now higher). We could add a dropdown in the frontend, but we should probably instead make paging dynamically load each page, improving performance and removing any arbitrary limit.
The "select all" checkbox literally selects all the data that has been loaded into the component (up to 500 rows). This is probably not what we want it to do, but I can't see it being used that often so we can probably live with it for now. We could add a "X rows selected", and simply by implementing the aforementioned data paging, you will get this effect for fee.

Hi @warrensearle,
Thanks for the comments :)

All these additions/changes should be made in the sandbox, away from actual usage of the components.

Would it be possible to understand a bit more about:
a) what this sandbox is?
b) how to use it?
c) why we wouldn't make the change directly to the component?

which should be covered by separate, specific tickets.

I'm afraid I don't really understand why we need to do this? It seems to be creating tickets for the sake of creating tickets. The component (in whatever form) was designed to solve a particular problem, identified in #636.
The work is scoped to the "Stages" area of admin. It may be that we find this pattern useful elsewhere in the application, but I don't think that should stop us making the changes there initially.
For example. the "Notifications" section isn't even using the table component itself. So I think adding these changes to areas beyond the initial scope is certainly something for other tickets, but changes to a small and well defined area are fine. This is especially true if the changes are actually to support using the component to deliver the business outcome.

I think it's important to note this is a fairly business critical change, and there is a demand for getting something out there. This doesn't mean we shouldn't do it right the first time around (eg. unit tests), but it would be good to understand how important some of the suggestions are, which is difficult to do when there isn't a great deal of explanation behind some of the requested changes.
To that end:

This should be re-organised so there's a separate pagination component, which our table component is then amended to make use of.

I can see now why this might be advantageous. I'm happy to look into doing it, but I would question where else we are likely to need to the pagination component urgently, and therefore how important it is that this is abstracted right now.
Thanks :)

Hey @crablab appologies if my original feedback was a little sparse. It was a follow-up on the conversation you had with @lloback this morning at stand-up. I shall elaborate a little bit here but also DM/call you.
So to bring some context to this, we have an existing Table component which is used across the whole app. It is already being used in the following locations and also being rolled out to pretty much every list page in the app:

Candidates list
Notes list
Applications lists
Stages lists
Changes we make to the Table component will effect all these current and future instances of it's use.

Therefore in changing or adding to 'global' components like this, one approach we've taken is to use a Sandbox page.
This is a simple page/environment where we control the data fed into the component we're working on and can see the results in isolation from the wider app. Let's go through this further in person.
The other approach that's usually good to take is new functionality like this should generally be optional. In this instance most uses of the Table component will indeed want paging but perhaps paging should only be turned on if the view using the component provides a prop to turn it on - e.g. the pageSize prop might be used to turn on paging <Table page-size="50">.
What you've done so far is indeed good and appreciated just I think there are three stages/tickets to the work:

This was based upon a user-reported issue where list sizes are limited to 50. The immediate and temporary fix for this is to remove/increase that limit so that users can do what they need to do. (this is not ideal but is ok as we know that we're not dealing with loads of data yet). See admin#636.
This highlights the need for adding pagination to our Table component. So we should feed into and prioritise the ticket we have for that. See admin#542
When our Table component supports pagination we should identify all the views that are using it and consider whether they all want pagination turned on, page size etc and if any supporting changes are needed such as updating our stores to support paging. See TBC.

My thoughts are that this PR should be for either 1) or 2) above rather than a mix of all three.
In terms of a Pagination component, it looks to me like that block of code (Table.vue, lines 69 - 107) could be encapsulated in its own component, along with supporting logic. Primarily this would keep Table.vue smaller and so easier to work with. In addition though we might want to display the pages links at the top of the table (or both top and bottom). Or maybe we'd use the same component outside of the Table, for example in an image gallery or document viewer.
Hope this helps to some extent. Let's discuss further in a call.

Thanks @warrensearle  - this is really helpful :smiley:

This is a simple page/environment where we control the data fed into the component we're working on and can see the results in isolation from the wider app.

This makes sense, thanks, I think this should probably be separate from the actual service, and there is a wider discussion to be had about centralising our component libraries and abstracting them from the actual codebase, given the reuse across repositories, which would then allow an independent sandbox,
I don't think we should be afraid of larger PRs, however. Hopefully increasing test coverage will help here, but changing a single component in one place (regardless of re-use across the codebase) should not require several PRs, and indeed that makes it more difficult to see what has changed. With better coverage we should be able improve this, and therefore increase the pace of delivery.

The other approach that's usually good to take is new functionality like this should generally be optional.

So I agree this is something I should have thought about! If you note, there is a computed property for this (which currently does nothing).
However, as you say "in this instance most uses of the Table component will indeed want paging", as mostly we will want paging enabled I think we should default to 'true', rather than disabling by default. I think that makes sense given the context in which we are using the component?

The immediate and temporary fix for this is to remove/increase that limit so that users can do what they need to do.

I, personally, think we should prioritise a proper if not complete fix for this. Since it requires deployment anyway, we might as well try to get a better change into the next train as quickly as possible.
We can be agile about this and get something out there to address the user need. I think a huge page could be a regression in terms of usability, which is why I prioritised getting this out in some form.

When our Table component supports pagination we should identify all the views that are using it and consider whether they all want pagination turned on, page size etc and if any supporting changes are needed such as updating our stores to support paging

Sure. I think that belongs here, rather than in a separate PR though. I can understand why we might want to avoid expending a load of energy on something that won't pass code review, but the more fragmented the problem becomes, the more difficult to track the changes and the longer it takes to get it co-ordinated and done.
This PR creates a component that we know we need to use in several Stages. If we don't want to roll out the change across all of the rest of the instances of the Table, we could make it disabled by default (as you suggest) for the moment, which would mean no change to the other instances. A follow on PR would then be to change it to the default behaviour, having confirmed there are no issues elsewhere - using the Stages instance as a "beta", if you will.
I think we might also want to review the 1:1 relationship between PRs and Issues (ticket) - I'm not convinced that is especially advantageous, especially for small pieces of work that don't necessarily need a ticket. A PR is self documenting and we could be more agile here.

In terms of a Pagination component, it looks to me like that block of code (Table.vue, lines 69 - 107) could be encapsulated in its own component, along with supporting logic. Primarily this would keep Table.vue smaller and so easier to work with. In addition though we might want to display the pages links at the top of the table (or both top and bottom). Or maybe we'd use the same component outside of the Table, for example in an image gallery or document viewer.

Agreed, this is the way to go. It will also make unit testing easier. I'll get this done today.


Cache the order ops during codegen for a nice compile speedup

With this change the compile time for mxnet/LSTM_backward.json went from 9.6 to 8.7 seconds.
The stopwatch changes we done while I was hunting down the issue and I liked them, so I kept them.

TESTNOW


feat(user-store): implemented partial methods in UserStore interface

Preliminary implementation of methods GetOne, GetOneByStudentID, GetOneByEmail, Create
Notable changes:
packages imported: fmt, strconv
signature of all methods in interface excluding GetAll changed return type to a pointer of the User struct
Create function assigns a new userID and created_at value(s) for the User struct provided when added to the database

In the SQL schema the studentID is an int, but in the User struct, the studentID is a string. Should we make the type consistent, so we don't have to perform a conversion each time?

@steph-feng I believe the type conversion point was brought up in the last commit from before :) https://github.com/ubccsss/Blood-For-Life-Management-Backend/pull/2

oops right! also, i think lines 71 and 97 need the ":=" instead of the "=".

@steph-feng Sorry Steph did u mean lines 70 and 96 where there is a "=" and not a "!="

I'm unable to change those to a ":=" as in lines 65 and 89 respectively the 'err' variable has already been assigned with ":=", and cannot be declared with a ":=" in later lines or the compiler will draw a red underline.

you are so right! my bad, all looks good to me!

no worries thank you sm for double-checking my work!


No need to be sad anymore

Based on changes in https://github.com/magic-lang/ooc-kean/pull/1618/files#r58666920
This seems like a workaround for an older version of rock and is no longer needed.

Hm, this failed on
make -s rescue
Getting latest bootstrap url...
Could not find latest bootstrap-only. Can you reach api.github.com ?
make: *** [download-bootstrap] Error 1

What if you close and re-open this PR? That's fixed weird issues for me before.

could be a spurious travis failure?

Closed and reopened the PR, but got the same error. Ironically, this PR is making me sad.

How is the magic-lang fork dealing with bootstrap downloads ?

@thomasfanell @fredrikbryntesson ?

Works like a charm here.

Works like a charm here.

Well that wasn't really my question — is it using the same script to download them? Where do you host your bootstraps? or are you just using ooc-lang/rock bootstraps? etc. I could look it up but.. time :(

We are using the ooc-lang bootstraps.

Closed and opened again, and now it works. Travis must have had a bad day yesterday.

🌚 🎆 !

I don't know know what that's supposed to mean @fasterthanlime , but thanks :D

I don't know know what that's supposed to mean @fasterthanlime , but thanks :D

fireworks are for celebration and.. I just kinda like the dark moon one


Feature Request - expression lang support

Use case: I am currently reporting the http path of each request to prometheus for monitoring. I noticed that the path contains the query parameters as well. i would like to remove the query parameters from the http path label.
On a more general level it would be nice to use expressions to parse the data being sent to a given adapter.

From the attribute vocab definition:

request.path | string | The HTTP URL path including query string

We should consider the introduction of a new "standard" attribute with query string removed.  This can be used as a compliment to the pending api mgmt work as well.
adding a substring type of func to the expression language is also a path forward here.


#4605 match.params aren't URI decoded - further test

Hi,
I think that #4605 is still not fixed, as this test demonstrates.
I will attempt to fix, but I can't guarantee I will succeed. I think the fix needs to be in history, and that the path component decoding function needs to be decodeURIComponent, rather than decodeURI. For that to work, we need to rearrange the parsing so that decoding happens after parsing (I think this commit does it before parsing), otherwise the parse will be ambiguous.
I think that the current code shows confusion around types, e.g. the line I linked to above pathname = decodeURI(pathname) shows that the distinction between encoded URIs and values used as path parameters is not being properly maintained, which has led to this bug IMO. Decoded path parameters are of a different type to encoded URIs, so the two should not be stored in the same variable without inviting confusion and bugs.
Thanks,
Rich

I have prepared a fix, which I have added to this PR.
I don't think that the URI decoding relevant to this bug should be happening in history at all, and I think that the decodeURI that was added in https://github.com/ReactTraining/history/pull/442 is quite suspicious and may be incorrect.
I believe that the history module should pass the paths to react-router, including any necessary URI encoding that is required for them to be valid URIs. When react-router extracts path params from these URIs, it should apply decodeURIComponent, because the values are moving from a URI typed domain to a string typed domain. I have done this in the attached commit (19670202) and all tests now pass.
Hope this helps,
Rich

This will also fix #5607, but I can't comment on there as it is "locked"

With history v5, we will be removing pathname decoding. Both v4 and v5 of history will remain compatible with RRv5 (and v4). With the React Router and history v6 releases, we will be switching to non-decoded pathnames (they should always be encoded, but the user will be responsible for providing the correct encoding), but for the time being it will be possible for pathnames to be either encoded or non-encoded. I bring this up for two reasons:

I worry that we cannot safely call decodeURIComponent on the params until we are certain that the pathname is encoded. The primary edge case for this would be if the decoded pathname has a percent sign (either a valid octet that gets double decoded or an invalid octet that throws an error).

decodedLocation.pathname = "/message/%20 is the space octet"
<Route path="/message/:message" />
params = { message: "  is the space octet" }

We should provide a way for people using history v5 to have decoded params. Encoded pathnames is the safe choice, but having to constantly decode params yourself is annoying.

I haven't discussed this with any of the other maintainers, but I think that it might be beneficial to add a decode prop to the <Route> (only for v5), which would signal that we can safely decode the params.
<Route path="/artist/:name" decode ... />

That should solve the problem in this PR while letting anyone that knows that they have params that are unsafe to decode to skip the decoding. (The inverse solution of providing a prop to not decode is also possible)
v6 will expect pathnames to be encoded, so we should probably be able to safely decode params there.
Thoughts?

I don't fully understand your comment. My initial reaction is that it doesn't really make sense, and you are trying to shoe-horn two incompatible concepts (URLs and some kind of more general "path") into a single library, which is causing you irreconcilable type errors.
I think you need to 1) actually specify what /type/ is held in the various values here and 2) enforce that consistently (which is hard in an untyped language). I think you are building on sand by proposing a user-specified "encoding" which may or may not be compatible with URL encoding.
In the meantime, I do think the proposed patch here is a) correct, b) an improvement on what is currently in the codebase and c) fixes a real bug. So I would suggest merging this patch and moving more theoretical discussions about "the user will be responsible for providing the correct encoding" in future versions to a different thread.

I will move the decoding issue elsewhere, but I'm against merging this PR at this point. It might be the correct decision in v6, but we'll cross that bridge when we get there.

Are you saying that the path params should never be decoded?
So for a route like <Route path="/:parentId/:childId", a URL like /a%2fb/c should give values {parentId: "a%2fb", childId: "c"}?
I think that is unconventional to the point of being wrong, but I suppose it could work if it is documented and applied consistently.
Currently the codebase is somewhere half way between the two viewpoints.

I think that a param should be decoded. My worry is that if we call decodeURIComponent on a string that is already decoded, we run the risk of double decoding an octet-like string.
This is all stemming from the history v4 implementation where a pathname is a decoded string. Any percent-encoded octets in the string should not be considered encoded (in the param %20 is the space octet, %20 is a string containing three characters, not the octet for a single space character). If we call decodeURIComponent on that string, the octet will be converted to a space (  is the space octet).
I really just don't want to further break things by adding automatic decoding unless we can be certain that it will give the correct output. Once all pathnames are encoded, we will know that any percent-encoded octets are "real" octets, so decoding would be safe.
Maybe I'm overthinking it; v4's behavior would already make the %20 is... pathname buggy, so it is possible that automatic decoding wouldn't break anything that isn't already broken. :man_shrugging:

Maybe I'm overthinking it; v4's behavior would already make the %20 is... pathname buggy, so it is possible that automatic decoding wouldn't break anything that isn't already broken. 🤷♂

I think so.
I would bet that everyone is using "web safe" path params, because they can't rely on the current behaviour. I don't think you need to worry about backwards-compatibility here, as there is clearly a bug, as evidenced by #4605, this issue and the unit tests I added.

I'm still slightly hesitant about blanket decoding every param. It is probably the ideal default behavior, but I wonder if anyone would want the ability to keep their params encoded. I'll leave the decision of whether to merge this as is or allow non-decoded params up to the other maintainers.

As an aside, I think that the title of this PR could be more clear. Something like "automatically decode params using decodeURIComponent" or "decode param characters not decoded by decodeURI". The latter describes what the PR fixes today, while the former describes what RR will want to do once pathnames are encoded.
// characters not decoded by decodeURI
; , / ? : @ & = + $ #

I wonder if anyone would want the ability to keep their params encoded

I can't think of any reason why they might want this.
This doesn't make sense to me at all. There is no option in JSON.parse to keep the fields "encoded"; why should a URL decomposing lib offer an option to incorrectly decompose a URL?
I'll leave it with you.

As an aside, I think that the title of this PR could be more clear. Something like "automatically decode params using decodeURIComponent" or "decode param characters not decoded by decodeURI". The latter describes what the PR fixes today, while the former describes what RR will want to do once pathnames are encoded.

I disagree, I think "match.params aren't URI decoded" is a reasonable description of the bug.
Part of the confusion might be that the builtin function "decodeURI" is poorly named and not very useful, for historical reasons.
Notice that the MDN docs for decodeURI do not mention any RFCs or explain when it is valid to use this function :-(
This SO explains some of the differences: https://stackoverflow.com/a/3608791/8261
"decodeURIComponent"/"encodeURIComponent" is correct for URL path parameters, which is the context we are discussing.

I really hate "stale bot".
This is a real bug in react-router. Even though no-one is currently working on it at present, I don't think this issue should be closed.

What is recommended workaround for this issue? Just noticed it upgrading from v3 to v5

.

Submitted PR on history project https://github.com/ReactTraining/history/pull/797 that I'm hoping is the other half of this issue.
I am in favor of this PR, as it causes some weird gaps in support for %-encoded path segments for me which at the moment might force a home-grown replacement for a project, which I'd really rather avoid.


Project name clashes with https://github.com/asciidoctor/asciidoctor-pdf

What happens if I have both this project and the Ruby pdf export project from asciidoctor installed globally on my machine?
The first one found in the path will be used.
Perhaps renaming the CLI script to asciidoctor-pdf.js (same as the actual repo name) would help? Like how asciidoctor.js can coexist with asciidoctor?

We had some debate on the Asciidoctor.js CLI (based on Asciidoctor.js) and we've decided to use the same name. Previously, the binary was called asciidoctorjs but it was confusing.
For instance, the following was not working:
npx asciidoctor -v

Even though the npm module is called asciidoctor, the binary was called asciidoctorjs... why is that you could ask if you didn't know about Asciidoctor Ruby.
I believe that it's pretty rare to install both Asciidoctor.js and Asciidoctor Ruby globally. And I can assume that if someone do that, then he must understand that he's using two implementations of the same project, one in Ruby and one in JavaScript. So he must decide which one he want to use.
When in doubt, you can always type: asciidoctor -v or asciidoctor-pdf -v.
Having said that we might reconsider this decision for this project because unlike Asciidoctor.js, this project is not a transpilation of Asciidoctor PDF (Ruby). In other words, it's not the same code base. It's two distinct projects based on different technologies.
I don't really like the "js" suffix in a command line and I think it's more accurate to say that this project is based on web technologies.
So maybe asciidoctor-web-pdf as suggested by @mojavelinux.

npm package: asciidoctor-web-pdf (or @asciidoctor/web-pdf)
binary: asciidoctor-web-pdf
project name on GitHub: asciidoctor-web-pdf

Summoning my peers for their valuable input 😉
//cc @oncletom @ahus1 @rdmueller @Ablu
Gosh naming is hard, who knew?! 😆

It's only an issue if you install both packages globally.
If you install both packages globally, I think the responsability of knowing which binary is called is on the user.
Globally installed binaries can be retrieved with ls $(npm config get prefix)/bin.
Another thing I see is adding an extra binary name (as @asciidoctor/cli does) to provide 2 binary names (asciidoctor and asciidoctorjs to pursue on the previous example).

I just renamed the repository and I've added asciidoctor-web-pdf as an alias. With https://github.com/Mogztter/asciidoctor-web-pdf/pull/243 both asciidoctor-pdf and asciidoctor-web-pdf are valid bin names.


Trending teams

Could calculate and display teams that are showing the most growth in either number of givers or amount being received. Stats page or part of a more general "find teams" system (https://github.com/gratipay/gratipay.com/issues/3127, https://github.com/gratipay/gratipay.com/issues/3938, etc.).

https://github.com/gratipay/gratipay.com/issues/3736?

I think that's related, but in order to incorporate #3127 it might need to not be on the front page. Or maybe that's a simple dropdown in the UI that could be made to look okay.

number of givers or amount being received.

I meant these two could be part of those sort, but the sorting thing will probably be on the homepage.

How often would the "trending" calculator run? I assume we have other processes that run on a schedule, could this be rolled in to recalculate a database value for is_trending?

FYI we do have some cron-ish infrastructure.

We might also consider migrating cron-ish work out of the web app and over to @gratipay-bot.

We might also consider migrating cron-ish work out of the web app and over to @gratipay-bot.

Out of curiosity, why?

Because it's hackish to have async tasks running in a thread in the main web app server. It makes it complicated to scale beyond one webserver, because one generally wants to scale async workers separately from web workers.

It makes it complicated to scale beyond one webserver, because one generally wants to scale async workers separately from web workers.

Ahh, that makes sense. So @gratipay-bot could do its thing over multiple servers if needed, whereas crontab would need to be mirrored to each machine.

http://stackoverflow.com/questions/787496/what-is-the-best-way-to-compute-trending-topics-or-tags

specifically http://stackoverflow.com/a/826509/2152245

Inspiration at http://github.com/explore:

Twitter:


Include human labels from QoE 010

Include the results from the listening test on WFS vs. stereophony in the database and in the documentation.

Done.


Add-question-4

Thanks @djuanit0x for the pull request, @urmauur and @nold2 will review it.

good question, thanks @djuanit0x

@all-contibutors please add @djuanit0x for content

@all-contributors please add @djuanit0x  for content


DEV: On small screen sizes if you don’t switch chats, new chats won’t mark as unread in the LHN

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

Action Performed:

Open a chat with an account on a small screen size
Send a message from that other account
Use the arrow button to move back to the navigation view (i.e. you can’t see the chat anymore)
Send another message from that other account

Expected Result:
Message should appear in the appropriate chat in the navigation, and be marked as unread
Actual Result:
Message appears in the appropriate chat in the navigation, but is not marked as unread
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

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

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: Dev
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/8897f861-5e2f-4ecf-b779-5fef36eaf198
Expensify/Expensify Issue URL:
Issue reported by: @dangrous
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1684247684295779
View all open jobs on GitHub

I'm not fully understanding the steps so I can't reproduce the issue. I'm going to close this until better reproduction steps are provided.


Example 4-11.AttributeError: 'dict' object has no attribute 'set_training'

In [267]: from ray.rllib.models.preprocessors import get_preprocessor
     ...: env = GymEnvironment()
     ...: obs_space = env.observation_space
     ...: preprocessor = get_preprocessor(obs_space)(obs_space)
     ...:
     ...: observations = env.reset()
     ...: transformed = preprocessor.transform(observations).reshape(1, -1)
     ...:
     ...: model_output, _ = model.from_batch({"obs": transformed})
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [267], in <cell line: 9>()
      6 observations = env.reset()
      7 transformed = preprocessor.transform(observations).reshape(1, -1)
----> 9 model_output, _ = model.from_batch({"obs": transformed})

File ~/.cache/pypoetry/virtualenvs/ray-KeD1w6JO-py3.9/lib/python3.9/site-packages/ray/rllib/utils/deprecation.py:122, in Deprecated.<locals>._inner.<locals>._ctor(*args, **kwargs)
    115     deprecation_warning(
    116         old=old or obj.__name__,
    117         new=new,
    118         help=help,
    119         error=error,
    120     )
    121 # Call the deprecated method/function.
--> 122 return obj(*args, **kwargs)

File ~/.cache/pypoetry/virtualenvs/ray-KeD1w6JO-py3.9/lib/python3.9/site-packages/ray/rllib/models/modelv2.py:357, in ModelV2.from_batch(self, train_batch, is_training)
    350 """Convenience function that calls this model with a tensor batch.
    351
    352 All this does is unpack the tensor batch to call this model with the
    353 right input dict, state, and seq len arguments.
    354 """
    356 input_dict = train_batch.copy()
--> 357 input_dict.set_training(is_training)
    358 states = []
    359 i = 0

AttributeError: 'dict' object has no attribute 'set_training'

@sepilqi I'm assuming this is a version error. Would you mind installing the dependencies as specified and run this again, e.g. directly on Colab?

Feel free to reopen if the problem persists.


The strings are sometimes displayed with missing characters

Do you have a bit more context ?

Android version
App version (does it still happen in master ? F-Droid or Play Store)
Custom theme ?
device language ? Open Food Facts language ?

I am using the APK
BlueStacks on windows

Closing as it is most probably a bluestacks issue


add support for loading integrations from json file

This will load the integrations from a json file on initialization. The file can be specified with an environment variable.
I also updated the devenv.bat to reference the current directory so the source code can be in an alternative location (with the VM it ends up as E:\).

Will add a unit test and update the installer in a separate PR.


[develop] Dump statistics for unit test runtimes

https://github.com/MinaProtocol/mina/pull/13937

!ci-build-me

!ci-build-me


”Densuș” is listed in the drop-down menu

Description:
"Densuș" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Densuș" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Densuș, HUNEDOARA".


fix(runtime-core): components options should accept components define…

…d with defineComponent
Currently, when using TypeScript, a component defined with defineComponent can not be used in the components options:
const comp = defineComponent({})
defineComponent({
  components: { comp }
})

This example was throwing with:
The last overload gave the following error.
    Type { comp: new () => ComponentPublicInstance<unknown, unknown, unknown, {}, {}, VNodeProps>; } is not assignable to type Record<string, Component>.
      Property comp is incompatible with index signature.

This commit fixes the issue, and adds a simple repro in the dts tests.

Thanks!


Major Test Explorer Update in 16.2

There was a major test explorer update in Visual Studio 2019 16.2 and as of this morning 16.2 is GA released!

Read more in the Release notes
Blog

Several docs should be updated with 2019 pictures and a few sections should be added as well to cover the main new features:

[X]  Get started was already recently updated
[x] Testing tools in VS : PR
[x] Unit Testing Basics (PR)
[x] Run Unit Tests in the Test Explorer : PR

New sections to be added in Test Explorer doc

[x] Filter buttons
[x] Adjustable and filterable columns
[x] New groupby
[x] New playlists tabbed view
[ ] Live Unit Testing tab

More minor updates:

[x] Test Explorer FAQ (PR)
[x] Get Started with Live Unit Testing
[x] Use Live Unit Testing with VS Enterprise
[ ] Code coverage doc

"Use Live Unit Testing..." updated in MicrosoftDocs/visualstudio-docs-pr#6386, and "Get started with Live Unit Testing" updated in MicrosoftDocs/visualstudio-docs-pr#6373

Since we are tracking code coverage on the new internal issue, https://github.com/MicrosoftDocs/visualstudio-docs-pr/issues/6300, I'll go ahead and close this. @Mikejo5000 Thank you for your work!


SyntaxError: ("no viable alternative at input 'for'", ('**********\Roaming\BurpSuite\bapps\30d8ee9f40c041b0bfec67441aad158e\AuthMatrix.py', 1319, 58, ''))

SyntaxError: ("no viable alternative at input 'for'", ('**********\Roaming\BurpSuite\bapps\30d8ee9f40c041b0bfec67441aad158e\AuthMatrix.py', 1319, 58, ''))

Can you provide what version of Jython you are using?
Any specific repro steps that cause this?

I' m use jython-standalone-2.5.3

I chose AuthMatrix installation in Bapp store

When I want to start AuthMatrix

I don't know what's wrong with it. Can you help me?

Currently AuthMatrix only supports standalone Jython 2.7.0 or greater.  Version 2.7.0 recognizes some syntax that is not supported in older versions, including python list comprehension which is used throughout AuthMatrix. This requirement is noted in the Readme of AuthMatrix.
If you can, try with the 2.7.0 jar available here.
http://www.jython.org/downloads.html
If you are still experiencing issues, let me know and we can reopen the issue.
-Mick

Thank you.  Why didn't I try more version. Repaired.


Update Dockerfile

Add the option --no-cache to the command pip install to avoid caching (this make the command rm -r /root/.cache not necessary anymore).
Print in the log what we are doing.
Install the package wheel as well (as it is when installing pip with the get-pip.py script).

@vuolter Thank you for your contribution!


How to use when migrate to AndroidX?

My profile show error: java.lang.IllegalAccessError: Field 'androidx.recyclerview.widget.RecyclerView$ViewHolder.mPosition' is inaccessible to class 'androidx.appcompat.widget.ViewHolderDelegate' (declaration of 'androidx.appcompat.widget.ViewHolderDelegate'

did you can please tell me solution?

Hi, You can pref my fork. I was migrate to androidX. See here: https://github.com/huyvm/RecyclerViewPager

@huyvm In My lib I can't get ViewHolderDelegate using import androidx.recyclerview.widget.ViewHolderDelegate;  so please tell me how to get that .. and thanks for fast reply

Hi @bctpl, remove old implement and add my RecyclerViewPager (read ReadMe).

I don't have any old implementation of that library I downloaded and convert into androidx that's it and I have all that library implementation but still can't resolve that and ViewHolderDelegate  it's declaration also not in androidx.recyclerview.widget when i dig into library

@huyvm Your repo work but how you do that please let me explain if possible why I can't get ViewHolderDelegate  in my implement ?

Hi, because RecyclerViewPaper in your implement don't support migrate to AndroidX.

Your forked implementation worked perfectly thanks for that. But still confused why  RecyclerViewPaper in your implement don't support migrate to AndroidX. not working. Anyway thanks for helping ☺

Hi, because https://github.com/lsjwzh/RecyclerViewPager don't yet convert repos to androidX. So when you use with implement from lsjwzh/RecyclerViewPager, you will see error.


[#231] support core bb service tokens

Description
Please provide a summary of the pull request and the issue it resolves. Please add necessary details, context, dependencies, explanation of when review is needed (see next section), etc.
**Resolves #231 **
Review Time Estimate
Please give your idea of how soon this pull request needs to be reviewed by selecting one of the options below. This can be based on the criticality of the issue at hand and/or other relevant factors.

[x] Immediately
[ ] Within a week
[ ] When possible

Type of changes
Please select a relevant option:

[ ] Bug fix (non-breaking change which fixes an issue).
[x] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[ ] Other (any another change that does not fall in one of the above categories.)

Checklist:
Please select all applicable options:

[x] I have signed the Rokwire Contributor License Agreement (CLA). (Any contributor who is not an employee of the University of Illinois whose official duties include contributing to the Rokwire software, or who is not paid by the Rokwire project, needs to sign the CLA before their contribution can be accepted.)
[x] I have updated the CHANGELOG.
[x] I have read the Contributor Guidelines.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] My change requires updating the documentation.
[ ] I have made necessary changes to the documentation.
[ ] I have added tests related to my changes.
[x] My changes generate no new warnings.
[x] New and existing unit tests pass locally with my changes.
[ ] Any dependent changes have been merged and published in downstream modules.

Hi @shurwit ,
Could you please take a look at this PR?
Thanks!

Sure @mdryankov!
By the way in general I intend to review all PRs that come from my team. I appreciate your reviews as well, but I just wanted to let you know that sometimes my team will open PRs for me to review and it will autorequest a review from you right away as code owner. Feel free to hold off on reviewing PRs from my team until I have had a chance to take a pass if you have other priorities. I will send you a message once I have approved a PR if you haven't gotten to it yet. Thanks again for your help!


Permission to create file in the .app file

Electron version: last version
Operating system: MacOSx El Capitan

Hi everyone, I post today because I have a problem with electron/node.js. For my application, I need to create and/or modify file who is store in my .app (after electron-packager) but I have already an error of permission denied. I would like know if it's possible to do that.
Thanks a lot.
PS : Sorry for english, but i'm french.

You can't do that, it will break the signature

Ok thank you !


Fixed export not expanding nested deployments #715 (#717)

PR Summary
Fix for release v1.2.x

Fixed export not expanding nested deployments. #715

Fixes #715
PR Checklist

[x] PR has a meaningful title
[x] Summarized changes
[x] Change is not breaking
[x] This PR is ready to merge and is not Work in Progress
Other code changes

[x] Unit tests created/ updated
[x] Link to a filed issue
[x] Change log has been updated with change under unreleased section

/azp run


fix typo in RouterManager and add method comment

Issues associated with this PR
fix typo and add method comment in RouterManager interface
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

LGTM


feat: Add line chart and paste dialog selection

So it looks like the world is not ready for the fast paste approach. Here is a more deterministic solution by @petehunt's idea.
Copy the following data and experiment in the preview.
N,Fibonacci
F1,1
F2,1
F3,2
F4,3
F5,5
F6,8
F7,13

In this PR
We are adding a third step, but to be honest, in real life we are not a chart replacement and people won't be pasting charts that often, so this is not really annoying as it shows already what is going to be inserted and can keyboard could be used for power users.

[x] Paste chart modal
[x] Show previews of charts
[x] Insert charts in the middle of the screen (@dwelle)
[x] Use Arrow Keys Tab key to choose chart (@dwelle)
[x] Press Enter or Space to insert (@dwelle)
[x] Remember the last choice and have it default next time (blue border) if user press Enter
[x] UI tweaks (colors, size, etc) (@j-f1)
[x] Mobile view (@j-f1)

Possible improvements as we go (if any)

Show Remember my choice and don't show this popup again

Show this popup with a special shortcut that will appear in Shortcuts dialog.

Special shortcuts for pasting directly Bar or Line charts

We can run out of smart shortcuts here

Special submenu in the Context menu for pasting special

Downside it's too hidden and we don't have access to Clipboard in many browsers without permission.

While it adds friction, I reckon you also won't be pasting charts all the time, so it's kinda ok? That said, I noticed showPasteChartDialog which I reckon will allow you to [x] remember my choice. But how do you then revert this choice?

But how do you then revert this choice?

By fast pasting!! 🤣 (Just kidding.. I updated the description)

Reading the updated description, I'd start with what you suggest: simply highlight what was selected previously. Later we can iterate on the remember my choice. I wouldn't add chart-specific shortcuts. As for the contextmenu, that can be implemented as an alternative either way.

I think this is good. Let's implement it and ship it! :rocket:

That preview looks awesome. You see what you will get. (yswywg)
no fancy "fast-paste" but clear UI and open for future graphs.

Fixed the paste bug which was caused by the button being a link with a href that set a hash. This caused a scene re-init. Moved to <button> which is semantic, anyway.
Fixed chart preview color differing from the chart being pasted, by introducing seed.

I got the UI working on mobile (if you hook up a keyboard), but it currently doesn’t present a paste option anywhere. Should this perhaps be in the context menu or something?

You can paste with the context menu!

I've moved currentChartType outside of charts because it doesn't really belong there. We should maybe also rename appState.charts to appState.chartsDialog again?

Yeah.. go for appState.chartsDialog

LGTM except for the issue with pasting on mobile, although we can address that in a future PR

Works nice on Android.. we need to check what's going on on Safari.. @j-f1 can you file a bug report?

Looks good. Merging. :tada:


can.List.prototype.sortIndexes is defined but not referenced

sortIndexes is defined here:
https://github.com/bitovi/canjs/blob/8425837c343efd6828bba1040bdabdd26ab96bea/map/sort/sort.js#L31
But a search yields only one result:
totes:canjs akagomez$ grep -rn "sortIndexes" .
./map/sort/sort.js:31:		sortIndexes: [],

It's possible that it's referenced using some funky string concatenation, but that seems unlikely to me since sort.js itself doesn't utilize it.

Is this an issue to remove that definition?  If so, and removing it causes no tests to fail, please remove it.  Thanks!


Refactor yamlparser_test.go

yamlparser_test.go has test cases involving manifest and deployment files. Classify those test cases and move them to manifest_parser_test.go if its manifest related test case and deployment_parser_test.go if its deployment related test case. Keep test cases as is which involves both manifest and deployment files.

Close it as fixed.


feat: ignore template characters in dashboards

Pull Request
Required Fields
:mag_right: What kind of change is it?

feat

:dart: What has been changed and why do we need it?

When including this repo as a git submodule, it is hard to isolate template objects from non-template ones.  This tells the template engine that these are not to be rendered.

Optional Fields
:heavy_check_mark: Which issue(s) this PR fixes?

https://github.com/kluctl/kluctl/issues/418

:speech_balloon: Additional information?

My deployment has a few layers of templates to simplify parameterization, being able to say "no don't treat {{ }} as parameter elements" makes including these dashboards in my system much easier.

Hi @jcpunk,
Can't you create this file in your repository at an upper level?
Example:
grafana-dashboards-kubernetes/dashboards/*.json

According to https://github.com/kluctl/kluctl/issues/418#issuecomment-1515983188, you should be able to that in your own repo.
I would prefer this solution to avoid including code used by external use-cases.
Let me know if that works for you.

I can go that route; I was merely hopeful to give something back to the project.  But if you don't think it will help anyone else, I'm fine to abandon this PR.

Apparently it doesn't work yet...
I'll merge this PR while waiting for the kluctl fix from @codablock.
Also curious to see if adding a file to the dashboards folder affects other external use-cases.
You already helped both this project and kluctl by creating this request, we now know how to exclude these and a bug is going to be fixed on kluctl side! 😉
Just so you know, I may delete the .templateignore file in this project once it's fixed on kluctl.
Thank you for your contribution!

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


Reset flashed EEPROM to use AppleIGC?

Hey,
I'm on the fence to upgrade to Sonoma, but I worry if I will be able to use ethernet. I previously had to flash my EEPROM to make ethernet work with Ventura.
How would it be now if ethernet won't work in Sonoma. Do I have to flash back the original firmware and use that new AppleIGC.kext? Or can I use that kext also with a flashed EEPROM? Not sure I can find that original EEPROM. :/

Hey.
Ethernet works with the custom firmware. It's not necessary to revert the firmware. But it's still recommended to use AppleIGC for better performance. All you have to do is add the kext and enable the DisableIOMapperquirk. Check my latest EFI folder and changelog for reference.


Document how to download the tool in binary form

Downloading and installing travisqueue using go get is super-slick, but unfortunately it requires that the current machine has a relatively new version of the Go SDK installed.
If your Travis CI machine is using a different programming language, e.g. language: ruby, then the version of the go tool is currently 1.7.x. This unfortunately is too old to build travisqueue as it relies on library methods only found in the 1.8 SDK.
Writing a build script and uploading binaries for major platforms as a "GitHub Release" would be useful, since then it could be easily downloadable from Travis builds. Without needing consumers to resort to upgrading the Go runtime in order to build/install the tool.

Closing out as stale. Please reopen if this comes up again.


i18next debug messages should not be emitted in production mode

Sorry, I left these console debugs with process.stdout.write()!
https://github.com/readium/readium-desktop/blob/5a235e99460f162c887c90840473dbc8558f1272/src/common/services/translator.ts#L77-L89

Fixed via https://github.com/readium/readium-desktop/commit/f2cb0c80b33d321297da3ca7cd664ccf8d8dc69f


Add Celo base package (no dependencies utils)

In an effort to reduce dependency bloating for celo/utils clients, this PR splits it into two parts. The celo/base package is added, which holds all utils code without any external dependencies. The premise is that it will always be safe to add the celo/base package as a dependency, since it will never depend from anything else (this is even enforced by a unit test checking the package.json file).
To maintain backwards compatibility with current celo/utils clients, the parts migrated to base were imported and exported in utils, as in:
import { SomeSymbol1, SomeSymbol2, ... } from '@celo/base/lib/___'
export {
 SomeSymbol1,
 ...
} from '@celo/base/lib/___'

Additionally, some references to celo/utils from celo/contractkit were redirected to the celo/base package. This prevents celo/contractkit clients from bundling unnecessary dependencies that were brought in by unrelated celo/utils code (e.g Bip39)
Relevant unit tests for the migrated parts were copied to the celo/base package, but still maintained in celo/utils to ensure backwards compatibility is not an issue.

Check the comment of the use of libraries as parameters.
I'm also curious about how many utils function are still in contractKit that we could make this sort of, "just add the lib and consume from base", that will only pick what is necessary

Probably a lot! I only moved a few as an example. In a different PR I will continue to move references


Create a discord server

I think a discord server will be useful so that people can discuss among themselves if they face any issue. This is much better than creating issues on github

I agree, I have been meaning to create one for some time 🙂
One thing I just want to make sure of is that useful information and answers to questions are still available publicly and indexable by google, for people who aren't using / don't want to use discord. Perhaps a FAQ section or similar that I'll maintain from time to time.

Link to discord is here: https://discord.gg/b4FTWkxdvT

Thanks


Update Grandle version to gradle-2.14.1-all.zip

https://issues.jboss.org/browse/RHMAP-10276

:+1: Built it successfully on QED1 and started on my device.

@matskiv Thanks for tested it! :sparkling_heart:


[WIP] Changes for Shortcut logic migration to app-model

References and relevant issues
Part of #7059
Description
Since some of the logic created over napari to handle keybindings/shortcuts representation (https://github.com/napari/napari/pull/5064 and https://github.com/napari/napari/pull/5604) could be moved to app-model (https://github.com/pyapp-kit/app-model/pull/211), do some refactoring to be able to use the logic from app-model and adjust any other logic related with shortcuts representation handling over the GUI (shortcuts related widgets).
Notes

Depends on https://github.com/pyapp-kit/app-model/pull/211

app-model minimum version constraint needs to be bumped here (>=0.2.8)

Still checking how the parse_platform logic https://github.com/napari/napari/blob/157b144d90e0a605a5dac68321dcd34250cd6590/napari/utils/interactions.py#L311-L335 should be handled ~and if further changes need to be done over app-model~

Probably this is something that should be handled over the napari side. Could be an oportunity to do a better separation of shortcuts settings representation vs GUI/view representation (an approach as the one described at https://github.com/pyapp-kit/app-model/pull/211#discussion_r1681612250 could make sense)

@napari-bot update constraints


create_perf_json: Add pcu_0 to event check ignores

GitHub actions running create_perf_json.py are currently failing. This commit is a quick follow-up to metrics added in https://github.com/intel/perfmon/pull/250 . Ignores handle equations such as the following.
cbox_0@event\=0x0@
cha_0@event\=0x0@
imc_0@event\=0x0@
pcu_0@UNC_P_CLOCKTICKS@

Thanks Ian!


Update core dependencies

Is your feature request related to a problem? Please describe.
As a user, I want to be able to validate against the latest versions of aind-data-schema and aind-data-transfer-models
Describe the solution you'd like
Update all core packages to the latest version
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Closed by https://github.com/AllenNeuralDynamics/aind-data-transfer-service/pull/184


xorg.libX11 - runtime dependency on xorg.libXcursor?

Issue description
I've ran into a strange situation where certain applications wouldn't respect my mouse cursor settings. An example of that is rxvt_unicode. Stracing urxvt shown the process trying to load libXcursor library which seemed relevant, despite urxvt itself not being linked against it. Some further digging shown that libX11, on which urxvt depends, seems to try loading it dynamically at runtime, and once I installed xorg.libXcursor the issue went away.
Is the requirement of manual installation of libXcursor the expected behaviour?
Steps to reproduce

Install rxvt_unicode package.
Customise any cursor settings for example by adding the following to .Xdefaults:

Xcursor.size:  48

Run

$ xrdb .Xdefaults

Launch urxvt from the same shell session.

Technical details

System: 16.09.git.a574006 (Flounder)
Nix version: nix-env (Nix) 1.11.7
Nixpkgs version: 16.09.1836.067e66a

Does this still work for you? I'm running into the same problem, but xorg.libXcursor is installed.
I can workaround the problem by adding the libXcursor path to LD_LIBRARY_PATH, but that seems like a horrible hack.

I changed my configuration quite a bit since reporting but as is I'm using the same LD_LIBRARY_PATH hack on NixOS 17.03, but specified in global configuration.nix. I can only suspect I had something similar previously and failed to mention that in the initial report. Apologies for that.

@hhomar also, forgot to ask - have you seen this issue in applications other than urxvt? It doesn't seem like a wide spread problem so perhaps it would make sense to fix the individual applications on case by case basis.

lightdm doesn't work without the hack either. I haven't seen the problem in any other applications so far.
I was hoping to find a way to fix all applications, but the only thing I could come up is:
diff --git a/pkgs/servers/x11/xorg/overrides.nix b/pkgs/servers/x11/xorg/overrides.nix
index c7a4ff20a7..132f3ce720 100644
--- a/pkgs/servers/x11/xorg/overrides.nix
+++ b/pkgs/servers/x11/xorg/overrides.nix
@@ -85,6 +85,9 @@ in
     preConfigure = setMalloc0ReturnsNullCrossCompiling + ''
       sed 's,^as_dummy.*,as_dummy="\$PATH",' -i configure
     '';
+    postPatch = ''
+      substituteInPlace src/CrGlCur.c --replace "libXcursor.so.1" "/run/current-system/sw/lib/libXcursor.so.1"
+    '';
     postInstall =
       ''
         # Remove useless DocBook XML files.

The problem with that is it requires libXcursor to be a system package and for the user to know to do that. It doesn't seem any better than using using LD_LIBRARY_PATH.

AFAICT, this issue is not resolved.

Thanks for linking to my post.
The post describes a series of hideous hacks to fix the problem for me, and is limited to solutions that don't require me to rebuild the world. They're clearly not appropriate for Nixpkgs, but it's not obvious how to fix it in Nixpkgs because of the circular dependency.
I think my best proposal would be:

Build and package libXcursor in libX11 so that the two .so files appear in the same directory.
If necessary (I suspect it is necessary), add $ORIGIN to the rpath of libX11.so so that when libX11 calls dlopen, it looks in its own directory and finds libXcursor.so.

If people think this has a shot of getting accepted, I can test it out and make a PR. I'm way out of the loop so not sure who to ask about this stuff.

Just for fun I tried that idea of getting both .so files in the same package: turns out libXcursor depends directly on libX11, but it also depends on libXrender which depends on libX11, i.e. a three-package cycle. So it's looking less likely that it can work.
For completeness, a few other references in nixpkgs:
https://github.com/NixOS/nixpkgs/blob/434dd13b25bfe1db97a7bb32cf772f3493416bc3/pkgs/applications/networking/instant-messengers/ripcord/default.nix#L53
https://github.com/NixOS/nixpkgs/blob/434dd13b25bfe1db97a7bb32cf772f3493416bc3/pkgs/development/libraries/qt-5/modules/qtbase.nix#L218 (used here: https://github.com/NixOS/nixpkgs/blob/434dd13b25bfe1db97a7bb32cf772f3493416bc3/pkgs/development/libraries/qt-5/5.15/qtbase.patch.d/0007-qtbase-xcursor.patch#L19)

One idea I had would be to build the packages each on their own (as is done currently) but then copy them together into a single "libX11" and adjust their rpaths via patchelf.


JITSI Meet - Unable to start - Getting error  Unable to start service org.jitsi.meet.sdk.JitsiMeetOngoingConferenceService@49c5a1c

Unable to start - Getting error  Unable to start service org.jitsi.meet.sdk.JitsiMeetOngoingConferenceService@49c5a1c
E/JitsiMeetSDK( 6792): java.lang.RuntimeException: Unable to start service org.jitsi.meet.sdk.JitsiMeetOngoingConferenceService@49c5a1c with Intent { cmp=com.metisneurotec.metis/org.jitsi.meet.sdk.JitsiMeetOngoingConferenceService (has extras) }: java.lang.IllegalArgumentException: Invalid notification (no valid small icon): Notification(channel=JitsiOngoingConferenceChannel shortcut=null contentView=null vibrate=null sound=null defaults=0x0 flags=0xa color=0x00000000 category=call actions=2 vis=PUBLIC)

Highlight: Invalid notification (no valid small icon): Notification(channel=JitsiOngoingConferenceChannel
Code: using the example from -> https://pub.dev/packages/jitsi_meet_wrapper/example
JITSI version: jitsi_meet_wrapper: ^0.0.6
Flutter version:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.7.7, on macOS 13.2.1 22D68 darwin-x64, locale en-IN)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.1)
[✓] VS Code (version 1.76.2)
[✓] Connected device (3 available)
[✓] HTTP Host Availability
• No issues found!

You can refer to this issue. Here is a solved solution to your problem.
https://github.com/saibotma/jitsi_meet_wrapper/issues/76

Hey there,
please try the newest release.


perplexity[patch]: standardize chat init args

Thank you for contributing to LangChain!
community:perplexity[patch]: standardize init args
updated pplx_api_key and request_timeout so that aliased to api_key, and timeout respectively.  Added test that both continue to set the same underlying attributes.
Related to 20085

@baskaryan related to 20085, let me know if you would like any changes.  My first attempted contribution :)


UG/DG updates for earlier versions.

UG/DG work in progress.
Tag this issue if you have made changes to the UG/DG.

While editing the user guide for #138, I noticed a few things.

User guide states that we have the following commands: delete-schedule, deleteschedule and group command. @AY1920S1-CS2103T-T10-4/developers Are we implementing this?
Based on their CommandParsers, addgroup and editgroup command supports both -r REMARK and -d DESCRIPTION but user guide inconsistently documents both prefixes. I believe this was because of a mixup with the early Tutorial 3 (see #41). I think we can stick to one but I'm not sure which. @Alvinnyk thoughts?
User guide states the addperson, addevent commands supports -c NUS_MOD_LINK but their CommandParsers doesn't seem to be parsing for it. @marqueurs404 Should we should remove it from the user guide or write code to implement it?
User guide has sections for export-ics and import-ics command. @marqueurs404 Should we remove it?
Slightly off-tangent but @YiJiee what happened to your UG update from #114?


Allow source to specify message 'content-type'

Right now my json messages are being input as application/octet-stream
is there a way to specify application/json?

I'm not sure I understand; input into what? Are you meaning the source or matcher part of this plugin?
Can you give some example of your configuration and the messages being handled?

So I have heka pointing events to rabbitmq and need to replace it, we'd like to use fluentd with a rabbitmq plugin.
Here is an example of how the output is seen
Expected output:
<EMAIL_ADDRESS>code here"}
Actual output:
eventtask........-.<.............application/octet-stream..............{"json code here"}
If you look at this other unmaintained amqp plugin, he had an option for content type, and I didn't see one in this amqp plugin so I thought I'd ask

nevermind! They just showed up!
The server reported 1905 messages remaining.
Exchange 	(AMQP default)
Routing Key 	eventtask
Redelivered 	●
Properties
priority:	0
delivery_mode:	1
headers:
content_type:	application/octet-stream
Payload
236 bytes
Encoding: string
{"timestamp":"2017-03-01T23:37:33+00:00","hostname":"new-random.hostname.com","program":"kernel","processid":null,"type":"syslog","logger":"systemslogs","payload":"[164664.907984] audit_printk_skb: 12 callbacks suppressed"}

So when consuming these messages my app expects application/json
It sees application/octet-stream
resulting in:
KeyError: 'octet-stream'
I can likely code for this, but it would be nice to be able to set the content-type appropriately.

I also tried to specify format json, but I get the following:
My config:

    @type amqp
    host "random.host.com"
    port 5672
    format json
    user "mozdef"
    pass xxxxxx
    key "eventtask"
    vhost "/"

2017-03-02 02:04:47 +0000 [warn]: parameter 'format' in
@type amqp
host "random.host.com"
port 5672
format json
user "mozdef"
pass xxxxxx
key "eventtask"
vhost "/"
 is not used.

@Phrozyn Hi,
Maybe this Issue is helpful? https://github.com/giraffi/fluent-plugin-amqp/issues/12

Ok, I see what you're upto here; You're using FluentD + the amqp plugin to capture events from servers to send to brokers, but are then using your own consumer code to read those messages back off the brokers for handling yourselves.
Gotcha. :+1:
Adding an option to specify content-type seems sensible, and while I'm there I'll include an enhancement for #35 and maybe a few other extensions for the other Exchange.publish options (eg TTL, reply_to etc)

Awesome! Thanks, this will help immensely!

This has been fixed by #39 and will be  included in the 0.11.0 release which'll also include #40

released as v0.11.0 thanks,


Unable to Access Flux pods via Istio Ingress - UF,URX upstream_reset_before_response_started{connection_failure}

Hi,
We have Istio 1.12.4 version installed using Operator in Azure Kubernetes Service. Flux is also deployed into AKS using helm charts. Created Virtual Service to expose flux clusters-service via Istio Ingress Gateway and running into error - 503 UF,URX upstream_reset_before_response_started{connection_failure}
Port-forwarding works OK to the service locally to access the UI of Flux. However, the issue is only while trying to access the UI over Istio Ingress. The request is reaching gateway pod and it looks like gateway is unable to communicate to upstream due to some connectivity issue. Tried a curl request from gateway and it is not able to reach flux service on port 8000. However, the upstream flux pods are working Ok and service is also available with 8000 port configured.
Flux pods do not have Istio sidecar by default. As part of troubleshooting the issue, manually injected sidecar as well without any luck. Curl request from the istio-proxy(in the app) is able to access the flux service on localhost, though.
Any inputs on this would be appreciated. Also, please let us know if there are any areas to be checked further.

This is resolved after creating a network policy. Not an issue at Istio side.

@praseed44 istio network policy ? can you give a rough outline？


no matches for tensorflow.org/, Kind=TfJob

I have set a configMap for bare metal environment, and got a problem when I created a TF job. I'm sure that I followed the instructions of README.md file step by step. I attached the error log as below:
error: unable to recognize "tf_job.yaml": no matches for tensorflow.org/, Kind=TfJob

This error indicates that the Custom Resource for TfJob could not be created.
Please take a look at this comment for some initial steps to try to identify the particular cause.
There's a high likelihood that you are hitting the same issue with the ConfigMap.

Thanks for replying. Let me have a look at the comment and refs.

@jlewi I checked my case according to your comment in #149 . The TF Job CRD is not created actually. But, the deployment and pod of TF Job are running. I took a look at the logs of TF Job pod, and found that it may be a authority problem of namespace.
E1127 03:01:44.508964       1 election.go:226] error retrieving resource lock default/tf-operator: endpoints "tf-operator" is forbidden: User "system:serviceaccount:default:default" cannot get endpoints in the namespace "default"

I forgot to set rbac.install=true when I run the helm install instruction. After setting that, the tf-operator is running well. But, I failed to docker pull gcr.io/tf-on-k8s-dogfood/tf_sample:dc944ff. Could you have a look? @jlewi

I confirmed the docker image exists. I also confirmed the bucket is public. Could this be an issue with gcr.io being blocked by the firewall?
In the meantime you should be able to build the Docker image from the repo using https://github.com/tensorflow/k8s/blob/master/examples/tf_sample/build_and_push.py

Ok, I'm going to build the Docker image. Thanks!

@jlewi I noticed that we directly call subprocess to build and push Docker image in build_and_push.py file. I think replace it with Docker SDK would be better and more portable. What do you think?

gcr.io is blocked, one needs VPN to access.

Anyway, the issue of no matches for tensorflow.org/, Kind=TfJob has been figured out. Close this issue. Others who facing same problem can trace #174 , I will create a PR to add troubleshooting guide this week.

I have same problem,  how can i fix?
describe:
"
the provided version "kubeflow.org/v1alpha2" has no relevant versions: group kubeflow.org has not been registered
no matches for kubeflow.org/, Kind=TFJob
"


Vulnerability roundup 63: libexif-0.6.21: 1 advisory

search, files

[ ] CVE-2018-20030 (nixos-19.03)

Scanned versions: nixos-19.03: 5847485e3ec. May contain false positives.

See also #56361


Assertion failure with -DSQLITE_DEBUG=1 build flag

Describe the bug
I build the jar package with export CFLAGS="-DSQLITE_DEBUG=1", then run the following java program with target/sqlite-jdbc-<IP_ADDRESS>-SNAPSHOT.jar and meet an assertion failure. but I run these query with sqlite CLI, there is no assertion failure.
package reproduce;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;

public class reproduce {
    private static final String DRIVER_NAME = "org.sqlite.JDBC";
    private static final String URL = "jdbc:sqlite:test.db";
    private static Connection connection;
    public static void main(String[] args) throws Exception {
        try {
            Class.forName(DRIVER_NAME);
            connection = DriverManager.getConnection(URL);
        } catch (Exception e) {
            e.printStackTrace();
            connection = null;
        }
        List<String> program = new ArrayList<>();
        program.add("PRAGMA encoding = 'UTF-16';");
        program.add("CREATE TABLE t0 (c1 TEXT );");
        program.add("INSERT INTO t0 VALUES ('');");
        program.add("CREATE INDEX i0 ON t0(c1);");
        program.add("ANALYZE;");
        program.add("SELECT * FROM t0 WHERE t0.c1 BETWEEN '' AND (ABS(''));");

        try (Statement statement = connection.createStatement()){
            for(String script: program) {
                try {
                    statement.execute(script);
                } catch (Exception e) {
                    System.out.println(e.getMessage());
                }
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

To Reproduce
export CFLAGS="-DSQLITE_DEBUG=1"
Expected behavior
No assertion failure.
Logs
java: target/sqlite-3.41.2-Linux-x86_64/sqlite3.c:81897: valueFromFunction: Assertion enc==pVal->enc || (pVal->flags & MEM_Str)==0 || db->mallocFailed' failed.`
Environment (please complete the following information):

OS: [Ubuntu 22.04]
CPU architecture: [x86_64]
sqlite-jdbc version 76b90f7

I don't quite understand what you are doing.  SQLITE_DEBUG is a compile time option for Sqlite. Building the jar with this option would have no effect, as the native libraries are already compiled in the repo.

I want to test Sqlite3 and modify this line https://github.com/xerial/sqlite-jdbc/blob/master/Makefile#L40 to download the latest commit version of Sqlite3. So I will build the Sqlite3 and SQLITE_DEBUG will have effect.

I want to test Sqlite3 and modify this line https://github.com/xerial/sqlite-jdbc/blob/master/Makefile#L40 to download the latest commit version of Sqlite3. So I will build the Sqlite3 and SQLITE_DEBUG will have effect.

That is not at all what you explained in the first message. If you can't explain what you do, how can you expect people to help?
Anyhow the failures are in the C code, so nothing related to sqlite-jdbc.

Thank you for your reply! This only occurs with JDBC driver, but I tried it with latest source code and can not reproduce, maybe it has been fixed. I close this issue.


C++11 and Godot

Is Godot tolerant to the C++11 standard? It seems Windows, Linux, Android, iOS, and Mac all support C++11 (at least the newer versions) so I was wondering if it was ok to write modules using it.

You can write modules using it as far as I know, but it's not used in the main code base (by choice AFAIK).

For modules i can't see why not. Godot does and will not use C++11 in the
near or medium future
On Tue, Jan 26, 2016 at 11:52 AM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

You can write modules using it as far as I know, but it's not used in the
main code base (by choice AFAIK).
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3456#issuecomment-175056921.

Awesome! I just wanted to make sure I wasn't going against any design standards / requirements by the Godot team.


A AI accelerator HDDL in Edge Computing

Abstract
Intel today introduced the Movidius Myriad X Vision processing Unit (VPU) which Intel is calling the first vision processing system-on-a-chip (SoC) with a dedicated neural compute engine to accelerate deep neural network inferencing at the network edge.
Intel also Unleashes a HDDL PCI card which integrates several Myriad VPUs for Edge Computing for AR/VR and AI scenarios.
In this talk, we will first introduce some details of Movidius VPU and HDDL, how it is managed in Edge cloud.  Also will give a demo to mange the HDDL and to use it for an AI inference.
Related Upstream Open Source Projects
OpenStack Nova, OpenStack Cyborg, Kubernetes
Category
Accelerator Hardware
Cloud Platform Management Support For Accelerators
Applications With Accelerator Support (AI, 5G, Edge/IoT, HPC, Quantum Computing, Neuromorphic Computing, etc)
Speaker Bio (no more than 2 people)
Shaohe Feng, Senior Software Engineers,  INTEL
Got involved in OpenStack for 5+ years and Kubernetes for 2+ years. Mainly focus on accelerator management. Interests include AI technology, hardware acceleration, network and so on.
Speaker email
ShaoHe<EMAIL_ADDRESS>

Move to part of the unconference discussion


RSPec cosmetic warnings

Cosmetic, but still they show up in my project when running RSpec with warnings on:
/home/mic/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/amazing_print-1.0.0/lib/amazing_print/formatter.rb:29: warning: mismatched indentations at 'end' with 'else' at 27
/home/mic/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/amazing_print-1.0.0/lib/amazing_print/formatters/object_formatter.rb:22: warning: mismatched indentations at 'end' with 'else' at 20
/home/mic/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/amazing_print-1.0.0/lib/amazing_print/formatters/base_formatter.rb:126: warning: possibly useless use of * in void context
/home/mic/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/amazing_print-1.0.0/lib/amazing_print/formatters/struct_formatter.rb:22: warning: mismatched indentations at 'end' with 'else' at 20

Should be fixed by #18


Support Swift2.3

Current coverage is 100% (diff: 100%)

Merging #3 into master will not change coverage

@@           master    #3   diff @@
===================================
  Files           2     1     -1
  Lines          58    18    -40
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
- Hits           58    18    -40
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update fe55cc8...7b6b54e


Support a dictionary of tensors as a CompositeTensor

TensorFlow version (you are using): 2.0.0b1
Are you willing to contribute it (Yes/No): No

Describe the feature and the current behavior/state.
The CompositeTensor base class offers a unified way of handling various types of tensors that are themselves composed of tensors. Currently, dictionaries of tensors are not supported; it would be useful if they were.
Will this change the current api? How?
Yes, by adding to the types of structures that can be treated as a CompositeTensor.
Who will benefit with this feature?
Dictionaries are one of the more convenient ways to manage collections of heterogeneous features. In issue #27679 (Passing a dictionary of tensors to py_function), it was stated that in that case, creating a subclass of CompositeTensor that can represent a dictionary would be one path to ultimately supporting dictionaries of tensors in py_function.

Most APIs that support composite tensors also support nested structures (as defined by tf.nest.  In particular, the tf.nest functions include an "expand_composites" argument that tells tf.nest that it should treat composite tensors as nested structures.
Therefore, we don't need a CompositeTensor for dictionaries -- we can just use dictionaries as is.  But what we do ned is to extend py_function to use tf.nest to do appropriate flattening and repacking of tensors at the input & output boundaries.  (Using "expand_composites=True" will ensure that this supports both "normal" nested structures and composite tensors.)
Closing this issue, but adding a similar comment to issue #27679.


Scroll bar jumps up when sorting

Hello
When I try to sort, the whole page scrolls up which causes strange experience when sorting. I found
http://stackoverflow.com/questions/1735372/jquery-sortable-list-scroll-bar-jumps-up-when-sorting
Is there a possibility to implement this into ui-sortable?
Thank you

@thgreasi has there been any progress on this? sorry to dig up an old issue but none of the SO solutions (settings height or using a placeholder) have worked for me.
Thanks

@thebucknerlife since this is marked as a jquery-ui related issue, I didn't put any extra effort on this.
Hopefully some stackoverflow research on jquery-ui-sortable might give you some results.

Very very very very very very very bad there isn't a good solutions for this yet.
The so called "solution" above is crap if you the draggable items within your sortable do not have the same size, like in my case.

@basvandenheuvel Very very very very very very very bad that you haven't made a solution and submitted a pull request. The dev community does not exist to make your life easy-peasy. Sack up and fix it if you want it fixed.

@mcblum welcome to github, you must be new around here :) Complaining about stuff does not equal to "i can do it better". Welcome

@basvandenheuvel True, but maybe a little tact would be nice considering you're using something that you didn't pay for. Commenting on a bug, reporting something that doesn't work, all fine.  Welcome


Adding an option to preserve spacing during HTML to Slate deserialization

Description
Currently, when deserializing HTML to Slate, the deserialization function removes excess whitespaces, causing issues in a specific chord editor application where it is crucial to maintain specific spacings between chords within the sheet music.
Context
The application in question is a chord editor that requires preserving multiple spaces between chords to ensure correct spacing.
Proposal
A Pull Request has been submitted proposing a modification to the deserialization function's settings, adding an option that allows the preservation of spacings as necessary for the specific chord editor application.
Link to Pull Request
https://github.com/thompsonsj/slate-serializers/pull/114

Thanks!
Test added in https://github.com/thompsonsj/slate-serializers/pull/116. Not all whitespace is preserved so let me know if you think that should be changed.
Released in https://www.npmjs.com/package/@slate-serializers/html version 2.1.0.


ogr2ogr output:    Segmentation fault (core dumped)

https://cartodb.supportbee.com/tickets/4048685

New ogr2ogr version already deployed fixes this error \o/


Show documentation URL in Gatekeeper error messages

Is your feature request related to a problem? Please describe.
The problem is that we have Gatekeeper-enforced safeguards in place that people might not understand.
Describe the solution you'd like
If a request would violate a safeguard, Gatekeeper will stop it. We should help users understand what went wrong by putting links to our documentation in the error message.
So instead of this:
$ kubectl run nginx --image=nginx --restart=Never
Warning: [require-harbor-repo] container "nginx" has an invalid image repo "nginx", allowed repos are ["harbor.long-running.dev-ck8s.com", "quay.io/jetstack/cert-manager-acmesolver", "quay.io/metallb/controller:v0.13.7", "jaegertracing/jaeger-tracegen"]
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-resource-requests] Container "nginx" has no resource requests
[container-image-must-not-have-disallowed-tags] container <nginx> didn't specify an image tag <nginx>

...imagine if each error message linked to the appropriate safeguard that we have put in place.
Describe alternatives you've considered
Not doing it, I suppose. But stuff like "has no resource requests" is a very short and unhelpful way of putting it, so it would be better if it was more helpful and also linked to the docs, which we can easily improve upon as well.
Definition of done:

[ ] All the safeguards that we put in place have appropriate links in their error messages (see screenshot below for which these are)
[ ] Optional: It is made clear that we are the ones making the rules, by using a prefix such as elastisys- for each rule

Ideally, instead of [container-image-must-not-have-disallowed-tags] container <nginx> didn't specify an image tag <nginx>, it would be: [elastisys-container-image-must-not-have-disallowed-tags] The container named <nginx> didn't specify an image tag. Elastisys Compliant Kubernetes requires all images to have tags to avoid the implicit :latest tag. Read more at https://elastisys.io/compliantkubernetes/user-guide/safeguards/enforce-no-latest-tag/

Smart!

This really has two tasks in it, namely:

[ ] The actual textual changes (should be super small, given it's a handful of strings that need changing)
[ ] Deploying to the long-running cluster, so that we can see this running live


Consider using werkzeug for routing

Here's a test case:
def test_overload_dynamic_routes():
    app = Sanic('test_dynamic_route')

    @app.route('/overload/<param>', methods=['GET'])
    async def handler1(request, param):
        return text('OK1: ' + str(param))

    @app.route('/overload/<param>', methods=['POST', 'PUT'])
    async def handler2(request):
        return text('OK2: ' + str(param))

    request, response = sanic_endpoint_test(app, 'get', uri='/overload/bla')
    assert response.text == 'OK1: bla'

    request, response = sanic_endpoint_test(app, 'post', uri='/overload/bla')
    assert response.text == 'OK2: bla'

    request, response = sanic_endpoint_test(app, 'put', uri='/overload/bla')
    assert response.text == 'OK2: bla'

    request, response = sanic_endpoint_test(app, 'delete', uri='/overload')
    assert response.status == 405

    with pytest.raises(RouteExists):
        @app.route('/overload', methods=['PUT', 'DELETE'])
        async def handler3(request):
            return text('Duplicated')

The reason is, that while a route gets replaced with a CompositionView in routes_static and routes_all, it still lives in routes_dynamic next to the CompositionView.
@youknowone , since you implemented that feature you're probably most familiar with that section of the code. Would you mind fixing this issue?

I found the reason and I tried an ad-hoc fix but It is very unreliable.
I think using werkzeug makes the problem easier, which is used by flask.

Ya, that's what I thought first when I saw that Sanic implements its own routing. werkzeug routing is very powerful and the library also offers other very helpful and well tested stuff. The only thing i don't like about it is, that it has some focus on WSGI. However, that's not the biggest part.
@seemethere @r0fls @channelcat What do you think about replacing Sanic's routing with werkzeug?

I think sanic should do. And more.
If I have right of voting for future of sanic, I believe sanic should import designs and codes of flask as much as possible. The are maintained and tested. Both projects have compatible licenses.
I suggest the strategy:

Set basic design policy of sanic which will be different. (ex: context-local is not sanic)
Copy designs of flask unless it conflicts to 1 or it has defects.
Implementations can be made in a cheap way. Bring codes or write new codes.
For non-async codes, we even can bring codes. like routing.

Routing is on the critical path for performance. Another project to look at for inspiration is the Falcon framework which, also being performance focused, has chosen to compile the route logic:
https://github.com/falconry/falcon/tree/master/falcon/routing

I tried werkzeug a little: https://github.com/youknowone/sanic/commit/0c636a5c36f611e301fe9f43e90f19f85889b164
It doesn't look very easy but possible to have werkzeug router as an option.

@youknowone How does doing that affect performance?

@seemethere I didn't test performance. I tested its working and it even is not working that well yet. (But it seems I am expecting another side of performance in sanic, so I am actually less interesting for the routing cost)
I think having werkzeug router not as a full replacement of sanic router but as an optional replacement will be a good choice regardless of its performance.

I profiled average route search time with 650 generated routes in Werkzeug and Sanic using the following script: https://gist.github.com/subyraman/8704f9a168d8261c0dde815f0068c224
average werkzeug time to find route: 0.0004255075638110821
average sanic time to find route: 0.0002654151733104999

But in a real world scenario there could be more efficient caching of the werkzeug router call.

Since the original bug has been fixed and the discussion went into another direction I changed the title. Could someone remove the bug label?

So.. what are the pros for using werkzeug? I think we should stick with the Sanic routing:

it's async
it's apparently faster (https://github.com/channelcat/sanic/issues/353#issuecomment-275957049)
it's ours, so we don't have to open PRs to improve things

@r0fls I think the argument is that it's more battle-tested than sanic's but imo I don't know if the performance drop-off would be worth it

@r0fls How is the routing async? werkzeug is tested very much and also it has all features developers needed for years. I think we have still a lot of work before us with Sanic, we can be glad about anything we don't have to implement.

Pulling in the behemoth that is Werkzeug (an entire WSGI Compliance Framework) to use it only for routing is not a great idea in my opinion. Sanic currently has only a few very-needed dependencies, and is very lightweight because of that.
Other downsides would include it being completely WSGI centric (ASGI is not even out yet, focusing on these things right now is kinda pointless), the apparent performance dip, it's extremely verbose and annoying to use, and on a more personal level, among all the reasons I have for my growing dislike of Flask, Werkzeug is ranking high up on that list.
Current routing works fine, I'd say keep it.

Sanic's routing isn't async per se, it loops through registered routes and
does regex matching against each (probably some optimization can be made
there). It's not blocking, but neither is werkzeug ;)
The Sanic router is okay, and definitely more easy to understand than
Werkzeug. But Werkzeug is definitely very mature in my opinion and accounts
for a ton of edge cases which will eventually hit Sanic. Like I'm working
on a 'url_for'  method right now for Sanic and I can already see the issues
that could crop up in routing.
I would lean towards not including Werkzeug, but maybe a case can be made
for forking the basic router and optimizing it.
On Wed, Feb 1, 2017, 5:56 PM Luiz Berti<EMAIL_ADDRESS>wrote:

Pulling in the behemoth that is Werkzeug (an entire WSGI Compliance
Framework) to use it only for routing is not a great idea in my opinion.
Sanic currently has only a few very-needed dependencies, and is very
lightweight because of that.
Other downsides would include it being completely WSGI centric (ASGI is
not even out yet, focusing on these things right now is kinda pointless),
the apparent performance dip, it's extremely verbose and annoying to use,
and on a more personal level, among all the reasons I have for my growing
dislike of Flask, Werkzeug is ranking high up on that list.
Current routing works fine, I'd say keep it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/channelcat/sanic/issues/353#issuecomment-276810390,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD2voJsCG_HOBEVDZ5ONI9EsN6YzvO3hks5rYQ2pgaJpZM4Lvk1L
.

I can agree both for using werkzeug or not, but I feel awkward about a few reasons of them.
Before starting, I upvote for @luizberti's bottom half and @subyraman for reasonability.
Sanic's router is not async and it shouldn't be async. async is not a boost-up magic but it consume additional operational cost. We can take advantage from that only when it has waiting time due to IO (or something similar waiting like that). To make it clear: routing is not an IO job.
Generally speaking, we shouldn't forget 2 factors in performance engineering

Remember Amdahl's law
Poor features lead better performance

I am not sure this is also true for others, but at least for me, routing cost was never a big deal for me because the major performance drop usually is coming from the user code. When it actually makes problems, it would be not resolvable by sanic's router (because it's routing is not optimized for that kind of flood of connections - of course same for werkzeug too), but it is better to write specialized routing on a request middleware.
Will sanic's router be light as well as now? If we keep it with these poor features, yes. Otherwise, not sure. Generally, when you implement more features in sanic's router, they usually drops the performance (which still is not very big part of the performance, though). Will sanic always have the poor features? I didn't expect it when I read "Sanic is a Flask-like" on the README. Will sanic improve the routing without performance drop? We can start it from better code base. @subyraman made a nice about it.
Routing costs cheap and sanic's goal is async rather than routing. Every project consumes human resources for features. Investing them to problems which already solved will not be as good as enhancing async server itself.

I didn't get the point why werkzeug is "heavy".
For installation point of view - it is 300kb and nothing other dependency.
For performance point of view - it asks reasonable cost for the features. About WSGI features, it will not affect your performance when you don't use it.
For the package size, it still can be splited. (But I don't think it is worth to do for a few kb by paying additional cost for management)

OK, agreed I misspoke saying it was async. It is apparently faster though. It is also targeted at python 3 (werkzeug still supports ancient python 2 versions iirc).

I would never advocate for use refusing to implement any decent feature in the name of sheer performance alone (unless the hit is too big of course), my only point here is to avoid feature and dependency creep.
In my opinion Flask overshoots it's feature set, and I would suggest us not borrowing absolutely everything we can from it as you seemed to suggest. Flask is terribly inconsistent in a lot of ways, and is not a "role-model project" by any means. Flask is widely used because all you have to do is pop a few @app.routes here and there and you'll have a working prototype, the 0-60 time is very fast. To that extent, which is Flask's most important aspect, I'd say Sanic can absolutely call itself Flask-like, cause the interface is very similar, and it's equally as easy to pull something out of nothing with it.
Flask has a lot of merit on it's own, but there is a big difference between being Flask-like and being an Asynchronous-Flask. I would aim for the first: Take what works, don't take what doesn't, keep the surface small and simple, let the users make extensions that provide extra functionality. In my opinion that is much more sane than just trying to reimplement everything that Flask has on an asynchronous backend, and this does not imply in anyway that we should keep a poor feature set in Sanic for sake of performance.
Sanic currently fills it's own niche, and for people who need something more along the lines of Flask, well, Flask is not going anywhere. 😉

All that being said, pulling in all of Werkzeug only to use a fraction of it's feature set is a poor decision in my opinion, and I would much rather go with @subyraman's idea of taking a good look into how it does routing and seeing what would be worthwhile to mimic in Sanic. We could start slowly optimizing Sanic's routing from what we currently have, then slowly start bringing in new improvements over from Werkzeug.
I value the current router a lot for it's simplicity, it's so small and easy to understand. The cost of having to look though Werkzeug's (horrible) documentation to implement things is something that will bring us only pain. Moreover Werkzeug is geared towards Flask's use cases and WSGI, and it may evolve into taking design decisions that don't necessarily favor our usage of it.
On a last note, routing is simple! It's definitely not the biggest worry in a project like this, and we could very well do it ourselves like we do today. Why not just take what we need from Werkzeug?

Closing, I think we've reached a consensus centered around @luizberti's comment.


April 2024 Steering and Technical Committee (STC) meeting

TBD

Agenda Item
I would like to reopen discussions about being more direct about the future deprecation of the Query API.
IMO It's not good that users are continuing to adopt it and hitting issues, while being unaware that there is no appetite to support it.

Agenda Item
I would like to reopen discussions about being more direct about the future deprecation of the Query API.
IMO It's not good that users are continuing to adopt it and hitting issues, while being unaware that there is no appetite to support it.

I agree with that item. We need someone to have the time commitment to fix this. I am dedicating most of my business hours working on the distributed scheduler, which (AFAIK) wins in priority when compared to the document store API (which, AFAIK, is the vision to fix this issue).

Agenda item proposal: #470

The meeting occurred and notes captured


Calling  keyword-only function without arguments crashes with NPE

The following valid Python 3 code:
def func(*, a=1):
    print(a)

func(a=2)
func()

... gives the following output in CPython:
$ python functest.py
2
1

... but raises NullPointerException if compiled and ran with VOC:
+ java -cp ../voc/dist/python-java-support.jar:. python.functest.__init__
2
Exception in thread "main" RuntimeError: java.lang.NullPointerException
	at org.python.types.Function.invoke(Function.java:412)
	at org.python.types.Function.invoke(Function.java:347)
	at python.functest.__init__.func(functest.py:2)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.python.types.Function.invoke(Function.java:388)
	at org.python.types.Function.invoke(Function.java:347)
	at python.functest.__init__.module$import(functest.py:5)
	at python.functest.__init__.main(functest.py)

I would like to work on it. Could you provide some hints on where to start?

@Ostrea Hey! I don't really know much more than what's in the above report at the moment.
The problem might be on the bytecode generated (in ast.py file) or in the code for calling functions (since it happens at runtime), it needs some debugging.

Thanks, will try to find problem

Hello, I tried debugging this problem , This runtime error is caused by  java.lang.reflect.InvocationTargetException e on line no : 399 in the Function.java file
..this exception in turn occurs when there is an error in the function which is wrapped by invoke.
.Thus there appears to be a bug in the adjustArguments(instance, args, kwargs) method..I think the bug is in this code : if (n_args == 0) {             return null;         }
line: 262
Also to check whether the control is passing on to this function or no can we use System.out.println()
or do we have to use another method..
Kindly guide me ahead..or am I going in the wrong direction :(

According to my debugging the problem is on byte code level. Current implementation doesn't generate default args values for arguments with type KEYWORD_ONLY, thus we get null in invoke.

I have fixed this issue, but it has caused problems with varargs. Should I pull request changes and start new issue for varargs?

@Ostrea you should not create issues for problems, unless they're reproducible with the code from the official master branch.
You can still create a pull request so we can do an initial review, though.

Okay

Attempting to compile a function with one keyword-only argument is also failing:
def func(*, a):
    print(a)

func(a=2)

The above under CPython works, printing 2, but attempting to compile it with VOC causes an error:
  File "/home/elias/src/voc-dev/voc/voc/python/ast.py", line 218, in visit_FunctionDef
    function = self._create_function(node, node.name, node.decorator_list)
  File "/home/elias/src/voc-dev/voc/voc/python/ast.py", line 975, in _create_function
    self.visit(node.args.kw_defaults[index])
  File "/home/elias/src/voc-dev/voc/voc/python/ast.py", line 165, in visit
    print('Node: %s' % dump(node))
  File "/home/elias/src/voc-dev/voc/voc/python/debug.py", line 45, in dump
    raise TypeError('expected AST, got %r' % node.__class__.__name__)
TypeError: expected AST, got 'NoneType'


fix(rust-lang/rust-analyzer): use gnu instead of musl target env

Check List

[x] Read CONTRIBUTING.md

[x] Read OSS Contribution Guide

[x] All commits are signed

This repository enables Require signed commits, so all commits must be signed

[x] Avoid force push
[x] Do only one thing in one Pull Request
[ ] Execute cmdx s to scaffold code
[ ] Install and execute the package and confirm if the package works well

rust-analyzer is actually dynamically linking musl libc, it's more generic to use gnu libc instead
$ file ./rust-analyzer-x86_64-unknown-linux-musl
./rust-analyzer-x86_64-unknown-linux-musl: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=3ee6d6ae7f11ba8557005ec900f137e324c7402e, not stripped
$ ldd ./rust-analyzer-x86_64-unknown-linux-musl
        linux-vdso.so.1 (0x00007ffc8bbc5000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fde7043a000)
        libc.musl-x86_64.so.1 => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fde70259000)
        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007fde727cf000)

$ file ./rust-analyzer-x86_64-unknown-linux-gnu
./rust-analyzer-x86_64-unknown-linux-gnu: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e63d6ba979f0c5ebf3959550cd1af2d3539db2d2, not stripped
$ ldd ./rust-analyzer-x86_64-unknown-linux-gnu
        linux-vdso.so.1 (0x00007ffcaa7a0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5d51b81000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5d51b7c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5d4f521000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5d51b77000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5d4f340000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5d51bab000)

refs：

rust-lang/rust-analyzer#13086
rust-lang/rust-analyzer#7658
rust-lang/rust-analyzer#16793

Thank you for your contribution!
I'm not familiar with this field, so I'm wondering which musl or glib we should choose.
Maybe we should update the document:
https://aquaproj.github.io/docs/develop-registry/registry-style-guide/#consideration-about-rust

linux: use the asset for not gnu but musl if both of them are supported
ref: https://github.com/aquaproj/aqua-registry/pull/2153#discussion_r805116879

In my understanding, musl is more portable than gnu because musl is built by static link.

--
https://superuser.com/a/1787079

GNU C Library (glibc) is the standard library used on many distributions. musl libc (muslc) is a new C library aiming to be lightweight, fast, simple, free, (annoyingly) correct. Musl is used on some distributions like Alpine Linux.

Maybe we should update the document:

No, in fact statically linking musl is indeed more portable than dynamically linking gnu libc.
However, for rust-analyzer, the use of dynamically linked musl libc instead of static linking is to support the Procedural Macros feature, but most linux distributions widely pre-install gnu libc instead of dynamically linked musl libc, which may also cause the libc.musl shared library not found problem. The problem is that the dynamically linked musl rust-analyzer loses its portability.
For the rust-analyzer scenario, the issue of compatibility between different versions of gnu libc is probably not very important. https://github.com/rust-lang/rust-analyzer/issues/16793#issuecomment-2016396816
refs:

High-level Differences between glibc and musl
Why not always statically link with musl?

I see. Thank you for your detailed explanation!

🎉 https://github.com/aquaproj/aqua-registry/releases/tag/v4.284.2