fix: correct toggleService logic in filters.tsx

PR-Codex overview
This PR improves the toggleService function in filters.tsx to correctly handle service selection in the client filters.
Detailed summary

Refactored logic to toggle service selection based on existing parameters
Improved handling of adding/removing services in the search parameters

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#2660  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jnsdls and the rest of your teammates on  Graphite


remove seperate sass, postcss build pipelines

Changes

Remove separate sass build pipeline, replaced with @snowpack/plugin-sass
Remove seperate postcss optimize build pipeline, to be replaced with built-in optimize.minify once #1615 lands

Good idea! I'd been meaning to do this. LGTM.


WIP: Refactor bugdown to markdown

https://chat.zulip.org/#narrow/stream/3-backend/topic/zerver.2Elib.2Ebugdown
Testing Plan:
Ran backend tests after each commit
GIFs or Screenshots:

@thedeveloperr are the parts you've done so far ready for a review?

There's some whitespace anomalies in the commit message.  But the strategy is a fine one.

@timabbott  will be done within 4 hours

@timabbott sorry I read your message wrong in a hurry. So far the commits pushed are ready for review.

@timabbott isort linting error are coming after I rebased with master. Can you plz review the existing commits while I solve those lint errors ? Thanks

Aside from this isort issue, this looks good; are you OK with my merging the commits thus far?

I merged what you have so far as 4224ac1b617ed3d116dcfe6926501b440a8e792c, after redoing 81d587d77186531ce8f9dba3eb8a0d29fcb2b472 and the couple commits before it to avoid the pattern of importing zerver.lib.markdown in a way inconsistent with basically all other imports in Zulip.
There's a good amount more to do to finish cleaning this up (BTW I'd change the test_fixtures.json to use backend instead of bugdown) and update documentation, but overall this is great progress.
Thanks @thedeveloperr!

(Let me know when you have the next PR; just wanted to merge this to head off merge conflicts).


zsh: command not found: nanopolish

I follow the below commands:
git clone --recursive https://github.com/jts/nanopolish.git
cd nanopolish
make

But there is always the error:
zsh: command not found: nanopolish

You need to provide the full path to the program: /home/example/nanopolish/nanopolish


Cant download a entire show from Crunchyroll

That is, I am trying to download from a direct show URL but it just stays on
"Trying to login" -> "Logged in successfully..." and nothing happens, but trying an individual URL from a specific episode works perfectly.
I got the lastest version and got it working for months.

You are the third one having this issue, it work for me so I really don't know what causes this.

Yesterday it was working, so its probably a thing from Crunchyroll, but single url episodes are working without problems.

Try using VPN, it might caused be blocking some connection, due to some debug from others it might be because some resources has been blocked, so the application tries to retrieve them and keep doing it forever.
you can use "verbose" option to see "error-log" file, remove your login from it and paste in the next comment.

DEBUG: You have successfully set the Debugging On.
DEBUG: Arguments Provided : Namespace(input=['https://www.crunchyroll.com/es/that-time-i-got-reincarnated-as-a-slime/es'], language='Japanese', password=[''], range='All', resolution=['1080p'], skip=False, username=[''], verbose=True, version=False)
DEBUG: Operating System : Windows - 10 - 10.0.17134
DEBUG: Python Version : 2.7.15 (64bit)
DEBUG: You have successfully set the Debugging On.

Let's wait for @Xonshiz to see it himself, he might know something I don't.

I can confirm the show links don't work, but individual episodes still work.

Just browsing a similar issue on youtube-dl page and apparently changing the user agent in the code might have a bit of a effect
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
But I don't know how many times it is referenced in the code so it might be a bit tedious to change.

Still not working. Tested with #ho-tross User Agent but it didnt work

Looks like it might be working again.  During the time it wasn't working, thumbnails for most recent episodes weren't working, just tried with Black Clover on Crunchyroll and it was able to download last week's and this week's episode no problem.


Data item to associate with a concentration

I am wondering how you encode datums about concentrations. I'm guessing you just have separate tabular columns in a database for that?  For example:

In an RDF graph view could I have an instance of a "concentration data item" which "is about" the concentration above?
In a pesticide ontology I was thinking of this structure that provides information about active ingredients of pesticides (where "has active ingredient" is a subproperty of "has part":

So here the concentration data item references an instance of a chemical its about, and that instance is part of the pesticide (or active ingredient of it).  Would this be criticized as leaving implicit (via the part of relation) what is bearing the concentration?
(Note the concentration datum wouldn't "inhere in" the instance of the chemical.)
[edit:] P.s. I ask this of you folks knowing how pesticide chemicals end up in concentrations in food samples along with nutrients so a strong alignment of data capture as well as generic "concentration of" semantics seems appropriate.

Put another way, if you have a concentration value and unit in your database, how exactly do you represent that in a graph database?

@ddooley I hope this helped, please let us know if you have any other questions.

I get the gist of how you enable a variety of things to be referenced - nutrients, plants, and anatomical parts of plants.  But what does a concentration datum look like?

@Graham-J-King do you have any example?

Apologies for the late reply @ddooley
According to @Graham-J-King (as he is working with the associations)
Short answer = 0.285 😊
Longer answer = here is an example with just one (CDNO) term associated with the trait_descriptor_id field.
Of course we can make more sophisticated queries with a FoodON (NCBI/PO) term associated with the plant_accession column, OM term with trait_descriptor.units field etc.

Please let us know if you have any questions.


Add Cluster Logging

Stories

As operator I want cluster logging, so that I can check on my cluster(s).

Motivation
We need means to get to the logs of our own (cluster)s.
Acceptance Criteria

[ ] All container logs are exposed to admins in a remotely accessible UI
[ ] Historic data is kept for the past two weeks (and truncated if it exceeds a certain unreasonable size)
[ ] CPU & Memory footprint is reasonable/small (if not we may have to consider having only one stack per seed; in that case we might also rethink our monitoring stack approach)

Out Of Scope

Like with the monitoring data we accept the loss of all logs when the Gardener has to drain a seed of its shoot clusters or loses its seed cluster for good and must move the shoot cluster control plane to another seed cluster

Implementation Proposal
Please check out the EFK stack (Elasticsearch + fluentd + Kibana; see various blogs, e.g. https://logz.io/blog/kubernetes-log-analysis). Is it what we should use?
If yes, should we handle it like the monitoring stack:

Aim at a logging stack that is co-deployed with every shoot cluster control plane and monitoring stack
Investigate what needs to be done technically to get to the logs in the shoot cluster namespace in the seed and the kube-system namespace in the shoot
Find our what needs to be done to contain the costs, i.e. keep historic data for the past two weeks and truncate it if it exceeds a certain unreasonable size

Definition of Done

[ ] Knowledge is distributed: Have you spread your knowledge in pair programming/code review?
[ ] Unit Tests are provided: Have you written automated unit tests or added manual NGPTT tickets?
[ ] Integration Tests are provided: Have you written automated integration tests?
[ ] Minimum API exposure: If you have added public API, was it really necessary/is it minimal?
[ ] Operations guide: Have you updated the operations guide?

Ticket is on hold until management has decided whether we may do it ourselves or have to wait for some central service.

Any idea what this "center service" would look like?

Decision is to follow the well established pattern we already went for with the monitoring stack.

This issue is being worked on in PR #176


Fix link issues

Fix following redirections:
https://github.com/linkedin/RocketData redirects to https://github.com/plivesey/RocketData
http://componentkit.org/ redirects to https://componentkit.org/
http://mobilecouch.co/ redirects to https://mobilecouch.co/

          1 Warning

:warning:
Too many changes (when adding, please keep it to one project per Pull Request)

  Generated by :no_entry_sign: Danger

Thanks!


Introduction to Chakra UI: A powerful component library for react

Great job! I like that there are many code snippets provided along with images where necessary. It was also nice that relevant links are embedded throughout the document for readers to get more information. One minor suggestion is to have a prerequisites section and providing resources for readers to learn or ensure they have the necessary prerequisites before reading this guide.

Closed as it does not follow the required format for the assignment.


Add option to prevent migrations from creating initial page/site

I feel this is a very elegant solution to the concerns in #1937.

Rebased on top of upstream/master.

Ah, actually, I found a little bug: the Wagtail migration code forces the root page's numchild to 1, assuming it will immediately get a child (that is has MP_Node properties set manually).
I'll have to fix that...

Hi @akx,
Thanks! This change looks sensible enough to me (subject to the numchild fix being made, of course), but I've never tried loading initial site data through fixtures/migrations, so I'm not really clear about what it achieves in real terms. In other words, I'd like to understand:

why the initial data is so annoying to deal with (if you're using fixtures, doesn't it get overwritten in the ./manage.py loaddata step anyhow?)
what a developer would need to change in their process to take advantage of this setting
how they would benefit as a result

@jordij, @timheap: I'd be interested to hear your thoughts - does this change fit in with the way you're handling initial data?
One thing I'm wary of is adding a settings flag and calling it 'done'... that means we're really just multiplying the number of possible configurations we have to support, without making things better for the average user (who isn't going to read through the reference docs to find out about new features they can use). If this is indeed a better way of doing things - rather than just a different way - then we ought to reflect that in our tutorials and project template where appropriate. Basically, I don't want to fall into the git trap, where there are all kinds of powerful features available, but they're hidden behind obscure switches that only the 'power users' know about because nobody dared to step up with an opinion and say "this is the configuration that 99% of users should be using, so let's set it up that way out of the box" :-)

There is a conflict here between new users and power users unfortunately. New users want a functioning Wagtail site out of the box. Providing them with the suggested Site, hope page, and some default user groups makes sense, and makes the initial set up very smooth and nice. Power users might want to create multiple sites, with many different home pages. The initial page structure may not work right for them. They might want a more complicated user and group set up. All this means that the initial sites, pages and groups get in the way, and have to be deleted before the real data gets created.
My preferred set up would be to have Wagtail create no initial data except for the root page of the tree. Not the home page, but the actual root page. No groups, no sites, no pages, nothing. Then, as part of the wagtail start projectname template, a migration should be created that creates these initial pieces of data for the user. New users would have all the initial data required to get started, while power users could customise this initial migration as much as they need to to install their own data - or remove the migration completely and create the initial data in another way.
Sadly, this proposal is quite difficult to achieve in a backwards-compatible manner, without having a flag new projects can set that indicates this initial data will be created by the project, which is partially  what this PR is about.

I fully agree with Tim on this one

Agreed. Nothing more to say to Tim's explanation.

So, if I've understood correctly - this PR could be turned into @timheap's ideal setup (or at least an approximation to it...) by:

leaving the WAGTAIL_MIGRATE_INITIAL_* settings as True by default (to preserve backwards compatibility on existing projects);
but setting them to False in project_template's settings (and presumably, in our 'integrating with Django' / 'configuring Django for Wagtail' docs, advising developers to do the same);
and updating project_template's data migration (currently home/migrations/0002_create_homepage.py) to create the initial site / homepage / group records.

The settings would have to remain in the project template for the foreseeable future - so effectively we're in the same situation as Django's USE_I18N / USE_L10N / USE_TZ flags, which have been in everyone's settings files forever and rarely need to be changed, but can't be dropped due to ancient legacy reasons. Which would be unfortunate, but clearly the Django world has tolerated those redundant settings without too much heartache, so it's not the end of the world if we have to do the same here ;-)
However, it seems to me that all we've really gained in all of this is the opportunity to omit a few 'delete' lines from the 0002_create_homepage migration - in other words, it boils down to a choice between some extra noise in the project_template settings, or some extra noise in the project_template migration. And given that choice, I'd go for the noise in the migration - it's something that only power users need to look at, and if it was suitably well-commented, perhaps with sample commented-out code blocks that users could uncomment and adjust to fit their requirements ("to remove the default groups, do this; to load initial data from a fixture, do this...") then I could see that being a lot neater. (Admittedly, we'd have to give a similar treatment to the configuration / integration docs.)
As I said, I'm not fully clear on the motivation for this change, so I'm prepared to accept that there may be issues with the "big noisy migration" approach that I haven't grasped.

Rebased again, sorry for the delay.
As for my motivation -- well, @timheap kinda put it in words for me there :)
I find it silly that the default project template's migration actually deletes the objects another migration has created, just so it can create its own versions, with the correct content types etc.
We're evaluating Wagtail for a home page project here at @andersinno (and so far it's been pretty great, though I'm looking forward for proper i18n support, as projects here in Finland tend to be multilingual beasts -- but I digress), and for that project we've been running a fork release that has this patch in, and our initial migration (though it could just as well be a "seed initial data" management command) looks like this. No silly deleting or editing of existing useless data. :)
def create_homepage(apps, schema_editor):
    ContentType = apps.get_model('contenttypes.ContentType')
    Site = apps.get_model('wagtailcore.Site')
    HomePage = apps.get_model('superawesomeprojectyay.HomePage')
    homepage_content_type = ContentType.objects.get_for_model(HomePage)
    homepage = HomePage(title='Kotisivu', slug='home', content_type=homepage_content_type)
    root = Page.objects.get(slug='root')
    root.add_child(instance=homepage)
    Site.objects.create(hostname='localhost', root_page=homepage, is_default_site=True)
    ContentType.objects._cache.clear()  # See https://github.com/django/django/pull/6088

I agree that the current behaviour is silly - no argument there :-)
(Sorry for the wall of text that follows, but it's kind of important...)
If we're making this change, it's absolutely essential that we roll out the new setting in a way that encourages all new users to use it - i.e. we enable it in the project template by default. For me, the worst possible outcome is that we end up with two competing conventions in use - the current "silly" behaviour, and the fixed behaviour that only power users know about - because then we end up with twice as many scenarios to test against, harder-to-diagnose tech support problems ("why are they getting that weird behaviour? Oh, they must have Obscure Setting X enabled..."), more complications if we change it again in future (see #1824 where we've tied ourselves in knots because a 'clever' migration had unforeseen side effects, and now we have two diverging configurations to deal with) - and just generally, more "moving parts" to account for. I fear that's what will happen if we merge this PR in its current form.
(Besides making life more difficult for us Wagtail developers, the "opt-in setting" approach doesn't really improve the developer experience for end users either. 95% of users won't read the reference docs, so they won't learn about the setting at all, and will be stuck with the "silly" behaviour. The other 5% won't understand the purpose of the setting, unless they've learnt a LOT about Wagtail internals, such as the difference between wagtailcore migrations and project_template migrations, and why having a raw Page instance for your homepage is a bad thing. Nobody is going to learn all those details for their first Wagtail project, so the only people who will benefit from this setting are people like you, who have been previously bitten by the "silly" behaviour, realised it's silly, and started digging into Wagtail internals for a better solution. That's not a good experience for anyone.)
So, unless anyone can see an alternative approach that addresses my concerns above, I propose that we add explicit WAGTAIL_MIGRATE_INITIAL_PAGE_AND_SITE = False / WAGTAIL_MIGRATE_INITIAL_GROUPS = False lines into project_template/project_name/settings/base.py. The question remains: if we do that, is this change still worthwhile, or does that completely nullify the goal of finding a more elegant solution? Personally, it seems like the latter to me: we no longer have the silly 'delete' operations sitting in migration 0002 forever, but instead we have some silly "don't change this unless you know what you're doing" lines sitting in the settings file forever. But then it's not really my judgment call to make - clearly you (@akx, @timheap, @jordi, @timorieber) have stronger feelings about the usefulness of this change than I do - if you think this PR is still worthwhile with my proposed amendment, I'll happily go along with it.

I'll take the silence as a sign that there's no enthusiasm for my amended proposal, then :-)
Unfortunately I don't think we're going to find a solution to the 'ugly migrations' issue that's satisfactory to everyone here and doesn't just shift the ugliness somewhere else. As such, I'll close this issue (but as always, it can be reopened if there's further progress on this).

Maybe because the emails are mixed up again? I have no idea why i keep
receiving these kind of messages. I don't know why github accounts are
always mixed up. Have nothing to do with that project.
On Apr 8, 2016 9:18 PM, "Matt Westcott"<EMAIL_ADDRESS>wrote:
Closed #2112 https://github.com/torchbox/wagtail/pull/2112.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/torchbox/wagtail/pull/2112#event-620113746

@Jordi Oops, that was my fault... looks like I mentioned you instead of @jordij in my earlier message. Sorry for the spam!
(Github doesn't provide a way for me to unsubscribe you from notifications, as far as I can see - you can unsubscribe yourself at https://github.com/torchbox/wagtail/pull/2112)

Oops sorry @gasman  I didn't get notified about what was going on.
I agree with you on the_ " Nobody is going to learn all those details for their first Wagtail project, so the only people who will benefit from this setting are people like you, who have been previously bitten by the "silly" behaviour..."_  but to me this change is useful as I'd use the new behaviour in 99% of my Wagtail-based implementations.
Personally, I don't see it as an issue if it remains as a "hidden" setting that shouldn't be changed unless the developer really wants to. Django has several settings with a default value that remain kind of "hidden" until you start digging and learning about them. I feel this would be a similar case, but again this is just my opinion :)

As is,  this PR looks fine. Backward compatible behavior is preserved by default. If a users wants to change the setting they can, and the caveat that it won't work with the default project seems to be clear in the docs.
@gasman

If we're making this change, it's absolutely essential that we roll out the new setting in a way that encourages all new users to use it - i.e. we enable it in the project template by default. For me, the worst possible outcome is that we end up with two competing conventions in use - the current "silly" behaviour, and the fixed behaviour that only power users know about - because then we end up with twice as many scenarios to test against, harder-to-diagnose tech support problems ("why are they getting that weird behaviour? Oh, they must have Obscure Setting X enabled..."), more complications if we change it again in future (see #1824 where we've tied ourselves in knots because a 'clever' migration had unforeseen side effects, and now we have two diverging configurations to deal with) - and just generally, more "moving parts" to account for. I fear that's what will happen if we merge this PR in its current form.

It is not necessary to force all users to use this approach. The default behavior should preserve backward compatibility so typical users are unaffected.  Core doesn't want or need to support this option, and can clearly state as much in the documentation. If the community finds this functionality useful, it may make sense for core to revisit the question of support.

(Besides making life more difficult for us Wagtail developers, the "opt-in setting" approach doesn't really improve the developer experience for end users either. 95% of users won't read the reference docs, so they won't learn about the setting at all, and will be stuck with the "silly" behaviour. The other 5% won't understand the purpose of the setting, unless they've learnt a LOT about Wagtail internals, such as the difference between wagtailcore migrations and project_template migrations, and why having a raw Page instance for your homepage is a bad thing. Nobody is going to learn all those details for their first Wagtail project, so the only people who will benefit from this setting are people like you, who have been previously bitten by the "silly" behaviour, realised it's silly, and started digging into Wagtail internals for a better solution. That's not a good experience for anyone.)

I can say 100% an opt-in setting would improve my developer experience with wagtail. I've lost a half-day, just figuring out how to set up fixtures so that I can prep to kick off the front-end development on my project.  I've had to figure out our normal approach with fixtures doesn't work because someone chose to use a data migration to seed data in wagtail, rather than fixtures. Then I had to work around the fact the manage.py flush doesn't work and build that into our docs and docker-compose files. You acknowledge the problem and silliness of having the seed data embedded in a data migration to begin with, such as slowing down test setup and breaking the fixtures feature.

So, unless anyone can see an alternative approach that addresses my concerns above, I propose that we add explicit WAGTAIL_MIGRATE_INITIAL_PAGE_AND_SITE = False / WAGTAIL_MIGRATE_INITIAL_GROUPS = False lines into project_template/project_name/settings/base.py. The question remains: if we do that, is this change still worthwhile, or does that completely nullify the goal of finding a more elegant solution? Personally, it seems like the latter to me: we no longer have the silly 'delete' operations sitting in migration 0002 forever, but instead we have some silly "don't change this unless you know what you're doing" lines sitting in the settings file forever. But then it's not really my judgment call to make - clearly you (@akx, @timheap, @jordi, @timorieber) have stronger feelings about the usefulness of this change than I do - if you think this PR is still worthwhile with my proposed amendment, I'll happily go along with it.

I would reject your proposal based on your false premise that this change has to break backward compatibility.  I think it is perfectly okay to give power users some freedom.  Nothing changes in settings unless a user turns it on. Core. Take a wait an see approach and see if the support concerns are valid, or maybe the contributor community will develop a new practice core can adopt.  I'd say all the PR needs is clear documentation that core won't support this.


maven build

is the extra v a typo?

compile the project with Maven by running: "mvnv clean package" from the project root

No, it depends on the system you use: it will also work with "mvn" command, of course, but it was "mvnv" in my IntelliJ


Build docker image for sqanti

Build docker image for https://bitbucket.org/ConesaLab/sqanti/

The current one is not working properly...

Current issue: libopenblas.so.0: cannot open shared object file: No such file or directory


Toggle advanced clock widget options when the option is toggled

Description

I think the other options should only show up when "Display a custom Timezone" is toggled on.
Priority
Low (Nice-to-have)

Yes this is something I wanted to add as well but we don't have nested options yet.

Closed by https://github.com/homarr-labs/homarr/pull/78/files
This feature will be part of v1.0, see https://github.com/ajnart/homarr/issues/1993


Spevacus: Watch amogue.com

Spevacus requests the watch of the watch_keyword amogue\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

amogue\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by NobodyNada in Charcoal HQ


[Bug] treesync::node::Node is private but public API needs it

Describe the bug
OpenMls allows to export ratchet tree but the Node class is private
https://github.com/openmls/openmls/blob/main/openmls/src/group/mls_group/mod.rs#L305-L308
    /// Export the Ratchet Tree
    pub fn export_ratchet_tree(&self) -> Vec<Option<Node>> {
        self.group.treesync().export_nodes()
    }

To Reproduce
Call export_ratchet_tree on MLS Group and capture in variable
let ratchet_tree: Vec<Option> = group.export_ratchet_tree();
Expected behavior
Node class not found.
Actual behavior
Node class should be public and accessible outside crate
Proposed fix:
https://github.com/openmls/openmls/blob/main/openmls/src/lib.rs#L60
Update mod treesync; -> pub mod treesync;
https://github.com/openmls/openmls/blob/main/openmls/src/treesync/mod.rs#L49
Update pub(crate) mod node; -> pub mod node;

That's correct and we should probably expose Node. Note however that Node is just an enum containing LeafNode and ParentNode which are also not exposed.
Can you tell a bit more about your use case, so that we can see what exactly needs to be exposed?

I wanted to use 'export_ratchet_tree(&self)' and share the value with other user, so that other user can use the returned value  while joining the group from welcome message.

As a workaround, you can probably just serialize the whole vector for now and pass the bytes to another user. I need to check a bit more about what exactly we want to expose here.

Closed via #725.

https://github.com/openmls/openmls/pull/783 PR has reopened this issue.

Arf, sorry for that. I guess we should have an integration test for that. Would you like to provide a minimal example perhaps?

Sure I can add one. The minimal example is using export_ratchet_tree method.

It looks to me like the Node struct is public and explicitly exported via prelude.rs. The export_ratchet_tree() function is used, for example, in the mls_group_operations test that lives in the test/test_mls_group.rs file as part of the integration tests.
@pulkitkothari can you do me a favor and check if you can import it via use opemmls::prelude::Node;? Or am I misunderstanding the issue?

@kkohbrok Yes you are right use opemmls::prelude::Node; worked thanks for the tip.

I'm also re-exporting them in #813, they should not only exist in the prelude.


chore: add e2e tests for transaction summary operations

Closes https://github.com/FuelLabs/fuels-ts/issues/2836

Summary

Introduces some e2e tests in the fuel-gauge test suite to ensure the operations and transaction summaries are correctly assembled for various types of transactions.
Checklist

[x] All changes are covered by tests (or not applicable)
[x] All changes are documented (or not applicable)
[ ] I reviewed the entire PR myself (preferably, on GH UI)
[x] I described all Breaking Changes (or there's none)

@dependabot rebase

Should we be migrating all these tests over?

To the best of my knowledge, all the possible scenarios for the transaction operations are now covered so there is no further tests to be added.

Should we remove the unit tests that have been migrated?

This is debatable, one perspective would say that the e2e tests cover the correctness of all the unit tests, and therefore yes they should be removed. My opinion is that they should remain (for now) as they are useful for faster debugging (although the drawback is that refactors are slower)
@nedsalk of course has a lot of thoughts on this. I think the ideal compromise is that delay removing them until we refactor the respective functions.


microk8s.config > $HOME/.kube/config, .config doesn't seem to exist

Did you perhaps mean:
microk8s.kubectl config view > $HOME/.kube/config
Or is this something from the bleeding edge?

Yeah, that would work too. But your guess was right, microk8s.config is only on --edge right now. You're the 2nd person to trip on this. We should update the readme to either say "you need edge", or just use the command you listed (which seems preferable tbh). Thanks for pointing this out.

The purpose of the microk8s.config wrapper is mainly to use the host IP as the endpoint address rather than the loopback address.  The commands use loopback internally, but it's more likely that you'd want the host IP if you're using the config externally.

Oh, it also changes the default for --raw to true rather than false which is necessary for using the config with an external kubectl.  The actual equivalent command is:
DEFAULT_INTERFACE="$(netstat -rn | grep '^<IP_ADDRESS>' | awk '{print $NF}')"
IP_ADDR="$(ifconfig "$DEFAULT_INTERFACE" | grep 'inet ' | "$SNAP/usr/bin/gawk" '{print $2}' | "$SNAP/bin/sed" -e 's/addr://')"
microk8s.config view --raw | "$SNAP/bin/sed" -e "s/<IP_ADDRESS>/$IP_ADDR/"

Ah, that explains a lot.  Ok, I'll switch to edge.  Thanks!
On Wed, Jun 27, 2018, 8:38 AM Cory Johns<EMAIL_ADDRESS>wrote:

Oh, it also changes the default for --raw to true rather than false which
is necessary for using the config with an external kubectl. The actual
equivalent command is:
DEFAULT_INTERFACE="$(netstat -rn | grep '^<IP_ADDRESS>' | awk '{print $NF}')"
IP_ADDR="$(ifconfig "$DEFAULT_INTERFACE" | grep 'inet ' | "$SNAP/usr/bin/gawk" '{print $2}' | "$SNAP/bin/sed" -e 's/addr://')"
microk8s.config view --raw | "$SNAP/bin/sed" -e "s/<IP_ADDRESS>/$IP_ADDR/"
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/juju-solutions/microk8s/issues/56#issuecomment-400721712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADovH6iQ96U_E1E5lvFAr0Md5--XEw5ks5uA6bzgaJpZM4U43vJ
.


fix: apply scrollbar-gutter: stable to prevent layout shift with modals

Description
Closes #2514
Adds scrollbar-gutter: stable to html to prevent layout shift when scrollbar appears/disappears, e.g. when opening the search modal.
Before

After

Hello! Thank you for opening your first PR to Starlight! ✨
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any issues you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Netlify 🤩

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

@delucis Thanks for having a look! There probably are ways of overflowing the navbar into the scrollbar gutter but I'm not a CSS expert so this is out of my depth. Stackoverflow has some suggestions: https://stackoverflow.com/a/70277203/7483211, e.g. combining scrollbar-gutter with overflow-y: auto;. The answer also has some nice fallbacks for browsers that don't (yet) support scrollbar-gutter (old Safari and Safari mobile)

Hmm, thanks for the link. Those options seem to have other problems unfortunately. We’ll need to dig in and see if there’s a good way to solve this. I think given the current two options of small layout shift in the background on modal open and displaying a visible gap in the title bar, I’d choose the layout shift for now. But would love to solve it better if we can.

Those options seem to have other problems unfortunately.

This has also been my experience so far with scrollbar-gutter: stable in this kind of scenarios, specially with fixed position elements.
To my knowledge, there are definitely some "hacky" ways to achieve this, but getting them right on all platforms, especially mobile, is super tricky.
This is a scenario where the obvious fix (overscroll-behavior on the <dialog>) does not work due to the spec:

An element that is not scroll container must accept but ignore the values of this property.

The WHATWG is aware of the feedback, there are also on top of this some browser bugs and differences of behavior between Chrome, Firefox and Safari (bugs linked in the issue).
I'm personally not sure there is at the moment a perfect or even good solution for this sadly.


Macros for verified users

Macro for verified users (inc moderators) with over 100 posts.
To allow for "stock replies" to be presented to a poster.
Anticipate 3-5 should suffice as some macros could be combined.
Should use a shortcut key combo eg. SHIFT m1 or ALT m1 for macro 1 etc.
So many replies are currently similar it may be of benefit to the users who frequent the forum more and already have shortform answers available in notepad or similar
Also of benefit to moderators too for similar reasons.
example

@
Your topic was [b]Moved[/b]  to it's current location / section as it is more suitable.
Could you also take a few moments to [url=https://forum.arduino.cc/index.php?topic=148850.0]Learn How To Use The Forum[/url].
Other general [url=https://forum.arduino.cc/index.php?topic=52113.0]help and troubleshooting advice can be found here.[/url]
It will help you get the best out of the forum in the future.
Thanks for your co-operation on behalf of The Arduino Team.

Just a quick note to say Thank you to Arduino for these macros.
Yes I know I was involved but my thanks are to those that allowed it to happen, and I think on behalf of some of the other moderators who sent personal thanks.
Invaluable tool to have.


Fix: prompted for script types when with parentId

Fixes #575
If use parentId parameter, prompt for types is not required.

[x] npm run test succeeds.
[x] npm run lint succeeds.
[ ] Appropriate changes to README are included in PR.

Thanks!


nyc paths in out.json

Greetings!
I've encountered a problem with collected coverage with paths in .out.json
All of them starts with /app/src/...
And coverage could not be collected properly as nyc produces an error:
Unable to lookup source: /app/src/Components/App/index.jsx(ENOENT: no such file or directory, open '/app/src/Components/App/index.jsx')
If I change the paths to ./src and create the report manually with nyc v13
everything seems to be working properly.
My app has a standard layout, created by RCA and all my source code is located in the src directory.
Might it be related to issue with nyc 14.1.1 bug?
https://github.com/cypress-io/code-coverage/issues/65

Try upgrading to latest dependencies and see if this solves the issue.

assuming resolved


add error handling to fetch wrappers

in client/src/utilities.js we need to add error handling so if the server returns a 500, we don't just print out the "cannot parse <" or whatever the weird error is. make sure to comment what it does.

It now outputs a message with the failing route, the status if not 200, and any text that couldn't be converted to JSON (in case they return HTML or a string instead of an object).
Potential improvement: I use Body.clone() to clone the fetch result so we can see the text in the debug message. Idk if this has performance implications. If it does, we can replace Body.json() with calls to Body.text() and JSON.parse() to still offer debug messages, but the code is less clear


try to fix prod

IBM Cloud toolchain: Delivery Pipeline deployed shopcarts to nyu-devops, including commit e92e28c0420b787fc05e4c4217819f94287e60db


nf-area-stack should sum y values for each area

Currently, nf-area-stack requires each area underneath it to have data y values that are exactly where they should be plotted. We have an internal requirement that the nf-area-stack should add the values of the each area under the current area. This is the way this should have behaved to begin with, but we can leave the original behavior.
Proposed Fix:

add a property named something like sum to nf-area-stack that is a boolean.
if sum is not set, show a deprication message warning that the default behavior will be changing in the next version to be sum=true, but is currently sum=false.. in other words, if you're already using the default incorrect behavior, it won't break.

To reiterate, and hopefully add clarity:
new sum property value:

true: will add the y values of areas "under" the current area to a total for plotting purposes.
false: (the current default bahavior) values are exactly where they should be to create a stacked area.
(no value): Defaults to false, but gives a warning message that it will default to true in the next version.

So given the following data y values:
dy1 = [1,2,3,4,5];
dy2 = [2,3,4,5,6];

If  sum is  false or not set, it will plot as:
dy1PlotAt = [1,2,3,4,5];
dy2PlotAt = [2,3,4,5,6];

if sum is true, it will plot as:
dy1PlotAt = [1,2,3,4,5];
dy2PlotAt = [3,5,7,9,11]; //sums of dy1 and dy2

cc @jeff3dx

This has been done in the 1.0.0-beta.25 and higher


Delete application gcpjxtest from this environment

The command jx delete application was run by kav and it generated this Pull Request

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Unsupported 'cache_type' argument passed on to PyArrow's HDFS classes from WholeFileCacheFileSystem

Hi,
In fsspec 0.5.2 via Conda, it appears the fsspec.implementations.cached.WholeFileCacheFileSystem might be feeding unwanted arguments to the PyArrow lib methods, such as cache_type.
If I setup my cached Filesystem like so:
import fsspec

fs = fsspec.filesystem(
            protocol="filecache",
            target_protocol='hdfs',
            cache_storage='/mylocalfolder',
            cache_check=3600, #one hour, Number of seconds between reload of cache metadata
            check_files=True, #doesn't work with HTTP files
            expiry_time=False, #The time in seconds after which a local copy is considered useless. Set to falsy to prevent expiry. 604800 => one week
            target_options={'path': '/myhdfspath/', 'host': 'myhdfshost'}
        )

This works fine:
fs.walk('/adir')

But this does not:
of = fs.open('/adir/afile.txt')
with of as f:
    f

I get this error

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-9-f4b5281b24bb> in <module>
----> 3 of = fs.open('/adir/afile.txt')
      4 with of as f:
      5     f

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/cached.py in <lambda>(*args, **kw)
    259             # all the methods defined in this class. Note `open` here, since
    260             # it calls `_open`, but is actually in superclass
--> 261             return lambda *args, **kw: getattr(type(self), item)(self, *args, **kw)
    262         if item == "__class__":
    263             return type(self)

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/spec.py in open(self, path, mode, block_size, **kwargs)
    706             ac = kwargs.pop("autocommit", not self._intrans)
    707             f = self._open(
--> 708                 path, mode=mode, block_size=block_size, autocommit=ac, **kwargs
    709             )
    710             if not ac:

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/cached.py in <lambda>(*args, **kw)
    259             # all the methods defined in this class. Note `open` here, since
    260             # it calls `_open`, but is actually in superclass
--> 261             return lambda *args, **kw: getattr(type(self), item)(self, *args, **kw)
    262         if item == "__class__":
    263             return type(self)

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/cached.py in _open(self, path, mode, **kwargs)
    333
    334         # call target filesystems open
--> 335         f = self.fs._open(path, **kwargs)
    336         with open(fn, "wb") as f2:
    337             if f.blocksize and f.size:

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/hdfs.py in <lambda>(*args, **kw)
    114             # all the methods defined in this class. Note `open` here, since
    115             # it calls `_open`, but is actually in superclass
--> 116             return lambda *args, **kw: getattr(PyArrowHDFS, item)(self, *args, **kw)
    117         if item == "__class__":
    118             return PyArrowHDFS

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/hdfs.py in _open(self, path, mode, block_size, autocommit, **kwargs)
     70         if not autocommit:
     71             raise NotImplementedError
---> 72         return HDFSFile(self, path, mode, block_size, **kwargs)
     73
     74     def __reduce_ex__(self, protocol):

~/conda/envs/myenv/lib/python3.7/site-packages/fsspec/implementations/hdfs.py in __init__(self, fs, path, mode, block_size, **kwargs)
    169         self.mode = mode
    170         self.block_size = block_size
--> 171         self.fh = fs.pahdfs.open(path, mode, block_size, **kwargs)
    172         if self.fh.readable():
    173             self.seek_size = self.size()

~/conda/envs/myenv/lib/python3.7/site-packages/pyarrow/io-hdfs.pxi in pyarrow.lib.HadoopFileSystem.open()

TypeError: open() got an unexpected keyword argument 'cache_type'

I get a similar error for get().

Seems a default kwarg is getting promoted here, this is indeed a bug.
Note that it is surprising to me to use local caching with HDFS, which I would expect to be fast enough to make it redundant.

Agreed. It's for integrating within a legacy system...

@marchub , I would appreciate a PR if you have time, to catch the kwargs and only pass on those expected by arrow.

I'll see what I can do over the weekend. Any pointers welcome.

Is this the sort of thing you were looking for https://github.com/marchub/filesystem_spec/commit/fdc2001705e0422d45ffe1f82b91f85150ae6d2c ? If so, I'll continue working on it and test it.


TopBar small-size styling

The TopBar component breaks oddly when the nav contents can't fit horizontally in the TopBar. This will be remedied with the Drawer component show/hiding for smaller screens, but the default styles for a nav that is too narrow for it's contents should break in a more functional way.
idea: maybe we allow the menu items to scroll horizontally if they are too wide to fit the available space?

so I think I may have found a possible solution for the layout issues + a fix that would have to be made to the topbar menu. but I don't know if these are the best ideas and would like to run them past @CheetoMao when she has a chance.
(mostly because an additional class would need to be added to one of the topbar menus.. the rev-TopBar-item that wraps the menu with the links...which is why I don't think this is the best solution haha

Should the whole top bar scroll? (This screenshot is with an additional style addition to overflow the whole topbar)

Or just the container with the menu in it? This is what I assumed should happen. Currently, I have the menu component horizontally scrolling if theres more menu items than there is horizontal space. (this screenshot includes the changes I mentioned in my previous comment that I'm not sure if they are the best options)

However, when the menu is put in the top bar, the container for the menu doesn't adjust its size to take up the remaining space between the logo and the search input. It appears that its having trouble because of double nested flex containers? (this is what is currently happening that I'm trying to fix)

While I'm working on the nav stuff, I'm going to make a prop for rev-TopBar-item to scroll. Whatever issues I was having the last time I worked on this arent happening anymore. All I had to do was apply overflow-x: scrollto the top bar item and it works fine (I'm not having issues like the last screenshot from the last comment).
I'm going to apply it with a prop so that users have the option to make the container scroll or not.

Oh I see what happened. So for the last screenshot here I think that was happening because the scroll was only applied to the one TopBar-item that had all the links in it that needed to be scrollable. if you apply the class to all of the topbar-items, the result is what you get here from my last comment

Ok I added the scrolls and all the scroll breakpoints as props. Wrote a loop to loop through breakpoints and class names to apply the scroll style.


Add a 'rebuild' command

Rather than forcing the user to delete .manifest manually, perhaps it is good to add a swege rebuild command.

Fixed in a recent commit.


Fully controlled selection state

Please describe the feature that you want to propose
It would be great if react flow's selection state could be fully controlled. Ideally in such a way that would allow for its current selection functionality (multiSelectionKeyCode, selectionKeyCode, onSelectionChange) to continue working.
Our application has selection state external to react flow. I'm currently trying to coordinate this external selection state with react flow like so:
const store = useStoreApi();
const externalSelectionState: string[] = useExternalSelectionState();

useEffect(() => {
  const state = store.getState();
  state.resetSelectedElements();
  state.addSelectedNodes(externalSelectionState);
}, [externalSelectionState, store]);

However, I would also like to use react flow's selection listeners and its multi select capability to affect this external selection state. I'm currently doing something like this to listen to these events:
const setExternalSelectionState: (ids: string[]) => void = useSetExternalSelectionState();

const onSelectionChange = useCallback(
  ({ nodes: selectedNodes }: { nodes: RFNode<...>[] }) => {
    const newlySelectedIds = selectedNodes.map((node) => node.id);
    setExternalSelectionState(newlySelectedIds);
  },
  [setExternalSelectionState],
);

and passing onSelectionChange to the ReactFlow component.
However, it's really easy to run into an infinite loop since resetSelectedElements and addSelectedNodes both seem to cause onSelectionChange to be called.
Ideally, selection state could be controlled without needing to have nodes/edges also controlled.

For anyone looking at this issue in the future, I was able to get around this by moving nodes/edges to being fully controlled.


Maven repository - dbmaintain:2.7.3

Hello,
is there a plan to publish latest version of dbmaintain - 2.7.3 to Maven repository? I see only a version 2.7.2 from Dec, 2016.

https://search.maven.org/search?q=dbmaintain
https://mvnrepository.com/artifact/org.dbmaintain/dbmaintain
https://repo.maven.apache.org/maven2/org/dbmaintain/dbmaintain/maven-metadata.xml

Thank you.

Yes, we plan to publish this release. I pushed it in the upper part of my todo list and will try to get it done in this week.

Unfortunately we tried that before but since red6 took over the project from the previous maintainers uploading to the public Maven repo was not working. There used to be problems related to the Maven group id and GPG keys. Maybe that has improved in the meantime.


Plugin.GoogleClient.Shared.GoogleClientBaseException: 10:

Hello!
I created a package and inside it I used GoogleClientPlugin.
When I work with the package inside the Sample project where I develop the nugets everything works fine, but when I want to test the packege as a nuget in another project I get this error when I try to log in with google:
Exception is: Plugin.GoogleClient.Shared.GoogleClientBaseException: 10:
at Plugin.GoogleClient.GoogleClientManager.LoginAsync () [0x000cb] in <9a6ffdce03a64aceaeeebe3956587f25>:0
at [my function]
The solutions I found was to verify the package name or the fingerprint and both of them are ok.
If you can see, the exception doesn't help me because the message it's "10:" and I can't find anything about it on google or in issues.
If you know why I get this error message please help!
Thanks!

I'm having the same problem. I downloaded the sample project to see if the problem was my code, but it presented the same error.

Hello!
I created a package and inside it I used GoogleClientPlugin.
When I work with the package inside the Sample project where I develop the nugets everything works fine, but when I want to test the packege as a nuget in another project I get this error when I try to log in with google:
Exception is: Plugin.GoogleClient.Shared.GoogleClientBaseException: 10:
at Plugin.GoogleClient.GoogleClientManager.LoginAsync () [0x000cb] in <9a6ffdce03a64aceaeeebe3956587f25>:0
at [my function]
The solutions I found was to verify the package name or the fingerprint and both of them are ok.
If you can see, the exception doesn't help me because the message it's "10:" and I can't find anything about it on google or in issues.
If you know why I get this error message please help!
Thanks!

Hi! I fixed the error by doing two things:

Add the Android SHA-1 debug key to Firebase. There is one key to debug and other to production:

https://docs.microsoft.com/en-us/xamarin/android/deploy-test/signing/keystore-signature?tabs=windows
You can add these to Firebase:

If you want to enable server auth code, the type needs be "Web application":

https://developers.google.com/identity/sign-in/android/start-integrating#get_your_backend_servers_oauth_20_client_id


Added links to sort weight tables

Added links to sort weight tables
This PR:

Adds links to the Unicode sort weight table used by .NET Core on Linux and macOS.
Adds a link to the section in the System.String class on Unicode versions used for string comparison.

Fixes #7242
//cc @tarekgh

other than my comment, LGTM

@tarekgh, I've revised the text. Could you review it again, please?


Invalid function npm:update error when updating javascript dependency

Package manager/ecosystem
javascript:npm
Hello, I'm trying to setup a pipeline in Azure Devops to run dependabot but the FileUpdater is throwing an error.
I'm running the pipeline inside a container job using the dependabot/dependabot-core docker image, and the dependabot-script to update the repo dependencies.
Is it possible that I might be missing the javascript native helper? Its weird because that shouldn't be the case when using the dependabot docker image.
This is the error:
Parsing dependencies information
  - Updating react-query (from 3.9.6)…/__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:111:in `run_helper_subprocess': Invalid function npm:update (Dependabot::SharedHelpers::HelperSubprocessFailed)
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:151:in `run_npm_top_level_updater'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:139:in `block in run_npm_updater'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:141:in `with_git_configured'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:137:in `run_npm_updater'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:115:in `run_current_npm_update'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:35:in `block (2 levels) in updated_lockfile_content'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:34:in `chdir'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:34:in `block in updated_lockfile_content'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:37:in `block (2 levels) in in_a_temporary_directory'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:37:in `chdir'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:37:in `block in in_a_temporary_directory'
	from /usr/lib/ruby/2.6.0/tmpdir.rb:93:in `mktmpdir'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.118.8/lib/dependabot/shared_helpers.rb:34:in `in_a_temporary_directory'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:30:in `updated_lockfile_content'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:187:in `updated_package_lock_content'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:120:in `package_lock_changed?'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:149:in `block in updated_lockfiles'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:148:in `each'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:148:in `updated_lockfiles'
	from /__w/1/s/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-npm_and_yarn-0.118.8/lib/dependabot/npm_and_yarn/file_updater.rb:39:in `updated_dependency_files'
	from ./generic-update-script.rb:168:in `block in <main>'
	from ./generic-update-script.rb:130:in `each'
	from ./generic-update-script.rb:130:in `<main>'

For reference, this is my pipeline: (I'm cloning the dependabot-script repo for now, for testing purposes)
trigger: none

variables:
  MAPPED_ACCESS_TOKEN: $(ACCESS_TOKEN) // secret variables need to be mapped first

jobs:
  - job: update_dependencies
    displayName: Update dependencies
    pool:
      vmImage: 'ubuntu-20.04'
    container:
      image: dependabot/dependabot-core:latest
      env:
        AZURE_ACCESS_TOKEN: $(MAPPED_ACCESS_TOKEN)

    steps:
      - script: git clone https://github.com/dependabot/dependabot-script.git
        displayName: Cloning dependabot-script repo

      - script: bundle install -j 3 --path vendor
        displayName: Installing dependabot dependencies
        workingDirectory: dependabot-script/

      - script: bundle exec ruby ./generic-update-script.rb
        displayName: Updating dependencies
        workingDirectory: dependabot-script/

Thanks for the help =)

hi. same issue here. any solution so far?

Hmm yeah that is weird. Are you using the latest version of the docker images? We've moved some of the helpers around recently.
Is there any way I could reproduce this?

@jurre
Yes. I'm using the latest version (released today) of docker images. I'm not sure if you can reproduce this but I followed the guide on the (https://github.com/dependabot/dependabot-script)'s README.

We've moved some of the helpers around recently.

So we need to change the way of installation? Is there some new guide?

could this be related to this PR dependabot/dependabot-core#2971?

@Songkeys you'll want to fork dependabot-script and update the Gemfile to install the latest version of dependabot-core gem: https://github.com/dependabot/dependabot-script/blob/main/Gemfile#L6 (currently 0.133.6)
The script version of core is really old.

@feelepxyz this indeed solves my problem. thank you so much.

Sidenote: we should probably update that 😄

If only there was a way to automate that 🤣

@feel

@Songkeys you'll want to fork dependabot-script and update the Gemfile to install the latest version of dependabot-core gem: https://github.com/dependabot/dependabot-script/blob/main/Gemfile#L6 (currently 0.133.6)
The script version of core is really old.
Sidenote: we should probably update that 😄

Thanks for the suggestion!
That solved our problem too so I'm closing this for now.


pull request for e2e test at 02/05/2017 22:26:07

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Automated cherry pick of #1982: fix: rbd image resize not found error

Cherry pick of #1982 on release/2.10.0.
#1982: fix: rbd image resize not found error

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@9ffc238). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             release/2.10.0   #2021   +/-   ##
================================================
  Coverage                  ?    7.6%
================================================
  Files                     ?     410
  Lines                     ?   63186
  Branches                  ?       0
================================================
  Hits                      ?    4806
  Misses                    ?   57970
  Partials                  ?     410

Flag
Coverage Δ

#aFlag
7.6% <ø> (?)

Continue to review full report at Codecov.

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

/lgtm

/approve


Add support for Cassandra API

Would be great to have this Cassandra support!

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Segmentation fault when cython generated code calls Fortran library executing a WRITE(*,FMT_STR) statement

While trying to wrap some Fortran code into Python with Cython, I found that the WRITE statement of Fortran can cause the generated Python module to crash (segmentation fault).
To be precise, the WRITE statemen only causes crash if it contains a format string.  Without a format string it won't crash.  Namely, WRITE(*,*) "xxx" does not crash but WRITE(*,"(A)") "xxx" does.  When called by a normal Fortran or C++ procedure, the related Fortran subroutine works as expected and there is no crash.
The following is an example.  It contains three files:
    1. fortran_write.f90
    2. testwrite.pyx
    3. setup.py

File fortran_write.f90:
module mod_write
use, intrinsic :: ISO_C_BINDING
implicit none

contains

subroutine fwrite(flag) bind(C, name="write_f")
    integer*4, intent(in) :: flag
    write(*, *) "In fwrite: flag=", flag
    if (flag .eq. 0) then
      write(*, *) "Message from fwrite (write_f)."
    else if (flag .eq. 1) then
      write(*, *) "MSG", 1234, 12.34
    else if (flag .eq. 2) then
      write(*, "(A40)") "Message from fwrite (write_f)."
    else if (flag .eq. 3) then
      write(*, "(I6)") 1234
    else if (flag .eq. 4) then
      write(*, "(F6.2)") 12.34
    end if
end subroutine fwrite
end module mod_write

File testwrite.pyx:
# distutils: language = c++

cdef extern:
  void write_f(int* flag)

cdef writef(flag):
  cdef int f;
  f = flag
  write_f(&f)

def run():
  writef(0)
  writef(1)
  writef(2)
  writef(3)
  writef(4)

File setup.py:
from distutils.core import setup
from distutils.extension import Extension
from Cython.Build import cythonize

extension = Extension(
    name="testwrite",
    sources=["testwrite.pyx"],
    libraries=["testwrite", "gfortran"],
    library_dirs=["./", "/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/"],
    include_dirs=["./"],
    depends=['fortran_write.f90'],
    extra_compile_args=["-std=c++11"])

setup(
    name="testwrite",
    ext_modules=cythonize([extension], language_level="3")
)

Compile procedure:
gfortran -c fortran_write.f90
ar rcs libtestwrite.a fortran_write.o
python setup.py build_ext --inplace

Test procedure:
python -c "import testwrite;testwrite.run()"

Output:
 In fwrite: flag=           0
 Message from fwrite (write_f).
 In fwrite: flag=           1
 MSG        1234   12.3400002
 In fwrite: flag=           2
[1]    7631 segmentation fault  python -c "import testwrite;testwrite.run()"

Expected output:
In fwrite: flag=           0
 Message from fwrite (write_f).
 In fwrite: flag=           1
 MSG        1234   12.3400002
 In fwrite: flag=           2
          Message from fwrite (write_f).
 In fwrite: flag=           3
  1234
 In fwrite: flag=           4
 12.34

By the way, f2py works fine.
Compile procedure:
f2py -c -m testwrite fortran_write.f90

Test procedure:
python -c "import testwrite;testwrite.mod_write.fwrite(2)"

System information
macOS Version 10.15.3
gfortran -v:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/9.2.0_1/libexec/gcc/x86_64-apple-darwin18/9.2.0/lto-wrapper
Target: x86_64-apple-darwin18
Configured with: ../configure --build=x86_64-apple-darwin18 --prefix=/usr/local/Cellar/gcc/9.2.0_1 --libdir=/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 9.2.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 9.2.0 (Homebrew GCC 9.2.0_1)

g++ -v:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin19.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

cython --version
Cython version 0.29.14
python --version:
Python 3.7.4
f2py version 2

I posted the same question at https://stackoverflow.com/questions/60693732/cython-segmentation-fault-when-calling-fortran-library-with-a-write-fmt-str-s but have not got any answer yet.

I wouldn't know why Cython should be doing anything differently. AFAICT, the way it calls the Fortran code is always the same, so if a certain (output) operation crashes inside of Fortran, I can't see that being Cython's fault.


✨ Track ks/OTP release 0.1.11

Summary
This PR tracks release 0.1.11 of ks/OTP.
Related issue(s)
Fixes #

/cc @nirrozenbaum
/cc @ezrasilvera
/cc @francostellari

/lgtm
/approve

/approve


Collapsible Headings - buttons

Would it be possible to have a setting for the buttons on the left hand side that toggle section collapse? They are quite large and people who prefer to stay on the keyboard as much as possible likely don't use them anyway - the keyboard shortcuts are great.

Absolutely, I'll get onto it.

Right, I think it's done, see #475.
I found the buttons handy for gauging the level of each heading. I thought it might get confusing trying to tell whether sections were collapsed, or just empty without them, but it is a matter of opinion, I suppose. I've left the options to default to showing the buttons, anyway.
I've also slightly altered the functioning so that the collapsible_heading_collapsed css class is applied to the cell rather than the toggle button, so one could add custom css to show collapsed headings if that were helpful/preferable.
Hope that helps,
J

(some more updates added to #475, more things are now configurable)


Missing indexes in the database

Description
Following  indexes improve the performance in WSO2 IS

CREATE INDEX IF NOT EXISTS IDX_SIA_AI ON SP_INBOUND_AUTH(APP_ID);

There are no indexes which will be hit by the following queries.

SELECT PROPERTY_KEY, PROPERTY_VALUE FROM IDN_OIDC_PROPERTY WHERE TENANT_ID = ? AND CONSUMER_KEY = ?
SELECT UM_ID FROM UM_HYBRID_ROLE WHERE UM_ROLE_NAME =? AND UM_TENANT_ID=?

Type
Improvement
Affected version
5.7.0

These changed need to be added to the migration client as well..

Migration impact tracked with https://github.com/wso2/product-is/issues/5245
Resolving the issue as fixes are incorporated


Linker error while using code in my own project.

Hi,
Thank you for the contribution. This project helped a lot in solving my webrtc problem.
Please see the picture above. I'm using the code in my own project, and the linker error suddenly occured. I'm sure I've added the webrtc compiled library in my library search path. I'm just wondering whether the project build setting was changed somewhere in order to build perch. Please help, thank you.

Hi Difujia,
Thanks for the feedback. Unfortunately, the PerchRTC classes are not setup to be easily used outside of the sample app yet (Would you be interested in this? See #7).
However, I'll see what I can do to help. The big issue when building in your own project is the CaptureKit classes. As we are subclassing C++ WebRTC classes within our project, the nighthawk-webrtc build includes C++ headers necessary for capture. Besides the headers, and defines in nighthawk-webrtc you also need to add the -fno-rtti flag to both PHVideoCaptureKit, and PHVideoCaptureBridge (see screenshot from the PerchRTC sample project).

Hope this helps,
Chris

Great, that works, thanks. I will look into wrapping this into a pod later.

No worries about the pod spec ticket, I self assigned it :) We are going to land a few more bug fixes and enhancements before dealing with class prefixes and packaging the code up for reuse.


Add Beginner-Level Python Projects

This is a simple egg-catching game built using Python and the Tkinter library. The player controls a catcher to catch falling eggs, scoring points for each successful catch while trying to avoid losing lives. The game increases in difficulty as time progresses.
Pull Request for PyVerse 💡
Issue Title : Add Beginner-Level Python Projects

Info about the related issue (Aim of the project) : This is a simple egg-catching game built using Python and the Tkinter library. The player controls a catcher to catch falling eggs, scoring points for each successful catch while trying to avoid losing lives. The game increases in difficulty as time progresses.
Name: Pasam Tharun
GitHub ID:  PasamTharun
Email ID<EMAIL_ADDRESS>**Idenitfy yourself: ** GirlScript Summer of Code 2024 Contributor

Closes: #58
Describe the add-ons or changes you've made 📃

Added a scoring system that tracks and displays the player's score in real-time.
Implemented a lives system that deducts lives for each missed egg and ends the game when all lives are lost.
Increased the difficulty of the game by adjusting the speed and frequency of falling eggs based on the player's score.

How it Works

Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested? ⚙

The game has been tested for functionality, ensuring that the scoring and lives systems work as intended.
Verified that the difficulty adjustments function correctly without causing game crashes or unexpected behavior.

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added tests that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

@PasamTharun please add proper comments for every function.

Do mean in code???
On Sat, 5 Oct, 2024, 3:57 pm UTSAV SINGHAL, @.***>
wrote:

@PasamTharun https://github.com/PasamTharun please add proper comments
for every function.
—
Reply to this email directly, view it on GitHub
https://github.com/UTSAVS26/PyVerse/pull/113#issuecomment-2395010637,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDYCS4OTQLMA44I5TYWP4VDZZ65J5AVCNFSM6AAAAABPNGUG42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGAYTANRTG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Do u mean in code??
On Sat, 5 Oct, 2024, 3:58 pm Pasam Tharun, @.***> wrote:

Do mean in code???
On Sat, 5 Oct, 2024, 3:57 pm UTSAV SINGHAL, @.***>
wrote:

@PasamTharun https://github.com/PasamTharun please add proper comments
for every function.
—
Reply to this email directly, view it on GitHub
https://github.com/UTSAVS26/PyVerse/pull/113#issuecomment-2395010637,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDYCS4OTQLMA44I5TYWP4VDZZ65J5AVCNFSM6AAAAABPNGUG42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGAYTANRTG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes

Done buddy
On Sat, 5 Oct, 2024, 4:00 pm Pasam Tharun, @.***> wrote:

Okay sure
On Sat, 5 Oct, 2024, 4:00 pm UTSAV SINGHAL, @.***>
wrote:

Yes
—
Reply to this email directly, view it on GitHub
https://github.com/UTSAVS26/PyVerse/pull/113#issuecomment-2395011257,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDYCS4N76HMN7R2G6RE2NODZZ65UFAVCNFSM6AAAAABPNGUG42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGAYTCMRVG4
.
You are receiving this because you were mentioned.Message ID:
@.***>


Fix link to Ludwig

https://uber.github.io/ludwig returns 404

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


Can't check other stat of dual-mod

My gloves have crafted +12 max life and 79 in base. But either I can't select +91 Life nor +12 AND +79. Also looks like it doesn't search dual mod at all cause as you can see in STAT FILTERS there is no #% Increased Energy Shield

Seems odd. Multiple filters are definitely possible. Can you share your copied item please? (CTRL+C while hovering)
Total modifiers are not supported yet.

Sure ;)
Rarity: Rare
Ghoul Hold
Fingerless Silk Gloves
Quality: +20% (augmented)
Energy Shield: 60 (augmented)
Requirements:
Level: 70
Str: 111
Int: 95
Sockets: R-R-R-B
Item Level: 85
14% increased Spell Damage (implicit)
Adds 6 to 9 Physical Damage to Attacks
+79 to maximum Life
Regenerate 9.4 Life per second
+47% to Fire Resistance
+32% to Cold Resistance
19% increased Energy Shield (crafted)
+12 to maximum Life (crafted)

Fixed with 0.5.0-alpha.0.


Add ordered and unordered lists

I've got you covered: a3583ffe8292ed6d270718015e61772b757a965d
Lists weren't originally part of our requirements, so I left them out, but I put them in now.
Thanks :)

@cjwirth It is working great. Thank you very much ;)


Feature updates to heapster

Removed elasticsearch dependency - faster pulls and start up time for grafana
Placed all components behind a replication controller
Added a Grafana service in preparation for getting rid of host ports.
Updated dependencies to static versions instead of 'latest'.

Note: The changes to Godeps will disappear once #37 has been merged.

cc @rjnagal @vmarmol. If possible try running heapster with this PR.

I am going to try this patch tonight.

Can you rebase to remove Godeps and squash other patches? It'll make it easier to cherrypick.

@rjnagal: Rebased and squashed a few commits.

Changes LGTM, will try out in a cluster now.

Finally got around to testing this. I works as expected. The only change would be to update the README with the new instructions :)
Feel free to do that in another PR. Merge away!

Thanks for the update @vmarmol.
On Wed, Jan 7, 2015 at 5:31 PM, Victor Marmol<EMAIL_ADDRESS>wrote:

Finally got around to testing this. I works as expected. The only change
would be to update the README with the new instructions :)
Feel free to do that in another PR. Merge away!
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/heapster/pull/39#issuecomment-69122999
.


Corrupt BLP or error?

Hello. I have a single BLP that does not convert. Could you take a look at it and tell me if it's just this BLP that's broken or if there is an error in the code?
SlimeSkinBlue.blp.zip
Thanks!

Hello
I think it might be a problem with the BLP file.
The conversion fails when an attempt is made to decode the JPEG image stored inside the BLP file (at blp.cpp:297).
If you put the following lines at, say, line 295, a file called image.jpg will be created containing the bytes extracted from the BLP file that are supposed to be a JPEG image:
FILE* pFile = fopen("image.jpg", "wb");
fwrite((void*) pSrcBuffer, pInfos->jpeg.headerSize + size, 1, pFile);
fclose(pFile);

In this case, image.jpg is a 51KB file that doesn't look like a correct JPEG image: its dimensions are reported to be 0x0 pixels. I don't know if it is the only error in the file.

Okay. Thank you very much for taking a look :).


REFACTOR collection form to react-hook-form

Note: I'm aware that the GitHub URL field is not saving correctly. I don't think it did before this refactor and I don't think I can fix this without backend changes. Therefore, I've made this ticket.

Seems like the endpoints select is showing some weird behaviour


Detect clickable elements programmatically

How it works
Clickable detector is implemented as a plugin that is called whenever a new state is discovered by Crawljax.
It detects clickables by using getEventListeners function in chrome devtools.
Requirements:

Google Chrome Browser

BrowserConfiguration.BrowserType = CHROME/CHROME_HEADLESS

Chrome Developer Tools enabled

Default BrowserProvider : BrowserOptions.setUSE_CDP(true)
Custom BrowserProvider : WebDriverBackedEmbeddedBrowser.setUSE_CDP(true)

For example usage, see ClickableDetectorExample in examples module
Limitations

Does not work for browsers other than Google Chrome
If the element interactions are not associated with a corresponding eventhandler as determined by browser, then they wont be considered clickables
Only click action is currently supported. Other interactions such as hover are not supported.

Feature is available now from 26ba317648aa240c60194c8290d36af7b30b98e5


PowerShell.EndInvoke(IAsyncResult) doesn't provide a way for users to get the partial results when a terminating error is thrown

When a terminating error is thrown from the script, PowerShell.EndInvoke(IAsyncResult) will throw the exception and there is no way to get the partial results back (output from before the terminating error).
It would be good to make it able to return the partial results when a terminating error is thrown.
Steps to reproduce
$ps = [powershell]::Create()
$ps.AddScript("'Hello World'; gcm blah -ea stop; 'yeah'") > $null
$a = $ps.BeginInvoke()
$b = $Ps.EndInvoke($a)

Expected behavior
Throw the exception, but at the same time allow the users to get the partial results back.
Actual behavior
Exception is thrown, $b is null, and the partial output is lost.
Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Move @PaulHigin's comment on this issue from https://github.com/PowerShell/PowerShell/pull/7917#discussion_r224256267

I feel this is fundamentally broken because if a terminating error occurs (including stop) then any data generated up to that point is lost ... a major sin in my book.
Some ideas to remedy:

Catch pipeline stop exception and insert into Error stream as non-terminating error. But this doesn't address a general terminating exception.
Catch all terminating exceptions (in EndInvoke) and insert into Error stream, marking the error as terminating in some way.
Create a new "EndInvoke" exception class that is thrown, which wraps the actual terminating error and also provides the output buffer as a parameter.

Wouldn't that be expected behavior?  A script would work the same way
function test { 'Hello World'; gcm blah -ea stop; 'yeah' }
$result = test
$result
# no output

I would think you typically wouldn't want output from a failed invocation, but there's always this overload for when you do
$ps = [powershell]::Create()
$ps.AddScript("'Hello World'; gcm blah -ea stop; 'yeah'") > $null
$inputCollection = [System.Management.Automation.PSDataCollection[psobject]]::new()
$output = [System.Management.Automation.PSDataCollection[psobject]]::new()
$a = $ps.BeginInvoke($inputCollection, $output)
$b = $Ps.EndInvoke($a)
$output

-> I would think you typically wouldn't want output from a failed invocation
It seems to me to be just the opposite.  For a long running script I would want to get all output information occurring before a terminating error.  It would help understand what happened, what may have caused the error, and what state the machine is in.

For a long running script I would want to get all output information occurring before a terminating error. It would help understand what happened, what may have caused the error, and what state the machine is in.

I'm inclined to agree that having output information would be useful in the initial stages of development and testing.  Once the code is in use I think it would be more common to rethrow or change code paths (and if you do absolutely need it, the other overload is still available to you).
That said, my main concern isn't really about the output and more about changing the behavior of EndInvoke.
Since the output collection is stored internally on the PowerShellAsyncResult returned by BeginInvoke, would it make sense to instead have a new method that can retrieve the output? e.g.
public PSDataCollection<PSObject> GetAsyncOutput(IAsyncResult);


[IR-28891] Bug Fix for serverless-init logging

What does this PR do?
This PR fixes a bug where logs were no longer being submitted from serverless-init unless a container was restarted or stopped.

Motivation
[BUG] serverless init 1.2.3 is not sending logs
IR-28891

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
Unit tests and deployed to self-monitoring apps

/merge


Compiled Minified JS is not exposing a usable Stack Trace on Error

I'm no longer able to capture usable Stack Traces from errors in a minified dart2js app with the 1.13.0 SDK. This is problematic because we capture the minified Stack Trace in the JS app to run it through the source_map_stack_trace package.
void main() {
  ...
  window.onError.listen((ErrorEvent e) {
    log.severe(e.message);
    ...
  }
}

SDK 1.12.1:
bootstrap.dart.js:1779 Uncaught Uncaught Error: Bad state: Unable to fetch Vessel session: XMLHttpRequest error.
Stack Trace:
Bad state: Unable to fetch Vessel session: XMLHttpRequest error.
    at dart.j (http://localhost:1040/bootstrap.dart.js:1779:3)
    at Jm.dart.Jm.$1 (http://localhost:1040/bootstrap.dart.js:27008:14)
    at dart.EL (http://localhost:1040/bootstrap.dart.js:12007:24)
    at a5J.dart.a5J.f9 (http://localhost:1040/bootstrap.dart.js:13922:16)
    at a6N.dart.a6N.$0 (http://localhost:1040/bootstrap.dart.js:12570:12)
    at dart.a7.static.hp (http://localhost:1040/bootstrap.dart.js:12495:75)
    at a7.cl (http://localhost:1040/bootstrap.dart.js:12442:3)
    at a6H.dart.a6H.$0 (http://localhost:1040/bootstrap.dart.js:12537:23)
    at dart.EJ (http://localhost:1040/bootstrap.dart.js:12004:9)
    at a5J.dart.a5J.ct (http://localhost:1040/bootstrap.dart.js:13918:16)

SDK 1.13.0:
Uncaught NullError: method not found: 'bl' on null

SDK Info: Dart VM version: 1.13.0 (Wed Nov 18 12:15:29 2015) on "macos_x64"

is there any update on this? it makes tracking down production issues near impossible on the 1.13.0 SDK

@travissanderson-wf @raphaeladam-wf Is it easy to reproduce? Could you try with the latest 1.14-dev release and see if it's still there?

mmm - I'm not yet able to reproduce the problem - in part e.message is only giving me the error message both in 1.12.1 and in 1.13.0. Are there more details on how you are extracting the stack trace from the error that are not shown above?
Here is what I'm doing:
main() {
  window.onError.listen((e) => print(e.message));
  document.body.onClick.listen((e) => foo());
}

foo() {
  ...
  // foo internally throws, but I made the code deep
  // enough to have some interesting stack trace
}

Another question: are you also seeing this issue when you use try-catch blocks? or only for asynchronous errors on window.onError? 1.13.0 didn't have that many changes on this. The main related change I recall was this commit (https://github.com/dart-lang/sdk/commit/5363e5c9453b096900d3a9bbc37012a4ea65f754) that was meant to improve how we capture the stack trace for errors thrown on async callbacks. Seems to be closely related to this, so it's possible that the bug was introduced there.

I have an example app here:
broken_app.zip
Built with 1.13.0 SDK
index.bootstrap.initialize.dart.js:4403 ErrorEvent: Instance of 'cd'
2015-12-22 13:52:45.575 index.bootstrap.initialize.dart.js:4403 ErrorEvent.error: NoSuchMethodError: method not found: 'ee' (C.f.ee is not a function)
2015-12-22 13:52:45.575 index.bootstrap.initialize.dart.js:4403 ErrorEvent.fileName: http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js
2015-12-22 13:52:45.575 index.bootstrap.initialize.dart.js:4403 ErrorEvent.message: Uncaught NoSuchMethodError: method not found: 'ee' (C.f.ee is not a function)
2015-12-22 13:52:45.575 index.bootstrap.initialize.dart.js:4403 ErrorEvent.type: error

Built with 1.12.1 SDK
index.bootstrap.initialize.dart.js:4446 ErrorEvent: Instance of 'ErrorEvent'
2015-12-22 14:48:24.966 index.bootstrap.initialize.dart.js:4446 ErrorEvent.error: Uncaught Error: NoSuchMethodError: method not found: 'ej' (C.f.ej is not a function)
Stack Trace:
TypeError: C.f.ej is not a function
    at bI.dart.bI.eM (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5410:29)
    at eval (eval at <anonymous> (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1270:8), <anonymous>:2:34)
    at dart.eh (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1083:69)
    at eY.dart.eY.b4 (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5176:10)
    at eY.dart.eY.aA (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5177:30)
    at kR.dart.kR.$2 (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4827:20)
    at dart.eh (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1083:112)
    at dart.kg (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4125:14)
    at http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4242:63
    at main-app.reverseText (http://localhost:63342/untitled4/build/web/index.html:10902:21)
2015-12-22 14:48:24.966 index.bootstrap.initialize.dart.js:4446 ErrorEvent.fileName: http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js
2015-12-22 14:48:24.966 index.bootstrap.initialize.dart.js:4446 ErrorEvent.message: Uncaught Uncaught Error: NoSuchMethodError: method not found: 'ej' (C.f.ej is not a function)
Stack Trace:
TypeError: C.f.ej is not a function
    at bI.dart.bI.eM (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5410:29)
    at eval (eval at <anonymous> (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1270:8), <anonymous>:2:34)
    at dart.eh (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1083:69)
    at eY.dart.eY.b4 (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5176:10)
    at eY.dart.eY.aA (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:5177:30)
    at kR.dart.kR.$2 (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4827:20)
    at dart.eh (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:1083:112)
    at dart.kg (http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4125:14)
    at http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js:4242:63
    at main-app.reverseText (http://localhost:63342/untitled4/build/web/index.html:10902:21)
2015-12-22 14:48:24.966 index.bootstrap.initialize.dart.js:4446 ErrorEvent.type: error

@kevmoo I'll give 1.14 a whirl

@kevmoo Upgrading to 1.14.0 does not appear to resolve the issue
Built with 1.14.0-dev.1.0 SDK:
ErrorEvent: Instance of 'ce'
2015-12-22 15:19:35.932 index.bootstrap.initialize.dart.js:4386 ErrorEvent.error: NoSuchMethodError: method not found: 'e9' (C.f.e9 is not a function)
2015-12-22 15:19:35.932 index.bootstrap.initialize.dart.js:4386 ErrorEvent.fileName: http://localhost:63342/untitled4/build/web/index.bootstrap.initialize.dart.js
2015-12-22 15:19:35.932 index.bootstrap.initialize.dart.js:4386 ErrorEvent.message: Uncaught NoSuchMethodError: method not found: 'e9' (C.f.e9 is not a function)
2015-12-22 15:19:35.932 index.bootstrap.initialize.dart.js:4386 ErrorEvent.type: error
2015-12-22 15:19:35.932 index.bootstrap.initialize.dart.js:717 Uncaught NoSuchMethodError: method not found: 'e9' (C.f.e9 is not a function)

Thanks for sending the repro test case, that was very helpful.
Seems that the problem only comes up when an existing zone wraps and rethrows the error. Polymer uses js-interop and binds callbacks to a zone. We can oversimplify that like this:
import 'dart:async';
import 'dart:html';
import 'dart:js' as js;

main() {
  window.onError.listen((e) => print(e.message));
  js.context['foo'] = Zone.current.bindCallback(callback);
  js.context.callMethod('foo', []);
}
callback() => throw 'hi there';

The JS interop bit is a bit of a red herring. Using an async microtask instead of body.onClick is enough to reproduce this in a couple lines:
import 'dart:async';
import 'dart:html';

main() {
  window.onError.listen((e) => print(e.message));
  new Future(callback);
}

callback() => throw 'hi there';

I'm going to investigate further to find the proper fix, but it would be nice if there was a more reliable way to get the stack trace than reading it out of a serialize message. It's not nice that if you get an exception that wasn't re-thrown, all the sudden you get fewer details (like my initial attempt to repro the problem).

@sigmundch Thank you! We appreciate you taking time to look into this.

OK - I think I have a better understanding of what's happening.
The regression was introduced in da8baacae46e5f1f00d90ada1fa85dc0a9e0286c. We stopped wrapping exceptions when rethrowing in zones, we weren't capturing the stack trace correctly and 5363e5c9453b096900d3a9bbc37012a4ea65f754 fixed that.
Because we don't wrap the rethrown exceptions, we can no longer override toString to include the extra stack trace. However, the stack is available and we attach it to the .stack property of the error. Unfortunately this makes the error harder to extract because it is not exposed through the Dart APIs - you need to use js-interop to get to it.
You can do this in multiple ways:

wrap the ErrorEvent object you get on onError and read the e.error.stack property from JS:

window.onError.listen((e) {
  var error = new JsObject.fromBrowserObject(e)['error'];
  if (error is JsObject) {
    print('stack is here: ${error['stack']}');
  }
  print(e.message);
});

use js-interop to listen for on-error events in the first place (like we do on this tests)

The good news is that this same logic is how you can to read out the stack trace when the original error was not rethrown (for example, my original attempt with document.body.onClick now will also print a nice stack trace from error['stack']).
I don't believe it makes sense to revert the changes in dart2js, since the new behavior is better at unifying how exceptions should be handled regardless of whether they are re-thrown. I'll wait to hear from you first to make sure the suggestions I propose here work for you before closing this bug, though.
/cc @lrhn (who made these changes in the firsplace), in case he has some additional insights/ideas to share.
One last note: the first change is in the stable channel 1.13.0, but the change is not (it was picked up in 1.14.0). Without the latter, you'll get a stack trace from the rethrown location, rather than the original trace. If it's important for you guys to work on the stable channel, let us know and we'll file a request to merge the fix into the stable channel.

We are probably stuck in the stable channel (for production and CI, but some of us use dev channel locally).  If it isn't coming until 1.14 is in the stable channel, our workaround might just be to downgrade to 1.12 until 1.14 is stable.  Thanks for looking into this.

Thanks for letting me know - I have filed a request to merge the fix into 1.13 (see #25334) so hopefully you don't have to workaround this for much longer. I'm closing this issue since all there is left to do is covered by that other bug.

Quick update - Bill just released a new stable channel version (1.13.2) that includes the fix. That should hopefully let you continue using the stable channel without downgrading.

@sigmundch thanks for the quick turnaround, we will upgrade our systems to use 1.13.2 and verify all is well for us!

Indeed! Thank you very much for the speedy response and resolution.

It works!  Thanks again.


nimble/ll: Fixes for dle

this needs some more changes

Test this please
Using our bot for tests. Not asking the PR author for testing.


New native Windows driver (win32drv)

Differences from the old native Windows driver (win_drv)

Much higher performance than the old native Windows driver and the SDL driver.
Only depends on Win32 API and C Runtime.
Written in pure C, so you can use it on x86, x64, ARM and ARM64 Windows.
Add support for Per-monitor DPI Aware.
Add support for keyboard and mouse wheel.
Customize window icon support.

Benchmark
The SDL driver

The new native Windows driver

Unbelievable!
But what is the trick? :slightly_smiling_face:  It seems you just copy the image rendered by LVGL into your buffer:
memcpy(g_pixel_buffer, color_p, g_pixel_buffer_size);
It's what most of the drivers do.

Unbelievable!
But what is the trick? 🙂 It seems you just copy the image rendered by LVGL into your buffer:
memcpy(g_pixel_buffer, color_p, g_pixel_buffer_size);
It's what most of the drivers do.

First, I create the Windows GDI bitmap object only once in this implementation and get the memory address for writing the pixels. So, I can reuse the bitmap object. It will reduce most of the context switching overhead.
Second, I use rounder_cb to make copy the LVGL's pixel buffer to the bitmap object's pixels address easier.
In general, I had tried my best to reduce the memory copy operations. But I can't use my zero memory copy operation implementation for the universal driver because I can't limit the user only use the 32bpp color depth. (But in the repository for Windows desktop application, I can do that.)

Thanks! I'm surprised that memory copy is so expensive even on PC.


Open devtools for android web view programmatically

Hi, I'm trying to automate opening devtools for android webviews. Currently I go to chrome://inspect and click inspect on my device, but that takes a lot of time throughout the day. So, I want to open devtools using cli.
So far I have this,
devtools_port=$(adb shell "cat /proc/net/unix" | rg 'webview_devtools_remote_([0-9]+)' -or '$1')
adb forward tcp:9222 localabstract:webview_devtools_remote_${devtools_port}
open -n -a "Google Chrome" $(chrome-remote-interface list | jq -r .[0].devtoolsFrontendUrl)

However it tells me "Debugging connection was closed. Reason: WebSocket disconnected"

Related issue: https://github.com/cyrus-and/chrome-remote-interface/issues/473

Not sure how is this related to chrome-remote-interface. The list command is merely returning data from /json/list.

Thanks for the reply. I assumed that chrome-remote-interface might be able to help with this, especially when I saw #473.
So chrome-remote-interface can't help here?

You could use chrome-remote-interface to interact with the target, as seen in #473, just remember to use -l to use the local version of the protocol, since Chrome for Android doesn't come with it.
But that's another story, what you're trying to do should work, I can reproduce your issue (even with regular Chrome pages; I don't have any WebView to test). The cause was this:
Rejected an incoming WebSocket connection from the devtools://devtools origin. Use the command line flag --remote-allow-origins=devtools://devtools to allow connections from this origin or --remote-allow-origins=* to allow all origins.

Not sure how to go about it with Android.

Truly appreciate your help. I tried adding that argument, but same exact error ("WebSocket disconnected").
devtools_port=$(adb shell "cat /proc/net/unix" | rg 'webview_devtools_remote_([0-9]+)' -or '$1')
adb forward tcp:9222 localabstract:webview_devtools_remote_${devtools_port}
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  $(chrome-remote-interface list | jq -r .[0].devtoolsFrontendUrl) \
  --args --remote-allow-origins=*

If interested, I could build you a plain capacitorjs APK in debug mode, so that chrome://inspect can open it.

That flag should be passed to Chrome on Android, or the WebView in your case. Of course passing a flag to a WebView makes no sense, maybe there's something to put in the manifest.

Thanks again. It's strange that this is all needed, while chrome://inspect lists all devices without any steps, and with a single click opens the inspector.
I added a break point to chrome://inspect and saw this data passed to the callback.

Don't see how that helps. I'll try to ask the Chrome team directly how to programmatically open a device listed on chrome://inspect.

Yes, it's strange indeed, and I'm pretty sure it used to work the way you describe, i.e., passing the ws= query parameter; it must be a recent change.


Not restoring completely using Android 5.0.2 on Samsung Galaxy S3

I have 8000 plus message to restore but however it didnt restore completely. Only few hundreds of old old sms were restored.   After it completed restored, it showing "updating threads" on the notification bar.
Then after finishing restoring all ~8000 messages without error, SMS Backup+ reports that all my SMS were duplicates.
I checked in privary guard setting and read sms/mms was turned on for  SMS Backup+ setting.
I downloaded the beta version 1.59 beta 3 and it still the same.. Pls help

Got the same issue

Seems duplicate of #527

Dup


[Windows] VSC 1.17.0 update : slashes now become backslashes

Expected : path/to/file.ext
Got : path\to\file.ext

@Paulmicha You can modify the plug-in source code.If you are a windows user, VSCode extensions generally on there C:/Users/Administrator/.vscode/extensions , and Linux or Mac on there ~/.vscode/extensions.

Resolved via PR #7