Help implementing multi qr code scan in stepper flutter

Hello ,
im building a flutter application and i want to scan 2 qr codes in a stepper widget in 2 steps
first one is to check the qr code on the voucher
and the second is to check the qr code on the vehicle
this is an example of the desired app :

also when i took the screenshot the camera stopped i don't know why xD,
this is my widget tree :
 Step(         isActive: _currentStep >= 1,         state: _currentStep >= 1 ? StepState.complete : StepState.disabled,         title: Text("Scan Qr code of the Voucher"),         content: SizedBox(           height: MediaQuery.of(context).size.height * 0.5,           child: Column(             children: [               Expanded(                 flex: 5,                 child: MobileScanner(                   // fit: BoxFit.contain,                   controller: controller,                   onDetect: (capture) {                     _onDetectQRDriver(capture);                   },                 ),               ),             ],           ),         ),       ),       Step(         isActive: _currentStep >= 2,         state: _currentStep >= 2 ? StepState.complete : StepState.disabled,         title: Text("Scan Qr code of the Truck"),         content: SizedBox(           height: MediaQuery.of(context).size.height * 0.5,           child: Column(             children: [               Expanded(                 flex: 5,                 child: MobileScanner(                   controller: controller1,                   onDetect: (capture) {                         _onDetectQRTruck(capture);                   },                 ),               ),             ],           ),         ),       ),
  the problem is that when scanning in the first step the on detect function is being called in both widgets so I'm firing 2 functions when the first qr code is scanned . I've tried to implement 2 controller for each qr scanner widget but didn't work,
  can someone please help and guide me on how to implement such flow (1-Scan first qr -> do some verification then proceed to next step (next qr code) and also do some verification....)
  regards

Same issue I am facing. Multiple qr not working.

Same issue I am facing. Multiple qr not working.

I'm thinking of adding a button on each step instead of the qr code widget directly
So each button will display a popup that will now contain the qr code widget
So we can easily manage the life cycle of it
What do you think?

I am using QR code in different pages but still same issues. Did you get any chance to resolve the issues?

Visibility detector + camera.dispose() each time not visible and then create a new controller if visible.


Create: 199-Binary Tree Right Side View -- SWIFT

File(s) Modified: 199-Binary-Tree-Right-Side-View.swift
Language(s) Used: Swift
Submission URL: https://leetcode.com/submissions/detail/787672275/

Thanks, @nprepaci!


Scrub more references to original repo name

This change is

+@EricCousineau-TRI for review.

Would help if I could spell...


column reference "name" is ambiguous

Hi,
I'm running into an issue with a combination of query and where clauses on a model. I'm running on PostgreSQL database.
The following code is dynamically built depending on the API request:
Brand.query((qb) => {
          qb.innerJoin('partners as p', function() {
            this.on('brands.partner_id', '=', 'p.id')
          });

          qb.where('p.name', 'ILIKE', '%partnername%');
        })
        .where('name','=','brandname')
        .fetch();

results in:
error: select "brands".* from "brands" inner join "partners" as "p" on "brands"."partner_id" = "p"."id" where "p"."name" ILIKE $1 and "name" ILIKE $2 order by "brands"."id" ASC limit $3 - column reference "name" is ambiguous

Again, the where clause is built dynamically from the API request. Is there any way to either prefix the where property with the tablename or to add an alias for the Brand model's properties?

Just add the table name as prefix .where('brands.name', 'brandname')

How can I get the tablename from a model? Its dynamic and we reuse the same crud api logic for models that dont require a specific implementation

Maybe Brand.prototype.tableName, or directly within a model instance model.tableName.
Is that what are you looking for ?

I have been using plugin that creates a static method field.
module.exports = function (bookshelf, options) {
  bookshelf.Model = bookshelf.Model.extend({}, {
    field: function (fieldName) {
      return this.prototype.tableName + '.' + fieldName;
    }
  });
};

Then it can be used like Model.field('someFieldName'). Eg.
Author.query(function (qb) {
  qb.where(Book.field('id'), 2); // WHERE books.id = 2
}).fetch()
// . . .

Closing this since there are several proposed solutions and the user never responded back.


a question in deepinsar.py

Excuse me，In line 134 of the program, should "clean_real" and "real" be replaced with "clean_imag" and "imag" respectively?

Hi @git97shunxin , I really appreciate your head up. The bug has been fixed.
Thank you!

Hi @git97shunxin , I really appreciate your head up. The bug has been fixed.
Thank you!

Hi,is there still a problem in the loss function?The calculation method in the loss function does not seem to match the formula(9) in the paper.I would appreciate it if you could check this question.

Hi @git97shunxin , I really appreciate your head up. The bug has been fixed.
Thank you!

Hi,is there still a problem in the loss function?The calculation method in the loss function does not seem to match the formula(9) in the paper.I would appreciate it if you could check this question.

Hi @git97shunxin ,
self.ae_r = self.batch_noisy_r[slice_index] - self.build_ae(
                self.features, is_train=True, reuse=reuse, name="dae_r", depth=self.config.fe_depth, ef_dim=self.config.fe_dim)
self.ae_i = self.batch_noisy_i[slice_index] - self.build_ae(
                self.features, is_train=True, reuse=reuse, name="dae_i", depth=self.config.fe_depth, ef_dim=self.config.fe_dim)

self.ae_loss_r = (1 / 2.0) * tf.reduce_mean(tf.reduce_mean(tf.squared_difference(self.ae_r, self.batch_clean_r[slice_index]), axis=[1, 2, 3]))
self.ae_loss_i = (1 / 2.0) * tf.reduce_mean(tf.reduce_mean(tf.squared_difference(self.ae_i, self.batch_clean_i[slice_index]), axis=[1, 2, 3]))

self.batch_noisy_r : noisy real channel, self.batch_noisy_i: noisy imag channel
sef.build_ae(...)'s outputs are estimated residuals for both channels.
The loss of each channel is calculated as L2 of ((noisy - est_resdiual), clean) for each channel.

Hi @git97shunxin ,
self.ae_r = self.batch_noisy_r[slice_index] - self.build_ae(
                self.features, is_train=True, reuse=reuse, name="dae_r", depth=self.config.fe_depth, ef_dim=self.config.fe_dim)
self.ae_i = self.batch_noisy_i[slice_index] - self.build_ae(
                self.features, is_train=True, reuse=reuse, name="dae_i", depth=self.config.fe_depth, ef_dim=self.config.fe_dim)

self.ae_loss_r = (1 / 2.0) * tf.reduce_mean(tf.reduce_mean(tf.squared_difference(self.ae_r, self.batch_clean_r[slice_index]), axis=[1, 2, 3]))
self.ae_loss_i = (1 / 2.0) * tf.reduce_mean(tf.reduce_mean(tf.squared_difference(self.ae_i, self.batch_clean_i[slice_index]), axis=[1, 2, 3]))

self.batch_noisy_r : noisy real channel, self.batch_noisy_i: noisy imag channel
sef.build_ae(...)'s outputs are estimated residuals for both channels.
The loss of each channel is calculated as L2 of ((noisy - est_resdiual), clean) for each channel.


command overhaul: 3 commands!

Hopefully, the last cleanup in pursuit of simplest path (before we release stuff!)
goals:

intuitive as possible (little jargon)
zero steps (no "run this before that")
auto-completion friendly (avoid commands that share same first character)

end state:

getenvoy versions (lists installed versions, -a includes remote ones not yet installed)
getenvoy use <version> (assign current version, installing as necessary)
getenvoy run -c envoy.yaml (run current version, installing as necessary)
current version is $PWD/.envoy-version or $ENVOY_HOME/version, which defaults to envoy-versions.json/latestVersion

current state (still not released):

run <version> -c envoy.yaml (run installing on demand as necessary)
versions (lists all versions)
install <version> (install if not already)
installed (lists all installed versions)
current version requires looking at the versions list

action 1: remove <version> from run, and read $ENVOY_VERSION $PWD/.envoy-version or $ENVOY_HOME/version

simplifies run syntax and the need to know what version you'd want
removes all questions about args to envoy: everything after run is interpreted by envoy
on first run $ENVOY_HOME/version is populated from envoy-versions.json/latestVersion

action 2: repurpose install -> use <version>

if we introduce a command to assign a version, there's a chance it isn't there, ends up the same as install
rename install to use, and upon use <version> install it as necessary
new change is to update $PWD/.envoy-version or $ENVOY_HOME/version if present

action 3: don't make a flag to write .envoy-version

getenvoy use 1.18.3 --local is only 1 more char than echo 1.18.3 > .envoy-version
by waiting to define a flag, we don't need to choose between bad jargon choices ex "local" or "cwd"
by waiting, we can get more input from end users

action 4: fold installed into versions -a/--all

getenvoy install collides on auto-complete with getenvoy installed which is annoying
getenvoy installed output is different than getenvoy versions mainly because we didn't have release date locally
during install, we can persist the "releaseDate" field into the $ENVOY_HOME/versions/$version directory create date
at that point getenvoy versions shows the installed ones and getenvoy versions -a shows all including remote, both knowing the release date

removes all questions about args to envoy: everything after run is interpreted by envoy

This is gold, I faced similar complexities when it comes to use protoc and abstractions like buf on top of it. You never know what options are interpreted by whom, ending up in a nightmare.

action 3: don't make a flag to write .envoy-version

+1, let's don't rush on this. I know people usually don't like PHP but for example composer only has --global flag, everything else is local. I guess on lack of local you default to global.

action 1: https://github.com/tetratelabs/getenvoy/pull/251

action 4: https://github.com/tetratelabs/getenvoy/pull/252

https://github.com/tetratelabs/getenvoy/pull/253 finishes this


Fix "Report a Bug" footer to point to github (Closes: #3485)

Thanks Daniel - we've already addressed this in the bs5 branch, which is what we currently expect to release next (after merging to main). See https://github.com/ietf-tools/datatracker/pull/3625

(I made and deleted a bogus comment due to not reading the context closely enough. Apologies for the noise).


Running the same workflows back to back (Synchronization)

Hi,
In my use case we'll be running workflows back to back and I'm concerned about some synchronization edge cases. Say I have workflow FOO with tasks BAR and BAZ (retryCount = 0) which is most of the time run at an interval of 5 minutes but for some reason ended up running at a much smaller interval for 2 or 3 intervals. To mock this edge case I'll post to /workflow once (that's FOO1), wait 30 secs, and post again (and this will be FOO2). So now I'm at a point where FOO1 and FOO2 are in the running state.

Is it guaranteed that BAR1 will be scheduled before BAR2?

Now BAR1 and BAR2 are both completed. Let's say for the sake of the edge case, BAR2 completed before BAR1, because I can have two replicas of BAR task runner and BAR2 got the better one (less busy k8s node, etc...)

Is it guaranteed that BAZ1 will be scheduled before BAZ2?

Thanks to everyone in advance!

Is it guaranteed that BAR1 will be scheduled before BAR2?

In this scenario, it is guaranteed that BAR1 will be scheduled before BAR2. Currently, the request to start the workflow will schedule the first task in the workflow (BAR1 in this case) before returning with a response.

Is it guaranteed that BAZ1 will be scheduled before BAZ2?

If the worker executing BAR1 completes processing and updates the status of BAR1 as COMPLETED before the worker executing BAR2, then it is guaranteed that BAZ1 will be scheduled before BAZ2.

I see, thank you for your response!


Using [@click] feature

The @click feature allows text to be clickable, and run a function when clicked, so something like [@click 'func_name(args)'] Clickable Text [/], WTPython could use this feature for the sidebar with the other answers, instead of key binds to go to the other questions. This would make the UI/UX much nicer to work with.

If possible, this should also apply to the answer headers in the main view. Link to the specific answer rather than just the question. Though they keystroke will probably have to be just the question page.


Added restart: unless-stopped to the docker-compose.yml

In order to start after server reboot. :)

@HristoKolev thanks for the contribution!
I am not certain this would be a sensible default. Personally, I wouldn't want random Compose stacks to restart on my machine without me knowing. If I do want to enable it, I add it to my own local copy or fork, without forcing all users to adopt my own preferences.
@deviantony opinions on that one?

Well, in my opinion, when I docker-compose up -d something I expect it to stay up until I say so.
Maybe that's just me. :)

I didn't realize how famous this repo is. If nobody has raised this issue up until now , then I must be in the wrong.

That holds true if you run the stack in a server setup, where it needs to be available all the time.
Now imagine using this locally, for backing a development flow that uses the Elastic stack. You will probably want your containers to be running when you're actively working on that project, but when you're not, I'm sure what you'd prefer giving back 2 GB of RAM to your workstation for other purposes.
Like you said the project is popular, so we need to keep it neutral by default, but easily extensible.

If I do want to enable it, I add it to my own local copy or fork, without forcing all users to adopt my own preferences.

Agree, I do not consider this one as a sensible default either.


Add another fuzzy finders support

Fixes #10
Different points from it is below.
"${FZPAC_FINDER}"'s value is colon separated list like a "${PATH}" variable, elements are but commands not directories. fzpac trys to use each of commands in "${FZPAC_FINDER}" in turn as fuzzy finder to find packages. So fallback to following commands if preceding one isn't found.
If no "${FZPAC_FINDER}" is set or empty, fzpac assumes the value is 'fzf:sk:peco:gof:fzy'.
# Elements are command name or path.
FZPAC_FINDER="finder1:/path/to/finder2:..." fzpac ...

# Precede your favorite fuzzy finder if you want to give priority to it.
FZPAC_FINDER="sk:fzf:..." fzpac ...

Thank you for your PR!🙏 I confirmed the operation. I will merge it!


Hello.c:1:19: fatal error: studio.h: No such file or directory  #include<studio.h>

Type: Feature Request
this new version is very frustating alwasys showing errors on output please solve the issus
VS Code version: Code 1.78.2 (b3e4e68a0bc097f0ae7907b217c1119af9e03435, 2023-05-10T14:39:26.248Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.91.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I am using Latest version old version was very good this latest version is very very frustrating latest version is not good

/question This is a C/C++ coding issue, not a VS Code one.

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


Version 0.2.7

add general searchsorted support
format files

Codecov Report
Attention: Patch coverage is 84.90566% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 52.01%. Comparing base (2a632b8) to head (e0a9eef).

Files
Patch %
Lines

src/PTYQoL.jl
84.90%
8 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #21      +/-   ##
==========================================
+ Coverage   48.03%   52.01%   +3.97%
==========================================
  Files          17       17
  Lines         331      373      +42
==========================================
+ Hits          159      194      +35
- Misses        172      179       +7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix onlyoffice docs

Fix typo and links

Not sure why the docs step is failing in CI because of missing file. I tried rebasing now. Let's see if that helps.


Can't click sometimes after clicking stat search box

I just clicked it and then it stopped working, then the UI was completely unresponsive
2018-05-13 10:01:17 [pool-2-thread-1] WARN  n.r.client.ClientSessionManager - Resetting session java.io.IOException: Unsuccessful ping     at net.runelite.http.api.session.SessionClient.ping(SessionClient.java:81)     at net.runelite.client.ClientSessionManager.ping(ClientSessionManager.java:105)     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)     at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)     at java.lang.Thread.run(Thread.java:748) 2018-05-13 18:55:13 [main] INFO  n.r.client.discord.DiscordService - Initializing Discord RPC service. 2018-05-13 18:55:15 [main] INFO  n.r.c.plugins.kourendlibrary.Library - Library is now reset 2018-05-13 18:55:16 [main] INFO  n.r.client.account.SessionManager - No session file exists 2018-05-13 21:04:29 [main] INFO  n.r.client.discord.DiscordService - Initializing Discord RPC service. 2018-05-13 21:04:30 [main] INFO  n.r.c.plugins.kourendlibrary.Library - Library is now reset 2018-05-13 21:04:31 [main] INFO  n.r.client.account.SessionManager - No session file exists

This bug contains like no information and I never saw it reported outside of this issue, so maybe it is not even valid anymore. Closing as invalid, reopen if bug persists + include more information about the bug


Add per-channel quantization support for NEConvolutionLayer

Problem description:
Are there any plans to support QSYMM8_PER_CHANNEL datatype for NEConvolutionLayer input tensor?
Are there any plans to support asymmetric per-channel quantization(something like QASYMM8_PER_CHANNEL/QASYMM8_SIGNED_PER_CHANNEL)?

There are some models that could be quantized more conveniently using asymmetric per-channel quantization. However the case could be handled using existing implementation of course.
@alvoron discussion could be of interest for you


Loader doesn't dismiss when there are several windows.

When, for example, alert controller is displayed in new window right after calling stopAnimating, loader doesn't dismiss, because at the time it tries to do so, keyWindow changed.
Our suggestions are:

cycle through all windows and find loader to dismiss
store weak reference to the window, displaying the loader

#230 addresses this issue by checking all windows on dismiss.


AAD support for baseGroups

Support for specifying a set of baseGroups for which to search from for Azure integration

LGTM


v1.1.0: Generate zenodo DOI

Just need to enable zenodo on this repo. DOI should be generated upon new release.

This is enabled - DOI will be generated upon release.


Add color to station names in chart titles

I've had a go at implementing one of the improved designs for the chart titles. I think the splitting it into smaller chunks helps readability, and I'm a fan of the added color for orientation. (My preferred option with a highlighted background is substantially more difficult to do in HTML canvas, since you have to draw the background color rectangles separately...)
I'm in no way a front-end dev, so let me know your thoughts, esp. if I've done something totally funky.  There are some issues with words overlapping on very small windows- resolving this might make things complicated at best, and infeasible at worst.
Anyway, I'm curious to hear others' thoughts on this approach...

Austin, this looks good. One thing that you could do to prevent the overlap on smaller screens, if possible, is to use a media query to move the rightmost text below the leftmost. For example:
Time between trains (headways)
Downtown Crossing southbound
Graph
Though you say this is Canvas, which I have less experience with than SVG, so I don't know if it is as easy as I imagine.

Thanks @androotubelli!
I'll have a play around with what you suggested. It's easy enough to calculate whether or not there will be overlap and do something different in that scenario.
The hard part I think will be leaving a larger vertical margin above the chart in case we need two lines for the title, since that happens before drawing any text. I'll keep fiddling with chartjs to see if I can get something working that's not too hacky.

Yeah a space between the title and the chart would not be great. If a media query is possible for moving the text to the second line, I would think creating an additional space would also be possible as a media query, but I can imagine that may be unnecessarily complicated for Canvas. Perhaps the title could be extracted and applied as an HTML/CSS element rather than as a canvas element?

According to @mathcolo, there were previous attempts at adding the title in CSS. I like having the title as part of the image itself if possible, but of course there are tradeoffs, and I won't deny that this approach feels a little hacky.
I haven't figured out if the vertical padding above the chart can be modified dynamically in chartjs, and I'm starting to suspect it can't, so I've added a larger vertical margin, which leaves the unused whitespace above the title unless we need to bump into it on small screens: see screenshots.


Integrate new replace menu

What should we do?

add new replace menu
add keyboard shortcut (R) to replace currently selected element

Why should we do it?
Support https://github.com/bpmn-io/bpmn-js/issues/1627.

To consider if we want to do this.

Yes. The keyboard shortcut may be missing with stock bpmn-js (yet). Did we add it?

Could you split up that monstrous issue up in two parts (ship replace + rest).
Makes it easier to follow along and not miss out on such things.

Let's not care about the token simulation R shortcut for the moment, but rather move forward at the core. Token simulation (similar to all other extensions) have to adopt. I.e. could decide to ditch the shortcut or use a different one.


if isinstance(result[0], tuple): KeyError: 0

seems like after updating mmdetection2.4 version , it trigger the bug above

Please follow the template for bug report to describe your issue.
BTW, what commands did you run and when did the error happen? It seems that the error happened when evaluating in the training procedure?

Confirm. This commit in mmdetection master breaks mmdetection3d evaluation:
https://github.com/open-mmlab/mmdetection/commit/e5072a3f75be4bc02da21ac6401e4f97d462c205#diff-49021e47adb24af571f86ef0b131a7eeR95

Thanks for your bug report, this is caused by the batch inference API change in MMDetection V2.4.0. We will also migrate to batch inference ASAP.

the same error. The version of my MMDetection is 2.4.0.


Changing Username on firebase user object doesnt change the name in the Database

When Changing the username from the "Change Username" option of the app, the Firebase object of the User gets updated, but not the username on the Firebase Realtime Database and ultimately on the Leaderboard.
Write code in the method which is responsible for updating FirebaseUser itself to update the database.

Done in commit #e3c200bb7980c7df7c7a044f673eb669d9389a3d.

Done in commit #e3c200bb7980c7df7c7a044f673eb669d9389a3d.


Implement str:join

This presumes PR #928 has been merged; thus, only the last commit is relevant.

It seems that this should somehow be coalesced with the existing joins function, which is implemented here: https://github.com/elves/elvish/blob/master/pkg/eval/builtin_fn_str.go#L286
I'm not sure how I feel about Go library functions that duplicate functionality of existing builtins. Maybe one should just be an alias for the other? @xiaq any thoughts about this?

Note that joins is considerably more limited and annoying, IMHO:
~/projects/3rd-party/elvish> joins : x (float64<PHONE_NUMBER>44555666777888999) y [a '' b] '' c [] d
Exception: want 1 or 2 arguments, got 9
[tty], line 1: joins : x (float64<PHONE_NUMBER>44555666777888999) y [a '' b] '' c [] d
~/projects/3rd-party/elvish> put x (float64<PHONE_NUMBER>44555666777888999) y [a '' b] '' c [] d | joins :
Exception: join wants string input, got !!float64
~/projects/3rd-party/elvish> e = ?(joins : (float64 2))
~/projects/3rd-party/elvish> joins : [x $e]
Exception: join wants string input, got exception

My version handles float64 as well as any other type that implements the elvish Stringer interface:
~/projects/3rd-party/elvish> str:join : x (float64<PHONE_NUMBER>44555666777888999) y [a '' b] '' c [] d
▶ x:111.22233344455567:y:a::b::c:d
~/projects/3rd-party/elvish> e = ?(joins : (float64 2))
~/projects/3rd-party/elvish> str:join : x (float64<PHONE_NUMBER>44555666777888999) y [a '' b] '' c [] d $e
▶ 'x:111.22233344455567:y:a::b::c:d:?(fail ''!!float64 cannot be iterated'')'

It doesn't, however, read the args from a pipe at the moment --- I'll add that capability:
~/projects/3rd-party/elvish> put x y | str:join :
▶ ''

I've modified the str:join implementation to read from stdin if only a separator string is provided as an argument so you can now do put a b | str:join : or str:join : a b.

BTW, @xiaq, I recognize that my choice of signature for this function is controversial. I won't be hurt if you argue it should use type Inputs and behave like  the joins command with regard to how arguments are specified. I actually wrote a version of this function which works that way. Ultimately I think the idiom this establishes is preferable. It can even be applied to count in a backward compatible fashion by special casing one argument, if it isn't a list, as a string whose char count should be returned.

@xiaq You should ignore this PR until PR #928 is merged. At which point I'll rebase and open a new PR. I'm going to leave this open for the moment in case anyone wants to comment about the API divergence from established builtins like joins.
@zzamboni Note that the str: namespace has other functions that mirror existing builtins. For example, str:has-prefix mirrors has-prefix. Yet they are not explicitly documented as analogs. They are also implemented identically implicitly rather than explicitly. That is, they both directly delegate to the Go strings.HasPrefix() function but neither is defined in terms of the other which is a source of potential confusion and bugs.

@zzamboni See also #576 where @xiaq documents the intent to replace builtins such as joins with a str:join. How best to do so while minimizing transition pain is an open question.

@krader1961 fair enough - thanks for the pointer! I agree it would be best to have the functions within the corresponding namespace eventually.

A week has gone by and there haven't been any comments. So close this until PR #928 is merged at which time I'll open a new PR.


No headingTextStyle, dataTextStyle, headingCheckboxTheme & datarowCheckboxTheme in PaginatedDataTable2 and AsyncPaginatedDataTable2

Hi there,
I'd discovered that these fields were found in DataTable2, but was missing in PaginatedDataTable2 and AsyncPaginatedDataTable2
:- headingTextStyle
:- dataTextStyle
:- headingCheckboxTheme
:- datarowCheckboxTheme
(version: 2.5.6)
Would help a lot if it could be implemented. Thank you.

Updated and pushed to pub.dev

Thank you very much.


Wifi interface is not added to bridge in bridge mode

Hello,
I had a problem with the bridging mode on my Raspberry Pi 1 Model B. As OS I use Arch Linux on my Pi and the Wifi stick is the TP-Link WN725N v2. Because of the Realtek chipset I have to use hostapd-rtl871xdrv from the AUR.
When trying to set up an access point with create_ap --driver rtl871xdrv -m bridge wlan0 eth0 TestAP the AP was up and running but I couldn't connect to it. All my devices didn't get an IP address from my router.
Doing the same thing with NAT worked perfectly, but I wanted the bridge mode. So I looked deeper into the problem and I noticed that the eth0 adapter wasn' added to br0. So as a workaround it is possible to execute the following line after the AP is running:
ip link set wlan0 master br0
This adds the wifi interface manually to the bridge.
Furthermore I added the following line to the create_ap script (right before echo "$BRIDGE_IFACE created."):
ip link set $WIFI_IFACE master $BRIDGE_IFACE
But I don't know if this can be done in general or it's just useful in my case. Can you please have a look at it?

I have exactly the same problem using the rtl871xdrv on a odroid running ubuntu 3.10. The wlan0 interface is not added to the bridge when create_ap completes its set-up.


Handle unicode uppercase characters in autocomplete

See https://github.com/Shopify/ruby-lsp/pull/957#discussion_r1310779085 for more context.
We currently only support "A".."Z" for completion. Let's understand the efforts and trade offs for supporting any arbitrary uppercase unicode character for completion, since Ruby does allow them to be used in constant names.

The characters that can begin constants depends on the source encoding. If it's # encoding: ascii then what you have is correct. So whatever solution you end up with, you should use the encoding of the source file.
A cheap way to do it is to ask Ripper or YARP. Both will have the encoding object for you.
encoding = Ripper.new(source).tap(&:parse).encoding

Once you have the encoding, you should make a regexp that is fixed so that encoding:
regexp = Regexp.new("[[:upper:]]".encode(encoding), Regexp::FIXEDENCODING)

then you can check if it matches the character:
begin
  regexp.match?(character)
rescue Encoding::CompatibilityError
  # If the character can't be represented in that encoding, then
  # it can't possibly be uppercase.
  false
end

@nirvdrum would know much more about this

@paracycle found out the right answer in https://github.com/Shopify/ruby-lsp/pull/1171#discussion_r1386765023. The spec already handles any valid identifier for trigger characters, so we actually don't have to worry about this.
Just indexing constants that use unicode characters should be enough.

Honestly, this doesn't feel like it's worth the effort and we received no requests for supporting this.


chore: no key warning

Description
Resolve the react error in dev mode due to no key passed in the Boxed component.
Fixes # (issue)
Type of change
How Has This Been Tested?
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:green_circle: Total coverage has increased
// Code coverage diff between base branch:release and head branch: fix/noKey-warning

Status
File
% Stmts
% Branch
% Funcs
% Lines

:green_circle:
total
56.48 (0)
37.98 (0.01)
36.27 (0)
56.7 (0)

:green_circle:
app/client/src/utils/WorkerUtil.ts
89.76 (0.78)
72.55 (1.96)
100 (0)
93.33 (0.95)

:green_circle:
app/client/src/utils/autocomplete/TernServer.ts
52.94 (0.23)
41.67 (0.84)
36.21 (0)
56.99 (0.25)

/ok-to-test sha=8661cce


various, multiseptate/septa   PMID:27898700

PMID:27898700
inviable stubby multi-septated vegetative cell
descendent of
FYPO:0002200	inviable stubby septated vegetative cell
thin incomplete primary septum
FYPO:0004654	thin, incomplete secondary cell septum
descendent of
thin discontinuous primary septum
NTR: abnormal septum site selection, incomplete septum, asymmetric assembly sites
A cellular process phenotype observed in the vegetative growth phase of the life cycle in which barrier septum assembly takes place in an abnormal location. The  septum begins assembly  at
two sites which are not on opposite sides of the medial cortex and terminates prematurely on both sides.
child of
FYPO:0002154	abnormal septum site selection
(is also is_a incomplete septum)
NTR thick secondary cell septum
descendent of
FYPO:0003211	abnormal secondary cell septum biogenesis
NTR abolished protein localization to cell tip

thin incomplete primary septum

"thin discontinuous primary septum" isn't a term now, and will be an exact synonym of the new term

abnormal septum site selection, incomplete septum, asymmetric assembly sites
..
(is also is_a incomplete septum)

I'll polish up the name wording. We don't have a generic "incomplete septum" term; I can add one, but I can't link it by is_a to a "septum assembly" term because a process phenotype can't be a type of structure phenotype (and vice versa). I'll make sure there's a path involving output_of.
Same goes for "thick secondary cell septum" and septum biogenesis - path will include output_of.

abolished protein localization to cell tip

is FYPO:0001585 (not so new ;) )

abolished protein localization to cell tip
is FYPO:0001585 (not so new ;) )

I keep forgetting that abolished isn't a descendent of abnormal....

I always until just, thought that it should be, but its good that you insisted not. "Abolished  process"  or "abnormal process" might be really useful "slim filters" on a gene page....
so you could quickly see which alleles abolished process completely or affected them.
I see the filters as way of  accessing specific alleles of different types like this....

inviable stubby multiseptate vegetative cell FYPO:0005869
incomplete septum FYPO:0005870
thin, incomplete primary cell septum FYPO:0005871
abnormal septum site selection from asymmetrically located sites, forming incomplete septum FYPO:0005872
increased secondary cell septum thickness FYPO:0005873
edit file: 39b7f12b4b763a4f85451bfff712d553ce002b33
release: 283902eb88adde96079e85c474853903133bd800


error while installing waifu2x

i cant seem to install this package on any operating system using npm i waifu2x
the error i get is this
2023-02-17T11_25_24_615Z-debug-0.log
attached are the logs for this.
npm ERR! syscall spawn git
npm ERR! path git
npm ERR! errno -4058
npm ERR! enoent An unknown git error occurred
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

turns out all i needed to do was install git. -_-


Prevent check of stream position on streams that don't support seek

Avoids exception when you pass HttpContext.Request.Body to SendAndScanFileAsync( Stream, CancellationToken )

Due to other PR merges this PR had a conflict so I've fixed that and incorporated into into #42, thanks for your contribution!
Also, thank you for the shutdown method addition.  I have removed all of that re-formatting as well.


Added support for incoming SASL/IAM auth

what

Added support for the incoming (AWS provider 2.43.x) SASL/IAM auth method.

why

Allows access control to an MSK cluster via IAM instead of requiring SCRAM secret management.

references

AWS provider support: https://github.com/hashicorp/terraform-provider-aws/pull/19404
closes #20

Description should say 3.43
Added support for the incoming (AWS provider 2.43.x) SASL/IAM auth method.


What does this PR do?
Re-apply #1261.
Which scenarios this will impact?
All the Kubernetes-based ones.
Motivation
Additional Notes
Tested by DataDog/datadog-agent#31558

This change has been successfully tested in DataDog/datadog-agent#31393

/merge


make single-point etcd service become multi-point service failed when want keep the old data

At the beginning I have only one host run etcd like this(/etc/etcd/etcd.conf):
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:4001"
ETCD_ADVERTISE_CLIENT_URLS="http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:4001"

Then I want add two other host in that cluster meanwhile keep the etcd's old data.
So firstly  cp -ra /var/lib/etcd/default.etcd/* /search/test/  to keep the old data . Secondly change the etdcd config file  like this:
ETCD_NAME=node1
ETCD_DATA_DIR="/search/test"
ETCD_LISTEN_PEER_URLS="http://<IP_ADDRESS>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:4001"

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER="node1=http://<IP_ADDRESS>:2380,node2=http://<IP_ADDRESS>:2380,node3=http://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
ETCD_INITIAL_CLUSTER_TOKEN="kube-etcd-cluster1"
ETCD_ADVERTISE_CLIENT_URLS="http://<IP_ADDRESS>:2379"

systemctl start etcd then etcdctl member list output as below:
ce2a822cea30bfca: name=node1 peerURLs=http://localhost:2380,http://localhost:7001 clientURLs=http://<IP_ADDRESS>:2379
This is obviously wrong!  It seems that if I use old data the config file doesn't work anymore.Wrong log as below:

Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: streaming request ignored (cluster ID mismatch got 2e20aefc0938965 want 987cde7c4bf4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: streaming request ignored (cluster ID mismatch got 2e20aefc0938965 want 987cde7c4bf4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: streaming request ignored (cluster ID mismatch got 2e20aefc0938965 want 987cde7c4bf4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: streaming request ignored (cluster ID mismatch got 2e20aefc0938965 want 987cde7c4bf4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)
Jun 08 20:17:19 mesos-78-12 etcd[38063]: request sent was ignored (cluster ID mismatch: remote[f18051b329e62a36]=2e20aefc0938965...f4849c)

So how can I fix this problem?
Thanks!

@workhardcc What etcd does is expected. It protects you from corrupting your cluster. Please use the configuration API to add/remove members: see https://github.com/coreos/etcd/blob/release-2.3/Documentation/runtime-configuration.md#add-a-new-member

Thanks for your reply!
You know my cluster start with static config file. I want to know that if I use API to update members, didn't I need to manual update the configure file ?


build: bump madsim

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
I'm thinking whether https://github.com/risingwavelabs/risingwave/pull/15722#issuecomment-2111456566 is related with madsim
test_serving_cluster_availability ---
thread '<unnamed>' panicked at src/tests/simulation/tests/integration_tests/batch/mod.rs:138:31:
called `Result::unwrap_err()` on an `Ok` value:

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

cc @wangrunji0408 @zwang28

BTW, madsim cannot compile with<EMAIL_ADDRESS>

I'm afraid we need to bisect madsim version between 0.22 and 0.27. 🥵

I guess it's possibly related with sleep? BTW, @zwang28 pushed a new commit to change the test in https://github.com/risingwavelabs/risingwave/pull/15722

cc @zwang28  Do you confirm the root cause of the failure? Wondering if it was simply caused by a different random number generated.


Added default_case option for Response plug

Coverage increased (+0.1%) to 96.364% when pulling e3198203ce011189cb984e51e2b1aa3b58919c1b on madshargreave:default-case into 945659b826b0d1df4d28eb5c6c4d8178f3418704 on sticksnleaves:master.

Thanks for putting this together! Sorry for not getting back to this sooner. Had a short week last week.
What if someone passes in an unsupported case? Should the default case be used?

I also think falling back to the default in unsupported cases would make sense.

@madshargreave could you implement a fallback to :default_case in the event an unsupported case is provided?

Closing due to inactivity.


Breadcrumbs Redmine Titles not correctly applied

Thanks for your great theme.
Really great!
Please, would you mind include in future revisions:  "a.root", "a.ancestor" and ".current-project" to PurpleMine2. This is the code with force new-line for current-project.  In classic Redmine theme this effect it is usual.
Thanks a lot !
Best regards.
`a.root{
font-size: 18px;
font-weight: normal;
}
a.ancestor{
font-size: 18px;
font-weight: normal;
}
.current-project{
display: block;
}`
This will be the effect:

Hi,
.current-project class was just introduced in Redmine 3.3, and not everyone has that long project names, so for compatibility, I had to do it differently, but should do the trick for most cases.


Storage account name less than 15 characters

Can we add a note when creating a unique name for the storage account that it not be longer than 15 characters?  This would prevent errors when running the AD DS domain join commands when the storage account name is longer than 15 characters and the deployment process needs to be restarted.

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

ID: 3b190fd1-42f6-3a90-5931-74b2ccd309c3
Version Independent ID: c4ca3c86-6257-59dd-e5a3-d40d4e0fa83c
Content: Create an Azure Files file share with a domain controller - Azure
Content Source: articles/virtual-desktop/create-file-share.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

@azurejoe Thank you for your feedback!  We have assigned this to the document author for further review.

Thanks for the feedback. I can see this was added to the article on 21st March.
#please-close


Error: Input buffer has corrupt header: glib: XML parse error

What is the output of running npx envinfo --binaries --languages --system --utilities?

What are the steps to reproduce?
https://gist.github.com/NoTalk-ly/11678ba68dc682498b92e5402333da68 this gistcan reproduce this case.
What is the expected behaviour?
no error.
Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?
above code snippet only depends on sharp.
Are you able to provide a sample image that helps explain the problem?
this error means sharp is not compatible some svg format？ but I use node-canvas to convert svg to png， it works without error，and the output image is correct.

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


How to find the session log out time for a user due to session inactivity.

I can able to find the user log out time in manual logout and write that data into a file but how can I find the logout time due to session inacticity?,because am using devise timeoutable it is redirecting to sign in page after the session.

Please use the mailing list or stack overflow for questions, we reserve the issues tracker for issues. Thanks!


feat!: deprecate Button and ButtonBase

Overview
PR Checklist

[x] Related to designs: https://www.figma.com/file/N6TfoPI5OA7GanX6Zl8nWj/Buttons-✅?node-id=268%3A16
[x] Related to JIRA ticket: GM-121
[x] I have run this code to verify it works
[x] This PR includes unit tests for the code change

Description
In preparation for #1070, marks the old buttons as deprecated in Storybook.

📬Published Alpha Packages:@codecademy/gamut-labs@4.4.6-alpha.00b0e3.0@codecademy/gamut@17.0.0-alpha.00b0e3.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f90649d41b8820ca4c9abe3--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.4.6-alpha.723c3c.0@codecademy/gamut@17.0.0-alpha.723c3c.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f90738f9e6195014b6580c0--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.4.6-alpha.13fe5f.0@codecademy/gamut@17.0.0-alpha.13fe5f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f96ed80caf4132fa50c5329--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.6.3-alpha.04bc70.0@codecademy/gamut@17.0.0-alpha.04bc70.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f99ed1b4b7d4714219b6b13--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://5fa0175ce50d1a349dd9ae3f--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://5fa01dea358dde3db2bfc0c4--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.7.1-alpha.a05f8f.0@codecademy/gamut@17.0.0-alpha.a05f8f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fa0c602ebf56440a2cfff02--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.7.3-alpha.111988.0@codecademy/gamut@17.0.0-alpha.111988.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fa40a11fb2653b15a79255b--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-labs@4.8.1-alpha.21f737.0@codecademy/gamut@17.0.0-alpha.21f737.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5fa484a1cbada300b4d46440--gamut-preview.netlify.appDeploy Logs


Remove incorrect JS for indeterminate progress

The documentation for Pico currently says you need to use JS to set a <progress> bar to an indeterminate state, but this doesn't actually work. The following code does not create an indeterminate progress bar:
<progress id="indeterminate-progress" value="25" max="100"></progress>
<script>
  document.getElementById('indeterminate-progress').indeterminate = true;
</script>

Based on the MDN article about <progress>, a progress bar is in an indeterminate state if there is no value attribute. This happens to be the case with the progress bar in the Pico documentation as well.
In other words, the JS in the Pico documentation doesn't do anything.

I have removed the unnecessary JS from the documentation, and documented that a progress bar is indeterminate if there is no value attribute.

The only element I know of for sure that does act this way is the checkbox. If you set its indeterminate property to true, then it will show the [-] icon instead of [ ] or [x]. This is handy for "check all" features, where the checkbox in question is both acting as a button to check all and a sort of state indicator for "are all of these checkboxes checked?".

@walterdavis True. mdn confirms that you need JS to set the indeterminate state for a checkbox. It looks like that case is already covered by Pico's documentation.
This PR only covers the indeterminate state for progress bars, which is actually unrelated to the indeterminate property. Instead, a progress bar is indeterminate if and only if the value attribute is not set in the DOM.

Hi @FWDekker,
Thank you, good find.
I will merge your PR into dev. Then I will add a few more fixes before merging into master.


Refactor the interface to avoid depending on libp2p

Summary of changes
Changes introduced in this pull request:

Removed use of  libp2p_identity::PeerId

Reference issue to close (if applicable)

Closes #24
Other information and links

Codecov Report
Patch coverage has no change and project coverage change: +0.01 :tada:

Comparison is base (a023655) 13.53% compared to head (dbd3ce7) 13.54%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #65      +/-   ##
==========================================
+ Coverage   13.53%   13.54%   +0.01%
==========================================
  Files         201      201
  Lines       19973    19958      -15
==========================================
  Hits         2704     2704
+ Misses      17269    17254      -15

Impacted Files
Coverage Δ

fil_actor_interface/src/builtin/miner/mod.rs
3.04% <0.00%> (+0.14%)
:arrow_up:

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

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


Pin dependencies to prevent the update

k8s dependencies
client-go dependencies
Azure and go-kit dependencies

What this PR does / why we need it:
This PR pin some dependencies to prevent their update as a side effect of make deps-update.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/retest

/retest

@slintes I did it, but go mod tidy change it to the date-commit stuff, I believe at least for 1.11.5 only tags that supported should have the form v0.3.0

@slintes I did it, but go mod tidy change it to the date-commit stuff

ok, too bad
I can't see logs of the failed jobs, probably because of the change in the prow config of today,will retrigger tests
/retest


New G-KPFM Notebook

Closing pull.  The new notebook has already been added to master and this pull makes many conflicting changes to the code.  If any of the other changes need to be merged, please apply them to the current master and create a new pull request.


refactor(sfc): codegen for user import bindings

close #11273
The underlying issue is that user import bindings are rewritten to $setup.Color in non-inline mode and Color is not returned in the setup function.

Solution 1: Return Color in __return__, which requires modifying isImportUsed to check if the import var is used in cssVars.
Solution 2: Introduce SETUP_IMPORTED_MAYBE_REF to handle user import bindings specially (the approach taken in the current PR).

/ecosystem-ci run

/ecosystem-ci run

/ecosystem-ci run

/ecosystem-ci run


Grid picking up previous values

Issue Type (delete the irrelevant ones)

[x] Bug

Specs
What version are you using?
Latest
What browser?
Chrome
When in remote mode and the per page is changed the table is rendering the previous values
I can't produce a repro very easily for this as it requires a server setup to response to the backend. I can show some screenshots of what's happening though:

Note that the state indicates that the data is from 26+ in column1 but actually what's displayed is 1-25. I noticed that when you change the per page the backend is called twice but when you change the page it is not. I also noticed that when the per page values are left at default this behaviour does not occur.
So for example when I have a per page of 10 by default the paging works fine but if I change to a per page of 25 then back to 10 it show the previous values in the grid. It's almost like once the per page is set the re-rendering of the table is out of date.
I'm lost on where to look at this but I noticed similar problems with the per page.

Something to do with these options:
        :paginationOptions="{
          enabled: true,
          perPage: serverParams.perPage,
          perPageDropdown: [10, 25, 100,250],
          dropdownAllowAll: false,
        }"

When I remove the perPage and the perPageDropdown options it's works. But with these options set the thing seems broken.

Same thing is happening when i have values updated by search. Is there a way of re-rendering the table. I've noticed on search that the loading icon doesn't display either and it only calls the back-end once rather than twice.

Disregard this. It's to do with the fact the rows are in vuex. I moved them to the component and it's all working sorry about the confusion.


Implement natural sort for nodepools

Problem: Rancher would remove "node9" instead of "node10" when decreasing
nodepool size. This was due to the alphabetical sorting of nodepool names.
Solution: Implement natural sort of nodepool names.
Addresses: https://github.com/rancher/rancher/issues/19431

LGTM

lgtm


Add flag for exiting with code 1

In my CI system, before allowing anyone to commit their code, I would like to make sure that all imports are sorted correctly. Usually, CI systems react on exit codes of the commands you specify.
Let's say in black there is a --check flag which just exits with code 1 in case there are some suggestion. The same thing in mypy. Can we introduce something similar in isort?

Hi @Jihadik,
isort has had a --check option for many years, and behaves exactly as you explain :).


Use prop-types package (PropTypes in React package is deprecated)

Because PropTypes is not available anymore in newer React packages, we need to use the standalone prop-types package to keep using PropTypes functionality.
See https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html#migrating-from-react.proptypes

@gpeal any chance to release a new version with this fix and support for react@16?


[onchain-fees] replace KAR token with TUR for on chain fees

KAR token is not needed currently
use the TUR token instead we need for bootstrap

LGTM +1 so we want to do bootstrap on rococo ?

no, just initial testing


Covariance checking on method signatures.

TL;DR, poke through API, evaluate if we have correct/valuable covariant types.
I'm rusty with generics and the implications therein, so recalling some notes:

covariant: accepting of subtypes; <? extends T>, representative of an "upper bound", read-only; we can be certain that it is, at the very least, T, but can't be certain of the actual type "below"
contravariant: accepting of supertypes; <? super T>, representative of a "lower bound", write-only, we can be certain

generally "closed" in Recipe core by https://github.com/openrewrite/rewrite/commit/4a02e760c6c099429d99c09058680a34c1569674 though there may be other opportunities to tighten up covariance
going to leave this open as a reminder until further review, but will move back to backlog

generally "closed" in Recipe core by https://github.com/openrewrite/rewrite/commit/4a02e760c6c099429d99c09058680a34c1569674 though there may be other opportunities to tighten up covariance
going to leave this open as a reminder until further review, but will move back to backlog

For future reference, here's a practical direct example usage of why covariance is valuable, specifically in the case of Recipe's .run(). Prior to Recipe having an invariant method signature on run, Recipe's run args needed SourceFiles, even though it may accept a list of subtypes to operate on; e.g., a list of J.CompilationUnit, despite being an extension of SourceFile, would have to be streamed/mapped/recollected to upcast to SourceFile as an input, rather than being able to input the subtype directly.
E.g., given:
// Recipe.java
public final List<Result> run(List<SourceFile> before)

this usage fails--
// barfs because...
        List<J.CompilationUnit>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
                ;
        List<Result> results = new Recipe().run(cus); // ... <-- J.Compilation unit is not SourceFile

and doing so would require stream/map-casting/re-collecting directly to SourceFile, like so:
        List<SourceFile>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
                .stream()
                .map(cu -> (SourceFile) cu) // note how we had to otherwise include this parse/stream/map/collect
                .collect(Collectors.toList())
                ;
        List<Result> results = new Recipe().run(cus);

despite the fact that J.CompilationUnit is a subtype of SourceFile and should otherwise be able to be operated on.
By widening the signature to be covariant, it's more flexible. Given:
public final List<Result> run(List<? extends SourceFile> before)

then we have more flexibility as intended:
        List<J.CompilationUnit>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
// not needed:
//                .stream()
//                .map(cu -> (SourceFile) cu)
//                .collect(Collectors.toList())
                ;

        List<Result> results = new Recipe().run(cus);

Just makes it easier to operate and clarifies intent.

For future reference, here's a practical direct example usage of why covariance is valuable, specifically in the case of Recipe's .run(). Prior to Recipe having an invariant method signature on run, Recipe's run args needed SourceFiles, even though it may accept a list of subtypes to operate on; e.g., a list of J.CompilationUnit, despite being an extension of SourceFile, would have to be streamed/mapped/recollected to upcast to SourceFile as an input, rather than being able to input the subtype directly.
E.g., given:
// Recipe.java
public final List<Result> run(List<SourceFile> before)

this usage fails--
// barfs because...
        List<J.CompilationUnit>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
                ;
        List<Result> results = new Recipe().run(cus); // ... <-- J.Compilation unit is not SourceFile

and doing so would require stream/map-casting/re-collecting directly to SourceFile, like so:
        List<SourceFile>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
                .stream()
                .map(cu -> (SourceFile) cu) // note how we had to otherwise include this parse/stream/map/collect
                .collect(Collectors.toList())
                ;
        List<Result> results = new Recipe().run(cus);

despite the fact that J.CompilationUnit is a subtype of SourceFile and should otherwise be able to be operated on.
By widening the signature to be covariant, it's more flexible. Given:
public final List<Result> run(List<? extends SourceFile> before)

then we have more flexibility as intended:
        List<J.CompilationUnit>
                cus = JavaParser.fromJavaVersion()
                .build()
                .parse()
// not needed:
//                .stream()
//                .map(cu -> (SourceFile) cu)
//                .collect(Collectors.toList())
                ;

        List<Result> results = new Recipe().run(cus);

Just makes it easier to operate and clarifies intent.


Jit flush message fix

I think it would be better to not have the tuning tip be conditional; if there are a lot of jit.flushes, it's easy to miss.

LGTM, though the lack of CI is bothersome.

Fixed; now prints e.g.
336073.38695098: warning: Dropped more than 100000 packets; flushing JIT to try to recover.  See https://github.com/Igalia/snabb/blob/lwaftr_starfruit/src/program/lwaftr/doc/README.performance.md for performance tuning tips.


Regression on POSIX shells

The following change introduced in https://github.com/blmayer/astro/commit/055ecf1cd2a0e46c3d39955b5153d91143f32643 produces the render below on POSIX compliant shells (tested with dash 0.5.12). I guess you can either change the shebang for a non-POSIX compliant shell or revert this change (reverting seems to work as expected)
Change at https://github.com/blmayer/astro/blame/297bdb047d2247a7da088f58bcbdbefc10ac9a22/astro#L203:
- printf -- "$sty$txt\\n"
+ echo -e "$sty$txt"

Current ugly output (note the spurious "-e"):
        -e Project Gemini
        -e
        -e Gemini in 100 words
        -e
        -e Gemini is a new internet technology supporting an electronic library of interconnected text
        -e documents.  That's not a new idea, but it's not old fashioned either.  It's timeless, and deserves
        -e tools which treat it as a first class concept, not a vestigial corner case.  Gemini isn't about
        -e innovation or disruption, it's about providing some respite for those who feel the internet has been
        -e disrupted enough already.  We're not out to change the world or destroy other technologies.  We are
        -e out to build a lightweight online space where documents are just documents, in the interests of
        -e every reader's privacy, attention and bandwidth.
        -e
        -e  1 => If you'd like to know more, read our FAQ
        -e  2 => Or, if you'd prefer, here's a video overview
        -e
        -e Official resources
        -e
        -e  3 => Official Project Gemini news
        -e  4 => Official Gemini documentation
        -e  5 => Known Gemini software
        -e  6 => Known Gemini servers
        -e
        -e CAPCOM aggregator
        -e
        -e This server hosts the first Gemini content aggregator, CAPCOM.
        -e
        -e  7 => CAPCOM
        -e
        -e Free Gemini hosting
        -e
        -e In the earlier stages of Project Gemini, free hosting was provided at this server.  The offer has
        -e been discontinued for new users, but existing accounts remain open and content remains online.
        -e
        -e  8 => Users with Gemini content on this server
~
~

Hi, thanks for looking at this. I fixed this in a later commit. Let me check what happened.

I confirm a4a71d5 correctly fixes this issue. Thanks a lot.

Thanks for reporting this.


copy from - undocumented dependancy on table status

CrateDB version: 2.3.4
Environment description: docker 2.3.4

Problem description:
this happened. a) I upgraded from earlier release to 2.3.4 by taking out the schema by show create table. b) created new tables in 2.3.4 with these schemas. c) tried to import by copy from json files. Nothing happened and no error message. It turned out that the table had a warning due to the fact that the dev node only was running one node and the schema had replicas = 1. When setting replica to 0-1 or default it was possible to import to 2.3.4. But no clear message that this was the cause. It was possible in earlier release. Maybe some info  doc under migration chapter would clearify this. /Jonas
-->

error message or info in the docs under migration. I see a warning on the table but had to figure out that warning was due to replicas/nr of node and that this stopped the import.
maybe info in docs under copy from that table must not have this warning/cause to make import possible,
/Jonas

In the next feature release (3.1) there will be COPY FROM .. RETURN SUMMARY which can be used to get a description of errors that happened.
I think that'll help a lot to get more insights into what's going on. I'll close this for now but we'd also gladly accept PRs that improve our documentation in various places.


Remote Attachment Codec

Expectations

Adding new codec to Flutter SDK to enable read remote attachments

I'm going to pick this up and get it merged in a series of forthcoming PRs -- thank you for putting this together!
(First PR is up w/ just the compression bits: https://github.com/xmtp/xmtp-flutter/pull/115)


Initial event for properties is only send to handlers of same object

from flexx import event

class Foo1(event.HasEvents):

    @event.prop
    def bar(self, v=0):
        return v

    @event.connect('bar')
    def on_bar(self, *events):
        print('Foo1 saw bar change')

class Foo2(event.HasEvents):

    def __init__(self):
        self.x = Foo1()
        super().__init__()

    @event.connect('x.bar')
    def on_bar(self, *events):
        print('Foo2 saw bar change')

>>> f = Foo2()
Foo1 saw bar change
>>> f.x.bar = 3
Foo1 saw bar change
Foo2 saw bar change

This was initially somewhat intended. Or at least a consequence of how the initialization worked, which at the time seemed acceptable. But I just ran into this and banged my head into the wall, so I now consider it a bug.
The point is that each object sends initial events at the end of initialization. But x does that at a time when the handlers of f are not yet connected. Maybe it makes sense to have each object check all handlers and create initial events for itself when such a handler is attached to a property.

The "cycle" here could also use some documentation; taking a composed widget with a super- and subclass as an example might be a good use-case to demonstrate in which order properties are set and init()s are called?

We just hit this one as well (after a few hours were wasted...). Doesn't it make sense to go through the steps explicitly?

Connect all event handlers
Assign kwargs to @event.props, letting events build up
Run init()on all widgets
Start event loop

Well, it's probably more complicated than that.. but it would be easier to understand if the flow was summarized like that somewhere in the docs.

That's basically what happens. Though there are various subtleties, like first set the props to their initial value (without sending an event), then call init() (cause it might create stuff that handlers need), then fire all events. And do the same at the JS side, at the right moment, so that it works consistent with how the Py side works, and not get events all mixed up :)
But yes, it needs more docs and examples (#192). And this issue need fixed asap.

(Sorry about your lost time, this is an issue that I have been wanting to fix since Scipy, have not gotten to it yet.)

A good approach to fix this (IMO) is to emit an event at the moment that a handler connects to an event that corresponds to a property (instead of explicitly firing such events after init). That way, when any handler connects to a event corresponding to a property (at any time), it will immediately receive an "initializing" event.
Now, what to do with dynamism? If we connect to "children.*.count", should we (A) get an event for each child when children changes (because that will trigger a reconnect)? Or (B) should the initializing-property-event only happen when a handler initialized (not each time it registers)?
Remember #120? With (A), we basically have a proposal similar to that of @korijn; in connecting to "children.*.count", when children changes, you'd get an event for each child. Not entirely sure what's more natural, I fear that (A) might hurt performance in some cases.

If you consider the case of "current_widget.title", then it makes a whole lot more sense to go with (A).

It's hard to judge since I don't have a good sense of what the event lifecycle looks like. Let's see if I got this right:

Property-setters are called first, passing in the corresponding kwarg if available.
init() is called to construct the widget's internal hierarchy.
Event handlers are connected.

Now, I'm going to think out loud here, hoping that it'll produce something useful... I matched the "idea" labels to yours, correct me if I'm wrong.
(C) If you change the order to (3, 2, 1), the event handlers "naturally" get events for their initial values. The only downside is that init() can't assume that the properties have been set already.
(D) We could also change the order to (3, 1, 2), but then event handlers can't assume that the internal widget hierarchy has been set up.
(B) You can also emit "initial event" as a 4th step making the order (1,2,3,4). That could work. I don't really see a downside to this one?
(A) Your suggestion to emit an "initial event" whenever an event handler is connected sounds like a concept from the old react system. It would be more appropriate to call it a "current value event" IMHO. This would "automatically" make it work, but also introduce new behavior elsewhere, e.g. in dynamism, which seems undesirable to me.

Aside of all this, I think that if you take a step back to zoom out, there is another solution that can be seen. Why not wait with step (4) until all event handlers have been attached, executing (4) globally instead of locally for each widget?

Another idea: @event.prop decorates a property that emits events. When such a property is set, that causes an event to be emitted. Now, I assume that these are "collected" somewhere until the next event-loop iteration, since our event handlers have a *events argument. Why not change where they are collected?
Assuming that the initial page construction (of all widgets) occurs in a single event-loop iteration. If you let the events build up and collect them at the property, rather than at the connection/handler, they will automatically propagate to all connected handlers in the next event-loop iteration, no?

You can also emit "initial event" as a 4th step making the order (1,2,3,4).

That's essentially what happens now. The problem is that a handler that connects after the object is created (as in a class that wraps another Widget) will not receive this event.
A global event is also not feasible, since you may compose / connect models after starting an app.
Just to be clear, I call it an "initialization-event" but it is the same event as would be send when the prop changes. I just called it that to make the distinction.

Your suggestion to emit an "initial event" whenever an event handler is connected sounds like a concept from the old react system. It would be more appropriate to call it a "current value event" IMHO. This would "automatically" make it work, but also introduce new behavior elsewhere, e.g. in dynamism, which seems undesirable to me.

The name of the event is just for the sake of discussion. I think you should indeed see it as a "current value event". If what we chose changes the behavior, that will be alright if that behavior is more natural than what we have now :)

It is clear that we want an initial event for handlers that connect to props on the same Model.
This issue made clear that we also want such an initial event for handlers that connect to props of a wrapped model, because it would be confusing otherwise.
Following through, I think it makes sense if any handler that connects (at any time) to a property receives an event to communicate the current value of that property.

The remaining question, I think, is whether an automatic reconnect due to dynamism should also lead to such events. I am leaning towards yes. To clarify, for a connection "parent.title" or "children.*.count", we would receive "title" and "count" events when  the parent/children change. This is different from the (removed) behavior in #120, where we would get "children" and "parent" events (which the handler would then need to filter).

Thanks for the clarification. I think you've got the right idea. I hope we're not overlooking any unexpected side-effects!

The story continues ...
This was fixed by sending a special event when a handler registered to an event corresponding to a prop. A side effect of this is that a handler connecting to children*.value gets a new "value" event each time its children changes.
I just ran into an issue where emit() was used from init() which does not work anymore. And I think it should work. Inspired by something @Korijn said above, I made events be captured, and clear this captured cache of events in the next event loop iteration. Any handler connecting to an event in the current event loop iter will receive the cached events. This by itself would also solve the problem that this issue describes.
The question is now: should we get rid of the special behavior for events corresponding to properties? In other words, when we have a handler connected to "parent.stack.children.value":

a value event is send when parent"

Simpler seems better: it's more predictable.
If you want to respond to the amount of children changing, just add parent.stack.children to your connector!
Also, wouldn't it be parent.stack.children.*.value?

Imagine using a deep connector ** and getting events for all the elements/parents/children along the (many?) path! That's certainly undesired... I would definitely go with the simpler behavior.

Also, wouldn't it be parent.stack.children.*.value?

Yes, that was a typo.

If you want to respond to the amount of children changing, just add parent.stack.children to your connector!

I agree with that, and I think it makes sense if you have a * in the connection string, . But if I think of an example where you want to keep of your parent's  title, I prefer writing connect('parent.title') and not `connect('parent', 'parent.title').
On the other hand, if Flexx re-sends events when the path changes, there is no way for the user to make Flexx not do that (unless he/she uses a proxy emitter or something). Whereas an extra connection string is easily added.
So I think we should go with the simpler approach yes.

So I agree that we should prefer the simpler approach, although there may be a middle-ground too.
Consider the following: if you connect to parent.title, then when parent is switched out, that could mean that parent.title no longer has the same value as before the switch. In such a case, I think it would make sense if you receive an event. If the value remains the same however, what gives?
I think that with this subtle difference, you can have an intuitive development experience for both of the scenarios. Connecting to just parent.title should allow you to track any change in the value. The same is true for the deep connector. Because, IMHO, that's all the event handlers should really care about.

I'm not sure if I understand what you mean. Checking if the value that parent.title represents changes when the parent changes seems like a lot of extra stuff: keeping track (holding on to) the current value, etc.. In that case I'd say we should not worry about sending an extra event when the value has not changed.
I don't see how what you propose maps to a connecting string with a star or with a deep connector, because then there is not a single value that you track. Rather, you're tracking a collection of values.
I'm almost inclined to say that we do the property-init-event thing only for connections that do not contain a star, but that would only add confusion.
Thinking about it more, a connection string is not a path to a value to track. It is a path to an event that we want to receive. This is obvious for stuff like mouse events, and also for the case where a connection string targets multiple events using the star syntax. It is less obvious for parent.title, but I don't think that case should break the rule.
We could consider allowing a syntax like +parent.title (exact syntax up for discussion) to indicate that the handler should fire for whenever any part in the path changes. Though let's wait with discussing this until we've used the new system for a bit.


Swagger UI isn't there

When generating my api repo I answered yes to whether swagger ui should be installed.
But when running npm start localhost:8080/swagger-ui/ returns a 404. Same when deploying to gh-pages.

Just created a test as well.
Looks like swagger-ui has been removed in favor of ReDoc. Looks good.
I think the README template is still referencing SwaggerUI


epath.Path("s3://...") regression in python3.12?

Hi there. I am not at all sure if it is not a misunderstanding or a misconfiguration on my end, but I am seeing different behaviour of epath.Path with s3 (at least) on python 3.11 and 3.12. Please, consider the attached screenshot for details.

Both of the environments are minimal with the following package versions:
Package             Version
------------------- -----------
aiobotocore         2.13.0
aiohttp             3.9.5
aioitertools        0.11.0
aiosignal           1.3.1
attrs               23.2.0
boto3               1.34.106
botocore            1.34.106
etils               1.8.0
frozenlist          1.4.1
fsspec              2024.5.0
idna                3.7
importlib_resources 6.4.0
jmespath            1.0.1
multidict           6.0.5
pip                 24.0
python-dateutil     2.9.0.post0
s3fs                2024.5.0
s3transfer          0.10.1
six                 1.16.0
typing_extensions   4.11.0
urllib3             2.2.1
wrapt               1.16.0
yarl                1.9.4

(with the addition of setuptools==69.2.0 and wheel==0.43.0 in test311).

Thanks for reporting the issue. epath is a small wrapper around fsspec and s3fs (for the s3:// backend).
Could you try to reproduce the issue directly with fsspec:
import fsspec

fs = fsspec.filesystem('s3')

print(fs.exists('s3://aaa/test'))

If so, I would report this directly in https://github.com/fsspec/s3fs/issues, as we cannot fix this from the etils side.

Thanks for the quick reply @Conchylicultor!
Unfortunately, I cannot reproduce it with fsspec and your snippet appears to execute equally correctly with both 3.11 and 3.12. And yet, epath.Path still does not. The following code
path_as_str = f"s3://{BUCKET_NAME}/test"
print(f"{fsspec.filesystem('s3').exists(path_as_str)=}")
print(f"{Path(path_as_str).exists()=}")

on 3.11 yields
fsspec.filesystem('s3').exists(path_as_str)=True
Path(path_as_str).exists()=True

while on 3.12:
fsspec.filesystem('s3').exists(path_as_str)=True
Path(path_as_str).exists()=False

Would you imagine that it may be of any significance that epath.Path.__fspath__ yiels s3://... on 3.11 vs s3:/... on 3.12 (see the screenshot above)?
It looks like in 3.11, Path('s3://aaa/test').parts yields ('/', 's3', 'aaa', 'test') which results in Path('s3://aaa/test')._uri_scheme being correctly identified as 's3'.
In 3.12, however, Path('s3://aaa/test').parts yields ('s3:', 'aaa', 'test'), (same as pathlib.Path('s3://aaa/test').parts) failing this condition, resulting in ._uri_scheme returning None.
Not sure if it is the root cause, but it also does not seem quite right to me... I am failing to find the definition of .parts right now though.

I encountered the same problem for gs:// and updating to the latest etils version has fixed for me

Marking this as closed as the fix has been released. Thank you all for reporting and the fix


February 12 Updates

What's New?

Fixed a subtle bug in the sequence builder where clicking a button would sometimes not fire a click / drag event.
DRYed up the sequence step button group.
Deployed latest to staging
Fixed some gemfile stuff that was causing Dokku to blow up

What's Next?

[x] Eat spring rolls at the hotel breakfast buffett. It's so good.
[ ] Figure out why as-sortable and as-sortable-item aren't working. Raised this issue.
[ ] Re-implement the manual control page, pending setup of bot in CA
[ ] Help Tim get coverage up on rpi.
[ ] Implement the schedule builder.
[ ] See if the scope.sequenceSteps hack is still needed now that most bugs were fixed in js-data.

Holy cow! I need to add public/assets to the Gitignore

Going to merge this one in now before we diverge too much.