Building on windows using visual studio: CMake Error: Could not create named generator Visual Studio 17 2022

ChatGPT is using glfw-sys in the code it generates and I can't compile and build.  I have visual studio 2017 installed and visual studio 2022.  This is the output I'm getting.
   Compiling glfw-sys v4.0.0+3.3.5
error: failed to run custom build command for `glfw-sys v4.0.0+3.3.5`

Caused by:
  process didn't exit successfully: `c:\working\rust\penrose_triangle_animation\target\debug\build\glfw-sys-9c72ace6c7467dec\build-script-build` (exit code: 101)
  --- stdout
  CMAKE_TOOLCHAIN_FILE_x86_64-pc-windows-msvc = None
  CMAKE_TOOLCHAIN_FILE_x86_64_pc_windows_msvc = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_x86_64-pc-windows-msvc = None
  CMAKE_GENERATOR_x86_64_pc_windows_msvc = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-pc-windows-msvc = None
  CMAKE_PREFIX_PATH_x86_64_pc_windows_msvc = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-pc-windows-msvc = None
  CMAKE_x86_64_pc_windows_msvc = None
  HOST_CMAKE = None
  CMAKE = None
  running: "cmake" "C:\\Users\\dhorner\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\glfw-sys-4.0.0+3.3.5\\." "-G" "Visual Studio 17 2022" "-Thost=x64" "-Ax64" "-DGLFW_BUILD_EXAMPLES=OFF" "-DGLFW_BUILD_TESTS=OFF" "-DGLFW_BUILD_DOCS=OFF" "-DCMAKE_INSTALL_LIBDIR=lib" "-DGLFW_BUILD_WAYLAND=OFF" "-DCMAKE_INSTALL_PREFIX=c:\\working\\rust\\penrose_triangle_animation\\target\\debug\\build\\glfw-sys-10875c7b5c1b7d51\\out" "-DCMAKE_C_FLAGS= -nologo -MD -Brepro" "-DCMAKE_C_FLAGS_DEBUG= -nologo -MD -Brepro" "-DCMAKE_CXX_FLAGS= -nologo -MD -Brepro" "-DCMAKE_CXX_FLAGS_DEBUG= -nologo -MD -Brepro" "-DCMAKE_ASM_FLAGS= -nologo -MD -Brepro" "-DCMAKE_ASM_FLAGS_DEBUG= -nologo -MD -Brepro" "-DCMAKE_BUILD_TYPE=Debug"

  --- stderr
  CMake Error: Could not create named generator Visual Studio 17 2022
  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 1

  build script failed, must exit now', C:\Users\dhorner\.cargo\registry\src\index.crates.io-6f17d22bba15001f\cmake-0.1.50\src\lib.rs:1098:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

cmake --version
cmake version <IP_ADDRESS>

The code given:
extern crate gl;
extern crate glfw;

use glfw::{Action, Context, Key};

fn main() {
    // Initialize GLFW
    let mut glfw = glfw::init(glfw::FAIL_ON_ERRORS).unwrap();

    // Create a window
    let (mut window, events) = glfw.create_window(800, 600, "Penrose Triangle", glfw::WindowMode::Windowed)
        .expect("Failed to create GLFW window.");

    // Make the window's context current
    window.make_current();

    // Load the OpenGL function pointers
    gl::load_with(|symbol| window.get_proc_address(symbol) as *const _);

    // Set the clear color to black
    unsafe {
        gl::ClearColor(0.0, 0.0, 0.0, 1.0);
    }

    // Define the vertices and indices of the Penrose triangle
    let vertices: [f32; 12] = [
        -1.0, -1.0, 0.0,
         1.0, -1.0, 0.0,
         0.0,  1.0, 0.0,
        -1.0, -1.0, 0.0,
    ];
    let indices: [u32; 6] = [
        0, 1, 2,
        2, 1, 3,
    ];

    // Create a vertex buffer object (VBO) for the vertices
    let mut vbo: u32 = 0;
    unsafe {
        gl::GenBuffers(1, &mut vbo);
        gl::BindBuffer(gl::ARRAY_BUFFER, vbo);
        gl::BufferData(gl::ARRAY_BUFFER, (vertices.len() * std::mem::size_of::<f32>()) as isize,
                       vertices.as_ptr() as *const _, gl::STATIC_DRAW);
    }

    // Create an element buffer object (EBO) for the indices
    let mut ebo: u32 = 0;
    unsafe {
        gl::GenBuffers(1, &mut ebo);
        gl::BindBuffer(gl::ELEMENT_ARRAY_BUFFER, ebo);
        gl::BufferData(gl::ELEMENT_ARRAY_BUFFER, (indices.len() * std::mem::size_of::<u32>()) as isize,
                       indices.as_ptr() as *const _, gl::STATIC_DRAW);
    }

    // Create a vertex array object (VAO) to bind the VBO and EBO
    let mut vao: u32 = 0;
    unsafe {
        gl::GenVertexArrays(1, &mut vao);
        gl::BindVertexArray(vao);
        gl::BindBuffer(gl::ARRAY_BUFFER, vbo);
        gl::VertexAttribPointer(0, 3, gl::FLOAT, gl::FALSE, 3 * std::mem::size_of::<f32>(), std::ptr::null());
        gl::EnableVertexAttribArray(0);
        gl::BindBuffer(gl::ELEMENT_ARRAY_BUFFER, ebo);
    }

    // Initialize the time variable and the angle
    let mut time: f32 = 0.0;
    let mut angle: f32 = 0.0;
    let mut direction: f32 = 1.0;

    // Main render loop
    while !window.should_close() {
        // Update the time and angle variables
        let delta_time = glfw.get_time() as f32 - time;
        time = glfw.get_time() as f32;
        angle += 100.0 *

I uninstalled and reinstalled the latest CMake.   I did get the software working!  It wasn't a penrose triangle exactly; but it was a triangle.


Update to Scala 2.12.0

From what I understand, the major blocker for this update is play-iteratees which have not been published against 2.12. On the other hand it seams that play-iteratees is being deprecated in favour of akka-stream and has not seen any update for months.
Can ReactiveMongo drop support for play-iteratees altogether?

That's not the blocker

@cchantep when are you going to make 0.12 release for scala 2.12? Is there any kind of snapshot to work with?

When the required dependencies themselves will be available for 2.12.


chore(main): release 0.5.1

:robot: I have created a release beep boop
0.5.1 (2024-03-01)
Bug Fixes

hmm_source_relationships.header (#88) (a500cb2)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/socialgene/sgpy/releases/tag/v0.5.1 :sunflower:


Format docs to show with --help correctly

Currently it prints out (not intended):

New TOPMed metrics be added to Exemplar LIMS merge report: - PF HQ Aligned Q20
Bases - Mean Insert Size (Library AVG) # corrected value - WGS HET SNP Q - WGS
HET SNP SENSITIVITY Update code that uses a single input file (example in
below) and generates an XLSX workbook with two sheets: - tab3 for TOPMed
Weekly Report, 'Production Metrics' (tab3) - tm_qc for TOPMed sample QC e.g. -
merge_report_with_new_topmed_metrics.xlsx Columns in TOPMed Weekly Report tab3
'Production Metrics': 1 External ID # extract from merge_name 2 Collection #
Study/Cohort 3 PF HQ Aligned Q20 Bases # new 4 Mean Insert Size (Library AVG)
# new 5 Mean Coverage (Raw) # new correct value 6 WGS HET SNP Q # new 7 WGS
HET SNP SENSITIVITY # new 8 Per 10 Coverage Bases 9 Per 20 Coverage Bases 10
Q20 Bases 11 Contamination % # convert Contamination Rate to Contamination %
12 Notes

positional arguments:
  recent_merge_report  *.xlsx, usually downloaded from Exemplar LIMS
  output_file          should end with .xlsx

optional arguments:
  -h, --help           show this help message and exit

It should print out something more readable:
New TOPMed metrics be added to Exemplar LIMS merge report:
- PF HQ Aligned Q20 Bases
- Mean Insert Size (Library AVG) # corrected value
- WGS HET SNP Q
- WGS HET SNP SENSITIVITY

Update code that uses a single input file (example in below) and
generates an XLSX workbook with two sheets:
- tab3 for TOPMed Weekly Report, 'Production Metrics' (tab3)
- tm_qc for TOPMed sample QC

e.g.
- merge_report_with_new_topmed_metrics.xlsx

Columns in TOPMed Weekly Report tab4 'Production Metrics':
1 External ID  # extract from merge_name
2 Collection  # Study/Cohort
3 PF HQ Aligned Q20 Bases # new
4 Mean Insert Size (Library AVG)  # new
5 Mean Coverage (Raw)  # new correct value
6 WGS HET SNP Q  # new
7 WGS HET SNP SENSITIVITY  # new
8 Per 10 Coverage Bases
9 Per 20 Coverage Bases
10 Q20 Bases
11 Contamination %  # convert Contamination Rate to Contamination %
12 Notes

positional arguments:
  recent_merge_report  *.xlsx, usually downloaded from Exemplar LIMS
  output_file          should end with .xlsx

optional arguments:
  -h, --help           show this help message and exit

https://docs.python.org/3/library/argparse.html#formatter-class

Fixed by PR #8.


BUG - 403 forbidden when member cannot be messaged

Ignoring exception in on_member_join
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/discord/client.py", line 378, in _run_event
    await coro(*args, **kwargs)
  File "/src/cogs/admin/verification_on_join.py", line 46, in on_member_join
    await member.send(welcome_message)
  File "/usr/local/lib/python3.9/site-packages/discord/abc.py", line 1616, in send
    data = await state.http.send_message(
  File "/usr/local/lib/python3.9/site-packages/discord/http.py", line 365, in request
    raise Forbidden(response, data)
discord.errors.Forbidden: 403 Forbidden (error code: 50007): Cannot send messages to this user
Ignoring exception in on_member_update
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/discord/client.py", line 378, in _run_event
    await coro(*args, **kwargs)
  File "/src/cogs/logging/logging_member_roles.py", line 47, in on_member_update
    await logs_channel.send(embed=embed)
UnboundLocalError: local variable 'embed' referenced before assignment

Error appears to block verification. Occurs when a user who has "Open DM permission" off, and the user cannot be messaged.
Perhaps we can add an error handler here that skips the message if someone cannot be DM-ed.

https://github.com/practical-python-org/ZorakBot/pull/174


Adding support of local LLMs

Hello, would it be possible to integrate something like GPT4All which runs locally and doesn't cost unlike OpenAI?

I second this motion, there are several local LLM software solutions that provide API access and it'd open this project to the majority of people.

+1 That would be great. I will try my best to find some time, but for now, here is a response I gave in another thread:
It should be relatively simple to make it happen. The main place you will need to edit would be:
generative_agents/reverie/backend_server/persona/prompt_template/gpt_structure.py
This is where all the actual API calls to OpenAI are made. You will want to edit the functions there to instead call Llama2. (You may have to edit utils.py + a few prompts if they break when using it with Llama)

You can run https://github.com/oobabooga/text-generation-webui with this extension: https://github.com/oobabooga/text-generation-webui/tree/main/extensions/openai
You can also replace the embeddings with Sentence Transformers by replacing get_embeddings(...):

from sentence_transformers import SentenceTransformer
def get_embedding(text, model_name="paraphrase-distilroberta-base-v1"):
    # Initialize the SentenceTransformer model
    model = SentenceTransformer(model_name)

    text = text.replace("\n", " ")
    if not text:
        text = "this is blank"

    # Get the embedding
    embedding = model.encode(text)

    return embedding

And then override api_base in utils.py to point to your proxy.
I have a hacky fork doing this at the moment: https://github.com/joonspk-research/generative_agents/compare/main...InconsolableCellist:generative_agents:main
However I'm not seeing any observed actions in my simulation. I suspect my model isn't generating content that's parsed into useful actions, though I haven't gone that far debugging it yet.

we have a similiar work like this standford town, but WI.    our team put some open source llm in the senario and we tested that THEY JUST DO NOT WORK without finetuing. the open source llms like llama and chatglm can not generate resonable and stable content.

Implemented GPT4All here :) Stars appreciated star⭐
https://github.com/SaturnCassini/gpt4all_generative_agents

It was super easy so thanks for modularizing all the gpt logic in one place @joonspk-research

@pjq It does work, it tends to loop but i think that can be solved with increased temperature and changing the params of the model, like penalty for repetition.
Also I didnt try models with more params, only orca mini which is known to not give the best results

You can run https://github.com/oobabooga/text-generation-webui with this extension: https://github.com/oobabooga/text-generation-webui/tree/main/extensions/openai
You can also replace the embeddings with Sentence Transformers by replacing get_embeddings(...):

from sentence_transformers import SentenceTransformer
def get_embedding(text, model_name="paraphrase-distilroberta-base-v1"):
    # Initialize the SentenceTransformer model
    model = SentenceTransformer(model_name)

    text = text.replace("\n", " ")
    if not text:
        text = "this is blank"

    # Get the embedding
    embedding = model.encode(text)

    return embedding

And then override api_base in utils.py to point to your proxy.
I have a hacky fork doing this at the moment: main...InconsolableCellist:generative_agents:main
However I'm not seeing any observed actions in my simulation. I suspect my model isn't generating content that's parsed into useful actions, though I haven't gone that far debugging it yet.

Does this mean replacing the entire utils.py with this code? But it seems that the error is reported openai_api_key does not exist, how to call this code instead?

Does this mean replacing the entire utils.py with this code? But it seems that the error is reported openai_api_key does not exist, how to call this code instead?

If you want to give it a try you can fork my repo. I had to add api_base in utils.py and then change the GPT calls to include api_base as a param (not sure if I could've done an environment variable or global variable instead). I replaced get_embedding where it appeared in gpt_structure.py as well.
Follow the instructions as normal to create your utils.py and add api_base = "http://yourserver:5001/v1"

这是否意味着用此代码替换整个 utils.py？但是似乎报告了错误openai_api_key不存在，如何调用此代码？

如果你想试一试，你可以分叉我的回购。我不得不在 utils.py 中添加api_base，然后更改 GPT 调用以包含api_base作为参数（不确定我是否可以代替环境变量或全局变量）。我也替换了get_embedding它出现在gpt_structure.py的地方。
照常按照说明创建 utils.py 并添加api_base = "http://yourserver:5001/v1"

I found an API interface that mimics OpenAPI under Alpaca2 in Stanford, and now it's deployed, and I only need URL http://localhost:19327/v1/completions to access the local port, so how can I now dock the port. Do I need to make changes to the gpt_structure.py script or utils.py?

@SaturnCassini Could you open up 'Issues" on your repo?

https://github.com/joonspk-research/generative_agents/issues/3#issuecomment-1672537659
The extension + setting export OPENAI_API_BASE="http://mylanahost:5001/v1" did it

https://github.com/SaturnCassini/gpt4all_generative_agents/issues

Whenever run xxx ends, this error will appear. Has anyone encountered this problem?
-==- -==- -==-
Traceback (most recent call last):
  File "/data/generative_agents/reverie/backend_server/reverie.py", line 471, in open_server
    rs.start_server(int_count)
  File "/data/generative_agents/reverie/backend_server/reverie.py", line 379, in start_server
    next_tile, pronunciatio, description = persona.move(
  File "/data/generative_agents/reverie/backend_server/persona/persona.py", line 222, in move
    plan = self.plan(maze, personas, new_day, retrieved)
  File "/data/generative_agents/reverie/backend_server/persona/persona.py", line 148, in plan
    return plan(self, maze, personas, new_day, retrieved)
  File "/data/generative_agents/reverie/backend_server/persona/cognitive_modules/plan.py", line 959, in plan
    _determine_action(persona, maze)
  File "/data/generative_agents/reverie/backend_server/persona/cognitive_modules/plan.py", line 573, in _determine_action
    generate_task_decomp(persona, act_desp, act_dura))
  File "/data/generative_agents/reverie/backend_server/persona/cognitive_modules/plan.py", line 164, in generate_task_decomp
    return run_gpt_prompt_task_decomp(persona, task, duration)[0]
  File "/data/generative_agents/reverie/backend_server/persona/prompt_template/run_gpt_prompt.py", line 439, in run_gpt_prompt_task_decomp
    output = safe_generate_response(prompt, gpt_param, 5, get_fail_safe(),
  File "/data/generative_agents/reverie/backend_server/persona/prompt_template/gpt_structure.py", line 262, in safe_generate_response
    return func_clean_up(curr_gpt_response, prompt=prompt)
  File "/data/generative_agents/reverie/backend_server/persona/prompt_template/run_gpt_prompt.py", line 378, in __func_clean_up
    duration = int(k[1].split(",")[0].strip())
IndexError: list index out of range
Error.


Using a custom prefix for a style fails with indented syntax (.sass)

I am trying to compile the following file
test.sass
:global .test
  background-color: #eee

via
./node_modules/node-sass/bin/node-sass -i test.sass test.css

but it fails with
{
  "message": "invalid top-level expression",
  "column": 1,
  "line": 1,
  "file": "/path-to-project/test.sass",
  "status": 1
}

Doing the same with scss syntax works perfectly. I am not sure if this is intended behaviour or a bug. Interestingly, the same example works on sassmeister.com although they are using node-sass for compilation. But i have no idea why!
For reference, I am trying to use global prefix for react css modules [gajus/react-css-modules#15].
My Setup:
> ./node_modules/node-sass/bin/node-sass -v
node-sass	3.3.2	(Wrapper)	[JavaScript]
libsass  	3.2.5	(Sass Compiler)	[C/C++]

@namxam the example given is not valid .sass and such will not compile on Node Sass. The .scss on the other hand is a super set of CSS and will accept this syntax.
If you think the the :global/:local: syntax of css modules should be part of the .sass` syntax you'll need to create an issue with the official Sass repository https://github.com/sass/sass/issues


CASMINST-5670 - Request for more clarity on "external ssh test" in docs

Description
If the External SSH tests are run from another CSM system that has overlapping (or default) network ranges for the Node Management and Hardware Management networks then some tests will fail.
An example would be running a check for fanta on surtur, both of which have been installed with default internal network values.
The test running on surtur will perform a DNS lookup for sw-spine-001.hmn.fanta.dev.cray.com and get the IP address <IP_ADDRESS> however that IP address also corresponds its own sw-spine-001 switch so the SSH test will succeeds whereas if it was run from an external non-CSM host it would fail.
Checklist Before Merging

[ ] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[X] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.2


Tooltips in other formats than html

The tooltips (hover mouse cursor -> see properties) in html exports are very useful. So much so, that I don't want to publish in a format that doesn't support them. But html (esp. incl.

We support HTML in tooltips, which isn't possible in SVG and PNG.

There could still be an embed option with completely static html, which would resolve the problem of embedding in markdown, etc., while retaining tooltips.
Does that mean you have no interest in implementing that ?

Not sure what you mean by "embed option with completely static html"?

At the moment, you can't embed a diagram exported as html in a lot of contexts (including GitHub/GitLab markdown), because it's not just static html, it contains

Sorry, static HTML export isn't possible.

I know it's impossible now. The issue was about making it possible ;]
But if you're saying this will not be implemented, then fine. Ack.

It's technically impossible, which means it cannot be solved or made possible.

What's technically impossible ? Generating an html page that shows a diagram without using javascript ?

Cross-browser, yes.


help with blocked firewall for ppa

my organization blocking this ppa to add on our systems , any possible way u can help ?? thanks

build this using docs with flag --btype=binary and install debs by dpkg -i *.deb


Undefined symbols for architecture x86_64:   "absl::lts_2019_08_08::AlphaNum" When building

Xcode version: 11.2.1
Firebase SDK version: 6.13.0?
Firebase Component: Firestore
Component version: 6.13.0

I use Firebase on iOS (mainly for Firestore) and have been working fine. Today I have updated Firebase with Carthage to version 6.13.0 and now my project fails to build with the following errors:
Undefined symbols for architecture x86_64:
  "absl::lts_2019_08_08::AlphaNum::AlphaNum(absl::lts_2019_08_08::Hex)", referenced from:
      firebase::firestore::nanopb::PrintHeader(int, absl::lts_2019_08_08::string_view, void const*) in FirebaseFirestore(pretty_printing.o)
  "absl::lts_2019_08_08::Base64Escape(absl::lts_2019_08_08::string_view, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)", referenced from:
      firebase::firestore::local::DescribeKey(leveldb::Slice) in FirebaseFirestore(leveldb_key.o)
  "absl::lts_2019_08_08::StrAppend(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, absl::lts_2019_08_08::AlphaNum const&, absl::lts_2019_08_08::AlphaNum const&, absl::lts_2019_08_08::AlphaNum const&, absl::lts_2019_08_08::AlphaNum const&)", referenced from:
      firebase::firestore::remote::Datastore::GetWhitelistedHeadersAsString(std::__1::multimap<grpc::string_ref, grpc::string_ref, std::__1::less<grpc::string_ref>, std::__1::allocator<std::__1::pair<grpc::string_ref const, grpc::string_ref> > > const&) in FirebaseFirestore(datastore.o)
  "absl::lts_2019_08_08::AlphaNum::AlphaNum(absl::lts_2019_08_08::Hex)", referenced from:
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > firebase::firestore::util::StringFormat<firebase::firestore::remote::RemoteStore*>(char const*, firebase::firestore::remote::RemoteStore* const&) in FirebaseFirestore(remote_store.o)

My cart file looks like this:
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFunctionsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseStorageBinary.json"
binary "https://building42.github.io/Specs/Carthage/iOS/Fabric.json"
binary "https://building42.github.io/Specs/Carthage/iOS/Crashlytics.json"

Is this a bug or is there something that has changed that I am not aware of? Thanks in advance!

@UMAD It looks like you didn't add in the absl.framework that is now installed with Firestore.

@paulb777 That was indeed the issue. Thanks! I didn't notice that this abseil.framework was downloaded when I did an update. Is there a newsletter or somewhere I can subscribe or some feed where I can see the release notes? Downloading updates that break builds then having to fish around for "what's new" doesn't seem to be idle.

@UMAD Glad that worked!
The release notes are here - https://firebase.google.com/support/release-notes/ios.
Making a newsletter/mailing list/subscription for the release notes is a great suggestion. @morganchen12 what do you think?

We used to have a twitter feed, but that stopped being updated when Alex moved off the team. @samtstern should we revive it?

Given the technical part of this issue is resolved, I'm going to close the issue. If there's further discussion about how best to publicize this feel free to continue discussion here or create a new issue.
@UMAD note that it's usually worth taking a spin through the release notes when upgrading anyway. Besides changes to dependencies this is a good way to see if there are fixes that might affect you or find out about new features.


support size of list or dict using ()

E.g.
type x = string[](1..2);

should be a list of strings with at least one and max 2 elements.
Should also allow
type x = string(5..10)[](1..2);

so list with 1 or 2 strings with length between 5 and 10
and also dict(2.4)[](5..6){}(8..9)
etc etc

The first example looks OK but the second starts to look a bit complicated. I don't understand what the last one does! (List with 5 or 6 elements that must be dicts... wait: dict[]{} isn't valid PAN today?!)
The use case seems valid but it we need to avoid confusing/ambiguous syntax, e.g.
type x = string[] with length(SELF) > 0 && length(SELF) < 3;

Does that apply to the length of the list of the length of the string within a list? Using brackets before & after the [] is actually less ambiguous but it's hard to remember: which is the length of the string and which is the length of the list?
How about:
type x = string[1,2] with [ length(SELF) > 0 && length(SELF) < 3 ];

The [1,2] constrains the length of the list and then the use of [] instead of {} shows it's a list comprehension on each member? My feeling is that being able to generically apply functions to members of a list via list comprehension syntax is more useful than being able to just constrain the length of a string.

@ned21 i like the [1..2] or {1..2} for size of list or dict (but we should use the .. separator imho); but i also like that (1..2) means size of of any type.
so
type x = string[];
type y = x(1..2);

should always be possible. maybe we can promote () to mean size of any type, and allow shortahnd [1..2] to mean [](1..2)?
SELF always means the full type, i don't find that confusing, but i do mind the boilerplate.
dict[]{} is (or should be) valid  pan, but my point with the 3rd example was to remind myself to make this fully recursive.


Loosing sync

I'm using helm in tillerless mode using the helm-tiller and in some cases losing sync with my releases. I can see a release in Minikube via k9s but helm list doesn't return any releases.
Where is tiller state saved?
Any suggestions on how I could either troubleshoot this or fix the issue altogether?
Output of helm version:
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T18:55:03Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Minikube

I would suggest opening an issues in Tillerless Helm as it is independent of Helm.
How Helm Uses ConfigMaps to Store Data provides detailed information on Helm state.

Closing as Tillerless helm issue.


Support for NuxtJS

I am having a little trouble registering the components in NuxtJS. I've tried importing it explicitly to using it as a plugin, still not recognizing the <vsm-menu> or <vsm-mob> components. Kindly help out.

Solved

vue.runtime.esm.js?2b0e:619 [Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render.

vue.runtime.esm.js?2b0e:619 [Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render.

I just created a new project in nuxtjs, connected the library - there seems to be no problem in the library itself.
Can you provide a little more information? For example, maybe you wrap a component in a <p /> element:
<template>
  <p>
    <vue-stripe-menu .. />
  </p>
</template>


Module 2.2 Assignment

👋 for this assignment, if you'd like to try again, please include a screenshot of merging on the command line using git merge.

for this assignment, if you'd like to try again, please include a screenshot of merging on the command line using git merge.

Sure i will try it again after lockdown due to covid19, all files are in lab.


infra: K8S cluster setup

In order to run full-scale network tests, we need to set up the k8s cluster on a cloud provider.
Here are the steps that needs to be done:

Choose a cloud provider
Install all dependencies required to run a testground's test-plan
Setting up a monitoring dashboard for runs
Including test-runs into GA (e.g. cadence)

Materials to read:

Docs on K8s from testground
Scripts-Infra repo

Ref: https://github.com/testground/testground/issues/1374

Closing in favour of #53


Update deployment target to iOS 9

iOS 8 is now several years old and is used by only a small fraction of active devices. As a result, iOS 9 should be the new baseline.

This is done.


most tests fail on Windows7

JVM doesn't start:
File "voc\tests\utils.py", line 500, in runAsJava
self.jvm.stdin.flush()
OSError: [Errno 22] Invalid argument
File write failed:
File "env\lib\encodings\cp1251.py", line 19, in encode
UnicodeEncodeError: 'charmap' codec can't encode character '\xff' in position 678: character maps to

@mygitplace is this issue resolved by #200?

yes, these 2 above were resolved in #200, there still other issues with Windows


Publish master docs to GitHub Pages

Not sure how important it is, but might be helpful for seeing the current status/API coverage.

I can setup a simple CI workflow. I guess it should be on a gh-pages branch?

Yeah, I think so.

If this is integrated with Travis CI, please do not introduce any Python tooling as part of this... I found working with their Python environment when I wanted a mixed Rust and Python environment absolutely execrable and I am not an incompetent Python author, and Travis specifically borks their Python environment for backwards compatibility reasons.

I've had Travis auto-publish to gh-pages before and it can be done purely with a workflow, no python required.

Oh good, that is Also Fine.

@KodrAus the gh-pages branch is deployed, but I don't think I have repository permissions to actually enable it


Master

In some instances failure to open has caused the printf output to
appear in other processes.

Changes applied.

I'm sorry but your change doesn't fix anything, I get the same error with and without it when I execute the script with a non-existent domain name:
$ ./burl ietf.or
./burl: line 17: ietf.or: nodename nor servname provided, or not known
./burl: line 17: /dev/tcp/ietf.or/80: Invalid argument
31/07/2017 19:41:16 unable to connect: ietf.or:80/

I didn't explain thing too well. The change fixes the the impact of the printf outputting to the unopened file descriptor number 3. It does this by only executing the printf etc lines if the exec 3 open is successful. It obviously isn't possible to fix connections to unreachable sites in the script.

On my system which uses a pipe for inter-process communication writing to the unopened file descriptor 3 actually presents the contents of the printf to my process through its pipe. This impacted process is a separate executable, I suspect an issue somewhere in Linux triggered by the open failure in the burl script. I beleive I have worked around this internal issue by only using the file descriptor once it has opened correctly.


Add Miyoushe login methods

About this PR
Currently genshin.py only supports login with account & password via HoYoLAB, this PR plans to add support to Miyoushe (CN HoYoLAB) as well.
Planned Features

Login with email/username and password: Done
Login with phone number + Ability to send OTP: Done
Check mobile number validity: Done

Other Information

The CN password login method is currently exposed in a separate function in the GeetestClient called cn_login_by_password
It seems like password login in Miyoushe doesn't have such thing as e-mail verification
I'm unable to trigger CAPTCHA with password login and OTP login, so whether the retcode is correct is unknown

https://github.com/thesadru/genshin.py/pull/167/commits/73daf08a347ecb7711605e2e04e49fcbd4f93aa7 adds the following stuff:

2 new public methods check_mobile_number_validity and login_with_mobile_number in GeetestClient.
New method enter_otp in geetest server (uses the same web page as email-verification internally)

All of them work for me while testing with my account; although once again I'm unable to trigger captcha, so that part of the code might not work.

Also, one thing that I haven't figured out is stoken... both OTP and password login in Miyoushe doesn't return stoken in the cookies.
That is unrelated to this PR tho.

Also, one thing that I haven't figured out is stoken... both OTP and password login in Miyoushe doesn't return stoken in the cookies. That is unrelated to this PR tho.

This is because you was working with web endpoint. There is no need for hoyo to add stoken because users can re-login through their web browser at any time.

This is because you were working with web endpoint. There is no need for hoyo to add stoken because users can re-login through their web browser at any time.

From what I heard from Chinese players, there is no such thing as redeeming code through the website, they all redeem through in-game. So, since our primary use for stoken is to refresh cookie_token, and cookie_token is only used for code redemption, I feel like there is no need to figure out how to obtain the stoken whatsoever.


More ergonomic client creation

Clients inside of the various SDKs form a tree structure. Typically, a "service" client (e.g., BlobServiceClient) is at the top of this structure, and other clients are created using that service client or some intermediate clients that are in turn created using the service client (e.g., a BlobClient is created using a ContainerClient which in turn is created using the BlobServiceClient).
This can work well but is not always the most ergonomic. For example, if you just want to interact with a specific blob you need to do the following:
let storage_credentials = StorageCredentials::Key(account.clone(), access_key); // Create the credentials
let service_client = BlobServiceClient::new(account, storage_credentials); // Create the service client
let blob_client = service_client
     .container_client(&container_name) // create the intermediate container client
     .blob_client(&blob_name); // Now we get the blob client.

It would be nice to offer the user a more convenient way to get to the blob client.
One possible way is to change the BlobServiceClientBuilder into just a ClientBuilder. Then instead of a build method that gives you a BlobServiceClient you would have multiple builder methods that give you the client you want:

service(self) -> BlobServiceClient
container(self, container_name: impl Into<String>) -> ContainerClient
blob(self, container_name: impl Into<String>, blob_name: impl Into<String>) -> BlobClient

This might get a bit unwieldy at deeply nested clients though.
However, in general such a design together with every client having convenient methods for getting other clients means that getting the client you need is never more than one method call away.

Additionally, there are some customers who need different client options depending on the resource. In the current API, they need to traverse the client tree twice. In code:
Before
let storage_credentials = StorageCredentials::Key(account.clone(), access_key); // Create the credentials

// Interact with blobs
let blob_client = BlobServiceClientBuilder::new(acount, storage_credentials)
      .retry(blob_retry_options)
     .container_client(&container_name)
     .blob_client(&blob_name);

// Interact with container
let container_client = BlobServiceClientBuilder::new(acount, storage_credentials)
      .retry(container_retry_options)
     .container_client(&container_name);

After
let storage_credentials = StorageCredentials::Key(account.clone(), access_key); // Create the credentials

// Interact with blobs
let blob_client = ClientBuilder::new(acount, storage_credentials)
      .retry(blob_retry_options)
      .blob_client(&container_name, &blob_name);

// Interact with container
let container_client = ClientBuilder::new(acount, storage_credentials)
      .retry(blob_retry_options)
      .container_client(&container_name);

So this does not currently work?
let storage_credentials = StorageCredentials::Key(account.clone(), access_key); // Create the credentials

// Interact with container
let container_client = BlobServiceClientBuilder::new(acount, storage_credentials)
      .retry(container_retry_options)
     .container_client(&container_name);

// Interact with blobs
let blob_client = container_client.blob_client(&blob_name);

That works. This is specifically for when you need clients that have different client options. We want to allow creating clients quickly without necessarily traversing the entire client tree to get to the client you want.

Brainstorming a bit, this feels like a problem that might be better solved w/ proc. macros. The current client creation api's match the pattern of what the upstream .net client builders use, so from that aspect it's good enough. But, since this is rs, I'm thinking you could have proc_macros that also do DI. For example, what if it's like this,
#[derive(Azure)]
struct MyStruct {
    #[az::storage::container]
    tenant: String,
    #[az::storage::blob]
    manifest: String,
    #[az::storage::blobs]
    files: HashSet<String>,
}

..

impl MyStruct {
    fn async cleanup(&mut self) {
      let manifest = self.blob("manifest").deserialize_to::<Manifest>().await.expect("should be a valid manifest");

      for d in manifest.delete.iter() {
        if let Some(to_delete) = self.remove(d) {
           let delete_resp = self.blob(to_delete).delete().await;
           // etc, etc
        }
      }
   }
}

And then behind the scenes, there's a trait that will setup all of the client trees using the fields to fill out the client creation code.
Of course this can be extended for all other resources in azure too. If there's interest I could work on a prototype.


Gemini-Pro response.text Error

We are getting error after getting response from gemini.
Error: "The response.text quick accessor only works for simple (single-Part) text responses. This response is not simple text.Use the result.parts accessor or the full result.candidates[index].content.parts lookup instead."
Code:
`
genai.configure(api_key = api_key)
model = genai.GenerativeModel('gemini-pro')
response = model.generate_content(final_msg[l])
tmp.append(response.text)  ### <-- Getting Error Here`
It is getting error for multiple text inputs which contains mathematical tokens(like lambda, pi, alpha, beta ...).
Thanks

I'm also having the same error.
Encountered this error while passing 4 images with prompt input to the model.
Then I tried using result.parts, as suggested by Gemini
It returned an empy list []

Right, sometimes the model doesn't return any text.
result.parts or result.candidates will show you what it did return.
You can check response.prompt_feedback to see if it had a problem with the prompt, and look at the additional fields on the Candidate - result.candidates[index] to see the finish reason and a few other things.
Maybe the error message should say that.

Right, sometimes the model doesn't return any text.
result.parts or result.candidates will show you what it did return.
You can check response.prompt_feedback to see if it had a problem with the prompt, and look at the additional fields on the Candidate - result.candidates[index] to see the finish reason and a few other things.
Maybe the error message should say that.

I used response.prompt_feedback, it didn't mention any warning message, all text was neutral and safe.
Then with result.candidates, the reason was mentioned as finish_reason: other.

See #170 Maybe it will help you

Yes, I had tried techniques in that issue too, but it didn't solve the error.
1] Altered safety_settings, still same error
2] Increased max_output_tokens to 10000 tokens, still same error

Would really like this to be fixed or properly explained... For me it works if the max_token_limit = 2048. Any less causes this error, which is absurd. What if I want a shorter answer?

one of the  situation was : the ai generated an answer which is proteced by citation, so, the candidates will be like this:

candidates [index: 0
finish_reason: RECITATION
]
(maybe finish_reason: Other, as @Yusuf80216 mentioned)

and  the parts obj is an empty list,  so i guess the ai generated an answer, but the answer is filter by some citation rules, and we get this err, r.However, in BaseGenerateContentResponse we can only get one candidate (or will raise ValueError).
so maybe it's better to return a candidate which is stopped with: FinishReason.STOP,  @MarkDaoust

for text
try:
    # Access the 'candidates' attribute from the response
    candidates = response.candidates

    # Assuming you want to access the first candidate's content
    generated_text = candidates[0].content.parts[0].text

    print("Generated Text:", generated_text)
except (AttributeError, IndexError) as e:
    print("Error:", e)

used for image

response = model.generate_content(img)

try:
    # Check if 'candidates' list is not empty
    if response.candidates:
        # Access the first candidate's content if available
        if response.candidates[0].content.parts:
            generated_text = response.candidates[0].content.parts[0].text
            print("Generated Text:", generated_text)
        else:
            print("No generated text found in the candidate.")
    else:
        print("No candidates found in the response.")
except (AttributeError, IndexError) as e:
    print("Error:", e)

It's absurde. Same here with any max token or lower safety_settings.

Same problem, chat.send_message (with stream flag) also sending the same exception, but only occasionally.  If the response comes back in different streaming chunks, some of them come back just fine before the exception.  Seems like a bug on the Google endpoint.

Use the following code to extract the response, You cannot access the text directly from the response
all_responses = []
for response in responses:
for part in response.parts:
if part.text:
all_responses.append(part.text)

We are getting error after getting response from gemini.
Error: "The response.text quick accessor only works for simple (single-Part) text responses. This response is not simple text.Use the result.parts accessor or the full result.candidates[index].content.parts lookup instead."
Code: ` genai.configure(api_key = api_key) model = genai.GenerativeModel('gemini-pro')
response = model.generate_content(final_msg[l]) tmp.append(response.text) ### <-- Getting Error Here`
It is getting error for multiple text inputs which contains mathematical tokens(like lambda, pi, alpha, beta ...).
Thanks

Right, there are a few ways that it can fail top return text. Look at result.prompt_feedback and result.candidates[0], they will give youy mopre information about what went wrong.


Incompatible transport object

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
v2
Current Behavior
Argument of type 'TransportConfig<string, { (args: { method: "web3_clientVersion"; params?: undefined; }): Promise; (args: { method: "web3_sha3"; params: [data: 0x${string}]; }): Promise; (args: { ...; }): Promise<...>; (args: { ...; }): Promise<...>; (args: { ...; }): Promise<...>; (args: { ...; }): Promise<...>; (...' is not assignable to parameter of type 'ExternalProvider |
Expected Behavior
No response
Steps To Reproduce
import * as React from 'react'
import { type PublicClient, usePublicClient, type WalletClient, useWalletClient } from 'wagmi'
import { providers } from 'ethers'
import { type HttpTransport } from 'viem'
function publicClientToProvider(publicClient: PublicClient) {
const { chain, transport } = publicClient
const network = {
chainId: chain.id,
name: chain.name,
ensAddress: chain.contracts?.ensRegistry?.address,
}
if (transport.type === 'fallback')
return new providers.FallbackProvider(
(transport.transports as ReturnType[]).map(
({ value }) => new providers.JsonRpcProvider(value?.url, network),
),
)
return new providers.JsonRpcProvider(transport.url, network)
}
/** Hook to convert a viem Public Client to an ethers.js Provider. */
export function useEthersProvider({ chainId }: { chainId?: number } = {}) {
const publicClient = usePublicClient({ chainId })
return React.useMemo(() => publicClientToProvider(publicClient), [publicClient])
}
function walletClientToSigner(walletClient: WalletClient) {
const { account, chain, transport } = walletClient
const network = {
chainId: chain.id,
name: chain.name,
ensAddress: chain.contracts?.ensRegistry?.address,
}
const provider = new providers.Web3Provider(transport, network)
const signer = provider.getSigner(account.address)
return signer
}
/** Hook to convert a viem Wallet Client to an ethers.js Signer. */
export function useEthersSigner({ chainId }: { chainId?: number } = {}) {
const { data: walletClient } = useWalletClient({ chainId })
return React.useMemo(
() => (walletClient ? walletClientToSigner(walletClient) : undefined),
[walletClient],
)
}
Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)
https://github.com/emiridbest/celoPets
Anything else?
The error is preventing DApps from deploying on vercel

Thanks for reporting. This issue is temporarily closed due to lack of information. Please provide a minimal reproducible example and reopen this issue.


dts: opentitan: update plic interrupt count to match spec

previously 184, update to 182, per:
https://opentitan.org/book/hw/top_earlgrey/ip_autogen/rv_plic/

@snematbakhsh PTAL.

@snematbakhsh PTAL.

LGTM (need to ask a maintainer for official approval though).
182 matches the current OT implementation: https://github.com/lowRISC/opentitan/blob/master/hw/top_earlgrey/ip_autogen/rv_plic/data/rv_plic.hjson#L40
Just a reminder that ndev = 182 actually means we have only 181 "real" interrupt sources because 0 is reserved (see https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#4-interrupt-identifiers-ids). That aligns with the zephyr rv_plic driver and the OT implementation, but might confuse those who look at dts (13f8d809300299cb56abf763d289e0b2eec0d4dc seems like evidence of past confusion).

@ycsin this patch could use review as well.

@ngm0  I don't think the CI failure is related to this PR, probably needs a rebase to fix


add support for akka grpc - update schedule flags

Codecov Report
Base: 36.29% // Head: 52.01% // Increases project coverage by +15.71% :tada:

Coverage data is based on head (acc9df3) compared to base (da4f290).
Patch coverage: 84.37% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##             main       #2       +/-   ##
===========================================
+ Coverage   36.29%   52.01%   +15.71%
===========================================
  Files           6       10        +4
  Lines         270      298       +28
===========================================
+ Hits           98      155       +57
+ Misses        172      143       -29

Flag
Coverage Δ

unittests
52.01% <84.37%> (+15.71%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...tnetwork/scheduler/handlers/SchedulerHandler.scala
53.33% <ø> (+13.33%)
:arrow_up:

...etwork/scheduler/launch/SchedulerApplication.scala
0.00% <0.00%> (ø)

...cheduler/persistence/typed/SchedulerBehavior.scala
55.24% <50.00%> (+16.57%)
:arrow_up:

...pp/softnetwork/scheduler/api/SchedulerServer.scala
66.66% <66.66%> (ø)

...ala/app/softnetwork/scheduler/api/GrpcClient.scala
100.00% <100.00%> (ø)

...pp/softnetwork/scheduler/api/SchedulerClient.scala
100.00% <100.00%> (ø)

...cala/app/softnetwork/scheduler/model/package.scala
75.00% <100.00%> (+8.33%)
:arrow_up:

...ftnetwork/scheduler/launch/SchedulerGuardian.scala
100.00% <100.00%> (ø)

... and 1 more

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

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


use typescript native types

Description
This PR is a first of two steps to get rid of Omit, Arguments, ConstructorArguments and ThenType in favour of their native Typescript counterpart.
Fixes (issue #)

Type of change

react-async Patch: No impact Omit usage change (non-breaking change which fixes an issue)

react-form-state Patch: No impact Omit usage change (non-breaking change which fixes an issue)

react-graphql Patch: No impact Omit usage change (non-breaking change which fixes an issue)

react-testing Patch: No impact Omit and Arguments usage change (non-breaking change which fixes an issue)

useful-types Patch: No impact ArgumentAtIndex and FirstArgument change to accept Parameters  (non-breaking change which fixes an issue)

[x]  Patch: Bug (non-breaking change which fixes an issue)

[ ]  Minor: New feature (non-breaking change which adds functionality)

[ ]  Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[x] I have added a changelog entry, prefixed by the type of change noted above (Documentation fix and Test update does not need a changelog as we do not publish new version)

As we're now no longer depending on @shopify/useful-types in several places, we might have packages that no longer depend upon @shopify/useful-types. For instance it looks like that was the only usage in react-form-state.
Can you identify these cases where a package no longer depends upon @shopify/useful-types, and then in those packages remove the dependency from package.json and the tsconfig.json.

MaybeFunctionReturnType looks very similar to ReturnType, I wonder if that's a meaningful difference, and thus if it's worth removing MaybeFunctionReturnType?
export type MaybeFunctionReturnType<T> = T extends (...args: any[]) => infer U
  ? U
  : never;

type ReturnType<T extends (...args: any) => any> = T extends (...args: any) => infer R ? R : any;

As we're now no longer depending on @shopify/useful-types in several places, we might have packages that no longer depend upon @shopify/useful-types. For instance it looks like that was the only usage in react-form-state.
Can you identify these cases where a package no longer depends upon @shopify/useful-types, and then in those packages remove the dependency from package.json and the tsconfig.json.

That's done, but it affected some unit tests. Let me know if I handled that properly!

MaybeFunctionReturnType looks very similar to ReturnType, I wonder if that's a meaningful difference, and thus if it's worth removing MaybeFunctionReturnType?
export type MaybeFunctionReturnType<T> = T extends (...args: any[]) => infer U
  ? U
  : never;

type ReturnType<T extends (...args: any) => any> = T extends (...args: any) => infer R ? R : any;

Tried to do it yesterday, but I guess I was tired, but browsing reddit I found exactly what I was missing 😅  that should be done!

I've pushed a commit that reverts the typescript-project-references.test.ts changes and applies the proper fix.
That test asserts that "if you use a dependency on another package in this monorepo in a package's package.json, then there should be a corresponding entry in that package's tsconfig.json reference field" (as this repo uses project references - one ts project per package)
You've removed react-server's dependency on useful-types in the package.json, but you did not remove the reference to the useful-types folder in react-server's tsconfig.json. And thus the test fails, as there should be mention of a dependant package (or in this case no mention of a package that is not depended upon) in both package.json and tsconfig.json.
The fix is not to modify the typescript-project-references.test.ts, but to update the tsconfig.json files, removing the references to useful-types in the packages that no longer depend upon useful-types

Nice! I totally missed that packages had internal tsconfig.json, that's my bad!

I've pushed a commit that reverts the typescript-project-references.test.ts changes and applies the proper fix.
That test asserts that "if you use a dependency on another package in this monorepo in a package's package.json, then there should be a corresponding entry in that package's tsconfig.json reference field" (as this repo uses project references - one ts project per package)
You've removed react-server's dependency on useful-types in the package.json, but you did not remove the reference to the useful-types folder in react-server's tsconfig.json. And thus the test fails, as there should be mention of a dependant package (or in this case no mention of a package that is not depended upon) in both package.json and tsconfig.json.
The fix is not to modify the typescript-project-references.test.ts, but to update the tsconfig.json files, removing the references to useful-types in the packages that no longer depend upon useful-types

Nice! I totally missed that packages had internal tsconfig.json, that's my bad!


Doc: Getting Started Guide: reel board blinky gif is outdated

Describe the bug
If setting up Zephyr according to the Getting Started Guide including build and flash of blinky sample on reel_board / real_board_v2, one can see blinking of red LED D3 (GPIO P0.11) at the front side. However, the Getting Starting Guide shows blinking of another led: LED D13 ( P0.13) at the back side.
To Reproduce
Steps to reproduce the behavior:

build and flash blinky sample for reel_board or reel_board_v2
compare blinking led on the board with blinking led in the Getting Started Guide gif
observe difference: board blinking on front side, gif blinging on back side

Expected behavior
Gif shall show blinking of front LED D3 (GPIO P0.11).
Impact
Could confuse new users setting up Zephyr on reel_board / reel_board_v2 according to Getting Started Guide.
Environment:

OS: Windows
Toolchain: GNU ARM embedded
Version used: 2.4.0-rc1

Additional context
Root cause: blinky controls led0. led0 has been reallocated on the reel_board from the back side led to the front side led. For example, version of 18 Sep 2019 still has "old" mapping which matches the Getting Started Guide blinking.

Root cause: blinky controls led0. led0 has been reallocated on the reel_board from the back side led to the front side led.

That is not quite true, the LED on the back was removed and GPIO reused for the buzzer. Actually documentation issue not a bug.

@DSc-de or @jfischer-phytec-iot will you update the .gif please?

Below please find the updated gif. If acceptable, please commit to /doc/getting_started/img . Please let me know if I shall do a pull request instead (never done this before but the great zephyr documentation will tell me how to).


separate annual timeseries from spr series; improve mean_age reporting

resolves #607
Information is in the issue.
The annual_time_series table has been separated from the SPR_series table such that only per-recruit values are in the SPR table.
update and check the mean age values
add more notes on each table
Testing can be done with any model.
needs work with r4ss

@iantaylor-NOAA - regarding F_report vs. F_std.  They refer to the same quantity and both terms are used in various places through the report file, with more for F_std.  I will consolidate all usage to F_std which is the name of the array.  The term's history is that it is the F quantity for which the standard deviation (std) is produced and reported.

Makes sense, thank you. Easy enough to adapt.


Add intent flag FLAG_ACTIVITY_NEW_TASK

hello thank you for the pull request
I see that there is better solution to this bug
by using ActivityAware and use same activity that used by flutter  (url_launcher plugin use this way )
i will try both your fix and ActivityAware to see which better

Hey,
I will also look into the solution.
Thanks for resolving this using ActivityAware.


added publisher read only mode docs

Purpose

Added documentation for the publisher read only mode feature.
https://docs.google.com/document/d/1VNlv2HEB7EN_kk_57GmA65KtqO5vTu2eYjjS83VFf9E/edit?usp=sharing

Goals

Describe the solutions that this feature/fix will introduce to resolve the problems described above

Approach

Describe how you are implementing the solutions. Include an animated GIF or screenshot if the change affects the UI (email<EMAIL_ADDRESS>to review all UI text). Include a link to a Markdown file or Google doc if the feature write-up is too long to paste here.

User stories

Summary of user stories addressed by this change>

Release note

Brief description of the new feature or bug fix as it will appear in the release notes

Documentation

Link(s) to product documentation that addresses the changes of this PR. If no doc impact, enter “N/A” plus brief explanation of why there’s no doc impact

Training

Link to the PR for changes to the training content in https://github.com/wso2/WSO2-Training, if applicable

Certification

Type “Sent” when you have provided new/updated certification questions, plus four answers for each question (correct answer highlighted in bold), based on this change. Certification questions/answers should be sent to<EMAIL_ADDRESS>and NOT pasted in this PR. If there is no impact on certification exams, type “N/A” and explain why.

Marketing

Link to drafts of marketing content that will describe and promote this feature, including product page changes, technical articles, blog posts, videos, etc., if applicable

Automation tests

Unit tests

Code coverage information

Integration tests

Details about the test cases and coverage

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes/no
Ran FindSecurityBugs plugin and verified report? yes/no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes/no

Samples

Provide high-level details about the samples related to this feature

Related PRs

List any other related PRs

Migrations (if applicable)

Describe migration steps and platforms on which migration has been tested

Test environment

List all JDK versions, operating systems, databases, and browser/versions on which this feature/fix was tested

Learning

Describe the research phase and any blog posts, patterns, libraries, or add-ons you used to solve the problem.

@Mariangela can we please get this merged ASAP. This is a blocker for the M3 release which is scheduled for this week.


Handle long IPv6 extensions properly

If we receive a network packet that has long IPv6 extension, then the upper layer protocol headers might get split between net_buf fragments. This means that we cannot blindly cast a protocol header struct to memory as that would cause invalid memory access. So if this happens, we need to read the header parameters individually. By default, the code checks if the headers are inside a fragment (which is the case 99% of the time) and does cast by default, and only read the protocol headers one by one if needed.

Rebased because of conflicts with merged PR#672

As a general epigraph, we're in the era of "huge" networking changes. Even https://github.com/zephyrproject-rtos/zephyr/pull/656, which is just a fix to previous feature patch, is "huge". This patch is also huge, I gave few comments reviewing few first commits of it, but would like raise some general issues.
So, first of all, the fact that there're such patches means that Zephyr IP stack matures. But it's hard to refrain from a question: "Aren't we ready yet to switch to contiguous buffers instead of fragments?" Well, suppose no ;-).
Then:

By default, the code checks if the headers are inside a fragment (which is the case 99% of the time) and does cast by default, and only read the protocol headers one by one if needed.

But why? What requirement calls for such an implementation? The only one I can imagine is optimization for speed. But do we have such requirement? I'd imagine we should optimize for code size (and really should, from Z version to version sample sizes grow considerably). But the biggest problem is two separate code paths which need testing. The fact that one of them happens in 1% only worsens the matter, meaning that unless there're full-coverage unit tests, that path can easily regress.
Note that I don't say "drop the fast path". It would be a hard choice to make, but maybe it's the right choice. Otherwise, I'd really say that this patch should be optimized for understandability, and the need for good network testing raises in priority from "major" to "critical".
Examples of things to improve:

Names like net_check_header() - how one would imagine this checks whether header fits in a (first?) fragment?
Fast and slow code paths in each function should have comments telling that this is fast path because ... , and this is slow path because .... Perhaps more comments, e.g. I gave an inline comment to a function which copies data on slow path and doesn't do anything on fast path. Why? Was data already written where needed? Please add comment then.

As a general epigraph, we're in the era of "huge" networking changes. Even #656, which is just a fix to previous feature patch, is "huge". This patch is also huge, I gave few comments reviewing few first commits of it, but would like raise some general issues.

It depends what you consider huge here, there are certainly lot of lines changed. Is it a bad thing if we fix things here?

So, first of all, the fact that there're such patches means that Zephyr IP stack matures. But it's hard to refrain from a question: "Aren't we ready yet to switch to contiguous buffers instead of fragments?" Well, suppose no ;-).

Well, if we want to have a low resource target devices that have as little as 32kb ram, then we cannot really use cont. buffers.

Then:
By default, the code checks if the headers are inside a fragment (which is the case 99% of the time) and does cast by default, and only read the protocol headers one by one if needed.

But why? What requirement calls for such an implementation? The only one I can imagine is optimization for speed. But do we have such requirement? I'd imagine we should optimize for code size (and really should, from Z version to version sample sizes grow considerably). But the biggest problem is two separate code paths which need testing. The fact that one of them happens in 1% only worsens the matter, meaning that unless there're full-coverage unit tests, that path can easily regress.

I do not really follow you here, are you against this patch?

Note that I don't say "drop the fast path". It would be a hard choice to make, but maybe it's the right choice. Otherwise, I'd really say that this patch should be optimized for understandability, and the need for good network testing raises in priority from "major" to "critical".
Examples of things to improve:
Names like net_check_header() - how one would imagine this checks whether header fits in a (first?) fragment?
Fast and slow code paths in each function should have comments telling that this is fast path because ... , and this is slow path because .... Perhaps more comments, e.g. I gave an inline comment to a function which copies data on slow path and doesn't do anything on fast path. Why? Was data already written where needed? Please add comment then.

More comments can be added. I will do that in next version.

New version uploaded which renames functions, removed first patch as it was useless and add more comments and documentation.

Sounds good to merge for a Friday

Heh, indeed good patch for a Friday. I have been testing this quite a lot so it should be ok thou.

So, per above, while this merged, IMHO it's still useful to discuss issues raised above, or at least I'd like to explain my concerns.

It depends what you consider huge here, there are certainly lot of lines changed. Is it a bad thing if we fix things here?

It's definitely good idea to fix things. But while in 20-line change is easy to review, and easy to get idea what ideas/requirements went into, which (much) larger patches, it's not easy to review them thoroughly, nor always easy to understand why they made like they are. That's why it's important to discuss bigger changes, and that's exactly what I'm trying to do.

I do not really follow you here, are you against this patch?

No, how one can be against a change which fixes a real problem? However, per above, I'm trying to discuss it to understand it better why it's the way it is - by showing other alternatives, and expressing concern with the way the patch does it. That doesn't mean I'm "against" the patch, or automatically think that another alternative is better, but I'd really appreciate your comments why you chose to implement it like that, especially as the maintainer, so your choice set the general design of the IP stack.
Thanks for adding more code comments!

All of net_udp_set_chksum(), net_icmpv4_set_chksum() and net_icmpv6_set_chksum() are always called with (pkt, pkt->frags) arguments. Is there a usecase for having these args separate, instead of just passing pkt?

But how to explain the fact that if ICMP header gets split between fragments, the we diligently copy values from input ICMP header hdr into packet (below), while if it fits, we don't do anything?

Well, I told that reviewing large patches is complicated ;-). Now that I peered enough time into it, I got it. The idea is that funcs like net_get_hdr() are passed with a pointer to a header structure which must be allocated (naturally on the stack) by a caller. But it's filled in optionally, only if needed. And these functions return pointer to either such filled in structure if that was needed, or directly inside packet.
Cool, that makes very good sense, and about the best way this can be done. The only 2 concerns is that I found a place (well, 2 for IPv4 vs IPv6) where return value of such func isn't used as expected, and another concern is growing stack usage, so we might need to optimize that later by reading individual fields directly from pkt (well, it's already done like that in quite a few places in this patch).
Thanks!


Add Sublime Text 2 information to README.rst

This information is not important for the main README.


[Bug]: yarn build failed for Teams Chef Bot sample

Language
Javascript/Typescript
Version
latest
Description
When executing the yarn build for Teams Chef Bot sample, it fails with unresolved dependency.
I expect I could do this from a specific sample, not from the root folder.

Reproduction Steps
1. Clone the teams-ai library
2. cd to the teams chef sample
3. yarn install
4. yarn build

Inside the sample directory, no yarn build is necessary. yarn build should only be run in the js directory when trying to create a local build of the teams-ai package to use with the sample.

this is duplicate of #1405

Inside the sample directory, no yarn build is necessary. yarn build should only be run in the js directory when trying to create a local build of the teams-ai package to use with the sample.

@therealjohn, how about provision/deploy to Azure? I think we need to run yarn install && yarn build in sample folder. see #1428

Closing this as duplicate. @dylanw-oss I have a meeting scheduled with therealjohn to discuss the above, so in case he doesn't get to a reply I will get back to you.


Transport and binding agnostics

It would be nice to have an agnostic interface for using mangos with different transports and binding.
Have you all seen the multi-formats library from the same organisation that is doing IPFS ?
The reason i bring it up is because they have a agnostic golang library that can use different transports and bindings. Its also well used.
Main web site:
https://protocol.ai/projects/
The 2  projects within the org i want to bring up:
https://protocol.ai/projects/#Libp2p
https://protocol.ai/projects/#Multiformats
Code:
https://github.com/libp2p
https://github.com/multiformats
https://github.com/multiformats/multicodec

Related:
https://github.com/whyrusleeping?tab=repositories

is getting SPDY integrated

https://github.com/marten-seemann/libp2p-quic-transport

Is getting QUIC integrated

I'm not sure how such an "agnostic" thing would work at all -- mangos clients and servers need to know how to reach each other, and that means that they have to agree which protocol they are going to use, and the client needs to know how to reach the server.  (E.g. what port it is listening on, etc.) . This stuff is baked in to the mangos/nanomsg URL.
You could build some sort of hybrid transport that makes use of a bunch of different underlying protocols (the clients and server would still need to agree somehow), and offer that as a new transport type in mangos.  I welcome such experimentation, even if I'm not particularly bullish on it myself.
Adding new transports to mangos is super easy -- at least for transports that present a connection based paradigm.  So for example, adding kcp should only take a day or so.  (Probably only a couple of hours.)  The transport interface is quite nice and pluggable; and indeed this is one area where I had hoped that others would find that they could contribute new stuff.
Sadly adding new transports to nanomsg (not mangos) is quite a lot more challenging.  I'm working on a new library (libnng) that should address that in C, and should be lots easier to create new transports for.
Stay tuned on that front.

Would not go-kit be a good option for transport agnostics ? I have used it specifically for that aim.
It's 100% golang too which is important.
Adding kcr would be very nice too for sure

Ok, I'm closing this issue as we're not going to refactor this project around go-kit or anything like that.   If folks want to ask for specific transports (e.g. kcp), I'm happy for those issues to be filed and addressed as they come up.


Upgrade vite plugin to latest

Latest Laravel installer uses Vite v6 which requires v5 of the vite plugin to be used.

Thank you, @csoutham.


[5.3] Resolve the current path by default for the LengthAwarePaginator

If no path provided to the paginator we'll resolve it from the request by default.
In reference to: https://github.com/laravel/framework/issues/15562

Looks like tests are failing here

Test need updating. :)

Just a few things, I think resolveCurrentPath should always be called with the user-supplied path, or default one.
    /**
     * Resolve the current request path or return the default value.
     *
     * @param  string  $default
     * @return string
     */
    public static function resolveCurrentPath($default = '/')
    {
        if (isset(static::$currentPathResolver)) {
            return call_user_func(static::$currentPathResolver);
        }

        return $default != '/' ? rtrim($default, '/') : $default;
    }
``

Then it can become:

```php
        $this->path = $this->resolveCurrentPath($this->path);

Also the same needs to happen to Paginator.php

Can also then remove supplying the path from the query builder paginate. Paginator::resolveCurrentPath() from Database\Eloquent\Builder

$this->resolveCurrentPath($this->path) will always return the resolved path and neglect user provided one since there's always a resolver added by the pagination service provider.
For the paginator change I think yes it needs to be changed as well.

Maybe it could become:
    /**
     * Resolve the current request path or return the default value.
     *
     * @param  string|null  $default
     * @return string
     */
    public static function resolveCurrentPath($default = null)
    {
        if (is_null($default) && isset(static::$currentPathResolver)) {
            return call_user_func(static::$currentPathResolver);
        }

        if (is_null($default)) {
            $default = '/';
        }

        return $default != '/' ? rtrim($default, '/') : $default;
    }

That way the custom resolver is only called if a path wasn't explicitly supplied.

$default = '/';`` maybe should be $default = $this->page``` but thought that looked a bit weird.

@garygreen that might be a breaking change :)

@themsaid yeah it maybe, it's nice though 😄
Your current version has a slightly different behavouir for / at the moment. Imo it should be:
$this->path = is_null($this->path) ?
    $this->resolveCurrentPath() :
    ($this->path != '/' ? rtrim($this->path, '/') : $this->path);

Hmm no forget that, your version does make sense. Though what if you wanted to force it to use / without calling the custom resolver? At the moment not possible...?

This is really a breaking change since now you can no longer pass / explicitly. @garygreen i suggest just manually passing in the path you want in the options to the paginator. If needed we can update the documentation to make this clearer.

It is breaking yeah so should go in 5.4. The paginator is very inconsistent with the paths at the moment imo. You shouldn't need to specify the path resolver, it should call internally itself if no path was given.


Versioning does run in development

The documentation for versioning states that:

Versioning is only performed when running in production mode. (ie with NODE_ENV=production)

However, when I run npm run dev (expands to node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules), it gives me versioned files.
Additionally, when I look at the code in this repository, I don't see anywhere in the versioning code that checks what the environment is.
Here is the webpack.mix.js:
const { mix } = require('laravel-mix');

mix
	.js('resources/assets/js/app.js', 'js')
	.extract([
		'jquery',
		'bootstrap-sass',
		'vue',
		'ladda'
	])
	.sass('resources/assets/sass/app.scss', 'css')
	.version();

if (mix.inProduction) {
	mix.disableNotifications();
}

I see that was removed from the docs since I wrote this (but before I hit submit on it).


MIDI Control Change messages with MSB and LSB parts

There is a type of MIDI Control Change messages, which is split into two MSB and LSB carrying message. It has a bigger range than a normal one.
Examples:

Name
1st byte
2nd byte
3rd byte

CC, channel 3, modulation wheel msb
0xB2 / 178
0x01 / 1
0x40 / 64

CC, channel 3, modulation wheel lsb
0xB2 / 178
0x21 / 33
0x00 / 00

TO-DO:

[ ] Find a way to determine if a MIDI message is split to MSB and LSB parts
[ ] Read more ( 1, 2 ) about RPNs, check if those are related to the issue

While I was reading a Table 2 or Expanded MIDI 1.0 Messages List, I've noticed that my understanding of CC messages was incorrect: "2nd byte" and "3rd byte" weren't recorded as "instrument" and "value", instead, they both were recorded as "see Table 3".
Table 3, or "MIDI 1.0 Control Change Messages (Data Bytes)" tells a story. There are MSB and LSB values, and those aren't written in an order I expect: parameter's lower byte and parameter's higher byte. When playing with VMPK knobs, I was receiving an instrument number and some value byte, which clearly were not MSB and LSB, so either I trusted its implementation and did a mistake, or something is very wrong with Alsa. And I hope both are ok and I am wrong.
Anyway, I see this order of knobs for a "Table 3":

0 - 31 - Knob MSBs for some knobs, most of which have assigned names
32 - 63 - Knob LSBs for some other knobs, most of which have assigned names matching MSB ones
64 - damper pedal on / off
65 - portamento on / off
66 - sostenuto on / off
67 - soft pedal on / off
68 - Legato Footswitch
69 - hold 2, and I don't know if it's different from damper or from sostenuto
70 - 127 - stuff I don't understand

"Table 3" also has a very encouraging message:

WARNING! Details about implementing these messages can dramatically impact compatibility with other products. We strongly recommend consulting the official MMA Detailed MIDI Specification for additional information.

So, I download the document named "The Complete MIDI 1.0 Detailed Specification" and prepare to be surprised again. The nice thing is that I am not surprised by it, it makes sense.

0 - 31 = MSB of most continuous Controller Data
32 - 63 = LSB for controllers 0 through 31
64 - 95 = Additional single-byte controllers
More stuff

And there's even more stuff after. Like this comment:

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted.

I wonder if it means "VMPK has a correct, maybe a bit limited implementation", or "you don't understand anything". Probably both.
Moreover, how do I know there's MSB and LSB for a knob? Do I start with LSB and "trigger" an event with "MSB"?

While I was reading a Table 2 or Expanded MIDI 1.0 Messages List, I've noticed that my understanding of CC messages was incorrect: "2nd byte" and "3rd byte" weren't recorded as "instrument" and "value", instead, they both were recorded as "see Table 3".
Table 3, or "MIDI 1.0 Control Change Messages (Data Bytes)" tells a story. There are MSB and LSB values, and those aren't written in an order I expect: parameter's lower byte and parameter's higher byte. When playing with VMPK knobs, I was receiving an instrument number and some value byte, which clearly were not MSB and LSB, so either I trusted its implementation and did a mistake, or something is very wrong with Alsa. And I hope both are ok and I am wrong.
Anyway, I see this order of knobs for a "Table 3":

0 - 31 - Knob MSBs for some knobs, most of which have assigned names
32 - 63 - Knob LSBs for some other knobs, most of which have assigned names matching MSB ones
64 - damper pedal on / off
65 - portamento on / off
66 - sostenuto on / off
67 - soft pedal on / off
68 - Legato Footswitch
69 - hold 2, and I don't know if it's different from damper or from sostenuto
70 - 127 - stuff I don't understand

"Table 3" also has a very encouraging message:

WARNING! Details about implementing these messages can dramatically impact compatibility with other products. We strongly recommend consulting the official MMA Detailed MIDI Specification for additional information.

So, I download the document named "The Complete MIDI 1.0 Detailed Specification" and prepare to be surprised again. The nice thing is that I am not surprised by it, it makes sense.

0 - 31 = MSB of most continuous Controller Data
32 - 63 = LSB for controllers 0 through 31
64 - 95 = Additional single-byte controllers
More stuff

And there's even more stuff after. Like this comment:

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted.

I wonder if it means "VMPK has a correct, maybe a bit limited implementation", or "you don't understand anything". Probably both.
Moreover, how do I know there's MSB and LSB for a knob? Do I start with LSB and "trigger" an event with "MSB"?


New synonyms to Consider alterations of ‘enteral tube feed’, ‘total parenteral nutrition’ and ‘gavage’ to improve the accuracy of word choice

Consider alterations of ‘enteral tube feed’, ‘total parenteral nutrition’ and ‘gavage’ to improve the accuracy of word choice

@matentzn and @pnrobinson ,  @laurenechan has made some good observations about changing term labels and moving the labels to synonyms.  Do we need to worry about the obsoletion of term labels yet?

IMHO we should never ever worry about obsoletion of labels. This is total overkill for vocabulary maintenance; that is why we have identifiers. We use obsoletion only in cases where we want to discourage the use of a word altogether (dwarfism case in HP). So my two cents is: go ahead and change if you maintain the original labels as synonyms! :)

Definitelt agree! Please just change the primary label and add the original primary label as an exact synonym. Nothing else is required!

I've made a few changes to reflect what I find to be more accurate terms, PR has been made.
Regarding total parenteral nutrition (TPN), I still find this to be a somewhat inaccurate term choice. TPN includes full and complete nutrition provided intravenously, whereas parenteral nutrition can be provided as specific macronutrients (i.e. just carbs and protein) or can be providing only part of the nutrition required (i.e. 50% of needs).
Without getting into the weeds, I think it would be more accurate to reorganize this as:
superclass: nutrition intervention
class: parenteral nutrition
subclasses: total parenteral nutrition (same NCIT term as we have now) and parenteral therapeutic nutrition supplementation (another NCIT term, not well defined currently) or some other variety indicating only partial needs provided through IV.
What do you all think on this? @pnrobinson @LCCarmody

Just to clarify, you would change 'enteral tube feed' to 'parenteral nutrition'?  I support that based on what you are saying.
I am not sure about 'parenteral therapeutic nutrition supplementation'.  Is that what it is typically called?  If it is just NCIT that has a term, then I might suggest 'parenteral supplementation' or 'parenteral nutrition supplementation' as the label with 'parenteral therapeutic nutrition supplementation' as an exact synonym and cross reference to NCIT.
I do not think we want to go deeper than that.

To clarify, I would be changing 'total parenteral nutrition' --> 'parenteral nutrition' with 'total parenteral nutrition' as a child term. 'Enteral tube feed' (or enteral nutrition as rec in the PR) would stay a separate term as they are separate feeding modalities. I think this was reflected in the PR, but if that doesn't seem clear I can make alterations.
Typically I'd call it 'partial parenteral nutrition' or 'supplemental parenteral nutrition', but yes just some term to provide differentiation as to how much is provided (full or partial of needs).

I think the hierarchy to what you are saying is fine, but it depends if you are physically doing it the way that you just described.   I have an issue with changing the label to mean something else and then recreating the same term as a child with a new MAXO number.
Even though I don't think there are (any?) users yet, theoretically it could mess up someone who is trying to find the term MAXO_0000114 total parenteral nutrition and find now it is 'parenteral nutrition' and the term they are actually looking for is a different number.
Looking at the pull request (and admittedly, I am not great at PR), i think this is what you are doing.   Could you make the new term the 'parenteral nutrition' and move the MAXO_0000114 as a child?  Do you know how to make new terms? Have a range of MAXO numbers?  We can have a call this afternoon if not.

I agree -- one should not change the meaning of an existing term by giving it a new label --

Ok, that makes total sense! From the sense of the PR that has been put in (branch: lec_6.19_2), this does not include any changes to the class status or label of total parenteral nutrition at this time other than adding synonyms.
I think creation of a new superclass (and new number etc) definitely makes the most sense. I think I know how to make new terms, but do not have a range of numbers yet. Can get on a call this afternoon if that is easiest!


Cretae jenkins job

job needs to be created on https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/VS Code/

job created https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/vscode-datavirt_release/ (to be tested)

job created and green for a master build https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/VS Code/job/vscode-datavirt_release/2/
It is providing snapshots build to https://download.jboss.org/jbosstools/vscode/snapshots/vscode-datavirt/
to be validated when there will be a release but it is very similar to all others VS Code extensions jobs so should be fine.
Note: Data Virt committers doesn't have the rights to approve the release step.


Replace Meow with Commander and implement CLI commands

Replace Meow with Commander as Commander is much more powerful.
Implement (most) new CLI commands as listed in our HackMD document. The new commands call stacker methods.
Add getCommitByHash methods to both Stacker and SourceControl.

Please merge after you've reviewed it :)
Test Plan
yarn cli i = the old yarn cli

yarn cli shows help

yarn cli r ... tries to run a rebase but fails as expected because ConcreteStacker is incomplete.

LGTM!


How can I change the background color opacity?

I want to make the gray background color behind the image a bit lighter... is there a css class I can edit for the background?
Thanks! Neta L.

Never mind! found it: .mfp-ready.mfp-bg


fix: remove redundant log and output correct file length

Signed-off-by: lowzj<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
The dfget will output twice result message and the downloaded file's length is not correct.
--2018-12-26 19:51:37--  https://www.taobao.com
dfget version:0.3.0
workspace:/Users/zj/.small-dragonfly sign:51733-1545825097.015
client:<IP_ADDRESS> connected to node:<IP_ADDRESS>
start download by dragonfly
download SUCCESS(0) cost:0.052s length:-1 reason:0
download SUCCESS(0) cost:0.052s length:-1 reason:0

Ⅱ. Does this pull request fix one issue?

Codecov Report

Merging #280 into master will decrease coverage by 0.18%.
The diff coverage is 14.28%.

@@            Coverage Diff             @@
##           master     #280      +/-   ##
==========================================
- Coverage   61.71%   61.52%   -0.19%
==========================================
  Files          30       30
  Lines        1669     1674       +5
==========================================
  Hits         1030     1030
- Misses        607      611       +4
- Partials       32       33       +1

Impacted Files
Coverage Δ

cmd/dfget/app/root.go
70.24% <ø> (+0.57%)
:arrow_up:

dfget/core/downloader/p2p_downloader.go
0% <0%> (ø)
:arrow_up:

dfget/core/core.go
66.23% <0%> (-1.32%)
:arrow_down:

dfget/config/config.go
91.42% <33.33%> (-1.78%)
:arrow_down:

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 8b18c01...e023395. Read the comment docs.

Through offline communication, the value of ctx.RV.FileLength returned by supernode. However, Supernode gets the value from HTTP header of the source file and returns -1 if the value does not exist.  So we get the incorrect fileLength here.
In addition, if the supernode returns without downloading the file, it will not be able to get this value, So we should double check that fileLength is correct by dfget.

LGTM.


Email for students from Vlerick Business School

email format<EMAIL_ADDRESS>

Hello, could you please consider this pull request? I am awaiting access to some student products


Return default prediction when horoskopy are down

Time to time maintainers of horoskopy.cz do things like a failover location test. During this period horoskopycli usually does not work. It would be nice to return some kind of default prediction.
$ horoskopycli vahy
2024/06/25 12:07:49 Could not find contant element

Could you please make it print ASCII version of the "this is fine" meme? :pray:

Sounds good! I guess we can use the meme from here - https://github.com/NaAbAsD/this_is_fine
Labeling the issue as good first issue. Might to good for newcomers.

here you go https://github.com/kozaktomas/horoskopycli/pull/3


Translation in single file

Hey first of all this plugin looks awesome!
My project contains all translations in a single yaml file instead of yaml files divided by language like this:
language_nl:
  tenants:
    styleguide: example

language_en:
  tenants:
    styleguide: example

Right now I don't think there is a way for this plugin to recognize different languages in one single file and my question is: am i missing something or is this not possible in this plugin?

No, unfortunately this is not possible right now.
I recommend to use at least one file per language.
Currently I don't see the need to implement this functionality.
Therefore I put this ticket on hold until further notice.

Okay understandable! Thanks for the quick answer anyway!


UHI Protocol Provider Platform Confirm Example Value is wrong

UHI Protocol Provider Platform Confirm API Example value is not correct,  schema value is wrongly used here instead of example value.
You have to replace Schema value with real example value similar to Search , Select or Status API examples.
Example value and Schema value can not be same, see red circle part of image.
In Swagger editor please review line no. 428 to 425
DHP also has the same issue in their open API specification.

Thanks @prakash2910 for your observations. We are in a process to fix this issue. Will update once done.


Vec::pop() on Slab::remove() when possible

solves #38

Thanks for the PR. Could you clarify how using pop addresses #38? As I understand, Vec::pop does not free memory?

Yes, but it actually shortens the vector so it can be shrink_to_fitted.
And I found just now that it's also needed to pop out all trailing Vacants. I'll fix it in this PR soon.

Removing other vacant entries would make remove() frequently take O(n) time, because the previous entry in the linked list that the vacant entries form must be updated and the index of that entry is not known.
With #62 shrink_to_fit() now pops trailing vacant entries on its own, so I don't think also doing that in remove() is useful.


System error when importing CausalPy

After installing the package using the shell, when I try to import the package in a .ipynb but I get the message "SystemError: initialization of _internal failed without raising an exception"
Can you help pointing out the root cause and how to fix it? Thanks!

Hi @kloskas. Thanks for this. I've not experienced that error, so I don't have any immediate solution that comes to mind. Because the description is quite brief, can you say a bit more? What version are you downloading? Presumably you pip installed it? To check if it's a CausalPy issue, does this error only happen when importing CausalPy but not other packages? Are you on Windows, Mac, or Linux? Is this being tried in a fresh environment?

Apologies, sure I can provide more detail:
1.- pip installed in prompt, the current version (didn't specify it says CausalPy-0.1.1)
2.- OS windows 10 enterprise v. 22H2 x64
3.- error only happens with CausalPy (other packages installed)
4.- local environment, not fresh
5.- tried to reinstall again
Just wanted to understand if it was something unexpected (seems it is), before cleaning everything and having to reinstall conda + packages (my last option, if there's nothing else)

I had to reinstall the environment. Now it works fine.


Feature/3176 json

Submission Checklist

[x] Run unit tests: ./runTests.py src/test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary
Add callback writer to output JSON data.
Intended Effect
Allow structured outputs in JSON format, per design-docs spec https://github.com/stan-dev/design-docs/blob/master/designs/0032-stan-output-formats.md
How to Verify
Unit tests
Side Effects
None
Documentation
N/A
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):  Coumbia University
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

OK, ready for re-review

ready for re-re-review

Actually @mitzimorris and @WardBrian one last thing, how should NA and infinite values get handled here? I'm unfamiliar with how json should handle these.

We print them such that the JSON parser we use can read them back in. This involves using some non-standard atoms:

Value
""JSON""

Not-a-number
NaN

Infinity
Inf

Negative infinity
-Inf

OK to merge?

I think so, @SteveBronder?

Yep good to merge!


Week 5 Review Ticket

James' Fastpage
James' Webpage

My JavaScript Table
My New Subpage and Notebook-JavaScript

Backend developer roles.   Made Cards on Flask page sharing classes.
JavaScript Kernel did a new column and shared through page.  Shared JS  had some problems with some style and links.
2.7

Had all the parts.
2.7

Contained everything that was needed for you to talk about about
2.7

2.7+ customized flask thoroughly through adding buttons that link to places and implemented Javascript in Jupyter notebooks. Along with team information.

Had everything you needed 2.7+


revert PR 5362

PR https://github.com/Itseez/opencv/pull/5362 tries to fix issues with the cascade classifier interface, but by doing so it broke down the extended functionality using the stage scores and weights. Therefore this needs to be reverted and better investigated before suggesting another fix.
@Dikay900 here you go!
@alalek or @vpisarev I suggest to merge this rather fast, so that problems around this issue can all be closed for now.
Related issue: https://github.com/Itseez/opencv/issues/6022

:+1:

:+1:

Thanks!


Use pure-Java RocksDB reader in Spark metadata client

DataBricks supplies an ancient version of rocksdbjni that does not export pure SSTable operations.  So we cannot use it.  Because rocksdbjni is a JNI library, it cannot be shaded (renamed) without major changes and recompilation and distribution and non-trivial fork chasing.  Instead, write our own RocksDB format parser, and use that in the client.
The majority of the PR is the new RocksDB format reader.
Please do not pull until we are

Sure that it works;
Know that it works with 2-level RocksDB index files, or that lakefs can never generate those.
Confident that we can test it against future versions that lakefs may generate.

Fixes #1847 :-) :smiley: :turtle: :skull:

Works on EMR 3.0.1: I set one up, configured lakeFS access and secret keys and endpoint, and then ran:
[ec2-user@ip-10-20-3-61 ~]$ spark-shell --jars s3://treeverse-ariels-test-us/clients/lakefs-spark-client-301-assembly-0.1.5.jar --master local
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
21/08/12 13:52:01 WARN Utils: Service 'SparkUI' could not bind on port 4040. Attempting port 4041.
21/08/12 13:52:01 WARN Utils: Service 'SparkUI' could not bind on port 4041. Attempting port 4042.
Spark context Web UI available at http://ip-10-20-3-61.ec2.internal:4042
Spark context available as 'sc' (master = local, app id = local-1628776321129).
Spark session available as 'spark'.
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 3.0.1-amzn-0
      /_/

Using Scala version 2.12.10 (OpenJDK 64-Bit Server VM, Java 1.8.0_272)
Type in expressions to have them evaluated.
Type :help for more information.

scala> import io.treeverse.clients.LakeFSContext; var df = LakeFSContext.newDF(spark, "foo", "main"); df.show
21/08/12 13:52:06 WARN SharedState: Not allowing to set spark.sql.warehouse.dir or hive.metastore.warehouse.dir in SparkSession's options, it should be set statically for cross-session usages
+----------+--------------------+--------------------+-------------------+----+
|       key|             address|                etag|      last_modified|size|
+----------+--------------------+--------------------+-------------------+----+
|   test1/1|4705d4f1817e4dfeb...|27bc8de95026209eb...|2021-08-08 10:54:50|   9|
|  test1/10|bce2f70445fa49cca...|0d81641648c6f5691...|2021-08-08 10:54:50|  10|
| test1/100|c5ecce57863445308...|68d89a66262a84844...|2021-08-08 10:54:49|  11|
|test1/1000|64be2ce234b14572a...|fff0b8896e1fd8857...|2021-08-08 10:54:58|  12|
| test1/101|9beb8ae62d274836a...|5315e6fdbe3a80411...|2021-08-08 10:54:49|  11|
| test1/102|46a8b031f815469bb...|f77ee7c1f79a966c8...|2021-08-08 10:54:49|  11|
| test1/103|a8d0d56a824d44a6b...|6ce5697f4a19aeb01...|2021-08-08 10:54:49|  11|
| test1/104|c3b90677a8de49508...|022011cc176128a49...|2021-08-08 10:54:49|  11|
| test1/105|ac585b85a63740d1b...|d844f89ac9583dfa3...|2021-08-08 10:54:49|  11|
| test1/106|c25bb64c981a47a4b...|3f6eef0fe1b5ed359...|2021-08-08 10:54:49|  11|
| test1/107|3fca29fc99b943c39...|a3aea4693761dcbeb...|2021-08-08 10:54:49|  11|
| test1/108|0d4acaef2b744f23b...|8a708fcfafc279d9b...|2021-08-08 10:54:49|  11|
| test1/109|4241c0bf729848099...|f0a0eec70602862d7...|2021-08-08 10:54:48|  11|
|  test1/11|49601c95f77b46c8a...|1dca97e4b449db7cc...|2021-08-08 10:54:48|  10|
| test1/110|7c0c82760e4840278...|bda8c8c92cd03cae0...|2021-08-08 10:54:49|  11|
| test1/111|33fc6bfe5cf04fcdb...|6d33f2e259a993eb3...|2021-08-08 10:54:49|  11|
| test1/112|c1f2cd7c94d447e18...|e1cd9fbc2e5503957...|2021-08-08 10:54:49|  11|
| test1/113|690b8d789fe041df9...|de164babfe6ec7fef...|2021-08-08 10:54:50|  11|
| test1/114|abb3ff95f34b475c8...|2688de85c7d6e21a2...|2021-08-08 10:54:50|  11|
| test1/115|932d16009a5448719...|2dcd8657d41ac8e45...|2021-08-08 10:54:49|  11|
+----------+--------------------+--------------------+-------------------+----+
only showing top 20 rows

import io.treeverse.clients.LakeFSContext
df: org.apache.spark.sql.DataFrame = [key: string, address: string ... 3 more fields]

:-)

Also works on emr-5.33.0, with Spark 2.4.7.

Tested on big metadata on EMR with the old version (that uses rocksdbjni), SELECT SUM(size)... returns an identical value -- so we are not losing any rows.
Re-merging #2347 (didn't work out, not sure what happened), and pulling.

Re-merging #2347 (didn't work out, not sure what happened), and pulling.

Ah...

@arielshaqed arielshaqed force-pushed the feature/1847-add-jpebble branch from ee8fddf to 63540a0 6 days ago

was the culprit.  The merge from ee8fddf just moved the tip (it was based off of this branch),  so rebasing removed it.  So redoing the merge makes sense.

Pulling once tests...