We need a "Back" button

As I am drilling down into different screens, I need an easy way to get back to the sub-screen that I was just on. So, we need browser-style forward and back buttons please.

If you are using a web browser, you can use the browser back buttons, but agreed this needs to be a standard part of the UI.

Sorry, I should have mentioned that, I use the Linux Light Client.

+1 Many friends of mine asked it too.

Most browsers put these in the upper left corner so let's keep convention

These are fontawesome arrows and I shifted the header menus over to accommodate them.

Should these be visible for light clients and hosted wallets?

Yes. It wouldn't be terrible for them to be on the web stuff as well. Might be easier and they could perform the same function as the back and forward buttons built into the browser. Your call though.

Yep definitely easier so if that's ok I'll just add them without any logic for turning them off.

Would be great if you could give them a hover state as well.

Looks-wise, they should match all the other buttons in the ui like the Generate buttons you see in the Deposit/Withdraw screen. Mouseover effects should be subtle.

So, more like this? Uglier but consistent :)

Yea I prefer the first one tbh

I love it, hover makes the light gray go to the same shade of white as the word Dashboard, or vise versa effect. No fill necessary.

They could be a tad smaller..

It is more consistent though as you say so I'll go with that

I've spent far too much time getting this right in terms of alignment etc so I don't wanna spend even more time getting the size right, I'm sure someone more css savy than me can get right... The functionality is there though.

It's fine. It's not technically a bug so leave it as is.

I'm still in love with it, thanx for adding it! :)

I think back and forward buttons need to be shown only in light wallets, in a browser they just duplicate browser's buttons. What do you think?

Well, in the interest of time, I don't see the harm in displaying them in the web as well. But feel free to make the call.

When it comes to supporting a customer with Technical Support, the Rep must be able to assume a consistent interface when speaking with the customer over the phone. For example, the Rep will say (do you see the left and right arrow buttons in the top right corner next to the word Dashboard?
If each wallet version starts looking different, light wallets vs web wallets etc, it will make Tech Support a real nightmare over time. Consistency is very important IMO.

I'm fine with the duplicated controls.


NoWhiteSpaceValidator not working

The no white space validator supplied by django-extensions is not called during form validation
Running Django-extensions 1.7.3 with python 2.7 on django 1.8

Is it possible to make a PR with a test case ?
That way we have the exact problem to fix and can make sure there will be no regression in the future.
Thanks

Actually after some in-depth investigation, it is working as expected. Writing tests helped! Thanks @trbs

@AthulMuralidhar awesome :-)
You think your test case might be interesting to include in django-extensions as additional tests ?

@trbs  it was just some brute force testing (i'm not too proud of it haha)


ark_PvPStructureDecay="true".... no?

 All other changes to arkmanager.cfg are added to GameUserSettings.ini. At least the minor changes I have made.
Is it a flag now?

The ark_... settings in arkmanager.cfg are passed to ShooterGameServer as options.  They are not directly added to GameUserSettings.ini by arkmanager.  It is the ShooterGameServer itself that adds certain options into GameUserSettings.ini.
It's possible that PvPStructureDecay is not one of the options that is copied from the command-line options to GameUserSettings.ini

Ah... I'll look more into it then.


Suggest --bind localhost for local preview

Otherwise, the app just displays the following message:

Shinylive uses a Service Worker, which requires either a connection to
localhost, or a connection via https.

Can you explain exactly how to reproduce the problem, and how this change fixes it? It's not clear to me.

Sure, happy to! (Sorry for being a bit terse in the OP, I was in a bit of a rush.)
Reproduction steps (I'm on macOS 13.0.1, using Firefox 107):

Create an app with shiny create my-app.
Export it with shinylive export my-app my-app/site.
This shows the following suggestion:

Run the following to serve the app:
  python3 -m http.server --directory my-app/site 8008

Running the server as suggested logs the following message: Serving HTTP on :: port 8008 (http://[::]:8008/) ...
Visiting http://[::]:8008 in the browser, I expect the app to start, but I get this message instead: Shinylive uses a Service Worker, which requires either a connection to localhost, or a connection via https.

:: is the IPv6 equivalent of <IP_ADDRESS>, i.e. all listen on all addresses on the local machine. But Shinylive seems to specifically require localhost (<IP_ADDRESS> in IPv4, ::1 in IPv6) unless HTTPS is used. Setting up HTTPS just for testing is too much work, but restricting the server to listen to localhost is only a --bind localhost away:
$ python3 -m http.server --directory my-app/site --bind localhost 8008
Serving HTTP on ::1 port 8008 (http://[::1]:8008/) ...

Visiting http://[::1]:8008/ in the browser then results in the app starting as expected.
So I figured that Shinylive should include --bind localhost in its suggestions on how to serve the exported website, to avoid this problem in the first place.

Just adding that I see the same behavior on Fedora 37.

OK, I understand now. It seems that the issue is that the message that is printed says that it's listening on ::, which is the IP6 equivalent to <IP_ADDRESS>, and means it's listening on all interfaces:
$ python3 -m http.server --directory site 8008
Serving HTTP on :: port 8008 (http://[::]:8008/) ...

But if you visit http://[::]:8008/ or http://<IP_ADDRESS>:8008/, neither of those is a localhost address, and so the browser's security sandbox won't allow running the service worker.
Because the server is listening on all interfaces, it is possible to visit localhost addresses like http://[::1]:8008/, http://<IP_ADDRESS>:8008/, or  http://localhost:8008/, and the app will run just fine.
That said, I think you're right that it makes sense to add --bind localhost, because users might copy and paste the http://[::]:8008/ address printed by http.server, and because there's no reason to listen to other interfaces, since these apps won't run if visited from an external interface.

Yes, you are exactly right: it's not about the current tip being technically wrong, it's about making http.server show a more helpful hint. Sorry for the confusion!


Command line: Increased prompt opacity

While reviewing switching between themes on the Command line plugin page, I noticed that the prompt is very hard to read for some themes. This is because the prompt only has an opacity of 40%. While this may have been in line with the previous fixed color (see #3326), I think it's too transparent.
This PR changes the opacity to 70%. This ensures that the prompt is readable is all themes. (Except Funky, but Funky has problems with Command Line in general, so let's ignore it.)

@at055612, this might interest you.

Agree with this change, also makes it consistent with the opacity of the output lines.


Implemented provider ddnss

I implemented libdns for the provider ddnss (https://github.com/libdns/template/pull/2).

Accepted -- thanks for the contribution!


Allow rustfmt to abort when using nightly only features on stable channel

Resolves #5022
Summary
At a high level, this feature was implemented by adding a new configuration option that toggles whether we abort rustfmt or log warnings when using unstable options on the stable channel. If we're on the stable channel and unstable features have been used, we decide how to move forward based on the set configuration option.
At a lower level this PR was implemented by making the following changes:

Adds a new configuration option called abort_on_unrecognised_options. This was the name suggested in the original issue, but I don't mind changing it.

The default value is set to false and the option was marked as unstable. Because it's unstable we needed to special case this option when determining if a user used an unstable option.

Adds an internal ~Vec~ UnstableOptions struct to Config to track unstable options used when on stable rustfmt
Helper methods are added to display both warnings and abort messages.

warning messages have been removed from fill_from_parsed_config

New method name abort_or_warn_on_unstable_options was implemented for Config which returns a new enum HandleUnstableOptions.
~A macro named abort_or_warn_on_unstable_options! was added to bring all the implementation details together in an ergonomic way~.
load_config now returns a Result<(Config, Option<PathBuf>) ,LoadConfigurationError>

Testing
Tests were added for all the helper methods. Some tests are only intended to run on nightly, and the rest of the tests are expected to run on stable.
I wasn't quite sure how to write the full integration test, so I'd appreciate some guidance on that as well as any other feedback on the PR.
I think the following integration tests are still needed:

Run rustfmt on stable with abort_on_unrecognised_options = true while using unstable options

Make sure we exit with status 1 and don't reformat the file
optionally test the abort messge

Run rustfmt on stable with abort_on_unrecognised_options = true while not using unstable options

Make sure we exit with status 0 and reformat the file

Run rustfmt on stable with abort_on_unrecognised_options = false while using unstable options

Make sure we exit with status 0
Make sure we output the warnings we expect

Run rustfmt on stable with abort_on_unrecognised_options = false while not using unstable options

Make sure we exit with status 0
Make sure no warnings were output

5-8) Run all combinations of test listed above but use nightly instead of stable.

Unclear what the output should be since abort_on_unrecognised_options shouldn't have any effect on nightly

Additional Thoughts
Also, something that I wondered about but didn't implement was what happens when you set the new option to true on nightly? Currently nothing happens, but should we print out a warning to let users know that the option won't have any effect?

Thank you for the PR! You've raised some good questions that I need to think on a bit.
An interesting wrinkle to the testing is that we actually only run our own CI/local builds on nightly, so we'd either need some trickery for the unit tests, or would otherwise just have to drop them and rely on human testing/validation.
The integration test story might be "easier" in the sense that we could compile on nightly and then use the stable version of cargo fmt and the associated env var to utilize the built version of rustfmt instead of the bundled one.
As far as the behavior goes, as long as all the unstable/unavailable options are still printed (as opposed to just the first one and then bailing), then I think that should be good

Thinking about the implementation a bit more and glancing over the diff, I've a few thoughts:

The behavior should be baked into the rustfmt library, and not the responsibility of consumers (e.g. the rustfmt bin, users of the lib, etc.) to insert another call to perform the check. The load_config function seems like a reasonable place for this at first blush, though may require a new custom error definition with corresponding updates to the signature and call sites
Are we accounting for unstable options from both config files and command line overrides? (e.g. rustfmt foo.rs --config some_unstable_thing=bar)
Instead of blending the concerns of aggregating options and display text the user, what do you think about defining a new struct to represent the options (and values), storing those (instead of error message Strings), and then encapsulating all the display text content in one place?

The behavior should be baked into the rustfmt library, and not the responsibility of consumers (e.g. the rustfmt bin, users of the lib, etc.) to insert another call to perform the check. The load_config function seems like a reasonable place for this at first blush, though may require a new custom error definition with corresponding updates to the signature and call sites

Also agree that it would be a lot better to have this baked into the rustfmt library. I think I initially implemented it the way that I did because I didn't want to make changes to function calls / signatures, but if you're alright with it then I'll update the implementation!
Would it make sense for load_config to return an anyhow::Result instead of a Result<(Config, Option<PathBuf>), std::io::Error>? Might make it easier to return a custom error type.

Are we accounting for unstable options from both config files and command line overrides? (e.g. rustfmt foo.rs --config some_unstable_thing=bar)

currently, I think that we're only tracking unstable options in a configuration file. Could you point me to where we parse the command line overrides.

Instead of blending the concerns of aggregating options and display text the user, what do you think about defining a new struct to represent the options (and values), storing those (instead of error message Strings), and then encapsulating all the display text content in one place?

I think this is a great idea. I was hoping you could give an example to go off of.

I didn't want to make changes to function calls / signatures, but if you're alright with it then I'll update the implementation

Understood. Fortunately now that we're no longer publishing rustfmt to crates.io we don't need to be constrained by semver compatibility on the public API of the library. There's a handful of folks that are still attempting to consume as a library directly from source, but we've made it clear to them that the API is subject to change without notice.
Feel free to suggest any changes that you think would be beneficial :+1:

Would it make sense for load_config to return an anyhow::Result instead of a Result<(Config, Option), std::io::Error>? Might make it easier to return a custom error type.

Feel free to give it a try

currently, I think that we're only tracking unstable options in a configuration file. Could you point me to where we parse the command line overrides.

Ah that's right, and there's been some past debate about whether the ability to use unstable opts on stable via the cli override is a feature or a bug. IIRC the returned Config already accounts for the values loaded from config files as well as any cli overrides so there shouldn't be any concern (at least for now given current behavior).

I was hoping you could give an example to go off of.

This one is a bit more complicated than what we need on the config side, but here's the main error kind def we return from the main entry point
https://github.com/rust-lang/rustfmt/blob/2c442ccf25a98c9e8f0a972d94f10ef44b7b09bf/src/lib.rs#L99-L143
Note that we don't necessarily have to use an error, but I think we'll want some kind of extension to the return type either way that callers (including the rustfmt bin) can use

I've been doing a little more work on this PR to implement the custom error return type for load_config. and I've run into an issue. I'm not 100% sure if load_config is the right place to emit the error because it leads to some inconsistencies.
The main issue is that load_config is called twice from main::format, and if there are unstable options passed from the command line, then we never get to the second invocation of load_config. This leads to 3 different scenarios where we could encounter unstable options. For the examples below assume we're using this rustfmt.toml file.
error_on_line_overflow = true
error_on_unformatted = true
version = "Two"

1) Unstable options are passed from the command line and we don't use --config-path:
Regardless of whether or not Unstable options exist in the default (unspecifed) rustfmt.toml only the command line options get warned / aborted on.
cargo run --bin rustfmt -- --check --config=abort_on_unrecognised_options=true,reorder_impl_items=true src\macros.rs

Can't set nightly options when using stable rustfmt
    - `reorder_impl_items = true`

Set `abort_on_unrecognised_options = false` to convert this error into a warning

2) Unstable options are not used on the command line but they exist in the default rustfmt.toml
If we don't pass unstable options from the command line and we don't pass the --config-path flag, and there are unstable options in the default rustfmt.toml file, then we'll abort / warn on the unstable options listed in the default rustfmt.toml.
cargo run --bin rustfmt -- --check --config=abort_on_unrecognised_options=true src\macros.rs

Can't set nightly options when using stable rustfmt
    - `error_on_unformatted = true`
    - `version = Two`
    - `error_on_line_overflow = true`

Set `abort_on_unrecognised_options = false` to convert this error into a warning

3)  Unstable options are passed from the command line and the --config-path
This is the only scenario where all unstable options are aborted / warned on.
cargo run --bin rustfmt -- --check --config=abort_on_unrecognised_options=true,reorder_impl_items=true src\macros.rs --config-path=rustfmt.toml

Can't set nightly options when using stable rustfmt
    - `version = Two`
    - `error_on_unformatted = true`
    - `error_on_line_overflow = true`
    - `reorder_impl_items = true`

Set `abort_on_unrecognised_options = false` to convert this error into a warning

How to move forward?
In one of your earlier comments you mentioned you didn't want this type of behavior.

As far as the behavior goes, as long as all the unstable/unavailable options are still printed (as opposed to just the first one and then bailing), then I think that should be good

I guess what I'm wrestling with is these changes bring the abort/warn functionality into the rustfmt lib, but it's the consumer of the lib main::format that's not implemented in a way to properly collect all unstable options.
Do you want me to also make changes to how main::format is implemented or is that a separate issue outside the scope of getting this feature into the project?

I'm not 100% sure if load_config is the right place to emit the error because it leads to some inconsistencies

Just to clarify my original line of thinking, I don't think load_config should be doing any emission itself whatsoever, but I was suggesting that it's return type include the information about specified (but unavailable) unstable options

As a general philosophy I think libraries should be cautious about writing directly to stdout/stderr buffers, especially in a manner that callers/consumers can't control. This starts to become more concretely relevant for us as we've had requests for error presentation to be incorporated into certain emitters vs. dumped to std{out,err} (e.g. if a user has selected the json emitter they'd like to get operational errors like invalid config included in the json object too)

I see what you're saying. The current implementation still prints a warning to stderr, which is the same behavior as before, but after some updates to the implementation the abort error bubbles up to src::bin::main.rs::main where it's caught and printed to stderr.
I've made sure to include the unstable options in the new LoadConfigurationError enum, so if we wanted to make some updates in the future to emit the unstable options differently we can probably do it without too much hassle.

I'm a bit surprised by the scenario you reported in number 1 because I thought the CLI overrides were set with a dedicated function that's on an entirely different call path than the standard config loading, and accordingly I was thinking it'd be possible to handle config file vs. cli overrides differently. Perhaps I'm remembering incorrectly though

You're right about the command line options being set using Config::override_value and toml configuration being loaded using Config::fill_from_parsed_config, however when we call main::format (code linked bellow) the first thing we do is call load_config.
In scenario 1) above, this causes load_config to immediately return a LoadConfigurationError, but we only parse the inline configuration. In scenario 2) we make it to the second load_config call, and in scenario 3 we bail again at the first load_config call.
I guess one scenario I didn't explore was if the abort_on_unrecognised_options=true was set in the default toml file. In that case I suspect we'd make it to the second load_config call and then bail from there.
https://github.com/rust-lang/rustfmt/blob/4389a4ce49e737915af1f1b27b96b05598a4e388/src/bin/main.rs#L290-L336

Regardless, and to clarify a bit more, I'm not terribly concerned if we can't display all unstable opts from both config files and command line overrides. I still have a sense that we can

Got it! In that case I think the current implementation achieves what you had in mind.

I realize that may not have addressed each individual item from your last comment, but does it help?

Helps out a lot! I think we're both on the same page with everything. I think the implementation achieves everything you were looking for, but if not please let me know so I can make adjustments.
The last piece of this is the testing story. I know you mentioned that we aren't testing "stable" in CI, but I was wondering if toggling the CFG_RELEASE_CHANNEL environment variable from nightly to stable is possible / would have any affect. I'm using the is_nightly_channel! macro along with abort_on_unrecognised_options to determine if rustfmt should abort, warn, or continue.

I might've confused myself with the labels :laughing: Remind me, is this just waiting on me to take another pass or were there still some other changes you had in mind?

Remind me, is this just waiting on me to take another pass or were there still some other changes you had in mind?

There are still a few minor tweaks that I'd like to make, like using the #[nightly_only_test] and #[stable_only_test] attributes. I also need to go back to the docs and update the new configuration section with the link to the tracking issue.
There might be other little changes too, but it's been a little while so I need to review the PR myself to know for sure 😅

@calebcartwright Okay, now I think I'm ready for a re-review (assuming all the CI that's running right now passes successfully!). The PR is now definitely on the larger side, so no rush on this.
I added integration tests to tests/rustfmt/main.rs to cover almost all of the different test cases that I outlined in the original comment. One thing the tests currently fail to do is verify that files were either formatted or left alone. I'm not sure what the best way to do that would be, but maybe that's something we can look to address in the future. I made some updates to the existing test macro assert_that! so that I could also test rustfmt's exit code.
Definitely let me know if we still need to make changes here. The last thing that I want to make sure about is that the new configuration option has the most descriptive name we can give it. Do you think that abort_on_unrecognised_options does the job?

Apologies in advance for what may seem like me moving the goal posts, but I'm actually now thinking that we may want to perform the check elsewhere.
Main points driving my rationale:

minimize breaking changes to the API surface (yes we've got some flexibility, but better to avoid a change unless we really need it)
separation of concerns and ensuring the gate is enforced strictly within rustfmt itself (the lib)
ability to better interop error with emitters (not something we should do now, but making it easier to do so down the road)

Accordingly, what if we instead performed the "are we on stable, were there any unstable options, and if both then what's the expected behavior" logic check within format_input_inner similar to the version check:
https://github.com/rust-lang/rustfmt/blob/master/src/formatting.rs#L31-L40
I think a new ErrorKind variant that has a UnstableOptions field would work and be able to largely reuse most of the error message logic you have. I'd also like to have the continue/abort behavior be binary, with the continue path still printing out the warning regardless (i.e. I don't want to introduce a silent continue type of behavior)

The last thing that I want to make sure about is that the new configuration option has the most descriptive name we can give it. Do you think that abort_on_unrecognised_options does the job?

I always strive to avoid double negatives as those tend to be far too easy for folks to mix up or otherwise cause confusion, so would suggest we invert with something like "format with unusable, unstable options specified on stable" that's defaulted to true as oppose to current "abort" with default of false

Thoughts?

I like all your suggestions. I moved the exit early / warning logic to format_input_inner, and I added a new ErrorKind variant. I'm still going to think on the name for a little bit.
I  still need to:

[ ] Set the default value for the option to true
[ ] Setup a tracking issue and update the README

Let me know if there's anything else you'd like me to do on this that I'm missing.


Support for Server Side Rendering with Nuxt3

Vue-datepicker-next version: 1.0.2
Vue version: 3.2.37
Browser: Chrome
~Reproduction Link or Source Code~
Hey, thanks for creating this awesome library. I am trying to use this with Nuxt3 but it seems that it doesn't support SSR as the error mentions that it cannot find document. Am I correct in my understanding and if so, are there any plans to make it SSR friendly?
Thanks!

Create a plugin plugins/date-picker.client.js
import DatePicker from 'vue-datepicker-next'
import 'vue-datepicker-next/index.css'

export default defineNuxtPlugin(nuxtApp => {
    nuxtApp.vueApp.component('DatePicker', DatePicker)
})

Then simply add this to your body
<ClientOnly>
  <DatePicker v-model:value="myDate"></DatePicker>
</ClientOnly>

I couldn't get SSR with Vite to work. For some reason it then worked when changing the import to
import * as DatePicker from 'vue-datepicker-next/index.js';

Not sure if related. Hope this helps someone. 🤗

Create a plugin plugins/date-picker.client.js
import DatePicker from 'vue-datepicker-next'
import 'vue-datepicker-next/index.css'

export default defineNuxtPlugin(nuxtApp => {
    nuxtApp.vueApp.component('DatePicker', DatePicker)
})

Then simply add this to your body
<ClientOnly>
  <DatePicker v-model:value="myDate"></DatePicker>
</ClientOnly>

This works for me, except the component shows later than any component. Any idea to fix this?

nuxt.config.ts
export default defineNuxtConfig({
  devtools: { enabled: true },
  build: {
    transpile: ["vue-datepicker-next"],
  },
  plugins: [
    // your other plugins...
    { src: '~/plugins/vue-datepicker', mode: 'client' }, // client mode
  ],
})

plugins/vue-datepicker.ts
import DatePicker from 'vue-datepicker-next'
import 'vue-datepicker-next/index.css'

export default defineNuxtPlugin(nuxtApp => {
    nuxtApp.vueApp.component('DatePicker', DatePicker)
})

// components/datePickerTest.vue
<template>

    <client-only><date-picker v-model:value="time0"></date-picker></client-only>

  </template>

use nuxt3, typescript
nuxt.config.ts
export default defineNuxtConfig({
  devtools: { enabled: true },
  build: {
    transpile: ["vue-datepicker-next"],
  },
  plugins: [
    // your other plugins...
    { src: '~/plugins/vue-datepicker', mode: 'client' }, // client mode
  ],
})

plugins/vue-datepicker.ts
import DatePicker from 'vue-datepicker-next'
import 'vue-datepicker-next/index.css'

export default defineNuxtPlugin(nuxtApp => {
    nuxtApp.vueApp.component('DatePicker', DatePicker)
})

datePickerTest.vue
<template>

      <client-only><date-picker v-model:value="time0"></date-picker></client-only>

  </template>

Yeah, that's work fine if i use vue-datepicker-next directly, but what if it fails same way when other package (UI lib lt's say) uses it? Is there a workaround to make other lib use this package client-only style but not make this lib fully client-only


Added def function for converting Integer to Roman

Pull Request Template
What have you Changed(must)
 I implemented a def function to convert Integer to Roman. Please review it.

Write here what you have changed in codebase
Issue no.(must) - #808
Pr will be closed and marked as spam. If issue number not found or issue was assigned to someone else.
Marking as spam can block your account from HacktoberFest.
Self Check(Tick After Making pull Request)

[ ] This issue was assigned to me if not it will marked as spam.
[ ] My file is in proper folder
[ ] I am following clean code and Documentation.My code is well linted and I am using flake8 standard for python
[ ] I have added title and what program will do first in the file

README - How to Contribute

this is shown in my window. Please approve my workflow.

flake8 check failed. Flake8 is for clean code. Please read about the Flake8.
you can install it on your local machine and run it in your directory to find out the issues.


plan to filter content by movie type PG, PG13, R, X, etc. rating system

Congrats on the success of this project! I'm still going through all the code but thought I'd submit this... perhaps the start of this already exists?
As a node runner maybe I'd like to only process messages that are NOT R or X rated. A way to vote with my resources, i.e. I'm willing to run a node and help this network but I have my lines of what content I'll process.
And this goes further than just Movie Style ratings, but also politics. As a node runner I might also want to ban certain usernames. Or at least the first step in all this is a way to classify, in great detail, the type of content you are asking the network to process; so the network can give you a bid on that.
For example, I have a pallet of clouts with:
178) just normal left leaning user posts
 17) high profile left politic figures
  1) very high profile political figure

or:
210) normal right leaning user posts
 47) normal left leaning user posts
 15) R or X in nature

As a node runner I would want to broker exchanges of pallets with prices for all the various options out there. This is free speech in a decentralized world? There's a market for which node runners will cross what lines.  But just wanted to get thoughts from Clout team on how they are thinking about this...
Another way to say this: Trump could never be banned from the entire clout network, but the % of node owners willing to process him might fluctuate.

Hi, @andrewarrow aren't you able to implement some variation of content filtering in your own custom code in a node you run?

Ya, that is the beauty/idea of the platform. It is a base for you to build what you want. You want porn, make a porn site/app based on bitclout. You want church, make a church site/app.  It is up to you. If you want them to create the filters for you.. then you are back at twitter.

I personally am against XXX rated content and fully support you filtering that if you want, but not on the codebase. Do it in your own code. Once once can filter content in the codebase, others would want to filter other things, and it would become too centralized. There is already an ability to edit the code manually and add filtering and you can still run it as a node connected to BitClout's ecosystem (at least from my understanding).

Thanks for the replies! How fascinating to see which forks that do certain types of filtering will be. Yes I could I could fork core today and name it "CleanClout" but then a friend of mine could also fork core but name his "NotSoCleanClout" and his filter logic might be different.
I guess it will come down to money and principals and just general awareness among all the node operators what forks are available.
But sounds like the default that comes from bitclout/core main branch will be no filtering. To @Mentors4EDU 's point of "it would become too centralized" if it came with some opinionated filters.
And I guess once mining kicks in, to make the most money you'll want to not filter anything? By definition limiting the messages you will process limits your potential for profits?
Anyways I'm getting ahead of myself. Tonight I'm just trying to get https://github.com/andrewarrow/clout-cli going. I'm building a CLI to copy the features identity and frontend are doing now in TypeScript. Just trying to understand how to create a new account, generate a  PublicKeyBase58Check string etc, but do it all from golang not nodejs.

All nodes will process all transactions and then select which content they want to display to users


Features/cat info

I have moved the Pico files into the CSS folder
I have changed the API calls for cats so that I retrieve the breed info and an information URL
I have added a call to a dog breed information API to pull info about dog breeds
I have added a modal popup if the user clicks on the breed name which displays the information URL (cats), or the breed info and a wikipedia page (dogs)
I have started adding results to the ending page
I have created dummy data from the app page, saved to local storage for testing the ending page

looks good


TP removes unused configurable ds field descriptions

What does this PR (Pull Request) do?
When the delivery service (HTTP*, DNS*, Steering* and any_map) forms were enhance to have better field tooltips, these configurable field descriptions were abandoned but never removed. This PR removes them.

[x] This PR is not related to any Issue

Which Traffic Control components are affected by this PR?

Traffic Portal

What is the best way to verify this PR?
Start up TP and run the UI tests.

new UI tests would not be necessary for this. the existing tests will verify that functionality has not changed in the UI as a result of this change.
the configurability of ds field names/descriptions in TP was never documented so no need to remove any documentation.

The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/3773/
Test PASSed.


Update the osvb/impl container hosts because they were deleted from google cloud

Hi Stephan!
This PR updates the osvb/impl container hosts because they were deleted from google cloud.
Updated from:
gcr.io/hdl-containers/...
To:
ghcr.io/hdl/...
The CI was breaking down, as shown in the following image:

Cheers! :smile:

/cc @umarcor

Thank you so much for updating this! :+1:
I had this on my todo list for quite some time now, but i haven't had the time to look up the new URLs...


Add caching to reference data lookups for Teacher creation

Context
https://trello.com/c/JFFRWNZ2/169-add-caching-to-reference-data-lookups-in-put-trn-request-operation
Changes proposed in this pull request
Adds caching to reference data lookups performed when creating a teacher. This reference data is effectively static so we're not worried about having to expire cache entries here.
Checklist

[x] Attach to Trello card
[x] Rebased master
[x] Cleaned commit history
[x] Tested by running locally

 Add caching to reference data lookups in PUT TRN Request operation


ctrl K ctrl F breaks hbs variables

Issue Type: Bug
Create express with hbs view engine.
Create hbs variable (ie: {{blaw}} in any view file.
ctrl K ctrl F will break hbs file.

VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:13:36.375Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 x 3696)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
31.94GB (15.93GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

vscode-docker
Pet
0.4.0

LiveServer
rit
5.3.1

You are probably using the prettier formatter. add below to your setting
	"prettier.disableLanguages": [
		"vue",
		"handlebars"
	]

Unfortunately that's the built-in HTML formatter, which is using js-beautify. You can either open an issue for them, or disable HTML formatting with html.format.enable: false.

We use beautifyjs as the underlying HTML formatter. It would be great if you can file and issue directly against https://github.com/beautify-web/js-beautify

The reference utility makes no claims of supporting handlebars/hbs marking for html files.
They also state "existing owners have very limited time to work on this project currently".
So it looks like the error is visual studio using this utility for handlebars/.hbs files.
I can open a ticket for a feature request, but given the above note, it feels kind of pointless.
There appears to be a number of beautifiers for handlebar/hbs.
Maybe this ticket title needs to be changed to "should not use beutifyjs for .hbs .handlebars files, should use one of the beautifiers that target hbs/handlebar files".
Regards,
John Grabner

From: Martin Aeschlimann<EMAIL_ADDRESS>Sent: Thursday, January 3, 2019 8:07 AM
To: Microsoft/vscode
Cc: johngrabner; Author
Subject: Re: [Microsoft/vscode] ctrl K ctrl F breaks hbs variables (#64236)
We use beautifyjshttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjsbeautifier.org%2F&data=02|01||6b776b4f0f494bcc274108d6719583e6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636821284301188655&sdata=HrCM1Lc5bPs7nuIG6rafHTxV7R%2F6bOENiKyliekxhwg%3D&reserved=0 as the underlying HTML formatter. It would be great if you can file and issue directly against https://github.com/beautify-web/js-beautifyhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbeautify-web%2Fjs-beautify&data=02|01||6b776b4f0f494bcc274108d6719583e6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636821284301188655&sdata=ONfSH4ejC5B7ii7OWBi%2Bbe2TrliMMXtQpBmUF5h7A0E%3D&reserved=0
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fissues%2F64236%23issuecomment-451189566&data=02|01||6b776b4f0f494bcc274108d6719583e6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636821284301188655&sdata=tuEJeijAMb9YqELhcIrRxFNHW80mWT%2BgUzIy%2B2qnB7c%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH1DhRFZzy5rgoBQBTY7bZ4p2DTEYfzcks5u_iqqgaJpZM4Y-89g&data=02|01||6b776b4f0f494bcc274108d6719583e6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636821284301188655&sdata=WJAYiZvrX3P6iuO3iSSkS%2F4dRLtSraIBckKe%2Bwo9%2B3A%3D&reserved=0.


Update filter values

Is there any possibility to change filter values (on-fly)?
I want to make a request to server, when user click on filter icon and then shows filter panel accordinly to values we have got.
Can I do this without custom filter? I don't need custom filter becasue I just need to update list of values every time when I click on filter icon in the column header...
How I can realize this? What kind of realization can you advise me?
Thanks.

Please raise support requests on either stackoverflow or the free forum: https://ag-grid.com/forum/forumdisplay.php?fid=4
Github is for issues only please.

ok, sorry, I replaced post to forum
Could you answer on it, please?


RFC: Signals and Slots Hooks

Summary
This proposal is intended to introduce the concept of Signals and Slots used by Qt to React.
Signals and slots would be a natural, React-like way of enabling inter-component communication.
Simply passing messages between components shouldn't require passing callbacks that mutate
the parent's state or wrapping the Context API or a full-fledged state-management library like Redux.
It's backward compatible (signals can be connected even to old components).
Read the full RFC here.
Example
import React, { useSignal, useSlot, useState } from 'react';
import PropTypes from 'prop-types';

function TextInput () {
    const [ value, setValue ] = useState('');
    const emit = useSignal('updated');
    const onChange = (e) => {
        setValue(e.target.value);
        emit(e.target.value);
    };
    return <input value={value} onChange={onChange}
}

TextInput.signals = {
    updated: PropTypes.string
};

function Banner({ name }) {
    return
Hello, {name}!
;
}

Banner.propTypes = {
    name: PropTypes.string
};

function App () {
    const name = useSlot('updated');

    return (
        <>
            <Banner name={name} />
            <TextInput />
        </>
    );
}

Look like this could be implemented in a user-space with ease. Just one context, one useState and one useCallback to create connected component.

Look like this could be implemented in a user-space with ease. Just one context, one useState and one useCallback to create connected component.

Would you mind posting a code example of that, preferably something similar to what I have above?
You are right that it could be implemented in user-space, but this seems easier and more natural to use. Context requires creating a provider and exporting the context so that other components can use it. It involves a lot of extra code, and it can be difficult to determine what the code is doing just by looking at it. Almost anyone could understand the example above.

@Symbitic I think a recent RFC (and the user-land solutions mentioned in it) seem to be very suitable to solve this problem: https://github.com/reactjs/rfcs/pull/130
E.g. checkout https://github.com/pie6k/hooksy
It's not a one-to-one mapping to your proposal, but arguably a more natural way to achieve the same thing

I'm not sure I entirely follow what
const MyButton = Button;
const MyBanner = Banner;
connect(MyButton, 'clicked', MyBanner, 'message');

would do. Surely the first two lines merely alias the Button and Banner components to new names, and the connect call would still pass in the original (presumably hypothetically imported from another module) components?

@FireyFly I don't know enough about the internals of React to say for sure. That was just meant to be an example of connecting to specific instances of components. If you have any alternate syntaxes feel free to share them.
@everdimension I checked hooky and all the others listed in that RFC. Unfortunately, I don't think any of them are substitutes for this. All of them are are for sharing state, which is arguably something that falls outside the scope of React. Signals and Slots are for allowing components to communicate with each other without being binding them. The only state for each component should be its own internal state. Having state be managed outside your scope (or managing another components state) inherently leads to tighter coupling.
Signals and Slots is meant to solve the problem of inter-component communication, not cross-component state management. If you feel differently about any of this feel free to explain why.

That was just meant to be an example of connecting to specific instances of components.

It doesn't actually do that, because the reassignment still points to the same reference.

It doesn't actually do that, because the reassignment still points to the same reference.

I'll have to put some thought into that. For now, does it at least illustrate what I'm trying to do?

Loosely, yes, altho as mentioned upthread, this sounds like a glorified event emitter which probably better exists in userland.

Loosely, yes, altho as mentioned upthread, this sounds like a glorified event emitter which probably better exists in userland.

Events are a natural part of the DOM, and by extension React.
Signals and Slots is an implementation of the Observer pattern, without needing to implement the observer (the event emitter).
Lastly, useReducer was already implemented in user-space as Redux. Wasn't it turned into an official React Hook because it made using React easier? If the main question is 'does this add value by making React easier to use and easier to understand,' then I think the answer is yes.
My next syntax idea would be something like:
const buttonRef = useRef(null);
const bannerRef = useRef(null);
connect(buttonRef, 'clicked', bannerRef, 'message');
<Button ref={buttonRef} />
<Banner ref={bannerRef} />

I will update the text of the RFC soon.

Draft 2 has been added. Replaces the aliasing syntax with refs defined by useRef() for connecting components. Also updates the weaknesses section with several items discussed here.
Example above has been updated to reflect the latest changes.

Can’t this be implemented with a useState hook?
import { useState } from 'react'

function Button({ name, emit }) {
  const onClick = () => emit(`Hello, ${name}!`)

  return <button onClick={onClick}>{name}</button>
}

function Banner({ message }) {
  return
{message}

}

function App() {
  const [message, emit] = useState('')
  return (
    <>
      <MyBanner message={message} />
      <MyButton emit={emit} name="World" />
    </>
  )
}

TS version
import { useState } from 'react'

function Button({ name, emit }: { name: string, emit: (s: string) => void }) {
  const onClick = () => emit(`Hello, ${name}!`)

  return <button onClick={onClick}>{name}</button>
}

function Banner({ message }: { message: string }) {
  return
{message}

}

function App() {
  const [message, emit] = useState('')
  return (
    <>
      <MyBanner message={message} />
      <MyButton emit={emit} name="World" />
    </>
  )
}

@j-f1
For something simple like that, yes, but that isn't necessarily scalable for large numbers of components.
Plus, It's still 'passing a function to a component as a parameter,' which is exactly what I am trying to avoid. Whenever you pass functions to a React component as a param, it inherently couples the child to its parent, because the parent is defining the child's behavior. For example, if the parent forgets to pass the emit function to the Button component, then the child's behavior will be broken.
Signals and slots is meant to encourage separation of concerns.
Producers are concerned only with what they will produce, not who will consume them.
Consumers are only concerned with what they will consume, not where it comes from.
The parent simply connects a producer to a consumer.

I admit that plenty of people have found usable alternatives to this, but I'm not sure if they would be scalable enough to built an entire production-level application out of them.

This is a major update. Instead of parents acting as an invisible mediator between two children, parents now capture the value of a signal emitted by a child which they can then pass to any other child. No more refs or keeping track of individual component instances.
You can think of this as adding the observer pattern to React. But instead of notifying observers by calling one of their methods, they notify components of changes by using React component props, which automatically update whenever a value is updated.
Most users have likely already implemented something very similar to the observer pattern by using e.g.:
import React, { useSignal, useSlot, useState } from 'react';
import PropTypes from 'prop-types';

function TextInput ({ value, setValue }) {
    const onChange = (e) => {
        setValue(e.target.value);
    };
    return <input value={value} onChange={onChange}
}

TextInput.signals = {
    value: PropTypes.string,
    setValue: PropTypes.func
};

function Banner({ name }) {
    return
Hello, {name}!
;
}

Banner.propTypes = {
    name: PropTypes.string
};

function App () {
    const [ name, setName ] = useState('');

    return (
        <>
            <Banner name={name} />
            <TextInput value={name} setValue={setName} />
        </>
    );
}

Most users will almost certainly do something like this at some point. The top-level App component provides a method for modifying the state to TextInput and then passes the updated value to Banner. The problem is that App exposes its own internal state and then provides a callback to modify the state to another component. That means App is tightly coupled to TextInput (plus, modifying the internal state of one component from inside another is just generally a bad idea).
Compare this with the example listed at the top of the thread. useState() has been moved to TextInput, which means it no longer has a way of modifying the App's internal state.
Once again, this is something that can be done in user-space, but it doesn't fix the underlying problem. Each component should be able to isolate its own state from any other components.
Another extra benefit: once the code for this is added to the React internals, it could be used to implement Error Boundaries as a hook. The observer pattern would work well for capturing an exception and then passing it up the stack until it reaches a handler.

In the spirit of #182, I'll try to provide some quick thoughts rather than an exhaustive review.
One thing that definitely can't work out is using strings for identifiers. We've learned that lesson with the legacy context API and don't want to repeat that mistake. In a larger app, strings always clash, so two components that are sufficiently far away (or just nested deeply) will at some point think that update means two different things. This is why the modern Context API forces you to actually import the context. This "ties" components together explicitly.
A minor nitpick is the Component.something = ... configuration style. We've been getting rid of these (e.g. propTypes is out of fashion now), and would rather not add more. Though this is relatively minor compared to the "big questions" of the design.

Most users have likely already implemented something very similar to the observer pattern by using e.g. [...]

Yes, that's the canonical way to do this in React.

The problem is that App exposes its own internal state and then provides a callback to modify the state to another component. That means App is tightly coupled to TextInput (plus, modifying the internal state of one component from inside another is just generally a bad idea).

I don't agree with this assessment. From TextInput's point of view, it just receives a function that requests change. You could name its prop requestChange or onChange instead of setValue to really drive that point. TextInput does not actually know that setValue will touch App's state, so I don't think it's fair to say that App exposes internal state to it, or that it's a bad idea. This is idiomatic React. Note how App can still change its state shape, or even move that state further app, or add some logic like <TextInput onChange={handleChange}> and then handleChange may decide not to call setValue, or transform it before calling, etc. So App is fully in control of what exactly it exposes.
I agree there's still some question of just how much decoupling we want to convey through naming and patterns. One pattern we've wanted to encourage is putting a reducer's dispatch function on the context.  But it's up to the component that provides the dispatch context (in our case, App) to handle this message and interpret this. I don't think this is really different from what this RFC is suggesting. Your variant is more concise, and I agree some more concise way to do this "dispatch context" pattern would be nice. I'm just not sure that what you're suggesting really solves all these cases. It seems to be a subset, and currently it being based around global strings makes it untenable. If you change that, I can take another look and give more feedback.

@gaearon

We've been getting rid of these (e.g. propTypes is out of fashion now), and would rather not add more.

Somewhat tangential, but this is news to me. Is there an intention to deprecate propTypes and if so, replace it with what? We use propTypes extensively because we're not using TS/Flow and it's an extremely helpful tool, so I'm surprised to hear it's considered "out of fashion".

There’s no immediate plan or anything like this but we’ve been de-emphasising it over the years, and much of the usage in the community has been replaced by TS. At some point it’s possible that we’ll stop “checking” prop types in React and people who want to use them would add check(props, propTypes) calls to their components. We could make a codemod for that. The nice thing about this approach is that it’s not specific to components and you can use it anywhere. So if you’re into runtime type checking, you can do this explicitly. Anyway, that is tangential. It’s just that we try to avoid APIs that assign properties to functions.

@gaearon

It’s just that we try to avoid APIs that assign properties to functions.

This part is easy to avoid. The TextInput.signals thing was optional. I just added that as a sort of prop type for type checking. If Function.propTypes is no longer used/needed, then neither is this.

One thing that definitely can't work out is using strings for identifiers.

I'll definitely need to put some more thought into this. With Qt C++, you pass in a method name (connect(m_class, &MyClass::methodName)). Since the whole point here is that we are using functions instead of classes, that won't work.
If a signal is an event, then it doesn't need to travel all the way up the stack. It is only visible to the direct parent (i.e. App will be able to connect to TextInput, but ParentApp will not).

I don't agree with this assessment. From TextInput's point of view, it just receives a function that requests change.

Then let me try another way of wording it: I want App to be able to receive information from TextInput without TextInput needing to execute a function that was passed as a parameter.

Here's a more condensed example of what I'm trying to do:
import React, { useSignal, useSlot, useState } from 'react';

function TextInput () {
    const [ value, setValue ] = useState('');
    const emit = useSignal('updated');
    const onChange = (e) => {
        setValue(e.target.value);
        emit(e.target.value);
    };
    return <input value={value} onChange={onChange} />
}

function App () {
    const name = useSlot('updated');

    return (
        <>

Hello, {name}

            <TextInput />
        </>
    );
}

In this example, TextInput doesn't depend on anything. Not any props, not a function-as-a-parameter, not a Context. It just publishes a value that a parent may consume. To me, that is much more reusable.

Closed in favor of my newer RFC: #246


Solved Issue #68 [FEATURE] Tablet Mode for Teams Section [GSSoC'23]

Description
Feat: enable Tablet Mode for Teams Section
Related Issue(s)
Closes #68
Proposed Changes

Edited _app.js (temp fix for minimizing conflicts with other issues).
Created Developer.module.css.
Modified CSS for Tablet Mode.
Fixed layout bugs in Tablet Mode.
Edited CSS to ease transition to TailwindCSS.

Screenshots (if applicable)

Checklist

[X] I have tested the changes locally and they are working as expected.
[X] I have added any necessary documentation or updated existing documentation.
[X] I have reviewed the code changes to ensure they adhere to the project's coding standards.
[X] I have added appropriate labels to this pull request.

This is not an accurate design @vishnu9865. You will have to push a little harder, this is the first time we are developing a page for tablet so you will have to adjust minor details of components being used in every page as well

This is not an accurate design @vishnu9865. You will have to push a little harder, this is the first time we are developing a page for tablet so you will have to adjust minor details of components being used in every page as well

@kaustubhai Sir,
Sorry sir, I thought I should not tamper with navbar code as my PR may have conflicts with any other contributor working on Navbar alignment or any navbar related issue.
Is it okay for me to work on navbar ? If so I am very happy solve the issue in this PR.
Thank you for your time with this PR.
Regards,
Jeyavishnu S @vishnu9865

This is not an accurate design @vishnu9865. You will have to push a little harder, this is the first time we are developing a page for tablet so you will have to adjust minor details of components being used in every page as well

@kaustubhai Sir, Sorry sir, I thought I should not tamper with navbar code as my PR may have conflicts with any other contributor working on Navbar alignment or any navbar related issue. Is it okay for me to work on navbar ? If so I am very happy solve the issue in this PR. Thank you for your time with this PR. Regards, Jeyavishnu S @vishnu9865

Yeah yeah please go ahead. I think it was mentioned that in the issue itself that this is the first page that was being migrated to tablet mode. Kudos for thinking for conflicts but, you had a go-ahead already to work on that

Ok sir, working on it 🚀🚀🚀

@kaustubhai Sir,
I have made some changes to the Navbar code.
Please feel free to ask for any changes required and sorry for any inconveniences caused.
Regards,
Jeyavishnu @vishnu9865

Sharing few pointers with you, I think it will look better then:

Remove the Home link from navbar for tab and desktop
Decrease the Dashboard button size (Can remove the icon and decrease the font-size) only for tab
Make button-group right-aligned and vovoca to the left as it is in desktop

@kaustubhai Ok sir, working on it.

@kaustubhai Sir,
I made the following changes. 👍

In review @vishnu9865

In review @vishnu9865

@kaustubhai Sir, ??


docs(codebox): the options tab is now the default

Renamed "All Options" to "Usage"
Renamed "Snippet" to "Example"
Moved "Requirements" at the 2nd position
do not use display:none in the raw HTML code

Fix #966

will be live in a bit


What happen to sixteen columns?

Was sixteen columns removed? Or am I missing something. I don't see it in the css.

It's always been 12-col as far as I know. Perhaps there's a 16-col fork of it you're thinking of?

Skeleton v1.2 had sixteen columns.

Interesting, just downloaded 1.2 and did indeed have a 16-col grid. Not sure why it was removed then.

New skeleton is completely percentage based. Possible to make a 16 column grid fork of this.

@bezierer you can use an online grid generator http://gridpak.com/ to recalculate columns.. but in my case, i ended up coding my own using stylus.. https://github.com/rlynjb/bitc/blob/master/bitc.styl


Remove node

Hi there,
Is it even possible to remove node completely with this package?
I use a 3rd party wrapper around this raft package which sends this -
  c := raftpb.ConfChange{
        Type:    raftpb.ConfChangeRemoveNode,
        NodeID:  uint64(*node.NodeId),
      }

When I delete a node and then it's data directory, it's still present on the raft members list, raft leader doesn't trying to replicate data to it so I'm assuming the node was removed.
When I'm trying to join the same node to the cluster again it returns - node already joined under another ID
Thanks

@kotyara85 It's hard to read your request, could you add some details? How is the 3rd party wrapper structured, and what does it try to achieve?

When I delete a node and then it's data directory, it's still present on the raft members list

Where is this list? Is this raft's list (the please point at the structure/field definition containing this list)? Or is this the 3rd party's list?
As I understand, after a node is removed from raft, it's the application's responsibility to then remove the corresponding data, it's not reusable. If you want a node to rejoin, it has to have a different node ID (even if it's physically the same node). Otherwise, some replicas (who might have still not seen the old node ID removal) can be confused by seeing a node that reuses the ID but behaves differently compared to what would be expected from the old node.

hi @pavelkalinnikov
I'm using this package - https://github.com/shaj13/raft/blob/main/node.go#L366-L399

I call this method to removemember and it's being marked as removed in raft config
Removing data directory and trying reconnect node with the same address and ID
This error occurs - rpc error: code = Unknown desc = raft: member 2 removed, raft: node state not found

Thanks

This question should be addressed to the third-party package that you are using. https://github.com/shaj13/raft


Reconsider adding ByKeyUrl

Aleksey
Further to my PR and previous issue https://github.com/DevExpress/DevExtreme.AspNet.Data/pull/150...
Having a separate byKeyUrl would be useful. The case you gave as achieving this result actually does not work in the case which necessitated me implementing this function.
The most common case I have for this is to do with users. I have several methods that return a subset of the user base. For example OrderApprovalUsers which is a subset of Users returned by users/GetOrderApprovalUsers.
When an Order is raised, the current list of approved users is returned for the selectbox, a user is selected e.g. user id 99. Lets say later that user leaves the business, or their authority is revoked - they are no longer returned by the users/GetOrderApprovalUsers controller method. As a result, no call to users/GetOrderApprovalUsers with userid:99 will ever return a value.
This means whenever I display this record, the ApprovedBy field is blank - even though I have data to complete it.
If however a separate byKeyUrl such as I have implemented can be specified, then the selectbox can call users/GetUserById?UserId=99 without impacting any other functionality. By default, the ByKey method uses the LoadUrl anyway, so all that is required is an additional property ByKeyUrl that is only actually used if it is specified. It is a very small change with a very powerful additional functionality.
Would you please reconsider?

Hello
You're describing a common case when

For display, you need current collection + previous assignment
For edit, you need only the current collection

There can be different ways to achieve this. For example, by using two different data sources. However, I don't think that the following would be correct:

collection.ByKey(key) is not empty
collection.Where(i => Key(i) == key) is empty

I disagree. For display you only require previous assignment. If the previous assignment is not a member of the current collection, then it is no longer a valid selection, and the only reason it would be changed would be to make a valid selection - otherwise you would leave it as it is. Regardless, you describe this as a common problem, but provide no solution that works with the controls except to provide a heap of additional plumbing on the server to modify the datasource.
To support a separate byKeyUrl requires a change to 1 line of code. Compare this to having to provide additional datasources for every single time this happens (at least 30 times in my codebase) and it really isn't even close. That is why I have actually implemented it - I would prefer not to have to maintain a separate fork though.
The additional advantage is where I have collections that require significant computational power. The majority of calls to the datasource are simply getting the key, and this can be made trivial where required if I can use a separate byKeyUrl
This change is completely backwards compatible - I am not referring to the AllUrl in my original PR (for which your previous supplied workaround works well), just the ability to specify a separate byKeyURL which defaults to the loadURL if not specified.
Like you point out, there are other solutions which require a lot more code and a lot more effort, so what exactly would be the problem with doing this? It literally just requires to replace
loadUrl = options.loadUrl

with
loadUrl = options.byKeyUrl || options.loadUrl

and add byKeyUrl  to the typescript definition.

For display you only require previous assignment. If the previous assignment is not a member of the current collection, then it is no longer a valid selection, and the only reason it would be changed would be to make a valid selection - otherwise you would leave it as it is.

I see that this is how your app handles business rules. Another example that comes to mind is my Spotify profile page when I view it from a non-domestic location. The UI displays a dropdown list of two countries, and I am only allowed to save with the current location.
I think that I fully understand your arguments. Indeed, byKeyUrl might simplify integration with DevExtreme widgets for the specific scenario. The point regarding heavy collections is also valid. Though, I'm not sure whether all widgets can correctly handle a data source whose byKey returns an item that is not returned by load.
We can keep the ticket open for further research.

Thanks Aleksey
How would we go about researching / progressing the potential impact on other controls? Reason I ask is that it is important to my application, and now also teams I work with. At the moment they use the standard devex asp.net js library, but having come across exactly this issue we are going to probably have to implement my fork.
Now that we have managed to resolve the Dto issue using customaccessors, and the AllUrl suggestion from #150 works well, this is the only difference still remaining in that fork, and it would be really great to be able to return to the main repo.

How would we go about researching / progressing the potential impact on other controls?

As usual, we cannot promise whether / when the suggested idea will be implemented. If you find that a certain DevExpress widget doesn't work well with a key that is not present among items, submit a Support ticket.
Consider also this approach which doesn't require a fork:
var store = DevExpress.data.AspNet.createStore(...);

store._byKeyFunc = function(key) {
    return $.getJSON("@Url.Action("CustomAction", "ApiController")", { key: key });
}

store.byKey(123).then(function(obj) {
    debugger
});

Similarly, you can override _loadFunc, _totalCountFunc, _insertFunc, _updateFunc, _removeFunc.


PDF files generating during a session are not visible to collaborators.

Issue Type: Bug
Description: When using Live Share in VS Code to collaborate on a LaTeX document through the LaTeX Workshop extension, as a replacement to Overleaf, editing of text files works flawlessly, but collaborators cannot build or visualize the resulting PDF files.
Steps to reproduce:
1 - Install Live Share.
2 - Install LaTeX Workshop.
3 - Create a LaTeX project.
4 - Share the LaTeX project with a collaborator through Live Share.
5 - Alternatively:
5.1 - (Collaborator) Attempt to build the LaTeX project. Expected result - project builds and a PDF file is created. Actual result - project does not build and a VS Code error message pops up, saying "ENOENT: no such file or directory, open 'C:<main_latex_file>.tex'. This is not the correct path for the main LaTeX file of the project.
5.2 - (Session creator) Build the LaTeX project. PDF file is built, and opens is a new tab. PDF file is visible to collaborator in Explorer.
6 - (Collaborator) Attempt to open a PDF file created during the Live Share session. Expected result - PDF file opens in a new tab. Actual result - varies. a) Occasionally, a binary file opens in a new tab, but it is not displayed as a PDF. Sometimes, this new tab closes immediately, sometimes it remains open showing the binary contents of the PDF file. In either case the PDF file correctly opens as a new tab for the session creator in response to the collaborator's attempt to open it. Note that PDF files created by the collaborators themselves, independently of the Live Share session, do open in new tabs and are displayed correctly. b) On other occasions, but much less frequently, a new tab for the PDF opens, displaying all the widgets for PDF visualization, but the file is empty and an error message shows on below the widgets. The message says an error occurred, with an button to display more info. Clicking the button shows the error "Cannot fetch pdf file."
Extension version: 1.0.1891
VS Code version: Code 1.43.2 (0ba0ca52957102ca3527cf479571617f0de6ed50, 2020-03-24T07:38:38.248Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabled_readbackwebgl2: enabled_readback

Load (avg)
undefined

Memory (System)
15.93GB (5.58GB free)

Process Argv

Screen Reader
no

VM
0%

Thanks for opening this, @prsmendonca. Editing of the text files is supported, but this scenario is currently not unsupported. I'll mark this as a feature request.

I also have this problem

This will be resolved as part of our general support for binary files that is coming in the next Live Share release. Thanks!

Is it released ? It does not seem to work with the current version v1.0.5449.

Is this still not included ? It doesn't seem to be the case in v1.0.5803
On the other hand, I don't understand how the versions are handled, if I understand correctly the latest version on this repo is v1.0.765 ant it is from 2019. What is up with that ?

Is this released? I am still experiencing the same problem on macOS.

Still not working after 2 years, guys... Neither PDFs nor even JPGs.

Very useful feature that is missing, liveshare for latex not really functional in this manner.

Any open-source alternatives for markdown collaboration with real-time PDF preview on the sidebar? For pandoc + latex?


Avoid NULL pointer dereference.

[manual merge from #9059 to 1.1.0]
Fixes: #9043

So what is a procedure? Can I approve this PR and merge to 1.1.0 branch or not? (Sorry, I'm still unfamiliar with the procedures).

When someone with write access to the main repo is the author, then the usual procedure is for that person to merge.  This isn't a matter of policy, it's simply habits that have built up over time.  Formally speaking, nothing stops you from doing the merge if you want to, or even me...  however, it's likely that @paulidale wants to clean the branch out locally, so that might be a reason to leave it all to him.
We're also trying to pace ourselves, i.e. give the PR a grace period if someone else has a late opinion.  This is also a matter of habit more than anything else, and we're not always very good at the pacing thing, especially with this kind of small fixes.
Not sure if that gave you some answer, even thought not definitive...

I forgot to update before bringing the changes across, I've rebased.

I don't mind if someone else wants to merge this, but I'm also happy to do it.  As @levitte wrote, the author generally does (or first reviewer if the author doesn't have write permissions to the repository).  It isn't a hard and fast rule.

The only changes on the rebase are in the generated errors.

Merged to 1.1.0


Are you using a reverse proxy? It sounds like you've gotten it setup wrong

          Are you using a reverse proxy? It sounds like you've gotten it setup wrong

Originally posted by @AvarianKnight in https://github.com/AvarianKnight/pma-voice/issues/414#issuecomment-1550389204
    i think this is my issue but not sure what i did wrong ..

i added setr mumble_maxClientPerIP 150 to my server.cfg and still doing it

No I don't, you need to forward peoples IP's properly through your proxy, I don't remember how you're supposed to do so though


SegWit

Hey,
Is your branch SegWit ready ?
Regards.

No its not segwit ready i'm afraid, but it is work in progress.


Phase 3 Funding: Improving Compressed Image performance and Dask integration in io.fits.

In this PR we propose development effort to improve the state of compressed image support in astropy.io.fits and to implement initial support for reading FITS files into Dask arrays.
This proposal is in two parts:

Part one: Implement a tiled decompression/compression package to replace astropy's current use of cfitsio, to simplify the codebase and to open the door to substantial performance improvements.
Part two: Write an initial implementation of loading FITS ImageHDUs directly in to Dask arrays (both compressed and uncompressed images. [Note that writing from a Dask array is already implemented.]

Rendered Proposal

Because the estimated total of all the proposals is a bit higher than the amount available for allocation, we suggest that you (@Cadair ) provide a budget range - i.e., a "minimum for this project to be viable" and "maximum you could use effectively for this project".

@martindurant This is still a very early draft, but do you have any thoughts or recommendations on how you would go about adding dask support to reading FITS files in Astropy?

Yes, I will certainly have thoughts!
In the meantime, you might be interested in this codec which can read variable-length table data from FITS, i.e., the heap, which would be a necessary prerequisite to loading the same data in parallel via zarr rather than astropy.io.fits. (The "rice" compressor isn't implemented in numcodecs, though, or - as far as I can tell - anywhere at all)

Some thoughts:

it is very reasonable to want to de decompression in parallel with dask, if you can release the GIL and overheads are reasonable. When we are comparing runtimes of ~100ms, overheads will be important, but up to 4-8x speedup might still be possible with the threaded scheduler
more important is lazy/out-of-core or selective fetching of the data, both to cutdown on transfer bandwidth (I am thinking of remote loading) as well as improving CPU load
probably remote loading can only work with a python implementation, being able to pass a file-like rather than a real local file handle, so I am fully behind this
the structure of a single compressed image is perfectly aligned with a kerchunk representation, loading piecewise via a single decompression codec. So writing a references scanner for kerchunk would be be pretty simple if we can handle the compression codecs, and you would get remote/parallel/out-of-core fo free. This turns the problem on its head by using zarr as the IO layer instead of fits, but I would suggest astropy should have zarr as a supported data format backend. It would also be possible, but more work, to bundle a smart IO layer under fits.HDU (see, e.g., what fsspec.parquet does to preload the bytes ranges we know we will need, and then pass this prefilled file instance to the loader).

@martindurant Just hypothetically, what would astropy need to expose for kerchunk to be able to "just" call astropy to expose a zarr array? @astrofrog and I were discussing different approaches to this problem today, and I think we were discussing implementing something fundamentally similar to how kerchunk has implemented FITS support but providing an API more familiar to current astropy.io.fits users. Obviously, if we were to end up taking that path, it would be redundant for both of us to carry around similar implementations, so knowing how to combine them would be great.

I think having astropy be able to read from zarr should be very simple, and kerchunk/dask would come for free. Whether it would want to export the same hdu/header interface as fits is another matter. Should check up on what asdf does right now.

Did someone say asdf ? cc @WilliamJamieson

Please react to this comment to vote on this proposal (👍, 👎, or no reaction for +0).

Congratulations!  The community has expressed support for this FR, and the Finance Committee has determined it can be funded.  This FR has been approved for $22,500, to be funded from the NASA grant.
@aaryapatil  is the Finance Committee member who will be supporting this project.  They will update this PR with the amount and then merge it, as well as being in contact with you to set up any necessary agreements and relevant Open Collective financial arrangements. They will also open a new issue where progress on this project can be discussed.

Why is this not given the full amount, while proposals with less support got the full request?

It is disappointing that the second half hasn't been funded (as that's the "flashy" part), but the first half is still required ground work, for both the second half of this proposal and for kerchunk to support tile compression etc.

@Cadair - I think this was a mis-understanding of the proposa amountl!  That is, I think the intent was to fund this whole proposal, not just the first part, and it was mis-understood as the 150 hours being the requirement for both parts. Will confirm that to be sure but my recollection is that we intended to fully fund this proposal.

Ok @eteq that sounds great. (There's a non-zero chance we find ourselves with less time anyway :see_no_evil: )

@aaryapatil - we have now completed the first bullet point in part 1 of the proposal which was to remove (as much as possible) CFITSIO from astropy:

https://github.com/astropy/astropy/pull/1425
https://github.com/astropy/astropy/pull/14252

These have both been merged (in addition to simplifying/removing a lot of FITS-related code, this works also speeds up compilation of the core package by 40% or so, so it has had benefits beyond just FITS).
We ended up using 138h for this work (invoiced today) instead of the original 100h we budgeted, so we now only have 12h left for the remainder of part 1. We are wondering if the finance committee would be happy to approve the additional 100h of funding we originally requested, as this would allow us to complete part 1 and also do a big fraction of part 2? (see https://github.com/astropy/astropy-project/pull/275#issuecomment-1281315500 for more details)

Are you sure you mean https://github.com/astropy/astropy/pull/1425 ? That was merged in 2013... Probably a typo of the PR number?

Oops deleted a character by mistake when reformatting my comment 😅 - fixed now

This looks great. Thanks, @astrofrog! Could you please post your update on the issue (#316) instead of on the PR. We aim to use the issue for keeping track of the progress. We will also get back to you about the the additional 100h of funding (hopefully next week).


C++ port

This port should resolve all the issues with the previous C version of the patcher.
It would be nice if someone could test it for me, since I don't own a Wii console. I attached a compiled copy of my fork here.
Edit: I fixed a lot of stuff, and here's a working version of the port.

Background: The current patcher is not compatible with CF.
This PR should fix it, along with the C++ port.

This patcher's not very happy:
image

The patcher seems to error out with error code: 1 on my Wii - a nice blob of what I presume is the connection is also shown. (If you have a debug build of any kind that logs to a file, I can run it)

Not sure how are you getting that because I just get
Data sent! Awaiting response... Incomplete data
Feel free to send a developer the following content:
!DOCTYPE```

I suppose the data receiving doesn't work, I will fix that asap

I fixed the receiving code for the patcher, but I removed the broken parser. This means that it'll say that there's Incomplete data, but it will still print the response from the server, which is what I'd really like to see in order to verify that the receiving code works for other users too. Here's the release.

Currently, when running on my (already patched) Wii, I get thee error cd 610 back:
POST /cgi-bin/patcher.cgi HTTP/1.1
Host: mtw.rc24.xyz
User-Agent: Nintendo Wii

mlid=w7720650706766587HTTP/1.1 200 OK
Date: Sat, 29 Jun 2019 23:54:33 GMT
Server: Apache/2.4.25 (Debian)
Content-Length: 36
Content-Type: text/plain; charset=utf-8

cd:610
msg:Invalid Wii Friend Code.

I can also test on an unpatched Wii at some point, presuming I can dig one out of my room.

If the friend code is supposed to be valid, I have no idea why it actually returns cd´ as 610`.

I found the issue!
You're not sending the Header Content-Type: application/x-www-form-urlencoded
Send that, and the server will correctly respond duplicate or not

Also, @Apfel you said that this would fix CF support, but yet AFAICT this still connects over HTTP: is that just while we're trying to debug the actual patcher working? c:

I disabled HTTPS specifically because the patcher did not like it.

Ah, I see. That's fine c:
Lmk when a copy with the correct header exists, and I'll try it out

I just checked what the Wii actually sends to the server, and I found this:
2019/06/30 02:30:51 Server is online.
2019/06/30 02:31:23 New Request!
Body: <- this is actually empty
Host: mtw.rc24.xyz
Method: POST
Local Address: <IP_ADDRESS>:56998 <- yeah I sent it to my computer, not to a server
User-Agent - [Nintendo Wii]
Content-Type - [application/x-www-form-urlencoded]

The body, which is supposed to contain the Mail ID as mlid, isn't there.
Also, this is the code for the server that I used for my private debug build
package main

import (
	"bufio"
	"fmt"
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/cgi-bin/patcher.cgi", func(w http.ResponseWriter, r *http.Request) {
		var d []byte
		if _, err := bufio.NewReader(r.Body).Read(d); err != nil {
			log.Fatalf("an error occurred! oh noes: %s", err.Error())
		}

		log.Println("New Request!")
		fmt.Printf("Body: %s\nHost: %s\nMethod: %s\nAddress: %s\n", string(d), r.Host, r.Method, r.RemoteAddr)

		for k, v := range r.Header {
			fmt.Printf("%s - %s\n", k, v)
		}

		fmt.Fprintf(w, "here's the response, please work\r\n")
	})

	log.Println("Server is online.")
	log.Fatal(http.ListenAndServe(":80", nil))
}

Maybe that was why we were getting CF 400 sometimes?

I have no idea, but that may be the reason - the formatting is fine, the request should work, but it just doesn't do what it's supposed to.

I see mlid=w[WIIID] when sent in the TCP stream. Maybe just try adding that header and change nothing about the body, and I'll check it's response?

Here you go.

Odd, that didnt seem to fix it (I mean I wasn't completely sure it would have anyways tbh)
Maybe the way the HTTP request is built is different bc C++? I wouldn't be personally sure, tbh.

The request has been fixed, Content-Length was missing. kill me
I will implement the parser now.

Branch was deleted to I'm closing this. Did not work anyways.


feat(workers): allow enabling logpush on worker uploads

This allows cloudflare-go users to turn on/off logpush support for Cloudflare Workers.
The analogous functionality in Wrangler can be found here: https://github.com/cloudflare/wrangler2/blob/7169142171b1c9b4ff2f19b8b46871932ef7d10a/packages/wrangler/src/create-worker-upload-form.ts#L294
Description
This adds a new option to CreateWorkerParams that allows control over the logpush setting. Note its a nullable bool: the 3 states are true - on / false - off / nil - unchanged. Again, this is analogous to wrangler with its boolean | undefined type.
Has your change been tested?
A new test was created to test this.
Screenshots (if appropriate):
Types of changes
What sort of change does your code introduce/modify?

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] This change is using publicly documented (api.cloudflare.com or developers.cloudflare.com) and stable APIs.

Re: My code follows the code style of this project. - it looks like there are a number of lint errors present, but none that this change set has introduced
cloudflare-go on  nathan/feat/workers-logpush via 🐹 v1.19.4
❯ golangci-lint --new-from-rev=HEAD~1 run ./..

Codecov Report

Merging #1160 (688a493) into master (6153c1e) will decrease coverage by 0.10%.
The diff coverage is 51.65%.

@@            Coverage Diff             @@
##           master    #1160      +/-   ##
==========================================
- Coverage   49.40%   49.30%   -0.11%
==========================================
  Files         127      128       +1
  Lines       12290    12399     +109
==========================================
+ Hits         6072     6113      +41
- Misses       4840     4885      +45
- Partials     1378     1401      +23

Impacted Files
Coverage Δ

utils.go
72.72% <ø> (ø)

mtls_certificates.go
26.59% <26.59%> (ø)

dns.go
68.69% <92.45%> (+4.97%)
:arrow_up:

workers.go
57.62% <100.00%> (+0.48%)
:arrow_up:

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


Why can't I have std::vector<json&> testList?

This works.
#include "json.h"
#include <vector>
using json = nlohmann::json;

int main()
{
  std::vector<json> testList;
}

This also works.
#include "json.h"
#include <vector>
using json = nlohmann::json;

int main()
{
  std::vector<json*> testList;
}

This doesn't. Gives compile error. Why?
#include "json.h"
#include <vector>
using json = nlohmann::json;

int main()
{
  std::vector<json&> testList;
}

This is unrelated to the library: https://stackoverflow.com/questions/8200701/vectors-of-references-to-objects


[#4811] improvement(CI): optimize CI jobs trigger conditions

What changes were proposed in this pull request?

optimize CI jobs trigger conditions to remove unnecessary jobs
reduce job number of FlinkIT and SparkIT on PR
fix skipUTs does not work

Why are the changes needed?
Fix: #4811
Does this PR introduce any user-facing change?
no
How was this patch tested?
CI passed

This PR is based on #4628

@diqiu50 @FANNG1 @yuqi1129 @xunliu can you please help to review your parts again?
Generally, LGTM, waiting for your check again.

LGTM

Any more comments here @yuqi1129 ?

Any more comments here @yuqi1129 ?

I have no further comments on the matter.


SUP: Attributes should be chained before defining the constraint relation

what does this exception mean?

I am not sure if it appropriate to replay to the closed issues, but I saw how people confuse with and width, and that mistake usually leads to such kind of problem. I have done it several times as well.
Simple example will definitely lead to such a problem:
[imageView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.right.equalTo(self.view.mas_right).width.offset(-10);
        make.bottom.equalTo(self.view.mas_bottom).width.offset(-10);
}];

After replacing 'width' with 'with' the problem is solved.

slabko  is right!    I  had make this mistake too!

god,i had make this mistake too ~~~

I want to vote slabko just like in Stack Overflow. lol

@slabko made the same mistake.

width,with
made the same mistake

@mjzjohn  +1 mistake!

@mjzjohn Same here!

@mjzjohn +1

@slabko +1 thanks！

oh width... wow.

+1

I also look width as with.....

Build view
_menuList = [DropListMenu new];
[_menuContainer addSubview:_menuList];
[_menuList mas_makeConstraints:^(MASConstraintMaker *make){
    make.width.equalTo(_menuContainer.width);
    make.height.equalTo(_menuContainer.height);
    _menuListTopConstraint = make.top.equalTo(_menuContainer.top);
}];

start animation
_menuListTopConstraint.top.equalTo(_menuContainer.bottom);

[UIView animateWithDuration:2 animations:^{
    [_menuList layoutIfNeeded];
}];

Please point it out for me, great thanks!

I don't get you question
At 2015-12-04 15:17:33, "Will Han"<EMAIL_ADDRESS>wrote:
Build view
_menuList = [DropListMenu new];
[_menuContainer addSubview:_menuList];
[_menuList mas_makeConstraints:^(MASConstraintMaker *make){
make.width.equalTo(_menuContainer.width);
make.height.equalTo(_menuContainer.height);
_menuListTopConstraint = make.top.equalTo(_menuContainer.top);
}];
start animation
_menuListTopConstraint.top.equalTo(_menuContainer.bottom);
[UIView animateWithDuration:2 animations:^{
[_menuList layoutIfNeeded];
}];
Please point it out for me, great thanks!
—
Reply to this email directly or view it on GitHub.

@iRory forget it, I just build a wrong animation operation with updating MASConstraint object directly. Problem solved.

@slabko  +1 thanks!!

I did this too,

thanks

@slabko thanks)

thanks

wrong
[lblName mas_makeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(imgView.mas_top);
make.leading.equalTo(imgView).trailing.mas_offset(8);
#}];
right
[lblName mas_makeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(imgView.mas_top);
make.leading.equalTo(imgView.mas_trailing).mas_offset(8);
}];

@slabko +1 thanks!!


conflict with bootstrap

Bug display when using material 2 radio because of conflicts with bootstrap, isn't theire a way to make material2 play well with bootstrap so that we can take benifit from the power of both

Closing this issue as it does not follow the issue template. Please file a new issue that follows the template, which gives the team the information needed to investigate.


EMI keybinds activate even when creative search is active

When in the creative inventory search menu (the compass in top right), EMI keybinds are still active, so if you're searching for something and you type "r" or "u", and you happen to be hovering over an item, you'll be thrown out of the search and the recipe view opens up.

This is a good note, I typically play in survival with EMI cheat mode, I'll fix this up.


Window Name in MacOS Menu-bar defaults to "MainWindow"

The name in the Menubar is "Main Window" rather than "Password Generator"

Resolves #7

resolved by #7


Support for additional my.cnf conf file ?

Is there support to specify an additional my.cnf file that is used to customized/override the default one?
I've tried with:
docker run --name mariadb-native -v /home/ubuntu/custom:/etc/mysql/conf.d ...
where inside custom/custom-file.cnf there is:
[mysqld]
innodb_buffer_pool_size=64M

Is this supported ?

This is currently not supported as /etc/mysql/my.cnf in Alpine MariaDB package does not contain !includedir /etc/mysql/conf.d/.
I'll fix it in a few minutes.


Stop when Wayland library has a fatal error

Currently, if one abruptly disconnects their Wayland connection socket (for example, by killing the compositor but not the demo program), I observe example programs getting stuck in the following lines as part of an infinite loop.
while (wl_display_prepare_read(display) != 0)
	wl_display_dispatch_pending(display);

After the socket is disconnected, libwayland will start returning -1 to all subsequent calls of functions that can return an error (like wl_display_dispatch_pending(), but not wl_display_prepare_read()), and silently do nothing when functions are called. As a result, it should be safe to delay checking for error and breaking out of the main loop until the final wl_display_dispatch_pending() call. (Eagerly checking for errors is possible but would make the code rather more complicated, as wl_display_flush() can have transient/EAGAIN failures.)
(The current code was added in commit https://github.com/SaschaWillems/Vulkan/commit/b69f87d5c3d29196d3380c5b14635a2cb57ba9d1, which likely used the function call pattern recommended by the Wayland documentation (see wl_display_prepare_read_queue()); however, the example given there does not properly check for errors.)

Thanks for your PR. Very much appreciated!


merge from template-node-app

package.json

chore(deps): add ^22.0.10 remove ^22.0.9 (devDependencies.semantic-release)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
54

Relevant Lines:
56

💛  - Coveralls


Network support for Iridium SBD?

Hello, this looks like a very interesting project. Are there any plans to support Iridium SBD networking? Thanks

@dmzmk @tbaums be great to get your thoughts? Thanks

Hey @Boes-man - Appreciate the question! We don't have Iridium SBD as a networking option on our road map...yet!
Want to drop me a quick email to set up a time to discuss your use case? michael[at]mycelial[dot]com, or @tbaums in our  community Discord!


Updated CodeEdit project file icon

Is your feature request related to a problem? Please describe.
New CodeEdit file icon

Like xcode's project file icon
An updated project file icon

Please read https://github.com/CodeEditApp/CodeEdit/pull/666#issuecomment-1163206791
Duplicate of https://github.com/CodeEditApp/CodeEdit/pull/666, https://github.com/CodeEditApp/CodeEdit/pull/665


Prettify Dialogs

Prettify Dialogs, Disable Accessing Mutator UI in Flyout

This change is

When will this get merged?

Can you rebase and fix the merge conflict with blocklylib-core/src/main/res/layout/blockly_variable_name_dialog.xml?

Rebased!

While GitHub is confused, this looks good. GitHub is not recognizing the commits as part of other PRs. Not sure why that is, because the hashes are identical. However, pulling this in via the command line showed the changes are exactly what would be expected:
 * branch              prettify-dialogs -> FETCH_HEAD
Auto-merging blocklylib-vertical/src/main/java/com/google/blockly/android/ui/vertical/VerticalBlockViewFactory.java
Merge made by the 'recursive' strategy.
 .../src/main/java/com/google/blockly/android/ui/WorkspaceView.java          |  4 ++++
 .../blockly/android/ui/mutator/ProcedureDefinitionMutatorFragment.java      |  8 ++++---
 blocklylib-core/src/main/res/drawable/ic_add_black_24dp.xml                 |  9 ++++++++
 blocklylib-core/src/main/res/drawable/ic_close_black_24dp.xml               |  9 ++++++++
 blocklylib-core/src/main/res/layout/blockly_variable_name_dialog.xml        |  8 +++++--
 blocklylib-core/src/main/res/layout/if_else_mutator_dialog.xml              | 42 ++++++++++++++++++++++++-------------
 blocklylib-core/src/main/res/layout/name_variable_view.xml                  | 19 +++++++----------
 blocklylib-core/src/main/res/layout/procedure_definition_mutator_add.xml    | 16 +++++++-------
 .../src/main/res/layout/procedure_definition_mutator_argument.xml           | 31 +++++++++++++--------------
 blocklylib-core/src/main/res/layout/procedure_definition_mutator_dialog.xml |  9 ++++----
 .../com/google/blockly/android/ui/vertical/VerticalBlockViewFactory.java    |  6 +++++-
 11 files changed, 102 insertions(+), 59 deletions(-)


Spec grammars for IS things

Fixes #1611, #1612, #1613
Builds on #1636

for auto closing:
Fixes #1611
Fixes #1612
Fixes #1613