ATTACH bbcode

I use vBulletin forum software and am integrating this for live previews, that will be it's only function I wont be saving any information.
One of the bbcodes within vBulletin is [ATTACH]94399[/ATTACH] which converts to attachment.php?attachmentid=94399 this can be either an image or a file.
For the live preview aspect of this, how would I get this to convert attach codes to use an image or link?

Hello! You can simply write a plugin thats convert any bbcode tag to what you need

Thats results into
Hello!  File 20200


bug: random failure of test test_get_logs_address

Bug Report
Kakarot RPC version:

Current behavior:
The test sometimes randomly fails in the CI on
https://github.com/kkrt-labs/kakarot-rpc/blob/25f8cf4694a316703231cdc6a400546d8de8cd81/tests/tests/eth_provider.rs#L344-L346

Expected behavior:
The test should pass everytime.

Steps to reproduce:
This is the main issue: reproducing locally as proven very difficult, as running the test 10+ times failed to expose the issue.
Might have to just run it locally multiple times with logging of the DB until the issue arises.
For this:

Add logging of the test fill of the database.
Build the genesis make katana-genesis.
Un-ignore the test test_get_logs_address.
Run the specific test make test-target TARGET= test_get_logs_address.
Repeat previous step until test fails.
Study logs in order to find issue.

Hey, can I take an attempt on this one?

it's not really a good first issue @rvalenciano so it might be complicated

@greged93 I'll try to reproduce the issue and ping here if I'm able to find anything.

@greged93 giving an update, I was able to reproduce the issue by running
for i in 1 2 3 4 5 6 7 8 9 10
do
   RUST_BACKTRACE=1 make test-target TARGET=test_get_logs_address
done

Working on a solution.

Hey @greged93 , got a question. I determine that the random failures is because of random data, specifically the numbers that we use for the block_number on the ETH Logs. Here we can see a comparison of the filter used in the MongoDB of a failed test in the left, and a successful test in the right.

As you can see, the block number in the failing test is bigger than the to value of the filter. In the successful test, this is not the case, which makes the MongoDB filter to return logs, as opposed as the initial case where no logs are returned because the block number is bigger than the to value of the filter.

Now that we have determined the cause of the random failure, we need to determine how to fix it.

First, we generate a collection of Logs that we store in a MongoDB collection. The values of the block_number, determined here, is just a an arbitrary u64.

The value of the to  value comes or from this function, which seems to be defined in this crate: alloy_rpc_types::eth::filter.

Since the possible value of block_number is the maximum possible value of a u64, and block_number should never be bigger than the to value, at least for the purpose of filtering logs on this test, to make it deterministic, should to always be the max value of a u64?
For the purpose of the test, can we mock the value than the to value is returning to make sure is in range of the filter?
Or should we make a dynamic assertion depending of the value of to ?

Hey @rvalenciano thanks a lot for you work in debugging this! I think for now you can just use u64::MAX as the value of to in the block range. You can update the tests test_get_logs_topics, test_get_logs_block_range and test_get_logs_address to fix this (I think the test test_get_logs_block_hash is fine since if doesn't use the block range). Again thanks!


Fixed the ordering to what you expected.

This also fixed a minor error I noticed with your ng-show logic. updatePlayer() was never called on first go around. So when you started not on the main kifu screen the button values would be hidden.

Just wanted to leave a final thanks for this item: I really love using this feature now that we've added it. Thanks for all your hard work in making it happen!


YARM silently overwrites existing site if new one has the same automatic name

I went around adding several uranium patches to YARM after setting up the mines, trains, etc. I got very confused when after adding four sites, only two appeared in YARM's list.
Long story short, I had to go back, re-add the missing sites, and rename them as I went because three of the four were getting the same automatically generated name (NW 1253 or similar, due to relative proximity I guess).
It strikes me as odd that YARM silently overwrites existing sites in this manner. The failure mode I expected to find was that YARM had combined them, but that was not the case.
IMO the ideal outcome would be to append "A", "B", etc. to the site name if it conflicts with an entry in the list. But feel free to tell me "Just rename each site as you create them, noob!" :) Though that would be easier if doing so did not require remote viewing the site first. (At least I was not kicked out of my train again, thanks to your fix the other day.)

Yes, this is a problem. It's also reported as #52, so we'll keep that one.

Ach, how did I miss that one? My most profuse apologies for the duplicate report!


Make All Tests Asynchronous

customer: @mariari
performer:
deadline:
estimated:
started:
actual:
completed:
confirmed:
dependencies:

[ ]
supersedes:

We do not have tests which assume synchronicity. We should try to make everything run async. However currently if we make all tests async in the Node, e.g. we encounter the following ETS errors:
* 1st argument: the table identifier refers to an ETS table with insufficient access rights
which can be fixed by making the initialization public rather than protected for the table, yet that then spawn another error regarding inserting non-existent tables.
@m1dnight you probably are the best person to tackle this

The anoma_node application has been addressed here: https://github.com/anoma/anoma/pull/1602
I'm looking at making the other applications concurrent  as well, but those will take some time :)


Added clarifying example of adding PK and compression

I keep coming across users who don't realize that you can add a data compression clause when adding a clustered primary key. Instead, they rebuild the clustered index, after they add it. This is very efficient. I've added a clarifying example to the previous PK example to show that you can do both. I've also changed a few references from AdventureWorks2012 to just AdventureWorks. Having the 2012 in place adds nothing, and just dates the content.

@greglow : Thanks for your contribution! The author, @CarlRabeler, has been notified to review your proposed change.


Subtraction gives incorrect result with zeek tsv formatted input

Subtracting two fields in a put with tsv formatted input gives an incorrect result.
$ zq -version
Version: v0.29.0

Here's a minimal example to reproduce.
$ cat << EOF | zq -f table 'put diff=(orig_bytes-resp_bytes)' -
#separator \x09
#set_separator  ,
#empty_field    (empty)
#unset_field    -
#fields orig_bytes      resp_bytes
#types  count   count
61      81
EOF

Result:
ORIG_BYTES RESP_BYTES DIFF
61         81<PHONE_NUMBER>3709551596

This error seems to be specific to Zeek TSV input format. The same example in JSON format works correctly.
$ echo '{"orig_bytes":61,"resp_bytes":81}' | zq -f table 'put diff=(orig_bytes-resp_bytes)' -

Result:
ORIG_BYTES RESP_BYTES DIFF
61         81         -20

I should note that I discovered this issue while processing Zeek logs captured from a real sensor on real world network traffic. So the issue is present there too, and I can provide larger Zeek logs if needed.
My guess is that the types of the bytes when read in are uints and subtracting them is doing unsigned arithmetic. Here's a link to a Go playground that gives the exact same result:<PHONE_NUMBER>3709551596.
https://play.golang.org/p/D9b6Fv8_47G

@ethack: Thanks for the detailed bug report! indeed, your analysis all seems correct. I'll take up the topic with the Dev team.
You're right that the Zeek count type gets internally treated as an unsigned integer after being read in by zq, since the Zeek docs do say it's an unsigned int. I'm not sure if you've stumbled across it yet, but since you're a Zeek user you might be interested in the doc at https://github.com/brimdata/zed/blob/zed-zeek-updates/zeek/type-compat.md that describes the mappings between the two type systems. (That version of the doc happens to be in a branch associated with a PR I've got under review at the moment because we're checking in changes in prep for an upcoming release. But since any fixes to to your issue are going to land in a future release anyway, I figure I might as well point you at the latest stuff. But in the remainder of this comment I'll focus on how things are at the last GA zq tagged v0.29.0, since I assume that's what you're running.)
You can see this clearly by having zq read the Zeek TSV file and print it back out as ZSON, as it shows the explicit (uint64) [type decorator]($ zq -f zson 'put diff=(orig_bytes:int64-resp_bytes)' example.log  {     orig_bytes: 61 (uint64),     resp_bytes: 81 (uint64),     diff: -20 } (=0)).
$ zq -version
Version: v0.29.0

$ cat example.log
#separator \x09
#set_separator	,
#empty_field	(empty)
#unset_field	-
#fields	orig_bytes	resp_bytes
#types	count	count
61	81

$ zq -f zson example.log
{
    orig_bytes: 61 (uint64),
    resp_bytes: 81 (uint64)
} (=0)

Looking at your JSON example, there we see no explicit type decorator, which is indicative that it's just inferring the type to be a signed integer (specifically int64 per the note about "implied-type values" in the ZSON spec section on Primitive Values). This makes sense since the JSON gives no typing info that would communicate whether or not the field is intended to be treated as signed. (BTW, the thing you see here with the unnecessary use of scientific notation has already been fixed.)
$ echo '{"orig_bytes":61,"resp_bytes":81}' | zq -f zson -
{
    orig_bytes: 6.1e+01,
    resp_bytes: 8.1e+01
} (=0)

While you're waiting on a fix, the good news is that I can offer you a short-term workaround by using type casting to treat one of the values as signed.
$ zq -f zson 'put diff=(orig_bytes:int64-resp_bytes)' example.log
{
    orig_bytes: 61 (uint64),
    resp_bytes: 81 (uint64),
    diff: -20
} (=0)

(Heads-up that the casting notation will be changing in the next release. With current head of main of the Zed repo, this would look like zq -f zson 'put diff:=(int64(orig_bytes)-resp_bytes)' example.log).

Thank you very much for the explanation and the workaround! I didn't know that typecasting was possible and that will work nicely for me.
I know the struggles of inferring types in the different formats of Zeek logs from another project I work on. Ironically, it's usually JSON that usually gives more trouble because of the lack of explicit types, but in this case it actually worked as an advantage :)

@ethack: I did a bit more hacking with this and also talked it over with the Dev team. In brief, it seems unlikely we'll change the default treatment here. I can actually see it both ways, since I totally empathize with how at first the result appears incorrect, but it seems to ultimately become a trade-off as to where you want to be exposed to potential incorrectness. Therefore we'd like to put enough controls in the hands of the user to make it do what they really want, and the casting workaround is one such way. There are others I'll get to below, and there may be more ideas for the future.
First, FWIW, I've confirmed our tooling is not alone in this treatment. Within Zeek scripting itself, using their count type (which is an unsigned 64-bit integer, hence equivalent to Zed's uitn64), the result is the same.
$ cat countmath.zeek
module Hello;

export {
    redef enum Log::ID += { LOG };

    type Info: record {
        orig_bytes:    count &log;
        resp_bytes:    count &log;
        diff_bytes:    count &log;
        };
    }

event zeek_init()
    {
    local orig: count = 61;
    local resp: count = 81;
    local diff: count = orig - resp;
    Log::create_stream(Hello::LOG, [$columns=Hello::Info, $path="hello"]);
    Log::write( Hello::LOG, [$orig_bytes=orig,
                             $resp_bytes=resp,
                             $diff_bytes=diff]);
    }

$ cat hello.log
#separator \x09
#set_separator	,
#empty_field	(empty)
#unset_field	-
#path	hello
#open	2021-05-27-10-56-15
#fields	orig_bytes	resp_bytes	diff_bytes
#types	count	count	count
61	81<PHONE_NUMBER>3709551596
#close	2021-05-27-10-56-15

MySQL actually refuses to do the computation at all and returns an error. Since Zed is designed to sometimes work on streams, I suspect we'd not want to fail completely like this, but perhaps it could catch what happened and still continue, but return a warning? Such a warning could perhaps point the user toward casting as a possible workaround (and we could cover this specific case in the casting docs.)
mysql> CREATE DATABASE mytest;
Query OK, 1 row affected (0.00 sec)

mysql> USE mytest;
Database changed

mysql> CREATE TABLE difftest (
    ->   orig_bytes INT UNSIGNED NOT NULL,
    ->   resp_bytes INT UNSIGNED NOT NULL
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO difftest () VALUES(61, 81);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT orig_bytes,resp_bytes,(orig_bytes-resp_bytes) AS result FROM difftest;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(`mytest`.`difftest`.`orig_bytes` - `mytest`.`difftest`.`resp_bytes`)'

mysql> SELECT orig_bytes,resp_bytes,(cast(orig_bytes as signed)-cast(resp_bytes as signed)) AS result FROM difftest;
+------------+------------+--------+
| orig_bytes | resp_bytes | result |
+------------+------------+--------+
|         61 |         81 |    -20 |
+------------+------------+--------+
1 row in set (0.00 sec)

It would be technically feasible for Zed to just change its default treatment of Zeek count values and store them as int64 rather than uint64, but this is the trade-off I mentioned above. The current treatment leaves the exposure of your diff computation giving a giant, incorrect-looking results like you saw. If we flipped the treatment, now we'd lose the top half of the numeric range, so now what came from Zeek as very large count values might be output from Zed as negative numbers. So it seems to come down to which exposure concerns you more as a user.
The casting workaround gives you a runtime way to make the decision, but I respect it might be a burden to have to do that as part of every query that needs it. Instead you might prefer to just have the fields read and stored with the type treatment flipped. It's not well-documented yet, but here's one way to do this in current zq at the tip of main (i.e. not yet in a GA release):
$ cat shaper.zed
type connbytes={orig_bytes:int64, resp_bytes:int64};
put this:=shape(connbytes)

$ zq -Z -I shaper.zed '| put diff:=orig_bytes-resp_bytes' example.log
{
    orig_bytes: 61,
    resp_bytes: 81,
    diff: -20
}

Of course, that's just laser-focused on your example log record that has only those to fields. A place where this "shaper" concept is typically used more broadly is when importing JSON, since it's so minimally typed. You already picked up on the fact that reading "unshaped" JSON with zq was doing more what you expected since we had no choice but to assume the numeric values might be signed and as large as possible, hence stored them as int64. But JSON's minimal typing causes all kinds of other hazards with Zeek data, since timestamps and IP addresses both become strings, there's no way to tell if a JSON array started life as a Zeek set, etc. So we publish a reference shaper config for Zeek JSON at https://github.com/brimdata/zed/blob/main/zeek/shaper.zed that restores the correct data types for all the fields known to be generated by an out-of-the-box open source Zeek install. If one wanted to make a selective or exhaustive change to how Zeek count values get treated at read time, they could tweak that shaper config to have fields that are currently marked as uint64 stored as int64, then apply that shaper config similar to what I did above.
I still find that a little unwieldy since as soon as you start customizing your Zeek with additional fields generated by Zeek packages, or new fields appear when you upgrade to new Zeek versions, now you'd need to keep that config up to date if you want it to remain 100% correct. That seems an appropriate cost to pay if someone's got all their input data as JSON, since so much of it needs fixing regardless. But if starting from Zeek TSV where 99% of the rich typing can alreadyd be derived accurately, but you might just want to flip the behavior for this one count type, it seems it would be handy to have a way to apply this kind of config per-type rather than per-named-field. That's still a topic being discussed on this end.
I'd be interested to hear your reactions as a user to any of the above.

I really appreciate the response and the surrounding discussion. I'll have to give this some more thought, but here is my first reaction.
I completely understand the viewpoint that the math on unsigned ints isn't actually the wrong thing to do as those are the native datatypes from Zeek. And if I were in a programming mindset at the time I would have realized that typecasting would be the way to go and would have looked for that option in the documentation.
I would call myself a programmer, though it is not my day job. I have a computer science degree and experience with signed/unsigned math in both C++ and Go. So I certainly know how to think in code, but, even with that background, when I'm using a tool like zq my mindset isn't were I even realize that datatypes and signed/unsigned arithmetic is something I should be concerned about. This was actually my second look at this problem with zq as the first time when I was getting unexpected results I just reached for a different tool and got the result I wanted.
For reference, what I was attempting to do was calculate a producer-consumer ratio calculation, which can range from -1.0 to 1.0. With typecasting, it works quite well with zq and I wouldn't be surprised if others discover this use case as well. Here's a full example:
$ cat conn.log | zq -f table 'sum_orig=sum(orig_bytes:int64),sum_resp=sum(resp_bytes:int64) by src=id.orig_h,dst=id.resp_h,port=id.resp_p | put pcr=(sum_orig-sum_resp)/(sum_orig+sum_resp+0.001)' -

So for me, with a programming background, if I were given hints that I need to pay attention to the underlying datatype and shown how to typecast that would be enough for me. But I'm not sure if someone with a non-programming background would have the same experience.
These are the places in the documentation I'd expect some reference to datatypes in expressions:

https://github.com/brimdata/zed/blob/main/docs/language/expressions/README.md
https://github.com/brimdata/zed/blob/main/docs/language/operators/README.md#put

I also understand why Zeek TSV and JSON behave differently. But as a user I value consistency between formats over technical correctness for extreme cases. One of the great benefits of zq for me is how it can handle both formats without needing to change my workflow or parse them differently. (Switching between zeek-cut and jq is painful :smile:) If I have to worry about the differences between formats again then zq loses some of its utility for me. I like the idea of the reference shaper file for JSON that you have as I think that would bring consistency for most cases. Personally, I'd want that to be the default for JSON and not have to use zq -I shaper.zed. But as long as the documentation is there to inform me this is a thing I might need, I can set it up at install time and make an alias and not have to worry about it again.

@ethack: Thanks for sharing the thoughts. It's spawned some nice discussions on this end. In this regard, we have created two issues for our backlog (#2777, #2778) that will hopefully help future generations not struggle as much if they bump into this.
Your thoughts on where the better coverage should be in the docs is spot-on. We're due to make some updates to those, so we'll definitely make sure there's better coverage as part of those updates. In addition, the topic of whether or not users should have to think like programmers is something we've debated as well. We've had this philosophy we call "the gentle slope of Zed", i.e. that users who don't think like programmers should be able to look at the Search bar in Brim more like a web search and not have to worry about things like data types and overflow if all they want to do is simple searches, but that if they do want to start using expressions/analytics, we'd want to advise them early that they'll probably want to review some of the relevant docs so they don't run into surprises, such as happened to you. So we're now thinking of the best way to point that out to users early without scaring off the ones who could still be content with never having to learn it if it's not required for what they want to accomplish.
Your point about "consistency between formats" is certainly valid, but we have aspirations to make zq applicable well beyond just Zeek, so it seems doubtful that we'd "lock in" any one shaper config out-of-the-box. In this regard your proposed approach of using a shell alias is probably the best approach for now, though we do have an issue #1059 to allow the Zed tooling to have its own way for persisting common default configs. Even if zq is not just for Zeek, I agree that it's essential to make sure Zeek users know the shaper option exists, and I have some Zeek-related docs to update as tracked in #2594 so I've made a note-to-self to emphasize this point.
As I think our future work is now tracked in other granular issues, I'd be inclined to close this specific issue and let the others live on, but I think your feedback here will live on as a handy reference to think about how different kinds of users might approach the tools. I'll hold this one open a bit in the event you have any other thoughts to share before I close. Thanks for all the input!

Thanks a lot for all the explanation and the relevant issues to track. I'm looking forward to the doc updates and hearing someday about your aspirations beyond Zeek!
I have no problems with closing this issue.


Horizontal List view not working inside vertical ListWheelScrollView in Flutter

Content is rendered perfectly if there is single item but as soon as we try to fit carousel as one of the child of ListWheelScrollView, it doesn't understand the horizontal swiping.
This code works if used normal list view with normal ScrollController()
My requirement is to show the nearest child of list if user scrolls in between position so using FixedExtentScrollController
Scroll Controller used is fixed one FixedExtentScrollController() with below ListWheelScrollView
Widget build(BuildContext context) {
    return SizedBox(
      height: MediaQuery.of(context).size.height,
      child: ListWheelScrollView.useDelegate(
        itemExtent: MediaQuery.of(context).size.height * 0.87,
        perspective: 0.001,
        physics: const FixedExtentScrollPhysics(),
        controller: scrollController,
        childDelegate: ListWheelChildBuilderDelegate(
          childCount: data.length,
          builder: (BuildContext context, int index) {
            return iStreamWidget.render(data[index]);
          },
        ),
      ),
    );
  }

Horizontal list view
Container(
      height: height * 0.88,
      padding: const EdgeInsets.symmetric(
        horizontal: 20.0,
        vertical: 35.0,
      ),
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.start,
        children: [
          _buildTitle(carouselPostModel.title, postModel.postFontType, context),
          Expanded(
            child: SizedBox(
              width: double.infinity,
              child: ListView.separated(
                  itemCount: descriptionList.length,
                  scrollDirection: Axis.horizontal,
                  shrinkWrap: true,
                  physics: const BouncingScrollPhysics(),
                  itemBuilder: (BuildContext context, int index) {
                    return _buildCard(
                      imageUrls[index],
                      descriptionList[index],
                      postModel.postFontType,
                      context,
                    );
                  },
                  separatorBuilder: (index, context) {
                    return const SizedBox(
                      width: 10.0,
                    );
                  }),
            )
          ),
        ],
      ),
    );

@agharshit08
Can you provide flutter doctor -v, a complete minimal code sample that we can directly run to verify the reported behavior along with expected result that you are looking to achieve ?
Also, see this link for your reference and check if it helps in your case.


Add support for tiled search.

Rather than a limit based on a count, the limit is filled when the coverage of the found items covers the entire tile.

will this tiled search support different rules for determining when the limit is reached (ex. first, last, all etc.)


Extensions: support developing Rancher Desktop extension

Provide support for developing Rancher Desktop as an extension with @rak-phillip

TODO

[ ] #9477

Related Issues

rancher-sandbox/rancher-desktop#2822
Original issue: rancher/dashboard#9070
Structure for routes and navigation https://github.com/rancher/dashboard/issues/9307

Related PRs

https://github.com/rancher/dashboard/pull/9279 -> add ability to override layouts in shell
PR for 9307: https://github.com/codyrancher/rancher-desktop/pull/1

This will be expanded as the extension task force and @rak-phillip hammer out what work is required in separate tickets.
This is somewhat independent on pure Rancher milestones since it ties more into Desktop. Will move to Q4 from a tracking perspective but this should be worked on in parallel with existing dashboard releases.

I created a high-level punch list for what the offline mode needs to support in #9477


[Astro] resource and signal rendering is mixed up on the client

Describe the bug
I'm rendering a resource and a signal:
  return (
    <>
      resource: {data()}

      signal: {isMounted() ? 'yes' : 'no'}
    </>
  );

But in Astro, the resource gets render output is:
resource: nopesignal: nonope
signal: yes

Your Example Website or App
https://stackblitz.com/edit/github-pqy8j7-3kzkkj?file=src%2Fcomponents%2FPage.tsx
Steps to Reproduce the Bug or Issue

Expected behavior
In pure SolidJS, the output is correct:
resource: nope
signal: yes

Screenshots or Videos
No response
Platform
Windows, Chrome 123
Additional context
No response

One solution is: wrap data with span
    resource: {data()}

    signal: {isMounted() ? 'yes' : 'no'}

I swore I fixed this top level fragment issue. And I had but I missed a case where it resolves for the first time under a Suspense boundary.


Prometheus: adding instance and mtls

I'm working on adding instance and mtls to Prometheus.
In my local .env, Prometheus was working in my VPN. The only things I changed are commited here, but now I get "Bad Gateway". I'm testing with Prometheus in my VPN but I don't have any sentry authentication in front of it.
There don't appear to be any errors in Prometheus' logs, but this is in Traefik's log:
traefik-1      | time="2024-06-06T01:04:43Z" level=error msg="sourceRange is empty, IPAllowLister not created" entryPointName=websecure routerName=prometheus-default-prometheus@docker

But I have PROMETHEUS_METRICS_IP_SOURCERANGE="<IP_ADDRESS>/0" in my .env and Traefik seems to see the IPAllowList value:

@EnigmaCurry, I think this works and is ready to merge.

I think maybe you forgot to push.

I think maybe you forgot to push.

Hmmm, I see the changes I pushed a few dayes ago here in the PR.


Workflow persist optimize - Auto persist, Clear stack, Delete

This PR optimizes the workflow persist feature.

clears the undo stack and redo stack when switching workflow.
auto-persists the workflow into the database upon change on the content or name. Currently, only the latest version of the workflow is saved.
adds a status label on the navigation bar to indicate the auto-persisting status.
implements a simple workflow delete logic.
fixes an issue where workflow loaded by id can't be executed.

Changes explained:

WorkflowCacheService(renamed from cachedWorkflowService)'s task is to maintain the frontend cache of the workflow. So whenever the user refreshes the page, the previously-worked-on workflow can be reloaded from localStorage.
WorkflowPersistService is responsible for saving the workflow into the backend. So when a user changes browser or machine, he/she can retrieve the previously-saved workflow.
WorkflowCacheService and WorkflowPersistService are designed to be parallel and independent from each other. They do a sync to maintain workflow status. WorkflowCacheService is always enabled, and WorkflowPersistService is enabled with the userSystemEnabled flag.
Right now only the latest version of a workflow is persisted in the database. In the future, this could be changed to periodically save a snapshot of the workflow, and the user can retrieve any previous version of it.

Proposal:

Separate the navigation bar component into sub-components, as it not only contains navigation now.

Demo:

save 1st workflow with cached workflow

create a 2nd workflow and save it

delete a workflow and switching workflow will clean undo-redo stack

Also please add a gif, there are many apps you can use, like
https://giphy.com/apps/giphycapture
https://getkap.co/?ref=producthunt

Also please add a gif, there are many apps you can use, like
https://giphy.com/apps/giphycapture
https://getkap.co

added

closed #918


Include "or stopped/deallocated"

Customers lose these dynamic IPs all the time when they just stop a VM. Would like to have this documented for reference.

@jolleymd,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@jolleymd : Thanks for your contribution to the Azure documentation! The author, @azdocprs, has been notified to review your proposed change.

@telmosampaio - Please review these proposed changes. Thanks

Please indicate if there is a reason this has not been merged.
Michael Jolley
Azure Networking Support

@jolleymd I agree with the issue, customer concern, and changes. Sorry that this has not already been addressed.
#sign-off


Revert keydown to hide beep.

reviewer: @amjith

Thanks for fixing that beep.

I've edited your comment to remove the profanity and replace it with the word beep. Thank you for understanding.


Remove usage of private git repo

In the Podfile you currently have:
source 'https://gitlab.rambler.ru/cocoapods/cocoapods.git'

@wiruzx Hi, thanks for reporting!
We are working on this issue - currently you can build the project without running pod install - the Pods directory is included in the repo.

The bug is fixed.


Pubish Apps to Sandbox recently fails sometimes

Describe the issue
We are using the function Publish-PerTenantExtensionApps in our Scripts to automate Publish new App versions to SaaS Environments. There are recently some Problems with the result of the Function.
The strange thing is, that sometimes we can publish without any Problems and sometimes the Error occurs.
In both Cases the App will be uploaded and also installed.
Are we missing any Params for the function or is there a known issue of my problem?
The Problem occurs also on different Environments but that can be a result of sharing the same Powershell Library and using the same script with different Params for our function.
Scripts used to create container and cause the issue
we just created a basic Powershell function to use the Function
function Import-BCAppsToSaaS {
    [cmdletbinding()]
    param (
         [string]$Path,
         [Hashtable] $bcAuthContext,
         [string]$environment
    )

    $bcAuthContext = Renew-BcAuthContext -bcAuthContext $bcAuthContext
	Publish-PerTenantExtensionApps -bcAuthContext $bcAuthContext -environment $environment -appFile $Path
}

Full output of scripts
Company  has id XXXX-XXXX-XX-XXX-XXXXX
Extensions before:
 - AMC Banking 365 Fundamentals, Version 21.4.52563.52836, Installed=True
 - API Reports - Finance, Version 21.4.52563.52836, Installed=True
 - Application, Version 21.4.52563.52836, Installed=True
 - Base Application, Version 21.4.52563.54065, Installed=True
 - Business Central Cloud Migration - Previous Release, Version 21.4.52563.52836, Installed=True
 - Business Central Cloud Migration - Previous Release (DE), Version 21.4.52563.52836, Installed=True
 - Business Central Cloud Migration API, Version 21.4.52563.52836, Installed=True
 - Business Central Intelligent Cloud, Version 21.4.52563.52836, Installed=True
 - Company Hub, Version 21.4.52563.52836, Installed=True
 - Contoso Coffee Demo Dataset, Version 21.4.52563.52836, Installed=True
 - Contoso Coffee Demo Dataset (DE), Version 21.4.52563.52836, Installed=True
 - Data Archive, Version 21.4.52563.52836, Installed=True
 - Data Search, Version 21.4.52563.52836, Installed=True
 - ELSTER VAT Localization for Germany, Version 21.4.52563.52836, Installed=True
 - Email - Current User Connector, Version 21.4.52563.52836, Installed=True
 - Email - Microsoft 365 Connector, Version 21.4.52563.52836, Installed=True
 - Email - Outlook REST API, Version 21.4.52563.52836, Installed=True
 - Email - SMTP API, Version 21.4.52563.52836, Installed=True
 - Email - SMTP Connector, Version 21.4.52563.52836, Installed=True
 - Essential Business Headlines, Version 21.4.52563.52836, Installed=True
 - Intelligent Cloud Base, Version 21.4.52563.52836, Installed=True
 - Intrastat Core, Version 21.4.52563.52836, Installed=True
 - Intrastat DE, Version 21.4.52563.52836, Installed=True
 - Late Payment Prediction, Version 21.4.52563.52836, Installed=True
 - customApp, Version <IP_ADDRESS>, Installed=True
 - Payment Links to PayPal, Version 21.4.52563.52836, Installed=True
 - Recommended Apps, Version 21.4.52563.52836, Installed=True
 - Sales and Inventory Forecast, Version 21.4.52563.52836, Installed=True
 - Send To Email Printer, Version 21.4.52563.52836, Installed=True
 - Service Declaration, Version 21.4.52563.52836, Installed=True
 - Shopify Connector, Version 21.4.52563.52836, Installed=True
 - Simplified Bank Statement Import, Version 21.4.52563.52836, Installed=True
 - System Application, Version 21.4.52563.52836, Installed=True
 - Troubleshoot FA Ledger Entries, Version 21.4.52563.52836, Installed=True
 - Universal Print Integration, Version 21.4.52563.52836, Installed=True
 - WorldPay Payments Standard, Version 21.4.52563.52836, Installed=True

customApp_<IP_ADDRESS>.app - upgrading...ERROR Der Server hat eine Protokollverletzung ausgeführt.. Section=ResponseStatusLine
bei <ScriptBlock>, C:\Program Files\WindowsPowerShell\Modules\BCContainerHelper\4.0.14\Saas\Publish-PerTenantExtensionApps.ps1: Zeile 173
bei <ScriptBlock>, C:\Program Files\WindowsPowerShell\Modules\BCContainerHelper\4.0.14\AppHandling\Sort-AppFilesByDependencies.ps1: Zeile 176
bei Sort-AppFilesByDependencies, C:\Program Files\WindowsPowerShell\Modules\BCContainerHelper\4.0.14\AppHandling\Sort-AppFilesByDependencies.ps1: Zeile 175
bei Publish-PerTenantExtensionApps, C:\Program Files\WindowsPowerShell\Modules\BCContainerHelper\4.0.14\Saas\Publish-PerTenantExtensionApps.ps1: Zeile 116
bei Import-BCAppsToSaaS, D:\devops\agent1\_work\180\PowershellTools\Scripts\Import-BCAppsToSaaS.ps1: Zeile 70
bei <ScriptBlock>, D:\devops\agent1\_work\_temp\e0012e53-947f-4c72-b1ba-c4651624b8ae.ps1: Zeile 32
bei <ScriptBlock>, <Keine Datei>: Zeile 1

Extensions after:
 - AMC Banking 365 Fundamentals, Version 21.4.52563.52836, Installed=True
 - API Reports - Finance, Version 21.4.52563.52836, Installed=True
 - Application, Version 21.4.52563.52836, Installed=True
 - Base Application, Version 21.4.52563.54065, Installed=True
 - Business Central Cloud Migration - Previous Release, Version 21.4.52563.52836, Installed=True
 - Business Central Cloud Migration - Previous Release (DE), Version 21.4.52563.52836, Installed=True
 - Business Central Cloud Migration API, Version 21.4.52563.52836, Installed=True
 - Business Central Intelligent Cloud, Version 21.4.52563.52836, Installed=True
 - Company Hub, Version 21.4.52563.52836, Installed=True
 - Contoso Coffee Demo Dataset, Version 21.4.52563.52836, Installed=True
 - Contoso Coffee Demo Dataset (DE), Version 21.4.52563.52836, Installed=True
 - Data Archive, Version 21.4.52563.52836, Installed=True
 - Data Search, Version 21.4.52563.52836, Installed=True
 - ELSTER VAT Localization for Germany, Version 21.4.52563.52836, Installed=True
 - Email - Current User Connector, Version 21.4.52563.52836, Installed=True
 - Email - Microsoft 365 Connector, Version 21.4.52563.52836, Installed=True
 - Email - Outlook REST API, Version 21.4.52563.52836, Installed=True
 - Email - SMTP API, Version 21.4.52563.52836, Installed=True
 - Email - SMTP Connector, Version 21.4.52563.52836, Installed=True
 - Essential Business Headlines, Version 21.4.52563.52836, Installed=True
 - Intelligent Cloud Base, Version 21.4.52563.52836, Installed=True
 - Intrastat Core, Version 21.4.52563.52836, Installed=True
 - Intrastat DE, Version 21.4.52563.52836, Installed=True
 - Late Payment Prediction, Version 21.4.52563.52836, Installed=True
 - customApp, Version <IP_ADDRESS>, Installed=True
 - Payment Links to PayPal, Version 21.4.52563.52836, Installed=True
 - Recommended Apps, Version 21.4.52563.52836, Installed=True
 - Sales and Inventory Forecast, Version 21.4.52563.52836, Installed=True
 - Send To Email Printer, Version 21.4.52563.52836, Installed=True
 - Service Declaration, Version 21.4.52563.52836, Installed=True
 - Shopify Connector, Version 21.4.52563.52836, Installed=True
 - Simplified Bank Statement Import, Version 21.4.52563.52836, Installed=True
 - System Application, Version 21.4.52563.52836, Installed=True
 - Troubleshoot FA Ledger Entries, Version 21.4.52563.52836, Installed=True
 - Universal Print Integration, Version 21.4.52563.52836, Installed=True
 - WorldPay Payments Standard, Version 21.4.52563.52836, Installed=True
Publish-PerTenantExtensionApps Telemetry Correlation Id: f3b241bc-8e33-43df-94f4-e169b3c9690e
##[error]Der Server hat eine Protokollverletzung ausgeführt.. Section=ResponseStatusLine
In C:\Program Files\WindowsPowerShell\Modules\BCContainerHelper\4.0.14\Saas\Publish-PerTenantExtensionApps.ps1:221
Zeichen:13
+             throw (GetExtendedErrorMessage $_)
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Der Server hat ...ponseStatusLine:String) [], RuntimeException
    + FullyQualifiedErrorId : Der Server hat eine Protokollverletzung ausgeführt.. Section=ResponseStatusLine

Additional context

It sometimes occurs but i cant recognize patterns there
in the past it worked without any problems. The first time it occurs was the 22. Februrary

Was the app installed/upgraded?
I am asking in order to learn whether the problem is during getting the install/upgrade status - or whether the problem actually occurs when trying to install/upgrade

We recently also have issues when publishing from vscode. It seems like the sandboxes are generally less reliable then they used to be. Somethings publishing an app takes 10 min.

Until now we only faced the Issue during upgrade the App.
I will try to reproduce the Problem while publishing a new App to the Sandbox.

We face the issue using Devops Release Pipeline with outbound Powershell.

Does this problem still occur?
Does anybody have a good repro?

Hi Freddy below the error Message still showing up
"appname_<IP_ADDRESS>.app - publishing and installing...ERROR The server committed a protocol violation. Section=ResponseStatusLine
at , C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\5.0.3\Saas\Publish-PerTenantExtensionApps.ps1: line 175
at , C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\5.0.3\AppHandling\Sort-AppFilesByDependencies.ps1: line 185
at Sort-AppFilesByDependencies, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\5.0.3\AppHandling\Sort-AppFilesByDependencies.ps1: line 184
at Publish-PerTenantExtensionApps, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\5.0.3\Saas\Publish-PerTenantExtensionApps.ps1: line 118
at , D:\ProgramData\Agentpool\agent-1_work\r7\a_Azure Pipeline\application\scripts\Release\Release_Pipeline_Cloud.ps1: line 17
at , D:\ProgramData\Agentpool\agent-1_work_temp\a8fd1acb-451e-4a3f-92af-a5b5a40860a5.ps1: line 4
at , : line 1"

Hey Freddy,
i was able to check the different circumstances. Here is what I noticed so far.
Publish in a fresh Environment

1x Time work without Problem.
2x I had the Problem above
Publish in a Environment where it the App already exists and had to be upgraded
6x Time work without Problem.
8x I had the Problem above

I also saw one time that the App Upgrade was started at the same time to the Production and the Sandbox Environment. The Upgrade in the Sandbox failed and the Upgrade in the Production had no Problems. A few days later it was the opposite.
To temporary handle the Problem we changed our Pipeline and set the "retryCountOnTaskFailure" in the Pipeline. If any Error  occurs while Upload the App, a Delay will start, before the next Retry. So the Script will try again after a few Minutes and see that the right Version is already installed. But thats hopefully only a temporary Solution for the Problem.
I hope that can help you.
If you need any further informations let me now.

Thanks
Would it be possible to get the apps you are publishing to see whether I can repro using your script above?

if i remember correctly it occurs randomly and only with a local Agent. When using an Azure Agent there is no problem.

For AL-Go projects, you could try to set:
"runs-on": "ubuntu-latest",
"gitHubRunner": "self-hosted",
"gitHubRunnderShell"; "powershell"

in .github/AL-Go-Settings.json
and run Update AL-Go System Files.
This would cause you to use self-hosted runners for the time consuming build job, but GitHub hosted Linux runners (cheap and fast) for the rest.

For AL-Go projects, you could try to set:
"runs-on": "ubuntu-latest",
"gitHubRunner": "self-hosted",
"gitHubRunnderShell"; "powershell"

in .github/AL-Go-Settings.json
and run Update AL-Go System Files.
This would cause you to use self-hosted runners for the time consuming build job, but GitHub hosted Linux runners (cheap and fast) for the rest.

Hi Freddy do you have some setting suggestions for while using Devops ?

@Pomaroli - that all depends on the solution/script you are using on DevOps.
AL-Go has a lot of functionality, which is controlled by settings - this is not GitHub or Azure DevOps functionality.

Okey i understand, we not using AL-Go for now maybe in future. We are using Azure Devops and i developed myself Build and Release Pipelines based on YAML and Powershell. To Compile and Test the AL-Source code we use Docker Instance's. After the App is compiled sucessfully we deploy using the In-Build Release-Pipeline functionality of Azure Devops with Powershell.  Basically we authenticate against BC Online an den Deploy PTE nothing special there.

@freddydk sorry for the late response.
I forgot that there is also the Al-Go Project on GitHub. I just wanted to tell you that I just created in VS-Code a basic project with the function AL-GO. So there is an app initiated with the Page Extension on CustomerListExt with the "Hello World" Messagebox.
I had the same problem uploading this basic app with one Page extension to my Saas Environment. For the moment, I extended our pipelines so that the PTE-Upload retries after a delay of 5 minutes. Afterward, the app is published, and no app will be uploaded again.
So at the moment, I tried the first install and also upgraded over self hosted Agents. The problem still sadly occurs.
Any other suggestions on what I can try? If you need any further information let me know.

@freddydk
This problem still bothers us.
Especially when we try to deliver more than one App into the Cloud and the Problem occurs at every App.
Any Updates on this topic?

@HeWessel - did you try to switch to GitHub or Azure DevOps hosted runners to see whether this solves the issue?
I will grab the sample you provided last and make some tests with that to see if I can repro.

Hi There, @freddydk did you changes something ? Since some days it seems do work fine now. Anybody else noticed some new behaviour ?
2024-01-10T09:26:38.7571725Z xy.app - upgrading....................completed

I didn't - maybe they fixed something in BC online to solve this

It did it again, sometimes it doesn't work. I haven't figured out what the connection is yet

Finally... - I was able to get a repro of this problem - and I saw exactly the same protocol violation problem.
In 6.0.26 I added some resilience to Publish-PerTenantExtensionApps to handle this special situation.


SNOW-1096894: Calling multiple registered models in snowsql returns NULL output for all but the first model

Suppose I have registered models m1, m2 and m3 in the core db under the schema models.
The following query will return NULL for the second and third predict call:
SELECT
    id,
    core.models.m1!predict(a,b,c,),
    core.models.m2!predict(a,b,c,),
    core.models.m3!predict(a,b,c)
FROM features

Note that calling the models independently in a query produces correct results and switching the order of the model call also changes which model produces a non-null output. It is always the first one.

To update this:
I've done a bit more testing and it appears that this does not generically return NULL.
Instead what seems to happen is that the first model is called three times per row instead of three different models one time.
This means that if you try to extract differently named outputs of the returned json, the return of the second and third model call will return null.
So as a minimal example:
SELECT core.test.model1!predict(0.1,0.1,0.1),
        core.test.model2!predict(0.1,0.1,0.1);

will return identical values, even if calling the model 2 separately will return a different value to model 1.

Sorry for late reply. Given it is consistently reproducing for you with same signature functions, would you please confirm if you observe the same between two versions of same model? That is, store model2 as new version V2 inside model1 while keeping original as default version in model1 and call like:
WITH model2 AS model1 VERSION V2
    SELECT mv!predict(0.1,0.1,0.1), model1!predict(0.1,0.1,0.1);

Just to update @adaykoth - We are still investigating this issue. I tried this and the resolution seems to be ok. We will keep you posted if we discover something
<EMAIL_ADDRESS>current_date(),mydb.myschema.mod1!snore(1),mydb.myschema.mod2!snore(1),mydb.myschema.mod3!snore(1) from (select 1);
+----------------+-----------------------------+-----------------------------+-----------------------------+
| CURRENT_DATE() | MYDB.MYSCHEMA.MOD1!SNORE(1) | MYDB.MYSCHEMA.MOD2!SNORE(1) | MYDB.MYSCHEMA.MOD3!SNORE(1) |
|----------------+-----------------------------+-----------------------------+-----------------------------|
| 2024-03-05     | [                           | [                           | [                           |
|                |   "my model1 - Zzz"         |   "my model2 - Zzz"         |   "my model3 - Zzz"         |
|                | ]                           | ]                           | ]                           |
+----------------+-----------------------------+-----------------------------+-----------------------------+

Hi @adaykoth fyi the team is actively working on the fix.

Hi @adaykoth ,
We have identified the root cause and implemented the fix in the just released 1.4.0 version. You need to upgrade and re-log your model so that they could work in the same query. We are closing this issue, however, if you have any problems or find this issue still exists, please reopen it. Thank you for your support!


introduce modularity in our playbooks

Purpose
In #175 we want to execute a task depending on a context and specific to an app. So we need to be able to execute tasks that are "application centric".
Proposal
Create a "hook" system. Tasks can live in the application folder and will be executed if they follow a pattern we choose. You should create a hooks folder and then in it files with the name of the hook you want to implement. For example for the hook vaults_created you should create this file for the forum application: apps/forum/hooks/vaults_created.yml

[x] create tasks to execute hooks
[x] example how to use them

This PR is a POC and I'm open to discuss about what can be implemented


IGAPP-203: Add and fix flow types for react-i18next (native)

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.
Will do web in a separate PR. I think it is quite nice that we have correct types everywhere now :tada:

Nice PR! All these type fixes are just because of withTheme, right?
We should think about upstreaming that one such that the community can benefit

Mainly because of withTranslation from react-i18next. If we want to upstream it we'd have to put more effort in the type definitions I guess. I'll look into it.


Deferred Transactions need to be Scheduled by Producers

at start of each block deferred transactions should be scheduled for up to 20ms.
scheduled after delivery of on block header message.

merged in PR #1911


Fix displaying the Linux SQL Instances by default

Unfortunately I missed this in #338 which has made the page quite wide by default, this fixes that by adding them to the default display filter list.

No worries - I've actually got the change made locally and am just tweaking a few more things before pushing. Thanks for this though :D


extension has snot worked for  nearly 2 weeks

Describe the bug
问题描述
A clear and concise description of what the bug is.
To Reproduce
如何复现
Steps to reproduce the behavior:

Go to  duckduckgo or Google search bars
Click on  ' type in  query'
Scroll down to '.ChatGptBox in manual mode.
See error
there is no error.. does not output.
Expected behaviour
*should output to browser sidebars..  **
A clear and concise description of what you expected to happen.

Screenshotsn/a not  required .
截图说明
If applicable, add screenshots to help explain your problem.
Please complete the following information):
请补全以下内容

OS: [e.g. Windows] win 11 64 ..

Browser: [e.g. chrome, safari] Versjon 122.0.6261.95 (Offisiell delversjon) (64-bit)

Extension Version: [e.g. v2.0.2]

Additional context
其他
Add any other context about the problem here.

Have you tried v2.5.0? I'm waiting for chrome store review

I can see many new ws responses in the Web Developer Tools, but the plugin show me "Waiting for response..."

Hi Jos, I'm still experiencing the 'Waiting for response...' issue with ChatGPT Web. I'm using version 2.5.0.

Please try the methods mentioned here: https://github.com/josStorer/chatGPTBox/issues/627#issuecomment-1980686629

Please try the methods mentioned here: #627 (comment)

This dosent work

try v2.5.1

This is what worked for me.

Open chat.openai.com in browser
Hit F12 and open Console in developer tools
Open ChatGPT Box extension popup
Send a couple of messages to the ChatGPT web page with cosole and GPTBox both open
Send messages to extension, you should get responses now

After doing this the extension responds to my messages.
I have to redo this process every time I restart the browser but it does work.
I'm using Firefox so it might be different for other browsers.

Problem:

Problem:

Open https://chat.openai.com/ and try again


'splitscroll' option is subjective

Problem:	'splitscroll' option is subjective.
Solution:	Replace with 'splitkeep' option that provides an option to keep the relative cursor position, screen lines or topline the same.
@brammool I think some user feedback on this patch is warranted(is keeping the topline useful?) although now that I went through the trouble of making the option non-boolean we might as well include it. I first wanted to keep the option simple but I can see how some users might prefer to keep the topline the same instead, and the change required turned out not to be too involved.
@ychin does 'set splitkeep=topline' behave as you would expect with this patch?

Yes! This is exactly what I was hoping for. Thanks a lot for spending the time on this. Playing around with this more, I can definitely see why some people may want splitkeep=screen (or even the original splitkeep=cursor), but to me the new splitkeep=topline is still probably what I prefer the most, since it seems to be the least surprising to me and most "stable" (in its own way).


RTL support

How can use for RTL text?

I haven't tested it for RTL text but I think it will need more tweaks.

just add these lines to xml tag :
android:gravity="right" android:textDirection="rtl"

just add these lines to xml tag :
android:gravity="right"
android:textDirection="rtl"


fix: should not start k8s-restart-job when reboot is needed for windows gpu

What type of PR is this?
/kind bug

What this PR does / why we need it:
should not start k8s-restart-job when reboot is needed for windows gpu
Which issue(s) this PR fixes:

Fixes #
Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2285

Relevant Lines:
2881

💛  - Coveralls


Segmentation Component - Ability to Clone a Segment when adding more segmented content to a page

Can segmentation component have a similar capability as native Targeting where the contents of a segment (say default segment) gets copied over every time author adds a new segment?
With the current Segmentation component (based on Tabs component), when we add segments, it adds a new tab with a component of our choice but there is no option to clone the contents of a previously added tab. This means that - even though author wants to do minor tweaks to the content based on the Segment, they have to re-author all the components.
It would be really beneficial for the authors if Segmentation Component can be extended to provide this capability.

Internal reference SITES-7909

Maybe one option would be to enhance the childreneditor for panels with a cop'n paste option. TBD with product management.  https://xd.adobe.com/view/20df175b-e251-430b-aaf2-5c06a9fb5ad1-758c/
@gabrielwalt

The PR in #233 will add a new clone button to the Segment Editor


Fix expose well-formedness check

Just a small bug fix + test for a forgotten ? in expose wf check.
I'm not sure where to put the tests, there's not really a structure in minitest/src/tests, so I created a new file and put the test in there.

Good catch!

there's not really a structure in minitest/src/tests

It's a bit chaotic, yes. If you have ideas for how to clean it up, I am all ears. :)
There seem to be no existing tests for expose so yeah this location makes sense.

@RalfJung I've updated this PR :)

Thanks!


fix bug introduced in #52 fix

seems I introduced a bug in PR #52. See if this fix makes sense.
there's another small fix with "query timed out" err handling, please review

Thanks for the fix. I handled the query timeout problem you fixed a bit differently, so I merged the lookup fix in separately here: https://github.com/feross/bittorrent-dht/commit/65497554b55c2fd166518fdda0c8277d095d89f7

Released as 3.0.0.


Add checks for Foldable

I think Foldable is technically lawless, but these look like good properties to have even if they're not officially required. Thanks!

I thought it had laws because http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Foldable.html states that

Foldable instances are expected to satisfy the following laws:
foldr f z t = appEndo (foldMap (Endo . f) t ) z
foldl f z t = appEndo (getDual (foldMap (Dual . Endo . flip f) t)) z
fold = foldMap id

and

If the type is also a Functor instance, it should satisfy
foldMap f = fold . fmap f

Oh, right. I'll remove it.


[Question]how to set redis get command timeout

I've meet a problem several times. redis.get cost much time, more than 1s (even more than 1 minute)
This is a terrible online disaster, so i want to know how to set timeout of get command.
Or what could cause redis cost so much time?

Could you tell me more about your setup and the code that is causing this delay? Is the server remote or local? Is this your first call to Redis in your script after a restart?
This is very unusual - Redis usually takes ~1ms to do a simple operation (like get). I would be surprised if this is actually a node_redis problem and more likely something to do with your environment and how Node is communicating (or not) with your Redis server.

server is remote, but in the same IDC. Most of the time, it only takes ~1ms, but this >1s situation came about 1time/4-5months, and continue ~ 1 minute

server is remote, but in the same IDC. Most of the time, it only takes ~1ms, but this >1s situation came about 1time/4-5months, and continue several seconds.
i have 4 redis servers, each key will hash to one of them, and then redis.get(This caused delay).
Our service has about 500,000,000+ requests one day, and each redis server has 10000+ operation per second on the rush hour.
The server is usually stable running, this problem appears suddenly, and disappears a few seconds later.

It's hard to say, but I would venture it is actually not a node_redis issue from what you're telling me - I can't think of a thing in the project code that would cause a stable service to take that long. I'm guessing that it has to do with something busy on the server (redis or node).
As far as a timeout, I don't think there is anything in the project to set a specific timeout for a single command. It could be done in your app - perhaps with a closure and a setTimeout - run the setTimeout and the get at the same time, then use a variable to see which one has completed first. It's definitely a hack, but it could work.

I got around to writing a gist on how to do a timeout for a redis command:
https://gist.github.com/stockholmux/3a4b2d1480f27df8be67#file-timelimitedredis-js
@cekimy Can we close this issue since it's seems more like a redis server stall issue and there is a non-library way of addressing the issue?

@stockholmux ok, thanks very much, I'll try this gist.

i still have this problem, when the network between node server and redis server has problem, redis.get will cost  hundreds seconds.
see our monitor: mostly it takes avg/1ms

this is my simple code:

redis.js

var redis = require("redis"), h = null;
var client = redis.createClient(6379, '<IP_ADDRESS>', {enable_offline_queue: false, retry_max_delay: 100});

addListener(client, 'error', null);
addListener(client, 'connect', client);

function addListener(handler, evt, value) {
    handler.on(evt, function() {
        h = value;
    });
}

var puppet = {
    'get': function(key, callback) {
        if (h === null) {
            //reporting error
            callback("redis error", null);
        } else {
            h.get(key, callback);
        }
    },
    //other commands
};

module.exports = puppet;

app.js

var http = require('http');
var redis = require("redis.js");

http.createServer(function (req, res) {
    //...
    var t1 = Date.now();
    redis.get('key', function(err, reply) {
        var t2 = Date.now();
        monitor("time_redis", t2 - t1);     //this is reporting to above pic's monitor,calculate the average value
        //...
    });
    //...
}).listen(1337, "<IP_ADDRESS>");

@cekimy what node_redis version and what parser do you use?

<EMAIL_ADDRESS><EMAIL_ADDRESS>and use default parser:hiredis

Hm, this is weird. Since you do not use the offline queue. I can't think of a reason why this could happen. Are you certain that you only use .get? Or what commands do you use?

i use .get, .set, .incr, .hgetall...and so on, but i only monitor the cost of every .get command.

Hm, you said there were connection issues while the huge delay occured? I can't explain such a delay right now and wonder what happend on your side in this case.
And did you try the code from @stockholmux? By having a glimpse at it, it looks good to me for solveing your issue.

ok，thanks

Having a command timeout would be a useful feature. I am experiencing an issue where the redis client hangs, after sending a command, for about 15 minutes before the socket emits an ETIMEDOUT error. The cause of this is most likely an OS or network issue, but I'd rather detect it within a few seconds rather than let my application hang for 15 minutes.
I am currently monkey-patching the behavior a la @stockholmux's solution. Ideally I would modify just RedisClient::send_command, but the input to that method varies wildly depending on circumstances, so it's untenable to pick out and change the callback. Alternately, the connection timeout could be implemented inside send_command. @BridgeAR what are your thoughts on that? Would you be open to a PR for this?

Hi,
Can you provide the code sample for lrange+ltrim in multi+exec.
Thanks in advance.

i change the file redis/index.js line 352
var queue_name = options.queues || ['command_queue','offline_queue']
to
var queue_name =  ['command_queue','offline_queue']
so that i can get an error callback when the server is down
but i don't know wether this change will make negative affects to the other functions or not


[Remote Store] Add generic support of checksum for all vendors

Follow up from https://github.com/opensearch-project/OpenSearch/pull/9289#discussion_r1292834129

[Storage Triage - attendees 1 2 3 4 5 6 7 8 9
Currently checksum validation is only supported on S3 . We need this support on all other repositories  - Azure, GCP , HDFS .


enhancement: allow for 0,n number of azurerm_dns_cname_record, azurerm_dns_txt_record

looking to accomplish with create_cname_records and create_txt_records toggle

https://github.com/Azure/static-web-apps/issues/911

addressed in v0.2.0


AzureCI and GitLabCI don't have Panic Recovery like GithubCI and BitbucketCI

Of the four supported CI tools only Github and Bitbucket have code that recovers from a panic, for example from GitHub CI
	defer func() {
		if r := recover(); r != nil {
			log.Println(fmt.Sprintf("stacktrace from panic: \n" + string(debug.Stack())))
			err := usage.SendLogRecord(githubActor, fmt.Sprintf("Panic occurred. %s", r))
			if err != nil {
				log.Printf("Failed to send log record. %s\n", err)
			}
			os.Exit(1)
		}
	}()

It would be great if this could be written in a manner that makes it not only support all existing CIs but also as new CIs are added this change could cover those as well.
I am going to take a stab at solving this issue myself and submitting the fix as a PR.

Submitted Pull Request here https://github.com/diggerhq/digger/pull/769
YouTube Video where I made these changes is here https://youtu.be/tzFjxQvP77g


Facet Data is missing from the search call response (v1)

Describe the bug
When this endpoint is used for the search: https://www.ebi.ac.uk/ols4/api/search?q=data&start=0&groupField=iri&rows=10
There is no facet count data (it only has the search results)
To Reproduce
call  https://www.ebi.ac.uk/ols4/api/search?q=data&start=0&groupField=iri&rows=10
Expected behavior
facet data needs to be included in the response
Screenshots
N/A
Upload minimal complete example
N/A
Additional context
It should respond like v2 API: https://www.ebi.ac.uk/ols4/api/v2/entities?search=data&size=10&page=0&facetFields=ontologyId
where the facetFieldsToCount field contains facet data.
I tried also to include facetFields param, but no luck:  https://www.ebi.ac.uk/ols4/api/search?q=data&start=0&groupField=iri&rows=10&facetFields=ontologyId

Just to note this needs to be compared with OLS3 as we don't want to make breaking changes to the backwards compatible API.

We are also interested in getting the facet data (facet field information) from the search endpoint as it was with the old API: https://semanticlookup.zbmed.de/api/search?q=diabetes&exact=false&obsoletes=false&groupField=true&rows=10&start=0
We use the type and ontology names and counts for filtering the search results.


sentry: set environment

see: https://docs.sentry.io/platforms/javascript/configuration/environments/
Related to: https://github.com/getodk/central-backend/issues/521, https://github.com/getodk/central-backend/issues/547
This is one axis on which we can filter Sentry issue reports.  Suggested values:

development: dev.getodk.cloud
staging: test.getodk.cloud
production: everything else

I think this is a reasonable idea, but I don't think we should put it in the public docker-compose.yml because people will change it. It seems like we should just add it on dev/staging for our own use.

These values have been set on dev & test envs.

Maybe I'm being dense or unreasonable here, but I'd like to not have this in the public docker-compose. Is that weird? I don't want self-hosters to change this and then we have weird environments in our Sentry. Basically everything but dev/test should be production, but not explicitly labeled as such.

If we're already setting the username (getodk/central-backend#593), I'm wondering to what extent setting the environment is additionally helpful. Could we just filter for dev and test using their usernames? Or do things become easier by setting the environment?

If we're already setting the username, I'm wondering to what extent setting the environment is additionally helpful.

Would it be helpful for controlling alert levels / automated triaging of issues?  E.g. you may want to be "paged" (in whatever form) for a production incident, but never for one triggered in staging or dev.

instead of filtering for a production environment, we could filter out the usernames test and dev

@matthew-white that's possible, but for both browsing issues and configuring alerts, "environment" is a top-level filter, whereas configuring an exclusive username filter is more involved and error-prone, and would need to be done twice each time.
Would this PR be acceptable if the change was somewhere less user-accessible than docker-compose.xml?

I could see how it might make some things easier to have the environment set. If there's a way to set it while addressing @yanokwa's concern, that sounds good!

@matthew-white Seems like docker-compose.yml has other changes in the non-prod envs, so would the following addition be suitable at https://github.com/getodk/central-backend/blob/master/lib/external/sentry.js#L120-L121:
  environment: process.env.SENTRY_ENVIRONMENT || 'production',

?

That sounds reasonable to me!

Now that getodk/central-backend#601 is merged, I think we can close this PR. (Please reopen if I got that wrong!)

AFAICT, SENTRY_ENVIRONMENT has been unset in both dev & test.  Ref #547

I broke this in the upgrade to v1.5.3 in Cloud. It's now fixed. The values I used:
dev.getodk.cloud: development
test.getodk.cloud: testing (not staging because maybe we'll setup a staging server?)


fix: avoid using closeWallet as a promise

Closed. Simplified scope here: https://github.com/Emurgo/yoroi-mobile/pull/2131


Merge some files. Needs refactoring

Fixes #131

Okay, that was a bad idea. Let's tackle them separately.


[Build] Unable to find image 'apachepulsar/pulsar-build:manylinux-cp39-cp39' locally

Describe the bug
Python client build error. (maybe introduced by https://github.com/apache/pulsar/pull/10954)
To Reproduce
Steps to reproduce the behavior:

Checkout the master branch
Run pulsar-client-cpp/docker/build-wheels.sh
See error

Expected behavior
The build succeed
Screenshots
If applicable, add screenshots to help explain your problem.
+ auditwheel repair dist/pulsar_client-2.9.0-cp38-cp38-linux_x86_64.whl
INFO:auditwheel.main_repair:Repairing pulsar_client_sn-2.9.0-cp38-cp38-linux_x86_64.whl
INFO:auditwheel.wheeltools:Previous filename tags: linux_x86_64
INFO:auditwheel.wheeltools:New filename tags: manylinux1_x86_64
INFO:auditwheel.wheeltools:Previous WHEEL info tags: cp38-cp38-linux_x86_64
INFO:auditwheel.wheeltools:New WHEEL info tags: cp38-cp38-manylinux1_x86_64
INFO:auditwheel.main_repair:
Fixed-up wheel written to /pulsar/pulsar-client-cpp/python/wheelhouse/pulsar_client_sn-2.9.0-cp38-cp38-manylinux1_x86_64.whl
--------- Build Python wheel for 3.9 -- cp39-cp39
Using image: apachepulsar/pulsar-build:manylinux-cp39-cp39
Unable to find image 'apachepulsar/pulsar-build:manylinux-cp39-cp39' locally
docker: Error response from daemon: manifest for apachepulsar/pulsar-build:manylinux-cp39-cp39 not found: manifest unknown: manifest unknown.
See 'docker run --help'.
Error: Process completed with exit code 125.

Desktop (please complete the following information):

OS: Ubuntu 20.04

This is because the build image was not released yet. Maybe @BewareMyPower knows when that happens? I see no reason why we couldn't build it now, but someone with the correct rights needs to run pulsar-client-cpp/docker/create-images.sh and pulsar-client-cpp/docker/push-images.sh.
As a workaround, you can build the image locally with pulsar-client-cpp/docker/create-images.sh, and edit the build-wheels.sh script to take pulsar-build instead of apachepulsar/pulsar-build.

Fixed https://hub.docker.com/layers/apachepulsar/pulsar-build/manylinux-cp39-cp39/images/sha256-7406830c7fe0afc8b9ce8b51948ef66b02bd35b7f3a0a573ea67bb4d89a59da6?context=repo


client: add connection state in log entry

Signed-off-by: nolouch<EMAIL_ADDRESS>
What problem does this PR solve?
add more information if cannot update the leader.

[2019/12/13 18:30:41.829 +00:00] [ERROR] [client.go:448] ["[pd] getTS error"] [error="rpc error: code = Unknown desc = rpc error: code = Unavailable desc = not leader"] [errorVerbose="rpc error: code = Unknown desc = rpc error: code = Unavailable desc = not leader\ngithub.com/pingcap/pd/client.(*client).processTSORequests\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:484\ngithub.com/pingcap/pd/client.(*client).tsLoop\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:433\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337"] [stack="github.com/pingcap/log.Error\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/log@v0.0.0-20190307075452-bd41d9273596/global.go:42\ngithub.com/pingcap/pd/client.(*client).tsLoop\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:448"]
[2019/12/13 18:30:41.834 +00:00] [ERROR] [client.go:341] ["[pd] failed updateLeader"] [error="failed to get leader from [http://tidb-test-1-pd-1.tidb-test-1-pd-peer.tidb-test-1.svc:2379 http://tidb-test-1-pd-2.tidb-test-1-pd-peer.tidb-test-1.svc:2379 http://tidb-test-1-pd-0.tidb-test-1-pd-peer.tidb-test-1.svc:2379]"] [errorVerbose="failed to get leader from [http://tidb-test-1-pd-1.tidb-test-1-pd-peer.tidb-test-1.svc:2379 http://tidb-test-1-pd-2.tidb-test-1-pd-peer.tidb-test-1.svc:2379 http://tidb-test-1-pd-0.tidb-test-1-pd-peer.tidb-test-1.svc:2379]\ngithub.com/pingcap/pd/client.(*client).updateLeader\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:229\ngithub.com/pingcap/pd/client.(*client).leaderLoop\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:340\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337"] [stack="github.com/pingcap/log.Error\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/log@v0.0.0-20190307075452-bd41d9273596/global.go:42\ngithub.com/pingcap/pd/client.(*client).leaderLoop\n\t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/pd@v0.0.0-20190711034019-ee98bf9063e9/client/client.go:341"]

What is changed and how it works?
add more information.
Check List
Tests

Manual test (add detailed scripts or steps below)

Codecov Report

Merging #2021 into master will increase coverage by 0.13%.
The diff coverage is 80%.

@@            Coverage Diff             @@
##           master    #2021      +/-   ##
==========================================
+ Coverage   77.46%   77.59%   +0.13%
==========================================
  Files         180      180
  Lines       18045    18049       +4
==========================================
+ Hits        13978    14005      +27
+ Misses       3014     2992      -22
+ Partials     1053     1052       -1

Impacted Files
Coverage Δ

client/client.go
73.15% <80%> (+1.87%)
:arrow_up:

server/heartbeat_streams.go
67% <0%> (-6%)
:arrow_down:

server/config/option.go
90.32% <0%> (-0.93%)
:arrow_down:

server/member/leader.go
76.53% <0%> (-0.52%)
:arrow_down:

server/server.go
83.13% <0%> (-0.4%)
:arrow_down:

server/core/storage.go
75.44% <0%> (ø)
:arrow_up:

server/cluster/cluster.go
81.4% <0%> (+0.46%)
:arrow_up:

server/grpc_service.go
59.17% <0%> (+1.51%)
:arrow_up:

server/region_syncer/client.go
82.89% <0%> (+3.94%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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

/merge


 IMHO it is the debugger's job to apply my breakpoints, and exposing an action to reapply all breakpoints seems like a workaround for a bug inside the debugger.

I agree with your reasoning however sometimes it the debugger adapter does not know when is a good time to reapply breakpoints. @weinand can provide more details.
Also the react people really want this feature, so we will for sure not remove it.
We can make it more hidden by removing it from the viewlet and keeping it as a global workbench action
@weinand opinions?

We could get rid of this in the UI if we would call it on every stopped event. This would slow down stepping.

If you compare breakpoints to watch expressions, I find it nice that there is no refresh button on the watch expressions (the debugger knows when it's a good time to re-evaluate them).
Maybe the debugger could keep a list of function breakpoints it could not apply and every chance it gets it tries to reapply the function breakpoints until they were applied successfully. Or perhaps report it to the UI on every pause that this function breakpoint is not active, is active, etc.


add PriorityQueue

Not sure which "style" of pq to build and I don't feel like building them all.

Basic binary PQ added as toybox.heap, roughly following Python heapq API.
I am leaving this issue open as I would also like to add a proper Double-Ended Priority Queue ("depq").

One of the reasons I want to add a depq is because in some tasks, on modern hardware, depq performs better than traditional pqs, even if you are only looking for the min value on every pop.
Had to do some googling, but found this ref:
https://probablydance.com/2020/08/31/on-modern-hardware-the-min-max-heap-beats-a-binary-heap/
And I know I've seen more benchmarks on this too. In one of my past jobs, we found an improvement via use of depq for a specific use-case that was just a Min Heap, but implemented via depq was more performant.


update bencher deps

Codecov Report

Merging #872 (fc5dc07) into master (80ed32d) will increase coverage by 0.15%.
The diff coverage is 29.62%.

@@            Coverage Diff             @@
##           master     #872      +/-   ##
==========================================
+ Coverage   78.58%   78.73%   +0.15%
==========================================
  Files         102      104       +2
  Lines       10556    10589      +33
==========================================
+ Hits         8295     8337      +42
+ Misses       2261     2252       -9

Impacted Files
Coverage Δ

bencher/src/bench_runner.rs
0.00% <ø> (ø)

bencher/src/bencher.rs
0.00% <0.00%> (ø)

bencher/src/handler.rs
0.00% <0.00%> (ø)

bencher/src/utils.rs
0.00% <0.00%> (ø)

bencher/test/src/mock.rs
100.00% <ø> (ø)

bencher/test/src/weights.rs
50.00% <46.15%> (+50.00%)
:arrow_up:

bencher/test/src/lib.rs
63.63% <100.00%> (+63.63%)
:arrow_up:

bencher/test/src/tests.rs
100.00% <0.00%> (ø)

... and 1 more

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


Switch partition with conf in coffee

@agherzan @michal-mazurek

LGTM

NIT: Why do you have multi-line for subject line?


Typescript Code Generation - Enum are represented as Strings instead of Enums

Enum values are generated as the String equivalent instead of an Enum
Example
Docs Link
\\ excluded for brevity

requestBody.settings.recurrence.range.type = "numbered";
requestBody.settings.recurrence.range.startDate = "2021-05-05";

const result = async () => {
	await graphServiceClient.identityGovernance.accessReviews.definitions.post(requestBody);
}

Expected output
\\ excluded for brevity

requestBody.settings.recurrence.range.type = RecurrenceRangeType.Numbered;
requestBody.settings.recurrence.range.startDate = "2021-05-05";

const result = async () => {
	await graphServiceClient.identityGovernance.accessReviews.definitions.post(requestBody);
}

@rkodev just want to confirm if you are working on this right now.

@ddyett Yes, this is currently in progress


Update BISCUIT Test Data

The BISCUIT MultiQC module and the code generating the input files for it have been updated such that the test data needed to be replaced. MultiQC pull request with updated BISCUIT module to follow.

x-ref https://github.com/ewels/MultiQC/pull/1167

Added back the old data, now have both versions in directories named after the version of biscuit: https://github.com/ewels/MultiQC_TestData/tree/master/data/modules/biscuit


VimNavigator: Add h/l for expanding/closing folders in explorer.

Hitting enter to open the folders and ....I'm not actually sure what to close them, isn't the best, at least coming from using stuff like Ranger.
Adding h to contract or l to expand would be pretty natural feeling, and make getting around the explorer easier I think.

Dullicate of #1442.
Good suggestion for h/l.

More info over there, so I'll just copy my idea on to that ticket!


Fix Windows and MacOS builds

Accomodate bazel 6.0 changes.
Use --host_action_env=PROGRAMFILES(X86) instead of --nodistinct_host_configuration.
Upgrade dmd compiler to pass the MacOS build.

@laurentlb, please review.


[SPARK-12820][SQL]Resolve db.table.column

Currently spark only support to specify col name like: table.col, or col in projection, but it's very common that user use db.table.col especially when join table across database.
Hive doesn't support this for now but it has been used in lot of other traditional db like mysql.

Test build #49381 has started for PR 10753 at commit 1cafed7.

When we have a database named "a", and two tables:

a table also named "a", and a struct column named "b", and a field in the struct named "c".
a table named "b", and a column in it named "c"

What happens if the user specifies "a.b.c"?

It would return attribute c in table b up on this patch. Any suggestion? throw ambiguous exception for such case?

What do we do if the user specifies "a.b" right now? I'd say we should follow that, and make sure we have a test case for it.

Would return attribute b in table a.  resolved within the logic of table.col

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49387/
Test FAILed.

Test build #49381 has finished for PR 10753 at commit 1cafed7.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Subquery(alias: String, child: LogicalPlan, databaseName: Option[String] = None)

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49381/
Test PASSed.

Merged build finished. Test PASSed.

I would say we'd better keep the same checking logic with mysql/hive for the ambiguous case, @zhichao-li can you please check that with mysql/hive?

@chenghao-intel , mysql(5.5) doesn't support nested data type for now, and hive(1.2.1) doesn't support the usage of "db.table.field" in projection list at the moment.  I guess most of the user work around this by using alias.

Test build #51930 has started for PR 10753 at commit 4155ffe.

Test build #51930 has finished for PR 10753 at commit 4155ffe.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/51930/
Test FAILed.

Test build #52031 has started for PR 10753 at commit a3c4f20.

Test build #52031 has finished for PR 10753 at commit a3c4f20.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52031/
Test FAILed.

Thanks for the pull request. I'm going through a list of pull requests to cut them down since the sheer number is breaking some of the tooling we have. Due to lack of activity on this pull request, I'm going to push a commit to close it. Feel free to reopen it or create a new one. We can also continue the discussion on the JIRA ticket.


Add fixed-center option

When "fixed-center": true, (default):

When "fixed-center": false,:

Resolves #957

thanks, I was waiting for this one since a long time!

LGTM!


Secured objects integrity

Motivation
Prevent someone to change part(s) of the integral data of a secured object in the database and thus tricking the application to send sensitive information to a malicious application.
Approach
Each secured object defines which is its integral data and a processor calculates an integrity to be stored next to the object. Upon retrieval of the object, the integrity is calculated and is compared to the previously stored one.
Open questions

[ ] What do we do with existing secured objects? Create different application that sets the integrity? Leave this code here and remove it after some time? have some flag in db that says "intregration_setup_done"?
[ ] Does it make sense to check integrity of all secured objects or only for brokers?
[ ] Does it make sense to allow extending the integral data outside of the open-source?
[ ] Does it make sense to allow configuration of integrity processor (e.g. different hashing algorithm in a wrapper)?
[ ] Should the integrity always be 32 byte slice or allow variable size?

Coverage increased (+0.08%) to 87.378% when pulling 3ed0bc6a8f24e0bf7438e21e3fe6b3219378c11d on credentials_integrity into 368409997db4c8cf45a07ec27489a6a51b741bda on master.


[BUG] Config version wrong

In the updater code, the provided config version is wrong, causing overwrites

This bug has been fixed and will be included in the next update.


Promisifies and renames library

This looks good. Just left a comment about maybe not needing the utils file as it's only used once.


compress/flate: compression ratio regression

Using 9af83462
The recent changes to compress/flate has provided pretty good improvements overall to the compression speeds, but I have noticed a few extraordinary cases where the compression ratio suffers significantly.
This spreadsheet compares the output sizes from go1.6 to current go.tip on a number of compression benchmarks. All tests were done using the flate.DefaultCompression setting.
Most notably, the clegg.tiff image from the ACT corpus experiences a 44% increase in output size (511928 to 741046 bytes).
I think it would be worthwhile to understand what causes this fairly significant regression in compression ratio before the go1.7 release.
cc @nigeltao @klauspost

I spent some time analyzing clegg.tiff, here's a histogram of the backwards references clustered by backwards distance and backwards copy length.
Lengths:           go1.6   go.tip
	1..1:          0       0
	2..2:          0       0
	3..3:          96798   0
	4..4:          19939   19534
	5..5:          3708    3683
	6..6:          19950   19349
	7..7:          4116    4691
	8..11:         2464    2557
	12..15:        874     873
	16..23:        157     162
	24..31:        17      18
	32..47:        5       6
	48..63:        44      44
	64..95:        46      46
	96..127:       57      57
	128..191:      7       5
	192..255:      313     315
	256..383:      4348    4348

Distances:
	1..1:          261     258
	2..2:          1       1
	3..3:          135100  38991
	4..4:          4       1
	5..5:          0       0
	6..6:          0       0
	7..7:          1       0
	8..11:         51      0
	12..15:        516     400
	16..23:        344     267
	24..31:        409     299
	32..47:        407     319
	48..63:        345     288
	64..95:        282     246
	96..127:       188     171
	128..191:      213     176
	192..255:      117     94
	256..383:      153     130
	384..511:      83      69
	512..767:      193     164
	768..1023:     186     160
	1024..1535:    373     305
	1536..2047:    348     301
	2048..3071:    7809    7502
	3072..4095:    168     126
	4096..6143:    70      70
	6144..8191:    1302    1267
	8192..12287:   858     873
	12288..16383:  498     516
	16384..24575:  1590    1674
	24576..32767:  973     1020

It seems that the ratio hit occurs because the new hash-chain algorithm only operates on 4-byte segments, rather than 3-byte segments. This tends to be pathological for bitmap-based images, which represent a pixel as a tuple of 3 bytes for (R, G, B). This explains why there is such a large number of {Length:3, Distance:3} references in go1.6 that cannot be generated in go.tip. Fortunately, I think RGB based images are slowly becoming obsolete, while RGBA is becoming more common (and can benefit from the minimum copy length of 4).
Given the dramatic increase in performance using 4-byte hashing, I'm support keeping 4-byte hashing even if it causes some inputs to suffer (especially RGB based images, and possibly other inputs).
@nigeltao, your thoughts?

Thanks for the analysis. It certainly sounds plausible that these are RGB 3-tuples in an uncompressed TIFF.
I agree that we don't need to revert 4-byte hashing yet.
For example, TIFF is not as common as it used to be, and more modern image formats use 2D-image-specific filtering before passing to a general purpose compressor like DEFLATE; those filters already take out any easy repeated-RGB-3-tuple wins. Using the standard library's image/png encoder yields 501111 bytes, smaller than both 511928 and 741046. WEBP Lossless (generated by the cwebp tool) is 379612 bytes.

For "BestCompression" it could be feasible to have a version that could to 3-byte matches. The token writer could then be modified to choose between 3-length matches and 3-byte literals depending on the encoded size.

Sounds good. Possibly adding 3-byte matching to BestCompression, might not be a bad idea. Since it seems we're in consensus about keeping the 4-byte matching, I'm going to relabel the issue to possibly adding 3-byte matching to high compression levels.

I ran both the Go tip and Go 1.6 image/png encoders over a corpus of 20,000 or so PNG images, comparing the output size of a decode-and-then-re-encode. I don't think image/png changed much; it should all be due to compress/flate. Below are the summary statistics (grouped by image type) of the ratios of tip size over 1.6 size; higher means tip is worse, a value of 1.000 means no change.
Gray      n=1252   avg=0.984  p25=0.977  p50=0.987  p75=0.994  p90=0.998  max=1.031
Gray16    n=7      avg=0.998  p25=0.985  p50=1.004  p75=1.009  p90=1.015  max=1.015
NRGBA     n=5365   avg=1.013  p25=0.985  p50=1.007  p75=1.039  p90=1.051  max=1.427
NRGBA64   n=154    avg=1.000  p25=0.994  p50=1.000  p75=1.005  p90=1.013  max=1.243
Paletted  n=3181   avg=0.989  p25=0.984  p50=0.990  p75=0.994  p90=0.998  max=1.023
RGBA      n=11644  avg=1.022  p25=0.991  p50=1.006  p75=1.036  p90=1.082  max=1.696
RGBA64    n=89     avg=1.006  p25=0.996  p50=1.001  p75=1.010  p90=1.032  max=1.118
overall   n=21692  avg=1.013  p25=0.986  p50=0.999  p75=1.027  p90=1.058  max=1.696

pXX are the percentiles, e.g. p50 is the median ratio. It's not too surprising that *image.RGBA and *image.NRGBA Go image types (i.e. what PNG calls RGB and RGBA images) miss the 3-byte matches the most. Nonetheless, I think the increase in compressed size, in the order of 1-2% on average and less than 1% on median, is acceptable for Go 1.7. Sure, we can always find specific examples (such as the TIFF in the original post) that re-encode relatively badly, but I think we're OK in general, at least for PNG.
In Go 1.8, we can consider re-introducing 3-byte matches, and see if that will bring the outliers back into the fold.


Stop flagging unused imports

Attempt at fixing #116

Seems to not break any tests, and the logic seems to also make sense, so merging this and hoping for the best 🤷


"No such file or directory" when running parts of benchmark

With criterion v0.2.4 and a clean target directory, when I run the following in the syntect repo:
cargo bench -- parse

There are some errors in the output:
     Running target/release/deps/highlighting-7594dd596dc32340
highlight/"parser.rs"   time:   [359.99 ms 361.81 ms 365.00 ms]
08:52:12 [ERROR] error: Failed to access file "target/criterion/highlight/\"scope.rs\"/new/sample.json": No such file or directory (os error 2)
08:52:12 [ERROR] caused by: Failed to access file "target/criterion/highlight/\"scope.rs\"/new/sample.json": No such file or directory (os error 2)
08:52:12 [ERROR] caused by: No such file or directory (os error 2)

The errors seem to be coming from files that were filtered out (because I only ran benchmarks with "parse" in the name).
Also, I thought those kind of names would no longer be used with #142?
(Didn't have the time to create a minimal reproducible example yet, but if it's not clear what the problem is I can do that.)

Hey, thanks for trying Criterion.rs, and thanks for the bug report!
I think I'll have to investigate this one some more before I can say what's happening for sure. I thought the folder names were fixed now as well. I suppose it's always possible I missed something.

You should be able to reproduce the problem by cloning this repo: https://github.com/robinst/criterion-example-string-inputs
And then run:
cargo bench -- foo

This should be fixed in the next version. It runs your test case without issue, at least. Thanks again for the bug report!

Thank you!


SunEditor: Increase z-index of .se-toolbar

Describe the bug
Depending on the version the z-index of .sun-editor .se-wrapper has been increased to 9999 or 1002, but the z-index of .sun-editor .se-toolbar hasn't been increased and therefore the toolbar drop-downs will be hidden behind the content.
primefaces-extensions:13.0.0:
/* Ensure the editor can receive input in dialog */
.sun-editor .se-wrapper {
   z-index: 9999 !important;
}

Most recent version:
.ui-dialog-content .sun-editor .se-wrapper {
    z-index: 1002 !important;
}

Illustration of the problem:

Reproducer
No response
Expected behavior
Toolbar drop-downs should have a higher z-index than the editor content.
PrimeFaces Extensions version
13.0.0
JSF implementation
All
JSF version
2.3
Browser(s)
No response

cc @stolp @MattSho

OK @stolp @mattsho I removed this CSS entirely and added a showcase example of using SunEditor in a dialog.  I can't see anything wrong.  I can edit text and add images and they get added in the correct spot.
What am I missing here?

Is the showcase live yet? I can't find a dialog there.
Anyway, in my application I reverted back to 12.0.7 (which also omits this CSS) and have no problems to speak of.
Yet, there are issues I can reproduce: When I use p:sunEditor with mode=inline in a dialog, the toolbar is cut off as shown here:

I circumvent this bug by using mode=classic in dialogs.
There also seem to be problems with the image highlighting when adding/editing problems as shown here:

But this is more of a first world problem.
@mattsho may document his problem here again, but I am fine for now and approve reverting the prior fix.

Here is a runnable reproducer:
pfe-suneditor.zip
Run mvn clean jetty:run and it looks like everything is working to me.  I do see the inline mode issue in the dialog you see but NONE of the other issues being reported by @mattsho ?

I think this fixes your dialog inline mode issue.
.ui-dialog div.se-toolbar.sun-editor-common.se-toolbar-inline {
  top: 0px !important;
}

@maroswal I released 13.0.1 are you able to test your scenario again please?

Thanks, I will give it a try and come back to you.

Sorry really have it fixed for 13.0.2 and 12.0.11. But for now this MonkeyPatch should work.
if (PrimeFaces.widget.ExtSunEditor) {
    PrimeFaces.widget.ExtSunEditor.prototype._render = function() {
        var $this = this;

        //initialize
        this.getLanguage();
        this.editor = SUNEDITOR.create(this.id, this.cfg);
        this.editor.onload = function(core, reload) {
            $this.callBehavior('initialize');
        }
        if (this.cfg.readOnly) {
            this.editor.readOnly(true);
        }
        if (this.disabled) {
            this.editor.disable();
        }

        //update input on change
        this.editor.onChange = function(contents, core) {
            $this.input.val([].map.call(core.context.element.wysiwyg.children, function(node) {
                return node.outerHTML || "";
            }).join(""));
            $this.callBehavior('change');
        };

        this.editor.onScroll = function(contents, core) {
            $this.callBehavior('scroll')
        };
        this.editor.onMouseDown = function(contents, core) {
            $this.callBehavior('mousedown')
        };
        this.editor.onClick = function(e, core) {
            $this.callBehavior('click')
        }
        this.editor.onInput = function(e, core) {
            $this.callBehavior('input')
        }
        this.editor.onKeyDown = function(e, core) {
            $this.callBehavior('keydown')
        }
        this.editor.onKeyUp = function(e, core) {
            $this.callBehavior('keyup')
        }
        this.editor.onFocus = function(e, core) {
            $this.callBehavior('focus')
        }
        this.editor.onBlur = function(e, core) {
            $this.callBehavior('blur')
        }
        this.editor.onPaste = function(e, cleanData, maxCharCount, core) {
            $this.callBehavior('paste')
        }
        this.editor.onCopy = function(e, clipboardData, core) {
            $this.callBehavior('copy')
        }
        this.editor.onCut = function(e, clipboardData, core) {
            $this.callBehavior('cut')
        }
        this.editor.onDrop = function(e, cleanData, maxCharCount, core) {
            $this.callBehavior('drop')
        }
        this.editor.onSave = function(contents, core) {
            $this.callBehavior('save')
        };

        // check if being used in dialog
        var dialog = this.input[0].closest('.ui-dialog');
        if (dialog) {
            $(dialog).find('.sun-editor .se-toolbar').zIndex(9999);
            $(dialog).find('.sun-editor .se-wrapper').zIndex(9998);
        }
    }
};

Seems to work for me with 13.0.2

Excellent thanks for reporting back!


DCOS-11961: Fix historical pod instance merge

Implement calls to filter the combined (current and historical) list of pod containers to remove potential duplicates.
This will fix issues with oscillating pod container data which was caused by duplicated containers.
Fixes DCOS-11961

LGTM 💯

LGTM too! ✨