serialization error: BoxOrdinal

My student Ryan (@RDReynolds) has found an issue - see below. @evaleev do you have any idea?

Toru,
I have traced back the problem with the Reference serialization test case.  (hf_tzvpp_bfgs_saveref.json)  An assert statement in boost::serialization indicated that we were trying to save a bool that was never instantiated, and gdb pointed to line 211 of btas/ordinal.h as the culprit.  It seems the problem does not occur if we change line 39 of btas/ordinal.h to the following:
BoxOrdinal() { contiguous_ = true; }
Probably the appropriate solution instead deals with where this constructor is called, though.
Best,
Ryan
PS: Note that because it's an assert statement, boost only picks up the error in debug mode. That's why it ran without problems for me originally.

@RDReynolds do I understand correctly that the compiler seems to optimize out the class member contiguous_ ? that in principle should not be possible since it is used by serialization ... could you provide extra details here? Error message and the compiler+boost version you used at least.

I don't think this is optimization. The error was observed with -O0 -g. gcc 4.8.3 and boost 1.55.
If I understood this is because in some context BoxOrdinal is constructed in a way that a member is not initialized (i.e., default constructor is called), and boost does not allow that to be serialized.

error message
lt-TestSuite: /usr/local/include/boost/archive/basic_binary_iprimitive.hpp:98: void boost::archive::basic_binary_iprimitive<Archive, Elem, Tr>::load(bool&) [with Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits<char>]: Assertion `0 == i || 1 == i' failed.

FYI: this comes from the following line when loading from an archive, which basically states that the stored boolean was not initialized.
basic_binary_iprimitive.hpp
    void load(bool & t){
        load_binary(& t, sizeof(t));
        int i = t;
        BOOST_ASSERT(0 == i || 1 == i);
        (void)i; // warning suppression for release builds.
    }

OK, I suspected that "instantiated" in the issue statement meant
"initialized". The standard does not allow to avoid "instantiating" unused
members, so that did not make much sense.
This is annoying  but for a debug build the penalty matters little ... I
will avoid doing this for a release build.
On Sat, May 2, 2015 at 7:20 AM, Toru Shiozaki<EMAIL_ADDRESS>wrote:

FYI: this comes from the following line when loading from an archive,
which basically states that the stored boolean was not initialized.
basic_binary_iprimitive.hpp
void load(bool & t){
load_binary(& t, sizeof(t));
int i = t;
BOOST_ASSERT(0 == i || 1 == i);
(void)i; // warning suppression for release builds.
}
—
Reply to this email directly or view it on GitHub
https://github.com/BTAS/BTAS/issues/78#issuecomment-98348127.

--
web: valeyev.net

Ah ok I did not catch that. To clarify - are you going to fix this by putting in this initialization in ifndef NDEBUG block or something? (well I am fine with any resolution as long as the code works!)

I pushed a change, please try.

Yes it runs through now. Thanks!


Feat/civ 3601

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-3601
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

reopening to test that onboarding has been completed


I got 404

stdout: [GIN-debug] Listening and serving HTTP on <IP_ADDRESS>:8080
stdout: [GIN] 2023/10/14 - 14:25:43 | 404 |      33.357µs |  <IP_ADDRESS> | GET      "/"
stderr: 2023/10/14 14:25:43 [DEBUG ERROR]: Status 404, Body: 404 page not found
stdout: [GIN] 2023/10/14 - 14:26:07 | 404 |      22.293µs |  <IP_ADDRESS> | GET      "/"
stderr: 2023/10/14 14:26:07 [DEBUG ERROR]: Status 404, Body: 404 page not found

I am hitting the exact same problem with the default docker-compose.yml

Sorry to disappoint you both, but this doesn't have web interface (yet).
The only way to interact with the service is by using the iOS/Android application.
With the app you can share albums on the web, but that's the only web feature at the moment.

@Yumega that probably means you cannot connect to the server.
Are you using same WiFi on your phone and your server? The right port?
By default it should be connecting to something like http://<IP_ADDRESS>:8080

Sorry to disappoint you both, but this doesn't have web interface (yet). The only way to interact with the service is by using the iOS/Android application.
With the app you can share albums on the web, but that's the only web feature at the moment.

:-) I guess we got ahead of ourselves a bit. Thanks for the pointer, I now could successfully connect the app to my server instance.

@Yumega so if you open with your phone browser these pages:

http://:8080 (qbittorrent)
http://:8383 (circled-server)
Do you see anything?

If you don't see same error 404 (as in your original post) in the second case, then it's a network access issue. You should see the same logs too.

By the way, you should have gotten an iOS prompt to allow local network connections.
Can you make sure it is actually ON? If you go to the "circled.me" Settings screen, you should be seeing this:

Thanks for checking.
Not having photos yet is normal as you haven’t been able to log in I guess.
And what about the logs from circled-server when you try to create first user?

Makes sense, but I can't see any of the requests the app would be making.
Like /user/login should be the first one.

Can you please try the latest docket-compose example file. Either from the repo or from the readme.
I updated it couple of days ago but it is possible you have the previous version.


Question about Streaming.

Thanks a lot for sharing the code!
Here are some questions:
Where is the code to process 'streaming'?
Is streaming necessary in training model? Or just use original data.
Thanks again.

A streaming example can be found in the streaming_transcribe.py script.


Adapt: Don't fail when we run on a host with 1 core

Motivation:
We require that the minimum queue size is 2 and use the number of cores as default value which can be less.
Modifications:
If we see less then 2 cores just use 2 as default size
Result:
Fixes https://github.com/netty/netty/issues/14579

@normanmaurer  I think we should use Math.max here, not Math.min.


How about the results if i don't use the text-image function?

Hi, guys. I'm really curious about whether this network can be applied to generate images merely based on image dataset.
And i have deleted the text-encoding module from the code, train the model intimately.The result of stageII is not so satisfactory.
Can anyone give me some advices? Thanks

Hi,
Our experimental results show that the conditioning augmentation proposed in the paper is very important for generating high-resolution images in stage-II. Since you have deleted the text-encoding module, it means that there is no conditioning augmentation in your stage-II GAN. That might be the reason your stage-II result is not so satisfactory.
Here are some suggestions to make your model better:
(1) Try new hyper-parameters and network structures for your unconditional version of StackGAN. Our new results show that if you add one extra layer (e.g., 64x64x(gf//2)) before the output layer (64x64x3) of stage-I GAN, you can get better stageI results, thus you might get better stageII results as well.
(2) In stage-II GAN, you might try to input the same or augmented z vector at where the original text conditioning augmentation vector c is inputed, because our paper also demonstrates that it is useful to input text information again in stage-II GAN to encourage it to add more details to the high-resolution image and correct defects in the low-resolution input image.


'Window is not defined' where do I put client-side only scripts?

I'm trying to run a-frame in one of my vue pages but I'm getting an error in my browser:
ReferenceError: window is not defined
I'm guessing this is because nuxt is trying to run the aframe module while rendering the page on the server.
<template>

</template>

Hi,
Yes, this is exactly due to the server-side rendering.
If you need to specify that you want to import a ressource only on the client-side inside, you need to you process.BROWSER_BUILD variable.

Thanks for your report, the documentation of the website will be completed soon.

Ah ha, brilliant! Thanks!

Hmm a-frame doesn't play nice with vue. It doesn't load properly.

I have experinced similar issues as well. I was trying to import a vue UI framework element-ui. However, it references window object and several native browser functions like addEventListener etc., so it breaks the server rendering. I'm thinking if there is a way to polyfill it somehow. Because for such kind of UI framework, if we cannot render it on server side, it's probably not good for SEO.
I've treid next.js with antd ( a UI framework built on React.js which similar to element-ui ) and it worked almost perfectly ( except next.js is using glamor as a css-in-js solution which is pretty hacky). When I have time I'll dig more for the reason why it's working in next.js but not nuxt.js.

I think that every vue plugin should be able to work both client-side and server-side since the version 2.0 of Vue.js.
I asked the team behind element-ui but they said it's not their priority, but I don't think it will be complicated to make it compatible with server-side rendering, since we will only have to add if statement where a client-side only function is called.
@andyhu what library are you talking about which is working with next.js but not nuxt.js?

@Atinux I mean I'm pretty sure that antd has some windows object references as well. But when I tried it, it does work in next.js. However it probably because that antd is more modular and I missed the browser specific part of the variable references. Anyway I'm going to test more.

I hope they will add theses check so element-ui could be used on the server-side too and render the proper HTML code!
I'm closing this issue since the question has been answer by @alexchopin by using process.BROWSER_BUILD.

I know this issue is closed and all, but I just want to point out an alternate solution - Vue's lifecycle hooks. All hooks except for beforeCreate and created do not even run on the server. If you're doing any client-side manipulation or inspection and referencing built-in browser globals like window or document, then you should do those things in these methods. This solution removes the need to inspect environment variables.

https://github.com/nuxt/nuxt.js/issues/30#issuecomment-264348589

Hi,
Yes, this is exactly due to the server-side rendering.
If you need to specify that you want to import a ressource only on the client-side inside, you need to you process.BROWSER_BUILD variable.[...]

why is this still not in the docs? I followed what was there and was still having issue importing a vue component. this solution cleared things up

Documentation

The official instructions on including Google analytics fail because of this

I have a follow up to this inquiry and didn't want to clutter up the project with another issue. There is another use for client-specific code within a component and that would be querying client browser capabilities. For instance, I have a component that must query the media capabilities of the platform and obviously this operation only makes sense from the client side. How is something like this generally handled?
I imagine this is also an issue for the people using WebGL, etc?

I have a follow up question that is a bit relevant to this issue and didn't want to clutter up the project by opening another one. I have code that needs to query browser-specific media and streaming capabilities. Where would that code best be located such that it is guaranteed to run when the component appears on the client side (whether it has previously been rendered by the server or not). I imagine this is also an issue for anyone trying to integrate with WebGL and other WebAPI technologies. Anyone have some advice?

@dkushner we have a special option for JS to be run only on client-side with ssr: false option: https://nuxtjs.org/guide/plugins#client-side-only

@Atinux, perfect thanks! Just happened to miss that portion of the docs.

@Atinux, actually I'm sorry it looks like that documentation is explicitly for Vue plugins. Do I need to wrap every external library I use as a Vue plugin in order to leverage this? For instance THREE and SocketIO will both rely on UA-specific objects being present like document and window. So do each of these libraries then become a separate plugin?

@dkushner yep

Excuse me, I call window inside mounted function which should be run only in browser, still throw "window is not defined error"

Currently, nuxt.js 1.0.0-rc11, it is process.browser and not process.BROWSER_BUILD inside a component.

Vue-FullCalendar
app/plugins/vue-fullcalendar.js
import Vue from 'vue'

if (process.BROWSER_BUILD) {
  window.onNuxtReady(() => {
    const VueFullCalendar = require('vue-fullcalendar')
    Vue.use(VueFullCalendar)
  })
}

This is the best answer I've ever seen. Thanks

I'm closing this issue since the question has been answer by @alexchopin by using process.BROWSER_BUILD.

How would that work if we are using import instead of require? If I put my import inside the if statement I get:
NuxtServerError Module build failed: SyntaxError: 'import' and 'export' may only appear at the top level

You have to use require at the moment @andrewharvey and ask for the library author to add SSR support (by giving him this link if it's a Vue.js library: https://ssr.vuejs.org/en/universal.html)

You have to use require at the moment @andrewharvey and ask for the library author to add SSR support (by giving him this link if it's a Vue.js library: https://ssr.vuejs.org/en/universal.html)

Thanks @Atinux. I also found I can use import by moving my code out from the page into a component and use ssr: false when loading that plugin in the nuxt.config.js.

@yun313350095  I tried process.browser but it didn't work. However, process.browser is working fine for me.
But is this real solution? i mean i have to put this if block every method, where i want to something for client-side interaction.

Hello, I'm very confused and having really bad times :disappointed:
What if, I have to add some components after the first contentful paint ?
I've something like this:
    <no-ssr>

        <post-share/>

ToRead

          <post-suggestion/>

    </no-ssr>

But I can't figure out how to load these components in front...
// vue instance
components: {
  // What I have to do?
}

Any help would be appreciated

@EmixMaxime

in HTML,

        <postShare />

Hope this will help

@sudhir600 Hum, that load the component in the server side, I have the window undefined error.

You have to lazy-import your components like this:


Allows locked entries to be collapsable

BEFORE
AFTER

don't really like this change, but codewise is ok
should still switch to a faster jquery lookup method


Optimisations

Optimise drawing & event handling of DynVec from O(n) to O(log n); also cull draw operations on other hidden child widgets sooner.

Also:

rename DynVec → List
add Row, Column and boxed derivatives of List
extend List API (based on Vec methods)


Add edpm baremetal CI job

With this commit, we add edpm baremetal CI job
against dataplane operator.
Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/180

recheck

recheck

recheck

/hold

recheck

/unhold

recheck


How to preserve the normalized picture?

I have used your code like:
i1=utils.read_image('./data/i1.png') i2=utils.read_image('./data/i8.tif') n=stainNorm_Reinhard.Normalizer() n.fit(i1) normalized=n.transform(i2) cv.imwrite('i8_n.tif', normalized)
but the picture preserved as 'i8_n.tif' looks strange. I want to know how to preserved the normalized picture which looks like in your example.

@Peter554  Thanks for your reply. I find it is because I don't convert the color space from RGB to BGR before I use the 'cv2.imwrite'.

Yes that would be it!


Use non-deprecated span attributes

Closes #129.

net.peer.name -> replaced with server.address on client spans and client.address on server spans.
net.peer.port -> replaced with server.port on client spans and client.port on server spans.
http.status_code -> replaced with http.response.status_code.

Rebased on top of #182.

Sorry @KasonBraley didn't mean to close this branch.


Add max_shard_size arg

PR types
Others
PR changes
Others
Description
Add max_shard_size arg.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.28 out of 29 committers have signed the CLA.:white_check_mark: KB-Ding:white_check_mark: DrownFish19:white_check_mark: ZHUI:white_check_mark: gongel:white_check_mark: JunnYu:white_check_mark: FeixLiu:white_check_mark: sijunhe:white_check_mark: qingzhong1:white_check_mark: guoshengCS:white_check_mark: wtmlon:white_check_mark: lugimzzz:white_check_mark: GhostScreaming:white_check_mark: w5688414:white_check_mark: DesmonDay:white_check_mark: wanghuancoder:white_check_mark: zhiqiu:white_check_mark: littsk:white_check_mark: wj-Mcat:white_check_mark: BeingGod:white_check_mark: Meiyim:white_check_mark: xiezheng-XD:white_check_mark: pangengzheng:white_check_mark: Liujie0926:white_check_mark: zjjlivein:white_check_mark: USTCKAY:white_check_mark: ForFishes:white_check_mark: haoyuying:white_check_mark: carryyu:x: daisimingdaisiming seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Where is this file called control_discovery.py?

Excuse me, when I try to run "batch_launcher_IdentifyAndHowto.sh", I cannot find "control_discovery.py" and "control_eval_grouping.py", And I only found 'discovery.py' and 'grouping.py', what's the difference between the two?

Hi! Thank you for poiting it out. All scripts' names "control_discovery.py" or "control_eval_grouping.py" are actually "discovering.py" and "grouping.py" in the current repo. I've corrected the script names now. Thank you for helping us improve the code.


Use a regex to detect notebook started message.

The notebook pip package was recently updated, and the newer version uses a different "notebook started" message. We parse the jupyter output in order to detect the the server has started, so this message change broke our string parsing. The newer message format includes the notebook package version, so my fix here is to add a regex to detect that version snippet.
New message format:
"[I 14:28:37.225 NotebookApp] Jupyter Notebook 6.1.1 is running at:"
Old message format:
"[I 14:41:05.133 NotebookApp] The Jupyter Notebook is running at:"
I verified that this works with notebook 6.0.3 and 6.1.1.
Fixes https://github.com/microsoft/azuredatastudio/issues/11607

Coverage increased (+0.0007%) to 37.843% when pulling 316b1cae9b8f252a16ba3edc23309d171126fb9b on corivera/notebookStartRegex into 0c3798ae26d5fa26d6b7464691d7cd7ea94f6121 on main.


JournalDB updates: stop swallowing KeyError & keep diff if persist() errors

What was wrong?

KeyError was being swallowed during persist(), which caused some painful debugging
On any kind of error during persist(), JournalDB was dropping all its changes on the floor (those that haven't yet been persisted, anyway)

(Pulled from #1735)
How was it fixed?

Track whether the wrapped DB has the key, and don't attempt delete if it was already missing (slight performance benefit, too)
Catch exceptions and rebuild the pending diff of changes so that persist() can be reattempted after catching an exception

Cute Animal Picture

Ok, I'll go ahead and merge since I got the :heavy_check_mark: -- if there are any more follow-ups, I'll open a new one.


Active rowset is garbage collected

Rowset is published but is garbaged collected during gc thread.

During publish version stage, it will first add rowset meta to tablet meta and then remove it from rowset meta manager.  If we check tablet meta first and then check rowset meta using 2 step unlocked the sequence maybe: 1. check in tablet meta [return false]  2. add to tablet meta  3. remove from rowset meta manager 4. check in rowset meta manager return false. so that the rowset maybe checked return false it means it is useless and will be treated as a garbage.


Feature/david fibonacci 01

One question, I don't know if is needed put the file package-lock.json inside the .gitignore

I just fixed all the requested changes


Remove need for "backend" block in Terraform modules.

One of the most common issues that Terragrunt users experience is that the "topmost" module that is called from your terraform.tfvars file is expected to have a backend block:
terraform.tfvars:
terragrunt = {
  terraform {
    source = "/my-module/"
  }
}

key1 = val1
key2 = val2

/my-module/main.tf:
terraform {
  # The offending block. The configuration for this backend will be filled in by Terragrunt.
  backend "s3" {}
}

variable "key1" {}
variable "key2" {}
...

In theory, a module should be unopinionated about which backend it implements and the calling code should express this opinion. In practice, Terragrunt works by copying the module to a temp directory and filling in the vars automatically, so it needs a backend block to "hook into".
An alternative way to implement this is to auto-generate a boilerplate Terraform template that calls the original module, but @brikis98 had a concern that we'd be forever playing catch-up to frequently changing Terraform code.
I don't currently agree with that argument, but it's still non-trivial to update Terragrunt to auto-generate new code, so for now, I just wanted to record the issue and let users know this is just about the most common issue we encounter with users.

@josh-padnick Glad you created an issue for this, as I am running into it while creating some example configurations for #169. The discussion came up in that thread in this comment, where @brikis98 suggested exposing variables that you can use to change the configuration of the S3 backend.
However, to make sure I follow your suggestion, you're saying that the larger problem is that my-module/main.tf defines a backend at all, right? If someone wanted to use the Atlas backend, for example, then they would not be able to use that module because it hard codes the S3 backend inline. I am running into this problem during local development of my Terraform modules because I want to use a local backend during dev (working in Terraform only land) and then the S3 backend when running in AWS (Terragrunt land). Since I am new to the tool, my workflow might be off, so feel free to suggest general improvements there.
Can you explain more your idea to "auto-generate a boilerplate Terraform template that calls the original module"?
Here are my thoughts on a potential solution (not sure if it is the same as your idea or not). Basically, I think that because the root terraform.tfvars file already defines the backend configuration, Terragrunt can use that configuration for all child modules automatically by generating a backend.tf file in the temporary directory in which Terraform actually runs. For example:
live/terraform.tfvars:
terragrunt = {
  terraform {
    # The root terraform.tfvars file configures the backend, which should
    # be used as the default for all child environments and modules
    remote_state {
     backend = "s3"
     config {
        bucket = "terragrunt-examples-remote-state"
        key = "${path_relative_to_include()}/terraform.tfstate"
        region = "us-east-1"
        encrypt = true
        lock_table = "terragrunt-examples-lock-table"
      }
    }
  }
}

live/staging/my-module/terraform.tfvars:
terragrunt = {
  # Load the root terraform.tfvars file to get the default backend configuration
  include {
    path = "${find_in_parent_folders()}"
  }

  terraform {
    # The environment terraform.tfvars file tell Terragrunt
    # where to load the Terraform source.
    source = "/my-module/"

   # If we defined a remote_state here, it would override the default
   # configuration defined in the root terraform.tfvars. For example,
   # we could switch backends entirely and have this module use
   # Consul instead of S3 for some reason, but it would still execute
   # the same exact Terraform module code.
  }
}

key1 = val1
key2 = val2

/my-module/main.tf:
# The actual Terraform module does not define a backend in its
# .tf files. This means that by default, it will use the local backend.
variable "key1" {}
variable "key2" {}
...

/var/.../terragrunt-download/.../backend.tf:
# Terragrunt could use the configuration that the user has already defined
# in the root terraform.tfvars file to generate this backend.tf file in the
# temporary directory in which Terraform actually runs.
# Notice that Terragrunt has already resolved the interpolation
# syntax and this file only contains final raw values.
# Terraform would concat this file with all other *.tf files in the directory
# during its run and use whichever backend was defined in this backend.tf file.
terraform {
  backend "s3" {
    bucket = "terragrunt-examples-remote-state"
    key = "staging/my-module/terraform.tfvars"
    region = "us-east-1"
    encrypt = true
    lock_table = "terragrunt-examples-lock-table"
  }
}

Currently, it looks like Terragrunt passes all of backend configuration via the CLI when calling Terraform. Thoughts on instead generating a backend.tf file in the temporary directory where Terraform actually executes?

If this issue is solved, then I think it would also resolve #212

@conorgil I think your understanding is spot on.
I think it's a reasonable approach, with two reservations:

If you're using a terraform { source = "..." } block in your Terragrunt configuration, Terraform checks out the code into a temporary folder.  But what if you don't have a terraform { source = "..." } block in your Terragrunt configuration, generating a backend.tf file into a version-controlled folder gets messy, as now you have this extra file that pops up every time you run terragrunt, you have to add the file to .gitignore, you have to teach developers to never edit it by hand, and so on.

Getting into the code generation business is messy in general:

What if there is already a backend.tf? Instead, we probably have to either generate a randomly-named file or something odd  that is unlikely to conflict, such as __backend__.tf.
Before generating the file, we have to scan the user's code to detect if a backend {} block already exists and log a warning and/or do no code generation if one is found.
If Terraform changes something about the backend block, such as adding new params to it or adding support for interpolation, the generated code is more likely to be backwards incompatible than passing command-line params.

Thoughts?

@brikis98 Great questions. I'll think on this more. Initial questions/responses below:

Hrm. I had not considered the case where there would not be a terraform { source = "..." } block in the Terragrunt configuration. Would the *.tf files just be defined in the same directory as the terraform.tfvars file which contains the Terragrunt configuration? What would the use-case for something like that be?

"Code generation..."

Yea, I thought about the naming issue. We could somehow generate a unique ID and incorporate that into the filename. Something like terragrunt_backend_<id>.tf and also include the classic autogenerated comment saying "This file is automatically generated by Terragrunt. Changes to this file will be overridden. Please see  for more details" and link to some docs.

I guess if we didn't do this and they already had a backend, crazy insane things would happen when Terraform tried to run. Hopefully, it would just error and shout about multiple backends. This would be a pain, but shouldn't be too bad to write. I think the UX gain for most Terragrunt users would warrant the effort.

Why do you think that the generated code would be more backwards fragile than CLI flags?
If new params are added to the backend block, then the user would first have to update the Terragrunt configuration to add the new params/keys. Then, Terragrunt could still just copy that stanza into the backend.tf file.
If Terraform updates to support interpolation in the backend stanza, then Terragrunt would already run into problems because we support interpolation in remote_state stanza already and it is the same syntax, right? Not quite sure how we would solve that off hand, but I also don't immediately see how CLI flags would make it easier to support. Am I missing something?

Would the *.tf files just be defined in the same directory as the terraform.tfvars file which contains the Terragrunt configuration? What would the use-case for something like that be?

Yep. This was actually the "normal" way of using Terragrunt for most of its life! The support for downloading source code into a temporary folder was only added part of the way through :)

Why do you think that the generated code would be more backwards fragile than CLI flags?

My hunch is that what we're seeing now of the backend block is just version 0.1, and that many changes will be coming to it over the next few releases, whereas the CLI, in general, is a bit more mature and stable. I don't have any data to back that up, of course, and during the Terraform 0.9 upgrade, both the CLI and the code had backwards incompatibilities, but that's my guess :)

Yep. This was actually the "normal" way of using Terragrunt for most of its life! The support for downloading source code into a temporary folder was only added part of the way through :)

Always interesting learning about a project after it has gone through some iterations. I did not realize that was the "normal" way of using Terragrunt historically. Though, now that I stopped to think and remembered that remote state locking was one of (if not the) primary feature for Terragrunt, it does kinda make sense that it could have been used inline for that.
My initial thought is that the automatically generated file still seems like a good solution. It would be very easy to debug what Terragrunt is doing under the hood by inspecting that file. For users using remote source, they won't run into problems because of the temp directory. For users using local source, they would have to add it to their gitignore. This would be a pain for those users, but we could make the filename consistent to make it less painful.
Also, given that Terraform now natively supports remote state locking and Terragrunt has correspondingly removed support for remote state locking (delegating to Terraform), do you think that using Terragrunt with local source is still a popular use-case? The "best practice" concepts outlined in #169 all favor a directory hierarchy that uses remote source as far as I can tell. Do you think that it is a reasonable stance to just say that as the tool has grown over time, remote source has emerged as the recommended best practice, so that we don't have to worry about legacy use-cases in this circumstance? Given, we'd need to provide a reasonable transition period for those types of things normally, but because there is an easy alternative (update .gitignore) it hopefully wouldn't be too painful in this case.

My hunch is that what we're seeing now of the backend block is just version 0.1, and that many changes will be coming to it over the next few releases, whereas the CLI, in general, is a bit more mature and stable. I don't have any data to back that up, of course, and during the Terraform 0.9 upgrade, both the CLI and the code had backwards incompatibilities, but that's my guess :)

I agree that the backend will likely undergo lots of changes since it is new and Terraform seems pretty comfortable with breaking changes as long as they are documented well and users have a clear transition path. However, what I am not following is why the CLI and backend block would change independently. If the keywords in the backend block change, then the keys in the CLI would have to change too, right? Even if the CLI continues to follow the pattern of -backend-config=key=value, the keys would both change in the CLI and the backend block, right?
A good example of this happening just recently is actually https://github.com/hashicorp/terraform/pull/14949, where they updated the S3 backend to replace the lock_table keyword with dynamodb_table. In the PR, they updated both the S3 backend and the CLI. The lock_table keyword is deprecated as of the next release and once it is removed, I would expect using it in the backend block as lock_table = my_table and also on the CLI as -backend-config=lock_table=my_table would both break at the same time.
Thoughts?

Also, given that Terraform now natively supports remote state locking and Terragrunt has correspondingly removed support for remote state locking (delegating to Terraform), do you think that using Terragrunt with local source is still a popular use-case?

Yes, it is. Since Terraform's backend doesn't support interpolation, many people use Terragrunt to avoid having to copy/paste the same backend settings to dozens of models. The support for declaratively defining CLI commands (extra_arguments) and running Terraform against multiple modules in parallel (apply-all, destroy-all) are also used with the "normal" Terraform folder structure.

Even if the CLI continues to follow the pattern of -backend-config=key=value, the keys would both change in the CLI and the backend block, right?

Yes, but Terragrunt currently blindly copies all the keys in the config {} block to the init command. In other words, it's largely agnostic to what the keys or values are, so it's more likely to continue to work, even as Terraform changes those keys.

Yes, it is.

Thanks for the background. Makes sense.

Yes, but Terragrunt currently blindly copies all the keys in the config {} block to the init command. In other words, it's largely agnostic to what the keys or values are, so it's more likely to continue to work, even as Terraform changes those keys.

That makes sense. The file solution should be agnostic in the same way. It would just copy over the keys from the terraform.tfvars file into the generated backend.tf file. However, given that the logic for the CLI flags already exists, that is definitely reason to not write new code for the sake of writing new code. If the file solution isn't definitively better, then leveraging existing code first makes sense.
If a user already has defined a backend stanza, the CLI approach would have to figure out how to handle that in the same way as the file approach, right? Are there any other shared pieces of work between the two approaches?

The file solution should be agnostic in the same way. It would just copy over the keys from the terraform.tfvars file into the generated backend.tf file.

It's a bit more complicated. First, we'd have to check if the code already has a terraform block. There very well could be one to define, for example, the minimum Terraform version. If there already is one, it's not clear if it's OK to define another one? Would Terraform merge them? Overwrite? Throw an error? Second, if there is already a terraform block, we should check if it already defines a backend. If so, I suppose we do nothing? Failing those two, we generate the nested blocks and fill in the keys as passed by the user. That'll work OK until Terraform decides to change the backend block syntax...

Fair point on the potential for multiple terraform blocks. Quick test on the following main.tf:
terraform {
  required_version = "> 0.9.0"
}

terraform {
  backend "s3" {
    bucket = "some-other-bucket"
    key    = "some-other-key"
  }
}

yields an error:

Error loading configuration: Error loading /some/path/main.tf: only one 'terraform' block allowed per module

So, that would seem to rule out the simple solution of just generating a backend.tf file, especially if the user has already defined a terraform block somewhere in their configuration. It doesn't make sense to generate a file in some cases and not others, to I think this is evidence to support the CLI flag approach.
However, I think that the CLI approach will require scanning the Terraform code as well.
The following main.tf file:
terraform { }

and then running the command:
terraform init -backend-config=bucket=some-command-line-bucket -backend-config=key=some-command-line-key -backend-config=region=us-east-1

works without error, but does not write anything to .terraform/terraform.tfstate file, so it is essentially a noop.
However, the following main.tf:
terraform {
  backend "s3" {
    bucket = "some-bucket"
    key    = "some-key"
  }
}

and then running the command:
terraform init -backend-config=bucket=some-command-line-bucket -backend-config=key=some-command-line-key -backend-config=region=us-east-1

works without error and writes the following backend information to .terraform/terraform.tfstate:
"backend": {
        "type": "s3",
        "config": {
            "bucket": "some-command-line-bucket",
            "key": "some-command-line-key",
            "region": "us-east-1"
        }
}

Therefore, I believe that Terraform requires a backend block to be defined in the configuration for it to write the backend settings to the .terraform/terraform.tfstate file and the CLI flags to have an impact. Also, note that the CLI flags overwrite the values of the backend block defined in the configuration, so we'll need to figure out how to handle that situation (error, warn user, automatically overwrite, etc).
Implementing a solution for this issue is definitely trickier than I initially thought. Glad we're talking it through and getting ideas and details written down to figure out the best solution (which I am unsure of at this point)!

Error loading configuration: Error loading /some/path/main.tf: only one 'terraform' block allowed per module

Ah, good to know.

Therefore, I believe that Terraform requires a backend block to be defined in the configuration for it to write the backend settings to the .terraform/terraform.tfstate file and the CLI flags to have an impact.

Yes, it does, and it's in our documentation that you have to define a backend block yourself.

Implementing a solution for this issue is definitely trickier than I initially thought.

Indeed. The CLI solution isn't great, but it's workable for now. My vote is to wait and see how the backend stuff evolves in Terraform 0.10 before investing too much more.

My vote is to wait and see how the backend stuff evolves in Terraform 0.10 before investing too much more.
Sounds good

As of https://github.com/gruntwork-io/terragrunt/pull/302, Terragrunt now checks if a backend is defined, and exits with an error if it's missing. I hope that's a decent compromise solution for this.


Sprite Inconsistency Fix 1

About the PR

This pr makes very minimal changes to some sprites in order to bring them up to date with other goob station assets
Why / Balance

Due to some sprites being copied from other stations there are some inconsistency between some goobstation sprites. this pr aims to fix that by recoloring some sprites to match others of its type and adding more detail to others. most changes are very minor
Technical details

Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

grey jumpsuit
rubber gloves
cargo softcap
bartender
chef
BSO armored suit
lawyer suits
Hydro
Librarian
wood  tables
mailman
trooper
safari

Summary by CodeRabbit

New Features

Updated copyright attributions for the janitor, cargosoft, and wood textures to acknowledge recoloring by InfinityRedPanda.

Bug Fixes

Corrected copyright information to ensure proper credit for the recoloring of resources.

looks good, but i feel it doesnt worth time to changing 1-2 pixels to fit something  like why..,

do you want me to change it back?

I wanted to get in contact with you on discord but im not sure what your tag is, mind throwing me a DM @ gaming420 on disc?


bad pixel correction feature

@kylechampley  Is there any bad pixel correction feature at Leap?  I can see that if the detector has some dark or white bad pixel then I can see below result slice at a specific slice. I adapted a blur filter when it reads  projection images, but that can not cover this issue(dark circle).

Yes, there is. See the “outlierCorrection” algorithm. There is a demo script for this, see d14_outlierCorrection.py

I checked both your outlierCorrection(A) and outlierCorrection_highEnergy(B). And I can see that the first one does not fully cover this issue, there is still dark circle. But the second one(B) can cover fully this issue, so I can not see any dark circle.
The second method needs more time to do for three times filer_2d.

You should be able to get better results from the standard outlier correction algorithm. Try using a bigger window size

Yes it is. Windows size is critical factor. The size bigger than 5 of  the standard outlier correction works well for my case. Thanks.

I will close this issue.


Chore: RPC integration testing with cloud

Description
The Cloud component is required since the local and remote contexts need to be on different machines to properly test the client exchange stuff.
During planning, the file path gets canonicalized into an absolute path, and so if both contexts are on the same machine, then they're both able to read that file. If they're both able to read it, then we're not really checking if the local file reads are working as expected.

For posterity: I took this off of next, but it shouldn't be de-prioritized. Will consider adding to next + 1 milestone


docker-compose role failed on downloading docker-compose task

I tried to run ansible-playbook nginx.yml
However, it failed at docker-compose role
The error is following
TASK [docker-compose : Executable is present] **********************************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "dest": "/usr/local/bin/docker-compose", "failed": true, "msg": "Request failed", "response": "Request failed: <urlopen error [Errno -5] No address associated with hostname>", "state": "absent", "status_code": -1, "url": "https://github.com/docker/compose/releases/download/1.7.1/docker-compose-Linux-x86_64"}

However, i tried wget with that url and it look fine...
vagrant@cd:~$ wget https://github.com/docker/compose/releases/download/1.7.1/docker-compose-Linux-x86_64
--2016-06-11 12:04:28--  https://github.com/docker/compose/releases/download/1.7.1/docker-compose-Linux-x86_64
Resolving github.com (github.com)... <IP_ADDRESS>
Connecting to github.com (github.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-cloud.s3.amazonaws.com/releases/15045751/ce36ff8a-1208-11e6-8249-a17669a3f0bf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20160611%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20160611T120430Z&X-Amz-Expires=300&X-Amz-Signature=2e139a682cbbb6e79326c94d7b0e7fcbf8f4bf959b30d052679a30c24b9cd08f&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Ddocker-compose-Linux-x86_64&response-content-type=application%2Foctet-stream [following]
--2016-06-11 12:04:30--  https://github-cloud.s3.amazonaws.com/releases/15045751/ce36ff8a-1208-11e6-8249-a17669a3f0bf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20160611%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20160611T120430Z&X-Amz-Expires=300&X-Amz-Signature=2e139a682cbbb6e79326c94d7b0e7fcbf8f4bf959b30d052679a30c24b9cd08f&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Ddocker-compose-Linux-x86_64&response-content-type=application%2Foctet-stream
Resolving github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)... <IP_ADDRESS>
Connecting to github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7963477 (7.6M) [application/octet-stream]
Saving to: ‘docker-compose-Linux-x86_64’

 0% [                                                                                ] 59,970      19.9KB/s

Can you please rerun the same Ansible command with additional "-vvvv" argument and send me the output of the task that fails?

Closing due to inactivity.


[Bug]: Text overflow in contest name container

Contact Details
<EMAIL_ADDRESS>What happened?
The title text "SuntoryProgrammingContest2024 (AtCoder Beginner Contest 357)" is overflowing outside the container box meant to display the contest name. The text is getting cut off and extending beyond the container boundaries.
What was expected to happen?
The contest name should fit fully within the provided container box without any text overflow or truncation. The container should be able to accommodate the complete title text without cutting it off.

What browsers are you seeing the problem on?
Firefox, Chrome
Relevant log output
No response
Are you interested in contributing?

[X] I'd like to work on this issue

Code of Conduct

[X] I have used the search function to check if an issue already exists
[X] I agree to follow this project's Code of Conduct

Which program are you contributing in?
gssoc

duplicate #822


enable server end pagination for project list

This commit is to support the server end pagination in the project list view. It is already merged into the master branch before. As we're planning to release a new version 1.2.x, use cherry-pick to add it in 1.2.0 branch.

Coverage decreased (-3.7%) to 51.144% when pulling 380f0ae8b4d16eccf92ff49a4100bcaace1f9262 on steven-zou:release-1.2.0 into b3e32c7b1e00b1634efc204f8ced124d0518af17 on vmware:release-1.2.0.

As for the build break, could you update the tag of admiral in the script on 1.2.0 branch?
please refer to: https://github.com/vmware/harbor/blob/master/tests/admiral.sh

Coverage decreased (-0.05%) to 54.819% when pulling d379c7b0fdb775b9d6b9ea3a33148b721cb1d658 on steven-zou:release-1.2.0 into b3e32c7b1e00b1634efc204f8ced124d0518af17 on vmware:release-1.2.0.


Add code formatting check to travis matrix

Formatter does not change not foo in bar to foo not in bar anymore :)
I can also open PR to branch 1.0 if you prefer.

I'd merge that, but I have similar changes in 1.0 branch. Let's keep it open and I'll apply the changes manually, thanks!

Applies into 1.0, thanks!


rename package

go-c3-sdk -> c3-go-sdk

personally i think it's strange to have the language in the middle
<language>-<project>-<library> (e.g ipfs,libp2p)
<project>-<library>-<library> (e.g. aws)

agreed. let's move it to the last thing: <project>-<library>-<language>


Malformed struct tag in /internal/guestrequest/types.go

Testing a new lint rule of revive on K8S code base highlighted a struct field annotated with a malformed (lack of ") JSON tag.
https://github.com/microsoft/hcsshim/blob/1085c8f569e1e3a07ce2ebcc921a952aa4b1af50/internal/guestrequest/types.go#L99

Thanks for reporting. Out for PR


Supply Abstract Data implementations for Plugin usability

With the stability of abstract DataManipulator implementation in SpongeCommon, I feel it's safe to now supply these abstractions for plugin usage. Little should change at this point.

@gabizou
I want to see the generics get proper names and explained before merge since plugin devs do need to know what is going on here.
Same for the classes themselves.


new class for performed notes

Hello in this PR I'm addressing partially issue #293 but also adding some checks for Performed Notes.
A performed Note is still a dict but with some extra checks and properties.
Current checks are failing because one of the Performed Note conditions is not satisfied from a match file.
Please review to know if the checks are too strict or if the file is problematic.
(re-opening because checks were not launched)

Potentially this addition should also consider Program changes and Controls as their own instances. Writing this here to open a discussion.

I left some comments on the code for things to double check

Codecov Report
Patch coverage is 58.76% of modified lines.

Files Changed
Coverage

partitura/performance.py
49.33%

partitura/utils/music.py
50.00%

partitura/io/importmatch.py
100.00%

:loudspeaker: Thoughts on this report? Let us know!.

One of my points is still open: I suggest to remove repr function. Then I suppose it will go by the dictionary default of using all keys and values

One of my points is still open: I suggest to remove repr function. Then I suppose it will go by the dictionary default of using all keys and values

Yes, I though you wanted to correct this part of the code although it should be fairly simple. This is why I didn't resolve this.


IO throughput performance of reading small size files is lower than expected

Is your feature request related to a problem? Please describe.
When I use the follow command to carry out the reading performance test.
./bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully  --base alluxio://*.*.*.*:19998/stress-client-io-base --file-size 102400 --threads 64 --clients 64 --read-type NO_CACHE --warmup 5s --duration 30s

And the file-size is 100KiB, alluxio client file cache is disabled, meta cache is enabled.  Worker files cache  store in ramdisk, client and worker is deployed two machine.
The network throughput can only reach 4GB/s
When I  execute stressclientIObench command using one client, the server network info is displayed in the screenshot below:

the cpu info:

the client network info is displayed in the screenshot below:

When I  execute stressclientIObench command using two clients,  the network IO throughput has not improved.  The worker network info is displayed in the screenshot below:

the cpu info:

the two clients network info is displayed in the screenshot below:

However, when I use grpc-java directly to test the network throughput can reach 5.4GB/s with the 100KiB response under the same machine environment. And test code can be provided if needed.

the CPU info:

How can I modify the configuration to improve QPS
the machine environment ：
CPU
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   46 bits physical, 48 bits virtual
CPU(s):                          104
On-line CPU(s) list:             0-103
Thread(s) per core:              2
Core(s) per socket:              26
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 8270 CPU @ 2.70GHz
Stepping:                        7
CPU MHz:                         2700.000
CPU max MHz:                     4000.0000
CPU min MHz:                     1000.0000
BogoMIPS:                        5400.00

mem
              total        used        free      shared  buff/cache   available
Mem:          1.0Ti       7.6Gi       684Gi       113Mi       315Gi       962Gi
Swap:            0B          0B          0B

network
        Speed: 50000Mb/s
	Duplex: Full
	Port: Other
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: off
	Link detected: yes

Describe the solution you'd like
How can I modify the configuration to improve QPS
Additional context
this is conf/alluxio-site.properties file content
# Worker properties
# alluxio.worker.ramdisk.size=1GB
# alluxio.worker.tieredstore.levels=1
# alluxio.worker.tieredstore.level0.alias=MEM
# alluxio.worker.tieredstore.level0.dirs.path=/mnt/ramdisk

# User properties
alluxio.user.metadata.cache.enabled=true
alluxio.user.metadata.cache.expiration.time=2h
alluxio.user.metadata.cache.max.size=2000000

alluxio.user.update.file.accesstime.disabled=true
alluxio.user.client.cache.dir = /data/alluxio_cache/
alluxio.user.client.cache.enabled = false
alluxio.user.client.cache.size =  100GB

alluxio.fuse.jnifuse.libfuse.version=3
alluxio.fuse.web.enabled = true

alluxio.fuse.cached.paths.max=1000000

alluxio.user.network.rpc.flowcontrol.window = 20MB
alluxio.user.network.rpc.max.connections = 1024
alluxio.user.network.rpc.netty.worker.threads = 1024
alluxio.user.network.streaming.flowcontrol.window = 20MB
alluxio.user.network.streaming.max.connections = 1024
alluxio.user.network.streaming.netty.worker.threads = 1024
alluxio.user.streaming.reader.buffer.size.messages = 128
alluxio.user.streaming.reader.chunk.size.bytes = 10MB

Alluxio cluster summary:
    Master Address: *.*.*.*:19998
    Web Port: 19999
    Rpc Port: 19998
    Started: 08-03-2022 15:38:07:184
    Uptime: 2 day(s), 2 hour(s), 30 minute(s), and 5 second(s)
    Version: 2.8.0
    Safe Mode: false
    Zookeeper Enabled: false
    Raft-based Journal: true
    Raft Journal Addresses:
        *.*.*.*:19200
    Live Workers: 1
    Lost Workers: 1
    Total Capacity: 671.37GB
        Tier: MEM  Size: 671.37GB
    Used Capacity: 12.50MB
        Tier: MEM  Size: 12.50MB
    Free Capacity: 671.36GB

# alluxio-env.sh
ALLUXIO_MASTER_JAVA_OPTS="-Xmx128G -Xms128G -XX:+UseG1GC"
ALLUXIO_WORKER_JAVA_OPTS="-Xmx32G -Xms32G -XX:MaxDirectMemorySize=32G -XX:+UseG1GC"
ALLUXIO_FUSE_JAVA_OPTS="-Xmx32G -Xms32G -XX:MaxDirectMemorySize=32G -XX:+UseG1GC"

@dbw9580 Hi, can you help with this issue?

What StressClientIOBench does when reading a file is that it opens the file, reads until the end, then closes it and repeats this process. It involves a round trip to the master to get the file status first, and then retrieves the data from a worker. Master's response of the file status typically takes 2KB ~ 4KB, which is small compared to the file size, but it takes some time at the master's side, and is blocking for the client.
Did you monitor master resource usage and make sure it's not the bottleneck? Can you try tweaking StressClientIOBench so that it does not close the stream after the file is read to the end and then reopen it, but reuses the stream by seeking to the beginning? This way the round trip to master can be avoided.

@dbw9580 Thanks for reply!
During the StressClientIOBench, the client has already opened the meta cache. In this case, will the master be requested？ (not the first time).
And I didn't see any obvious network requests from the packet capture in the master.

By the way, which option in the  StressClientIOBench  can reuses the stream?

OK I see metadata is cached at the client side. There should be no master-client rpc overhead then.
How is the test data written to Alluxio? Is it fully cached by the worker? I see neither CPU nor memory is the obvious bottleneck, can you please do some profiling to see what the worker is spending its time on?

OK I set the alluxio.user.file.writetype.default=MUST_CACHE
I used the Write operation of the StressClientIOBench command to write the test data to Alluxio, the complete command is followed:
./bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation Write  --base alluxio://*.*.*.*:19998/stress-client-io-base --file-size 102400 --threads 64 --clients

The data is fully cached by the worker.
I got a cpu profile file,can you help me take a look at this file.
1_64_cpu.html.zip

@dbw9580 There is a discovery wish it would do help on your analysis of this performance issue. It seems that the read performance worker could provide is constrained by some concurrency process limit and reaches maximum when incoming concurrency requests are near 128, here is the situation:
all the below tests adopt the common configuration:
alluxio.user.metadata.cache.enabled=true
alluxio.user.metadata.cache.expiration.time=2h
alluxio.user.metadata.cache.max.size=2000000
alluxio.user.update.file.accesstime.disabled=true

And client is xxx.xxx.xxx.138, worker is xxx.xxx.xxx.139

stress on worker with a single StressClientIO and client adopts the default values for alluxio.user.network.rpc.max.connections  and alluxio.user.network.streaming.max.connections, which are:

alluxio.user.network.rpc.max.connections = 1
alluxio.user.network.streaming.max.connections = 64

Run the read stress test:
./alluxio-2.8.0/bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://xxx.xxx.xxx.139:19998/stress-client-io-base --file-size 100k --threads 256 --warmup 5s --duration 30s
During the test period, client established 65 connections with worker:

And make worker cpu usage reach about 1300% during test

making us get the read performance from worker at about 2.1GB/s
2022-08-15 20:57:29,637 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 2074.031738

run two StressClientIO bench simultaneously with the same client configuration as Test 1:

mpirun -np 2 ./alluxio-2.8.0/bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://xxx.xxx.xxx.139:19998/stress-client-io-base --file-size 100k --threads 256 --warmup 5s --duration 30s
During the test period, client established 130 connections with worker:

And worker cpu usage could increase to about 2400% during test

Making the read performance from worker increase to about 3.4GB/s
2022-08-15 20:59:36,874 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 1712.063232
2022-08-15 20:59:36,894 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 1716.617676

stress on worker with a single StressClientIO, but this time change the alluxio.user.network.rpc.max.connections to 1024:

alluxio.user.network.rpc.max.connections = 1024
alluxio.user.network.streaming.max.connections = 64

Run the single read stress test:
./alluxio-2.8.0/bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://xxx.xxx.xxx.139:19998/stress-client-io-base --file-size 100k --threads 256 --warmup 5s --duration 30s
During the test period, client established 320 connections with worker:

At this time, the worker cpu usage could reach about the same utility(about 2500%) as Test 2:

And the read performance of this single StressClientIO is also the same as Test 2(which used two StressClientIO instances, but each one creates 65 connections with worker)
2022-08-15 21:10:46,620 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 3457.203613
Compares the Test2 with Test3, we see that worker read performance isn't decided by the number of StressClientIOBench instances, but by the connection numbers they create with alluxio worker, as long as the aggregate connection number reaches beyond 128(test2 is 130), it could get the 3.4GB/s bandwidth and after that it couldn't boost any more even though we continue increasing the connection number (neither by increase the StressClientBench instance number nor by increase thread number of StressClientIOBench instance)
In order to verify this assumption, we did the fourth test:
4. stress on worker with two single StressClientIO instances, each with the client configuration same as Test 3:
alluxio.user.network.rpc.max.connections = 1024
alluxio.user.network.streaming.max.connections = 64

Run the read stress test:
mpirun -np 2 ./alluxio-2.8.0/bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://xxx.xxx.xxx.139:19998/stress-client-io-base --file-size 100k --threads 256 --warmup 5s --duration 30s
now they create 640 connections with worker:

But this time, the worker cpu usage remains the same utility(about 2500%) as Test 2 and Test 3:

And the aggregate read performance that worker provides is also about the same as Test 2 and Test 3:
2022-08-15 21:12:39,181 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 1638.822632
2022-08-15 21:12:39,184 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 1642.981079

In a summary, it seems that the worker could just handle at most 128 concurrent read requests, which seems there is some software limit on its concurrent process ability, then we tried to adjust the alluxio.worker.network.netty.worker.threads, but it doesn't take effect after setting it to 512 or 1024, the performance remains the same.
So do you have any idea about this? @dbw9580

@JianyuLi @LKR1996 thanks for the porfiling report.

Looks like it spends quite some time acquiring the block lock when reading the block file. Can you try increasing the number of block locks? You can set alluxio.worker.tieredstore.block.locks and alluxio.worker.tieredstore.block.lock.readers to a higher value (both have a default value of 1000) and see if it makes a difference.

@dbw9580
change the below configuration from default 1000 to 10000 for worker and restart it:
alluxio.worker.tieredstore.block.locks=10000
alluxio.worker.tieredstore.block.lock.readers=10000

Repeat above Test 3: stress on worker with a single StressClientIO whose client configuration as below:
alluxio.user.network.rpc.max.connections = 1024
alluxio.user.network.streaming.max.connections = 64

The worker cpu usage and final read performance are still the same:

2022-08-16 21:19:06,081 INFO  StressClientIOBench - thread count: 256, errors: 0, IO throughput (MB/s): 3341.894043
And here is the cpu profile result this time, please have a look.
cpu.html.zip

Looks like it's actually the mSharedMapsLock that is heavily contended, rather than the individual block locks. Can you take a jstack snapshot and see if the threads are all waiting for this lock?
https://github.com/Alluxio/alluxio/blob/7cbad50484612f5c8270e120418995fef775c664/core/server/worker/src/main/java/alluxio/worker/block/BlockLockManager.java#L206
@beinan what do you think? the performance of the worker seems to have hit a bottleneck here.

@dbw9580 Collect four jstack snapshots of worker during test, we do see that there are many BockDataReaderExecutor waiting for mSharedMapsLocks:

Here are the details stack logs:
jstack-logs.zip

Further we collect the cpu wall time profile under Test1 & Test2:

Test1: single StressClientIO and client adopts the default values, which get the read bandwidth of 2.1GB/s

alluxio.user.network.rpc.max.connections = 1
alluxio.user.network.streaming.max.connections = 64

The whole DataReader.runInternal just accounts for 0.92%

Test2: two StressClientIO and client adopts the default values which get the aggregate read bandwidth of 3.4GB/s
this time the DataReader.runInternal percentage increases to 17.04%

which contains lots of lock wait:

Details wall time profile please refer to:
wall_profile.zip
Hope the wall time profile comparison would be helpful!

@beinan @dbw9580 Is there any new ideas about this issue?

I have a PR that removes the shared lock #16078 . Can you give it a try? @JianyuLi

Tried with branch https://github.com/dbw9580/alluxio/tree/fix/block-lock-manager-remove-lock, the peak read bandwidth & cpu usage of worker during test has break the previous limit, details are as below:

Test1: single StressClientIO and client adopts the default values, which get the read bandwidth of 2.1GB/s

alluxio.user.network.rpc.max.connections = 1
alluxio.user.network.streaming.max.connections = 64

For the cpu wall time profile, DataReader.runInternal percentage decreased from 0.92% to 0.31%

Four StressClientIO and client adopts the default values which make the peak read bandwidth reached near 4.9GB/s & cpu usage of worker to 31 cores during test:
mpirun -np 4 <alluxio_base>/bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://<master_address>:19998/stress-client-io-base --file-size 100k --threads 256  --warmup 5s --duration 30s

this time the DataReader.runInternal percentage just increases from 0.31% to 1.37%, compared with previous 17.04%

The detailed wall profile results please refer to:
wall_profile.zip

@dbw9580 your improvement in #16078 solved the problem issue we met here and in #16040. We are looking forward to this MR be merged in master, thanks!

@dbw9580 your improvement in #16078 solved the problem issue we met here and in #16040. We are looking forward to this MR be merged in master, thanks!

Thanks for the feedback! I'll have the PR reviewed and merged soon.
In the meantime, I noticed that in your last profiling graph the call to SerializingExecutor.execute is blocking on a task queue and taking a lot of time. I suspect that is caused by its task queue which is a bounded blocking queue with a fixed capacity of 32:
https://github.com/Alluxio/alluxio/blob/64648e7db5789b6ca58751c34771e651b373fd71/core/server/worker/src/main/java/alluxio/worker/grpc/GrpcExecutors.java#L58-L63
It's shared among all instances of BlockReadHandler:
https://github.com/Alluxio/alluxio/blob/64648e7db5789b6ca58751c34771e651b373fd71/core/server/worker/src/main/java/alluxio/worker/grpc/BlockReadHandler.java#L131-L132
Coincidentally, in your observations, the CPU usage is capped at around 3020%. Can you please try adjusting the capacity of this queue to a larger value and see if it improves throughput?

@dbw9580 increase the capacity of BlockingQueue for BLOCK_READER_SERIALIZED_RUNNER_EXECUTOR from 32 to 64:

The read bandwidth of StressClientIO and cpu usage during test don't change.
And the Block Reader related metrics during two times 180s StressClient test are as below:
./bin/alluxio runClass alluxio.stress.cli.client.StressClientIOBench --operation ReadFully --base alluxio://<master_address>:19998/stress-client-io-base --file-size 100k --threads 256  --warmup 5s --duration 180s

From the BlockReaderThreadActiveCount, we saw that there were more than 32 active read threads concurrently process read requests at some time, but this heavy load didn't last long, more details could see the csv metric dump file:

details please refer to Worker.BlockReaderThreadActiveCount.csv
cpu wall time profile during test please refer to
wall.html.zip

@dbw9580 Does master have the same issue? I read master metadata just can reach 18w qps. And CPU just can reach 900%

It's possible, but hard to tell without a detailed description of how you
did your tests, and some flamegraph showing what master is spending its
time doing.
Best regards,
Bowen
tokingHong @.***> 于 2022年9月21日周三 20:20写道：

@dbw9580 https://github.com/dbw9580 Does master have the same issue? I
read master metadata just can reach 18w qps. And CPU just can reach 900%
—
Reply to this email directly, view it on GitHub
https://github.com/Alluxio/alluxio/issues/16022#issuecomment-1253628772,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVM5HFDPGLAMRVAHZDM2A3V7L4QJANCNFSM55VNIMTQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Reverse for 'complete' with arguments '(u'twitter',)' and keyword arguments '{}' not found

I have integrated social-auth with my project and now when I am creating a template and trying to use it, this error comes up. I am a bit new to this,, hence un-able to solve this issue.
Please tell what I have done wrong. I am working on local server, and I have filled the correct consumer keys. I hope I can try out this while running on the local server?

Check the reverse, it must be socialauth_complete instead of complete.


lact crashed (sigsegv) at recent kernels (6.5/6.6)

Card is Vega10:
lshw -C display
  *-display
       description: VGA compatible controller
       product: Vega 10 XL/XT [Radeon RX Vega 56/64]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:09:00.0
       logical name: /dev/fb0
       version: c7
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=amdgpu latency=0 resolution=5120,1440
       resources: irq:77 memory:e0000000-efffffff memory:f0000000-f01fffff ioport:2000(size=256) memory:f0600000-f067ffff memory:f06a0000-f06bffff

Crashed just upon start - no tweaks or overclocking ever applied. Crash never occurred at 6.4.x kernels.
lact-v0.4.5.amd.bug.txt

That is extremely weird. I'm also running a Vega 56 on the 6.5 kernel, and I cannot reproduce this.
Do the GPU reset errors occur when LACT is not enabled? And is LACT enabled to start on system boot, or do you start it later manually?

The reset with kernels > 6.4 is occured even when LACT is not launched but very rare (once per day) but it always accured when I launch LACT. I pretty sure this is real kernel problem but submitting and waiting for bug report at ketnel.org can take years

Can supply any additional info (straces or so)

Please try the following:

Install the latest build from the master branch (either from the test release or using the lact-git AUR package if you are on an arch-based distro)
Edit /etc/lact/config.yaml and set log_level: trace under daemon. If it doesn't exist, here's the minimal required contents:

daemon:
  log_level: trace
  admin_groups:
  - wheel
  - sudo

Start the service (systemctl start lactd)
Run the gui with lact gui --log-level trace

This should provide detailed logs (in both the daemon and gui) for what exactly is happening during the crash

Daemon do not starts. Any config example exists ?
lact daemon
Error: Could not deserialize config

Caused by:
    missing field `gpus`

Added
gui: {}

And it starts. In short: lact sigsegv's when no daemon is launched. No sigsegv with daemon. GPU crash occurring in both cases - as with daemon as without. Logs attached
lact-daemon.log
lact-gui-with-daemon.log
dmesg-with-daemon.txt
lact-gui-no-daemon.log
dmesg-no-daemon.txt

BTW:
ubsan.txt
Kernel build with UBSAN shows warnings in amdgpu driver

BTW: Kernel build with UBSAN shows warnings in amdgpu driver
ubsan.txt

Ignore this - it is false warning and fix is already present in 6.7

Can't reproduce GPU crash with amdgpu.mcbp=0 kernel cmd option

Do you still get a segfault with the kernel option that resolves the crash? The application logs seem perfectly normal in all of the scenarios - even in lact-gui-no-daemon where there is a segfault in dmesg. Does the segfault happen after the log you posted?
The UBSAN log mentions an error when reading the power table - this would make sense, as both the standalone gui and gui with daemon try to read it to display clocks info. If the kernel crashes from that, there's not much that can be done from LACT's side to avoid it.

The lact (0.4.6) sigsegv's just after launch when no daemon present - see the start of dmesg-no-daemon.txt :
[Nov 6 06:09] lact[16171]: segfault at 7fddcf1ff910 ip 00007fdde1c9651b sp 00007fdddddda610 error 4 in libc.so.6[7fdde1c28000+195000] likely on CPU 0 (core 0, socket 0)
[  +0.000017] Code: 0f 1e fa 41 57 41 56 41 55 41 54 55 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 87 d0 02 00 00 48 89 fb 85 c0 0f 88 44 01 00 00 48 39 bf 28 06
[  +0.500052] lact[16181]: segfault at 7fddcf1ff910 ip 00007fdde1c9651b sp 00007fdddddd8ea0 error 4 in libc.so.6[7fdde1c28000+195000] likely on CPU 15 (core 7, socket 0)
[  +0.000016] Code: 0f 1e fa 41 57 41 56 41 55 41 54 55 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 87 d0 02 00 00 48 89 fb 85 c0 0f 88 44 01 00 00 48 39 bf 28 06

Not sure if the SIGSEGV event can be catched by lact - usually process is killed by kernel so you will not see anything at app logs.
The UBSAN kernel warnings are false alram and you can ignore them. The kernel GPU driver do not crash with amdgpu.mcbp=0
The sad problem is that this setting is set to 1 at recent kernels - this is why I did not see it with 6.4.x. Seems like nobody tested the driver before this change.

If this is still relevant: does this occur with recent kernel (6.7) and lact (0.5.2) versions?

App still crashes when no daemon present, kernel v6.7.3:
[Feb 5 06:51] lact[523318]: segfault at 79968bc00910 ip<PHONE_NUMBER>89651b sp<PHONE_NUMBER>3fa340 error 4 in libc.so.6[799693828000+195000] likely on CPU 0 (core 0, socket 0)
[  +0.000018] Code: 0f 1e fa 41 57 41 56 41 55 41 54 55 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 87 d0 02 00 00 48 89 fb 85 c0 0f 88 44 01 00 00 48 39 bf 28 06
[  +0.623788] lact[523329]: segfault at 79968bc00910 ip<PHONE_NUMBER>89651b sp<PHONE_NUMBER>3f9040 error 4 in libc.so.6[799693828000+195000] likely on CPU 14 (core 7, socket 0)
[  +0.000017] Code: 0f 1e fa 41 57 41 56 41 55 41 54 55 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 87 d0 02 00 00 48 89 fb 85 c0 0f 88 44 01 00 00 48 39 bf 28 06

But amdgpu driver do not crash anymore as amdgpu maintainers reverted back amdgpu.mcbp=1 kernel option.

Could you do the following:

Run the app with debuginfo (clone this repo and simply run cargo run, information about required dependencies here)
Check the core dump of when it crashes with coredumpctl info -1 lact

dump.txt

Could you also check strace -f ./target/debug/lact?

strace.txt

Please try the segfault-fix-attempt branch and tell me if it helps (based on the strace, it should fix the issue)

Confirming - no segfaults any more in segfault-fix-attempt branch

Closing


GetDefaultPagesSettings API Failing after upgrading to DNN 9.11.1

After Upgrade from 9.3.2 to 9.11.1, got 500 error in Site Settings->Default pages
http://dnndevupgrade11.me/en-us/API/PersonaBar/SiteSettings/GetDefaultPagesSettings?portalId=undefined&cultureCode=
Seem Issue is parameter --> portalid=undefined
Any one faced this issue? Any Solution for this?

I had this issue in the past with missing values, in the database those values were -1 instead of null or null instead of -1 and it made that part of code choke. I can't remember exactly now (and can't check right this moment) in which table that was, but I feel like in the Portals table... You could compare those values with a clean install, and either null or -1 should not be anywhere...

Looks like it's related to mapStateToProps on BasicSettingsPanelBody, where it missing portalId
https://github.com/dnnsoftware/Dnn.Platform/blob/a3cd23452e5837a3260915fc736edbccceec0a01/Dnn.AdminExperience/ClientSide/SiteSettings.Web/src/components/basicSettings/index.jsx#L381-L402
Due this, most of Api call on SiteSettings has portalId=undefined

PotalId = undefined might not be issue, I see code is already handling null value of portal id. API fails even if set 0 to portal id. I think something wrong in some table in upgrade, will be checking it against fresh installation.

Ok, I now have a database open here, check that in Portals table all PortagGroupID should have a number (no nulls) -1 represents null here...
Then in the PortalLocalization table, it is the reverse, null IS supported and you should not have -1 in:

HomeTabId
LoginTabId
And all the other SomethingsTabId

Figured it out, All was ok as you mentioned. But was missing PortalSettings for PageHeadText. I added it and then was able to do so.


dont use logForObject with nil pointer

the d.account field is known to be nil here, so logforobject will crash on that.  use a plain info log

/retest


bug: ItemReorder+ItemSliding with Ckeckbox not working

Type: bug
Ionic Version: 2.x
Platform: ios 9 webview
When an ion-list is set to reorder="true" with ion-item-sliding, the reorder function does not work on iOS. In the browser with ionic serve, as well as on Android, everything is working fine.
Code to reproduce:
<ion-list no-lines reorder="true" (ionItemReorder)="reorder($event)">
    <ion-item-sliding *ngFor="let item of items">
      <ion-item>
        <ion-label>
            {{item.title}}
        </ion-label>
        <ion-checkbox [(ngModel)]="item.checked"></ion-checkbox>
      </ion-item>
      <ion-item-options side="right">
        <button ion-button icon-only (click)="editItem(item)">
          <ion-icon name="settings"></ion-icon>
        </button>
        <button ion-button icon-only color="danger" (click)="deleteItem(item)">
          <ion-icon name="trash"></ion-icon>
        </button>
      </ion-item-options>
    </ion-item-sliding>
  </ion-list>

When <ion-checkbox [(ngModel)]="item.checked"></ion-checkbox> is commented out, the reorder works on iOS.
When the sliding items are changed to normal items (ion-item-sliding tags as well as ion-item-options block commented out), the reorder also works on iOS.

Hello, thanks for opening an issue with us! We will take a look into this.

Same problem here. Any progress on that?

Any updates on this? Thanks!

See this comment https://github.com/ionic-team/ionic/issues/12760#issuecomment-325470731 for another permutation of this.


393 remember report type

Resolves #393

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

5 of 5 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.005%) to 88.865%

Totals

Change from base Build<PHONE_NUMBER>:
0.005%

Covered Lines:
5397

Relevant Lines:
5787

💛  - Coveralls


fix: Change datasource properties to headings

Changes properties entries in datasource pages from  tags into h4 so that they are linkable.
Resolves #1620
Checklist
I have:

[ ] run the content through Grammarly
[ ] linked to sample apps when relevant
[ ] added the meta description for each page in the PR
[ ] minimized the callouts and added only when necessary
[ ] added the queryString parameter to the Tabs (if used)
[ ] masked PII in images. For example, login credentials, account details, and more
[ ] added images only when necessary
[ ] deleted the images that are no longer used for the updated pages in the PR
[ ] followed the image file naming convention while renaming or adding new images. (Use lowercase letters, dashes between words, and be as descriptive as possible)
[ ] used the <figure/> tag instead of a markdown representation for images
[ ] added the <figcaption/> tag to add a caption to the image
[ ] added the alt attribute in the <img/> tag
[ ] verified and updated the cross-references or created redirect rules for the changed or removed content
[ ] reviewed and applied the style changes for UI formatting. For example, Bold the UI elements(Buttons on screen) used in the doc.

@danciaclara Thanks for the catch! Fixed.


Add experimental/klauspost_snappy package, which might be more efficient than the google snappy package

Relates to #10.

Just a minor tweak.

Thanks- updated.


adapt to incoming changes in cortex-m and cortex-m-rt

:pushpin: Commit 5e2da93 has been approved by japaric

@homunkulus r+

:hourglass: Testing commit 5e2da93 with merge 5e2da93...

:sunny: Test successful - status-appveyor, status-travis
Approved by: japaric
Pushing 5e2da93e941b0557fd7738aca9c30828f80a07f0 to master...


Extend getting started instructions to obtain config-user.yml

First time users that use conda to install esmvaltool might have trouble getting to the config-user file. The docs point to the config-user-example.yml on github, but for those new users it may not be clear how to download a single file from there. This should make it a little bit more accessible.
Tasks

~[ ] Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)~ I figured a PR was the easiest way to explain what I wanted to do.
[x] Give this pull request a descriptive title that can be used as a one line summary in a changelog
~[ ] Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables~
[x] Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
[x] Preferably Codacy code quality checks pass, however a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
~[ ] Please use yamllint to check that your YAML files do not contain mistakes~
~[ ] (Only if really necessary) Add any additional dependencies needed for the diagnostic script to setup.py, esmvaltool/install/R/r_requirements.txt or esmvaltool/install/Julia/julia_requirements.txt (depending on the language of your script) and also to package/meta.yaml for conda dependencies (includes Python and others, but not R/Julia)~
~[ ] If new dependencies are introduced, check that the license is compatible with Apache2.0~

Thanks @SarahAlidoost , I agree this is clearer. Can you approve?


Updates to PR TheFireCo#155

For context, see https://github.com/TheFireCo/genkit-plugins/pull/155 and https://github.com/TheFireCo/genkit-plugins/pull/155#issuecomment-2476616742.

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

Superseded by https://github.com/TheFireCo/genkit-plugins/pull/157


Fixed Selenium grid console displaying null for iOS capabilities

Address the issues reported as part of GitHub issue #324.

this is merged


Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Other
Brief description of your issue
The Yuzu Emulator and a bunch of related tools are being taken down due to settling the court case with Nintendo.
The main yuzu GitHub repo is already privated/gone: https://github.com/yuzu-emu/yuzu, and I expect the other tools to follow shortly.
Packages affected seem likely to be:

YuzuEmu.Yuzu.Mainline
CitraEmu.Citra
eliboa.TegraRcmGUI

Steps to reproduce
winget install YuzuEmu.Yuzu.Mainline, etc.
Actual behavior
Fails/will fail to install
Expected behavior
Fails/will fail to install
Environment
N/A

Screenshots and Logs
No response

Better to redirect it here https://github.com/pineappleEA/pineapple-src/releases

Apparently Citra is also disappearing (at least for now?), added to the comment

yeah I open this issue (https://github.com/microsoft/winget-pkgs/issues/142153) to redirect the repo to https://github.com/PabloMK7/citra/releases/tag/v2.1

TegraRcmGUI is still available: https://github.com/eliboa/TegraRcmGUI

@Exorcism0666 - some of the news items I saw were indicating that that tool (and a number not in pkgs) was possibly also part of the settlement.

Yuzu has since been removed from winget, so I think we can close this issue @stephengillie.


Add ruff code formatting and linting github action

see #169
this is probably not in its final form since i think we should discuss when this would be triggered, but thought this would prompt discussion

@ceesem this is another option https://pre-commit.com/


EDIT:   Address lack of client code in plan confirmation

During FTA synch outage, a number of RUPs were created with wrong client pointers, leading up to incorrect client_id getting set in plan_confirmation.

@LisaMoore1 the same list of client id's applies to this one.  If those all look stale (and particularly like we shouldn't be waiting on a signature from them) then I can clear these out.
Marking as 'ready to test' but again its more of a 'spot check data'

Unfortunately, to just clear these out based on the client id (and not location code), is a bit troublesome.
If there are any plan confirmation records with client ids that aren't pulled down from FTA every day we can safely clear those out (that last list I sent would be my reference for doing so).  It's those that do exist in both lists (current and plan confirmation), that we are unsure about because of the missing location code in plan confirmation, so we'll need an issue to tackle that database issue.

leaving ready to test as there's still a number of records we can clear up once lisa has had a chance to review the stale client list.

@micheal-w-wells When you are satisfied with this one can you please close it? Thx


Allow overriding injected container settings inline

Today, users can modify the injected config globally (through
values.yaml or changing the injection template manually) or on a per-pod
basis (by annotations, for specific fields we add support).
This expands the per-pod customization support by allowing a user to
explicitly declare a container like istio-proxy in the pod spec. This
allows complete customization of any field in the container spec.
This is described in detail in
https://docs.google.com/document/d/1Rmp9B3DDypgMCau-YAqidx_r3qvKLZj6jUX-t22zj84
Note to reviewers: I have had many PRs in injection area the past few
weeks which were fairly trivial. This one is not. The decisions here
are essentially a new API, so please review as such. In particular,
image: auto is a non-obvious decision as part of this PR.
I have "release notes none" since I will add a single release notes for the full sequence of PRs once complete.y

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f6a657e1ed25ad617326083e3c971c7e088fab89
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f6a657e1ed25ad617326083e3c971c7e088fab89
link
/test lint_istio

gencheck_istio
f6a657e1ed25ad617326083e3c971c7e088fab89
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
8bb3a225217eb91342e4a9859df8420c636b739c
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
8bb3a225217eb91342e4a9859df8420c636b739c
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
b50dcaf85f5fe62a0af49f8f22214a6a6a31b86b
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
b50dcaf85f5fe62a0af49f8f22214a6a6a31b86b
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Update info on AAD Pod Identity Parameter

Update info on AAD Pod Identity Parameter
I have been working on a deployment of Dapr/Keda to expand my knowledge in this area. I stumbled upon this doc, and planned to use it to enable Pod Identity for KEDA. The aadPodIdentity setting did not work for me. After reviewing the GitHub repo at kedacore/charts, I found that the correct parameter is actually podIdentity.activeDirectory.identity. Updating the docs to reflect that, and to also point to the helm chart for future reference.
Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO)

Thanks for updating! However, this is for v1.4. Is that the version you had issues with? Because at that point it was still called like the original configuration.

Thanks for updating! However, this is for v1.4. Is that the version you had issues with? Because at that point it was still called like the original configuration.

Doh, you're exactly right. I'm using 2.5.1, and can see that it's updated in the latest version of the docs.
I navigated to that page through the search, not quite realising that I had clicked on a prior version. If there is an option to display the version of a page in search results, that'd be super (to help eliminate confusion like this). Thanks for your quick help @tomkerkhove - appreciate it.

No problem and thanks for opening a PR anyway! Feel free to open an issue for the search  thingy, good suggestion!


Add retry logic to each UI test

Describe the bug
There are numerous time out errors in the team city UI tests. In order to determine the cause of the time outs, retry logic will be added to each test's implementation. If the test fails, it will be retried up to 2 more times. If the test fails 3 times, the failure will be logged with other pertinent information like the time of the test and how much time was between each failure.
To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Not needed currently.


chore: replace travis with github action

Based on the template workflow "verify-app". I've removed the e2e job since it is in another github action already.
TODO: secret decoder rings

GH_TOKEN
DHIS2_BOT_GITHUB_TOKEN
(anything else?)

Looks good!
Why not merge the Cypress action into the unified one? It allows you to save an install command re-use the cached node_modules in addition to control when the e2e tests are run. For example, there is no need to run expensive e2e tests if the cheap unit tests fail for example.

Looks good!
Why not merge the Cypress action into the unified one? It allows you to save an install command and re-use the cached node_modules in addition to control when the e2e tests are run. For example, there is no need to run expensive e2e tests if the cheap unit tests fail for example.

Makes sense!

This seems to have created a new repository @d2-ci/dashboard-app, I think the name in package.json needs to be updated


ERROR: vagrant up --provider=virtualbox

A customization command failed: ["modifyvm", :id, "--paravirtprovider", "minimal"]
screenshot:

Hi - please try upgrading VirtualBox to 5+ (see this troubleshooting.md page for more details).

@dpb587-pivotal
thanks! it works!


API suggestion: import paths

import { clearAll, prime } from 'firebase-jest-testing/fireStore'

Could partition the exports by the affected Firebase product.
Benefits:

this would allow e.g. Realtime Database support to be added, later, without overlapping FireStore features.

Done in alpha.10


Using constants in #[regex()] macros

I have multiple lexers that use common, and lengthy, regexes. It would be nice to put each regex in a const and reference it in multiple times.
In general, Rust doesn't allow constants in macros because macros get evaluated first. But I though that a nested macro might work:

#[macro_export]
macro_rules! myregex {
    () => {
        "complicated_thing_here"
    };
}
...
enum MyLexer {

    #[regex(myregex!())]
    MyTokenType,

}

but I get:
error: expected literal
   |
41 |     #[regex(myregex!())]
   |             ^^^^^^^

Is it possible to define a regex string in one place and use it in multiple places?

Hello! As far as I know, this is not possible, see https://github.com/rust-lang/rust/issues/52393.
The short explanation is that the procedural macro #[regex(<input>)] needs to be able to read the content of <intput> as compilation time, which is not possible at the moment.
If you want to reuse some regex, you can still use subpatterns, see https://github.com/maciejhirsz/logos/issues/162.
Now, I just noticed that this should be documented somewhere in the book ^^', so I'll open an issue for that.

Closing this as this is a limitation of Rust, not Logos.


can not see the map?

Hi @LiXingguangBrandonStark - I'm afraid this doesn't look like the Nextstrain website, so I'm not sure we can help with this bug. Can you give the URL you are trying to view?


Problem with opening notebook

cannot open or access file:///home/jovyan/.local/share/jupyter/runtime/nbserver-1193-open.html
urls do not exist

Hi @edsml-a5a334c7, thank you for raising the issue. Could you please let us know more details, such as where are you running the notebook, what machine and operating system you use, etc.

I am using a MacBook Pro 13, and I have tried running the git clone on both Safari and Chrome. I managed to circumvented the issue by downloading GitHub Desktop, however still cannot access the files using the original method.
Thanks,
Caoimhe

On Aug 21, 2023, at 11:16 AM, Marijan Beg @.***> wrote:
Hi @edsml-a5a334c7 https://github.com/edsml-a5a334c7, thank you for raising the issue. Could you please let us know more details, such as where are you running the notebook, what machine and operating system you use, etc.
—
Reply to this email directly, view it on GitHub https://github.com/ese-msc/introduction-to-python/issues/50#issuecomment-1686048975, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB7KVUVAZULAJ56OQG37VCTXWMYOVANCNFSM6AAAAAA3XOP5IM.
You are receiving this because you were mentioned.

I have yes. I installed Homebrew and Xcode Command Line Tools (although I am aware that they are redundant) as well. I am currently working through the exercises but I am curious about what was going wrong prior to my installation of GitHub Desktop so that it does not prove an issue in the future.

On Aug 21, 2023, at 7:31 PM, Marijan Beg @.***> wrote:
Have you created the conda environment and installed all dependencies (step 3 in installation instructions)?
—
Reply to this email directly, view it on GitHub https://github.com/ese-msc/introduction-to-python/issues/50#issuecomment-1686826531, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB7KVUWQPVXRSH465MUBY5LXWOSPVANCNFSM6AAAAAA3XOP5IM.
You are receiving this because you were mentioned.

Hi @edsml-a5a334c7, I do not understand from your previous message if you managed to run the notebook locally in the end. Could you please clarify?

Hi @edsml-a5a334c7, could we please have an update on this issue?

It has been resolved. Thank you so much for your help. Best,CaoimheOn Aug 24, 2023, at 6:01 AM, Marijan Beg @.***> wrote:
Hi @edsml-a5a334c7, could we please have an update on this issue?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I am still unsure why the original git clone command, run from the terminal did not work initially, but it seems to be working now. Thanks,Caoimhe On Aug 24, 2023, at 9:26 AM, Caoimhe Chan @.> wrote:It has been resolved. Thank you so much for your help. Best,CaoimheOn Aug 24, 2023, at 6:01 AM, Marijan Beg @.> wrote:
Hi @edsml-a5a334c7, could we please have an update on this issue?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Thank you for letting us know. I will close this issue now.


Use some lightweight secret management thing

I'm tired of passing env variables around. should use some not-too-complicated secrets thing. If it's just as easy, I'd prefer something cloud agnostic, but gcp secrets is probably fine. Ideally levanter's python code would know nothing about it though and just use env variables or an env file (which I know isn't best practice, but I'm not actually worried about my HF or WANDB key)

fixed in #601 (🙇 @rjpower )


Split TE hierarchical weight resolution into DCGate and POPGate tests

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 53.056%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1736

Relevant Lines:
3272

💛  - Coveralls

Pull Request Functional Test Report for #2714 / 0f2e8e9e25c055b006fc368b183c4d165e6199ec
No tests identified for validation.
Help

@jasdeep-hundal are you ok with allowing this ATE test to be split into two without requiring refactoring to using OTG?  It seems ok to me and this change is urgent.

@jasdeep-hundal changed adding new ATE test to warning instead of failure
Will revert it with separate PR