chat with bob example broken

Hi @abdeladim-s , thanks for the update!
I was trying to update to pyllamacpp==2.4.0 but found that even the example on the README, which is similar to llama.cpp's ./examples/chat.sh but not identical, is not working properly. For example, when I copied the example code into a foo.py and run it, I got:

If I go to llama.cpp, check out 66874d4 then make clean && make && ./examples/chat.sh, I got:

I just want to get an equivalent of running llama.cpp's chat.sh with pyllamacpp==2.4.0, no more no less. How should I do it?

Hi @nuance1979, You are welcome & thanks for reporting the bug.
Could you please let me know what model are you using so I can debug using the same model ?

@nuance1979 Oh, I have just noticed! it was just the print out of scope :sweat_smile:
please give it a try now and let me know if the problem persists ?

@abdeladim-s Yes, the format is fixed. But I was mainly talking about the content that's not right:

You see the ./examples/chat.sh from llama.cpp gives me the sensible answer about who Barack Obama is but your code snippet gives me non-sensical answer. Something is wrong.

I think you just need to specify the exact parameters as that chat.sh example.
I have updated the example in the readme to match it.
Those are my results :

Please update from source and give it a try ?

Thanks a lot! I don't know why but I'm still getting non-sensical results like this after I install from master branch and use the updated example:

Another try, still non-sensical:

I see a difference in llama_init_from_file: kv self size = 512.00 MB while when I run ./examples/chat.sh it was 256 MB. Not sure if that makes a difference. But when I run ./examples/chat.sh, I can always get answers that makes sense.

@nuance1979, that's weird, the model seems to be always hallucinating! on my end everything's working as expected (as you can see on my previous comment).
yeah you are right, I really don't know why it is devised by half, usually it equals to the context size!
but I don't think this hallucination problem  has nothing to do with  the kv cache size.
You should at least get meaningful results!
have you tried other models?
Can you try the pyllamacpp cli as well ?

I tried pyllamacpp cli and still got non-sensical output:

I checked the SHA256SUM of my .pth and f16.bin files and they matched completely. Again, the same model gave me completely sensible answer when invoked with ./examples/chat.sh so the logical conclusion is that something within pyllamacpp is not right. You can try check your model's SHA256SUM against this file: https://github.com/ggerganov/llama.cpp/blob/master/SHA256SUMS

Yeah something is happening, but I honestly have no idea since I couldn't reproduce this issue on my end.
Do you have any idea how to proceed ?

Can you ask a third person to try it? Just to see whether it's a problem on my side.

Sure .. let us try that, @ParisNeo is using pyllamacpp as a backend to his UI, and his repo has so many stars already.
--
Hi @ParisNeo,
Could you please let us know if someone on your repo has reported a similar problem to this issue ?
And ,if you have some time, could you please try the example in the readme page whether it's working properly on your side ?
Thank you!

Hi, No, I didn't have any complaints about the pyllamacpp backend yet. If I have time tomorrow I'll try. I got to go.

Thanks @ParisNeo, Let us know if you found any issues.

hi @nuance1979, any news on this ? Are you still getting the same error ?
Yes. Still non-sensical answers.

If you know someone else who can test it then please send them a message!
Sure. I'll ask my friend to test it.

Otherwise I have tried to test it on colab as well, even though it is slow, but it worked as expected. Please give it a try, here is the notebook.
All my tests were done with the original llama 7B model (quantized into q4_0.bin with llama.cpp). But you are testing WizardLM-7B in the notebook so I don't think it's useful here.

Ok. I tried your notebook with llama-7b and it can reproduce what I saw:

Again, I want to emphasize that the same model behaves correctly when I use ./examples/chat.sh from llama.cpp repo.

All my tests were done with the original llama 7B model (quantized into q4_0.bin with llama.cpp). But you are testing WizardLM-7B in the notebook so I don't think it's useful here.

Oh! are you using the original model? .. So maybe that's the source of the problem.
The original LLaMA model is not fine-tuned on instruction-response, so using it in a chat manner is not really correct! But I am quite surprised it is working on llama.cpp.
I will try to test with the original model and see.
But usually, you will need to try that example with fine-tuned models like wizardLM alpaca 'vicuna` etc. to get good results.

I understand the difference between original llama and instruction-tuned variant. All I'm saying is that the fact that llama.cpp works under the same condition points to a potential bug in pyllamacpp and it would be great if you can fix it.

@nuance1979, Yeah you are right. Sorry for that :(
I don't know what am I messing in my implementation. especially it seems to be working with other models!
I need to check it again ..
Let me know if you have any ideas .. any help would be appreciated! Thanks!

in lord of llms, I had to do this in my install script:
            # Step 2: Install dependencies using pip from requirements.txt
            env = os.environ.copy()
            env["BUILD_CUDA_EXT"] = "0"
            requirements_file = current_dir / "requirements.txt"
            subprocess.run(["pip", "install", "--upgrade", "--no-cache-dir", "-r", str(requirements_file)], env=env)

if it helps someone, I tried it like this. edit cli.py and make following changes:
PROMPT_CONTEXT = """Transcript of a dialog, where the User interacts with an Assistant named Bob. Bob is helpful, kind, honest, good at writing, and never fails to answer the User's requests immediately and with precision.

User: Hello, Bob.
Bob: Hello. How may I help you today?
User: please tell me the largest city in Europe.
Bob: Sure, The largest city in Europe is Moscow
"""
PROMPT_PREFIX = ""
PROMPT_SUFFIX = ""

example output:
python3 cli.py /Users/xxx/llm/llama-cpp-python/models/vicuna-7b-1.1.ggmlv3.q5_1.bin

██████╗ ██╗   ██╗██╗     ██╗      █████╗ ███╗   ███╗ █████╗  ██████╗██████╗ ██████╗
██╔══██╗╚██╗ ██╔╝██║     ██║     ██╔══██╗████╗ ████║██╔══██╗██╔════╝██╔══██╗██╔══██╗
██████╔╝ ╚████╔╝ ██║     ██║     ███████║██╔████╔██║███████║██║     ██████╔╝██████╔╝
██╔═══╝   ╚██╔╝  ██║     ██║     ██╔══██║██║╚██╔╝██║██╔══██║██║     ██╔═══╝ ██╔═══╝
██║        ██║   ███████╗███████╗██║  ██║██║ ╚═╝ ██║██║  ██║╚██████╗██║     ██║
╚═╝        ╚═╝   ╚══════╝╚══════╝╚═╝  ╚═╝╚═╝     ╚═╝╚═╝  ╚═╝ ╚═════╝╚═╝     ╚═╝

PyLLaMACpp
A simple Command Line Interface to test the package
Version: 2.4.1

=========================================================================================

[+] Running model `/Users/xxx/llm/llama-cpp-python/models/vicuna-7b-1.1.ggmlv3.q5_1.bin`
[+] LLaMA context params: `{}`
[+] GPT params: `{}`
llama.cpp: loading model from /Users/xxx/llm/llama-cpp-python/models/vicuna-7b-1.1.ggmlv3.q5_1.bin
llama_model_load_internal: format     = ggjt v3 (latest)
llama_model_load_internal: n_vocab    = 32000
llama_model_load_internal: n_ctx      = 512
llama_model_load_internal: n_embd     = 4096
llama_model_load_internal: n_mult     = 256
llama_model_load_internal: n_head     = 32
llama_model_load_internal: n_layer    = 32
llama_model_load_internal: n_rot      = 128
llama_model_load_internal: ftype      = 9 (mostly Q5_1)
llama_model_load_internal: n_ff       = 11008
llama_model_load_internal: n_parts    = 1
llama_model_load_internal: model size = 7B
llama_model_load_internal: ggml ctx size =    0.07 MB
llama_model_load_internal: mem required  = 6612.59 MB (+ 2052.00 MB per state)
.
llama_init_from_file: kv self size  =  512.00 MB
...
[+] Press Ctrl+C to Stop ...
...
You: who is barack obama?
AI:
Obama, Barack Hussein (b. 1961), first African American president of the United States (2009-17). He was born in Honolulu, Hawaii, to a Kenyan father and an American mother. After graduating from Columbia University and Harvard Law School, he worked as a community organizer in Chicago before being elected to the Illinois state senate in 1996. In 2004, he was elected to the U.S. Senate, and four years later he ran for president, defeating Republican John McCain in the general election. He won re-election in 2012. Obama's presidency was marked by efforts to address climate change, improve healthcare access, and strengthen national security through foreign policy initiatives such as the withdrawal of U.S. troops from Iraq and the pursuit of peace talks with Iran. He signed into law landmark legislation including the Affordable Care Act (ACA) and the Matthew Shepard and James Byrd Jr. Hate Crimes Prevention Act, and oversaw the end of U.S. combat operations in Afghanistan. Despite some controversies, Obama remains a highly regarded figure in American politics and continues to advocate for progressive causes through his organization, Organizing for Action.
You:

I am synced to commit 6d487b904b93c48862cc1d8b29c7f3466ca6f6a5


Increase/Decrease viewport clipping distance

Desired behavior
Right now the viewport clipping distance is locked to 1000 meters with no way to adjust it. We'd like to be able to Increase and decrease the viewport clipping distance in Ignition GUI.

+1, this is part of https://github.com/ignitionrobotics/ign-gazebo/issues/421

we can probably either put this in the View Angle plugin or make a new gui plugin.
If we're to do it in the View Angle plugin:

Add a spinbox (IgnSpnBox) to configure the camera's far clip distance in ViewAngle.qml
In spinbox's onEditingFinished handler in QML, invoke a function in the ViewAngle.cc to set a variable containing the camera's far clip distance value.
The actual call to set the camera's far clip distance needs to be done in the rendering thread (OnRender()). The View Angle gui plugin already has a pointer to the rendering camera, so it all comes down to the Camera::SetFarClipPlane call.

similar steps if it needs to be done in a separate gui plugin.


Feature/iac terraform

Type of PR

Code changes

Purpose

...
This PR contains the Terraform IaC scripts for the dataops solution

Does this introduce a breaking change? If yes, details on what can break
Author pre-publish checklist

[ ] Added test to prove my fix is effective or new feature works
[ ] No PII in logs
[ ] Made corresponding changes to the documentation

Validation steps

...
For validating these changes one can run the terraform scripts from their local machine on their personal subscription -

Go to the directory - modern-data-warehouse-dataops\single_tech_samples\datafactory\sample2_data_pre_processing_with_azure_batch\deploy\terraform

Run the following terraform commands to validate and deploy the scripts -   terraform init
   terraform plan
   terraform apply

Issues Closed or Referenced

Closes #issue_number

References #issue_number

@maansi-1608 , can you please update the root readme.md to update the steps for execution. Make sure you get the latest first.
Also list down the pre-requisites first.


Allow passing in VNode as Children

Problem

Having a component with properties like this:
#[derive(Clone, Debug, PartialEq, Properties)]
pub struct Props {
    #[prop_or_default]
    pub header: Children,
    #[prop_or_default]
    pub children: Children,
    #[prop_or_default]
    pub footer: Children,
}

It looks like you need to manually convert everything before assigning:
let header = html! {<> {"Header" }</>};
let footer = html! {
{"Some footer text"}
};

let header = Children::new(vec![header]);
let footer = Children::new(vec![footer]);

Steps To Reproduce
Steps to reproduce the behavior:

See code above

Expected behavior
I would expect this to be auto-converted:
let header = html! {<> {"Header" }</>};
let footer = html! {
{"Some footer text"}
};

html!{
  <MyComp
    header=header
    footer=footer/>
}

I guess the proper fix to this would be to create an implementation of the Transformer trait for VComp/VNode to ChildrenRenderer<VNode> and maybe also for Vec<VComp>.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:

Yew version: [e.g. v0.17, master]: v0.17
Rust version: [e.g. 1.43.0, nightly] 1.49
Target, if relevant: [e.g. wasm32-unknown-emscripten]
Build tool, if relevant: [e.g. wasm-pack, trunk]
OS, if relevant: [e.g. MacOS]
Browser and version, if relevant: [e.g. Chrome v83]

Questionnaire

[ ] I'm interested in fixing this myself but don't know where to start
[X] I would like to fix and I have a solution
[ ] I don't have time to fix this right now, but maybe later

Something to consider for #1637

As far as I know, this would require specialization which right now is nightly only

As far as I know, this would require specialization which right now is nightly only


tiny wtfs

when one grapheme becomes two unicodepoints, thus len(string) is two:
len('g̈')
'U+', hex(ord('g̈'[0])) #returns the first

despite added support for ordered dicts, the order does not matter when comparing:
{'a': 20, 'b': 2} == {'b':2, 'a':20}

pow(4,-1, 3) == 4**-1 % 3

Thanks for sharing these :)
The second one shows why using OrderedDict can still be useful in certain cases.
The third one actually throws an expception in Python 3.6, although it works fine with 3.8 or higher.


Feat: Onboard dataset Open Buildings

Description
This dataset includes 135 pipelines.
Checklist

[x] (Required) This pull request is appropriately labeled
[x] Please merge this pull request after it's approved

Use the sections below based on what's applicable to your PR and delete the rest:
Data Onboarding

[x] I'm adding or editing a dataset
[x] The Google Cloud Datasets team is aware of the proposed dataset
[x] I put all my code inside  datasets/open_buildings and nothing outside of that directory

@adlersantos @nlarge-google Please review


Enable Windows CI Running Tests on AppVeyor

When last checked, ctest would hang immediately on AppVeyor.  Running by hand is problematic (and has been for a while), so let's get this sorted out.

Any particular reason to use AppVeyor and not GitHub Actions?

Appveyor is what we had originally and if it just works, now, that's enough for the moment until we get these other things taken care of. If appveyor still hangs, then I will take the time to move us over to GitHub actions based. It will be (more of a) hassle but it will also speed things up by eliminating the need to double check things by hand.


Save users data

When a user registers in the library, it should be stored in the data file (users.csv).

There needs to be a page called /register added, or user gets registered on the /enter page?

just save user in the console app (main.py)
web registration will be on the next release


Rking/ch119887/add required providers to terraform block

TODO test with k8s provider
Test Plan

CI
tested on stp and tfe infra repos

References

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@be1d578). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #523   +/-   ##
=======================================
  Coverage        ?   55.99%
=======================================
  Files           ?       21
  Lines           ?     1943
  Branches        ?        0
=======================================
  Hits            ?     1088
  Misses          ?      700
  Partials        ?      155

Continue to review full report at Codecov.

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


grbl_ros: 0.0.10-1 in 'eloquent/distribution.yaml' [bloom]

Increasing version of package(s) in repository grbl_ros to 0.0.10-1:

upstream repository: https://github.com/flynneva/grbl_ros.git
release repository: https://github.com/flynneva/grbl_ros-release.git
distro file: eloquent/distribution.yaml
bloom version: 0.9.8
previous version for package: 0.0.6-1

grbl_ros
* fixed merge conflicts for eloquent ci
* restructure code
* fixed flake8 errors
* added python3-serial to package.xml
* dependency is pyserial not serial
* removed old import
* setup-ros reference master branch
* switched ci to rolling for main and devel branches
* added changelog for rolling release
* separated methods to semantic file name
* Delete dashing-release.yml
* Update dashing-release.yml
* Update dashing-release.yml
* Update foxy-release-candidate.yml
* Update eloquent-release-candidate.yml
* Update dashing-release-candidate.yml
* Update dashing-release.yml
* Update and rename release.yml to dashing-release.yml
* Create foxy-release-candidate.yml
* Create eloquent-release-candidate.yml
* Update and rename ros_ci.yml to eloquent_ci.yml
* Delete release.yml
* Delete release-candidate.yml
* Merge pull request #21 <https://github.com/flynneva/grbl_ros/issues/21> from flynneva/devel
* specify distro in issue body
* Merge pull request #18 <https://github.com/flynneva/grbl_ros/issues/18> from flynneva/devel
* changed checkout branch name
* Merge pull request #16 <https://github.com/flynneva/grbl_ros/issues/16> from flynneva/devel
* renamed and specified branch to checkout
* Merge pull request #14 <https://github.com/flynneva/grbl_ros/issues/14> from flynneva/devel
* create dashing release candidate
* Update greetings.yml
* Merge pull request #12 <https://github.com/flynneva/grbl_ros/issues/12> from flynneva/devel
* rolling not valid for this setup-ros release
* only run if issue has eloquent in the issue
* eloquent release
* only run eloquent on eloquent branches
* dashing release candidate
* Delete greetings.yml
* Delete docs.yml
* only release dashing on dashing branch
* run on rolling for main/devel
* import main for dashing/eloquent
* remove mac from action
* switched to mac os and back to ros-tooling wg
* removed mac from matrix
* accidentally put uses on wrong step
* test action-ros-ci that sources ROS for windows
* test windows fix for ci
* vcs-repo-file-url param
* Merge pull request #11 <https://github.com/flynneva/grbl_ros/issues/11> from flynneva/devel
* removed vcs-repo-file-url param
* bump action-ros-ci & add vcs repo url
* package should not be in matrix
* Merge pull request #10 <https://github.com/flynneva/grbl_ros/issues/10> from flynneva/devel
* bumped ros ci to 0.0.18
* regressed to ros ci 0.0.15
* specify target distro
* specify target distro
* added ros source binary for distro
* Merge pull request #9 <https://github.com/flynneva/grbl_ros/issues/9> from flynneva/devel
* Merge pull request #8 <https://github.com/flynneva/grbl_ros/issues/8> from flynneva/update_readme
* added release actions
* added testing section
* forgot to add ubuntu
* update readme
* Contributors: Evan Flynn
* separated methods to semantic file name
* Delete dashing-release.yml
* Update dashing-release.yml
* Update dashing-release.yml
* Update foxy-release-candidate.yml
* Update eloquent-release-candidate.yml
* Update dashing-release-candidate.yml
* Update dashing-release.yml
* Update and rename release.yml to dashing-release.yml
* Create foxy-release-candidate.yml
* Create eloquent-release-candidate.yml
* Merge pull request #21 <https://github.com/flynneva/grbl_ros/issues/21> from flynneva/devel
* specify distro in issue body
* Merge pull request #18 <https://github.com/flynneva/grbl_ros/issues/18> from flynneva/devel
* changed checkout branch name
* Merge pull request #16 <https://github.com/flynneva/grbl_ros/issues/16> from flynneva/devel
* renamed and specified branch to checkout
* Merge pull request #14 <https://github.com/flynneva/grbl_ros/issues/14> from flynneva/devel
* create dashing release candidate
* Update greetings.yml
* Merge pull request #12 <https://github.com/flynneva/grbl_ros/issues/12> from flynneva/devel
* rolling not valid for this setup-ros release
* run on rolling for main/devel
* remove mac from action
* switched to mac os and back to ros-tooling wg
* removed mac from matrix
* accidentally put uses on wrong step
* test action-ros-ci that sources ROS for windows
* test windows fix for ci
* vcs-repo-file-url param
* Merge pull request #11 <https://github.com/flynneva/grbl_ros/issues/11> from flynneva/devel
* removed vcs-repo-file-url param
* bump action-ros-ci & add vcs repo url
* package should not be in matrix
* Merge pull request #10 <https://github.com/flynneva/grbl_ros/issues/10> from flynneva/devel
* bumped ros ci to 0.0.18
* regressed to ros ci 0.0.15
* specify target distro
* specify target distro
* added ros source binary for distro
* Merge pull request #9 <https://github.com/flynneva/grbl_ros/issues/9> from flynneva/devel
* Merge pull request #8 <https://github.com/flynneva/grbl_ros/issues/8> from flynneva/update_readme
* added release actions
* added testing section
* forgot to add ubuntu
* update readme
* Contributors: Evan Flynn

@flynneva In your PRs for the different distros (#26402, #26403, #26404, and this one) you are using the same branch name for all of them. Why do you have different version then?
I would expect:

either separate branches for each distros if the sources are different
or a single tagged version in the upstream repo which is only bloomed for each distro?

looks like i messed up the bloom track somehow.
and yes the source code is all the same - just the linting causes errors if I keep the same "test" file for each distro. see this issue that i made earlier in the week...and the reason why I am now trying to manage different branches for each release only to handle the testing.

@dirk-thomas, i do have separate branches for each distro in the actual repo...but tags aren't branch specific so I cant use the same tag across them.
any suggestions how to manage versions across branches for different distros in the same repo?

Commonly we bump the minor version for a newer distro to leave room for future patch releases in the older distro. E.g.

dashing: 0.1.x
eloquent: 0.2.x
foxy: 0.3.x
rolling: 0.4.x


Detailed overview of prefixes

Issue type
[X ] Feature request
[ ] Bug report
[ ] Documentation
Environment

NetBox version:  2.3.3

A detailed description of the proposed functionality:
This feature request relates to issue #2100 as far as i can see.
It would be nice to be able to display all ip addresses within a (sub)prefix for ipv4 and ipv6.
When you assign an ip address you want to make sure the ip is free, Netbox covers that but what it doesn't do is hand out a detailed list of all ip addresses within that range whether it's reserved, assigned or free like in Racktables.
For example, if you create a /21 ipv4 prefix, you can create smaller childs(already in Netbox) like a /24 or even /27.
When you click on the /27 you would get a list of all the 32 ip's within that prefix and should be able to link it to devices, virtual machines and maybe even reserve it/add comments.
And the other way around, if you create devices or vm's where you need to assign single ip addresses you should also be able to get the same list, select the desired ip's and assign them.
The same goes for ipv6 except that the list would contain all the next available ipv6 prefixes within that parent. For example, a /48 should show a list that let's you assign childs of /56, /60, /64 etc... until that /48 is full.
That means if you assign a smaller prefix within an ipv4 or ipv6 prefix, the list should be updated accordingly to make it impossible to create prefixes that aren't valid.

Basically, i think Netbox should hand out available ip resources within a blink of an eye without having to think what is free or not.

A use case for the new feature: ipv4
If you have a /26 and you created it as a "shared prefix" it is possible that you want to assign ip 1 to 8 to customer A and ip 16 to 18 to customer B. When customer A wants 2 more you would have a clear overview of the assigned list and select ip 9 and 10 to be "added" to the account of customer A.
Customer A is happy not to have it's ip's scattered around the whole prefix.

A use case for the new feature: ipv6
Ipv6 contains "A LOT" of ip's, it's very easy to make mistakes, especially if you are used to ipv4.
With this feature you will have a clear overview what prefixes are available to use within an instant and without calculating or using extra tools.

A rough description of any necessary changes to the database schema
Don't think this will be a lot, prefixes are already in the database.
Maybe some extra entry's would be needed to contain detailed information per single ipv4 address or small ipv6 address like reservations and comments ?

Any relevant third-party libraries which would be needed
Don't think so.

It would be nice to be able to display all ip addresses within a (sub)prefix for ipv4 and ipv6.

In Netbox today, when you navigate to a prefix, there is already a tab labelled "IP Addresses". How does your proposal differ from this?

When you assign an ip address you want to make sure the ip is free, Netbox covers that but what it doesn't do is hand out a detailed list of all ip addresses within that range whether it's reserved, assigned or free like in Racktables.

It does, except that ranges of IP free addresses are aggregated.  Here is an example:

When you click on the /27 you would get a list of all the 32 ip's within that prefix and should be able to link it to devices, virtual machines and maybe even reserve it/add comments.

That sounds like two slightly different requests.

Itemising all free IP addresses. Note that in the Netbox data model, there is no object representing a "free" address; it's just a gap between other addresses.  But I prefer aggregating the gaps: in an IPv6 subnet you could have millions of free addresses between A1 and A2, and I wouldn't want them listed separately.

Being able to assign a free IP address directly to an interface, from the IPAM region.  At the moment, Netbox doesn't work this way: if you create an IP address first, it's quite tedious to assign it to an interface.  It works better if you go to the interface and add a new IP address there.

A use case for the new feature: ipv4
If you have a /26 and you created it as a "shared prefix" it is possible that you want to assign ip 1 to 8 to customer A and ip 16 to 18 to customer B. When customer A wants 2 more you would have a clear overview of the assigned list and select ip 9 and 10 to be "added" to the account of customer A.
Customer A is happy not to have it's ip's scattered around the whole prefix.

I think a better solution for this is IP Address Ranges, see #834

As far as I can tell, the available-prefixes and available-ips API endpoints already provide the functionality being proposed.


WIP: Server scaling

Mostly ansible and config to setup and avoid conflicts in multiple servers:

mongo replicas, using secondary to handle reads by ctf-stats
multiple web in front of a load-balancer

Note: This still requires manual actions to join the mongo replica set (rs.initliaize, rs.add, etc)

Some manual-ish steps:

Generate a keyfile for vault:openssl rand -base64 756 > /opt/mongodb/replica.key

On all dbs and web, add /etc/hosts entries for both primary and secondary (e.g. 2019db and 2019db-mirror)
mongo console on Primary

rs.initiate()
rs.add({ host: '2019db-mirror', priority: 0 })


[Vaults UI] [Bug] Manage data button under empty folder

When creating a new folder we see a manage data button that makes no sense AFAICT?

Brings to connection management


Format code and interest in accepting changes re sprite flipping and sprite anchor

Hey @FraserLee are you still maintaining this crate? And if yes, are you open to issues/changes? I'm using your crate and looking into if I can make some enhancements to it including:

sprite x/y flipping
supporting changing sprite anchor (useful when changing texture atlas index and the new sprite has a different anchor/pivot)
I wondered about your choice of pivot coordinate space because it differs to Bevy's (0.0, 1.0) vs (-0.5,0.5)

If you are open, I think it would be worth doing a quick pass over the codebase and format it like in https://github.com/FraserLee/bevy_sprite3d/pull/19 (but that PR suggests they've made code changes).
As a start, if I submit a PR to format the code without changing any logic, would you merge it?

Absolutely! Those enhancements sound great, I'm very open to them.
Quick note on formatting: default cargo fmt is pretty ruinous to the code here (you can check out the discussion on prior PRs for details). I wouldn't be surprised if there's some configuration of formatting options that are a lot better than the defaults, if you'd want to go searching for them please feel welcome. If not, please keep formatting changes manual and reasonable.
Best of luck, I hope to merge your changes soon!

@FraserLee awesome, wish me luck! Re formatting, I was hoping to just copy whatever bevy repo uses? I don't care personally about what the format is, I just noticed that in my VS Code when saving it reformats the whole world by default and I want to set the repo up so it avoids that (a la bevy repo).

I see your comments on https://github.com/FraserLee/bevy_sprite3d/pull/11. I'll see what rustfmt.toml looks like once applied.

On second consideration, I'll keep this issue open for future discussion until it's no longer needed. Feel free to keep posting here 🙂
One thing:

I just noticed that in my VS Code when saving it reformats the whole world by default

I don't want to be a prescriptivist about tools. We all walk our individual paths to a setup that works best for us and us alone, a beautifully unique entangled mess of our own idiosyncrasies, our environment, broader engineering culture, the rest of the causally connected universe in our past light-code. "Correct" is meaningless beyond what feels correct for you. There are no universal truths.
That said.
Editing text and diffing text have been solved problems since the 80s. If your editor can't edit text without destroying any meaning from the diff, you may have a problem with your editor.
I don't use VSCode, but it might be worth checking out something like this:
https://tosbourn.com/configure-vs-code-to-only-format-changed-lines/

I see your comments on #11. I'll see what rustfmt.toml looks like once applied.

Yep it's pretty much as per https://github.com/FraserLee/bevy_sprite3d/pull/11/files and I don't know rustfmt enough to be able to add rules in there off the top of my head to try and match the existing style.
I can add #[rustfmt::skip] in a couple of places to avoid changing some of the arrays, but the arrays are not that large, it doesn't feel worth it.
Anyway, if it were me, I'd just add the bevy rustfmt.toml, apply it (which feels universal in Rust but who knows maybe I know nothing), merge it and move on but it sounds like you'd prefer to leave it as is. All good, it's your decision 🙏
If I can work out a nice DX for making changes, I'll be back in the future with some PRs but I haven't got any of the features mentioned above working yet anyway, so nothing to share yet.

Hey, just throwing in my 5 cents out of the blue!
Probably best to let rustfmt handle most of the formatting (as contributors will usually auto format, afaik), then add #[rustfmt::skip] for the tricky parts (and edit rustfmt.toml for any other specifics you need). Otherwise trying to stick to a single style is going to be a pain :)

This isn't planned, so closing.


Provide documentation for the expected structure of a template container

The fhir-converter service has support for using Azure Storage as a custom template library.
However, to my knowledge, we do not provide documentation for the structure of the storage container.  For example, should we upload raw .liquid files, should they be archived in a .tar.gz or something else?

Thanks @liammoat for the feedback. Looking into this.

I'm trying to use custom template but when perform this POST request:
{       "InputDataFormat": "Hl7v2",       "RootTemplateName": "Hl7v2/ADT_A01",       "InputDataString": "MSH|^~\\&|SIMHOSP|SFAC|RAPP|RFAC|20200508131015||ADT^A01|517|T|2.3|||AL||44|ASCII\nEVN|A01|20200508131015|||C005^Whittingham^Sylvia^^^Dr^^^DRNBR^PRSNL^^^ORGDR|\nPID|1|3735064194^^^SIMULATOR MRN^MRN|3735064194^^^SIMULATOR MRN^MRN~2021051528^^^NHSNBR^NHSNMBR||"   }
I receive:
{     "error": {         "code": "InvalidTemplate",         "message": "The template content or name is invalid.",         "innerError": {             "code": "TemplateNotFound",             "message": "The requested template could not be found: Template 'Hl7v2/ADT_A01' not found"         }     } }
In attach a visual organization of the liquid template in the container.
Thanks


Make PyO3 functions as async function

Problem
Pyo3 can support async calls.
https://pyo3.rs/v0.13.2/ecosystem/async-await.html .
Because our rust APIs are all async calls, it is probably cheaper to directly implement them as async call from Python side?

this is one way to solve #736


Dialer using HTTPClient.Jar, Added Referer Header

I faced with issue when i tried to connect to Cloudflare protected resources, i wasnt able to connect after success negotiation.
Changes:
websocket Dialer use HTTPClient.Jar instead of extracting in makeHeader()
"Referer" Header added to makeHeader() without it i cant connect to CF protected resources

Hi @GanbI4. Thanks for the pull request! I looked at it and added 37db4c2dc4ad22f0a53abb529890b7e21a1c29b7 based on your diff. It adds support to re-using the cookie jar during the connect request.
However, by removing the section where cookies are added, some of the tests fail. We want to make sure the cookies are kept, but this diff causes them to be lost:
$ go test -race ./...
--- FAIL: TestMakeHeader (0.00s)
...
        signalr_internal_test.go:33: signalr_internal_test.go:732 one cookie:
                        exp: http.Header{"Cookie":[]string{"key1=value1"}}
                        got: http.Header{"Referer":[]string{"/negotiate?clientProtocol=&connectionData="}}

        signalr_internal_test.go:33: signalr_internal_test.go:732 three cookies:
                        exp: http.Header{"Cookie":[]string{"key1=value1; key2=value2; key3=value3"}}
                        got: http.Header{"Referer":[]string{"/negotiate?clientProtocol=&connectionData="}}
...

Regarding the negotiate URL Referrer header, that change will add it to every request sent to the server. Is that required or is it only needed for connect, reconnect, and/or start requests?
Lastly, you may find that https://github.com/carterjones/go-cloudflare-scraper is useful when trying to access CloudFlare protected resources. It's a bit different than the other forks I've seen.
I'm happy to make changes if necessary, but I just want to make sure they are the correct changes. Thanks again for your interest in this project :) Looking forward to hearing back from you.

893b6e26c703130eaaebd9e6dc54cb245a9dbd22 adds support for Cloudflare-protected sites. Please try the latest updates on master. If it still doesn't work for you, feel free to send a PR or create an issue with as many details as possible. Thanks again for the PR!

Hello! Thanks a lot! Looks like all is ok. Except "Referer" Header with cloudflare scrapper, but i think it should be inside https://github.com/carterjones/go-cloudflare-scraper repo, btw i made PR there too.
Anyway, now is all ok, if i add "Referer" manually by Client.Headers["Referer"] = %some_url%
Thanks again!

Great! Glad it's working. I noticed you made a PR on https://github.com/cardigann/go-cloudflare-scraper rather than my fork, which is great! However, I don't manage the original repository. So I made the change on my fork: https://github.com/carterjones/go-cloudflare-scraper/commit/e1c190340950851b5cd7fae8f809e091fa2daffd
I then updated this signalr project with that update: https://github.com/carterjones/signalr/commit/6a2792bd2543e268d7796923b8fea5058532383c#diff-79da17e0a69d08b15e67940ac762f160
So if I did everything correctly, you should be able to use the latest on the master branch from this signalr repo and the Referer header should be set properly.
Thanks again for the feedback. I really appreciate it.


[SSR]: Different vite version builds produce different outputs, is this a bug?

Describe the bug
The latest vite version, the output of the pnpm build, has the assets directory under the dist/node directory, while in vite 3.0.3, there is no assets directory under the dist/node directory. Is this a bug?
vite: 3.0.3

vite: latest

Reproduction
https://github.com/kimmy214/vite-ssr.git
Steps to reproduce
No response
System Info
System:
    OS: macOS 13.0
    CPU: (6) x64 Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
    Memory: 30.10 GB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 14.19.1 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 6.14.2 - /usr/local/bin/npm
    Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
  Browsers:
    Chrome: 107.0.5304.62
    Safari: 16.1

Used Package Manager
pnpm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I guess this is not a bug and #9401 changed the output.


Bump version to 15.0.1

Version 15.0.0 broke building the example pages, and @tombye's pull
request (#214) fixed the problem but didn't bump the version.
So this fixes everything.

this fixes everything

A bold claim indeed.
:+1: for ambition.

http://www.enotes.com/homework-help/what-macbeths-tragic-flaw-how-does-lead-his-doom-86737

Macbeth's fatal flaw in the play is unchecked ambition


Decompose runner.Runner

runner.Runner was unwieldy and hard to implement/understand/use. Break it down.
This implements the API from https://github.com/scootdev/scoot/pull/167 (and fixes all references to new names)
Names that could be better:
Statuses
ServiceFacade

Current coverage is 62.83% (diff: 63.92%)

Merging #178 into master will decrease coverage by 1.35%

@@             master       #178   diff @@
==========================================
  Files            58         65     +7
  Lines          2843       2887    +44
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           1825       1814    -11
- Misses          895        955    +60
+ Partials        123        118     -5

Powered by Codecov. Last update 52929d8...52c00ef


SameSite cookie support

Fixes #3044.
Please suggest where I should add additional test cases.
According to the web.dev article linked in the issue:

SameSite=Lax by default
Must not set SameSite=None without Secure flag

I've fixed the stack-overflow problem -- it was caused by infinite recursion in a render method.
The Scala 2.13 job is still failing though, albeit in an inconsistent manner.  It passed for the build that fixed the recursion problem but failed for the subsequent commits, which were only formatting changes.

Test failure is the standard irritating flake, so I restarted.


Display public usernames in search if full_name is private.

Coverage remained the same at 89.81% when pulling 79c8545a4ea08f1367ae61a4bef054ca8e46cceb on akatsoulas:search-display-usernames into 77726323ffb74488561b7c2d8bf0af6fedef3e8e on mozilla:master.

Coverage increased (+1.7%) to 91.505% when pulling 79c8545a4ea08f1367ae61a4bef054ca8e46cceb on akatsoulas:search-display-usernames into 77726323ffb74488561b7c2d8bf0af6fedef3e8e on mozilla:master.


Document exactly when UnknownStream will be returned

It would be nice to know exactly when UnknownStream will be returned.

I am wondering if I can rely on UnknownStream being returned, or if it always indicates a bug in the caller.  There are other similar cases, such as calling Connection::write or Connection::finish on a closed connection.
I can, of course, keep track of this state explicitly, but it feels wrong to do so if it is not required.

You are free to rely on the documented behavior; that is why it's documented. You should consider structuring your application such that you're not holding onto references to resources that you were already notified have been destroyed, though.

I am writing a library (libp2p-quic) that wraps quinn-proto.  If UnknownStream is returned, that indicates a bug in the caller, so I log it at error level.  Thank you.


Why the results are different for make_evaluation_prediction and predictor.predict

For example,
Training dataset: 2020-01-01 ~ 2020-01-25
Testing dataset: 2020-01-01 ~ 2020-01-31
after trained a DeepAR model with training dataset,
predictor = model.train(train_set)
the forecast of evaluation for 2020-01-25 ~ 2020-01-31 is,
forecast_it, ts_it = make_evaluation_predictions(
dataset=test_set,
predictor=predictor,
num_samples=num_samples
)
As my think, there is another way to evaluate will get the same result:
forecast_it = predictor.predict(train_set)
However, I got two results with big gap, therefore I'd like to know is there any difference between "make_evaluation_predictions" and "predictor.predict"?
Thanks in advance.

That should give the same forecasts if your train set is the same as the test set except that the the last prediction_length time points have been removed from each time series -- this is what make_evaluation_prediction does before the forecast is generated. Can you maybe double check this?

That should give the same forecasts if your train set is the same as the test set except that the the last prediction_length time points have been removed from each time series -- this is what make_evaluation_prediction does before the forecast is generated. Can you maybe double check this?


Design UI for Homepage

Reference : Home

yess!

Can I work on it?

Okay I will assign it to you


Zeneth usage? Access?

Zeneth a gasless way of transacting is mentioned here:
https://github.com/flashbots/flashbots-docs/blob/main/docs/community-tools.mdx
Is it still used? Can't seem to access the site easily (hsts site/link)?

Zeneth no longer relevant.
@bertmiller we can close this issue


⚠ Spryr has degraded performance

In 760e950, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 4454 ms

Resolved: Spryr performance has improved in e19f959 after 8 minutes.


[Comment if interested] Grib message to GeoJSON

Or just JSON

JSON then GeoJSON.

Interested!

This issue was moved to GribApiDotNet/GribApi.NET#12


No such module: 'RealmSwift' (CocoaPods 1.2.0, Xcode 8.3.2, Realm 2.7.0)

Goals
Install Realm through CocoaPods
Expected Results
Much like other successfully installed Pods (AlamoFire, SwiftyJSON, HDAugmentedReality) it to install without issue
Actual Results
Build Failed - No such module: 'RealmSwift'
Steps to Reproduce
I have tried this on both existing projects as well as on a new project.
Code Sample
import UIKit
import RealmSwift

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

}

Version of Realm and Tooling
ProductName:	Mac OS X
ProductVersion:	10.12.4
BuildVersion:	16E195

/Applications/Xcode.app/Contents/Developer
Xcode 8.3.2
Build version 8E2002

/usr/local/bin/pod
1.2.0
Realm (2.7.0)
Realm (~> 2.7)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)

(not in use here)

/usr/bin/git
git version 2.11.0 (Apple Git-81)

<!---

## Goals
Install Realm through CocoaPods

## Expected Results
Much like other successfully installed Pods (AlamoFire, SwiftyJSON, HDAugmentedReality) it to install without issue

## Actual Results
Build Failed - No such module: 'RealmSwift'

## Steps to Reproduce
I have tried this on both existing projects as well as on a new project.

## Code Sample
`import UIKit
import RealmSwift

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

}`

## Version of Realm and Tooling
```
ProductName:	Mac OS X
ProductVersion:	10.12.4
BuildVersion:	16E195

/Applications/Xcode.app/Contents/Developer
Xcode 8.3.2
Build version 8E2002

/usr/local/bin/pod
1.2.0
Realm (2.7.0)
Realm (~> 2.7)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)

(not in use here)

/usr/bin/git
git version 2.11.0 (Apple Git-81)
```

Did you problem also go away after you did a build?

It didn't. I had to do a fully manual install in order to get Realm installed.

Yep getting this as well when installing via cocoapods. No such module: 'RealmSwift'. Quite frustrating.

@aamck I had to install it using the following instructions.  My project is early days and I'm trying out various alternatives to CoreData so between this and the warnings spam from issue https://github.com/realm/realm-cocoa/issues/4973 I might pass on it for now & try something else. Thanks for the response though.

@aamck It was a big ol' pain in the arse indeed. Now that it is working though, I have found it to be absolutely brilliant. Especially with the Realm Browser (though finding the .realm file was an absolute nightmare, and required me to install https://github.com/luosheng/OpenSim which worked like a charm.

I'm sorry about the difficulty you had installing Realm via CocoaPods. Would you be willing to share your podfile, or at least the declaration you used to add Realm Swift to your podfile?

platform :ios, '10.0'

target 'App' do
  use_frameworks!
  pod 'RealmSwift'

end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['SWIFT_VERSION'] = '3.0'
    end
  end
end

A few notes in the future to check if you do run into build issues again:

Make sure you're using supported tools & versions, and to follow the installation instructions. As of this writing:

Install CocoaPods 0.39.0 or later.

Run pod repo update to make CocoaPods aware of the latest available Realm versions.

In your Podfile, add use_frameworks! and pod 'RealmSwift' to your main and test targets.

Paste the following at the bottom of your Podfile, updating the Swift version if necessary:
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['SWIFT_VERSION'] = '3.0'
    end
  end
end

From the command line, run pod install.

Use the .xcworkspace file generated by CocoaPods to work on your project!

If you're still running into issues building/installing with CocoaPods, please share the full unabridged output of these commands:
pod --version
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate || rm -rf Pods
pod install --verbose
rm -rf ~/Library/Developer/Xcode/DerivedData

After running those commands, please attempt to build your project.

From my reading of this thread, it appears that everyone sorted this out eventually, so I'll now be closing this. Please feel free to re-open if following the instructions I shared above doesn't resolve the issues you're seeing, or file a new issue. Thanks!

@garethallenstringer I realised that I was trying to import RealmSwift into a class that was targeted to iOS and a watchOS extension. When I removed the watch extension target then did a clean & build the error went away.

Running the pod install script works, but it's setting the Swift Version to 3.0. Is RealmSwift not available for Swift 4? When I update to Swift 4 with Xcode 9, I get the same error. Not sure, if this should be a new issue, since it only pertains to updated versions of Swift & Xcode 9.

@michaelcordero I'd suggest that maybe this ought to be a separate issue, as it pertains to Swift 4 and my issue does not.

Hello @michaelcordero ,
Open this link: https://realm.io/docs/swift/latest/ and download. Add the swift 4 folder framework files to your xcode 9 and add them in your project in build link. It works.

Please don't comment on closed issues like this. Thanks.


Verification tests

Casper,
Please find attached the toml, lua and mesh files (.msh, .geo) I used for the tests I did. For testing i used the static executable.
./app/static cosine.toml --output testA

Verifying the result can be done by opening the generated vtu file and plotting the values for mu.
I note that you have defined the region index as a float. Hence in the Lua files I use floor() to map the floats to the current region (integer) index. This is not ideal. It would be better to just have an integer coming into the Lua callback.
Archive_2.zip
I found a mistake in the mesh definition I used with the previous zip file. Please use the -diri.{geo, msh} files.

It is great to parse all the physical tags. Nice one!
However, I would strongly caution against parsing and exposing the the elementary tag from GMSH (etag).
The reason for this is that the elementary tags are not unique. These numbers are autogenerated by GMSH are essentially a function of the order you create objects in the input file. For instance, if you edit the .geo file these numbers can and often do change when you re-load the .geo file. There the elementary tag generation may not even be consistent across GMSH versions, e.g. the same .geo file run through different GMSH versions can result in different values for the elementary tags. Hence, defining the behavior of a physical model in tandem (e,g. boundary condition specification, material properties) using elementary tags is super fragile, error prone and not very portable (or reproducible).
Given this issue, I would suggest not to expose the elementary tags to the end user.

@dmay23 -- Thanks for having a look Dave!
My understanding was that the physical tags correspond to physical objects declared in the GMSH .geo file, whereas elementary tags correspond to the geometrical primitives that constitute the physical objects. So e.g. in the example .geo file excerpt
Curve Loop(1) = {1, 2, 3, 4};
Plane Surface(2) = {1};
Physical Surface(3) = {2};

2 would be the elementary tag and 3 would be the physical tag of the elements in the mesh. This seems to be the case when looking at some generated .msh files by eye, and is also the explanation given in the GMSH documentation (https://gmsh.info/doc/texinfo/gmsh.html, search for 'elementary'). That being said, it is nowhere affirmed that this principle is guaranteed, and you might be right.
My idea was to reserve the physical tags for distinguishing sets of equations to be solved, as in the case of boundary conditions, and use the remaining elementary tags to define groups with different material properties, be that on the boundary or in the domain. Because the elementary tags would be incredibly useful given that on the boundaries the physical tags are already reserved, it would be a shame to toss this functionality. Are you 100% sure that the elementary tags are unreliable?

@dmay23 -- Thanks for having a look Dave!
My understanding was that the physical tags correspond to physical objects declared in the GMSH .geo file, whereas elementary tags correspond to the geometrical primitives that constitute the physical objects. So e.g. in the example .geo file excerpt
Curve Loop(1) = {1, 2, 3, 4};
Plane Surface(2) = {1};
Physical Surface(3) = {2};

Yes and no. The elementary tags are identifiers for any geometric primitive, but the tag value does not impart any info about the type of the geometric primitive. The elementary tags indicate a unique identifier for given class / type of geometric primitive. For example, you can have an elementary tag for a point with the label 0, and an elementary tag for a line with a label 0. But you cannot have two points assigned the same elementary tag of 0.

2 would be the elementary tag and 3 would be the physical tag of the elements in the mesh. This seems to be the case when looking at some generated .msh files by eye, and is also the explanation given in the GMSH documentation (https://gmsh.info/doc/texinfo/gmsh.html, search for 'elementary'). That being said, it is nowhere affirmed that this principle is guaranteed, and you might be right.

When building simple geometries, elementary tags are assigned by the user. However in more complicated (and relevant to building models with faults) the elementary tags are not explicitly assigned by the user. For instance, suppose you build two surfaces which intersect. To build a mesh which conforms to these two interfaces, you would call BooleanFragments(). This method takes your two surfaces, and determines the intersection between them and returns an array of objects defining new surfaces, new lines and new points associated with the intersection. These returned objects are not assigned elementary tags by the user, they are assigned by GMSH. In fact, the user doesn't usually even care what such tags are - rather for a tandem/seissol model you would simply collect all the returned surfaces and assign them an appropriate physical tag to identify them as a fault.
Whenever you use methods such as BooleanFragments() (or even Box() for that matter), geometric primitives are created and GMSH assigns unique elementary tags. To figure out what these elementary tags are, you have to inspect the geometry in the GMSH GUI and then configure the GUI to display the elementary tags.
So is not only tedious, but worse over, the e-tags auto generated are dependent on the order your geometry is defined.

My idea was to reserve the physical tags for distinguishing sets of equations to be solved, as in the case of boundary conditions, and use the remaining elementary tags to define groups with different material properties, be that on the boundary or in the domain. Because the elementary tags would be incredibly useful given that on the boundaries the physical tags are already reserved, it would be a shame to toss this functionality. Are you 100% sure that the elementary tags are unreliable?

Yes.
I can agree that exposing the elementary tags could be quite convenient for an advanced user (or when ones needs to do some hack test or build some very special/unique model), but I don't believe it is good that the Lua files depend on them by default.
If you expose both elementary tags and physical tags in the Lua file you seemingly would also need a way to indicate whether the specification of model boundary conditions (for example) is to made using e-tags or physical tags.
It's probably easier to work through specific use cases to see what works best.
As an example, take a case of one fault where you want to use R&S but you want some over stressed patch in some region and possibly different R&S parameters in different sections.
Lets assume R&S requires at each point a value for "a", "b", and normal stress \sigma_n
Assume the 1D profile along the fault looks like this
 |----- segment 1 ----------| ------ segment 2 ------------ | ------ segment 3 -------- |

In segment 1 we want

a = a_A
b = b_A
\sigma_n = f_A(x,y)

In segment 2 we want

a = a_A                                 # same as segment 1
b = b_A                                 # same as segment 1
\sigma_n = f_A(x,y) + 100

In segment 3 we want

a = a_A                                # same as segment 1
b = b_B
\sigma_n = f_B(x,y)

The above could readily be defined with three unique physical tags, and a mechanism to define parameters (or methods dependent on space) region-wise for each segment 1, 2, 3 based on the specific physical tag the user selected when defining the .geo file.

Hi @cpranger did you have comments reviewing this PR? Is it still open for a reason? Thanks!


disable running rhel os in azure cloud provider

What this PR does / why we need it:
Disable running rhel e2e tests for azure.
None

Disable running rhel e2e tests for azure.

Why?

Disable running rhel e2e tests for azure.

Why?

Because running rhel for one cloud providers is our requirement for now

/approve
/lgtm


BadSMSCode error when linking ASF MobileAuthenticator

I've been unable to link any new ASF Mobile authenticators to any of my accounts for the past day. The issue started happening after the recent steam changes with the removal of the checkboxes for email confirmations for trades/market transactions. I've tested multiple times with multiple steam accounts and phone numbers and always get BadSMSCode. Even after manually linking my phone number to the account through the steam client, I still still get BadSMSCode error when trying to link ASF authenticator.

1/22/2016 8:42:38 AM [] NOTICE: CheckForUpdate() <> Local version: <IP_ADDRESS>
1/22/2016 8:42:38 AM [] NOTICE: CheckForUpdate() <> Remote version: <IP_ADDRESS>
1/22/2016 8:42:38 AM [] NOTICE: CheckForUpdate() <> You're currently using pre-release version!
1/22/2016 8:42:38 AM [] NOTICE: CheckForUpdate() <> Be careful!
1/22/2016 8:42:40 AM [] INFO: Start() <Bot 19> Starting...
1/22/2016 8:42:46 AM [] INFO: OnConnected() <Bot 19> Connected to Steam!
1/22/2016 8:42:47 AM [] INFO: OnLoggedOn() <Bot 19> Successfully logged on!
1/22/2016 8:42:47 AM [] NOTICE: LinkMobileAuthenticator() <Bot 19> Linking new ASF MobileAuthenticator...
1/22/2016 8:43:20 AM [!!] ERROR: LinkMobileAuthenticator() <Bot 19> Unhandled situation: BadSMSCode
1/22/2016 8:43:21 AM [] INFO: Init() <Bot 19> Logging in to ISteamUserAuth...
1/22/2016 8:43:22 AM [] INFO: Init() <Bot 19> Success!
1/22/2016 8:43:30 AM [] INFO: IsAnythingToFarm() <Bot 19> Checking badges...
1/22/2016 8:43:30 AM [] INFO: IsAnythingToFarm() <Bot 19> Checking first page...
1/22/2016 8:43:32 AM [] INFO: IsAnythingToFarm() <Bot 19> Checking other pages...
1/22/2016 8:43:32 AM [] INFO: IsAnythingToFarm() <Bot 19> Checking hours...
1/22/2016 8:43:34 AM [] INFO: StartFarming() <Bot 19> We have a total of 1 games to farm on this account, farming in progress...
1/22/2016 8:43:34 AM [] INFO: StartFarming() <Bot 19> Chosen farming algorithm: Complex
1/22/2016 8:43:34 AM [] INFO: FarmMultiple() <Bot 19> Now farming: 252150
1/22/2016 8:43:34 AM [] INFO: Farm() <Bot 19> Still farming: 252150

It's very likely that Valve changed something regarding this, as other projects that are using SteamAuth are experiencing similar issues: https://github.com/Jessecar96/SteamDesktopAuthenticator/issues/193
No solution yet.

This is supposed to be resolved by now, Volvo pls?

This is now fixed for good in https://github.com/JustArchi/ArchiSteamFarm/commit/7ae29aa1228793ba5058c701b9dfdfc92764b927


App crash after add com.facebook.fresco:fresco:1.5.0

Hi Wysaid, I added com.facebook.fresco:fresco:1.5.0 in your sample then app crash and I got "Could not find ffmpeg.so"
https://github.com/facebook/fresco

Maybe fresco uses other archs, you can just add all archs of the JNI module  in your code.

Thank you. It's working.


./SocialFish user password !! how can I fix it ??

python3 SocialFish.py youruser yourpassword

View

View https://github.com/UndeadSec/SocialFish/issues/129

type python3 SocialFish..py root toor


update links

Updated links from AdoptOpenJDK to adoptium in README

Thanks @totorororo

Looks good, will merge once checks complete!


Inquiry about behaviour when refreshMetadata is called with empty argument

Description
Hi!
Not sure if there is a better place to ask these questions. I’m wondering if someone can help me better understand the code path when refreshMetadata is called with an empty list of topics and conf.Metadata.Full is set to true. Upon code reading, it seems Sarama just forwards a request with empty topics to broker https://github.com/IBM/sarama/blob/228c94e423f068fa75293e12f68cb6cf249d38d3/client.go#L1034 without populating or fetching topics. I'm curious about the underlying mechanism.
Does the broker identify topics created on the server and fetch metadata accordingly? My confusion arises because I expected (refreshMetadata() with empty topics & metadata.full == true) to work roughly in a similar way as (refreshMetadata() with specific topics & metadata.full == false) but I got an error about  an invalid replication factor in Kafka servers when using the latter. After some research, this seems to imply that the number of brokers is too small on the kafka server side. My guess is that even when metadata.full is set to true, kafka never really refreshed the metadata for all topics for a cluster that had just started - possibly because the kafka topics haven’t been created at that point? Any insights into this issue would be appreciated.
Versions

Sarama
Kafka
Go

<EMAIL_ADDRESS>

Configuration

config := sarama.NewConfig()
config.Producer.Return.Successes = true
config.Producer.Partitioner = newChangefeedPartitioner
config.Metadata.Full = false

Logs

logs: CLICK ME

I231213 18:34:52.883283 12346 github.com/Shopify/sarama/sarama.go:132 ⋮ [kafka-producer] 376  ‹Initializing new client›
I231213 18:34:52.883365 12346 github.com/Shopify/sarama/sarama.go:132 ⋮ [kafka-producer] 377  ‹Successfully initialized new client›
I231213 18:34:52.883392 12346 github.com/Shopify/sarama/sarama.go:129 ⋮ [kafka-producer] 378  client/metadata fetching metadata for [‹auth_test_table›] from broker ‹<IP_ADDRESS>:9093›
I231213 18:34:52.883747 12359 github.com/Shopify/sarama/sarama.go:129 ⋮ [kafka-producer] 379  Connected to broker at ‹<IP_ADDRESS>:9093› (unregistered)
I231213 18:34:52.976467 12346 github.com/Shopify/sarama/client.go:1103 ⋮ [kafka-producer] 380  Unexpected topic-level metadata error: ‹kafka server: Replication-factor is invalid›
I231213 18:34:52.976584 12346 github.com/Shopify/sarama/sarama.go:132 ⋮ [kafka-producer] 381  ‹Closing Client›
I231213 18:34:52.976803 12372 github.com/Shopify/sarama/sarama.go:129 ⋮ [kafka-producer] 382  Closed connection to broker ‹<IP_ADDRESS>:9093›

@wenyihu6 I replied in the cockroachdb issue, but copying here too

When calling refreshMetadata(sink.Topics()) instead of an empty argument, sarama returns pq: kafka server: Replication-factor is invalid for kafka-auth roachtest.

The difference here is that by refreshing metadata with an explicit set of topics, you go into the Kafka code path that permits automatic topic creation (which is disabled when you've done Metadata.Full and passed an empty topic list)
https://github.com/IBM/sarama/blob/5f63a84f47c39bf08a1c276f1f6b5f1d754e9fc3/client.go#L1022-L1028
The fact that you're getting 'Replication-factor is invalid' in that scenario suggests that the number of running/active brokers you have in the Kafka cluster is fewer than the default replication factor, so Kafka is returning INVALID_REPLICATION_FACTOR to Sarama because it doesn't have enough active brokers to satisfy the create request

Closing. Thanks again for helping me understand here!
(For posterity interested in this discussion, we discussed more in https://github.com/cockroachdb/cockroach/issues/116872.)


CPUPROFILE_FREQUENCY=1 causes timer_settime() to fail with EINVAL

Because timer_settime() does not like tv_nsec greater than 999999999
Arguably this is not even a bug, but it is an unfriendly failure mode.

Thanks for the report. Care to propose a patch with a fix ? (and maybe even a test)


Wallet

Wallet not syncing

Wallet in wallet mode never start syncing and can not get node for wallet

Same problem. The wallet is not syncing. What to do?

I partially solved the problem. I replaced the payout address for the farm with the address of the exchange wallet and everything worked out. The coin is farmed and goes to the exchange wallet. I don’t know how 7/8 will behave later, but as a temporary solution, this is the norm. Here is the address of the exchange where I did it: https://www.chiafork.cc

Dear developers and programmers, what will we do with a non-working wallet?

???

?????

Dear developers and programmers, what will we do with a non-working wallet???

How to synchronize wallet???!!!

@advlive
@SGABR
@bagyra
i'm trying this:

now i change number of target wallet
but i think is a certificate's issue, infact server refuse "self connections" on <IP_ADDRESS>,
maybe i'll try to headless_fullnode and UI certificates on remote host (in local lan)
it almost seems like a commercial gimmick: if I don't have a wallet, I can't sell :)))))

found anomalies on rpc wallet ttry to change from 6236 (managment port DL) to 6062 (rpc i think it's right)

works fine, but can't connect the wallet to node <IP_ADDRESS>

still persist acknowledgemt with c.a., but if you can run peer -a <IP_ADDRESS>, the wallet is like an external an works.... i think that this fork is near to....... (mens agitat molem) look!!!!


How to Send MIME messages with SendGrid

Explain how MIME messages can be sent, in more detail, using SendGrid. Explain that this can only be done over SMTP.
The doc should go here:
for-developers/sending-email/__________/

@ksigler7 Can you suggest how can i proceed with this issue.


declared-license-mapping: Add LGPL-2.1 mapping

Found "GNU Lesser General Public License v2 (LGPLv2)" in 1.
Signed-off-by: Thomas Steenbergen<EMAIL_ADDRESS>

Closing this in favor of the approach discussed in the community meeting on 2022-11-24.


[Llama3] Debug accuracy drop on sequence lengths > 64k tokens

Status:
Prefill seqlen up to 128k supported in Llama3 codebase (1b, 3B, 8B, 11B, 70B), but bad accuracy in some corner cases:

✅  All models show good output for prefill seqlen up to 32K tokens.
❌  All models showing bad (repetitive) output for 128K tokens.
✅  With top-p sampling, prefill up to 64K is good in most models.

❌ Exception 1B/3B

Things we've tried so far:

TODO

This is now supported in main.
Added a P2 followup for small Llama models here: https://github.com/tenstorrent/tt-metal/issues/15737


[Video] Plugin does not display ads if started in fullscreen

When video content playback starts in fullscreen, the plugin does not properly initialize IMA SDK and ads are not displayed.
[---Steps to Reproduce---]

Access the Plugin test page: https://codepen.io/imasdk/pen/wpyQXP
Right-click on video player and select "Show Controls"
Put the video in full screen
Click on the video to trigger playback

Hello @vhbramos ,
After some experimenting, the following code captures the fullscreen event from the "Show Controls" option:
document.addEventListener('webkitfullscreenchange', () => {
    // response to event.
});

However, what is interesting, is this does not trigger the videoJS fullscreenchange event. If it did trigger the event, then things should work as expected. Without that event being triggered, it becomes somewhat messy to manage the fullscreen state for IMA. I would recommend raising an issue in the video.js issues queue to better understand how it can be supported on their end.
In the current state, I do not think we can support this functionality in this plugin.
Let me know if you have any additional questions.
Thank you,
Jackson
IMA SDK team


[BUG]

What happened?
-Hello. I seem to have a heck of a lot of console spam when I start the server up or when shutting down, which makes the server take 2 to 5 times as long to start up/shut down.
What should happen?
Steps to reproduce

start the server up :D

Version
-dcintegration-1.1.18-1.12
Mod version 0.0.0
Config file
-https://bytebin.lucko.me/ejE9YkPtA9
*
Crash report if available (use https://paste.dimdev.org)
-https://gyazo.com/638e22de6ab784c2fedf80e44920bd4c
Additional info

Disable B:MODIFY_CHANNEL_DESCRIPTRION=true
See #70 for more information


Rendered kubeconfig.yaml uses wrong server value

The kubeconfig.yaml cluster server value is hardcoded to https://<IP_ADDRESS>:6443 and I see a TODO comment. Adding this issue to track the fix. For now, I'll comment that users should edit the config manually.
https://github.com/coreos/bootkube/blob/master/pkg/asset/k8s.go#L51

fixed in https://github.com/coreos/bootkube/pull/22


Add shorthand for focusing and skipping tests

Below is an example of a test created with a string and function. If you're not making use of other TestDefinition options, it is easier to write the test like this and the function's body will have less indentation.
test("example", () => {
  assert(true);
});

Currently if you want to focus or skip the test, you have to rewrite it to use a TestDefinition.
test({
  name: "example",
  only: true,
  fn() {
    assert(true);
  },
});

I'd like this module to provide shorthands to enable focusing or skipping tests without modifying the call signature.
The first option I thought of is adding functions onto the test function.
test.only("example 1", () => {
  assert(true);
});
test.ignore("example 2", () => {
  assert(true);
});

Another option would be to export separate test functions. The downside to this way is that it would require importing the functions.
testOnly("example 1", () => {
  assert(true);
});
testIgnore("example 2", () => {
  assert(true);
});

Decided on a different change.
https://github.com/udibo/test_suite/issues/13


Fix partition selection issue that causes incorrect creation of pools

I'm not sure this is still an issue and I did a pretty poor job of documenting the bug.
The original problem was we would occasionally see SLB/ADC elements being created in incorrect partition.  If I recall correctly, we discovered it had something to do with the shared partition and having 2 requests sent to create elements on different partitions recreated the problem.  This was 3 months ago and unfortunately I didn't attach more context.


toolchain: mwdt: add some compile options to reduce warning

When compile zephyr project with arcmwdt toolchain, there are some harmless but noisy compiling warnings,
add some compile options:
-Wno-typedef-redefinition
-Wno-duplicate-decl-specifier
-Wno-incompatible-pointer-types
to reduce warning.
warning: duplicate 'inline' declaration specifier [-Wduplicate-decl-specifier]
warning: redefinition of typedef 'k_tid_t' is a C11 feature [-Wtypedef-redefinition]
......

Hmm, any clue about why do we need '-Wno-incompatible-pointer-types'?

BTW, your commit doesn't touch '-Wno-incompatible-pointer-types' at all.

Hmm, any clue about why do we need '-Wno-incompatible-pointer-types'?

It might be fixed by some code changes in latest commits, I can't reproduce it, so I remove it.

Now when there's only 1 warning being muted we may explicitly mention in in the commit title.
Also it would be really useful to have an explanation of why that redefinition happens and maybe even insert an extract from real code which requires that treatment.

The redefinition is caused by this PR : userspace: memory domain cleanups & arch-specific data support:
1 warning generated.
[106/114] Building C object zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj
In file included from zephyr/kernel/idle.c:7:
../include\kernel.h:648:26: warning: redefinition of typedef 'k_tid_t' is a C11 feature [-Wtypedef-redefinition]
typedef struct k_thread *k_tid_t;
                         ^
../include\app_memory/mem_domain.h:18:26: note: previous definition is here
typedef struct k_thread *k_tid_t;

https://github.com/zephyrproject-rtos/zephyr/blob/04fe7c6eeb7880d2a41d1d9d8e17a3d7d427c9ed/include/kernel.h#L648
https://github.com/zephyrproject-rtos/zephyr/blob/04fe7c6eeb7880d2a41d1d9d8e17a3d7d427c9ed/include/app_memory/mem_domain.h#L18
kernel.h include kernel_includes.h:
https://github.com/zephyrproject-rtos/zephyr/blob/04fe7c6eeb7880d2a41d1d9d8e17a3d7d427c9ed/include/kernel.h#L17
kernel_includes.h include mem_domain.h:
https://github.com/zephyrproject-rtos/zephyr/blob/04fe7c6eeb7880d2a41d1d9d8e17a3d7d427c9ed/include/kernel_includes.h#L45
Maybe we need to do some changes in codes, but it's interesting why only mwdt toolchain will treat this as redefinition warning.

@andrewboie could you comment here ^^^

Is it possible that it is the same issue?
https://patchwork.kernel.org/patch/10920427/

@andrewboie could you comment here ^^^

I needed k_tid_t for that header, without pulling in the entire kernel.h to avoid circular deps. GCC was fine with this (probably because the definition is unchanged), but it seems MWDT is not.
Probably the best solution is to create a thread.h header with all the thread definitions and have both kernel.h and mem_domain.h include it

@andrewboie, thanks for explanation. It's most likely not MWDT thing but CLANG thing (MWDT is CLANG based) given that link about '-Wno-typedef-redefinition' adding in Linux kernel for CLANG.
@IRISZZW could you please update the commit message? Otherwise ACK.

@abrodkin could you review this again?

attempt to fix this proper was submitted here: https://github.com/zephyrproject-rtos/zephyr/pull/29359


feat(ap engine): 支付宝小程序httpRequest 升级

支付宝端旧接口 my.httpRequest 将被废弃，请使用my.request
来代替。钉钉端目前尚未支持my.request，请继续使用 my.httpRequest。
Closes #213

Codecov Report

Merging #220 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #220   +/-   ##
======================================
  Coverage    86.1%   86.1%
======================================
  Files           1       1
  Lines         259     259
======================================
  Hits          223     223
  Misses         36      36

Continue to review full report at Codecov.

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

麻烦有空了尽快升下呀，要发版本啦


Line is not drawn as requested, changing value and endValue meaning

When you configure a line annotation, with value and endValue, the line is always going down (on horizontal line) even if the endValue is greater than the value.
The issue is here:
https://github.com/chartjs/chartjs-plugin-annotation/blob/97616ce85e99e32ae2636cfbd57679fe276a0803/src/annotation.js#L131-L137
because you always set X (or Y) with Math.min and X2 (and Y2) with Math.max.
Instead, these values don't have to be changed by Math.min and Math.max but set as they are:
if (scale.isHorizontal()) {
	x = min;
	x2 = max;
} else {
	y = min;
	y2 = max;
}

I'm using the master. I'm gonna submit a PR if agreed.

Fixed by #248


Monthly payment worksheet: calculations

Adds monthly payment calculations
Additions

Add monthly payment calculations file
Add basic tests for calculations

Testing

Run grunt test to see results of initial tests for calculations module

Review

@cfarm
@mthibos

Notes

The calculations currently call each other where necessary, so they don't depend on previous calculations having been run to produce the data that is passed in to them.

This PR contains the basic logic for the calculations. Formatting values/ensuring numerical values may follow in future PR.

@mthibos Do we want to round these calculations? Or keep decimals, if a user enters them?

Checklist

[X] Changes are limited to a single goal (no scope creep)
[X] Code can be automatically merged (no conflicts)
[X] Code follows the standards laid out in the front end playbook
[X] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

Pinging @contolini because I bet Cat is already on the road.

I'll review this today.
On Tuesday, October 13, 2015, Stephanie Osan<EMAIL_ADDRESS>wrote:

Pinging @contolini https://github.com/contolini because I bet Cat is
already on the road.
—
Reply to this email directly or view it on GitHub
https://github.com/cfpb/owning-a-home/pull/640#issuecomment-147815331.

--
Chris

Aside from my minor nitpicking above, this looks :+1: to me.

@contolini Ok, I removed that line from the insurance calculation.


Voice Packet Malformed

Voice encoding does not properly format outgoing voice packets. MumbleConnection.cs:
public void SendVoice(ArraySegment<byte> packet)
{
    _tcp.Send(PacketType.UDPTunnel, packet);
}

This simply sends the encoded data.... but makes no effort to build the correct format of packet around the encoded data!

I am going to start looking into this issue but it certainly seems like the packet needs to be properly formatted based on this specification [1].

Hi, looking at the code the BasicMumbleProtocol EncodingThread is forming the packet correctly. So I changed the warning comment in PR #47


Question/Bug? - Setting post excerpt

[x] This is a question about using the theme.
[x] I have updated all gems with bundle update.
[x] I believe this to be a bug with the theme --- not Jekyll, GitHub Pages or one of the bundled plugins.
[x] I have tested locally with bundle exec jekyll build.

Environment informations

**Minimal Mistakes version:4.1.0
**github-pages or jekyll gem version:3.3.1
**Operating system: macOS Sierra 10.12.2

Expected behavior

I wanted to set my own excerpt for posts instead an auto-generated one. Therefore, I added an excerpt value into my YAML front matter, but it doesn't work. The pages still use auto-generated one instead I added.
Steps to reproduce the behavior

I checked out the layout file, and find out excerpt is referenced in the includes/archive_single.html by the following code.
{% if post.excerpt %}
{{ post.excerpt | markdownify | strip_html | truncate: 160 }}
{% endif %}

I notice itemdrop='description' and post.excerpt are sourcing different content from the post. Therefore, I tried to change either of them to make them both source from description or excerpt. Then I can have my own excerpt rather than an auto-generated one.
For example
{% if post.excerpt %}
{{ post.description | markdownify | strip_html | truncate: 160 }}
{% endif %}

Is it an inconsistency bug or I understand it incorrectly? All files are in my GitHub repo.
Thanks for the help!

Strange. It appears to be working correctly on the demo site.
If you check out [this archive page](Layout: Excerpt (Defined)) and scroll down, the post titled "Layout: Excerpt (Defined)" has an excerpt that has been manually set.
The excerpt override was set just as you did with excerpt:  in the post's YAML Front Matter.
---
title: "Layout: Excerpt (Defined)"
excerpt: "This is a user-defined post excerpt. It should be displayed in place of the post content in archive-index pages."
categories:
  - Layout
  - Uncategorized
tags:
  - content
  - excerpt
  - layout
---

This is the post content. It should be displayed in place of the user-defined excerpt in archive-index pages.

This paragraph should be absent from an archive-index page where `post.excerpt` is shown.

Do you have a public repo somewhere and a link the source of the post that's not working? Not that it should matter but is it a post, a page, or a collection document?

Hi Michael, thanks for your reply!
I changed the archive-single.html to original and it works correctly this time.
I have no idea why it didn't work last night. Sorry for the trouble I made!
Thanks again for your help and this amazing theme.

I found the issue for me was that I was running bundle exec jekyll serve -i. When I changed it to bundle exec jekyll serve it worked.

Hello everyone,
I have a bug on my blog built on GitHub Minimal Mistakes.
Locally, when I run bundle exec jekyll serve, everything works well on localhost:4000 and the design is OK.
When I visit my blog online, I realised the design is not OK, and I don't know why. I need your help
Thanks in advance


RolesAnywhere Assume Capability

Add capability to assume via RolesAnywhere

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

Closed to create a cleaner branch after having identified the source of the telemetry issue.


vite devServer 404

Describe the bug

what is this interesting bug?   terminal says its running , but actually theres no resources on localhost:3000
Reproduction
https://github.com/yaohuangguan/moviegoer-react
this repo has the problem
System Info
System:
    OS: macOS 11.3.1
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
    Memory: 297.01 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 12.20.1 - /usr/local/opt/node@12/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.10 - /usr/local/opt/node@12/bin/npm
  Browsers:
    Chrome: 90.0.4430.93
    Firefox: 86.0
    Safari: 14.1

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

you should move the index.html out of src


Fix update options in diff

Issue #156 was fixed by PR #162, but only in editor.js. This change also propagates the fix to diff.js, which is currently still not able to update options.

Thanks

Would it be possible to merge this into NPM as v0.24.1? If not, what would the timeline roughly be for v0.25.0?

Sure, I'll do it when I get home.


encoding error

anaconda labelimg error
Version: 1.8.6
Summary: LabelImg is a graphical image annotation tool and label object bounding boxes in images
Home-page: https://github.com/tzutalin/labelImg
Author: TzuTa Lin
Author-email<EMAIL_ADDRESS>License: MIT license
Location: e:\software\anaconda\envs\pytorch\lib\site-packages
Requires: lxml, pyqt5
I open the dataset and it prompts me that the encoding is wrong:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 0: invalid start byte
Then I convert the classes.txt of the data to utf-8 format, it still reported an error:
UnicodeDecodeError: 'gbk' codec can't decode byte 0x8a in position 8: illegal multibyte sequence
When I was coding in gbk, I was prompted to convert it to utf-8, and after I switched it, I was prompted to convert gbk
After receiving it, I would like to ask if you have any other annotation tools to share, which support the yolov5 txt annotation format

Create a new conda environment.
pip install -r requirements.txt

I want to train YOLO to recognize the direction of objects. For that, I need to annotate prominent corners and the line connecting two annotated boxes will indicate the direction. It would be helpful if the corner is positioned at the center of the annotated box, and if a cross is displayed at the center of the box. Additionally, the annotated box needs to be of a fixed size.

For the annotated box to be of fixed size, the images need to be resized and it heavily depends on the quality of your dataset. For a cross you can use the Opencv library to drawmarker() at the center of bounding boxes and then you can center your corner around the cross.


Wrong link to stable release https://owncloud.org/install/

https://owncloud.org/install/ points to old 8.1.1 and not to the latest 8.1.2.

there is no 8.1.2 yet, that shouldn't be in the changelog either. We're still fixing something and finishing testing ;-)

@jospoortvliet Will 8.1.2 ever be released?

@enoch85 we'll skip it and release 8.1.3, hopefully today. Coming with a blog about the community VM and an explanation for the delay ;-)


Loosen rules for RegExp { } literals

Check the regex for valid quantifier, if none found, suppose it's a character literal.
If } is encountered outside of quantifier parsing, it is treated as a literal
This MR fixes #142 and partial for #74

Hmm, I might be reading the diff wrong but it seems that {x} would emit a matcher for x\} (not /\{x\}/, i.e. no "atom char" matcher is emitted for the left curly brace?

I don't think so. The error at line 1658 was replaced by the same code as in default: case, that is :
advtok = DUK__ADVTOK(1, DUK_RETOK_ATOM_CHAR);
out_token->num = x;

So the { is still added as a literal token, treated as a PatternCharacter.
I can add test for these if needed

duk> x = /{foo}/
= /{foo}/
duk> x.test('{foo}')
= false
duk> x.test('foo}')
= false
duk> x.test('ffoo}')
= true

Ok, so the index is handled correctly but the "bailout" clause shouldn't match the offending character but rather the left curly - and then resume parsing the rest.

A test case illustrating the new behavior (and its limitations if any) will definitely be needed - you can add one in this pull, or I can add one in master if this gets merged.
Another thing needed in master will be a compliance option to turn the behavior off. Again, you can add it in the pull or I can add it in master.

One limitation in the current approach is that if the quantifier looks like a number but turns out not to be, the regexp parse will fail with an "invalid quantifier" still so that the fix for #142 is partial, e.g.:
duk> x = /{1111111111111111111111111/
SyntaxError: invalid regexp quantifier (too many digits) (line 1)
	input:1
	duk_lexer.c:1619

This may be fixable in the pull. I don't think this will be a practical limitation though, so documenting it in a testcase would be good enough for now in my view.

Hmm - if I understand the new approach correctly, it postpones the DUK__ADVANCECHARS in the regexp quantifier parsing loop until we know whether it's a quantifier or something else, and DUK_LOOKUP(lex_ctx, index + N) lookups are used in the loop instead. However, the guaranteed window (DUK_LEXER_WINDOW_SIZE) is only 6 codepoints long so unless I'm mistaken the algorithm may overrun the window in some cases?
One simple fix for this would be to increase the window so it's always enough to scan valid quantifier expressions (~20 codepoints or so) but this has some performance impact.
Another alternative (which wouldn't need to change the window) would be to change the algorithm so that it snapshots the lexer position before the loop and then advances in the quantifier parsing loop as in master. When the quantifier turns out to be invalid, the lexer position can be rewound and we can resume parsing. Rewinding the lexer should have no side effects - it'd be more difficult if we needed to "unemit" bytecode but luckily that's not necessary here.

Yes, that was the idea. I agree the proposed change will make this code
better. I wasn't aware the lexer could be rewound.
For the too many digits, does a test suffice for you?
The bug is a copy/paste issue :-(. I should have paid more attention.
Finally, to disable the option, should I create a preprocessor option?
I'll setup a linux machine and add the tests and the fixes
Thanks for the comments
On Tue, Jan 5, 2016 at 1:02 PM, Sami Vaarala<EMAIL_ADDRESS>wrote:

Hmm - if I understand the new approach correctly, it postpones the
DUK__ADVANCECHARS in the regexp quantifier parsing loop until we know
whether it's a quantifier or something else, and DUK_LOOKUP(lex_ctx,
index + N) lookups are used in the loop instead. However, the guaranteed
window (DUK_LEXER_WINDOW_SIZE) is only 6 codepoints long so unless I'm
mistaken the algorithm may overrun the window in some cases?
One simple fix for this would be to increase the window so it's always
enough to scan valid quantifier expressions (~20 codepoints or so) but this
has some performance impact.
Another alternative (which wouldn't need to change the window) would be to
change the algorithm so that it snapshots the lexer position before the
loop and then advances in the quantifier parsing loop as in master. When
the quantifier turns out to be invalid, the lexer position can be rewound
and we can resume parsing. Rewinding the lexer should have no side effects

it'd be more difficult if we needed to "unemit" bytecode but luckily
that's not necessary here.

—
Reply to this email directly or view it on GitHub
https://github.com/svaarala/duktape/pull/513#issuecomment-168982216.

As a bit of background, I haven't added support for loose parsing of RegExps because there are a lot of individual issues, and most of the cases require actual backtracking (including bytecode backtracking). I'm also not very enthusiastic about "dead end partial fixes", i.e. changes which fix a subset of cases but can't be developed into fully working solutions -- one can easily get lost in improving the fixes step by step but never quite reaching a fully working end result. That's why the main plan for RegExps is to add support for (optionally) hooking up an external regexp engine which will perform better and will be able to support a lot of non-standard RegExps; these are very difficult to achieve in the built-in engine which is size and portability optimized.
Even so, this RegExp curly brace issue comes up pretty often, and because the change is potentially relatively simple, it'd be nice to merge this into the built-in minimal regexp engine.

As for the concrete questions / issues:
IMO it'd be OK to fail for now for e.g. /{1111111111/; the test case should illustrate this current limitation. I think this limitation should actually be fixable, and I can give it a go once the basic change is in master. The memory safety fix will be necessary before merging, of course.
As for the config option, I can handle that bit in master (if you prefer), but the change is basically:

Add a config metadata file, e.g. config/config-options/DUK_USE_NONSTD_REGEXP_BRACES.yaml, the option should be enabled by default. The YAML metadata is documented in config/config-options/DUK_USE_EXAMPLE.yaml but comparing to existing files is also useful.
Modify the changes in the lexer so that the new/old behavior are behind #if defined(DUK_USE_NONSTD_REGEXP_BRACES). Test both cases by modifying duk_config.h.

Once the remaining issues are resolved, I'll be happy to merge this pull, and I think a lot of users will appreciate it :-)

I addressed all the remarks you made. Looks cleaner. From here, it would be easy to convert any quantifier parsing failure to literal {, but I believe it will be hard to debug and understand what's going on in the regex.
Code compiles without warnings and pass the tests

This is what I use as a reference point:
https://regex101.com/
I tested this pull, works pretty well.  There are two issues I noticed:

If the regex starts with what would otherwise be a valid quantifier, e.g. /{2}/, Duktape throws an error "quantifier without preceding atom".  Regex101 also rejects this, so it almost certainly isn't an issue in practice.
/{2,,}/ is rejected with a "double comma in quantifier" error.  Regex101 accepts this as a literal match in all modes.

As all those issues are already managed as error, it would be pretty easy to make them work as well. That was the subject of my comment after the last commit.
Again, I believe we should chose wisely which one to (dis)allow, as it may be harder to debug strange behaviors for people not used to this discrepancy.

That's why I like regex101, it serves as a useful point of reference for real-world regex engine behavior.

Like @crazyjul said I think the remaining issues should be relatively easy to fix. I'm OK with either fixing them in separate pulls or working them out in this pull.

Ok, small vote here. Here is the list of error easily bypassed :

invalid regexp quantifier (too many digits)
invalid regexp quantifier (double comma)
invalid regexp quantifier (missing digits)
invalid regexp quantifier (missing digits)

Which one do you think should trigger literal brace?

Double comma:
This is a tough call.  Regex101 treats it as literal, but it might be more useful to keep it as a syntax error, like it is now.  It'd be easy to make a typo and add an extra comma, and it would be confusing to have your quantifier suddenly turn into a literal.  I vote to keep the error.
Too many digits:
Probably best to leave this alone too.  Ideally something like /a{11111111111111111111111111111111111}/ would trigger the error, but /a{11111111111111111111111111111111111maggie}/ would not (i.e. literal curlies).  But since it's probably not easy to differentiate between the two cases, I vote again to leave the error.
Missing digits:
I'm not sure what triggers "missing digits", this would have to be clarified.

In fact, the 'too many digits' is easy to change to get that behavior. Right now, it checks the digit count for each digit. Simply checking it at closure would be enough, any alien character would cancel the parsing.
For Missing digits, it triggers on {} and {,}.

I vote literal semantics for missing digits then.

Because this behavior is out-of-specification, it'd probably be quite useful to compare against e.g. V8. Even if the behavior was different, it's good to know where the differences lie.

node 4.2.2 has this behavior :
Missing digits leads to literal
No limits for digits

Some quick experiments in Node.js v5.3.0:
> /{}/.exec("a pig ate everyone at 8:12 {}")
[ '{}', index: 27, input: 'a pig ate everyone at 8:12 {}' ]
> /{1}/.exec("a pig ate everyone at 8:12 {1}")
SyntaxError: Invalid regular expression: /{1}/: Nothing to repeat
    at new RegExp (native)
    at repl:1:1
    at REPLServer.defaultEval (repl.js:252:27)
    at bound (domain.js:287:14)
    at REPLServer.runBound [as eval] (domain.js:300:12)
    at REPLServer.<anonymous> (repl.js:417:12)
    at emitOne (events.js:82:20)
    at REPLServer.emit (events.js:169:7)
    at REPLServer.Interface._onLine (readline.js:210:10)
    at REPLServer.Interface._line (readline.js:549:8)
> /a{}/.exec("a{}")
[ 'a{}', index: 0, input: 'a{}' ]
> /a{111111a}/.exec("a{111111a}")
[ 'a{111111a}', index: 0, input: 'a{111111a}' ]
> /{1,,}/.exec("{1,,}")
[ '{1,,}', index: 0, input: '{1,,}' ]

tl;dr: Curlies are literal unless they form a valid quantifier atom.

Here it is, I've implemented failure support as discussed here. A test is also attached to it.
To avoid code bloater with #ifdef #else #endI've created a macro that either report error or jump to literal brace code. I was not sure about the coding standard here, so comment if it needs to change

@crazyjul Great, thanks! :) I'll look into this pull once I've got 1.4.0 finished, probably weekend or early next week.
Just as a quick comment on the error macro: I think the error handling could be simplified so that the quantifier syntax errors would just share a single error message string ("invalid regexp quantifier") when the non-standard curly support is disabled. That would make it unnecessary to use an error macro and the goto target site could just throw the shared error if non-standard curly support is disabled. The original error message precision is somewhat of an overkill compared to error message verbosity in other places.
But in case the macro remains: there are no #defines inside functions now as a convention, but it's probably OK here as it's quite local. I'd like an #undef after the macro is no longer used. Finally, internal macros are always prefixed DUK__ (double underscore).

Stuff to clean up in master after this is merged:

RegExp limitations documentation on website and internal regexp documentation
Check if make emscriptentest and friends now work without a fixup step (there were other issues apart from RegExp syntax errors as well so might not work)

@crazyjul You might want to squash some of the commits.  The exception being the testcase(s), for which the convention from what I've seen is usually to commit them separately.

@fatcerberus Yeah, I've tried to keep code commits separate from other commits because it makes e.g. cherry picking easier. But it's not that important because one usually knows when committing something that will be cherry picked to a fix release later so that only that commit can go in separately. What I don't like too much is a bunch of fixup commits in the master :-)

Ok, I'll do it this afternoon
On Mon, Jan 11, 2016 at 11:54 AM, Sami Vaarala<EMAIL_ADDRESS>wrote:

@fatcerberus https://github.com/fatcerberus Yeah, I've tried to keep
code commits separate from other commits because it makes e.g. cherry
picking easier. But it's not that important because one usually knows when
committing something that will be cherry picked to a fix release later so
that only that commit can go in separately.

I've squashed all the commits to keep a single one.

@crazyjul I just noticed that you added your name to the wrong author list in AUTHORS.rst, could you please open a pull to add yourself to the first list in AUTHORS.rst (which is for code contributions)? Thanks! :)


[DUOS-1964][risk=no] Add DataAccessGovernance section to Data Submission Form

Addresses
https://broadworkbench.atlassian.net/browse/DUOS-1964

Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

@lu-c thank you for all the super helpful feedback!! i will look over this later today & incorporate it all. I agree on all your major points (esp. about preferring CSS). My plan is to migrate all of this over to FormField objects once your PR is merged in, which will I think clean up A LOT of what's not so great in my PR :)


PKG_DDL_UTIL can not find object "BC_PORTAL:INDEX:bcp_addresses_l1:::::::"

ORA-20114: Can not find object with key "BC_PORTAL:INDEX:bcp_addresses_l1:::::::"
ORA-06512: at "ORACLE_TOOLS.PKG_DDL_UTIL", line 6002
This object key is available: "BC_PORTAL:INDEX:bcp_addresses_l1:BC_PORTAL::BCP_ADDRESSES::::"

The last version does not have this problem.