Generate bool accessors for single-bit fields

This makes using such fields significantly more ergonomic, as
previously they would have been u8s, leading to unnecessary
conversion and silent truncation in downstream code.
The bool writers are never unsafe because it is meaningless
to have a writable field that only admits one (or worse, zero)
valid values.

Oh, and as a minor but sweet side effect, this change makes documentation much easier to read.

Thanks for the PR, @whitequark.
I don't think I'm going to accept this PR as it is since it seems to throw away enumeratedValues information if the field has size 1 bit. This results in a loss of readability. Something like this:
// nrf51.svd
timer0.mode.write(|w| w.mode().counter()); // or mode().timer()

would become
timer0.mode.write(|w| w.mode(false));  // false mode?

if I'm reading this correctly.
I'd be more willing if the enumeratedValues information was preserved.
Also note that the code generation is designed such that adding enumeratedValues information to a SVD file and then running it again through svd2rust expands the previous API in a backward compatible way and I'd like to preserve that property.

:umbrella: The latest upstream changes (presumably c758eb7) made this pull request unmergeable. Please resolve the merge conflicts.

I'd be more willing if the enumeratedValues information was preserved.

I have completely missed this case, thanks.

Also note that the code generation is designed such that adding enumeratedValues information to a SVD file and then running it again through svd2rust expands the previous API in a backward compatible way and I'd like to preserve that property.

I have not previously realized that this is a goal. I agree that it seems clearly desirable, and while it would not be a deal breaker for me personally, I can certainly understand if it is for you. As such, let's change the goals a bit.
For this PR, I will, much more modestly, change the bits() -> u8 accessor to bit() -> bool. This would fix a large part of the ergonomics issue that prompted me to write this PR.
After that, I suggest rethinking the approach to nesting in the generated code a bit. The existing code generator makes the documentation very hard to use, particularly when many of your fields are single-bit, many of our other fields have no reserved bit patterns, and many of your registers only have one field (perhaps because all of the registers require 32-bit access even if the peripheral doesn't). In this case, writing code against the generated API becomes an endless maze of indirection that serves no purpose.
It is, indeed, nontrivial to rework the code so that later you can add more detail (fields and enumerated values). As a compromise between backwards compatibility and ergonomics, I suggest pulling the bits function out of the proxies, and not generating the proxies at all unless there's anything nested inside. So, if you don't have any <enumeratedValues>, you don't have the field proxies defined at all, and access the bits using periph.reg.read(|r| r.field_bits()) and periph.reg.write(|w| w.field_bits(0xa)); if you don't have any <fields> then you don't have the register proxy defined at all and access the bits using periph.read_reg() and periph.write_reg(), and if you have both <fields> and <enumeratedValues> then nothing changes in the API from the current situation at all.
I hope that this will cut down the majority of noise in the documentation, and make it much more convenient for casual use.

@japaric I have now updated this PR. An alternative approach to changing the name depending on the width would have been to call the accessor raw(), but I do not like it because it implies that the accessed value is somehow not fully representative of the underlying semantics, whereas talking about "the GPIOA enable bit" is very common.

We definitely need something like this in order to improve ergonomics of the common case.

Thanks for the changes @whitequark. This now looks good me. Could you update the crate level documentation (src/lib.rs - that's what shows up in docs.rs) to reflect the changes?
re: documentation being hard to navigate. I agree. When I designed the API I was assuming autocompletion would always be used to write code. So in my mind using the API should have looked like this:
peripheral.register.write(|w| w._)
                                |fieldA - enables / disables the timer
                                |fieldB - oneshot or contiguous
                                |fieldC - enables / disables interrupts
                                |(..)

// then
w.fieldA._
         | enabled() - enables the timer
         | disabled() - disables the timer

In practice, racer doesn't work that well when closures or type inference is involved.

@japaric done

@whitequark after looking at this again (after properly sleeping), I'm not fully convinced about all the changes here.

the bits -> bit change makes sense to me. It better reflects that field is
1-bit in size.

the u8 -> bool change feels like it reduces readability. From the documentation changes:

-//! i2c1.cr2.write(|w| unsafe { w.sadd0().bits(1).sadd1().bits(0b0011110) });
+//! i2c1.cr2.write(|w| unsafe { w.sadd0().bit(true).sadd1().bits(0b0011110) });

bit(1) would have been clearer, IMO: "Set this bit to 1". bit(true) doesn't immediately tells me that the bit is being set high. I have no way to tell from just the invocation if true actually maps to 0 under the hood. bit(1) also requires less typing.
I do agree that bool is better than u8 when it comes to constraining the input.
I think this would be even clearer if it used methods: sadd0().set() and sadd0().clear() (or set_low/set_high). Same with if i2c1.c2r.read().sadd0().is_high() (or is_set). This also deals with restricting the input.

the 'the bit method is never unsafe' change seems to have been reverted. Was that a change of heart? I thought that was one of the main motivations of this change (to reduce the unsafe noise).

Would love to hear others' opinions

I think this would be even clearer if it used methods: sadd0().set() and sadd0().clear() (or set_low/set_high). Same with if i2c1.c2r.read().sadd0().is_high() (or is_set). This also deals with restricting the input.

"Low" and "high" aren't applicable to bits, only signals, and in fact this would add ambiguity because a logical one could be represented by either low or high signal level. set and clear are fine, I've been thinking about these just today. I have no strong opinion on is_set other than it feels extraneous (it's purely an alias of bit() and I might never use it.
Regarding bit taking u8, I am wholly unconvinced. Currently, you choose the smallest width integer type that can fit the field--and I think this makes sense, fields with a size that's an integral number of octets are very common, and modeling them properly (i.e. such that with every legal input, no bits are lost during a write) is important. What my change does is merely extends this to work properly on fields of width 1.
The change of bit to take bool in particular is motivated by functions that don't merely set a bit to a known value but rather take an argument. Adding a as u8 in every such case is a major code smell, in my opinion. The inverse case is also quite troublesome: you could easily accidentally compare it with an u8 variable whose valid range is wider than [0;1], or you would have to manually narrow it when performing a match, etc. I think this is a clear improvement.

the 'the bit method is never unsafe' change seems to have been reverted. Was that a change of heart? I thought that was one of the main motivations of this change (to reduce the unsafe noise).

Somewhere in the process I've added the equivalent of this change to my SVD file generator and, it seems, then never noticed removing it when refactoring the svd2rust patch. I of course still think it's a major improvement in ergonomics and will add it back.

set and clear seem nice, +1 on that one.
Regarding the u8 vs bool, I think @whitequark has good reasoning there (I do feel the "less typing" argument, but with set and clear I think it's a non-issue).
Regarding safety, I think the method should definitely be safe.

Updated

Thanks for updating the PR @whitequark. I stil don't think that we should (over)use bool to represent bits. I think it would make more sense to use a enum Bit { Zero, One }. It has better readability, IMO:
// READ
// this PR: if the bit is ... what?
if peripheral.register.read().bitfield().bit() { .. }

// better: if the bit is one
if peripheral.register.read().bitfield().bit().is_one() { .. }
// or
if peripheral.register.read().bitfield().bit() == Bit::One { .. }

// with enumerated values (bitfield = mode)
if peripheral.register.read().mode().bit().is_one() { .. }
if peripheral.register.read().mode().bit() == Bit::One { .. }
if peripheral.register.read().mode().is_output() { .. }
// or
if peripheral.register.read().mode() == Mode::Output { .. }

// WRITE
// no enumeratedValues
peripheral.register.write(|w| w.bitfiled().set()); // or clear()
peripheral.register.write(|w| w.bitfiled().bit(Bit::One));

// with enumeratedValues
peripheral.register.write(|w| w.mode().set()); // or clear()
peripheral.register.write(|w| w.mode().bit(Bit::One));
peripheral.register.write(|w| w.mode().output()); // or input()
peripheral.register.write(|w| w.mode().variant(Mode::Output));

I stil don't think that we should (over)use bool to represent bits. I think it would make more sense to use a enum Bit { Zero, One }. It has better readability, IMO:

I think almost every example above is non-representative as they are missing the key motivation for having the .bit(x) accessor as opposed to .set()/.clear() accessors: to support code that receives the value from somewhere else. Consider something like the following:
#[derive(Ord)]
enum Mode { Active, LowPower, Sleep };

fn enable_clocks_for(mode: Mode) {
  clocks.uartclk.r0().bit(mode <= Active);
  clocks.uartclk.r1().bit(mode <= LowPower);
  //etc
}

My point is that the fact that it is a bit is an implementation detail, logically, it is a toggle. There's really no reason to newtype bool and then add useless conversion everywhere. Can you show any example where your bool newtype would prevent a bug from being added?
That said I think adding .is_set() and .is_clear() is a definite improvement in readability and I want it as well.

I would really discourage: Bit { Zero, One } over true, false. It does not give any more information and may in fact be misleading/harder to work with. I can't apply logical operators to Bit { Zero, One } without additional fiddling for example (for toggling, etc).
I agree that in the case of .bit() being able to feed boolean values has a lot of ergonomics in the generic case, and in the case where more information is available from an enumeratedValue type convention should dictate that the more descriptive type is used.

Consider something like the following:

IMO, that code looks like it has been optimized for writing rather than for reading. I would use match on the enum and set/clear personally.
OK. It seems fine to just use bool since you can also use {,is_}{clear,set} if you want to. I'll review this as it is. @whitequark you can send is_set / is_clear as a follow up PR.

IMO, that code looks like it has been optimized for writing rather than for reading. I would use match on the enum and set/clear personally.

Perhaps the choice of the example was not the best. But nevertheless I disagree on the underlying point, having to insert a match/conditional every time a bit could be either set or cleared indicating an on/off state would be completely unnecessary boilerplate. svd2rust is supposed to reduce that not add it.

The bit method on W could be simpler, I suppose, but it works OK.
    pub fn bit(self, value: bool) -> &'a mut W {
        const MASK: bool = true;
        const OFFSET: u8 = 19;
        self.w.bits &= !((MASK as u32) << OFFSET);
        self.w.bits |= ((value & MASK) as u32) << OFFSET;
        self.w
    }

@homunkulus r+

:pushpin: Commit 3405452 has been approved by japaric

:hourglass: Testing commit 3405452 with merge 0a1d8f6...

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


Test the admin dashboard

Refactor the code where needed in order to test :

[ ] that the dashboard link is sent, or not, depending on flag and on email
[ ] that the jwt encryption is well decoded at the other end (encrypt and decrypt, end to end test)

Actually there are some tests for this, but they are in createConfController. Move them to their own file with a corresponding name.


fix service type always equals zero issue - [closed]

In GitLab by @tmon546596046 on Mar 15, 2019, 06:01
Merges helm-bug -> dev
the service created by helm always has zero service type
this pr fix the issue

In GitLab by @wknet123 on Nov 13, 2019, 11:39
closed


Tween Leaves

Some general purpose utility leaves for behavior trees would be nice to have. I'm not sure how abstract they can be made given the limitations of Godot's editor(e.g. no support for Variant @export properties).
I think 1 leaf for each node property type that can be tweened would be useful? So, TweenVector3, TweenVector2, TweenInt etc.
Or you could maybe accomplish the same thing with a few Tween leafs for each primitive type in Godot:?
class_name TweenFloatProperty extends BTLeaf

@export var transition_type: Tween.TransitionType = Tween.TransitionType.TRANS_SINE
@export var ease_type: Tween.EaseType = Tween.EaseType.EASE_IN
@export var tween_property: String = "rotation:y"
@export var tween_value: float = 0.0
@export var duration: float = 2.0

var tween : Tween
func tick(actor: Node, _blackboard: Blackboard) -> Status:
	_init_tween(actor)
	if tween.is_running():
		return Status.RUNNING
	return Status.SUCCESS

func _init_tween(actor: Node):
	if tween == null:
		tween = get_tree().create_tween().bind_node(actor)
		tween.set_trans(transition_type)
		tween.set_ease(ease_type)
		tween.tween_property(actor, tween_property, tween_value, duration)

One Leaf for each value seems pretty overkill. You could probably export a Script resource that is responsible to create the tween. If you can come up with something, feel free to open a PR. I may look into it tomorrow and give it a try :)

@squk Would you mind checking out #28? I added it as one node. Are there any other features that might be useful for this Leaf? (Types, callback, tween method etc.)

LGTM! Much better than the impl I provided


Document Create Quick Filter action

@worksofliam Some of the existing pictures in object-browser.md, seem to be outdated or not consistent in terms of inline/right-click actions. I suppose it would be a good idea to update all of these? Possibly in a separate PR?

@SanjulaGanepola Separate PR, if you fancy it. Thanks!

@worksofliam Since this Create Quick Filter feature got merged in, we can merge this PR now.

@worksofliam @sebjulliand Curious about why this PR is still outstanding, since the code is in the latest release.

@SJLennon totally my bad. It'll happen when I'm back working next week.

@worksofliam Let me handle this small one - no problem...


Question regarding normalization

First off, thanks a lot for the implementation! Looking at the Librispeech dataset, I realize that the ground truth is in all caps, whereas model predictions (before fine-tuning) are mostly lower case. While this is not an issue for WER computation (since it involves normalization), lower and upper case texts get tokenized very differently, and I wonder if this hinders the model training process i.e. should the ground-truth text also be sent to lower-case before it is fed to the model for loss computation (and subsequent backprop).
I ask because in my own attempt to fine-tune on LibriSpeech, I notice that the WER jumps from ~5 at the beginning to 15-16 and then drops to 9 as training progresses, whereas the loss function converges smoothly. I wonder if this is an artifact arising from the model suddenty trying to learn to predict everything in all-caps?

Hi,
I agree, it makes more sense to feed the model uncapitalized text, since then it only has to learn to not capitalize words instead of having to capitalize everything. But also once the decoder gets the first token in capitalized form, it should continue that trend.
Regarding your attempt, the jump in WER seems quite substantial. I also sent the capitalized text to the model, but the WER hovered around 5%. You can see this from the training plot in my project.
It is quite possible that the culprit for this jump is the fact that the model has to learn to generate everything in capitalized form. One experiment I wanted to try, that I didn't do at the time of implementing this project, was to only train the decoder and head, or the last couple of layers of the decoder. If you are training the whole model, this might make the output unstable because you are also changing the encoder.
Also, keep in mind that the LibriSpeech data also doesn't contain punctuation, and you should consider adding it as a normalization step if you haven't already.
But still, this jump in WER does seem fishy. I would double check the code, potentially there is a problem with the normalization implementation since the loss is converging but the WER score gets worse.
Hope this helps, and if you have any other questions feel free to ask.
P.S.
One more thing I realized while implementing the project, the pretrained Whisper model seems to basically perform well enough already on the LibriSpeech dataset, so any more training could potentially cause instability. I was only able to get a 0.5% increase in performance when looking at the normalized text.

Thanks for the response!
Changing from capitalized to lower-case text leads to a much more stable learning curve (that somewhat matches your plots) and get the model to a WER slightly better than without fine-tuning (but only by a small percentage, as you mention). I should mention that I froze the encoder (as does the code in this repository currently, I think?)


Support Bazel

Bazel is a language-agnostic build system. My team has been using the system to build C++ programs in recent ICFP contests (2017, 2018, 2019). We'd like to use it in this year's contest as well.
However Bazel downloads some language toolchains during build for reproducibility. For example, on buliding Java programs, Bazel downloads OpenJDK of a fixed version. However README says there is no Internet access during build.
Could you give me guidance on how to proceed?

Can you create a base image with all necessary toolchains already downloaded? As suggested here.

Sure. I'm sending a PR.


epic(pano): posts page (home)

What is this epic about?
Posts page will allow us to see multiple posts in a list.
We want to have multiple posts live under /posts?filter= route.
We have 5 different filters => {
all: "hepsi", // this will be used for fetching newest posts
active: "en son yorumlananlar",
hot: "en fazla yorum almışlar",
liked: "beğendiklerim",
"my-posts": "başlıklarım",
}
An example: https://pano-dev.kamp.us/
apps/gql changes

TBD

apps/kampus/app/pano

Add a new page under apps/kampus/app/pano/posts/page.tsx

show list of posts

Related files/folders from deprecated pano
https://github.com/kamp-us/monorepo/blob/dev/deprecated/pano/app/routes/index.tsx
https://github.com/kamp-us/monorepo/tree/dev/deprecated/pano/app/routes/posts
Tasks for this epic
Posts

[ ] #552
[ ] #550
[ ] #567
[ ] #568
[ ] #569
[x] feat(pano): Create a Post sort filter mechanism regarding to filter queries

Comments

[ ] #513

Upvotes

[ ] #514
[ ] #554
[ ] #556

i’ll be working on this with Can as planned


New resources: Blocktrain, Embark, create-eth-app

add New resources: Blocktrain, Embark, create-eth-app

assigned to @pruthvirajjadhav1

closed by #193


Cinder: spdknvmf.py  nvmf_create_transport

It shouldn't just be RDMA, TCP should be added to the mix

Thank you for your contribution!
This GitHub repository is just a mirror of https://opendev.org/openstack/cinder, where development really happens. Pull requests proposed on GitHub are automatically closed.
If you are interested in pushing this code upstream, please note that OpenStack development uses Gerrit for change proposal and code review.
If you have never contributed to OpenStack before, please see:
https://docs.openstack.org/contributors/code-and-documentation/quick-start.html
Feel free to reach out to the First Contact SIG by sending an email to the openstack-discuss list with the tag '[First Contact]' in the subject line. To email the mailing list, you must first subscribe which can be done here:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss


Enable Travis CI integration

@sjfink Can we enable Travis CI integration with this repo? Among other things, this will annotate pull requests with the build status of the corresponding commits.

Travis CI is configured to schedule a build for every commit and pull request. We may want to limit it to just the latter.
Currently it only builds the project. Running the tests requires we embed Cloudant credentials in the repo, so I'm considering that dependent on issue #1.

@vinodmut shouldn't we leave this one open until #1 is closed?

Sure, we can re-open it. I don't see a way to specify dependencies among issues.
@lehoanganh Does waffle.io support dependency tracking?

As the Travis CI is now doing the full build with CouchDB, I think we can close this one.


build: move from c++11 to c++17

Moving from cpp 11 to cpp 17 will allow us to use modern features like filesystem support, optional, any, execution policies and improved templates.

Main question to answer: will we break something that cannot be fixed? (DXC is moving forward with cpp17 by ex)

See also line 34, and #5020
Is this specific to clang and GCC? I suppose we have to leave the C++11 flow for MSVC?

The idea was to align this repo to LLVM (and now DXC) 3 years "rule": allow compiler/toolchains/standard bump after ~3 years.
Thanks for pointing out #5020. Updated this PR to work with this change.
Vulkan-validation-layers already build in cpp17, shaderc can build in cpp17, Dawn still builds when changing spirv-tools to cpp17, and DXC dropped support for pre-2022 VS, so won't break either.

We have agreed to move forward with this. We just want to hear if there are any objections from the spir working group.
We believe this should be acceptable because:

The vulkan validation layers have already moved to c++17, so the eco system is moving that way.
The eco system survey shows that 95% of Vulkan developers use VS2019 or later, so their compilers support C++17.

There are a few other changes that will be needed before we can merge this.
Some kokoro file checkout a specific version of googletest instead of the latest for the kokoro builds. I think we should be able to remove that:
./kokoro/macos-clang-release-bazel/build.sh
./kokoro/check-format/build.sh
./kokoro/windows-msvc-2017-release-bazel/build.bat

We will also have to update the README to say that we use C++17 (https://github.com/KhronosGroup/SPIRV-Tools#usage).

We have agreed to move forward with this. We just want to hear if there are any objections from the spir working group.

In the 2022-01-18 SPIR WG meeting, the group agreed to move to C++17 minimum.
Thanks!

Thanks! Updated the README to say we use c++17, and support VS2019 (added a note saying we won't drop support for VS2017 until it breaks due to incomplete support).


[Security] Critical CVE-2022-40674 in expat

Hello,
There is this critical CVE CVE-2022-40674
for expat which affect lots of temurin docker images.
For alpine based images which affects me directly fixed version of expat 2.4.9-r0 is already in alpine repository. If understand correctly, you need to "refresh" temurin docker image to avoid using existing image layer.

Regards

Related to https://github.com/docker-library/official-images/issues/13259

Related to https://github.com/adoptium/containers/issues/279

Waiting for upstream image rebuild CC @tianon

I'm not sure why the alpine:3.16 image hasn't been updated recently, but we've triggered rebuilds of everything based on it now (so our system is working through that queue now).


Can't save derivation containing custom rewrite

I tried to save a derivation where the custom rewrite involves a non-zero phase Fraction(1,4) (the same rewrite as in #102 ). I then got the following exception:
Traceback (most recent call last):
  File "C:\Users\jweteri\Documents\Projects\zxlive\zxlive\mainwindow.py", line 292, in save_file
    data = self.active_panel.proof_model.to_json()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jweteri\Documents\Projects\zxlive\zxlive\proof.py", line 124, in to_json
    proof_steps.append(step.to_json())
                       ^^^^^^^^^^^^^^
  File "C:\Users\jweteri\Documents\Projects\zxlive\zxlive\proof.py", line 21, in to_json
    "diff": self.diff.to_json()
            ^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jweteri\Documents\Projects\zxlive\../pyzx\pyzx\graph\diff.py", line 124, in to_json
    return json.dumps({
           ^^^^^^^^^^^^
  File "C:\Users\jweteri\AppData\Local\Programs\Python\Python311\Lib\json\__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jweteri\AppData\Local\Programs\Python\Python311\Lib\json\encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\jweteri\AppData\Local\Programs\Python\Python311\Lib\json\encoder.py", line 258, in iterencode
    return _iterencode(o, 0)
           ^^^^^^^^^^^^^^^^^
  File "C:\Users\jweteri\AppData\Local\Programs\Python\Python311\Lib\json\encoder.py", line 180, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type Fraction is not JSON serializable

This error is not related to custom rewrites. I am able to reproduce this in any derivation containing a Fraction phase. This is a bug in PyZX's to_json method of GraphDiff. It does not do anything special when converting Fraction to json. This seems like something that should already exist somewhere in PyZX. Do you know how phases are usually converted to json in pyzx?


Completion endpoint returns same response repeatedly

LocalAI version:
LocalAI Release 2.8.0.
Environment, CPU architecture, OS, and Version:
Docker container running in Linux Mint 21.3 "Virginia".
Image built from 2.8.0 Dockerfile.
Ryzen 5 7600x (x86-64)
Describe the bug
In the /v1/chat/completions endpoint,  it seems like cached responses are being returned over and over for the same prompt, even if the seed is changed. Changing the seed, temperature, min-p, top-k, and top-p has no effect. The same response with an identical ID will be returned every time. This happens even when prompt_cache_ro and prompt_cache_all are both set to false.
To Reproduce
Send a response to the chat endpoint. A CURL command is shown below, which may have to be adapted for your testing circumstances.
curl http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d '{
    "model": "mixtral",
    "messages": [
        {
            "role": "system",
            "content": "You are a friendly, expressive, and curious chatbot who loves to engage in conversations and roleplays."
        },
        {
            "role": "user",
            "content": "How are you doing?"
        }
    ],
    "max_tokens": 1024,
    "temperature": 1.2,
    "seed": 2668776,
}'

Now, change the seed. Observe that the endpoint returns an identical response.
Expected behavior
Two requests to the same model with the same prompt and different parameters may return two different results. LLMs are stochastic due to the sampling process, and parameters like temperature, seed, min-p, top-p, and top-k all act to introduce randomness between responses.
Logs
@lunamidori5 might have some, since they were helping me troubleshoot this problem.
Additional context
Here's the YAML file used when this problem was observed:
context_size: 4096
f16: true
gpu_layers: 2
low_vram: false
mmap: true
name: gpt-14b-carly
no_mulmatq: false
prompt_cache_all: false
prompt_cache_ro: true
parameters:
  model: gpt-14b-carly.gguf
  top_k: 0.5
  top_p: 0.9
  n: 1
  RepeatPenalty: 1
  typical_p: 0.8
stopwords:
- user|
- assistant|
- system|
- <|im_end|>
- <|im_start|>
template:
  chat: localai-chat
  chat_message: localai-chatmsg
threads: 14

I noticed this behaviour too while working with LocalAI. I also tried to set the prompt_cache_all option to false but this didn't change anything. Setting temperature, top_k, top_p, seed to different values also doesn't change anything. The strangest part is, it keeps generating the same output even after recreating the whole container except the ID is now different.
I also tried to modify the prompt slightly by adding an "!" at the end for example, but even then, the answer is identical.
I'm using localai/localai:v2.9.0-cublas-cuda12

I'm having a look at this - the options seems passed just fine up to the gRPC server and llama.
However, even when I set          slot.params.seed = time(NULL); right before we set the slot ready to be processed https://github.com/mudler/LocalAI/blob/dc919e08e83f02f5e4b05655094bd1440cb0837a/backend/cpp/llama/grpc-server.cpp#L879 ( as llama.cpp does as well ), it seems completely ignored.
Also to note, that's the full json data printed out (and looks indeed setting seed, top_k, and top_p accordingly):
12:36PM DBG GRPC(c0c3c83d0ec33ffe925657a56b06771b-<IP_ADDRESS>:40341): stdout {"cache_prompt":false,"frequency_penalty":0.0,"grammar":"","ignore_eos":false,"mirostat":0,"mirostat_eta":0.0,"mirostat_tau":0.0,"n_keep":0,"n_predict":-1,"penalize_nl":false,"presence_penalty":0.0,"prompt":"Instruct: tell me a story about llamas\nOutput:\n","repeat_last_n":0,"repeat_penalty":0.0,"seed":-1,"stop":[],"stream":false,"temperature":0.20000000298023224,"tfs_z":0.0,"top_k":40,"top_p":0.949999988079071,"typical_p":0.0}

Ok, tracing seed seem to be just a red herring and dragged me in the wrong direction. I'm tracing back the usage and it looks like it is because it doesn't have enough candidates to select the tokens.
I've tried to switch sampler with phi-2 and I got finally a more undeterministic result. It looks to me it is very much depending on the model/sampler strategy - mirostat can get more candidates, while the temperature sampler has less to select which (so it is more deterministic).
E.g. with phi-2:
name: phi-2
context_size: 2048
f16: true
gpu_layers: 90
mmap: true
trimsuffix:
- "\n"
parameters:
  model: huggingface://TheBloke/phi-2-GGUF/phi-2.Q8_0.gguf
  temperature: 1.0
  top_k: 40
  top_p: 0.95
  mirostat: 2
  mirostat_eta: 1.0
  mirostat_tau: 1.0

  seed: -1
template:
  chat: &template |
    Instruct: {{.Input}}
    Output:
  completion: *template

usage: |
      To use this model, interact with the API (in another terminal) with curl for instance:
      curl http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d '{
          "model": "phi-2",
          "messages": [{"role": "user", "content": "How are you doing?", "temperature": 0.1}]
      }'

There were incongruences with the docs, updated also the samples. If the persist feel free to re-open the issue


Router forces reload on back button with pushstate

Describe the bug
I've migrated a Sapper site to SvelteKit and noticed an issue with how the SvelteKit router handles back button navigation.
I have a /slug page. On scrolling to the bottom, a list of new items from the site's front page is appended, and the url is changed to / using history.pushState.
I have window.onpopstate function that detects this particular situation, so if the back button is pressed after a user has scrolled into the appended items section (with the url set to / using pushState), this simply scrolls us back to the top of the page instead of triggering router navigation, and sets the original url to /slug using history.replaceState.
(The relevant sapper issue is described here: https://github.com/sveltejs/sapper/issues/791)
This worked great in Sapper but required a workaround, which was to pass {id:0} as data, ie history.pushState({id:0}, '', url). The back button then didn't force the router to handle navigation, allowing scrollTop to work properly.
The same code in SvelteKit always forces a page reload when clicking back.
It might be useful in situations like these to be able to disable the default router navigation, as I think it's a common enough use case... the Sapper workaround was a bit of a hack, so I wouldn't expect SvelteKit to handle it the same way necessarily.
Edit: I'm sure there are good reasons for this, but digging into it more I guess the main issue is how the Sapper and SvelteKit routers handle history.state. Sapper sets an "id" key with an incrementing value on each router page navigation, so by passing {id:0} as data in history.pushState this (I guess?) caused the router not to treat that history entry as a router navigation...
I don't quite understand how the SvelteKit router internals work yet, but it seems to just set a "svelte:scroll" key with the current x/y scroll values... but there doesn't seem to be a way to pass any data that would tell it to ignore this history entry as a routable event.
This may not be possible or make much sense, but I had a thought that since triggering a history.pushState in a component doesn't affect the $page store (ie because no route navigation happens, $page remains the same before and after a history.pushState), there could be some way of the router detecting whether a history entry was created by a router navigation, or outside of it?
Expected behavior
Back button should not force a router navigation/page reload but instead scroll back to top of page in this instance.
Severity
How severe an issue is this bug to you? Is this annoying, blocking some users, blocking an upgrade or blocking your usage of SvelteKit entirely?
Not severe but has broken important (admittedly bit hacky) functionality of a migrated sapper site.

I wonder if https://github.com/sveltejs/kit/pull/830 might solve this? I haven't looked closely enough to understand if they're related yet

They are definitely related. I haven't had a chance to test the pull request in #830 but if I understand it correctly, this might be a slightly different issue in that in my case, as there is no href/click event happening to set the url constant.
I think the section of router.js relevant to my issue is this one, since popstate is being triggered by a back button press. Because I'm creating a new history entry using pushState, the router (sensibly) considers the back button as a navigation event because the previous history entry has a different url path. But in this case we are actually still on the same page, so it would be great to have some way of overriding this behavior or checking whether page.path has actually changed, and only triggering route navigation if it hasn't. I think that might solve #830 as well. Not sure if that's possible or desired behavior... but I think there is a need for something like this based on the Sapper issue I referenced (and my own use case).
addEventListener('popstate', (event) => {
    if (event.state && this.enabled) {
        const url = new URL(location.href);
        const info = this.parse(url);
        if (info) {
            this._navigate(info, event.state['sveltekit:scroll'], []);
        } else {
            // eslint-disable-next-line
            location.href = location.href; // nosonar
        }
    }
});

I can confirm that this has not been solved by #830

Please provide a complete and minimal reproducible example we can clone that demonstrates the issue.


After route:cache, Route::current()->getPrefix() returns route prefix without slash at the start.

Laravel Version: 9.23.0
PHP Version: 8.1.9
Database Driver & Version: X

Description:
After route:cache, Route::current()->getPrefix() returns the current route prefix without slash at the start.
I think it would be better to unify this and always return prefix without slash at the start.
Not Cached
Route::current()->getPrefix() returns "/testPrefix";
Cached
Route::current()->getPrefix() returns "testPrefix";
This only happens for grouped routes:
// Broken, getPrefix() returns -> NOT CACHED: "/test" | CACHED: "test"
Route::prefix("/test")->group(function () {
    Route::view("/", "pages.test")->name("test");
});

// Broken, getPrefix() returns -> NOT CACHED: "/test" | CACHED: "test"
Route::group(["prefix" => "/test"], function () {
    Route::view("/", "pages.test")->name("test");
});

// Broken, getPrefix() returns -> NOT CACHED: "/test" | CACHED: "test"
Route::controller(TestController::class)->prefix("/test")->group(function () {
    Route::view("/", "pages.test")->name("test");
});

// Working as expected, getPrefix() returns -> NOT CACHED: "test" | CACHED: "test"
Route::view("/", "pages.test")->prefix("/test")->name("test");

I think the problem is in the RouteGroup::formatPrefix() method.
https://github.com/laravel/framework/blob/2a1a55caf3c65a74f173f47be594587cb931f22c/src/Illuminate/Routing/RouteGroup.php#L64-L73
Here if the old prefix isnt set it basically does this - "" . "/" . "newPrefix" ->  adds slash at the start because the old prefix is an empty string.
I managed to fixed the problem by adding ltrim to the return.
$old = $old['prefix'] ?? '';

if ($prependExistingPrefix) {
    return ltrim(isset($new['prefix']) ? trim($old, '/').'/'.trim($new['prefix'], '/') : $old, '/');
} else {
    return isset($new['prefix']) ? trim($new['prefix'], '/').'/'.trim($old, '/') : $old;
}

If my understanding of the problem is correct, I would be happy to submit a PR to fix this.
#43376 # Steps To Reproduce:

We should indeed fix this but the cached behavior should adopt to the non-cached behavior, not the other way around.

The problem is that the behavior differs even for not cached routes as i described here.
It depends if you use route group or not.
// Broken, getPrefix() returns -> NOT CACHED: "/test" | CACHED: "test"
Route::group(["prefix" => "/test"], function () {
    Route::view("/", "pages.test")->name("test");
});

// Broken, getPrefix() returns -> NOT CACHED: "/test" | CACHED: "test"
Route::controller(TestController::class)->prefix("/test")->group(function () {
    Route::view("/", "pages.test")->name("test");
});

// Working as expected, getPrefix() returns -> NOT CACHED: "test" | CACHED: "test"
Route::view("/", "pages.test")->prefix("/test")->name("test");

Route::view("/", "pages.test")->prefix("/test")->name("test");

This isn't valid code. I don't think we document using prefixes like that on single routes anywhere.

Oh, my bad.
Then i guess the problem would be somewhere here.
https://github.com/laravel/framework/blob/45cd804928f4c1a42fafd2b78c7fa023a59c542a/src/Illuminate/Routing/Route.php#L804-L809
You are basically trimming the slash at the start from the $newPrefix.
I managed to fix it by replacing trim by rtrim.
protected function updatePrefixOnAction($prefix)
{
    if (! empty($newPrefix = rtrim(rtrim($prefix, '/').'/'.ltrim($this->action['prefix'] ?? '', '/'), '/'))) {
        $this->action['prefix'] = $newPrefix;
    }
}

This works for me and the prefix is always returned with slash at the start. Cached or not cached.

Can you try to send in a PR?

Done. Here is the PR: https://github.com/laravel/framework/pull/43932.

Ima close this issue for now. I will create a new one with proper explanation of the problem soon.


Vue 3 Support

TLDR: We're looking to use vue-ld in a Vue 3 application and it doesn't look like there's support for Vue 3 yet. Is there a timeline on support?
In a Vue 3 app we're configuring main.js like this:
import { createApp } from 'vue'
import App from './App.vue'
import { VueLd } from 'vue-ld';

const app = createApp(App)
app.use(VueLd, {
    clientSideId: 'YOUR_CLIENT_SIDE_ID',
    user: {
        key: '...',
        email: '...',
        name: '...',
    },
    options: {
        // Standard LaunchDarkly JavaScript SDK options
    },
});
app.mount('#app')

When we run the application we're finding that the page doesn't load and we're getting the following error in the console:
Uncaught TypeError: Vue.observable is not a function
    at Object.install (index.es.js:1010)
    at Object.use (runtime-core.esm-bundler.js:3003)
    at main.js:6

I believe this could be because Vue.observable is not supported in Vue 3. Is there a timeline for when vue-ld will support Vue 3? Or, can you point me at a similar tool for Launch Darkly that supports Vue 3?
Thank you!

@gav-nomoss we will not be ready to work on upgrading to Vue 3 until fall at least; you are welcome to submit a PR if you need a faster timeline.

Hey @benjamin-t-frost - thanks for getting back.
We're planning to make use of this library in a Vue 2 project that will eventually be migrated to Vue 3, so it's good to know Vue 3 is on your horizon!


Added strokeCap, capWidth and capColor options

Strokecap can now be customised through props
I wanted a circular cap at the end of the progress. Added capwidth and capcolor options to accommodate that
Introduced couple of variables (center, radius)

All new properties are optional. Old behaviour is retained if new properties are not specified.

Would love to see this merged 😍

Sorry for late response. Can you update the docs as well?

Hi @jaysson I have used your changes and looks great. But there is something on the background path of the circle the circle path is being cut in half on the center and the borders of the paths.

@jaysson Are you up for rebasing this and fixing a few errors, or would you like me to implement your changes?
There are a few things we need to fix before merging:

Rebase the PR (linecap has been introduced, though the casing is off if you want to fix to lineCap)
The cap-circle gets cut off as shown by @renso3x
Please make the cap optional and only include the Shape if capWidth is defined. Make capColor default to tintColor

Closing for inactivity.


[WIP] Cache

Implements a cache so that the plugin doesn't re-load from wordpress between compiles when watching.
Closes #2

Coverage decreased (-2.67%) to 97.33% when pulling 96d3f6d455612500e6724d98d8ca09f7691b67b7 on cache into e541b4f56c28cea0eb3dfb59f0764d31febff098 on master.


invalid number of args for optional arguments of jitclass methods.

Reporting a bug

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[x] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Numba version: 0.50.1.
Code to reproduce:
import numba as nb

@nb.experimental.jitclass([('x', nb.int64)])
class Cls:
    def __init__(self, x=1):
        self.x = x

@nb.njit
def test():
    Cls()  # doesn't work: `invalid number of args: expected 2, got 1`
    Cls(1)  # works

test()

Expected behavior: No errors.
Results: invalid number of args: expected 2, got 1 for Cls().

@roosephu thanks for reporting this, I can reproduce it! I believe it is a duplicate of: https://github.com/numba/numba/issues/4820 - please check for duplicates the next time, thanks!


Unified docs generation and docs for the Go client

This PR:

Adds docs for the Go client
Updates docs for the Node client (mostly clarifications and new links to the reference docs)
Generates node and go docs from a docs.zig file in each client directory.
Tests that most of the docs in docs.zig actually compile (using go build and tsc --noEmit)
Tests that the developer setup commands work (TODO: Phil validate this works for node as well)

With this Zig script, unique parts of the docs are defined in $client/docs.zig filling in the Docs struct from src/clients/docs_types.zig.
To generate docs you run zig run generate_docs.zig in the src/clients directory and it generates $client/README.md for each client that has implemented these docs structs.

bors r+


Fix unit tests

lazy load the transport layer so it is not initialized if it is not needed

Codecov Report

:exclamation: No coverage uploaded for pull request base (mirror@1e61aaa). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             mirror     #47   +/-   ##
========================================
  Coverage          ?   3.85%
========================================
  Files             ?      32
  Lines             ?    6609
  Branches          ?    1056
========================================
  Hits              ?     255
  Misses            ?    6349
  Partials          ?       5

Impacted Files
Coverage Δ

Mirror/Runtime/Transport/Transport.cs
10% <0%> (ø)

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 1e61aaa...60a717f. Read the comment docs.


nothing change

i'm doing  all steps to Adding new form elements
and nothing added or change

Please check README


test(blockifier): parametrize test_max_fee_exceeds_balance by resource bounds types

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1322  👈
#1321
#1314
#1313
#1312
#1311
#1310
#1309
#1308
#1307
#1306
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @dorimedini-starkware and the rest of your teammates on  Graphite


Is Cowboy affected by the HTTP/2 Rapid Reset attack?

See: https://nvd.nist.gov/vuln/detail/CVE-2023-44487
Overview: https://blog.cloudflare.com/zero-day-rapid-reset-http2-record-breaking-ddos-attack/

I believe cowboy is already protected against this by this HTTP/2 option, which by default permits resetting 10 streams in 10 seconds:

max_reset_stream_rate ({10, 10000})
Maximum reset stream rate per connection. This can be used to protect against misbehaving or malicious peers that do not follow the protocol, leading to the server resetting streams, by limiting the number of streams that can be reset over a certain time period. The rate is expressed as a tuple {NumResets, TimeMs}. This is similar to a supervisor restart intensity/period.

I have not tested this though.

That's actually an old one. Not sure why there's a new CVE. See https://github.com/ninenines/cowboy/issues/1398 and the original CVE https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514
The relevant test is https://github.com/ninenines/cowboy/blob/master/test/security_SUITE.erl#L205-L230

Oh nevermind that's not exactly the same. This one is the client doing request/cancel very fast many times. I don't think we have a protection against that one.

I think we basically need a max_cancel_stream_rate that works more or less the same as max_reset_stream_rate. Should be an easy enough contribution if anyone wants to do it.

There's a protocol-level draft in https://martinthomson.github.io/h2-stream-limits/draft-thomson-httpbis-h2-stream-limits.html that would likely prove better long term but in the meantime a max_cancel_stream_rate will remain necessary.

Note that these protections are not enough on their own. When Cowboy closes a connection when a reset/cancel rate has been reached, nothing prevents the misbehaving client from connecting again. Cowboy does not provide block lists or other features to fully prevent the DoS, it can only make it a little more expensive to the attacker. The protocol-level draft would work out much better against attack scenarios.
I believe if you have nginx, haproxy or Apache httpd in front of Cowboy you are not affected by this issue.

I think we basically need a max_cancel_stream_rate that works more or less the same as max_reset_stream_rate. Should be an easy enough contribution if anyone wants to do it.

What's the difference between "cancel" and "reset"? The frame to cancel a stream is called RST_STREAM and this is what the existing option controls. CANCEL is only an error code, which can be used in RST_STREAM or GOAWAY. There is no other mention of "cancel" in rfc7540. What am I missing?

Does Cowboy parse all stream messages in one packet before acting on them? If so, it could cancel out all request/cancel pairs that essentially are no-ops before handling them

What the option controls is when the server resets the stream due to an error. From Cowboy's point of view, if the stream has to be stopped due to an error it has to reset it, but if it's the client resetting then it has to cancel the request handling.
Right now Cowboy has protections against bad requests that it has to repeatedly reset, but there's nothing for the client doing the resets (cancelling requests).

Does Cowboy parse all stream messages in one packet before acting on them? If so, it could cancel out all request/cancel pairs that essentially are no-ops before handling them

No and that would only work for request -> cancel -> request -> cancel anyway. Clients could do N requests -> N cancels.

Two more relevant points.
Depending on the server, and particularly in proxies, a stream may be reset by the client but a lot of resources may still be in use while the request is being shut down. In vanilla Cowboy there is no such problem because Cowboy will shutdown the request process. This process by default does not trap exits and so will terminate immediately.
The other angle of attack is the way streams are counted. HTTP/2 has a configurable stream limit. The number of current streams is the active streams, meaning the streams which have not ended and not been reset. In the scenarios where resources stay up for a while after the reset, this becomes a big problem because those reset streams do not count toward the limit, and therefore the attacker wastes a lot of resources with each canceled request.
So applications that are likely to be affected are those that have request handlers that trap exits. Others will see a waste of resources similar to a simple flood of requests.

Is it documented anywhere that Cowboy handler processes can get terminated basically at any point?

Not sure exactly but related options like shutdown_timeout are documented.

Note that these protections are not enough on their own. When Cowboy closes a connection when a reset/cancel rate has been reached, nothing prevents the misbehaving client from connecting again. Cowboy does not provide block lists or other features to fully prevent the DoS, it can only make it a little more expensive to the attacker. The protocol-level draft would work out much better against attack scenarios.
I believe if you have nginx, haproxy or Apache httpd in front of Cowboy you are not affected by this issue.

We use end-to-end TLS connections and terminate TLS on the Erlang node, and we use a load balancer (nginx, haproxy, etc.) only on the TCP layer. This is to keep the data encrypted even within a semi-trusted environment. With this setup, the load balancer can handle and block DoS attacks when many connections are created, but it cannot see the rapid reset attack, which is just a single TCP connection.
I have opened a PR.

One existing config that limits the attack seems to be max_received_frame_rate with the default limit of 10000 frames in 10 seconds (limiting the rapid reset attack to 5000 pairs of new stream and reset stream).

We use end-to-end TLS connections and terminate TLS on the Erlang node, and we use a load balancer (nginx, haproxy, etc.) only on the TCP layer. This is to keep the data encrypted even within a semi-trusted environment. With this setup, the load balancer can handle and block DoS attacks when many connections are created, but it cannot see the rapid reset attack, which is just a single TCP connection.

That's fine as long as it detects the many connections we keep closing and acts on that. That's what I meant.

One existing config that limits the attack seems to be max_received_frame_rate with the default limit of 10000 frames in 10 seconds (limiting the rapid reset attack to 5000 pairs of new stream and reset stream).

Sounds good but fairly expensive still to the server.

I have opened a PR.

I will take a look next week when I get back to work. Thanks!

PR was merged. This will be in upcoming Cowboy 2.11. If a guide to tweaking security configuration for Cowboy is needed, please open a separate ticket or better yet a PR. Closing this, thanks!


Reinforcement bullets might be overshadowing the targeted feedback

I've noticed, when playing through questions on TIE, that I sometimes miss the targeted feedback when the reinforcement bullets (the ones with ticks and crosses) appear. Perhaps this is because my eye is drawn automatically to the coloured things at the bottom.

I wonder if there's a way to make the targeted feedback more prominent when it appears, or mute the reinforcement bullets a bit more, since IMO the former is more important? But it might be good to check first whether this phenomenon (of auto-skipping to the reinforcement bullets) is a more general one or if it is just me.
/cc @theresa-lee @rabidbit

Is this any better? ...

Ooh -- yes, actually. After reading the bullets, I immediately go on to read the next thing.

Closing this until we get more data to make a decision.


HotFix: DateTime problem

HotFix: DateTime problem
Description
Do Day +1 => Get irreal dates like 32.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] Test
[x] Documentation
[ ] Keep updated translations (.po)
[x] Update changelog

https://github.com/IciaCarroBarallobre/elixir_wordle/pull/41


TabItem custom Width truncated

Describe the bug
If I specify a custom width for a TabItem it will be shown truncated.
To Reproduce
Create a TabControl, then create a TabItem and try to specify a custom width, for example 75.
Expected behavior
That TabItem will resize without be truncated.
Screenshots

Original width, not truncated

Changed width (75), truncated
OS version
Windows 11
.NET version
7.0
WPF-UI NuGet version
2.0.3
Additional context
No response

I've been working on a fix waiting for your official fix. Please take this as a starting point. I simply overwrote the TabItem template based on yours with a custom style.
<Style BasedOn="{StaticResource {x:Type TabItem}}" TargetType="{x:Type TabItem}">     <Setter Property="Template">         <Setter.Value>             <ControlTemplate>                 <Border Height="36" Background="{ui:ThemeResource ControlFillColorDefaultBrush}" CornerRadius="5,5,0,0">                     <StackPanel x:Name="TabHeaderStackPanel" Margin="8,0,8,0" Orientation="Horizontal">                         <TextBlock Height="15" HorizontalAlignment="Stretch" Text="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type TabItem}}, Path=Header}"/>                     </StackPanel>                 </Border>             </ControlTemplate>         </Setter.Value>     </Setter> </Style>

Same issue here do we have an update to the official fix?

This is still no solution but the problem seems to be that by reducing the width of the entire TabItem, this doesn't trickle down to a border that is set for the TabItem and draws its graphics.
If you go here: ... /TabControl/TabControl.xaml
You'll find this part in the TabItem template:
<Border
    x:Name="Border"
    MinWidth="180"    // Here's our problem!
    MinHeight="36"
    Margin="0"
    Padding="6"
    ...
</Border>

As far as I know, a template can't be partially used in XAML, so it's an all or nothing thing. What you can do is to copy & paste the entire thing starting with <Style TargetType="{x:Type TabItem}"> and ending with </Style> into a <Window.Resources> section or similar, overwriting the entire TabItem template, much like @Marko97IT commented above. The difference is now you're using the latest template code for WPFUI and know where to find it if there are updates.
The "real" fix should be to make MinWidth here a bindable property.


Simplify and fix os.MkdirAll() usage

Please review; I think it's of moderate importance as ignoring error from MkdirAll can lead to some other error later and it could be hard to track the cause down to failed MkdirAll.

Here's an example
http://play.golang.org/p/xcuYZ1YtyZ

@kolyshkin Thanks for the patch. The existing code ignores the error ONLY for the case of EEXIST. If, as per your example, the call os.MkdirAll doesn't fail with EEXIST, then it is fine. The code will just work as is. But, if it fails with ENOTDIR, then we return the error as expected.
Also, this behavior seems to be OS specific. Hence should we confirm the behavior of isExist across OSes before removing that check ?

@mavenugo The thing is, it is wrong to ignore EEXIST error, too. In its current implementation (https://golang.org/src/os/path.go#L12), MkdirAll() can actually return EEXIST in a case of the following race (which I admit I was too lazy to explain in details, but here you go).
First, MkdirAll calls stat() and gets ENOENT, so it goes on to check and create all the parents. At this time, someone else creates a file under the same name as the last MkdirAll component. Finally, MkdirAll calls Mkdir to create that last component, Mkdir returns EEXIST which MkdirAll passes to the caller.
Having said that, the race should be pretty rate, this is why I named my commit "Simplify and fix" not "Fix and simplify". This extra check is redundant in the first place.
As of OS dependent, I admit I have UNIX/Linux in mind and don't know much about other platforms, but MkdirAll is definitely not OS-specific. Although Mkdir (which it calls) is OS-specific, it should be wrong to ignore its errors on any platform.

@kolyshkin Thanks for the explanation. As you understand, Ignoring the EExist is a lazy way to make sure we dont fail if the directory is already available. Hence, if we decide to return the EExist error, then it is going to impact the rest of the code which has some assumptions on createBasePath.
If we decide to go with this patch, we have to fix this assumption appropriately.
Though we cannot do it in an atomic way, we could check for the presence of the directory before calling MkdirAll and returning the error.
I wouldn't be happy to go with the observation made in http://play.golang.org/p/xcuYZ1YtyZ which executes in a particular OS and a specific environment. am more interested in making sure the current assumption is honored. Which is, createBasePath creates the base base directory if not already available (or) return a success if it is already available.

Ignoring the EExist is a lazy way to make sure we dont fail if the directory is already available.

No. Please re-read my patch description. Let me quote the relevant part:

Quoting MkdirAll documentation:

MkdirAll creates a directory named path, along with any necessary
parents, and returns nil, or else returns an error. If path
is already a directory, MkdirAll does nothing and returns nil.

This means two things:

If a directory to be created already exists, no error is
returned.

Also, I went ahead and checked that the current implementation of MkdirAll() is in sync with the above quoted documentation (i.e. it doesn't return EEXIST error if the directory is there), and that it is also OS-independent.
So, once again, the check for EEXIST after MkdirAll() is at the very least redundant.

@kolyshkin yep. I missed that point. Thanks.
LGTM.
cc @aboch

BTW my similar pull requests to Docker and RunC are merged:

https://github.com/docker/docker/pull/15146
https://github.com/opencontainers/runc/pull/162

Thanks @kolyshkin for the explanation.
LGTM


fix of example of using classify --read-text-dirs

classify argument --read-text-dirs expects dirs to be separated by "," as could be seen in cc.factorie.app.classify.Classify:
for (directory <- opts.readTextDirs.value.split(",")) {
moreover; there should be no space; since readTextDirs.value contains only the first token.

Thanks!


Intermittent nil dereference from the 2.2.3 bind values support code

Not much to go on at the moment, but on something like one run out of a hundred of our cucumber suite, we get a strange nil dereference coming from a bit of code that hooks up Arel bind values to ActiveRecord inserts.
The code in question is in lib/arel/visitors/bind_visitor.rb whose introduction was the sole diff from 2.2.2 in 2.2.3, so I was hoping you could give me some more background on the change.
I'm not clear on how the visitor stuff is used but my interpretation of the below backtrace is that there is one fewer bind value being provided than the AST expects.  Is that reasonable?
I can't figure out how this could be intermittent.  The model class in question has no magic stuff.  Could well be an ActiveRecord bug but given bind_visitor only just went in, I am hazarding a guess it's Arel.
(We are running an older version of Rails - from 3-1-stable - but master has no relevant changes to this code that I can see, 4bc2ae0 being the only vaguely related thing, so I believe it's not already fixed.  And I can't see anything wrong in the higher-level ActiveRecord calls nor the aliased methods to do query caching, transaction isolation levels, etc.)
undefined method `reverse' for nil:NilClass
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:10:in `to_sql'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/bind_visitor.rb:17:in `call'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/bind_visitor.rb:17:in `visit_Arel_Nodes_BindParam'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `send'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `visit'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:119:in `visit_Arel_Nodes_Values'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:117:in `map'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:117:in `visit_Arel_Nodes_Values'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `send'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `visit'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:82:in `visit_Arel_Nodes_InsertStatement'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `send'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:19:in `visit'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/visitor.rb:5:in `accept'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:18:in `accept'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:185:in `with_connection'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/to_sql.rb:16:in `accept'
/var/anonymized/vendor/bundle/ruby/1.8/gems/arel-2.2.3/lib/arel/visitors/bind_visitor.rb:11:in `accept'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:9:in `to_sql'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:91:in `insert'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in `insert'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/relation.rb:70:in `insert'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/persistence.rb:313:in `create'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/timestamp.rb:51:in `create'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/callbacks.rb:268:in `create'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:390:in `_run_create_callbacks'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:81:in `send'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:81:in `run_callbacks'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/ac...tiverecord/lib/active_record/callbacks.rb:268:in `create'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/persistence.rb:294:in `create_or_update'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/callbacks.rb:264:in `create_or_update'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:399:in `_run_save_callbacks'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:81:in `send'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activesupport/lib/active_support/callbacks.rb:81:in `run_callbacks'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/callbacks.rb:264:in `create_or_update'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/persistence.rb:57:in `save!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/validations.rb:56:in `save!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/attribute_methods/dirty.rb:33:in `save!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:246:in `save!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:295:in `with_transaction_returning_status'
/var/anonymized/vendor/bundle/ruby/1.8/gems/transaction_isolation_level-0.1.0/lib/transaction_isolation_level/adapter_patches.rb:43:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:199:in `transaction_without_isolation_level'
/var/anonymized/vendor/bundle/ruby/1.8/gems/transaction_isolation_level-0.1.0/lib/transaction_isolation_level/adapter_patches.rb:43:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:208:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:293:in `with_transaction_returning_status'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:246:in `save!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/has_many_association.rb:14:in `insert_record'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:436:in `create_record'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:344:in `add_to_target'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:434:in `create_record'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:147:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/gems/transaction_isolation_level-0.1.0/lib/transaction_isolation_level/adapter_patches.rb:43:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:199:in `transaction_without_isolation_level'
/var/anonymized/vendor/bundle/ruby/1.8/gems/transaction_isolation_level-0.1.0/lib/transaction_isolation_level/adapter_patches.rb:43:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/transactions.rb:208:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:146:in `transaction'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:433:in `create_record'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_association.rb:115:in `create!'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_proxy.rb:53:in `__send__'
/var/anonymized/vendor/bundle/ruby/1.8/bundler/gems/rails-a84c005e35d2/activerecord/lib/active_record/associations/collection_proxy.rb:53:in `create!'
/var/anonymized/features/step_definitions/signup_steps.rb:126

Haven't seen this one for a while, so closing.


[REVIEW] DDRSS

Project link
https://github.com/Pradumnasaraf/DDRSS

Nice one 🔥
Consider removing the bit.ly link and using the original one. For me bitly links have some kind of negativ touch but this is only my personal opinion on that.

Nice one fire Consider removing the bit.ly link and using the original one. For me bitly links have some kind of negativ touch but this is only my personal opinion on that.

Agree Tom, removed it :rocket:

Nice one fire Consider removing the bit.ly link and using the original one. For me bitly links have some kind of negativ touch but this is only my personal opinion on that.

Agree Tom, removed it :rocket: , Thank you

Looks great, some thoughts

Recommend using issues with labels
Animated gif might make it come to life a bit more

Review live stream https://www.youtube.com/watch?v=NxxJ_5nyG9E


Jenkins UI dropping port in links that redirect - v2.7.4

Working fine, apart from when clicking around the UI.
My installation is on port 8080 within the container, and then I'm mapping this to 8080 on the host.
Some links (presumably those that don't have a redirect) are fine and direct me to links with :8080, such as 'Manage Jenkins' and 'New Item', but with many others (that I guess are 'add ons' to the core) seem to link to the proper URL on port 8080 (on hover), but after clicking it redirects, dropping the port and I get a 404.
I've set the Jenkins URL up properly, and even specified port 8080 in the options.
Grepping around my $JENKINS_HOME I can't see anywhere where add-ons seem to be able to set their own ports on redirects.
Is there some other port setting I'm missing?
Any help would be greatly appreciated.
UPDATE:
So links without a trailing slash are dropping the port. This is very strange.
Doesn't work:
http://myciserver.com:8080/me/my-views (redirects to http://myciserver.com/me/my-views/)
Does work:
http://myciserver.com:8080/me/my-views/
UPDATE 2
Ok, so it appears to be caused by Amazon's new 'Application load balancer'.  I have no idea what's causing it to feck up, but it works with a 'classic load balancer'.  Going to have to play around with this.

Raised with Amazon https://forums.aws.amazon.com/thread.jspa?threadID=239669


ISPN-5903 BZ1266831 Fix logging exception when both infinispan-remote uber-jar and infinispan-commons on classpath

Jira: https://issues.jboss.org/browse/ISPN-5903
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1266831
This issue was already fixed, the problem is that when the infinispan-remote package is used with infinispan-spring4-remote package, there is an exception:
java.lang.NoSuchMethodError: org.infinispan.commons.logging.BasicLogFactory.getLog(Ljava/lang/Class;)Linfinispan/org/jboss/logging/BasicLogger;

This happens because two versions of BasicLogFactory are loaded, one from infinispan-remote that is "shaded" by maven-shade-plugin, one from infinispan-commons (transitive dependency of infinispan-spring4-remote) which is not "shaded", both have the same fully qualified names and when the hotrod-client is loaded, it picks up one of those classes, when it picks up the infinispan-commons version, it fails with the above error as method that returns  infinispan.org.jboss.logging.BasicLogger is not found. The infinispan-remote version is picked up if it's loaded first, which can be achieved by defining the package before infinispan-spring4-remote in a pom.xml. Another solution is to exclude infinispan-commons from infinispan-spring4-remote, which gets rid of the later version of BasicLogFactory altogether. See the linked BZ for more information.
This fix disables "shading" of the org.jboss.logging package, which makes the above workaround unecessary.

:+1: @tristantarrant Does it look good for you?

Integrated in master. Thanks @VaclavDedik !


consider to give a option to override watch folders?

Clear and concise description of the problem
wanna to watch external folder or node_modules/xx .
  const { ignored = [], ...watchOptions } = serverConfig.watch || {}
  const watcher = chokidar.watch(path.resolve(root), {
    ignored: [
      '**/node_modules/**',
      '**/.git/**',
      ...(Array.isArray(ignored) ? ignored : [ignored])
    ],
    ignoreInitial: true,
    ignorePermissionErrors: true,
    disableGlobbing: true,
    ...watchOptions
  }) as FSWatcher

https://github.com/vitejs/vite/blob/main/packages/vite/src/node/server/index.ts#L321-L332
Suggested solution
add something like rootPaths , to watch options .
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

What's the use case?

@sodatea My project use a private npm package, so i need to watch specific package in node_modules.

Could you try negated glob patterns to see if it overrides the default ignored patterns?
Something like ignored: ['!**/node_modules/**']


Fix ignorePackages to produce errors

Closes #1518
@ljharb By "never" I mean literally never, even the test produced zero error before fixing buildProperties(). (I found this in https://github.com/w3c/respec/pull/2555)

Coverage decreased (-4.1%) to 92.39% when pulling 2bfd9d0d0a83954a26f95949ade56705d4f48e1f on saschanaz:ignorePackages into 112a0bf442e52b25cd7029a9905df2508e191ac1 on benmosher:master.

Coverage decreased (-4.1%) to 92.39% when pulling 2bfd9d0d0a83954a26f95949ade56705d4f48e1f on saschanaz:ignorePackages into 112a0bf442e52b25cd7029a9905df2508e191ac1 on benmosher:master.

Coverage decreased (-4.1%) to 92.39% when pulling 2bfd9d0d0a83954a26f95949ade56705d4f48e1f on saschanaz:ignorePackages into 112a0bf442e52b25cd7029a9905df2508e191ac1 on benmosher:master.

Coverage decreased (-4.1%) to 92.39% when pulling 2bfd9d0d0a83954a26f95949ade56705d4f48e1f on saschanaz:ignorePackages into 112a0bf442e52b25cd7029a9905df2508e191ac1 on benmosher:master.


Unable to upload folder on iOS, no permission

Describe the bug
Unable to upload folder on iOS, no permission
To reproduce
1 Click on 'Upload folder'
Expected behavior
Successfully uploaded folder
Screenshots
No response
Desktop (please complete the following information)

OS: [ipadOS]
Version: [16.6.1]

Smartphone (please complete the following information)

Device: [ipad8]
OS: [ipadOS]
Version: [16.6.1]

Additional context
No response

Maybe check your settings to allow access to document storage:

@NotOfficer I have the same issue, both for the previous versions (1.15.4/1.16.0...), and also for the current one (1.16.2), and if I go to the IOS settings is identically at your, but he doesn't function anyway. Does it work at you?

Hi! Sorry for the late reply, I'm in China right now. Although I don't know who are you, but I can tell you that my Localsend on iOS & iPad OS is not working when you try to select a whole folder. The way I solved this is using Mac Version Local send.  However, it's still not perfect, some folder can't be select.  Fortunately, I keep synchronizing my files on iCloud and Samsung google, which is fine for me currently. My apple device are all using beta OS, I'm sure it's some program conflict after iOS 18 iPad OS18 and Mac Sequoia. Let me know if you have solution.
Best
Dingcheng Wang 王鼎承

From: rixcxardo @.>
Sent: Wednesday, November 27, 2024 7:40:19 PM
To: localsend/localsend @.>
Cc: DingchengWang @.>; Manual @.>
Subject: Re: [localsend/localsend] Unable to upload folder on iOS, no permission (Issue #1974)
@NotOfficerhttps://github.com/NotOfficer I have the same issue, both for the previous versions (1.15.4/1.16.0...), and also for the current one (1.16.2), and if I go to the IOS settings is identically at your, but he doesn't function anyway. Does it work at you?
941F435A-010F-4607-8D55-FCFF547D0757.jpeg (view on web)https://github.com/user-attachments/assets/c77ec602-4e40-4143-8f34-0c4e1c242655
—
Reply to this email directly, view it on GitHubhttps://github.com/localsend/localsend/issues/1974#issuecomment-2503654894, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHJOWLI5ZNXHUJSCJ3STAQD2CWVSFAVCNFSM6AAAAABQ32WAUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBTGY2TIOBZGQ.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


Why can't OpenAI access the Azure Search Resource? [FIXED]

Library name and version
Azure.AI.OpenAI" Version="2.0.0-beta.2"
Query/Question
Hello, so I am trying to call the OpenAI client while using AzureAISearch as a Data source. The problem I am having is that the resource does not seem to be used whenever I call OpenAI and the response given by it is that it does not has any information on the topic. In the Chat playground I am able to make this part work and it properly gives me an answer surrounding the topic fed to the LLM by AzureAISearch.
Basically, the OpenAIClient works properly but I cannot get answers from the Data source.
It is also important to note that I have tried the code with API keys, and it still does not work. I also tried this code using the sample given in the Chat playground step by step, and still nothing. This is how my code is looking right now.
and I am including all the packages shown in the sample.
            ChatClient chatClient = azureClient.GetChatClient("StackBuddAY");

            // Setup chat completion options with Azure Search data source
            ChatCompletionOptions options = new ();
#pragma warning disable AOAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
            options.AddDataSource(new AzureSearchChatDataSource()
            {
                Endpoint = new Uri("https://stackbuddysearchresource.search.windows.net"),
                IndexName = "tags",
                Authentication = DataSourceAuthentication.FromUserManagedIdentity(AppConfig.MIClientId),
            });
#pragma warning restore AOAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

            // Create chat completion request
            ChatCompletion completion = chatClient.CompleteChat(
                new List<ChatMessage>()
                {
                    new UserChatMessage("Do you have any specific documentation about the MSI team from managed Identities that has explicitly been provided to you? ?")
                });

            // Process and print the response
#pragma warning disable AOAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
            AzureChatMessageContext onYourDataContext = completion.GetAzureMessageContext();
#pragma warning restore AOAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
            FunctionLogger.Instance.LogInformation("CHAT MESSAGES FOR TEST");
            FunctionLogger.Instance.LogInformation(completion.Role + ": " + completion.Content[0].Text);
            if (onYourDataContext?.Intent is not null)
            {
                FunctionLogger.Instance.LogInformation($"Intent: {onYourDataContext.Intent}");
            }

            foreach (AzureChatCitation citation in onYourDataContext?.Citations ?? new List<AzureChatCitation>())
            {
                FunctionLogger.Instance.LogInformation($"Citation: {citation.Content}");
            }

            return Task.CompletedTask;

            ```

### Environment

I am running this in ```.NET 8.0``` and in an ```Azure function```

Any update here? I am running into exact same issue. Azure Search data source works in Chat playground but throws 400 bad request when using Azure.AI.OpenAI 2.0.0-beta.5. If I disable below code, application works but then it fails the purpose of using custom data source:
ChatCompletionOptions options = new ChatCompletionOptions();
options.AddDataSource(new AzureSearchChatDataSource()
{
Endpoint = new Uri(searchEndpoint),
IndexName = searchIndex,
Authentication = DataSourceAuthentication.FromApiKey(searchResourceKey),
AllowPartialResult = true,
InScope = true,
QueryType = question,
Strictness = 4,
TopNDocuments = 20
});

@santiagogun I see you marked the issue as fixed. Can you please help me understand how this was fixed?

Hi, I ran into the same issue, can you help me resolve the issue?

Change:
            ChatCompletion completion = chatClient.CompleteChat(
                new List<ChatMessage>()
                {
                                new UserChatMessage(chatMessage)
                }
            );

To:
            ChatCompletion completion = chatClient.CompleteChat(
                new List<ChatMessage>()
                {
                                new UserChatMessage(chatMessage)
                },
                options
            );

Put "options"


SignalPlot using YOffset leaves dots at original position

Bug Report
Issue: SignalPlot using YOffset leaves dots at original position
Reproducing: Use Data.YOffset on a SignalPlot, and observe the dots left at the base position - see screenshot. Looks like the markers get left behind, except it's not the markers, because setting them to not visible doesn't help. However, if you try to zoom in on them, they will disappear at a certain level of zoom.
private double[] RandData() {
    double[] d = new double[10000];
    Random r = new Random();
    for (int i = 0; i < 10000; i++) d[i] = r.NextDouble()*100;
    return d;
}

private void Form1_Load(object sender, EventArgs e) {
    double[] data1 = new double[10000];
    double[] data2 = RandData();
    double[] data3 = RandData();

    Signal s1 = formsPlot1.Plot.Add.Signal(data1);
    s1.Marker.IsVisible = false;
    Signal s2 = formsPlot1.Plot.Add.Signal(data2);
    s2.Data.YOffset = 150;
    s2.Marker.IsVisible = false;
    Signal s3 = formsPlot1.Plot.Add.Signal(data3);
    s3.Data.YOffset = 300;
    s3.Marker.IsVisible = false;
}

System Details

ScottPlot Version: 5.0.10-beta
Operating System: Windows 10
Application Type: WinForms
.NET Version: .NET 8.0

More oddities with this, which might help identify the problem.

private void Form1_Load(object sender, EventArgs e) {

    double[] data1 = new double[10000];
    double[] data2 = new double[1];

    // uncomment this to produce the second screenshot
    //for (int i = 5000; i < 10000; i++) data1[i] = 100;

    Signal s1 = formsPlot1.Plot.Add.Signal(data1);
    s1.LineStyle.Color = Colors.Red;
    s1.LineStyle.Width = 5;
    s1.Data.YOffset = 100;

    // s2 just to keep the origin in frame
    Signal s2 = formsPlot1.Plot.Add.Signal(data2);
    s2.LineStyle.Color = Colors.Blue;
    s2.LineStyle.Width = 5;

}

With all zero data values, but YOffset of 100:

Zoom in close enough and the lines disappears, it's made up only of the wrongly places dots.
With the second half set to 100 (uncomment the line in the code above), and YOffset of 100:

Zoom in to this one and even odder things happen...

Thanks for reporting this @raburton!
I suspect it's been fixed in #2949 because your code looks good on my machine now. These updates should be in the next release which I plan to push to NuGet within the next few days 👍


Fix setupwizard roles

Assign roles to org/project as needed.

Feel free to push back on this, but in #499 it was suggested by @blueandgold to use the naming convention for service accounts in that best-practices document to align with what this wizard creates. It might be best to sneak this in with this PR.

Adding cla: yes label, as all commit authors are covered by CLA.


close python on exit, including SIGINT, SIGTERM

I saw lots of instances of the python application popping up and realized they were probably not being killed when I kept exiting my application.
This seems to fix the issue.

Uhm, that's wierd. It closes my python apps when the parent(node) process ends. I mean, It's definitely safer killing it manualy as you did in PR and I will merge that, but can you tell me when does it not close the python process at all?

I was often closing my application with Control-C, which might be part of it. It is also an Electron application specifically, I'm not sure if that has specific life-cycle quirks. But yes, I was seeing orphaned winpy.exe processes in task manager until I made this change.

Ok.
Thanks for the reply and mostly for the code update.


toBeMinOf()

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (6d150d6) to head (b211a66).

Additional details and impacted files
@@             Coverage Diff             @@
##                main       #25   +/-   ##
===========================================
  Coverage     100.00%   100.00%
- Complexity        21        22    +1
===========================================
  Files              2         2
  Lines             50        52    +2
===========================================
+ Hits              50        52    +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


int too large to convert to C long

Describe the bug
If the file size is greater than integer type we took this error:
File "SKOPOSSFTPDownload_v1.0Engine.py", line 426, in pi_push_all_records
File "SKOPOSSFTPDownload_v1.0Engine.py", line 472, in _process_file
OverflowError: Python int too large to convert to C long
To Reproduce
Download a file of more 3GB
Desktop (please complete the following information):

OS: Windows 10
Alteryx designer
Version 2020.2.3

I resolved updating the download python module using int64
SKOPOSSFTPDownload_v1.0Engine.zip


[zh] Localize blog: Verifying Container Image Signatures Within CRI Runtimes

I will localize the blog: Verifying Container Image Signatures Within CRI Runtimes.
To avoid any conflict, this issue is opened.
/language zh
/assign

/triage accepted


fix(TDI-42892):Eliminate restraint of Azure SAS

What is the current behavior? (You can also link to an open issue here)
https://jira.talendforge.org/browse/TDI-42892
What is the new behavior?
Please check if the PR fulfills these requirements

[ ] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: failure :x:

Pull request test result: success :star:
Sonar results


Remove self as a maintainer

Description
It’s been a while since I’ve been able to contribute, and I need to  reduce the GitHub notifications noise.
Perhaps one day I’ll be back, thanks for all the great work!
Issues Resolved
n/a
Check List

[ ] A summary of changes made is included in the CHANGELOG under ## Unreleased
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable.

@jeffbyrnes thanks for much for all the help. Good luck with the inbox noise 😆


input with any::<bool>() constraint causes test to run for a long time

Hey,
The following runs for a very long time, and seems to be unable to reduce the input:
#[macro_use]
extern crate proptest;

use proptest::prelude::*;

proptest! {
    fn run_for_a_long_time(v in any::<bool>()) {
        println!("v: {}", v);
        assert!(!v);
    }
}

fn main() {
    run_for_a_long_time();
}

Note that it works when the assert is just assert!(v).

Fixed in 0.7.2.


UI/AppKit: Make the header buttons more accessible

By Setting setBordered property on header buttons to Yes this path makes the whole button clickable. Previously the only the icon was clickable, now it's easy to click.

Thanks! Agreed that this is better.
But per the contribution guidelines, please write the commit title in the imperative mood. So instead of "Making header buttons ...", it would be something like "Make the header buttons ...".
(And "no visual changes" isn't quite true, the buttons now have a hover effect)

@trflynn89 thanks for the feedback. Totally forgot to read the guidelines. Let me know if need to change anything else.
Thanks again:)

@nicolasdanelon you must update the commit title/message as well not just the PR title/description.
The following commands should help you do that.
git commit --amend

Edit the commit title and message as requested.
Then push the changes back to your remote branch.
git push --force-with-lease


Tree node cannot be collapsed unless clicked parent node

If the folder is expanded, it cannot be collapsed when we click again it. If we want to close it we should click to the parent node. Folder should be collapsed when we click to the folder icon or arrow icon.

Hi @ayZagen this is not the behaviour that we are using. But I will take it into account for the next release


Feature to minimize cell-output

Having a button on each cells output so that larger blocks can be minimized to reduce the on-screen info. Could be a sliding feature if not a button. Such as minimizing/maximizing a screen size vs. drag & drop to resize.
This could improve notebook overview and reduce clutter, even when the cells can't be deleted.

Actually implemented this in July


Give better control over system dispatching (by Object905)

To explain why I created this PR: @Object905 previously created #22, however deleted the branch and I requested changes. I then restored the commits and created this Pull Request.
Thanks @Object905!
bors r+


feat: Asynch implementation on clean branch

Implements asynch features with parameterized timeout and concurrency inputs.

Great. Thanks for the update!


feat(cli): add 'clear' command to clear the terminal and stay in loop

fixes #139

Implemented a 'clear' command in the CLI to clear the terminal screen.
The clear screen functionality is supported for both Windows ('cls') and Unix-based systems ('clear').
The program remains in the command loop after clearing the screen, allowing continuous use until 'exit' is entered.

https://github.com/pieces-app/cli-agent/assets/107706485/55258614-c386-4152-bd00-9bd8dd85d033

@mdex-geek great job looks good but can you add this to the CHANGELOG.md? And the README.md too

@Bishoy-at-pieces i add this in changelog.md and readme.md

Thank you!


Update config.yml

Fixes Issue
My PR closes #463
👨💻 Changed following url : https://discord.gg/KUWjx4fygJ which was invalid to a valid one.
✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title and description of the PR is clear and explains the approach.

Note to reviewers

📷 Screenshots

@RuchirDixit you created this PR in your forked repo and not the actual main repo.


Review e2e journeys

Reviewed the end to end journeys for XI and GB
Added the headings to all stepdefs and updated the features
Arrival had to be only updated for procedure type due to using a shared stepdef with departures
Arrivals will be reviewed for the above in a separate ticket

Looks like coding best practices are in place, Authorisation flows are as expected & both the e2e journeys are passing in my local.
I am happy to approve  & John / Gosifo, to review the overall Journey rules


[WIP] Update to TS5

Updating to the new TS5, mostly to try it in #707

Continues in https://github.com/Shopify/hydrogen/pull/1240


Fix RedHat.CaseSensitiveTerms rule for "Customer Portal" to detect preceding "Red Hat" defined in an attribute

Describe the bug
The following asciidoc source:

Generates a false 'error':

What does the complete string of {CompanyName} Customer Portal resolve to in the HTML?

@aireilly - Sorry I missed this Q. Here's the asciidoctor HTML output:
... log in to the Red Hat Customer Portal and go...
The {CompanyName} attribute is set as follows:
:CompanyName: Red{nbsp}Hat
Thanks


Update: Add React v18 support, package workflow improvements

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Negative event.timeStamp values

Similar to #6, looking into the data I've also found several cases where the event.timeStamp value is negative, which obviously messes up the data.  This library needs to account for that.

Closed via #8.


BE-236 - Elements and jurisdictions should point to the current UN name for countries

Signed-off-by: Elisa Kendall<EMAIL_ADDRESS>Description
Replaced all references to the legacy LCC representation for the United States with United States of America; other countries for which there are multiple names had already been updated in FIBO
Fixes: #1467 / BE-236
Checklist:

[x] I'm familiar with the FIBO developer quide. My contribution meets all the requirements described there.
[x] My contribution follows the principles of best practices for FIBO.
[x] My changes have been reconciled with latest master and no merge conflicts remain.
[x] This PR is related to exactly one issue. The issue is referenced by using a GitHub keyword such as "fixes", "closes", or "resolves".
[x] Hygiene tests have been applied by a PR with "(WIP)" in title.
[x] The issue has been tested locally using a reasoner (for ontology changes).

Looks good!
John
@.*** @.***>  | M:<PHONE_NUMBER>
From: Elisa Kendall @.>
Sent: Thursday, March 25, 2021 9:55 PM
To: edmcouncil/fibo @.>
Cc: John Gemski @.>; Review requested @.>
Subject: Re: [edmcouncil/fibo] BE-236 - Elements and jurisdictions should point to the current UN name for countries (#1468)
@ElisaKendall https://github.com/ElisaKendall  requested your review on: #1468 https://github.com/edmcouncil/fibo/pull/1468  BE-236 - Elements and jurisdictions should point to the current UN name for countries.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub https://github.com/edmcouncil/fibo/pull/1468#event-4511169003 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGJ2YDUKJOAXERAV3V34TTFPSQFANCNFSM4Z2MESZA .  https://github.com/notifications/beacon/ACNGJ24JD6MW72OOHHD6HB3TFPSQFA5CNFSM4Z2MESZKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGPAAAAAAIM4L46W.gif


feature Support to use mv group dimension when query aggregate  function is distinct (#36318)

Proposed changes
cherry-pick to 2.1
pr: https://github.com/apache/doris/pull/36318
commitId: c1999479

run buildall

run buildall


Hi, are you working on this migration to new Architecture?

https://github.com/reactwg/react-native-new-architecture/discussions/167
In this link, they are listing the most important libraries in React Native for tracking the migration to the new architecture. Are they working on this migration

do you have any update on this item? we are looking to migrate to new architecture

Hi @hwekim, it is on our roadmap, but there is no ETA yet.

Hello,
Is there any update on the prioritization of this issue? My team is starting to uncover problems in upgrading certain other libraries due to not being able to move to the new architecture.
Regards.

@ulrikap Thanks for your interest, this is still on our road map,  though we don't have significant updates to share at the moment.  We will keep you informed as soon as we have more concrete information.
May we know which company you are representing? it will help us gather the list of the requesting companies and prioritize accordingly.

@cacheung RN new architecture is officially in beta and my team is currently blocked by @adobe/react-native-aepcore.
See React Conf Keynote for details and roadmap: https://youtu.be/Q5SMmKb7qVI?si=isJuMMInn6a8Yufd&t=1230

@blumk May Thank you for reaching out. Could you provide me with your company name?  I will add it to the request list for internal review.

@blumk Thank you for reaching out. Could you provide me with your company name? I will add it to the request list for internal review.

@cacheung abbott.com / hellolingo.com. Thank you!

@cacheung React Native 0.76 will ship with new architecture enabled by default:
https://github.com/facebook/react-native/releases/tag/v0.76.0-rc.0

@blumk Thank you for the information. We're aware and are currently in the process of running some certification tests.

@cacheung do you have any updates or estimations?

@Ashalbulk We're actively working on the testing and making good progress. We’ll have more information to share with you as soon as we can - thank you for your patience!

@cacheung no updates?

@Ashalbulk Thank you again for your patience.  We’re making great progress and anticipate sharing an update in Jan next year.