Issue with pluck() when the item being plucked is a Carbon::Carbon object retrieved via __get()

Laravel Version
10.13.5
PHP Version
8.1.18
Database Driver & Version
n/a
Description
I have an object Class, where the value "date" is retrieved via a call to __get():
class Message extends FTNBase
{
...
	public function __get($key)
	{
		switch ($key) {
			case 'date':
				if (str_contains($x=chop(Arr::get($this->header,$key)),"\x00"))
					throw new \Exception('Date contains null values.');

				return Carbon::createFromFormat('d M y  H:i:s O',
					sprintf('%s %s%04d',$x,($this->tzutc < 0) ? '-' : '+',abs($this->tzutc)));
...
       }
...
}

When I call dd(['messages'=>$this->messages->pluck('date')]); it results in a collection of null's, where $this->messages is a collection of Message::class.
So I added the following line to src/Illuminate/Collections/helpers.php data_get() function (line 77).
if ($segment === 'date') dd(['a'=>$target->{$segment},'b'=>isset($target->{$segment}),'c'=>$x=$target->{$segment},'d'=>isset($x)]);

Which results in the following output:
array:4 [ // vendor/laravel/framework/src/Illuminate/Collections/helpers.php:77
  "a" => Carbon\Carbon @1645155150^ {#3897
    #endOfTime: false
    #startOfTime: false
    #constructedObjectId: "0000000000000f390000000000000000"
    #localMonthsOverflow: null
    #localYearsOverflow: null
    #localStrictModeEnabled: null
    #localHumanDiffOptions: null
    #localToStringFormat: null
    #localSerializer: null
    #localMacros: null
    #localGenericMacros: null
    #localFormatFunction: null
    #localTranslator: null
    #dumpProperties: array:3 [
      0 => "date"
      1 => "timezone_type"
      2 => "timezone"
    ]
    #dumpLocale: null
    #dumpDateProperties: null
    date: 2022-02-18 14:32:30.0 +11:00
  }
  "b" => false
  "c" => Carbon\Carbon @1645155150^ {#3901
    #endOfTime: false
    #startOfTime: false
    #constructedObjectId: "0000000000000f3d0000000000000000"
    #localMonthsOverflow: null
    #localYearsOverflow: null
    #localStrictModeEnabled: null
    #localHumanDiffOptions: null
    #localToStringFormat: null
    #localSerializer: null
    #localMacros: null
    #localGenericMacros: null
    #localFormatFunction: null
    #localTranslator: null
    #dumpProperties: array:3 [
      0 => "date"
      1 => "timezone_type"
      2 => "timezone"
    ]
    #dumpLocale: null
    #dumpDateProperties: null
    date: 2022-02-18 14:32:30.0 +11:00
  }
  "d" => true
]

IE: "b" is false even though "a" shows that it returns a value.
I was able to resolve this by adding an __isset() method to my class, but I was thinking that this really should be fixed another way. Not sure if it is a bug with PHP?
Steps To Reproduce
Details above...

Did you try implementing ArrayAccess on your Message class? That's potentially workaround for the problem.
Not sure this is a framework issue really.

Hey there,
Can you first please try one of the support channels below? If you can actually identify this as a bug, feel free to open up a new issue with a link to the original one and we'll gladly help you out.

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

Thanks!


[site.entry-point] should not be a hard deprecation

When we were implementing support for entry points, we'd made [site.entry-point] a hard breaking deprecation, and were expecting people to rewrite their configs to add an entry point. But then we did add support for build.upload.main as a soft deprecation. Folks are worried about having to rewrite their code with wrangler2, and this specific usecase. We should make that field work, with a deprecation warning.

Fixed in https://github.com/cloudflare/wrangler2/pull/843


Transactional producer sending phantom messages

Following up with #682, I wanted to know why messages sent from our producer had evenly numbered offsets in kafka and why the high-watermark for that topic/partition was always NumberOfMessages+1.
So I created a simple topic:
bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test

Then I created a simple transactional producer, and admin to display watermark:
const { Kafka } = require('kafkajs')

const kafka = new Kafka({
  brokers: ['<IP_ADDRESS>:9092'],
  clientId: 'producer',
})

const config = {
  idempotent: true,
  maxInFlightRequests: 1,
  transactionalId: 'id',
}

const admin = kafka.admin()
const producer = kafka.producer(config)

const run = async() => {
  await admin.connect()
  await producer.connect()

  const transaction = await producer.transaction()
  try {
    await transaction.send({
      topic: 'test',
      messages: [
        { key: 'a', value: '1' },
      ],
    })
    await transaction.commit()
  } catch (ex) {
    await transaction.abort()
    console.log(ex)
  }

  const offsets = await admin.fetchTopicOffsets('test')
  console.log(offsets)

  await admin.disconnect()
  await producer.disconnect()
}

run().catch(console.error)

The first run of the code produced:
[ { partition: 0, offset: '2', high: '2', low: '0' } ]

The second produced:
[ { partition: 0, offset: '4', high: '4', low: '0' } ]

The third produced:
[ { partition: 0, offset: '6', high: '6', low: '0' } ]

As you can see, the offset and high watermark increments by two even though I'm only sending one message.
Next, I modified the code to use the producer to send the message:
...
  await producer.connect()

  try {
    await producer.send({
      topic: 'test',
      messages: [
        { key: 'a', value: '1' },
      ],
    })
  } catch (ex) {
    console.log(ex)
  }

  const offsets = await admin.fetchTopicOffsets('test')
  console.log(offsets)
...

The first run of the modified code produced:
[ { partition: 0, offset: '7', high: '7', low: '0' } ]

The second produced:
[ { partition: 0, offset: '8', high: '8', low: '0' } ]

The third produced:
[ { partition: 0, offset: '9', high: '9', low: '0' } ]

Now the offset and high watermark is only incrementing by one, as one would assume.
Consuming the topic from the beginning retrieves six messages (as expected since I sent 3 via transaction and 3 via producer):
const { Kafka } = require('kafkajs')

const kafka = new Kafka({
  brokers: ['<IP_ADDRESS>:9092'],
  clientId: 'consumer',
})

const topic = 'test'
const consumer = kafka.consumer({ groupId: 'test-group' })

const run = async() => {
  await consumer.connect()
  await consumer.subscribe({ topic, fromBeginning: true })
  await consumer.run({
    eachMessage: async ({ topic, partition, message }) => {
      const prefix = `${topic}[${partition} | ${message.offset}] / ${message.timestamp}`
      console.log(`- ${prefix} ${message.key}#${message.value}`)
    },
  })
}

run().catch(console.error)

Output:
- test[0 | 0] /<PHONE_NUMBER>604 a#1
- test[0 | 2] /<PHONE_NUMBER>837 a#1
- test[0 | 4] /<PHONE_NUMBER>956 a#1
- test[0 | 6] /<PHONE_NUMBER>105 a#1
- test[0 | 7] /<PHONE_NUMBER>091 a#1
- test[0 | 8] /<PHONE_NUMBER>388 a#1

I haven't looked at transactions in over a year (maybe closer to two), but unless I'm mistaken, when you call commit, what happens is that the transaction coordinator writes a transaction commit marker to the partition. A transaction commit marker is how a consumer knows whether or not a certain message has actually been committed or is currently part of an open transaction (or one that has been rolled back).
When a consumer reads from the partition, any message that does not have an associated transaction commit marker will not be returned to the user (assuming the client understands transactions and is configured to only read committed messages). So the phantom message you are talking about is that transaction commit marker.
You can verify this by publishing N messages within a single transaction before committing, and you should see the offset incrementing by N+1.
Feel free to re-open if I'm wrong about this, but I'm 95% sure that this is the case. You can read more about how transactions work here.


Fixed cluster violations chart to show accurate violation number

The cluster violations chart was displaying the total number of clusters as the number of clusters with violations
Ref: https://issues.redhat.com/browse/ACM-2535

/test all

This issue also affects other charts such as the ones in the governance overview, not sure if a separate issue should be filed for those or if I should just include them in this fix.

/cc @yiraeChristineKim

/cc @dhaiducek  @JustinKuli


Picker Popup not showing if it got attached in the DOM as part of a DOM-Tree with "display: hidden"

🐛 Bug Report
Attaching an Picker who is contained in an DOM-Tree who is "display: hidden" when added to the DOM fails to open the Picker Popup.
🤔 Expected Behavior
It does matter if the tree is hidden or not and the Picker Popup just opens
😯 Current Behavior
The Popup does not open appropriately (one just sees a thin line)

💁 Possible Solution

🔦 Context

💻 Code Sample
function Bug() {
  const [state, setState] = useState(0);

  return (

      <Picker label="Choose A">
        <Item key="rarely">A1</Item>
        <Item key="sometimes">A2</Item>
        <Item key="always">A3</Item>
      </Picker>

      <Picker label="Choose B">
        <Item key="rarely">B1</Item>
        <Item key="sometimes">B2</Item>
        <Item key="always">B3</Item>
      </Picker>

    <ActionButton onPress={() => setState(state + 1)}>Toggle</ActionButton>

);
}

Click Toggle and you should see something like shown in the screenshot above
🌍 Your Environment

Software
Version(s)

react-spectrum
master

Browser
FF / Chrome

Operating System
OS-X

🧢 Your Company/Team

🕷 Tracking Issue (optional)

Here's a codesandbox https://codesandbox.io/s/red-firefly-5975t
It seems as though it doesn't remeasure after initial render. So display none has a width of 0 when it's figuring out the overlay size. I've added a different case where the Picker size just changes to demonstrate this as well.

We might be able to add a useResizeObserver<EMAIL_ADDRESS>call in here to handle it https://github.com/adobe/react-spectrum/blob/main/packages/%40react-spectrum/picker/src/Picker.tsx
Where we observe the trigger size.


Export to BibTeX is Failing

Debug log ID
PWG3J5PA-euc/6.7.250-7
What happened?
Export to BibTeX is failing. Cannot create a basic export (no notes, etc.) and no errors appear.

This may be a visual bug, the Updated description in the auto export settings simply doesn't seem to update. The file itself does change modification time.
The file also updates on auto-export.
I will close this as I don't really care about the lack of visual update in settings. If anyone else wants that fixed, open a new issue. If the debug helps with this visual issue, here's another log:
9P29VLYB-euc/6.7.250-7

Manual exporting done 7 times


[REEF-880] Make logged and actual wait time consistent in Name Lookup…

… classes
Replaced the actual wait time with what was logged, as that seems to make more sense.
JIRA:
REEF-880
Pull request:
Closes #

Indeed, it seems more natural for wait time to increase linearly with the number of retries than to behave in a quadratic way, so log message seems more proper. I'll test and merge


WindowCommandButton + Flyout

I have four WindowCommandButton on the right side, and a flyout that is also on the right side, and it's modal. When the flyout is open, I'm able to click on the window command buttons behind the flyout.
I already set RightWindowCommandsOverlayBehavior="HiddenTitleBar" on the window.
Am I missing something? What can I do to disable the click event of these window command buttons?
Thanks.

@warffen just set the WindowButtonCommandsOverlayBehavior to hide the WindowCommandButton

@punker76 I have just tried all the options of WindowButtonCommandsOverlayBehavior and it didn't hide the WindowCommandButtons

@warffen which version of MahApps?

@punker76 1.1.3. I think I haven't expressed myself correctly as I wanted on the question. The WindowCommandButtons that stay behind the flyout are hidden, but the "home" that is not behind the flyout is still clickable.


Caliptra mailbox_data_avail output not registered

Hi Caliptra team,
The output port "mailbox_data_avail" of caliptra_top is not registered.
Will it glitch when sampled by external SoC on async clock ?
   I think better to add DFF here before output.

Best Regards
Derek Wang

Hi @Nitsirks ,
Any updates ?

Hi, @Nitsirks ,
Is it okay if I add one DFF after "mailbox_data_avail" and used registered output ?
Best Regards
Derek Wang


Testing a saga dispatching actions handled by another saga

Hello,
I'm trying to test a saga dispatching actions handled by another saga, and I can't seem to find how to make this work.
Tested saga
export function* initialize(action) {

    yield put(actions.loadingStart())

    // load & wait config
    yield put(configAccessor.fetch()) // <- this fire a FETCH action handled by datastoreSaga
    yield call(waitForState, configAccessor.isLoaded)
   ....
}

and the second :
function* datastoreSaga() {
    yield takeEvery(types.FETCH, fetchData);
    yield takeEvery(types.REFRESH, refreshData);
}

I tryed to simply
sagaTester.start(datastoreSaga);
sagaTester.start(initialize);

But that doesnt work, the datastoreSaga's takeEvery(types.FETCH) never calls it's fetchData saga.
Is it possible to test that kind of scenario ?

Are you calling it correctly? Is the fetch function action?
I am doing this and it works:
Tested saga
yield put(patientActions.fetchPatientPartners());
Patient actions
  type: types.PATIENT_FETCH_PATIENT_PARTNERS_REQUEST,
});```

Second saga

function* fetchPatientPartnersRequest() {
try {
const res = yield call(api.get, '/patientPractices');
}
}
function* watchPatientRequests() {
yield takeLatest(types.PATIENT_FETCH_PATIENT_PARTNERS_REQUEST, fetchPatientPartnersRequest);
}

I do not have to start second saga. I just need to start the first one.

@pgayvallet sagaTester.start takes a single saga (a generator function). You can spawn additional sagas from your root sagas. This pattern is similar to redux's reducers.
See here for additional information: https://redux-saga.js.org/docs/api/#middlewarerunsaga-args


Overload resolution ambiguity: Plugins { version(null) }

Overload resolution ambiguity:  public abstract fun version(p0: String?): PluginDependencySpec! defined in org.gradle.plugin.use.PluginDependencySpec public open fun version(p0: Provider<String!>!): PluginDependencySpec! defined in org.gradle.plugin.use.PluginDependencySpec

plugins { `kotlin-dsl`.version(null) }

What do you expect? Why did you pass null to version()? The current error is totally expected.

@blindpirate The parent project has applied kotlin-dsl. If I also apply kotlin-dsl in the child project, the following error will be thrown:

Caused by: org.gradle.api.GradleException: Error resolving plugin [id: 'org.gradle.kotlin.kotlin-dsl', version: '2.1.6']
at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:216)
... 163 more
Caused by: org.gradle.plugin.management.internal.InvalidPluginRequestException: Plugin request for plugin already on the classpath must not include a version

plugins {
    `kotlin-dsl` apply false
}

Please search before you ask: https://www.google.com/search?q=Plugin+request+for+plugin+already+on+the+classpath+must+not+include+a+version&oq=Plugin+request+for+plugin+already+on+the+classpath+must+not+include+a+version&aqs=chrome..69i57j69i64&sourceid=chrome&ie=UTF-8

@blindpirate I know this, but I think this is not what I want, the parent project should apply it, and this is not working:
For :root:foo build.gradle.kts
`plugins { kotlin; `kotlin-dsl` apply false }`

For :root:foo:bar build.gradle.kts
`plugins { kotlin; `kotlin-dsl` }`

org.gradle.internal.exceptions.LocationAwareException: Build file 'root/foo/bar/build.gradle.kts' line: 23
Error resolving plugin [id: 'org.gradle.kotlin.kotlin-dsl', version: '2.1.6']

Caused by: org.gradle.plugin.management.internal.InvalidPluginRequestException: Plugin request for plugin already on the classpath must not include a version
at org.gradle.plugin.use.resolve.internal.AlreadyOnClasspathPluginResolver.resolve(AlreadyOnClasspathPluginResolver.java:62)
at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:213)
... 163 more

But if I use:
id("org.gradle.kotlin.kotlin-dsl")
I meet the expected work, but the string is not easy to write, so I prefer kotlin-dsl version null


Razor components with generic type parameters @typeparam to implement generic type contraints

See generic type constraints in razor


ocean.py has 10 stale branches. Leverage? Remove?

ocean.py has 10 stale branches. All are >3 mos old, and most >6 mos old. See image below.
It's hard to maintain software - and software quality - with random branches hanging around.
TODO for this issue
For each branch:

identify if we do want to leverage the code at all
if "no", delete
if "yes", then find an appropriate way to take it to completion. Eg (a) merge in main, (b) create a fresh branch and bring over relevant changes, then get it merged in, (c) let go, don't bother with it, and do "no / delete" and perhaps mark the github issue as wontfix as well.

Stale Branches: link

I cleaned up the branches. From the list of stale branches, I only kepy the parameters.md one, that we know we want to revive someday.

I only kepy the parameters.md one, that we know we want to revive someday.

Looks like there are two stale branches still open. Besides the parameters.md one you mention, there's a "v3" one by David H-M. We should resolve that too.

Thanks for the info.
It's kind of annoying to have this sitting here as a branch. We could also fork it into a different repo. If we did that, do you see any issues, with usability or maintainability?

Thanks for the info.
It clutters up ocean.py to have this sitting here as a branch. We could also fork it into a different repo. If we did that, do you see any issues, with usability or maintainability?

I think the problem would be especially with overcrowding the list of repos. It's not just ocean.py, but also provider, aquarius, barge (and others, maybe) that have a v3 version.
We would also have to update PyPi directories and deployments to use the new repos, with everything that entails: credentials, secrets and configurations for running release builds and tests. PyPi and GitHub releases would then also consider these different packages, not different versions.
From a strictly code-related perspective, I think it moving all these repos would generate some manageable confusion with our users and impair some abilities to cherry-pick fixes when needed. However, I think this is a minor argument to make, and the arguments above are more potent here.
I think the decision to keep v3 as branches was a sane one.

Thanks for the thoughts. OK then!
At some point - when people have had enough time to move over to v4 - we can merely delete the branch. But no rush, at least 6 mos, possibly much longer.


Update unix-timestamp extension

Description

Screencast

Checklist

[ ] I read the extension guidelines
[ ] I read the documentation about publishing
[ ] I ran npm run build and tested this distribution build in Raycast
[ ] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

It would be amazing if this was part of the calculator, but if it is not, the second-best option is that I can make a quicklink to convert the selected timestamp. raycast://extensions/destiner/unix-timestamp/timestamp-to-date?arguments=%7B%22timestamp%22%3A%22{selection}%22%7D. I added this just for timestamp -> date and not for date -> timestamp as that is more complex for converting the selected text to a timestamp.

Hi!
Thank you for your contribution! My name is Milena and I will be reviewing it today.
We just added this to our calculator, so you should be able to create a QuickLink like this: raycast://extensions/raycast/calculator/calculator-history?fallbackText=now%20to%20timestamp. Not sure if the selection would work yet, but should be added soon if not.
Do you still want to continue with this PR? @Destiner what do you think?

wow, that is amazing! thank you for adding it to the calculator, it is super helpful! I guess we can close this pr :)


Performing a query on the extended custom user data

I've followed these (great) instructions and have added a custom field to my database. A common ask for people using this example might be: "How can I perform a lookup in the database to make sure my custom field is unique?". For example, if I have "DomainName" as a custom user data property in my registration, I don't want another user registering their unique data with another user's DomainName entity. Just like you can't create two users with the same email address; you get 'username is already taken'.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 431df4fc-4168-cc8f-d053-9b264d2971c1
Version Independent ID: cd157d04-d596-83fa-6edb-24d52193eb34
Content: Add, download, and delete custom user data to Identity in an ASP.NET Core project
Content Source: aspnetcore/security/authentication/add-user-data.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@HaoK 	can you suggest?

@HaoK can you suggest?

You can always just use linq on the Users IQueryable on the UserManager, i.e. userManager.Users.Where(u => o.DomainName == "whatever") and throw a similar error if more than one is found

@jasonshave  Any chance you could PR this fix? At the top right of the article, select the pen icon:

Select the pen icon again. Save.


[bug] Nuitka produces runtime TypeError with Pydantic's BaseModel

A module utilizing Pydantic's BaseModel class is compiled via Nuitka. The plain source code runs fine when executed in test_my_module.py, however the compiled code fails to pass. The resulting error when trying to invoke b.bar(bar_arg='some argument') causes the following exception. (Code is included down below in the body of the issue template).
Traceback (most recent call last):
  File "/home/[user1]/.pyenv/versions/3.9.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/[user1]/.pyenv/versions/3.9.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/mnt/c/Users/[user1]/github/nuitka-pydantic-bug/test_my_module.py", line 19, in <module>
    test_minimum_failure()
  File "/mnt/c/Users/[user1]/github/nuitka-pydantic-bug/test_my_module.py", line 8, in test_minimum_failure
    b.bar(bar_arg='some argument')
TypeError: bar() missing 1 required positional argument: 'self'

Nuitka version, full Python version, flavor, OS, etc. as output by this
command (it does more than you think, and we are adding more all the time):

python -m nuitka --version

(.venv) [user1]@LAPTOP:/mnt/c/Users/[user1]/github/nuitka-pydantic-bug$ python -m nuitka --version
<IP_ADDRESS>
Commercial: None
Python: 3.9.9 (main, Dec 29 2021, 12:20:17)
Flavor: pyenv
Executable: /mnt/c/Users/[user1]/github/nuitka-pydantic-bug/.venv/bin/python
OS: Linux
Arch: x86_64
Distribution: Ubuntu "16.04.6

How did you install Nuitka and Python

Installed via pip into a virtualenv (WSL Ubuntu). Also tested on plain Windows with pip + venv. Confirming that Python.exe is not from the Windows store.

The specific PyPI names and versions
It should be taken from this output if there specific packages involved, e.g.
numpy, you are expected to shorten this to the relevant ones.

python -m pip freeze

Nuitka==<IP_ADDRESS>
pydantic==1.9.0
typing_extensions==4.0.1

Many times when you get an error from Nuitka, your setup may be special
Then even a print("hello world") program will not work, please try that and report
that instead.

Confirming simple "hello world" works

Also supply a Short, Self Contained, Correct, Example

See here for the repo with the example below.
my_module/init.py:
from pydantic import BaseModel

class A:
    def foo(self, foo_arg):
        print(f'A.foo({foo_arg})')

class B(BaseModel):
    member_a: A

    def bar(self, bar_arg: str) -> None:
        self.member_a.foo(bar_arg)

    class Config:
        arbitrary_types_allowed = True

class B2:
    def __init__(self, member_a: A) -> None:
        self.member_a = member_a

    def bar(self, bar_arg: str) -> None:
        self.member_a.foo(bar_arg)

test_my_module.py:
import my_module as mm

def test_minimum_failure() -> None:
    a = mm.A()
    b = mm.B(member_a=a)
    print(f'b: {b}', type(b))
    print(f'b.member_a: {b.member_a}', type(b.member_a))
    b.bar(bar_arg='some argument')

def test_working() -> None:
    a = mm.A()
    b2 = mm.B2(member_a=a)
    print(f'b2: {b2}', type(b2))
    print(f'b2.member_a: {b2.member_a}', type(b2.member_a))
    b2.bar(bar_arg='some argument')

if __name__ == '__main__':
    test_working()
    test_minimum_failure()

Provide in your issue the Nuitka options used

python -m nuitka --module my_module --include-package my_module

Note if this is a regression
If it used to work in an earlier version of Nuitka, please note what you know
about that.

I have tried the following versions: `0.6.19rc8`, `<IP_ADDRESS>` and `<IP_ADDRESS>`

To expand on the above, the exact issue is that an instance of class B fails to execute b.bar(...)without passing in a reference to itself:
import my_module as mm

a = mm.A()
b = mm.B(member_a=a)

b.bar('some arg')    # raises `TypeError: missing positional argument 'bar_arg'`
b.bar(bar_arg='some arg')  # raises `TypeError: missing positional argument 'self'`
b.bar(b, 'some arg')    # Ok

Executing b.bar(b, 'some arg') with a reference to itself works as (un)expected...
It seems like a compiled class inheriting from BaseModel does not pass a self reference to the member's method. I'm not familiar with what Nuitka is doing under the hood, but hopefully all this info is helpful.

I am suspecting this is #471 which has a solution, check it out, will need 0.6.19 to be really good, but 0.6.18 series has something for it, but I definitely recommend to use develop for now. The 0.6.19 release is due soon.

Confirming that using nuitka 0.6.19rc9 with --experimental=function-base resolves the runtime error

You are spot on, to ask, this is indeed the solution, it's just that with the hotfix, some things work with it, and now all the things are supposed to work, and in fact it could be the baseline code if I was more daring. However I will probably want to make it on a develop branch with 0.6.20rc to gather feedback if that is really good. I am very conservative with Nuitka.

nuitka v0.6.19 using --clang , --experimental=function-base option and vs2022 compile error:
C:\Users\78081\AppData\Local\pypoetry\Cache\VIRTUA~1\KFCLIE~2.8\lib\SITE-P~1\nuitka\build\static_src\CompiledFrameType.c(544,5): error: initializer element is not a compile-time constant
    &PyFrame_Type, // tp_base
    ^~~~~~~~~~~~~
4 errors generated.
Backend C: 0%| | 0/556s
cons: *** [static_src\CompiledGeneratorType.obj] Error 1
static_src\CompiledFunctionType.c(523,5): error: initializer element is not a compile-time constant
    &PyFunction_Type, /* tp_base */
    ^~~~~~~~~~~~~~~~~~~
In file included from static_src\CompiledFunctionType.c:2722:
C:\Users\78081\AppData\Local\pypoetry\Cache\VIRTUA~1\KFCLIE~2.8\lib\SITE-P~1\nuitka\build\static_src\CompiledMethodType.c(526,5): error: initializer element is not a compile-time constant
    &PyMethod_Type, /* tp_base */
    ^~~~~~~~~~~~~~~~
2 errors generated.
Backend C: 0%| | 0/556s
cons: *** [static_src\CompiledFunctionType.obj] Error 1

clang component is: v143 build tool C++ Clang (x64/x86), Windows for C++ Clang compiler (12.0.0)
python version: v3.8.10 (x64)
pydantic: v1.9.0
typing_extensions: v4.0.1
If you do not inherit BaseModel, you can compile successfully without the --experimental=function-base option.

Ah, clangcl @hjzCy I might fix that up in a hotifx coming to 0.6.19, only MSVC proper seems to compile it at this time.

So, on factory and on coming hotfix, this is compiling just fine now: https://nuitka.net/doc/factory.html

Note, I am soon going to make this the default. I noticed it's missing checks for the method type however, I will want to add those first.

Hey Guys,
I am using the factory build of nuitka and still getting runtime issues.
Stacktrace:
  File "pydantic/main.py", line 228, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/fields.py", line 488, in pydantic.fields.ModelField.infer
  File "pydantic/fields.py", line 419, in pydantic.fields.ModelField.__init__
  File "pydantic/fields.py", line 528, in pydantic.fields.ModelField.prepare
  File "pydantic/fields.py", line 559, in pydantic.fields.ModelField._set_default_and_type
pydantic.errors.ConfigError: unable to infer type for attribute "cpu"

the variable looks like
    cpu: Optional[bool] = None

pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "setuptools_scm>=6.2", "https://github.com/Nuitka/Nuitka/archive/factory.zip"]
build-backend = "nuitka.distutils.Build"

setup.py
setup(
    packages=find_packages('src'),
    package_dir={'': 'src'},
    python_requires=">=3.8",
    install_requires=load_requirements(),
    extras_require={
        "dev": load_requirements("requirements-dev.txt"),
    },
    command_options={
        'nuitka': {
            '--experimental': 'function-base'
        }
    },
)

Do you have any idea how I might address this?

Looks good to me in terms of options @murphp15 not sure what's going on there, either the arguments are not passed correctly, or pydantic has another issue, can you provide a minimal reproducer without setuptools and much software used?

And also, if you have --show-scons in your options, it would show the command being executed, just to make sure the proper command line to Nuitka gets composed.

@kayhayen Is there files that we should be looking for in the build to indicate that this infer information has been kept?
Or is there a way we can explicitly add this info for pydantic?

Looks good to me @murphp15 so this might be another issue, unfortunately. If you wanted an NDA, consider getting in touch via https://nuitka.net/doc/commercial.html, and I could work on this within your environment. But without a reproducer, there is nothing I can do really except spending time on trying out random things, which is not how I can spend my time.

There were changes necessary for 3.10 to not crash with generators, it is currently the default on the factory branch and seems proven, but currently is held back by the other changes there not being yet entirely ready for release.

This is part of the 0.7rc1 pre-release on develop right now.

This is part of the 0.7 release now.


fixing issue to add comments in aclog

Fixes issue where comments are being sent to the proxy, but not being saved in aclog.

Thanks for your contribution.


redefine CMAKE_ABSOLUTE_DESTINATION_FILES to DESTDIR/root

Required to be able to redefine CMAKE_ABSOLUTE_DESTINATION_FILES
for sed preprocessing before installing this files into root system itself
It should be some prefix variable like CMAKE_ABSOLUTE_PREFIX ?= /
to use some temp directory
PS:
I'm forked to ponyatov/stlink and going to do
git checkout tags/1.4.0 -b ponyatov_140
is it be possible to send a pull request from ponyatov_140 branch?

make DESTDIR= install works without any changes

Great, thanks for reporting back.


csm time interpolation range

Changes
Describe changes in this PR
Related Issues
Closes #289
Checks

[x] updated CHANGELOG.md
[x] updated tests
[x] updated doc/
[x] update example/tutorial notebooks

it probably makes sense to implement this in the get_cs_on_edge method

Hello @CagtayFabry! Thanks for updating this PR.

In the file weldx/tests/test_transformations.py:

Line 6:1: F401 'typing.Iterable' imported but unused

Need to do some cleanup and update the docstrings of the CSM and LCS methods to reflect the new behavior, but apart from that this should be ready. You can already have a look. I am not sure if there is a way to merge some of the conditions in LCS.interp_time but I think there isn't much room for optimizations because coordinates and orientations are pretty independent of each other. Maybe we can put their individual interpolations into small internal functions, but that would be just code cosmetics.

I took a quick look and I think the implementation looks good (and pretty readable now with the Time class), no need to micro manage there I guess 👍
however for some of these larger if branches and longer functions I sometimes find it easier to have a few inline comments about the code (just for readability), I'll add an example

eventually we could also implement stuff like 'partially' overlapping times, so LCS.time = [0,1,2,3,4,5] and interp_time=[3,4,5,6,7,8,9] would give back LCS.time=[3,4,5] (I hope that makes sens 😉 )

I streamlined the behavior of interp_time so that it will also return a static system if only a single time value is passed. Before we had a time-dependent system with a single value. Now the time and the extra array dimension are stripped in that case.

eventually we could also implement stuff like 'partially' overlapping times, so LCS.time = [0,1,2,3,4,5] and interp_time=[3,4,5,6,7,8,9] would give back LCS.time=[3,4,5] (I hope that makes sens 😉 )

I think this will make stuff too complicated. It might be easy to implement in the LCS, but it will be a nightmare in the CSM. We would have to check for this case separately and broadcast the missing values for the multiplication. But this would also require figuring out how many values were stripped on either side of the returned array. I would leave it as is.

I streamlined the behavior of interp_time so that it will also return a static system if only a single time value is passed. Before we had a time-dependent system with a single value. Now the time and the extra array dimension are stripped in that case.

Maybe we can keep the time as a dimension but not coordinate of the dataarray, I'll take a look

eventually we could also implement stuff like 'partially' overlapping times, so LCS.time = [0,1,2,3,4,5] and interp_time=[3,4,5,6,7,8,9] would give back LCS.time=[3,4,5] (I hope that makes sens 😉 )

I think this will make stuff too complicated. It might be easy to implement in the LCS, but it will be a nightmare in the CSM. We would have to check for this case separately and broadcast the missing values for the multiplication. But this would also require figuring out how many values were stripped on either side of the returned array. I would leave it as is.
agreed

Maybe we can keep the time as a dimension but not coordinate of the dataarray, I'll take a look

I don't think that this makes sense.

Maybe we can keep the time as a dimension but not coordinate of the dataarray, I'll take a look

I don't think that this makes sense.

Thought it could be nice to keep some time information but also not really needed right now I guess

@CagtayFabry Funny thing: I can't require your approval because you created the PR, but I can approve myself 😉 So are we good to go?

Maybe we can keep the time as a dimension but not coordinate of the dataarray, I'll take a look

I don't think that this makes sense.

Thought it could be nice to keep some time information but also not really needed right now I guess

looked into it a little and I think it would be good to differentiate between xarray coords and dimensions more in our codebase (currently we mostly use coords which is probably not what we actually want)
I'll see about it in a separate PR


HDDS-5487. [Ozone-Streaming] BlockDataStreamOutput support FlushDelay.

What changes were proposed in this pull request?
Just as what we did in HDDS-3155. Streaming also need support FlushDelay. This part is similar to BlockOutputStream.
Currently, the default value for FlushDelay is true.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-5487

A failed CI is unstable in relation to OM. It has nothing to do with this patch. Let's merge this. Thanks @sadanand48 for the review.


network-chatflow: Please give option to choose the farm name to be used for your network

Currently it choose the nodes randomly and sometimes the access point ends in a node that does not have a routable IP.

add this feature in chatflow and libs:
Chatflow: https://github.com/threefoldtech/jumpscaleX_threebot/commit/0268075594310448ac1808aa12dc28ce313b1caf
libs: https://github.com/threefoldtech/jumpscaleX_libs/commit/868c8909bd13e3f8740844268f14aa48910a428c

verified


[INTERNAL] TaskUtil: Support specVersion 2.4

Coverage increased (+0.0007%) to 94.866% when pulling e5c9214e485ad56d94d310737f85766892955529 on support-specVersion-2.4 into a992f45cbf7d3de27a3eb7cb5f57d1920d817d45 on master.


"Gighera" "Nedeia" "Zăval" are listed in the drop-down menu

Description:
When user writes "Gighera" "Nedeia" "Zăval" the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Gighera"

Expected results
The location appears in the drop-down menu as "Sat Gighera, DOLJ (Gighera)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Nedeia"

Expected results
The location appears in the drop-down menu as "Sat Nedeia, DOLJ (Gighera)"


register new stream and API port for AzuraCast

A developer version should be made with the AzuraCast stream.
URLS are:
MP3:
https://azuracast.mahoro-net.org/listen/tsumugi/radio.mp3
API:
https://azuracast.mahoro-net.org/api/nowplaying/tsumugi
https://azuracast.mahoro-net.org/api/nowplaying_static/tsumugi.json << faster fetch
Goal: achieve the exact same features as it did before
Later on, I should:

update R/a/dio codebase to compile for API32 (just like the commits from here)
Add alarm sound preview on R/a/dio too
either make a new Tsumugi port from R/a/dio, or port existing features from R/a/dio back into Tsumugi

requested songs appearance (with colored text)
5 songs start history
request songs with HTTPS PUT (quite complex)
probably even moar stuff?

yup done


vm_state = "started" parameter causes changes on every apply for default_ipv4_address, ssh_host and ssh_port

System details:

Proxmox VE 8.2.2
Terraform v1.8.5
terraform-provider-proxmox v3.0.1-rc2

I want to use exactly this vm state started and its describe behavior in documentation for vm_state:

Do note that started will only start the vm on creation and won't fully manage the power state unlike running and stopped do.

Feature introduced https://github.com/Telmate/terraform-provider-proxmox/issues/955 https://github.com/Telmate/terraform-provider-proxmox/issues/893
Unfortunately, started value causes changes on every terraform apply for default_ipv4_address, ssh_host and ssh_port:
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # proxmox_vm_qemu.cloud_vm_from_packer_template will be updated in-place
  ~ resource "proxmox_vm_qemu" "cloud_vm_from_packer_template" {
      + default_ipv4_address   = (known after apply)
        id                     = "***/qemu/***"
        name                   = "***"
      + ssh_host               = (known after apply)
      + ssh_port               = (known after apply)
        tags                   = "***"
        # (62 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Tried to change define_connection_info to false, no success, the same behavior.
Tried to add in lifecycle ignore_changes for default_ipv4_address, ssh_host and ssh_port, but causes warning:
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
╷
│ Warning: Redundant ignore_changes element
│
│   on main.tf line 42, in resource "proxmox_vm_qemu" "cloud_vm_from_packer_template":
│   42: resource "proxmox_vm_qemu" "cloud_vm_from_packer_template" {
│
│ Adding an attribute name to ignore_changes tells Terraform to ignore future changes to the argument in configuration after the object has been created, retaining the value originally configured.
│
│ The attribute default_ipv4_address is decided by the provider alone and therefore there can be no configured value to compare with. Including this attribute in ignore_changes has no effect. Remove the attribute from ignore_changes to quiet this warning.
│
│ (and 2 more similar warnings elsewhere)

Is this expected and normal behavior for this case or is it a bug?
Note, vm_state = "running" do not cause such behavior and works as expected.

@Tinyblargon,
What is your thoughts on this topic?

@maksimsamt, this definitely is a bug. But since it's only an inconvenience and not a breaking bug, I'm putting this in the backlog.


Allow for more project-level customization

This would be a fairly big update that allows a project to customize the behavior of the app more. Some examples of the types of customizations that we'd like to have:

When a Workspace of a specific type is created, automatically create an auth domain for that workspace with a related name.
Automatically add a specific group to any ManagedGroup that is created in the all.
Automatically share a Workspace of a specific type with a specific ManagedGroup.
...etc.

This change involves adding new adapter methods (e.g., before_django_create, before_anvil_create, after_django_create, after_anvil_create, etc) and then using them throughout the views or model methods.

Partially addressed in #499 for workspaces


ChainEndpoint has no way to signal readiness

Summary
The ChainEndpoint trait defining a backend has no way to signal readiness to the rest of the application, causing problems for stateful backends.
Problem Definition
The ChainEndpoint trait defines the interface between Hermes' execution core and a pluggable, chain-specific backend.
The existing backend, for CosmosSDK chains, is stateless: all state required for the relayer is fetched on demand via RPC. This works because the state is maintained on a fullnode, which has visibility into all state.
For Penumbra, the context is different. Penumbra only has shielded transactions, and user data is not visible to full nodes. Instead, Penumbra clients must scan and synchronize the subset of chain data visible to their user.  This functionality is provided by a "view server", akin to a micro-node responsible for syncing and indexing just a single user's data. The Rust implementation of the view server is intended to be usable as a library that can be pulled into other programs as an off-the-shelf component.
To pay fees, a Penumbra relayer must perform shielded spends. To perform shielded spends, the relayer must know what funds it has available, and to learn that, it must sync with the chain. While we've put considerable effort into making this fast, it's not instant.
Thus, we'd ideally like to have a way for the ChainEndpoint to signal readiness to the rest of the application. The CosmosSDK endpoint could return readiness immediately, while the Penumbra endpoint would wait to scan to the current chain tip.
However, it's not clear how best to augment the ChainEndpoint trait to provide this. The code structure is a little confusing, since the ChainEndpoint trait presents a synchronous API, which may internally do async operations, and is invoked through a bespoke message passing system. (While changing this design is out of scope for this issue, it might be worth considering a pure-async design, or perhaps this is already considered, I don't know)
Proposal
???
Acceptance Criteria

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

While changing this design is out of scope for this issue, it might be worth considering a pure-async design, or perhaps this is already considered, I don't know

We are indeed working on an async-first (or perhaps even async-generic) re-implementation of Hermes which we call Hermes SDK, which will become the foundation for Hermes v2.
It is still very early and very much in flux at the moment, but we expect that this new architecture will make it much easier to add support for non-SDK chains in the future.


[RFC] Metrics Framework

Is your feature request related to a problem? Please describe.
Feature Request https://github.com/opensearch-project/OpenSearch/issues/1061
Feature Request https://github.com/opensearch-project/OpenSearch/issues/6533
PR - https://github.com/opensearch-project/OpenSearch/pull/8816
Describe the solution you'd like
Problem Statement
The current OpenSearch stats APIs offer valuable insights into the inner workings of each node and the cluster as a whole. However, they lack certain details such as percentiles and do not provide the semantics of richer metric types like histograms. Consequently, identifying outliers becomes challenging. OpenSearch needs comprehensive metric support to effectively monitor the cluster. Recent issues and RFCs have attempted to address this in a piecemeal fashion, and we are currently engaged in a significant effort to instrument OpenSearch code paths. This presents an opportune moment to introduce comprehensive metrics support.
Tenets

Minimal Overhead – Metrics should not impose minimal overhead on system resources such as CPU and memory.
No performance impact – Metrics should not adversely affect cluster operations in terms of performance.
Extensible – The metrics framework should be easily extendable to accommodate background tasks, plugins, and extensions.
Safety - The framework must ensure that instrumentation code does not result in memory leaks.
Well defined Abstractions – Metrics frameworks should offer clear abstractions so that changes in implementation framework or API contracts do not disrupt implementing classes.
Flexible – There should be a mechanism for dynamically enabling/disabling metrics through configurable settings.
Do not reinvent - We should prefer to use out of the box solutions available instead of building something from scratch.

Metrics Framework
It is widely recognized that observability components like tracing and metrics introduce overhead. Therefore, designing the Metrics Framework for OpenSearch requires careful consideration. This framework will provide abstractions, governance, and utilities to enable developers and users to easily utilize it for emitting metrics. Let's delve deeper into these aspects: –

Abstractions - While metrics frameworks like OpenTelemetry can be leveraged, we will abstract the solution behind the OpenSearch APIs. This future-proofs the core OpenSearch code where metrics are added, reducing the need for changes. Hooks for metrics have already been included in the Telemetry abstraction, following a similar pattern as the TracingTelemetry implementation.
Governance - Similar to tracing, we should define mechanisms for enabling and disabling metrics at multiple levels.
Code Pollution - To mitigate code pollution, we should provide utilities such as SpanBuilder to abstract away repetitive boilerplate code.

HLD

Metric APIs - The Metrics API will facilitate the creation and updating of metrics. It should handle most of the heavy lifting and abstract the need for boilerplate code.

public interface Meter extends Closeable {

    /**
     * Creates the counter. This counter can increase monotonically.
     * @param name name of the counter.
     * @param description any description about the metric.
     * @param unit unit of the metric.
     * @return counter instrument.
     */
    Counter createCounter(String name, String description, String unit);

    /**
     * Creates the up/down counter. Value for this counter may go up and down so should be used
     * at places where negative, postive and zero values are possible.
     * @param name name of the counter.
     * @param description any description about the metric.
     * @param unit unit of the metric.
     * @return up/down counter instrument.
     */
    Counter createUpDownCounter(String name, String description, String unit);

    /**
     * Creates the histogram instrument which is needed if some values needs to be recorded against
     * some buckets, samples, etc.
     * @param name name of the counter.
     * @param description any description about the metric.
     * @param unit unit of the metric.
     * @return histogram instrument..
     */
    Histogram createHistogram(String name, String description, String unit);

    /**
     * Creates the Gauge which helps in recording the arbitrary/absolute values like cpu time, memory usage etc.
     * @param name name of the counter.
     * @param description any description about the metric.
     * @param unit unit of the metric.
     * @return counter.
     */
    Gauge createGauge(String name, String description, String unit);
}

Storage - Metrics data need not be emitted with each event or request. Instead, they should be stored or buffered (like async loggers) and aggregated over a configurable time frame in an in-memory store before periodic emission.
Sink - Periodically emitted metrics should be written to a configurable sink. Users should have the flexibility to define their preferred sink.

Implementation
OpenTelemetry offers decent support for metrics, and we can leverage the existing telemetry-otel plugin to provide the implementation for metrics as well.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

 As a start, will we be able to get an implementation that logs a bunch of counters for every HTTP request, so we'll be able to do out-of-process aggregation / computation of percentiles?
The current stats-based approach that uses global (or per-node, per-index, per-shard) counters obscures a lot of useful information. For example, maybe I see stats showing that we're spending a lot of time doing thing A and a lot of time doing thing B. Are we spending a lot of time doing A and B in the same requests? Are some requests spending time on thing A, while other requests are spending time on thing B? Was there only once request that spent a really long time doing thing B?
Request-level collection of counters would be extremely useful.

@Gaganjuneja thanks for putting this one up

public interface Meter extends Closeable {

I believe we should rename it to MeterRegistry or MetricRegistry since Meter is usually an individual metric. But that is minor,  what worries me a lot is the amount of the abstractions we will have to introduce to facade the different metric providers (Otel, Dropwziard, Micrometer, ....), I believe it is going to be massive.

 As a start, will we be able to get an implementation that logs a bunch of counters for every HTTP request, so we'll be able to do out-of-process aggregation / computation of percentiles?
The current stats-based approach that uses global (or per-node, per-index, per-shard) counters obscures a lot of useful information. For example, maybe I see stats showing that we're spending a lot of time doing thing A and a lot of time doing thing B. Are we spending a lot of time doing A and B in the same requests? Are some requests spending time on thing A, while other requests are spending time on thing B? Was there only once request that spent a really long time doing thing B?
Request-level collection of counters would be extremely useful.

Yes, we can generate the Request level counters and connect the traces with metrics to see both aggregated and request level view.

As a start, will we be able to get an implementation that logs a bunch of counters for every HTTP request, so we'll be able to do out-of-process aggregation / computation of percentiles?

@msfroh could you give an example of what kind of counters for every HTTP request you are looking for?

For example, maybe I see stats showing that we're spending a lot of time doing thing A and a lot of time doing thing B

I believe with traces you should naturally get that, since A and B should be denoted by span or span hierarchy.

Yes, we can generate the Request level counters and connect the traces with metrics to see both aggregated and request level view.

@Gaganjuneja To be fair, I really doubt that is we could (and even should), however we could add events + attributes to the spans and than query / aggregate over them as need.

@Gaganjuneja To be fair, I really doubt that we could (and even should) do that, however we could add events + attributes to the spans and than query / aggregate over them as need.

Yes, we can do that only challenge comes here is with sampling.

@Gaganjuneja thanks for putting this one up

public interface Meter extends Closeable {

I believe we should rename it to MeterRegistry or MetricRegistry since Meter is usually an individual metric. But that is minor, what worries me a lot is the amount of the abstractions we will have to introduce to facade the different metric providers (Otel, Dropwziard, Micrometer, ....), I believe it is going to be massive.

I totally agree with you @reta here. We can start small and keep on adding the instruments based on the requirements. Like for now we can just start with counter and keep in facade simple as shown in the interface. I understand the above interface is motivated from the Otel schema but we should be able to implement it for most of the metering solutions.

@msfroh could you give an example of what kind of counters for every HTTP request you are looking for?

You bet! If I could have my every per-request metrics record wish granted, it would include things like (in priority order):

Overall request latency
Counters related to the search request (query clause count, 0/1 counter on presence of various features -- different aggregations, collapse, rescore, etc, request source size in bytes).
Counters related to the search response (total hits, hits returned, number of aggregation buckets in the response, response size in bytes).
A 0/1 failure counter.
Latency of each search phase.
0/1 failure counters for each search phase.
Shard success/failed counters for each search phase.
Total CPU cost of the request.
CPU cost broken down by search phase, per shard.

And of course, I would love to be able to correlate all of this back to the original query (not necessarily from a time series system, since I would expect that to store aggregate histograms of counters, but I should be able to fetch the raw logs that were aggregated for ingestion into the time series data store).

Overall request latency
Latency of each search phase.

This is the goal of tracing - you get out of the box

Counters related to the search request (query clause count, 0/1 counter on presence of various features -- different aggregations, collapse, rescore, etc, request source size in bytes).
Counters related to the search response (total hits, hits returned, number of aggregation buckets in the response, response size in bytes).
A 0/1 failure counter.

Those could be attach to each span

Total CPU cost of the request.
CPU cost broken down by search phase, per shard.

This could extremely difficult and expensive to track but we do try to track the CPU cost of search task per shard, that could be attached to task spans as well.

@reta -- so all my wishes can potentially be granted? Can I have a pony too? 😁

haha @msfroh one more

And of course, I would love to be able to correlate all of this back to the original query (not necessarily from a time series system, since I would expect that to store aggregate histograms of counters, but I should be able to fetch the raw logs that were aggregated for ingestion into the time series data store).

Trace ids could be (and should be) in logs so it should be possible to correlate all logs for specific trace and request

Overall request latency
Latency of each search phase.

This is the goal of tracing - you get out of the box

Counters related to the search request (query clause count, 0/1 counter on presence of various features -- different aggregations, collapse, rescore, etc, request source size in bytes).
Counters related to the search response (total hits, hits returned, number of aggregation buckets in the response, response size in bytes).
A 0/1 failure counter.

Those could be attach to each span at the relevant subflow

Total CPU cost of the request.
CPU cost broken down by search phase, per shard.

This could extremely difficult and expensive to track but we do try to track the CPU cost of search task per shard, that could be attached to task spans as well.

This information is already available as part of TaskResourceTracking framework which can be reused. Not sure if this should be attached as an event or attribute to the span.
Only use case where we need the metric and trace integration is - Let's say we have a one metric graph for HttpStatusCode and it shows peek for statusCode=500 now we may want to see all the requests failed during this peek Now,

If a metric has traceIDs associated, it can immediately pull those traces and we should be able to figure out the reason hopefully.
We can query the traces for that time range and with httpStatuCode=500 and do the evaluation.

So, I agree we should be able to handle the storage side instead of integrating in the server because the sampling issue still persists there as well.

Hi @reta
I've been exploring various metric solutions and their suitability for our use cases. While these tools employ distinct methods for metric collection, there are still some common elements. Let's delve into the various types of meters available:

Counters
Counters are relatively straightforward, with most of them sharing a common set of parameters. One significant difference lies in how some tools handle counters for incrementing and decrementing values. Therefore, it might be beneficial to maintain two different counter types for increasing values and values that can move both up and down.

a.    Increasing Counters
Counter createCounter(String name, String description, String unit);
b.    UpDown Counters
 Counter createUpDownCounter(String name, String description, String unit);
There's also a variation involving asynchronous counters that require a callback and operate at a specific cadence, which we can incorporate later based on our use cases.

Timer/Histogram
Metrics related to time, such as latencies, exhibit variations in implementation and differing opinions among tools. For instance, OpenTelemetry (OTel) generalizes these as Histograms, whereas other tools like Micrometer and Dropwizard provide a dedicated timer interface for latency metrics, though they function similarly to histograms. Differences may still exist in how quantiles are handled, but we can maintain consistent API signatures by following the structure below. If we implement the Histogram API, it can serve as a generic solution for all bucket-based aggregations.

Histogram createHistogram(String name, String description, String unit, List<Double> buckets);

Gauges
Gauges follow a similar structure, but each tool has its unique implementations and classes. To standardize this, we can use the following signature, which defines a natural schema for Gauge metrics and can be adapted for different tools.

Gauge createGauge(String name, Observable observable, String description, String unit);
Given the clarity around counters, I propose that we commence by implementing support for counters first and then gradually expand the framework. I would appreciate your thoughts on this.

Given the clarity around counters, I propose that we commence by implementing support for counters first and then gradually expand the framework. I would appreciate your thoughts on this.

Sure, it make sense, thanks @Gaganjuneja, counters are the most basic metric out of all, would be great to unify API to support labels / tags / ... and other meta concepts than are applicable to all metrics.

@reta
I have analyzed the histogram/timer support in different solutions like otel, dropwizard and Micrometer and based on that I am proposing the following APIs for histogram.
Histogram createHistogram(String name, String description, String unit);
This is a generic api where the histograms buckets can be automatically provided by the implementation. Most likely we can go for exponential histogram gram createHistogram(String name, String description, String unit, List buckets);) gram createHistogram(String name, String description, String unit, List buckets);) in case of OpenTelementry.
Histogram createHistogram(String name, String description, String unit, List<Double> buckets);
Here, users can provide their own list of explicit buckets. This gives more control to the user in case they want to track the specific boundary ranges.

Thanks @Gaganjuneja , I am unsure this is sufficient to understand what you are suggesting, what is Histogram? Could you please share something complete?

Understanding the distribution of response times or OpenSearch operation is crucial for assessing performance. Unlike average or median values, percentiles shed light on the tail end of the latency distribution, offering insights into user experience during extreme scenarios. For example, the 95th percentile represents the response time below which 95% of requests fall, providing a more realistic reflection of the typical user experience than average latency alone. This information is invaluable for system administrators and developers in identifying and addressing performance bottlenecks.
Various methods exist for calculating percentiles, with one straightforward approach involving the computation of several percentiles based on all data points. However, this method can be resource-intensive, requiring access to all data points. Alternatively, the use of a Histogram is an option. A Histogram stores the frequencies of different ranges or bins of values in a dataset.
Constructing a histogram typically involves the following steps:

Data Binning:

The range of values in the dataset is divided into contiguous and non-overlapping intervals or bins.

Counting Frequencies:

The number of data points falling within each bin is counted.

Plotting:

Bins are represented on the horizontal axis, with corresponding frequencies (or percentages) plotted on the vertical axis.
The height of each bar reflects the frequency of data points in that bin.

Histograms are particularly useful for visualizing the distribution of continuous data, providing insights into central tendency, spread, skewness, and potential outliers. Patterns such as normal distribution, skewed distribution, or bimodal distribution can be easily identified, aiding in data interpretation.
In OpenTelemetry, histograms are a metric type that allows observation of the statistical distribution of a set of values over time, offering insights into spread, central tendency, and data shape.
Other telemetry tools like Dropwizard and Micrometer also support histograms. The major difference lies in how they define buckets:

Otel provides two approaches: a) explicit bucketing, where users define their buckets, and b) exponential bucketing, where Otel automatically fits the distribution in a fixed number of buckets using scale and max buckets factor.
Dropwizard uses an exponentially decaying reservoir to sample values for histograms, allowing efficient estimation of quantiles.
Micrometer uses dynamic bucketing, adjusting bucket sizes automatically based on observed values.

To unify Histogram APIs across implementations, the following APIs are proposed:
Automatic Buckets approach - A generic API where histogram buckets are automatically provided by the implementation, likely following the exponential histogram option from Otel.
Histogram createHistogram(String name, String description, String unit);

Explicit bucket approach - Users can provide their list of explicit buckets, offering more control in tracking specific boundary ranges.
Histogram createHistogram(String name, String description, String unit, List<Double> buckets);

Thanks for details, but I still don't see the API, what is Histogram in Histogram createHistogram(String name, String description, String unit, List<Double> buckets);? Could you please share the complete API skeleton to understand what the capabilities we would like to support. Thank you

Thanks for details, but I still don't see the API, what is Histogram in Histogram createHistogram(String name, String description, String unit, List<Double> buckets);? Could you please share the complete API skeleton to understand what the capabilities we would like to support. Thank you

Sure, I took it literally :)

As mentioned above CreateHistogram will create the Histogram metric instrument.
Histogram is a metric Instrument like Counter which will help in recording the values and build the histogram underneath. For now, this will be implemented to delegate the record calls to Otel.
public interface Histogram {

    /**
     * record the value.
     * @param value value to be recorded.
     */
    void record(double value);

    /**
     * record value along with the tags.
     *
     * @param value value to be recorded.
     * @param tags  attributes/dimensions of the metric.
     */
    void record(double value, Tags tags);

}

@reta, your thoughts here?

@reta, your thoughts here?

I am trying to figure out 2 things here:

Not all metric providers allow to parameterize buckets
Adding tags per value void record(double value, Tags tags); (the same applies to Counters) looks very unique to OpenTelemetry Metrics (none of others support it). How does it work?

Not all metric providers allow to parameterize buckets

Yes, most of the tools provide the dynamic bucketing or percentile calculations. We can also for now keep the API simple and provide the metric provider level config. We can live with one single API for now.
Histogram createHistogram(String name, String description, String unit);

Adding tags per value void record(double value, Tags tags); (the same applies to Counters) looks very unique to OpenTelemetry Metrics (none of others support it). How does it work?

Yes, more generalised in Otel but we need this feature to create the dimensions based on data like index name or shardId etc. There are ways to achieve this in other tools by overriding the metricsRegistry and storage where we can explicitly keep the metrics at dimension level. Otel provides this out of the box.

Yes, more generalised in Otel but we need this feature to create the dimensions based on data like index name or shardId etc.

The purpose of tags is clear but this is usually done on per meter level. I am trying to understand how does it work on value level - would it be represented by multiple meters at the end?(we would need to add the javadocs to explain the behaviour anyway)

Got it, thank you, I think we are good to go with Histograms :)

Extending it further to add support for Gauge which is a current value at the time it is read. Gauges can be synchronous as well as asynchronous.
Synchronous Gauge -  Synchronous Gauge is normally used when the measurements are exposed via a subscription to change events.
Asynchronous Gauge - When the measurement is exposed via an accessor, use Asynchronous Gauge to invoke the accessor in a callback function
I think, Asynchronous Gauge make more sense in our use cases to record the resource utilisation in periodic manner. It can also be used to capture queue size at any point in time etc. Anyways synchronous Gauge is experimental in open telemetry (refer otel discussion - https://github.com/open-telemetry/opentelemetry-java/discussions/6272)
Proposed API -
ObservableGauge createObservableGauge(String name, String description, String unit, ObservableInstrument observableInstrument);

ObservableInstrument
public interface ObservableInstrument {

    /**
     * Value supplier
     * @return supplier
     */
    Supplier<Double> getValue();

    /**
     * tags
     * @return tags
     */
    Tags getTags();

}

ObservableGauge
public interface ObservableGauge {

    /**
     * removes the registered Observable
     */
    void remove();

}

@reta, your thoughts here?

@Gaganjuneja hm ... the gauge part is looking like an option, but I believe we should not be driven by OTEL APIs but keep out APIs consistent instead:
Disposable createDoubleGauge(String name, String description, String unit, Supplier<Double> valueProvider, Tags tags);

The Disposable could be modelled after reactor.core.Disposable  & Co (reactive streams) - it is not specific to gauge (or any meter in general), but indicates a general resource (meter in this case) with explicit lifecycle.

Thanks @reta for reviewing.

Agree on Disposable/Closable.
Tags - Gauge is a asynchronous meter. Asynchronous counters would also have similar signature. As it's going to be registered and scheduled so tags per value would remain same. To make the API consistent we will have to provide that either as part of supplier or the way you suggested.

I think we can go ahead with this for now.
Disposable createDoubleGauge(String name, String description, String unit, Supplier<Double> valueProvider, Tags tags);

Thanks @Gaganjuneja

Agree on Disposable/Closable.

Using Closable would be preferred I think - we could use the Java standard library

Greetings @Gaganjuneja
Kindly is there a way currently to export metrics/spans to signoz?
I mean the configuration currently in the docs states that grpc only export to localhost, is there a way to configure opensearch to export metrics/spans to specific endpoint i.e. configurable URL for a remote collector. ?
Thank you.

external signoz we can do through local signoz/otel collector for now. We can externalise this property as a config.

@Gaganjuneja
also I want add that we tried to configure metrics and spans on local log files, the files are being created but no logs are added into those files, both kept empty even when executing some queries on indices.
we followed the documentation step by step and configured everything related.
any suggestions ?
opensearch is deployed with helm chart, we tested it on version 2.12 and 2.13
Thank you.

@zalseryani strange. Could you please share the exact steps you followed and the value for the following settings

telemetry.tracer.enabled
telemetry.feature.tracer.enabled

Hi,
I am trying to understand integration with Prometheus.
As far as I understand Prometheus strongly prefers a pull model (ie. Prometheus server is the one to scrape the target node(s)), although there seem to be ways how to push metrics to Prometheus this comes with operational and configuration overhead and usually requires sidecar instances.
What is the plan to enable integration with Prometheus? What is the role of the Collector box in the schema above? Is that any "user managed" component? Is that the component that would be scraped by Prometheus or the one that would eventually push metrics to Prometheus?
What is the function of Periodic exporter? Does it periodically push in memory cache of collected metrics to Collector?
When metric store/sink requires specific format of the data who and when is responsible for the conversion?

@Gaganjuneja
Thank you for your time, we were missing the second config you shared with us telemetry.feature.tracer.enabled, but it is worth noting that this one was not mentioned in the docs.

also we found another typo in the docs related to the traces class for grpc protocol, it is mentioned incorrectly, and it should be io.opentelemetry.exporter.otlp.metrics.OtlpGrpcMetricExporter instead of this org.opensearch.telemetry.tracing.exporter.OtlpGrpcSpanExporterProvider , because if we use the first one, get the following error in opensearch logs that the following class was not found.

uncaught exception in thread [main]
java.lang.IllegalArgumentException: Failed to parse value [org.opensearch.telemetry.tracing.exporter.OtlpGrpcSpanExporterProvider] for setting [telemetry.otel.tracer.span.exporter.class]
Likely root cause: java.lang.ClassNotFoundException: org.opensearch.telemetry.tracing.exporter.OtlpGrpcSpanExporterProvider
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
	at java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:872)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at org.opensearch.telemetry.OTelTelemetrySettings.lambda$static$0(OTelTelemetrySettings.java:86)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
	at org.opensearch.telemetry.OTelTelemetrySettings.lambda$static$1(OTelTelemetrySettings.java:84)
	at org.opensearch.common.settings.Setting.get(Setting.java:483)
	at org.opensearch.common.settings.Setting.get(Setting.java:477)
	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:644)
	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:549)
	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:519)
	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:489)
	at org.opensearch.common.settings.SettingsModule.<init>(SettingsModule.java:178)
	at org.opensearch.node.Node.<init>(Node.java:591)
	at org.opensearch.node.Node.<init>(Node.java:417)
	at org.opensearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:242)
	at org.opensearch.bootstrap.Bootstrap.setup(Bootstrap.java:242)
	at org.opensearch.bootstrap.Bootstrap.init(Bootstrap.java:404)
	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:181)
	at org.opensearch.bootstrap.OpenSearch.execute(OpenSearch.java:172)
	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:104)
	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138)
	at org.opensearch.cli.Command.main(Command.java:101)
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:138)
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:104)
For complete error details, refer to the log at /usr/share/opensearch/logs/docker-cluster.log

One more thing please, regarding the GRPC traces with remote connection (instead of localhost) you told me in the upper comment that We can externalize this property as a config, is configurable now or you meant to be done in the future ?

Appreciating your time and efforts :)

@zalseryani, Thanks for your note. We can do it in the upcoming release. Would you mind creating an issue for this?


Content is collapsed when a TextInput is focused in KeyboardAwareScrollView container on Android

Android 6.0

@anisa07 since no explanation was left, and your description was the best articulation of the problem I was just facing, my solution wound up being:
enableAutomaticScroll={(Platform.OS === 'ios')}
That prop was making everything collapse instead of pan on Android.


Changed eableCyclomaticComplexity to generateAdditionalMetrics

Changes
Changed default parameter enableCyclomaticComplexity to generateAdditionalMetrics for default coverage options.
Responding to the update in the logs I forgot to update pointed out by @nikosatwork thanks for the catch! comment link

The enableCyclomaticComplexity option has been replaced with the generateAdditionalMetrics option since version 0.3.0 of the Code Coverage package
Source<EMAIL_ADDRESS>
And updated version of codecoverrage package in example project to be v1.1.1 since it's the most recent non-experimental release.
Checklist

[x] Read the contribution guide and accept the code of conduct
[x] Readme (updated or not needed)
[x] Tests (added, updated or not needed)

Great! Thanks for the follow-up.


fix NullPointerException during Import using the BikeCommonFlagEncoder

As it is stated in the AbstractFlagEncoder, the protected method init() should be called as the last action in the constructor.
I was getting NullPointerExceptions on line 278 in the BikeCommonFlagEncoder resulting in "Problem while parsing file"-Exceptions.
The NPE was caused by the "getConditionalTagInspector" returning null.
Calling the init()-Method at the end of the constructor initializes the ConditionalTagInspector. Now I can import again :-)
Hope this helps :-)
Feedback very welcome!
Grüße aus Stuttgart/München :-)

no wait... maybe the BikeCommonFlagEncoder should be abstract? The BikeFlagEncoder inherits from this...

Ok, there is a problem with my solution: The BikeFlagEncoder inherits from BikeCommonFlagEncoder, thus the BikeCommonFlagEncoder must not call init(). It seems as if the BikeCommonFlagEncoder should be abstract.

It seems as if the BikeCommonFlagEncoder should be abstract

Probably yes. What do you think @ratrun ?

I agree. BikeCommonFlagEncoder should be abstract.

Shall I issue a new pull request with the abstract BikeCommonFlagEncoder?

favor pull-request "Make BikeCommonFlagEncoder abstract" over this pr. Closing this.


Create documentation for devices

The devices/inventory file format is a little different from the ITF format. Some documentation would be nice.

I would say the documentation has taken great strides forward.


Update pt_BR.lang

oooooops... sorry ('Dano do Item' corrigido)

Looks like I missed this for a while, sorry


[Candidate 1v1 Blue Hole ZH v1] Infantry cannot enter bunker at the top right

Observed behaviour
Infantry cannot enter bunker at the top right.
Expected behavior
Infantry can enter bunker at the top right.
Screenshots

fixed


Pin your note

Pin Your Note
Project Details: We get so many ideas throughout the day and it’s a common nature of human that we forget the things very easily (even the important ideas or thoughts) due to our busy schedule or for some other reason. To remember things easily isn’t it a good idea to make an app that create a note of our ideas online? Using Python you can build a Pin Your Note application where a user can list out all the things he/she wants to remember and that list will be accessible from anywhere (since it is on a digital platform).

I am going to start my work, please assign to me


Update null feature parsing logic

About the changes

I was trying out Unleashed for the first time (product is awesome!) but noticed features would never become enabled in the Rust client. I noticed if I only had features with descriptions things did work, and tracked it down to the poller failing to parse the features from json. Not relevant to the Rust sdk but it does seem like if you create a new feature and don't give a description, the field is null in the json response, but if you create it with a description but then erase the description and save it, it returns "" instead of null.
In any case, the description field on a feature can be null - when it is null it fails to parse since it's represented by a String in the Rust representation.
The obvious way to fix this would be just changing description: String to description: Option<String>, but it does seem like it was intentional since there are other optional fields and it has a #[serde(default)] attribute. Maybe someone has some more context on that?
The default serde attribute isn't enough in this case because it doesn't apply when the field is present, but set to null, it only applies if the field isn't given at all.
Assuming it was intentional to not make the description optional, this parser should turn an incoming description: null into description: "".
I added a test that fails before this change but passes afterward.

Important files

Discussion points

If it wasn't intentional to make the description not optional we can go that route instead and just make it optional. I think there's some more work to do there since there is other code that assumes the field will be String and not Option<String>, but happy to do that work if that's the route we want to go.

This looks and sounds (and smells?) like a sensible change to me! I'll have a look later on today or this week 😄 Thanks for your contribution 🙏🏼

Hey, thanks for the quick response!
Glad to hear we don't need to go that custom deserializer route! I updated the PR to make the field optional instead of removing it completely - the reasoning is just that if the strict feature is enabled, the parsing will always fail since description is always present in the response from the api, iiuc.
If we want to remove the field completely it seems like it might be best to also remove the strict feature from the crate, since if we delete the field that feature will always break the parsing?
If the change to optional works I think this should be g2g, happy to remove the field entirely and remove the strict feature (or just remove #[cfg_attr(feature = "strict", serde(deny_unknown_fields))] from the feature struct) if that's better too.

@masonj5n Ah, sorry; looks like clippy found a couple places where you'd forgotten to wrap the name in an Option in benches/is_enabled.rs. Would you mind going to clean up?

Whoops, sorry about that! Should be good now

@masonj5n Thanks a lot for your contribution! 🙏🏼  I took the liberty of rebasing your changes into a single commit and adding a little more context in the commit message. I'll go ahead and merge this once the CI jobs have run. Will sort out a release shortly too 😄


Experiment with jemalloc.

We should experiment more with jemalloc to see if we can optimize our allocation behavior (and fragmentation) by taking advantage of jemalloc's rich configurability and introspection APIs.

I have a branch up just for seeing with the default performance of jemalloc looks like compared to the glibc allocator: #52
By default, the RSS grows significantly when using jemalloc, by almost a factor of 2x in our SMP benchmarks: roughly 65-70MB vs 30MB. This, I believe, is actually trivially explained by the default arena configuration which is 4x the number of available CPUs. Since the SMP runners expose many cores, we get many arenas... and as Tokio has many worker threads and those eventually end up getting scheduled across all of those different CPUs... we end up with a lot of arenas holding on to memory.
Naturally, we would likely want to tune this: reduce the arena count to something lower, tweak per-thread cache sizes, adjust decay/purge timings, and so on. The big thing is that, ideally we could do this automatically rather than have to make people schlep around with environment variable tweaks.

Looking at tikv-jemalloc-ctl, it doesn't seem like we can change the things we care most about -- arena count, per-thread cache size, decay/purge timings -- at runtime... at least not dynamically.
We would need to do something akin to setting the environment variable (MALLOC_CONF) before the first malloc call, which is when jemalloc will read that environment variable and configure itself. It's not clear to me if we can, in fact, do that without also allocating memory in the process. Maybe.
Another option is to potentially use the exec function from glibc to replace the current process with a new process... in this case, replacing ourself with... ourself. We'd calculate all of the relevant tunables we want to set, use exec (execvpe to be specific) to replace ourselves and set MALLOC_CONF in the process, which would then ensure that the configuration is present before jemalloc initializes.
I think this might be doable, but would have to test it to be sure because this is definitely outside of my comfort zone as I've never had to do it before.

I added another PR -- https://github.com/DataDog/saluki/pull/71 -- for testing mimalloc, at the recommendation of @lukesteensen.
Between now and the prior updates on this issue, we had actually resolved an issue in lading that was leading to a relatively small trickle of data being sent -- 5 to 6MB/s -- instead of the intended 100MB/s. Now that we're sending the firehose, the numbers have changed.
For jemalloc, we see now that the RSS is more or less on par with glibc even without changing any tunables. The major standout is the reduction in CPU, though, going from around 155% CPU down to 95%. The RSS is at least more stable, though, growing far slower over the course of the experiment.
For mimalloc, we also see an improvement in CPU (155% CPU down to around 125%) which is not nearly as good as jemalloc... but we see a big improvement in RSS, going from around 150MB peak down to 100MB. This usage is very consistent across the course of the experiment, more so than jemalloc... which is good, we love consistency!
These are all high throughput scenarios, though, which is only half of the story. It's not clear if the memory usage will be better in a low throughput experiment after having fixed the previously mentioned bug... but that's one of the things on the list to add, not only for general benchmarking of Saluki/ADP but also to gain more insight into these two alternative allocators.

From benchmarking mimalloc further, it seems like the defaults are designed for applications with much higher concurrency/throughput, where the memory consumption at idle/low load isn't a concern at all. To wit, using mimalloc increases our baseline RSS by nearly 2x compared to the system (glibc) allocator, which is unacceptable.
There do appear to be some tunables we could try to tweak (here, here) but I haven't investigated those deeply and it's not clear if those would then present issues with heavy load profiles.
Similarly, the story is the same for jemalloc, where the defaults result in baseline RSS jumping nearly 2x. We do have experience with tuning jemalloc to reduce the arena count, per-thread cache size, enabling background threads, and so on... but one of the main issues is that it's all based on setting environment variables before the process starts/the allocator initializes itself, and we really don't want to impose the need to tweak things like this to get better performance.
As such, we probably should at least experiment with a little bit of tuning for jemalloc, and like mimalloc, see how those changes are reflected across the different load profiles... but given our goals around pre-allocating of buffers, significantly reducing the number of allocations at runtime, and so on... the value of switching allocators becomes very dubious when we would still have to tune them extensively to meet our memory goals.
More to come.


[terra-form-select-combobox] Added "Results that contain" text in combobox

Summary
   Fixed-Added "Results that contain" text in combobox.

What was changed:
Added  a  div tag to display "Results that contain" text in combobox
Why it was changed:
Combobox should display a message in its selection menu, saying "Results that contain " while dynamically filtering options as the user types.
Testing

This change was tested using:

[x] WDIO
[ ] Jest
[ ] Visual testing (please attach a screenshot or recording)
[ ] Other (please describe below)
[ ] No tests are needed

Reviews
In addition to engineering reviews, this PR needs:

[x] UX review
[ ] Accessibility review
[ ] Functional review

Additional Details

This PR resolves:
UXPLATFORM-9733

Thank you for contributing to Terra.
@cerner/terra

No Matching Results screenshot is updated incorrectly !!

updated

+1


Spelling fixes

Changed "gerooted" to "gerootet". Added a dot at the end of two sentences.

Good catch, thanks very much!


Tag type text is cut-off when creating new badlist item

Describe the bug
When creating a new badlist item from the "Manage" menu item the tag description text is cut-off prior to the end of the tag text itself; making it hard to read which one you're currently selecting without explicitly typing it out.
To Reproduce
Steps to reproduce the behavior:

Go to Manage -> Badlist
Click on 'add_badlist' (green plus icon in the top right)
Select 'tag' as badlist type
Click on the tag dropdown and the tag text should be cutoff before the end of the tag name itself

Expected behavior
When selecting the dropdown I expected to be able to read the tag text in its entirety. This because for some tags there are two variants (f.e. network.static.domain and network.dynamic.domain) and one might only want to create the badlist for one of them.
Screenshots
Below is a screenshot which demonstrates the cut-off tag text:

Environment (please complete the following information if pertinent):

Assemblyline Version: <IP_ADDRESS>
Browser: Arc 1.49.1, Microsoft Edge 126.0.2592.87, Firefox 127.0.2

This should be resolved in the <IP_ADDRESS> release.


feat: add support for multiple entry files

contains two breaking changes. the first change isn't a huge deal as
it isn't exported anywhere that consumers would use (not really part
of library surface). the second change is more of an issue due to
supporting dts.config.ts in 1.3.0, which can consume DtsOptions.
BREAKING CHANGE: name is now string[] in NormalizedOpts
BREAKING CHANGE: input is now an indexed object instead of a
string in DtsOptions
closes #55

Would it be possible to avoid the breaking changes? e.g. normalize the one entry to an array:
name: string | string[]
input: string | object


Video reader vertical mode has some parts that needs to be realigned

Steps to reproduce
set vertical mode on the video reader of the app.

Expected behavior
Parts aligned
Actual behavior
parts not aligned
Crash logs
No response
Aniyomi version
r5237
Android version
Android 8, Miui 8
Device
Huawei p8 lite 2017
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Your issue will be solved soon

Has been Fixed by making icons smaller


General | Enhance Error Handling

At the moment, ioki-ruby is not able to handle errors that have a non-json response body (e.g. some errors like 404 - ActiveRecord::RecordNotFound come with a 'text/html' response body). Reason being, the JsonParse middleware of Faraday tries to parse the response body to json no matter what. This however causes ioki-ruby to raise a Faraday::ParsingError when the response body is not a json.
This PR will add the content_typ setting to the JsonParse middleware of Faraday which ensures that only response bodies of type json will be parsed. Response bodies of any other type will not be parsed and thus will not raise the infamous Faraday::ParsingError.

Neat. We should put out a new release soon :)


Fix inconsitencies between 2.4 and 2.6

Some commits added/removed things from 2.4 and changes were not applied
to 2.6.

@bparees PTAL

lgtm, thanks @rhcarvalho

(looks safe enough but i'll wait for tests)


test(blockifier): gas consumed added to tx reciept

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

#2961  👈 (View in Graphite)
#2953
main-v0.13.4

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


[BugFix] Fixing descriptions of inversed NamedTransforms

If the transform direction is inversed, then order the input/output descriptors accordingly.
Resolves: #111

Closing this one as it was merged in #117.


Error for gradle 4.x

When migrating to Gradle 4.x presents the error:
Execution failed for task ':app:transformClassesWithBladeForDebug'.

java.io.FileNotFoundException: C:\A-NG\azure\mntng- android\app\build\intermediates\transforms\Blade\debug\0\androidx\dynamicanimation\R$id.class
(O sistema não pode encontrar o caminho especificado)

I'm sorry it's not working for you, but this library hasn't been updated in a while and I currently don't have capacity to actively work on it.


Ability to append to Body

[ ]  Feature Request

Current Behavior
When click on the select button to open dropdown, it opens in parent container, which can do problems when you are using it in popups or modals because those have overflow:hidden property enabled.
Expected Behavior
It should have ability to append it on body, which will solve overflow:hidden problem in parents container, you can also see ngx-bootstrap dropdown for the reference.

@chris--jones do we have any milestone for this ?

Any news on this?

@softsimon Any chance this "feature" will be added soon?

@natcohen I wouldn't know because I am not maintaining this lib by adding new features currently. I'll merge a PR if someone make it.