Selenide doesn't take a screenshot when method switchTo().window(2) fails

Tell us about your environment

Selenide Version: 5.12.2

Code To Reproduce Issue [ Good To Have ]
    openFile("page_with_tabs.html");
    switchTo().window(33);

Produces an error without screenshot:
org.openqa.selenium.NoSuchWindowException: No window found with index: 33
	at com.codeborne.selenide.SelenideTargetLocator.window(SelenideTargetLocator.java:193)
  ...
  Caused by: org.openqa.selenium.TimeoutException: Expected condition failed: waiting for window to be available by index: 33 (tried for 0 second(s) with 200 milliseconds interval)

fixed by https://github.com/selenide/selenide/pull/1240


Apply for Fluid Community Committer

Dear Fluid TOC members and maintainers,
I applied to wushiming (GithubID: wushiming540) as a new committer.
Wu Shiming, senior engineer of Huawei's NAIE platform, is responsible for large-scale distributed machine learning platform architecture design and new feature evolution, deep learning algorithm application optimization, and AI model acceleration. Research areas include large-scale cluster scheduling, high-performance computing, distributed file storage, distributed cache, etc. Participate in open source projects such as Fluid, Alluxio, and Volcano.
As an in-depth user of Fluid, I actively participate in weekly community meetings and discussions, contributing to the growth of the community and expanding Fluid's user cases.
The commit history: https://github.com/fluid-cloudnative/fluid/commits?author=wushiming540
Aug 16, 2023
docs: build fluid compnent
Talks/Presentations/Blogs
https://github.com/fluid-cloudnative/community/wiki/Meeting-Agenda-and-Notes#20231019

It is moved here: https://github.com/fluid-cloudnative/community/issues/60


Tabindex -1 in bootstrap dropdown causes wrong behavior when dropdown inside form

When you insert a ButtonDropdown::widget inside an active form, pressing Enter in one of the form text fields will not submit form, but will open up a first dropdown inside it since their links have tabindex set to "-1". Also you cannot override tabindex in linkoptions since it is coded in line 92 in Dropdown.php file as  $linkOptions['tabindex'] = '-1';

There is nothing wrong with dropdown that you use. Behavior is not wrong. If you want to prevent opening dropdown (when you press Enter),  just add option 'type' => 'button' . Here is an example:
            <?php $form = ActiveForm::begin(['id' => 'login-form']); ?>
            <?= ButtonDropdown::widget([
                'label' => 'Action',
                'dropdown' => [
                    'items' => [
                        ['label' => 'DropdownA', 'url' => '/'],
                        ['label' => 'DropdownB', 'url' => '#'],
                    ],
                ],
                'options' => [
                    'type' => 'button'
                ]
            ]);?>
            <div class="form-group">
                <?= Html::submitButton('Login', ['class' => 'btn btn-primary', 'name' => 'login-button']) ?>
            </div>
            <?php ActiveForm::end(); ?>


Cross-compile ImageMagick

In this PR I add support for cross-compiling ImageMagick. I've also had to cross-compile zlib and libpng as transitive dependencies. So far, faasm/faasm#680 implements the support to run ImageMagick with WAVM, and we can succesfully flip a .png image in the tests. I also have to include one definition in wasi-libc and add a syscall to the libc.imports list.
ImageMagick generates one executable binary (magick) with all the dependencies linked. We can use this same binary for different purposes just by changing the command line arguments. This means that inv imagemagick actually generates an "executable" .wasm which we place under /usr/local/faasm/wasm/imagemagick/main/function.wasm.

For some reason the GHA workflows are not running...
I'm requesting a review anyway.


GDShader: Add hint_enum for uniform int

This adds a new shader uniform hint for int named hint_enum.
uniform int noise_type : hint_enum("OpenSimplex2", "Cellular", "Perlin", "Value") = 0;

Similar to @export_enum, this changes the int input into a dropdown in the editor.
This has been requested in #8738 and then later in godot-proposals #7847
Unresolved Issues
There are two unresolved aspects to this PR:

This PR adds strings to the .gdshader parser, and maybe the error handling could be better? At the moment, using strings outside of this hint results in something like: Expected expression, found 'STRING_CONSTANT'. Maybe it should be something more coherent, like: Strings are not supported in shaders.?
While the visual shader implementation of this technically works, there appears to be some editor UI issues with visual shader nodes using PackedStringArray and String inputs. I wasn't able to figure out how to fix this.

Bugsquad edit, closes: https://github.com/godotengine/godot-proposals/issues/7847

I think you should recreate it as a separate branch rather than pushing a master - this is a common way to contribute to the engine, to avoid problems. You need to squash the commits also (see https://docs.godotengine.org/en/latest/contributing/workflow/pr_workflow.html#modifying-a-pull-request).

Ahh, sorry for my mistake! I didn't realize pushing from master would cause issues. I'll redo everything in a sec (+ squash commits from this point forward). 👌


IsoTpParallelQuery: support delays between requests

Might want to make this a generic parameter instead in FwQueryConfig, which would in turn be a generic parameter for IsoTpParallelQuery. No real point to only have delays between certain requests.
This has the side effect of fixing FW queries on CAN-FD. We can either retry the query right after if we see skipped iso-tp frames, or do it more proactively by querying each ECU with something safe, then waiting 200ms just like the dealer software does (it also requests a diagnostic mode b"\x10\x03, but the timing matters the most).
WIP

This is done much simpler in https://github.com/commaai/openpilot/pull/26040, and more correctly too. As this PR would only cease queries to individual ECUs, it would still be possible to continually be querying through the gateway here, based on ECU response times


.8 domReady never being called

Using Polymer .8 I have the following element
<link rel="import" href="../../bower_components/polymer/polymer.html">

<dom-module id="app-logo">
  <template>
    <link rel="import" href="../../bower_components/font-roboto/roboto.html">
    <link rel="stylesheet" href="../../bower_components/components-font-awesome/css/font-awesome.min.css">
    <link rel="stylesheet" href="app-logo.css">
    <i class="fa fa-sun-o"></i> playground
  </template>
</dom-module>

<script>
  Polymer({
    is: 'app-logo',

    //this is never called
    domReady:function(){
      console.log("logo domReady");
    },

    //however this is.
    ready:function(){
      console.log("logo Ready");
    }

  });
</script>

ready is called fine but domReady is never called?
Is this a regression or intentional. I didn't read anything about it in the migration guide?

This is by current design: domReady is not available in 0.8.
The 0.5 approach for this problem was brittle and prone to failure. We're investigating the use cases around 0.5's domReady method in an attempt to provide something better for 0.8.


Content Query WebPart : Fixed WebUrls not showing

Q
A

Bug fix?
yes

New feature?
no

New sample?
no

Related issues?
Issue 288 and Issue 292

What's in this Pull Request?
There was a really minor detail that I forgot which turned out to have a pretty big impact on the WebPart : The search query responsible for filling the Web Url dropdown in the WebPart's toolpane had no rowLimit parameter specified, which caused the query to return a maximum of 10 sites since 10 is the default rowLimit value when not specified.
I never figured this bug in my tests since I had less than 10 site collections / subsites combined, but after two different users have raised an issue in regards to sites or subsites not showing in the dropdown, I added multiple sites until I could replicate the issue.

@spplante,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

thx Simon, appreciated. Great to see this one evolving more and more.

This is just a temporary fix as 500 results for the WebUrl is still a bottleneck for big businesses, especially when site collections and webs are mixed together.
I am currently working on adding a new property Site Url on top of Web Url, wich will allow to select 500 site collections, and then unlimited sub webs since I won't use the search to list sub webs once the site is selected.
Should be merging this tonight if everything goes well!


Adds multi topic EventEmitter aka application Event Bus

RxJS version: 5.1.1
Expected behavior:
Provide built-in Events service.
Actual behavior:
No built-in Events service.
Additional information:
Currently almost every SPA uses shared event bus and people reimplement the wheel all the time. For me it looks like a good fit for library as rxjs to provide a unified way to create event bus based on Subjects. I created created a PR for such a bus in Ionic2 project, so you can take a look:
PR: https://github.com/ionic-team/ionic/pull/11861
Issue: https://github.com/ionic-team/ionic/issues/11770
Basically it's just a service with one method topic(name: string) which returns Subject.
import { Subject } from 'rxjs'

@Component({ ... })
export class MyComponent {
   constructor(private events: Events) {
     this.destroyed = new Subject()
   }

   ngOnInit() {
      this.events.topic('app:offline')
         .takeUntil(this.destroyed)
         .subscribe(() => this.doStuff())
   }

  ngOnDestroy() {
    this.destroted.next(true)
    this.destroyed.complete()
  }
}

Benefits:

allows to integrate Events service with other rxjs application logic easier
easier unsubscribing with help of takeUntil
easier merging with other observables
adds all rxjs methods to application wide events (e.g., debounceTime, throttleTime, etc)

Looking into PR, it seems it's lightweight wrapper around single subject as you mentioned. In that case, I could think of this could be separate modules other than to be included in core library, and it'll allow to fulfill most of benefits you've described. Is there specific constraint this should be included in core, like it should rely on some internals of implementation can't be achieved by separate module?
I do see of values of this, but also thinking about cases like our mono-package contains lot of unused paths for certain environment (i.e we've had node-specific types caused browser users pain, ajax impl, etcs) would like consider separated way first.

@kwonoj such thing as ApplicationEvents are normally used in any SPA application.
I believe it's very useful to have such functionality based on rxjs when you use Observables.
There is no other reasons  why this should be a part of rxjs, only convenience and this can be implemented separately

It's my personal opinion and other commiter's may have different opinion (reason I labeled discussion) but I'd usually advocate approaches as

create userland module first
then consider migrating into core repo once if needed

Once something is added to core, it is not trivial to move back to separate module as similar to what we've discussed over some other functionalities. Primary reason for those is make core as much as lightweight, in terms of size / api surface both and if someone wants additional features, they can opt in by installing those modules.

I see your point and it makes sense. So I close the issue


ensure no-restart mode

well, it seems, that atm the plugin is installing in a no-restart mode, but to keep that feature, we must follow: http://www.jetbrains.org/intellij/sdk/docs/basics/plugin_structure/dynamic_plugins.html

closing, as the feature is present

JB do this check when performing a static analysis on the plugin: "A+ Plugin for IntelliJ 0.1 can be dynamically loaded/unloaded without requiring user to restart IDE." https://plugins.jetbrains.com/plugin/13634-a-plugin-for-intellij/update/75647
but the verified can be used "locally" as well, before pushing to plugin repo: https://github.com/JetBrains/intellij-plugin-verifier


 We still have benchmarks that are screwed up (e.g. lists), I'm not yet sure if I'm going to fix more of these problems in this PR. See this comment for an explanation of what went wrong and this discussion for a prediction that it would happen.

/benchmark nofib

/benchmark nofib

/benchmark nofib

/benchmark nofib

/benchmark nofib

/benchmark validation

/benchmark validation

/benchmark validation

/benchmark validation

/benchmark nofib

/benchmark validation

/benchmark nofib

These results look very encouraging: the cost model predictions for the nofib results have always apparently been much bigger overestimates for the primetest examples than for the other ones, but these results are much closer to the predictions of a recent cost model.  This may have cleared up a bit of a mystery.
 We're mostly underpredicting here, but the results are a lot more precise for the validation benchmarks.

/benchmark lists

/benchmark bls12-381-benchmarks

There goes my precious builtins performance...

These results look very encouraging: the cost model predictions for the nofib results have always apparently been much bigger overestimates for the primetest examples than for the other ones, but these results are much closer to the predictions of a recent cost model. This may have cleared up a bit of a mystery.

I think the results are worse than they used to be? We underpredict by a slightly larger margin in the worst case and on average too. I'd rather have less uniformity but underpredict less too. 15% overestimates seem totally OK for me, perhaps even desirable as a margin of safety for edge cases.

These results look very encouraging: the cost model predictions for the nofib results have always apparently been much bigger overestimates for the primetest examples than for the other ones, but these results are much closer to the predictions of a recent cost model. This may have cleared up a bit of a mystery.

I think the results are worse than they used to be? We underpredict by a slightly larger margin in the worst case and on average too. I'd rather have less uniformity but underpredict less too. 15% overestimates seem totally OK for me, perhaps even desirable as a margin of safety for edge cases.

Well we can easily make it underpredict less by increasing the machine step costs a bit, for example.  However, the way it's calibrated at the moment does make it mostly overpredict for validation examples, which are a lot more realistic than nofib (where there's probably a lot more GC going on, for example).  The figures here are with a preliminary new version of the cost model too: we'll need to re-run the costing benchmarks to take account of recent changes.

These results look very encouraging: the cost model predictions for the nofib results have always apparently been much bigger overestimates for the primetest examples than for the other ones, but these results are much closer to the predictions of a recent cost model. This may have cleared up a bit of a mystery.

I think the results are worse than they used to be? We underpredict by a slightly larger margin in the worst case and on average too. I'd rather have less uniformity but underpredict less too. 15% overestimates seem totally OK for me, perhaps even desirable as a margin of safety for edge cases.

Well we can easily make it underpredict less by increasing the machine step costs a bit, for example.  However, the way it's calibrated at the moment does make it mostly overpredict for validation examples, which are a lot more realistic than nofib (where there's probably a lot more GC going on, for example).  The figures here are with a preliminary new version of the cost model too: we'll need to re-run the costing benchmarks at some point to take account of various recent changes.


panic in main

I can't explain it, but thought I'd post an issue in case this is something you'd come across before.
cargo test-junit fails with a panic when I run it as part of a build step in a docker container.
Any ideas?
Step 6 : RUN cargo test-junit --name test-report
 ---> Running in 77ae59c9b724
thread 'main' panicked at 'Parser error', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: cargo_test_junit::main

Full backtrace indicates https://github.com/rustation/cargo-test-junit/blob/master/src/main.rs#L43
I'll probably have to work around the stream handling to get this to work for me. Maybe I'll have to do this as a post-build step (which I'd prefer not to) so I can use docker run --tty to get stdout to not panic.
Step 6 : RUN cargo test-junit --name test-report
 ---> Running in 78d228b2abbd
thread 'main' panicked at 'Parser error', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
stack backtrace:
   0:     0x56326b330bc3 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hab274209b3900f9c
                               at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x56326b32ce24 - std::sys_common::backtrace::_print::h8f655fc4b25b9b70
                               at /checkout/src/libstd/sys_common/backtrace.rs:71
   2:     0x56326b335ac7 - std::panicking::default_hook::{{closure}}::hd0f0fde26cdd4a91
                               at /checkout/src/libstd/sys_common/backtrace.rs:60
                               at /checkout/src/libstd/panicking.rs:355
   3:     0x56326b33567c - std::panicking::default_hook::h123df66825ae8c79
                               at /checkout/src/libstd/panicking.rs:371
   4:     0x56326b335f9b - std::panicking::rust_panic_with_hook::h3635757261b59272
                               at /checkout/src/libstd/panicking.rs:549
   5:     0x56326b29272f - std::panicking::begin_panic::h46d3207214572fc9
   6:     0x56326b298fa6 - cargo_test_junit::main::h8c4a99bfbef70169
   7:     0x56326b33ce3a - __rust_maybe_catch_panic
                               at /checkout/src/libpanic_unwind/lib.rs:98
   8:     0x56326b33673a - std::rt::lang_start::ha5350a26f8f175ab
                               at /checkout/src/libstd/panicking.rs:433
                               at /checkout/src/libstd/panic.rs:361
                               at /checkout/src/libstd/rt.rs:57
   9:     0x7f8297143b44 - __libc_start_main
  10:     0x56326b291c99 - <unknown>
  11:                0x0 - <unknown>
The command '/bin/sh -c cargo test-junit --name test-report' returned a non-zero code: 101

So, I switched the build to use cargo directly in the jenkins slave, but I am sometimes getting this error, and sometimes not.
I assume this is some issue with a dependency, duct maybe?
I think for now, I'm just going to run cargo test --message-format=json and write a small converter to push the output through in the shell itself.

Hi,
If I remember correctly, there is something in the raw test output that is non-deterministic.
When that occurs the parser fails to handle it.
If you can paste your raw output for a few runs, I can try updating the parser.

And yeah, given we don't have useful output when formatting as JSON (and I needed Junit reporting), the current option was to parse the raw output.
Ultimately, having useful output in other formats would obviate this repo.

I see the same:
thread 'main' panicked at 'Parser error', opt/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549                                                                                5: std::panicking::begin_panic                                                                                6: cargo_test_junit::main                                                                                7: std::panicking::try::do_call                                                                                at /checkout/src/libstd/panicking.rs:454                                                                                8: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
   9: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:57
  10: __libc_start_main
  11: _start

How would I acquire the raw test output? Do you log that into some file?

In case you mean the output of cargo test, this is what I see:
   Compiling libdrm-sys v0.2.0 (file://<<PROJECT>>)
warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found struct without foreign-function-safe representation annotation in foreign module, consider adding a #[repr(C)] attribute to the type, #[warn(improper_ctypes)] on by default
    -->
<<PROJECT>>/target/1.16.0/debug/build/libdrm-sys-99c34009add0f9d8/out/bindings.rs:5641:58
     |
5641 |     pub fn drmWaitVBlank(fd: ::std::os::raw::c_int, vbl: drmVBlankPtr)
     |                                                          ^^^^^^^^^^^^

Lots of these. They are a result of servo/rust-bindgen#442, which has been fixed in Rust 1.17.0, but I do try to test my code with older versions, too.

P.S. The list of tests seems to start at ^running (\d+) tests$ and it ends at ^test result: (\w+). (\d+) passed; (\d+) failed; (\d+) ignored; (\d+) measured$. Do you already use that to guide your parser?

I've also experienced this. However it was happening to me on CircleCI 2.0 when executed from my config.yml file but works locally and when SSH'd into the build and running manually there. Not exactly sure how to resolve this. My thoughts is something weird is up with the parser.

In case you mean the output of cargo test

@devurandom, yes. if you could paste the full stdout of cargo test (from a clean build), I can add a failing test case and address it.


OpenSea changed the /events endpoint pagination, so events_backfill() is not working

Now the next field returns tha cursor hash, previously it returned the whole URL so it breaks the current implementation

Fixed by https://github.com/zseta/python-opensea/pull/19


Multiple loading of the model resulted out of GPU memory

@root_validator()
def validate_environment(cls, values: Dict) -> Dict:
"""Validate that llama-cpp-python library is installed."""
model_path = values["model_path"]
if values["client"] is None:
try:
from transformers import AutoTokenizer, AutoModel
values["client"] = AutoModel.from_pretrained(model_path, trust_remote_code=True).half().cuda()
values["tokenizer"] = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)
        except ImportError:

==============
the reqeust execute the code every time cause  out of memory;
i know the code  validate  the operation of the   browser  webpage

but  the  request   http://localhost:3000/validate/node/dndnode_42    build_object  every_time

That's a good catch. The node validation should be cached. I'll creating an issue and start working on that ASAP


DepCard: Add a space between labels

Otherwise they squish up against each other.

Before:

After:


correct stream id logic

From the HTTP/2 Spec
Streams are identified with an unsigned 31-bit integer.  Streams
initiated by a client MUST use odd-numbered stream identifiers; those
initiated by the server MUST use even-numbered stream identifiers.  A
stream identifier of zero (0x0) is used for connection control
messages; the stream identifier of zero cannot be used to establish a
new stream.

The updated logic matches reactivesocket-java
https://github.com/ReactiveSocket/reactivesocket-java/blob/272401b1cbe2ea5f6bc7a16d4af18900c43a6f75/reactivesocket-core/src/main/java/io/reactivesocket/StreamIdSupplier.java

https://github.com/ReactiveSocket/reactivesocket/pull/92/files

But reactivesocket-cpp matches the current spec
https://github.com/ReactiveSocket/reactivesocket-cpp/blob/ff931c00c533d0db1d213d8503fc5435112e6085/src/StandardReactiveSocket.cpp#L60

cc @benjchristensen


Add support to designate models and enums as internal

Adds support to simultaneously rename models and designate them as internal in order to support convenience layers.
For example, say I have model Widget and I want to replace it with a customized model.
autorest swagger.json --swift ... --remap-models Widget=WidgetImpl
or, better yet, add to your readme.md:
remap-models: >
    Widget=WidgetImpl
    Foo=InternalFooWhatevs

This will result in Autorest generating the Widget struct with the name WidgetImpl and designating it and all of its members as internal. However, where this model is used inside autogenerated client methods and options, it will still generate with the Widget name, resulting in a broken reference. The intent is then that in your convenience layer you supply the customized model:
public struct Widget: Codable {
  init(from raw: WidgetImpl) {
    // convert WidgetImpl into Widget...
  }
}

This fixes the broken reference and should allow you to use the generated client without having to make a wrapper.
Limitations
Right now, this only supports remapping objects models (classes and structs) and enums. Clients are not yet supported.

@tjprescott I tried regenerating Chat with this branch but am not seeing the renames applied. I might be using the wrong syntax? I tried the following so far:
CONFIG.MD:
namespace: AzureCommunicationChat
remap-models: >
    CreateChatThreadResult=CreateChatThreadResultInternal
    CreateChatThreadRequest=CreateChatThreadRequestInternal
    ChatMessage=ChatMessageInternal
    ChatMessageContent=ChatMessageContentInternal
    ChatParticipant=ChatParticipantInternal
    ChatMessageReadReceipt=ChatMessageReadReceiptInternal
    ChatThreadProperties=ChatThreadPropertiesInternal
    CommunicationError=ChatError

Using above config as below (replacing placeholders with actual paths), where my local autorest is on the feature/generateInternal branch:
autorest CONFIG.md
--swift
--use=<PATH TO AUTOREST>/Documents/autorest.swift
--input-file=<PATH TO SWAGGER>/swagger.json
--output-folder=<PATH TO AZURE SDK>/azure-sdk-for-ios/sdk/communication/AzureCommunicationChat

Also tried using without a configuration file:
autorest
--swift
--use=<PATH TO AUTOREST>/autorest.swift
--input-file=<PATH TO SWAGGER>/swagger.json
--output-folder=<PATH TO AZURE SDK>/azure-sdk-for-ios/sdk/communication/AzureCommunicationChat
--remap-models ChatParticipant=ChatParticipantInternal

/check-enforcer evaluate

@knvsl if you are using command line directly, you have to specify --remap-models="ChatParticipant=ChatParticipantInternal" otherwise autorest will complain about "multiple configuration files".
When you switch to this branch, you probably also need to run make install first to ensure the updated templates are installed correctly.

So I still am not seeing the changes applied, I feel I'm missing a step here. It's regenerating without error but I don't see the changes applied.
Here's what I am doing:

Checkout feature/generateInternal
on feature/generateInternal npm run install
My CONFIG.MD:

namespace: AzureCommunicationChat
remap-models: >
    CreateChatThreadResult=CreateChatThreadResultInternal
    CreateChatThreadRequest=CreateChatThreadRequestInternal
    ChatMessage=ChatMessageInternal
    ChatMessageContent=ChatMessageContentInternal
    ChatParticipant=ChatParticipantInternal
    ChatMessageReadReceipt=ChatMessageReadReceiptInternal
    ChatThreadProperties=ChatThreadPropertiesInternal
    CommunicationError=ChatError

My swagger.json: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/communication/data-plane/Microsoft.CommunicationServicesChat/stable/2021-03-07/communicationserviceschat.json
Run following autorest command:

autorest
  CONFIG.MD
  --input-file=swagger.json
  --output-folder=/Users/kinovose/Documents/azure-sdk-for-ios/sdk/communication/AzureCommunicationChat
  --use=/Users/kinovose/Documents/autorest.swift

I double checked the CONFIG.MD is being applied, because if I revert the contents to contain the directives I had they are applied

@knvsl after step 1 you have to run make install in your autorest repo. This is the only the updated templates will get installed.

@tjprescott npm run install runs make install, but I also tried running make install directly & don't see a difference.

@tjprescott Interesting, after changing the log level and re-running I do NOT see my config settings. I see there is an error as well, but autorest is still completing the code generation (the renames just aren't applied):
AutorestSwift.default (INFO) Autorest Configuration: {

}
AutorestSwift.default (WARN) Discrepancies found in round-tripped code model. Error saving files: Error Domain=NSCocoaErrorDomain Code=4 "The folder “before.json” doesn’t exist." UserInfo={NSFilePath=/var/folders/vd/bv1hsvk55_9_fvkmz017mmqm0000gn/T/7B24CC80-FE19-424F-9CCE-CF013D1BDB45/before.json, NSUserStringVariant=Folder, NSUnderlyingError=0x7f8bd54d2480 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}
AutorestSwift.default (INFO) Generating code at: /var/folders/vd/bv1hsvk55_9_fvkmz017mmqm0000gn/T/7B24CC80-FE19-424F-9CCE-CF013D1BDB45/AzureCommunicationChat
AutorestSwift.default (INFO) Base URL: /var/folders/vd/bv1hsvk55_9_fvkmz017mmqm0000gn/T/7B24CC80-FE19-424F-9CCE-CF013D1BDB45/AzureCommunicationChat

@knvsl you don't need to worry about the round-trip error. However, the fact that it is showing the Autorest Configuration means you are running on the branch. I just don't see anything that would indicate why it's not parsing the setting. What if you pass --remap-models="..." via the command line?

I was one commit behind on the branch, pulled latest and I am able to see the changes applied when using the flag on the command line, I'm unable to get the CONFIG.md working though
Here's what works for me (for input file I'm referencing the swagger published to the specs repo):
autorest
--swift
--use=/Users/kinovose/Documents/autorest.swift
--input-file=https://github.com/Azure/azure-rest-api-specs/blob/master/specification/communication/data-plane/Microsoft.CommunicationServicesChat/stable/2021-03-07/communicationserviceschat.json
--output-folder=/Users/kinovose/Documents/azure-sdk-for-ios/sdk/communication/AzureCommunicationChat
--namespace=AzureCommunicationChat
--remap-models="CreateChatThreadResult=CreateChatThreadResultInternal CreateChatThreadRequest=CreateChatThreadRequestInternal ChatMessage=ChatMessageInternal ChatMessageContent=ChatMessageContentInternal ChatParticipant=ChatParticipantInternal ChatMessageReadReceipt=ChatMessageReadReceiptInternal ChatThreadProperties=ChatThreadPropertiesInternal CommunicationError=ChatError"

/check-enforce evaluate

/check-enforcers evaluate

/azp run

/check-enforcer evaluate


Web - Payments - Error message appears on clicking "Save and Continue" in additional details form

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue was found when executing PR #8017
Action Performed:

Navigate to /settings/payments/enable-payments
Enter information in all fields
Tap on "Save & Continue"

Expected Result:
Able to proceed to next page.
Actual Result:
Error is displayed " Please verify your name and date of birth. If the information is correct, click "Save & Continue"." unable to proceed to next page with the terms checkboxes.
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web

Version Number: v1.1.42-4
Reproducible in staging?:  Y
Reproducible in production?: Y
Email or phone of affected tester (no customers<EMAIL_ADDRESS>/ Qwerty123
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/157993764-70facf51-9d31-40c2-a5b7-1932ef7b1673.mp4

Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:
Issue was found when executing PR #8017
View all open jobs on GitHub
view this job

@tylerkaraszewski Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

This is not obviously external. I am going to leave it internal for now.

Triggered auto assignment to @jboniface (Internal) because issue was reported by a contributor who needs to be compensated if this issue is fixed

job posted

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Santhosh-Sellavel (Exported)

Triggered auto assignment to @mountiny (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Oops, I didn't realize this was flagged internal (I didn't actually realize Contributor Managers were auto assigned to Internal issues?)

@jboniface This should not be Internal per the current use of the label. There is nobody to pay for reporting this issue. However, we would like to make sure this gets fixed so maybe we should triage Engineering again.

@mountiny so the problem is that the label should not have been applied? maybe we should clarify the description for the label? possible the name as well? like Internal - Reported By Contributor

@mountiny also can you point to where we changed the usage for this label? it used to just mean "requires an internal engineer"

@jboniface Yeah, it has been discussed couple of times now to change the Triage process as the Internal label is misleading and also if the issue is not External, then it can dissapear to nowhere. There is a tracking issue here where we plan what to do, it still needs to be discussed so we nail the process.
The functionality has been added 3 months age as a new chore for CM here

yeah, this seems confusing

@mountiny i filed an issue for the immediate problem. the internal label should always be applied for internal issues but it should only auto-assign a CM when it sees reported by in the title.

@jboniface thanks, I see where the problem is, I will make it a FirstPick issue for one of the new hires 🙇

Issue not reproducible during KI retests. (First week)

Not reproduced during retest.

Removing. Help Wanted label and waiting for second retest @mvtglobally

Coming shortly. I will update in a bit

@mountiny We had slightly different issue during reproduction this time. Original error no longer display. But user unable to proceed
https://utest-dl.s3.amazonaws.com/testRunStepMinAttachmentsResult/19190223/Recording__133.mp4?AWSAccessKeyId=AKIAJ2UIWMJ2OMC3UCQQ&Expires=1680067066&Signature=rkl7%2FmBjdbU2y6NhmCbAT4tOJ98%3D

@mvtglobally that does not look good. Could you please make sure if this happens on Prod as well and create a new issue for it?
This one seems resolved so ti would be best to crete new GH with spot on description and also consider adding Deploy Blocker if this does not happen in production

It seem to work fine now.
Issue not reproducible during KI retests. (Second week)

@mvtglobally Thank you! I will close this for now and if it appears again, we could reopen this!


[T5A2][T10-B2] Li Zhiyuan

polymorphism

@lzyuan168 Some comments added. Please close the PR after reading comments.


Add formatter support

Formatter support is added by making use for the terraform fmt command provided by the Terraform binary.
The script will check for the binary's location by searching through the paths available in the user's PATH env variable.  If a custom binary is provided in the preferences, that will be used instead.
The formatting will occur on save by default, but this can be set in the preferences.  A one-off command exists to handle the save behavior as well.
I've tried to handle configuration changes to both in realtime with observers so changing the path or toggling auto-save on or off should update without needing to reload the extension.
This will take care of the terraform fmt portion of https://github.com/Eiara/HCL.novaextension/issues/4#issue-677359532

Hey!
Sorry for the delay on looking at this, I've been rather sick.
The formatter looks great, I'll merge that in. 🙂

Hey!
Sorry for the delay on looking at this, I've been rather sick.
The formatter looks great, I'll merge that in. 🙂

Assuming you're good with the MIT licence?

Assuming you're good with the MIT licence?

Yeah I stopped using Nova for the time being - feel free to use the code with whatever licensing works best :). Hope you are feeling better!

Yeah I stopped using Nova for the time being - feel free to use the code with whatever licensing works best :). Hope you are feeling better!


Ability to automatically convert Resources to references when passed to property functions

Add a 'Referencable` class with a prototype function for returning a reference to the object.
Have the Resource class extend Referencable
Have all of the property functions check their passed objects to see if they're an instanceof Referencable to know whether or not to invoke the .ref() function or just add the param raw

This will be complete after we merge #43


[Bug] please support swaped mouse

my pc has been exchanging the left and right of the mouse
Steps to reproduce

enter gui normal mode
shift-f shift-f
type any marker key
the context menu displaying, just like the right mouse is clicked

Environments
Windows Version  22H2
win-vind Version 5.7

You can customize all key mappings of win-vind.
As shown in the cheat sheet, the FF is defined as <easyclick><click_left>.
Therefore, please try gnnoremap <shift-f><shift-f> <easyclick><click_right> in your .vindrc.
Thanks.


 I don't see one.

no .but u can grab the link from source code


Add Flatpak support.

Added everything needed to build a Flatpak.  Icon stolen from https://whatisthe2gs.apple2.org.za/ .  Please read over the files.  One (com.samirsinha.Clemens.appdata.xml) is missing a needed email address and another (buildFlatpak.sh) a GPG key.

Thanks!  I think before merging this I'll need to look at how to manage local user data.  I have a couple ideas.  At least for Linux it may make more sense to locate this data in the user account's folder as you suggested (and play nice with flatpak.)   I'll work on that first and then try this PR out.

I'm in the process of integrating this and have merged your changes into a development branch for me to fine-tune.


(PUP-6921) Improve separation of concern between String and Enum types

Before this commit, the PStringType had two attributes. A size_type and
a values array. An inferred String would hence result in a String type
with two complex objects and all checkes would then take both objects into
account.
This commit simplifies the PStringType so that it only has one attribute.
The attribute can be either a size_type or a string value.
Since this means that a String can hold max one string value, the common
type of two different strings is now changed to instead be an Enum. I.e.
the inferred element type of the array ['a', 'b']. The logic for computing
assignability and commonality between Enum and String has been improved.

what happens when generalizing an Enum? Does Enum[a, bb, ccc] generalize to String[1,3] ?

CLA signed by all contributors.

An Enum[a, bb, ccc] is generalized into String, not String[1,3]. This is analog to a String inferred from "ccc". It will also be generalized into a String (without parameters). For String, this hasn't changed. For Enum, it has. There a call to generalize used to be a no-op.
The reason for the change is that it works better with the TypeMismatchDescriber. It uses generalize when it knows that the types differ in such a way that there is no need to show type details. So rather than showing "expected Integer, got Enum[a, b, c]" it now shows, "expected Integer, got String". Good to keep in mind here is that generalization almost only happens on inferred types and there's no runtime correspondence to an Enum. The Enum pops up when inferring collection types (from strings).
An alternative would be to keep the old behavior and instead move this to the TypeMismatchDescriber. There, it's more certain that the "actual" is an inferred value.


Use ALF for post controls

Changes:

New icons!
New repost menu

Web: ALF <Menu>
Native: ALF <Dialog>

Hover states
Cleaned up sizes/padding/etc

hell yea, this has been bothering me every time i go to repost, seeing that ugly round button 😭

also, are we happy with the hover state?

ios feed before
after

ios thread before
after

web feed before
after

web thread before
after

Excited for this change, but you know Imma nitpick.
First two thoughts:

Also the icons seem slightly larger in general. I may need to see it on an actual device but my initial reaction was they seemed big.

Hmm, interesting that the spacing has all changed. I think this is from the padding needed for the hover state


Invalid Double Issue

Hi, I've encountered the following issue.  I/flutter (28517): ════════════════════════════════════════════════════════════════════════════════════════════════════

Even I have this issue.

I got this Issue too.

Did you guys find out any solution to it ?


Context changes since last release

@tizoc I fixed the code related to my comment.
Other than that I think it's good for merging

@sebastiencs great, thank you.


Revamp UI

Closes #94.
This PR:

revamps the UI to give a more personalised look to Tinner
integrates new fonts for the system

Notes:

further UI updates will come over the course of development whenever necessary
there may be merge conflicts due to modification in role display logic

LGTM! Really nice ui, good job!

UI looks much better than before!


Add JOSS paper folder and files

Description
Add JOSS paper folder and files

Codecov Report

Merging #213 (d04c04e) into main (a216518) will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #213      +/-   ##
==========================================
+ Coverage   83.75%   83.82%   +0.06%
==========================================
  Files          26       26
  Lines        3023     3042      +19
==========================================
+ Hits         2532     2550      +18
- Misses        491      492       +1

Impacted Files
Coverage Δ

preliz/internal/optimization.py
99.35% <0.00%> (-0.65%)
:arrow_down:

preliz/distributions/continuous.py
92.97% <0.00%> (+<0.01%)
:arrow_up:

preliz/distributions/discrete.py
93.21% <0.00%> (+0.03%)
:arrow_up:

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

Do we need to add this https://github.com/marketplace/actions/open-journals-pdf-generator? or are we going to compile it locally?


[GSB] Start tracking source locations for requirements within protocols.

Start reshuffling RequirementSource to store more information about
requirements in protocols. As a small step, track the source locations
for requirements written within the protocols themselves.
Note: there's a QoI regression here where we get duplicated
diagnostics (due to multiple generic signature builders being built
from a bad signature).

@swift-ci please smoke test

Note: not ready to merge this until I find a way to avoid the awful QoI regression.

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


2 resolve name inconsitancy between plugin name and import name

Should be fixed.

Also is it intended, that the package just spits out the entire RollPass data to the Report (besides the factors m11...m33)? See below:


Un-supported directives are breaking syntax highlighting

In the latest build of sublime. Maybe something has changed which is causing the un-supported directives behave incorrectly.
In my test. Putting () parenthesis after the un-supported directives ( Those which are not added in the package yet ) are causing highlight break issue.
Example
1: Un-supported direcitve Without Parenthesis. Don't Break

2: Un-supported direcitve With Parenthesis. Breaks all syntax highlight after

3: Supported directive

Oddly enough putting a second close bracket will fix the highlighting. (but of course, break the code)
ie. @stack())

This has been fixed.


Variables get automatically converted to string when using them in response expressions..

Let's say we have an operation which has as action a python_script. Inside we have variables a = 100, b = 2
If I use
result = a < b it gets correctly evaluated to false.
But if I use
results:
- SUCCESS: a < b
Then the operation succeeds since it's doing a string comparison.

@oritstone do you remember why we made it that way in the first place?
it seems odd to me now..

so do we all agree that except to the case of @Action that for some reason returns only strings, we should use Serializable for outputs like we do for inputs.
@meirwah @oritstone @meshipeer @avimora @TudorLesanHP @Bonczidai

Agree

+1 assuming there is no technical issue with that


waitForAntreaDaemonSetPods should wait for Pods being ready

Phase Running just means at least one container is still running, or is in the process of starting or restarting.

Thanks for Quan's help to fix it. Maybe we should use a temporary variable in the for-range loop.

Thanks for Quan's help to fix it. Maybe we should use a temporary variable in the for-range loop.

fixed

/skip-all


[FEAT]  Deep Filtering on Nested JSON Fields in Supabase

Is your feature request related to a problem? Please describe.
I'm currently working on a project using Refine with Supabase as the data provider. I have a use case where I need to filter data based on a nested JSON field. However, it seems that Refine does not support deep filtering on nested JSON fields out of the box.
Here's a snippet of my current implementation:
const {{ tableProps, searchFormProps }} = useTable({{
  onSearch: (values: any) => {{
    return [
      {{
        field: "data->>'spanish'",
        operator: "contains",
        value: values.value,
      }},
    ];
  }},
}});

where data is a JSONB field in Postgresql containing a key named spanish.
Describe alternatives you've considered
No response
Additional context
No response
Describe the thing to improve
allow filtering based on nested json.

Hey @LazerJesus could you elaborate more on the issue? It's not clear what's the issue. From your snippet, it seems like it should work. Do you get any error or empty response?
You can also swizzle the supabase data provider and modify it as needed as a quick workaround. https://refine.dev/docs/packages/cli/#commands

i had to change field: "data->>'spanish'" to field: "data->>spanish".


[GLUTEN-1632][CH]Daily Update Clickhouse Version (20240220)

Auto commit by gluten daily build, please check the build status and merge it if it's green.

fix https://github.com/oap-project/gluten/pull/4715


"configure-sysplex" - Page Not Found

Description
The reference to page "configure-sysplex" is not found when linking from
https://docs.zowe.org/stable/user-guide/zowe-ha-overview/#enable-high-availability-when-zowe-runs-in-sysplex
Pages to Update

Expected behavior
Display the requested page

Thank you for creating the issue!
Assigned to @nellietan to work on this.


Support variable number of arguments to fontist install

fontist install is the "gold star" of the fontist CLI. It makes sense that it would be a good idea to make it at least similar ish too other package manager's package-manager install <THING> commands so that users can get going quickly. Right now if you want to install two fonts you have to use two commands.
jcbhmr@PIG-2016:~$ fontist install "Fira Code" "Inter"
ERROR: "fontist install" was called with arguments ["Fira Code", "Inter"]
Usage: "fontist install FONT"

compared to other package managers like npm, pip, Cargo, (probably more) this is an inconvenience (not a bug or a critical flaw, just an inconvenience)
npm install --global typescript glob prettier eslint
cargo add rand wasmtime wit-bindgen serde
pip install tensorflow black pytest

Nice suggestion! 👍 Where could we see the closest need in such feature? May be somewhere in typst?
Also fontist could start supporting installation of formulas (not fonts) the same way:
$ fontist install -F fira_code google/inter

This could help with keeping arguments clean from quotes.

Nice suggestion! 👍 Where could we see the closest need in such feature? May be somewhere in typst?

It's not really a thing I need or something I even have a specific use-case for; it's just a UX thing that made me go "huh I guess I can't do that; that's inconvenient and didn't conform to my intuitive expectation"
If you really reach for one, here's a use-case:
- run: fontist install "Fira Code"
- run: fontist install "Fira Mono"

vs
- run: fontist install "Fira Code" "Fira Mono"

Thank you @jcbhmr !
This is indeed a good suggestion and as expected. In the beginning it was rare that people wanted to install multiple fonts all at once, and then when the need came the manifest was used for it. However it is indeed useful to allow the user to just type in multiple fonts / formulas.
Let’s do it!


log(engine, dm): hide sensitive info in log

What problem does this PR solve?

Issue Number: close #6917
What is changed and how it works?

Migrate some function in dm/pkg/utils/util.go to pkg/logutil/sensitive.go for reuse of such code.
Implement zapcore.ObjectMarshaler for Job and CreateJobRequest.

Check List
Tests

Unit test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
`None`.

/run-all-tests

/cc @amyangfei
/cc @lance6716

/cc @gozssky

/cc @lance6716

/run-engine-integration-test

/run-engine-integration-test

/merge


Could you please provide a sample for EF Core 2?

Could you please provide a sample for adding a trigger, Condition is given it that I can't change your DbContext inheritance chain. If not possible then at least provide steps to create/alter/delete trigger, add migration and update database.
Further technical details:
Database engine: SQL Server
Visual Studio or SSMS version: Visual Studio 2017 15.5, SSMS 17.4

https://github.com/NickStrupat/EntityFramework.Triggers#manual-overriding-to-enable-triggers
:)


[cloud_firestore] fix crashes when passing DocumentReference to FieldValue

Description
This change ensures the correct DocumentReference type is passed to the platform interface when using FieldValue.arrayUnion & FieldValue.arrayRemove
Related Issues
https://github.com/FirebaseExtended/flutterfire/issues/1986
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[x] No, this is not a breaking change.

@ditman Yup, since we have different types between cloud_firestore and  cloud_firestore_platform_interface. The codec used to work with the method channel only accepts cloud_firestore_platform_interface which is the main reason we have to resort to encoding like that.
Best Regards,
Amr Yousef
Mobile: +44(0)7780090148
Website: https://amryousef.me
LinkedIn: https://www.linkedin.com/in/yousefamr/

On 13 Feb 2020, at 22:05, David Iglesias<EMAIL_ADDRESS>wrote:
@ditman approved this pull request.
Thanks for fixing this so quickly @amrfarid140 https://github.com/amrfarid140!
In packages/cloud_firestore/cloud_firestore/lib/src/field_value.dart https://github.com/FirebaseExtended/flutterfire/pull/1994#discussion_r379145491:

@@ -26,7 +26,7 @@ class FieldValue extends platform.FieldValuePlatform {
/// will be overwritten with an array containing exactly the specified
/// elements.
static FieldValue arrayUnion(List elements) =>

 FieldValue._(_factory.arrayUnion(elements));

 FieldValue._(_factory.arrayUnion(_CodecUtility.valueEncode(elements)));

We've had a bunch of those now, do we need to .valueEncode eeeeeverywhere that gets passed in to the platform?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/FirebaseExtended/flutterfire/pull/1994?email_source=notifications&email_token=ABGFK4J7RIO25YCVCTUHNG3RCW72LA5CNFSM4KUPGBX2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCVPZK4Y#pullrequestreview-358585715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGFK4KWTG7SNSSTORH7VT3RCW72LANCNFSM4KUPGBXQ.

(I'll merge and publish as soon as this goes green)

PS: This PR has... 147 commits...
For the next PR, can you please re-fetch your origin/master and work off of a fresh master? That way the # of commits should go wwwwway down (this PR should only contain 1 commit really)

@amrfarid140 this doc is interesting, so you don't have to use your master branch to push code to us, you can use branches off of a recent master, and then the PRs will be much smaller, now that we're in "short-lived" branches mode!
https://github.com/flutter/flutter/wiki/Tree-hygiene

@ditman Should we merge this or do you want me to make the changes re:git branches and make another PR ?

@amrfarid140 I'm merging this right now, but for the next PR please make sure you've got your master up to date (and maybe work off of a branch?)

Published https://pub.dev/packages/cloud_firestore/versions/0.13.2+2


Test on huge set

This can is a draft to test musConv on a large set of CIF files
# coding: utf-8
import sys
import random
from ase.io import read
from ase.data import atomic_numbers
from ase.atom import Atom
from ase.calculators.lj import LennardJones
import numpy as np
from musConv.chkconv import check_SC_convergence

try:
    atoms = read(sys.argv[1])
except:
    sys.exit()

valid_atom = set(atomic_numbers.keys()) - set(atoms.get_chemical_symbols())

imp = random.sample(valid_atom, 1)[0]

atoms.append(Atom(imp, np.random.random(3)))
atoms.set_calculator(LennardJones())
atoms.get_forces()

csc   = check_SC_convergence(atoms,atoms.get_forces(),mu_num_spec=imp)
cond  = csc.apply_first_crit()
cond2 = csc.apply_2nd_crit()
print(f"Convergence of 1st criteria is {cond}, while 2nd criteria is {cond2}")

Many undocumented exceptions are raised.

It worked fine for me. I got only the  'prints' I left in the code to see what happens which will be later refined, depending on the workchain.
This is what the code above prints for me.
"""
First SC convergence Criteria  NOT achieved
For specie Fe the 2nd SC convergence is NOT achieved, min dist required is 10.159411694927224 Ang
The current SC size is NOT sufficient for convergence checks on specie--> C
Convergence of 1st criteria is False, while 2nd criteria is [False, False]
"""
I expect this from the code as it is now.

Can you post the exceptions  that were raised for you?

I just tried with all the cif files that I have on my laptop, but the code needs to be adapted to work with materials project for example.

Not sure I get it,  why we need to adapt it to material project.

Nothing to adapt in your code, it's just the test above that can be easily interfaced with COD, materials cloud, or any other source of CIF.

Final comment, this code can be used to test the whole iterative procedure without aiida. I think it's a good idea to get a feeling of the expected results.


add unix socket support

At the moment only a TCP server can be made.
This PR allows the user to use a unix socket and create a UNIX Domain socket server.

As far as I know, the specification of websockets only describes its usage over TCP and optionally TLS. There are some TCP-specific considerations in the design. This makes me uncomfortable about supporting "websockets over unix sockets".
That said, outside of providing defaults for various arguments, serve does very little. It's just a helper for creating an asyncio server with WebSocketServerProtocol.
You could reuse WebSocketServerProtocol, where most of the value of websockets lies, and copy-paste the five lines you modified in the PR to start your server.

I see what you mean. I hence decided to follow your advice by creating a new serve function ,which uses create_unix_server. Thanks

Thanks, it's good to know that this workaround solves your problem. Could you share your alternative version of serve()?
I understand the use case. It's quite reasonable. Let's keep the pull request open for now.

Sure !
def serve(ws_handler, path=None):
    loop = asyncio.get_event_loop()
    ws_server = WebSocketServer(loop)
    factory = lambda: websockets.WebSocketServerProtocol(ws_handler, ws_server, loop=loop)
    server = yield from loop.create_unix_server(factory, path)

    ws_server.wrap(server)

    return ws_server```

Superseded by #281 which provides a first-class API, similar to create_unix_server vs. create_server


New features added without incrementing minor version number

NLog version: 4.6.2
Platform: .NET Core 2
Current NLog config: N/A
I have NLog 4.6.2 in a project, and NuGet tells me there is a newer version available. While checking the CHANGELOG, I see that all the 4.6.x patch releases since then also include new features and improvements. Shouldn't the minor version be incremented for these, and not the patch? The current pattern makes it more challenging to assess the risk of updating.
I have read in a few other issues that the team takes SemVer very seriously so this has left me a bit puzzled.

hey! You're right that updating the minor version would be better.
Currently we also do small features in patch releases. Those are features with a really small impact on current code.
Note: I think we're doing that from version 4 (2015).
Unfortunately I think this is a result of open source contributions. Pull requests are submitted unplanned and so we get most of the time a feature change before a bugfix.  So to keep things we are not removing the feature before doing a patch release.
I have to think if we need to change it. If we would do that, then that will having the following consequences:

We will do a lot more minor releases
We will delay small features because of patch releases which only contains bugfixes.

Must admit I like the goal of not having PullRequest resting for a very long time. So when community offers a new feature, then they should not be punished to constantly handling merge-issues while waiting for the next minor-version.
Also don't think the NLog-team is a large enough to maintain multiple release-branches and dev-branches. Already enough confusion by maintaining a dev-branch and master-branch.
To me the semver for minor-version is mostly about:

Not making existing classes as obsolete and generate build-versions.
Not removing existing classes and generate build-errors
Not changing existing interfaces and generate runtime-errors / build-errors.
Not changing existing methods and generate runtime-errors / build-errors.

So I prefer that we stay away from bumping minor-version unless marking things obsolete, or introducing major features with new interface or new building blocks.

A good discussion! It's a nice "problem" to have such an active community making PRs!
SemVer clearly states:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

I think not getting any "real" patch versions wouldn't really make it any different than the current process -- as mentioned there have been very few fix-only releases. But bumping the minor version would be more reflective of the state of the project and provides more clarity.
I understand, however, that your current overhead for releasing minor version updates may not make that practical.

SemVer clearly states:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

Yes, I saw it.
I'm thinking to remove the semver badge and update the text.
For NLog 5, I think creating more minor versions is feasible. But we NLog 4 we keep the process now as is.

Obviously it's up to the NLog team on how to proceed. But for now at least I have more clarity on the current practice, which is what I was initially looking for. Feel free to close this issue unless you want to use it to track some action item.


Profile image

Image is not circle

:joy:  :joy: :smile:
only add this and fix :+1:
        width: 250px;
        height: 250px;


Use xorg-libxfixes

Appears we are using a CDT for libxfixes. However we have the conda-forge package xorg-libxfixes, which should work in place of it. Would be good to switch over if we can.

We decided to go with the CDTs for now. There is a CFEP, https://github.com/conda-forge/conda-forge-enhancement-proposals/pull/7, that we should vote/discuss more and than we can make changes like this everywhere. (Preferível with a migrator.)
Closing this as stale.


[Sema] Fix protocol refinement access control message

Previously, the protocol refinement access control error would always assume a protocol was being refined/used in a where clause. Change it to instead refer to the appropriate declaration kind.
Resolves SR-9195
cc @slavapestov

@swift-ci Please smoke test

Oh hey, I filed this.


Ci/setup ci

Make this forked project able to build a docker image and push it to ghcr.
Additionally and some linters and make then happy.

/publish

Hi @amimart, I added the release workflow


External contributor seeking a good first issue

Description
Is there any good first contributions that will be ok to solve?

Hi @evenstensberg! Thanks for reaching out. We're a bit behind on creating a backlog for Explorer-1. Can you share what about this project interests you and/or what types of things would be fulfilling for you to work on? That will help us get started on a backlog of good first issues.

Hi! Okay, that is fine. I want to contribute to any Front End problems, preferably in JS/TS!

Okay, we still haven't gotten to creating a backlog of first issues yet, but here's one that's CI-related: https://github.com/nasa-jpl/explorer-1/issues/512
If you're interested, feel free to take it on!


Add support for parsing unix timestamp measurements

Proposed changes
This is an initial proposal for how thin-edge JSON measurements can be augmented to support unix timestamps in addition to ISO-8601 (/RFC-3339 which is what we actually parse and emit). At the moment it does not make any changes to the code generating thin-edge JSON, nor the documentation.
It currently parses an integer number of seconds, as this is the easiest format to process with the time crate, although it would be pretty easy to modify this to be something different, which could be:

integer number of milliseconds/microseconds/nanoseconds
float number of seconds
a number with a suffix to represent the unit (e.g. "1701952729000ms") (which could be provided as an alternative to one of the other proposed formats)

In short, there's a lot of flexibility here. Parsing something other than seconds or nanoseconds will make the error messages from time a little bit less clear. These errors only occur when times are out of the time crate's supported range, which run from (-9999-01-01 to 9999-12-31), so they're unlikely to occur in practice. So long as we add clear supplemental information about what units we are using, it should be easy to debug in any case.
Not a breaking change at the time of writing this as all it does is add support on the parsing side, but the feature as a whole is definitely a breaking change for people inspecting messages thin-edge sends.
Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue
https://github.com/thin-edge/thin-edge.io/issues/2337
Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[x] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

This is a good start.

It currently parses an integer number of seconds, as this is the easiest format to process with the time crate, although it would be pretty easy to modify this to be something different, which could be:
integer number of milliseconds/microseconds/nanoseconds
float number of seconds
a number with a suffix to represent the unit (e.g. "1701952729000ms") (which could be provided as an alternative to one of the other proposed formats)

I would avoid to accept too numerous alternative formats, as this might add more confusion than help.

Seconds since Epoch is an usual and sound choice
If by float number of seconds you mean something such as<PHONE_NUMBER>.877, Yes this is a good option. This improves the precision while being compatible with Seconds since Epoch.
I would avoid Milliseconds since Epoch because not compatible with Seconds since Epoch.

In short, there's a lot of flexibility here. Parsing something other than seconds or nanoseconds will make the error messages from time a little bit less clear. These errors only occur when times are out of the time crate's supported range, which run from (-9999-01-01 to 9999-12-31), so they're unlikely to occur in practice. So long as we add clear supplemental information about what units we are using, it should be easy to debug in any case

I will not bother too much on the extent of the accepted date range, as the point is only to represent now.

Not a breaking change at the time of writing this as all it does is add support on the parsing side, but the feature as a whole is definitely a breaking change for people inspecting messages thin-edge sends.

I think the only time-related messages published by thin-edge are health check messages. So, the scope of the breaking change is quite small.
All this needs to be discussed with @albinsuresh and @reubenmiller.

I would avoid to accept too numerous alternative formats, as this might add more confusion than help.

Seconds since Epoch is an usual and sound choice
If by float number of seconds you mean something such as<PHONE_NUMBER>.877, Yes this is a good option. This improves the precision while being compatible with Seconds since Epoch.

This is in line with what I would expect as a user. I think the suggestions that aren't just a number of seconds are needlessly confusing for what is meant to be a simpler way of representing timestamps. We can easily accept an integer or floating point number of seconds (your understanding of what I meant by that is correct), I just haven't bothered to do that yet. I expect this to be only marginally less trivial than the integer case though.

I would avoid to accept too numerous alternative formats, as this might add more confusion than help.

Seconds since Epoch is an usual and sound choice
If by float number of seconds you mean something such as<PHONE_NUMBER>.877, Yes this is a good option. This improves the precision while being compatible with Seconds since Epoch.

This is in line with what I would expect as a user. I think the suggestions that aren't just a number of seconds are needlessly confusing for what is meant to be a simpler way of representing timestamps. We can easily accept an integer or floating point number of seconds (your understanding of what I meant by that is correct), I just haven't bothered to do that yet. I expect this to be only marginally less trivial than the integer case though.

The other decision to be made with floats is how much precision do we want to preserve? The way we need to convert the f64 to an OffsetDateTime is by supplying an integer (i128) number of nanoseconds. I think at this point I would be tempted to multiply the value by 1000 and then round that to get an integer number of milliseconds before converting to nanoseconds, because much more precision will likely be junk information. If someone really cares about precision, they could always use ISO8601 instead.

I agree with all of the suggestions from @didier-wenzek in https://github.com/thin-edge/thin-edge.io/pull/2508#issuecomment-1845625274

I think the only time-related messages published by thin-edge are health check messages. So, the scope of the breaking change is quite small.

We can make the transition as easy as possible by making the timestamp configuration configurable (on a mapper and tedge level)

aws setting to control the outgoing message to use RFC3334 or unix timestamp format
azure setting to control the outgoing message to use RFC3334 or unix timestamp format
tedge setting to control the local (tedge) message used when internal components of thin-edge.io services use when to post information about when the service health was published locally (e.g. RFC3334 or unix timetsamp)
Use default settings of unix timestamp (for all of the settings above)

I've now moved the timestamp module to tedge_utils and re-export it from tedge_config (for the convenience of the higher level crates). Annoyingly, it hasn't become much simpler, but now code only needs to interact with either TimeFormat (for serialization) or IsoOrUnix (for deserialization)

I've now moved the timestamp module to tedge_utils and re-export it from tedge_config (for the convenience of the higher level crates). Annoyingly, it hasn't become much simpler, but now code only needs to interact with either TimeFormat (for serialization) or IsoOrUnix (for deserialization)

Yeah, I'm also a bit surprised to see how many dependencies have to be pull down from tedge_config to  tedge_utils.
But, we will see later how to re-organize the crates.

The failing system is likely due to this PR "Watchdog does not kill mapper if it responds"
Also, you still have to fix https://github.com/thin-edge/thin-edge.io/pull/2508/files#r1423786896

@didier-wenzek I've now fixed both of these (see https://github.com/thin-edge/thin-edge.io/pull/2508#discussion_r1428044445 about the first point)


error when metadata is present but empty?

This is the relevant line that assumes length(pairs) > 0:
https://github.com/JuliaData/Arrow.jl/blob/3deb5b9570b18d84ae6be19bb5cf465458beeb81/src/utils.jl#L202
I suppose this needs to be tweaked to return an empty ImmutableDict for empty pairs?

Hi @ericphanson - do you think you could have a look at this please? I'm still on 2.0.0

Would you be up for making a PR? It should just be a matter of checking if pairs is empty and returning a Base.ImmutableDict{String,String}() if so.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #814 (20ca3be) into main (25a6217) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@           Coverage Diff           @@
##             main     #814   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       53       53
=======================================
  Hits          378      378
  Misses         17       17


Support operator for common class like String

I could not using "+" operator to append string, it's good if the lib support it, by now I have to using externalFunctions to append two string.
Thank you.

try .toStringAsFixed() for a num.
That's because https://github.com/hythl0day/hetu_script/issues/4 is still not fixed :/

Sorry because I've tested with case append string and num toString, it's run ok with toStringAsFixed.

I've tested again, and it looks like that .toString() works in 0.0.2+4

I tested in 0.0.2+4, it's okay.
proc main() {
  var first = 'first';
  var last = 'last';

  print(first + last);

  print(3.toString() + first);

  print(233.toString() + true.toString());

  print(['hello, world'].toString() + 42.toString());
}


Relational Data Model

Description
Give an explaination of Relational Data Model and Reduction of E-R Schema to Tables.
Domain
Database
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

I am the author of this issue now. Have a nice day !

/assign


Remove Improve this Doc from C# API pages

Found this in the styles checklist in the doc roadmap.

Is this working?

Thanks!


thetakhirov patch #2 | some updates

Changes:

Added specific routes
Added config files
Added hints for IDE:

Next plans 🏁

Create middlewares


Build error after upgrading to version 1.9

Confirm by changing [ ] to [x] below to ensure that it's a bug:

[x] I've gone though Developer Guide and API reference
[x ] I've searched for previous similar issues and didn't find any solution

Describe the bug
I have been building a shared library that uses the sdk for transcribestreaming and lexv2-runtime.  Before upgrading to 1.9, I was including all of the aws-c-* libs in my link step, i.e.
-laws-cpp-sdk-transcribestreaming -laws-cpp-sdk-core -laws-c-event-stream -laws-checksums -laws-c-common -lpthread -lcurl -lcrypto -lssl -lz

and this all worked fine.
Now, I have upgraded to version 1.9.  I followed the instructions to git update submodules --init --recursive to get the new crt lbraries, etc and successfully built the sdk (tests at the end of the build step pass).
I changed my link command to this:
-laws-cpp-sdk-transcribestreaming -laws-cpp-sdk-core -laws-crt-cpp -lpthread -lcurl -lcrypto -lssl -lz

as it was my understanding from the docs that libaws-crt-cpp encompasses the other libs
My problem is that when I try to load my shared library I get an undefined symbol error
2021-05-19 18:40:40.934882 [CRIT] switch_loadable_module.c:1785 Error Loading module /usr/local/freeswitch/mod/mod_aws_transcribe.so
**/usr/local/freeswitch/mod/mod_aws_transcribe.so: undefined symbol: aws_tls_ctx_release**

Any idea what I am doing wrong?  Are there additional libraries I should link with? Any insight will be much appreciated
Here, by the way, is my cmake command to build the sdk
cmake .. -DBUILD_ONLY="lexv2-runtime;transcribestreaming" -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_FLAGS="-Wno-unused-parameter"

SDK version number
1.9
Platform/OS/Hardware/Device
Debian 10
To Reproduce (observed behavior)
Steps to reproduce the behavior (please share code)
Expected behavior
My shared library would load successfully and be able to use the sdk apis
Logs/output
If applicable, add logs or error output.
Additional context
Add any other context about the problem here.

Closing this, as I was able to build after adding all the libraries.  (However, my process now crashes while handling a transcribe request - may open a separate issue on that).
For posterity, I had to fiddle with the link order a bit, this is what worked
-laws-cpp-sdk-transcribestreaming -laws-cpp-sdk-core -laws-crt-cpp \
-laws-c-s3 -laws-c-http -laws-c-auth \
-laws-c-mqtt -ls2n -laws-c-compression -laws-c-io -laws-c-cal -laws-c-event-stream \
-laws-checksums -laws-c-common  \
-lpthread -lcurl -lcrypto -lssl -lz

I have also experienced this problem， but in S3 function。This is my link lib order
 -laws-cpp-sdk-s3 -laws-cpp-sdk-core -laws-crt-cpp -laws-c-s3 -laws-c-http \
-laws-c-auth -laws-c-mqtt -laws-c-compression -laws-c-io -ls2n -laws-c-cal \
-laws-c-event-stream -laws-checksums -laws-c-common  -lpthread -lcurl \
-lcrypto -lssl -lz -ldl


data.current(..., 'close') vs data.history(..., 'close', ...)

Dear Catalyst Maintainers,
Description of Issue
I get different values when running data.current vs data.history, here are the re-production steps:

run_algorithm with bitfinex and quote_currency should be btc
When data.current_dt is equal to 2018-04-16 00:00:00+00:00 , run data.current(symbol('neo_btc'), 'close'), you will get the value 0.00846018
Run data.history(symbol('neo_btc'), ['close'], 1000, '60M'), the value for 2018-04-16 00:00:00+00:00 is now 0.0084583.

What did you expect to happen?
Both values to be the same. Actually, I don't know which one is the correct one.

What happened instead?
Two different values.

What steps have you taken to resolve this already?
I noticed that when using .history(...) the correct value is placed 1 hour before, specifically 2018-04-15 23:00:00+00:00
Anything else?
Thanks!

Thanks for reporting.
Could you please provide the following  information:

The mode of algorithm (I assume it is backtest, right?) and the data frequency in use
The exchange you are using
catalyst version

Thanks,
Lena

Thanks for the fast response!

mode is backtesting, data frequency is minute
exchange is bitfnex
catalyst version is 0.5.14

I think we can close this.
I just now realized that I am running .close in a minute setting not an hour setting so it gives me the last price of 2018-04-16 00:00:00+00:00 minute, not hour

Why would you expect that during a period, data.current would return the close price for this period? This would introduce an obvious look ahead bias: you cannot know the close price until after the period has ended.

@sam31415 I am not sure what is the problem.
I put the order at the end of the current period (the close price).
Catalyst engine then simulates the buy at the order of the next close price.

I don't think it works like this, at least from my experience on Quantopian. As far as I know Catalyst start working at the beginning of the period, not at the end, which imho makes sense.

From debugging the code I noticed that the orders are executed 1 bar after the one you put the orders in.
Check @AvishaiW comment in this issue:
https://github.com/enigmampc/catalyst/issues/295#issuecomment-382302818

Thanks @eranhirs , the difference in the price is indeed due to the different period used (minute vs hour).
Regarding the data.current - @eranhirs observation is correct - the current bar (which in minute frequency is a minute bar) holds the entire information for this period.
Meaning that if current_dt is  2018-04-16 00:00:00+00:00 the OHLCV information is for the period 2018-04-16 00:00:00+00:00 -  2018-04-16 00:00:59+00:00.
@sam31415 , this is not a bias, because as @eranhirs explained, all decisions are taken into consideration in the next bar. IMHO this is Zipline logic, but if you feel otherwise, please let us know.

@lenak25 One thing I can tell you for sure is that in live trading, at 2018-04-16 00:00:00, current_dt is equal to 2018-04-16 00:00:00. If now you're telling me that in the backtest in minute data, when current_dt equals 2018-04-16 00:00:00, you have access to the close price at 2018-04-16 00:01:00, then there is a look ahead bias. In live trading at 2018-04-16 00:00:00, you don't know what will be the close price of the current minute bar.
Are you really sure about what you just wrote? If yes, that's worrisome. And I really doubt such an obvious flaw would be present in Zipline. I'll check the source when I get some time.

@sam31415 that is a good point and I agree with you.
We will investigate this further to understand where this behaviour came from.
Thanks for bringing this up!

@STOpandthink I assume this is current_dt during backtesting, right? Then it means that there is indeed an inconsistency between the backtest mode and the live mode, because in live trading, current_dt is really the current time.

Thanks everyone for your inputs, we have investigated this issue and made the required adjustments, included in release 0.5.19.
The problem was due to the different definitions of the OHLCV intervals in the cryptocurrency exchanges versus the stock market.
Cryptocurrency trading exchanges use left-bounded intervals when defining OHLCV candles:
9:31 interval: 9:31:00 am <= t < 9:32:00 am
9:32 interval: 9:32:00 am <= t < 9:33:00 am
9:33 interval: 9:33:00 am <= t < 9:34:00 am

To meet the different nature of the crypto data definition versus the stock market data, Catalyst code had to be altered as follows: when the minute clock ticks at the beginning of every minute data.current returns the closing price from the previous minute and data.history last bar matches data.current providing the price up to the minute prior to the current one.
Meaning that if current_dt == 2018-04-16 00:01:00 the data.current will return the  information of the 2018-04-16 00:00:00 - 2018-04-16 00:00:59 period.
A more detailed explanation was added to our documentation as well.
@sam31415 @eranhirs @STOpandthink, thanks again for reporting!


fix(client): Correctly resolve configDir when prismaSchemaFolder is used

Configuration directory is used for resolving relative SQLite and SSL
certificates paths in QE. After #24609, we correctly changed it in all
of the CLI commands, but not in generated client. Therefore, if
prismaSchemaFolder was used, client could not find the DB or SSL
certifcate, created by migrate command.
Fix #24647
Fix #24779
/integration

Run


Support CoffeeScript 2 features

Adding require 'coffee-coverage/register-istanbul' inside Cakefile’s runTests throws errors for the files with new features added in CoffeeScript 2 (note filenames):
CoverageError: Could not parse documentation/examples/jsx.coffee:
[stdin]:9:4: error: missing / (unclosed regex)
  </aside>
   ^

CoverageError: Could not parse documentation/examples/object_spread.coffee:
SyntaxError: unexpected ...

CoverageError: Could not parse documentation/examples/type_annotations.coffee:
SyntaxError: unexpected : string

And import or export statements, added in 1.11, still aren’t supported (#82):
CoverageError: Could not compile documentation/examples/modules.coffee after instrumenting:
SyntaxError: import statements must be at top-level scope

I am pretty sure https://github.com/benbria/coffee-coverage/pull/91 isn't ready for a code base so large, but it might be worth a try? import/export aren't supported yet, but it might be a good starting point.

https://github.com/benbria/coffee-coverage/pull/91 has been merged and published as v3.0.0.


NPT ensemble in TorchMD

Hope it finds you well. I would like to perform a simulation of a lipid bilayer with semi-isotropic pressure coupling, but I found that the NPT ensemble does not seem to be available in TorchMD. How could I use pressure coupling in the simulation? Any suggestions are welcome.

Hi, there is no support for barostats in torchmd. I have not considered myself how to implement it either, so I cannot help you much. Feel free to work on it and make a PR though if you want.


CVE-2020-7608

https://github.com/advisories/GHSA-p9pc-299p-vxgp
The package showdown has an old yargs-parser dependency with this critical security vulnerability. Can we update the dependencies to remove it?

This one is important for us, too - @jessiehuff

If you're still on PF4:
<EMAIL_ADDRESS>If you're on PF5:
<EMAIL_ADDRESS>In either case, showdown is no longer declared a dependency, it continue to remain a peer dependency though.
So in your own project, make sure that showdown is at 2.1.0 or greater.
i.e.
https://github.com/opendatahub-io/odh-dashboard/blob/main/frontend/package.json#L75
https://github.com/openshift/console/blob/master/frontend/package.json#L220
Could be updated


ENH fix rtti issues on osx

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

See this issue (https://github.com/conda-forge/clangdev-feedstock/issues/67) for why this PR exists.
Also, reading the FAQ and ABI info here (https://libcxxabi.llvm.org/) is pertinent to this PR.
TL;DR This should be safe and helps C++ libraries preserve RTTI information across linkages.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

For all platforms, or just osx?

IIUIC, on linux we still need it.

Let's go with on OSX for now.

Well the tests pass! IDK how the recipe looks. Thoughts?

Can you check that the symbols exported by the new libc++.dylib is the same as the older build number?

This won't build on my mac so I am exporting the symbol list in the ci. I'd like to build it locally on my mac to ensure that the fix works but we might not be able to. Are we saving artifacts in the CI for people to download and test with? That'd be nice right now...

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

The recipe must have some tests.

Also the compile tests are not being run.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Alright finally. Here is the diff of the symbols
(base) localhost:Desktop Matt$ diff old_syms.txt nw_syms.txt
2440a2441
> _bcmp
2447d2447
< _chmod
2454a2455
> _fchmodat

They are in different spots, but I don't think that matters. I used nm -gj to export.

And now conda build is not using the test requirements for outputs like it claims it should. :(

Alright @isuruf. I am filling a ticket with conda-build for the bug in the test env. I am going to comment out those tests for now.
Here is the diff of the symbols again in case it go lost in the shuffle:
(base) localhost:Desktop Matt$ diff old_syms.txt nw_syms.txt
2440a2441
> _bcmp
2447d2447
< _chmod
2454a2455
> _fchmodat

@conda-forge-admin, please rerender

Please don't comment out tests, at least on OSX.

Sure, but do be aware that the tests of the code compiling were not ever running. They also won't unless we remove the multiple outputs. Right now conda build won't inject the parent test requirements into the subpackage envs.

issue w/ conda build for cross-reference: https://github.com/conda/conda-build/issues/3777

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you, but it looks like there was nothing to do.

@conda-forge-admin, please restart build

OK @isuruf. I've solved the issue with the tests (the conda build documentation was wrong) and they all run now. I also built the package locally and it makes the error I reported go away.
Does the difference in the symbols worry you?

@conda-forge/clangdev Do any of you understand this package conflict for linux?
Package libllvm8 conflicts for:
clang -> libllvm8==8.0.1=hc9558a2_0
Package clangdev conflicts for:
clang -> clangdev[version='8.0.0|8.0.1|9.0.0']
Package libgcc-ng conflicts for:
clang -> libgcc-ng[version='>=7.3.0']
Package libcxxabi conflicts for:
libcxx==9.0.0=h14c3975_1 -> libcxxabi==9.0.0=1
Package libstdcxx-ng conflicts for:
clang -> libstdcxx-ng[version='>=7.3.0']
Package gcc_impl_linux-64 conflicts for:
gcc_linux-64 -> gcc_impl_linux-64[version='5.4.0.*|7.2.0.*|7.3.0.*|8.2.0.*']
Package package_has_been_revoked conflicts for:
gcc_linux-64 -> package_has_been_revoked
Package libllvm9 conflicts for:
clang -> libllvm9==9.0.0=hc9558a2_2
Package libcxx conflicts for:
libcxxabi==9.0.0=1 -> libcxx==9.0.0=1
Package clang conflicts for:
clangxx -> clang[version='8.0.0|8.0.1|8.0.1|9.0.0|9.0.0',build='hc9558a2_0|hc9558a2_1|hc9558a2_0|hc9558a2_6|hc9558a2_3|hc9558a2_4|hc9558a2_5|hc9558a2_1']
Package libclang conflicts for:
clang -> libclang==8.0.0
Package binutils_linux-64 conflicts for:
gcc_linux-64 -> binutils_linux-64[version='2.28.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|2.31.1|5.4.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0|7.2.0',build='hc67e822_9|hc67e822_15|25|had2808c_24|h6176602_9|h6176602_6|h6176602_2|h6176602_1|h6176602_0|he4fe6c7_1|h6176602_10|h6176602_11|h6176602_12|h6176602_3|h6176602_7|h6176602_8|19|26|had2808c_27|hc67e822_10|hc67e822_11|hc67e822_12|hc67e822_13|hc67e822_14|hc67e822_2|hc67e822_3|hc67e822_7|hc67e822_8']
Package clangxx conflicts for:
clang -> clangxx[version='8.0.0|8.0.1|9.0.0']
Package clang-tools conflicts for:
clang -> clang-tools[version='8.0.0|8.0.1|9.0.0']

IDK how or why libllvm8 is getting pulled in.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

The recipe must have some tests.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Let's just remove libcxxabi for all platforms.

I am going to build linux against the libstdc++ ABI provided by the default compilers.

Sure. We are not using it and it is in the git history, but happy to keep all of the windows stuff in the current head.

So building libc++ against the ABI in libstdc++ for linux means that when this library is used, one has to pass -llibstdc++ at link time even if you intend to use libc++. Is this weird @isuruf? IDK who uses this package on linux, but I am guessing this could break things for them. Maybe using none on linux might be better?

Th advantage of the build as it stands now is that in principle two libraries, one compiled with libc++ and one compiled with libstdc++, could pass around exceptions or something I think.

meh it is not linking right anyways going to go with none in the interest of finishing this.

Grrrrrrrrr. We should simply package the cxxabi with the cxx lib and call it good. IDK what the none setting is, but it appears to just not define the symbols it needs. I would have thought none would include those symbols in libc++ or something.

There is this option: LIBCXX_ENABLE_STATIC_ABI_LIBRARY

Bundling seems fine. We were using a run constrained section with an exact pin.  Thus they were bundled anyways.

OK @conda-forge/libcxx. This is the best I can do. To summarize

We have remove the separate libcxxabi library in order to work around some weird solver conflict.
On osx, we now pull libcxxabi from the system libraries and we do not ship our own. This solves an exception RTTI problem I was having.
On linux, we now bundle libcxx and libcxxabi into a single package called libcxx. The recipe was using exact pins and an exact run constrained, so this procedure is not actually different from what we were doing.
I have reenabled the compilation tests that were being skipped.
I cleaned up some windows stuff we are not using.
The ppc64le and aarch64 builds still fail due to a missing dependence (clangdev 9 and llvmdev 9).

Shall we merge?

@beckermr, can you clean up the commits or shall I squash and merge?

squash and merge is great.

Wooooooo! Thank you @isuruf! As usual you are very helpful and I learned a lot!


core[minor]: Add XML output parser

I think we can do streaming with something like this: https://github.com/matteodelabre/saxophone


Updating .kproj files

Hi @BrennanConroy, I'm your friendly neighborhood Microsoft Open Technologies, Inc. Pull Request Bot (You can call me MSOTBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.msopentech.com.

TTYL, MSOTBOT;

@BrennanConroy why are you updating the .kproj files in this repo?
looks like the changes are just to the byte order mark.  IOW no real changes.
side curiosity: what script are you using to do this work?


Defining a ruleset

I've an API endpoint, /api/create/. This creates a new entry in the DB depending upon the payload received from the client.
Payload - {
'field1': 'value1`,
'field2': 'value2`,
'field3': 'value3`,
'field4': 'value4`,
'type': 'A'
}

Now depending on the type, I've a specific ruleset/workflow. For eg:- Type A needs to perform certain tasks before saving the data, Type B has its own set of operations.
I don't have any UI, just the requests coming over the POST request. How can I use rules for such a use-case?

Yes, you can. You can write a rule to start a ruleset or you can have a top level branch rule:
with statechart('risk3'):
    with state('start'):
        @when_all(m.type == 'A')
        @to('A')
        def action_A(c):

        @when_all(m.type == 'B')
        @to('B')
        def action_B(c):

    with state('A'):
        # do your thing

    with state('B'):
        # do your thing

run_all()

Please take a look at the docs for all the details:
https://github.com/jruizgit/rules/blob/master/docs/py/reference.md


Add uptime for ocean fish

Adds ocean fishing time (sunset, night, day) to individual fish, and route calculation based on real time to figure out when those routes are available.

This is a little bit of a work in progress still.  It seems to be working fine for the fish window and the fish timer window for spectral fishing spots, but there's some fish that seem like they're unavailable based on coloring in the fish timer window for non-spectral ocean fishing spots.  I'll sort it out, but happy to fix any feedback in the meantime if you had it.

d02cc68 needed some more ocean fishing special cases, but this should be good to go now.

I'll close this and look through the other PR when I find the time, it contains those 6 commits from here anyway.

Oh, I could have rebased the other one once you finished looking at this.  However you want to do it.


symbolic link ${jdk-home}/lib to forwarding toolchain directory for Kotlin

Closes #417
Test plan
I tested this on https://github.com/fwcd/kotlin-language-server :slightly_smiling_face:

I might have to change this to copy everything, as symbolic links under Windows has historically required elevated permissions. What do you think? @olafurpg


Missing new network names in /networks/id/assets/id

Issue moved to LimeChain/hashport-api #116 via Zenhub


neocube.bsc: Use integer division

fixes paulscottrobson/neo6502-firmware#14
(trying how this works from the fork)

Already fixed it :)


Feature Request: CRD Support

Hi,
It would be nice to be able to support CRDs such as those provided by cert-manager and Itsio in a generic way. Alternately a documented way to create a package that registers those CRDs for use with this library.

I was thinking about it while I had to write some custom CRDs for a project that uses Agones, but no docs are currently available. Perhaps it's a good start to write some 🤔

Looking at a couple of CRDs, it looks like the cluster has a few with openAPIV3Schema on it.
For instance on one of my clusters I ran kubectl get crd for a list and then did kubectl get crd -o yaml certificates.certmanager.k8s.io which then had the schema definition.

I can only show an example for the Issuer in cert-manager.io/v1:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: sandbox
spec:
  selfSigned: {}

namespace My\Namespace;

use RenokiCo\PhpK8s\Contracts\InteractsWithK8sCluster;
use RenokiCo\PhpK8s\Kinds\K8sResource;

class Issuer extends K8sResource implements InteractsWithK8sCluster
{
    /**
     * The resource Kind parameter.
     *
     * @var null|string
     */
    protected static $kind = 'Issuer';

    /**
     * Wether the resource has a namespace.
     *
     * @var bool
     */
    protected static $namespaceable = true;

    /**
     * The default version for the resource.
     *
     * @var string
     */
    protected static $defaultVersion = 'cert-manager.io/v1';
}

Also, there are a lot of traits and contracts that can be added. But it seems like docs need a little bit of revamping. 🤓

https://github.com/renoki-co/php-k8s/blob/revamp/docs/docs/CRDS.md


Create config

HI, I couldn't copy the config.example file cause it didn't work for mine..
So, I made wanted you guys to make a new file..
Thanks,
MidnightPatio

The idea is to not have the actual config file in the repository, since it's unique for each setup and would create merge conflicts if the example config was ever modified. Issues copying the file are unfortunately not related to the bot.