Issue with reading mp3 file

I have huge number of monstrually downsamples mp3 files. 30 seconds each, 11khz, 16 kbps, 16 bits, mono, 60 KB of size. I know a lot of them have different sample rates in frames. But practically all players i checked workes fine and plays this monstrocity. Unfortunetely NAudio cannot deal with it.
Code:
var reader = new Mp3FileReader(filePath);

returns an exception:
System.InvalidOperationException: Got a frame at sample rate 22050, in an MP3 with sample rate 44100. Mp3FileReader does not support sample rate changes.
   w NAudio.Wave.Mp3FileReader.ValidateFrameFormat(Mp3Frame frame)
   w NAudio.Wave.Mp3FileReader.CreateTableOfContents()
   w NAudio.Wave.Mp3FileReader..ctor(Stream inputStream, FrameDecompressorBuilder frameDecompressorBuilder, Boolean ownInputStream)
   w NAudio.Wave.Mp3FileReader..ctor(String mp3FileName)

Is there any way to omit the validation phase and read this mp3 frames? All i want to do with this files is to read Id3v2Tag RawData and then read all their frames like that:
Mp3Frame frame;

while ((frame = reader.ReadNextFrame()) != null)
{
     stream.Write(frame.RawData, 0, frame.RawData.Length);
}

Yes, I'm sure its fixable. The trouble with MP3 is that there are a lot of different types of them out there and sometimes they genuinely are not well-formed. I generally recommend using MediaFoundationReader where possible for that reason as its likely to cope with a much broader range of MP3 files than the NAudio code.

Hello Mark ... regarding the Mp3FileReader issue and your recommendation to use the
MediaFoundationReader currently my application takes in custom encrypted mp3 files and decrypts them into a MemoryStream.  This Stream is then passed into the Mp3FileReader.  Unfortunately I am receiving too often the InvalidOperationException "Got a frame at sample rate N, in an MP3 with sample rate X. Mp3FileReader does not support sample rate changes."  I would like to use the
MediaFoundationReader however, the constructor only takes a file path and in the case of my application I do not want to expose non-encrypted mp3 audio files.  I have researched how/if the  MediaFoundationReader can be modified to use a stream ( IMFByteStream ) but there does not seem to be viable solutions to this.  Are you aware of how this can be accomplished?
Thank you for your time Mark.

Hi, i get the same issues as described in the first post and i am actually using the plugin in Unity engine. In general it works fine except the problem that it can not load certain MP3 files which i don't know why is really !
However, i also tried to use "MediaFoundationReader" as suggested above but the engine just crashes at this part of the code :
mediaReader= new MediaFoundationReader(musicTrackPath); - Crashes the game engine
mp3Reader = new Mp3FileReader(musicTrackPath); - Works for most MP3 files but not all !
I simply changed the variable type from "Mp3FileReader" to "MediaFoundationReader".
Is there any way i can deal with this !?
Any help is really much appreciated ! Thanks !

It depends what version of Windows you are on as to whether MediaFoundationReader will work or not. It uses a different set of Windows APIs and codecs to Mp3FileReader (which uses ACM codecs by default)

It depends what version of Windows you are on as to whether MediaFoundationReader will work or not. It uses a different set of Windows APIs and codecs to Mp3FileReader (which uses ACM codecs by default)

MediaFoundationReader crashes on latest Windows 10 x64 ! I am now using "Mp3FileReader" for mp3 files and try catch which mp3 files can not play and try to play another one. It seems to work for now as a workaround.
May i ask which are recommended ( or min ) Windows versions for Mp3FileReader, WaveFileReader  and MediaFoundationReader ?

What error does MediaFoundationReader crash with?
Desktop versions of Windows tend to come with more codecs pre-installed than server versions of Windows. I'd expect most MP3s to be playable with either Mp3FileReader or MediaFoundationReader on desktop editions of Windows 10 out of the box.


Improving package organization

I'm gonna add more updates before heading to the main problem.
Can you help me testing?

Certainly. Is automated testing as shown in this video the kind of testing you had in mind?
https://searchchoices.jod.li/integration_test.mkv
I should be back in few hours.


Admin command for visibility into membership info for the cluster

Added new admin API DescribeCluster which exposes all membership
information for the cluster.
Updated Membership contract to expose GetReachableMembers API on
Monitor interface and ServerCount and Servers API on
ServerResolver interface which is used for implementing the
DescribeCluster admin handler.
CLI changes to add new admin cluster command to describe cluster.
cadence admin cluster d
{
  "supportedClientVersions": {
    "goSdk": "1.5.0",
    "javaSdk": "1.5.0"
  },
  "membershipInfo": {
    "currentHost": {
      "Identity": "<IP_ADDRESS>:7933"
    },
    "reachableMembers": [
      "<IP_ADDRESS>:7935",
      "<IP_ADDRESS>:7939",
      "<IP_ADDRESS>:7933",
      "<IP_ADDRESS>:7934"
    ],
    "rings": [
      {
        "role": "cadence-frontend",
        "serverCount": 1,
        "servers": [
          {
            "Identity": "<IP_ADDRESS>:7933"
          }
        ]
      },
      {
        "role": "cadence-history",
        "serverCount": 1,
        "servers": [
          {
            "Identity": "<IP_ADDRESS>:7934"
          }
        ]
      },
      {
        "role": "cadence-matching",
        "serverCount": 1,
        "servers": [
          {
            "Identity": "<IP_ADDRESS>:7935"
          }
        ]
      },
      {
        "role": "cadence-worker",
        "serverCount": 1,
        "servers": [
          {
            "Identity": "<IP_ADDRESS>:7939"
          }
        ]
      }
    ]
  }
}

Coverage decreased (-0.2%) to 67.746% when pulling 4e05c133a23a86458caad23c05d0b9da88ce72fb on samarabbas:ringpop-visibility into e5f7c87a86fe3af5f9e925bef7cface679df330c on uber:master.


Library can't be used with Home Assistant

Checks

[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of actualpy.

Reproducible example
I can provide a basic custom component if you really want to devote dev time to this.
Log output
"<frozen runpy>", line 88, in _run_code
File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 189, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
self._run_once()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
handle._run()
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 477, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 559, in _handle
return await handler(request)
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 83, in forwarded_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware
response = await handler(request)
File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
result = await handler(request, **request.match_info)
File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 81, in with_admin
return await func(self, request, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 74, in wrapper
return await method(view, request, data, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 172, in post
return await self._post_impl(request, data)
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 179, in _post_impl
return await super()._post_impl(request, data)
2024-10-16 13:48:07.334 ERROR (MainThread) [homeassistant.config_entries] Error occurred loading flow for integration actual_budget: cannot import name 'TypeAdapter' from 'pydantic' (/usr/local/lib/python3.12/site-packages/pydantic/__init__.cpython-312-x86_64-linux-musl.so)

Issue description
I believe this library can't be used with home assistant as they use version 1.X as stated here https://github.com/home-assistant/core/issues/99218 and from the reported pip version INSTALLED: 1.10.17.
It looks like many libraries have migrated away from pydantic? I'm not a python developer by trade so I don't know the cost of doing said migration at this moment but would be willing to help if it meant me being able to use this library without forking it.
Expected behavior
Not to get an error
Installed versions
https://github.com/bvanelli/actualpy.git@main

Hello @raiyni ,
First of all, please also check out https://github.com/jlvcm/actualpy/tree/pydanticv1 and https://github.com/jlvcm/ha-actualbudget, he already did some work downgrading pydantic to v1 and implementing a Home Assistant plugin.
How exactly do you intend to install this library on home automation, by the way?

It looks like many libraries have migrated away from pydantic

Regarding that, I think that pydantic is very useful as a data model and abstraction layer. Currently the SQL models and the response models depend on pydantic, and I would not change that. It allows me, for example, to convert the names and add documentation to otherwise cryptig fields from the actualbudget data model. If there is a way to offer a better compatibility layer, I would do that instead, but I'm afraid sqlmodel might not support that so well.

Hello

First of all, please also check out jlvcm/actualpy@pydanticv1 and jlvcm/ha-actualbudget, he already did some work downgrading pydantic to v1 and implementing a Home Assistant plugin.

Yes, I did check out their fork and at the time, appeared to have been very behind on their history and hadn't had any activity in either repository for several months. It also appears that they have updated their repositories since opening this issue. I would have to read the diffs more clearly if the commits they have on top are only related to pydantic v1 or if they overwrite some conflicts with their code.
My thought was mainly about using the original (yours) library and not having to maintain a fork of it with a downgraded version of a library and still merge in upstream changes. As that would just greatly decrease time to deploy if there was too much conflicting changes from pydantic v1.

How exactly do you intend to install this library on home automation, by the way?

Are you asking about usage? Similar to jlvcm's addon, it would be used for pulling budgets, pulling accounts, maybe offering some basic input fields and triggering bank syncs.

Regarding that, I think that pydantic is very useful as a data model and abstraction layer. Currently the SQL models and the response models depend on pydantic, and I would not change that. It allows me, for example, to convert the names and add documentation to otherwise cryptig fields from the actualbudget data model. If there is a way to offer a better compatibility layer, I would do that instead, but I'm afraid sqlmodel might not support that so well.

Understandable. It looks like pydantic has added a .v1 compatibility module if that would be more appropriate to maybe integrate?
https://docs.pydantic.dev/latest/migration/#using-pydantic-v1-features-in-a-v1v2-environment
eg usage  https://github.com/YoSmart-Inc/yolink-api/compare/v0.3.1...v0.3.4

Hi, @raiyni, I've updated  my package with the latest changes from this repo.
I thought about using the compatibility  layer but I don't want to affect @bvanelli work negatively in any way and I'm betting on home assistant eventually upgrading the package, so ended up going this simpler route for now
Feel free to expand on any of my repos, both the HA plugin, and the Actualpy fork, or leave a issue if you need upgrading or have any problem with it and as I'll try to help you as soon as I have some time
Hope my work helps you in any way, thanks 🙏

I don't you closing this @bvanelli  in lieu of @jlvcm's reply, thank you both for your time

thanks for the replies, I'll try to investigate if pydantic v1 support is something I could implement, if not technically possible I'll close the issue.

Ok, so I actually tried, and turns out adapting code from version 1 to also work in version two (using the pydantic.v1 layer) is rather easy, but downgrading pydantic v2 to v1 takes so much effort because there is no backport of most functions, so to keep the same functionality, a lot of things have to be reverted back to the deprecated functions instead. This is especially true for the validators, that have gotten a lot better in v2.
Considering support for v1 features will be dropped next year, I don't think it's a good idea to do that. I have tried for around one hour to some patching so that the code runs, and it becomes much much uglier. 😞
I also find it very unfortunate that the problems with the HA integration are not technical, but rather a lot of people with mixed views of usage of pydantic, some people not merging the change requests or straight up removing pydantic from their requirements.
Let's hope that their migration is at least successful in the next month or two so that a fork is not necessary for so long, since functionality can vary since validators act differently on different library versions.


Not working at Go tip

gls currently does not work at Go tip - it appears to have broken somewhere between 1.11.2 and golang/go@78c0e1f81d4052f8ca5a50e4e7c5bb35ddec6519.
This means that the goconvey package doesn't work any more, since it relies on gls for context tracking.
Test code:
package main

import (
	"fmt"
	"runtime"

	"github.com/jtolds/gls"
)

func main() {
	fmt.Printf("Go version: %s\n", runtime.Version())
	manager := gls.NewContextManager()

	manager.SetValues(gls.Values{
		"foo": 1,
	}, func() {
		foo, ok := manager.GetValue("foo")
		fmt.Printf("foo, ok = %+v, %t\n", foo, ok)
	})
}

Output on recent versions:
Go version: go1.11.1
foo, ok = 1, true

Go version: go1.11.2
foo, ok = 1, true

Go version: devel +78c0e1f Fri Nov 9 19:57:57 2018 +0000
foo, ok = <nil>, false

Bisected to golang/go@13baf4b2cd34dfb41c570e35b48ec287713f4d7f.

nice! better inlining! okay I'll fix

fixed


ServerLogReportExtension upgrade WIP

WIP

Generated reports

Generated reports

Generated reports

Generated reports

Generated reports

Hi @mbocek I was investigating AbstractXmlReporterExtension.printString() method due to exception catching. It is called by every print method of report extensions and can throw IllegalStateException. But it seems that if this exception is thrown anywhere report is going to be broken. So there is no point in trieing to catch it in ReportExtension.


Development

Completed second assigment.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

304 of 304 (100.0%)  changed or added relevant lines in 13 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
439

Relevant Lines:
439

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

304 of 304 (100.0%)  changed or added relevant lines in 13 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
439

Relevant Lines:
439

💛  - Coveralls


Bower Support

Would be nice to load this lib via bower.

Indeed this would be tremendously useful if available in Bower. It would nicely compliment an API such as Stripe or Recurly to get a currency out of a country code of a browser !

Very happy to add a bower config. Would also be nice to package it all up into a standalone script that cas just be referenced in an html page without needing everyone to have a build system. Browserify can do this I believe, and there is already a makefile so the step could be added there.
If you'd like to do this and pull request it that would be great - I'm currently very busy with other things :)


Disposable Interface

Use case
As of this writing, a lot classes in the SDK have a method defined on them with the signature void dispose(). Some of the examples are,

TabController
TextEditingController
PageController
ScrollController
State
ChangeNotifier

Let's call them disposables.
Right now I cannot write functions/methods/classes that can accept a disposable.

Proposal
I propose that a new abstract class definition be added to Flutter with the following definition,
abstract class Disposable {
  void dispose();
}

This abstract class should be implemented within the SDK where ever it already is implicitly satisfied. Eg:
class ChangeNotifier implements Listenable, Disposable

No breaking changes.
No new API (no new methods/functions only marking existing classes).

Duplicate of https://github.com/dart-lang/sdk/issues/43490 ?

@alexeyinkin i don't think this is a duplicate. looks to me 'Disposable' is really a Flutter contract more than a language feature.

If we make it a Flutter feature, we leave the pure-Dart StreamController and StreamSubscription behind. So we still will have disposable classes not covered by this interface, which defeats the point of introducing it.

@alexeyinkin not sure that is the point. StreamController & StreamSubscription have an async cancel. not quite the same thing. AsyncDisposable would be required for them as they need the caller to be also colored as async.

In that issue, cancel() vs dispose() is being questioned: https://github.com/dart-lang/sdk/issues/43490#issuecomment-695754533
Those seem to be different names for the same concept. You have something, want to get rid of it, call that thing, simple.
Also, I think that the decisions on Disposable and AsyncDisposable should be coordinated wherever each of them ends up. That's the reason to mark it duplicate.
And we should be careful putting generic things that are valid in pure Dart in Flutter. For instance, missing Listenable in Dart is really inconvenient, see

https://github.com/flutter/flutter/issues/136155

I agree with you @alexeyinkin. it would definetly be quite nice to have this Disposable contract in pure Dart


Added support for "RequestMsg" and "ResponseMsg" naming suffixes. Thi…

Added support for "RequestMsg" and "ResponseMsg" naming suffixes. This is a convention for IBM WPM servers.

Coverage increased (+0.09%) to 93.127% when pulling edd9897b8199e3b1d4ce932bc11161f6fe09c589 on jarredkeuch:master into bc6992ac2cac8e822795172b0d7bd9df0e5bcd85 on vpulim:master.

@jarredkeuch why did you close this?

Good morning! It's not right. Not yet.
Here's our problem: A complex type is being used for the operation
input.When a complex type is used, the extension name (e.g. "
extension="tns:getMyStuff") should be used instead of the input name.
Unfortunately, node-soap only uses the input name.
I should have an updated pull request today.
On Mon, Feb 13, 2017 at 1:37 PM, Joseph Spencer<EMAIL_ADDRESS>wrote:

@jarredkeuch https://github.com/jarredkeuch why did you close this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vpulim/node-soap/pull/919#issuecomment-279481133, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHFun7ipZQZhtOH1v7SEhSkLvAe74dCnks5rcKLygaJpZM4L9eyF
.

@jarredkeuch please do not close a PR and open a new one simply to make changes to it. You can easily force push to reset the state of your branch in git.


Feature Request: Image Icons for the layer buttons in Map and Ground Editors

Specifically the 'D' 'M' '^' and 'v' buttons. To someone who doesn't already know what they do, they're a little vague, so images might convey what they do better. Not something high priority at all though.

Added in https://github.com/RogueCollab/RogueEssence/commit/a78f7e016e5bfe0ab7c7d8e7cbc78155790a327c


Discussion: Handling multiple processes within Embark predictably

While I was working on the issue that Embark's service [SERVICE] on/off commands aren't working anymore, I ran into a couple of things that raised some questions I'd like to discuss in this issue.
Why is this command non-functional on latest master?
First and foremost it's important to know why the service command isn't working anymore. Just to recap what this command does, when running either $ embark run or embark console (and therefore, the same applies to Cockpit), we used to have a command
> service [SERVICE] on/off

that can be executed in any of Embark's interactive consoles and enables users to turn services inside Embark on and off respectively. Originally, there used to be dedicated commands for specific services, such as > webserver start/stop or  > ipfs start/stop.
This has been more generalised in this PR and documented here so that any process can be started and stopped with a single console command.
As part of the bigger refactor in v5 a few months ago, this command has been entirely disabled to ensure better decoupling of modules inside Embark (notice how the comment points out that ProcessManager shouldn't know anything about deployment). This was done as a TODO so I assume this was actually a temporary step that was intended to be properly handled later on.
The reason this service command was registered as a deployment:deploy:beforeAll hook, was most likely because there is no other "signal" within Embark at which point we know that all necessary processes have actually been registered (and launched).
This can be easily verified by reintroducing the registration of the service commands without depending on the deployment:beforeAll event - by the time the command is registered, availableProcesses is essentially empty because none have registered yet.
Other issues with the service command
If we forget for a second the fact above and hijack the deployment:deploy:beforeAll event to get notified that all processes have been registered, there are still some things in flux with how we handle these services/processes.
After the refactor, we have introduced several stack components and layers to handle more concrete plugins. For example there's a stack component for Storage which, in practice will be used by plugins for ipfs and swarm. Same goes for Communication which at this point is primarily consumed by whisper.
The former results in no ipfs service being registered as such. Instead, there's now a storage service (as opposed to what our documentation says https://embark.status.im/docs/using_the_console.html#Enabling-and-disabling-processes). In addition, we explicitly document that whisper as a service can't be started/stopped as it's tied to the spinned up blockchain process and requires Embark to be restarted.
This is no longer true since we switched to spinning up a separate geth node for whisper and therefore should be able to start/stopping that process without affecting the blockchain process.
These things raise some questions
Above I've described different things that in my opinion need fixing, but they are also independent issues. I'd like some thoughts on the following:
1. How to Ensure a predictable registration lifecycle for processes
Assuming that we want to keep the service commands, we need to come up with a new way to ensure the registration of this command happens at a time all initial core process have been registered. Relying on deployment:deploy:beforeAll is not an options as we want to preserve semantic decoupling of the process manager.
I think what we need is, similar to the module registration/loading approaches discussed in the past, a registration/initialization phase for processes that enables us to signal when this is "done" so we're save to register a service command that needs to retrieve all registered processes.
We most likely still need a second phase that can be called #n times at runtime due to Embark's capability of extending Embark itself using plugins. Although, if we know for sure that processes are exclusively things that are stack components, we might not need such a routine as we dictate what stack components exists.
2. How to handle stack "processes" vs plugin "processes"
Due to the stack component vs plugin component architecture, we need to decide how we want to handle cases in which for example multiple processes for a certain stack process have been registered and launched.
To give an example, theoretically it's possible to have ipfs and swarm enabled within Embark. The process available inside the console is only Storage though. Turning that one on and off is broken at the moment, but I'm also wondering, should we still allow to turn of individual plugin processes?

Good write up.
If I understand correctly, right now, the process manager is a stack component, but the actual processes are storage, communication, etc. and they are stack components too so we cannot really register them in the manager.
How about we move the process manager to be a core module? I don't think it's too farfetched, considering processes are core to Embark anyway.
That way, both stack components and plugins can register as processes and have the same type of handling.

Thanks for your feedback @jrainville !

If I understand correctly, right now, the process manager is a stack component,
So, the process manager is already a core component as you can see here: https://github.com/embark-framework/embark/blob/master/packages/core/core/src/processes/processManager.js

so we cannot really register them in the manager.

Actually the registering process in itself is not really the issue here. Processes are being registered in several places throughout Embark.
The issue I've described above is that we don't have a notion of "registering processes is done". IOW: there's no explicit phase or signal that tells us that Embark is actually done registering (and launching processes).
This in fact goes hand in hand with having a register + init phase for modules as well. Most likely, registering processes within a module is going to be part of the init process of a module (among other things).
So I guess what I'm trying to explore here is that we need an API for that and ideally we discuss together what it should look like and how it should work.
Does that make sense?

Ah ok, yes makes sense.
I checked the processManager again and I see that the only reason we wait for all processes to be registered (not even started, it doesn't care) is so that it can list correctly all processes here: https://github.com/embark-framework/embark/blob/master/packages/core/core/src/processes/processManager.js#L76
Basically, we could call _registerCommands straight away, but it wouldn't have the name of the processes, which sucks.
Now, like you said, having a way to wait for all processes to be registered is hard because the manager is a core component, so it's not supposed to know about if and when stack components and plugins are going to register to it.
So, a real solution would be to not have to wait at all. By that, I mean that the manager should just have to modify the registerConsoleCommands and change the labels to add the new process every time a new one registers. However, that is not doable (I think)  with the current API, because I think it would just add a new console command and not replace it.
Another solution would be to not wait at all again and also not show the labels. We would instead add a new command called something like service list that prints the current list of registered services (plugins).
The last solution I can think of is to continue as it was before and hijack a random event to know when stuff should be ready. But it's really not ideal because, like this, the commands are not  available at the start and it's a bit arbitrary.
In conclusion (that was a big essay wasn't it? haha), I don't think waiting for "all" the processes to be registered is doable, nor really useful, because we'll just end up with race conditions and no one likes that.
I then  propose to go with the second option, the one where we add a command to show the registered processes, because it is quite easy, it removes the arbitrary wait and also is relatively intuitive (list commands are quite widespread)

Appreciate your input. Let me get into your points.

I see that the only reason we wait for all processes to be registered (not even started, it doesn't care) is so that it can list correctly all processes here

Unfortunately, that's not the only case. We rely on availableProcesses here to determine whether or not a given command matches this command. In other words, if availableProcesses is empty, none of the service [SERVICE] on/off commands will be recognized.

Now, like you said, having a way to wait for all processes to be registered is hard because the manager is a core component, so it's not supposed to know about if and when stack components and plugins are going to register to it.

One way I can see this working if we had an actual initalization phase within Embark that either signals/broadcasts to several components that it's done initializing (this includes at least processes registered and loaded during bootstrap), or it comes with a built-in "after init" that will execute other lifecycle hooks, such as registering API calls etc. (which by the way, is an API we'd need anyways if we want a way to ensure any REST APIs are created at a time when it's valid to do so).

So, a real solution would be to not have to wait at all. By that, I mean that the manager should just have to modify the registerConsoleCommands and change the labels to add the new process every time a new one registers.

As mentioned above, I actually think it's perfectly fine for this to be asynchronous. We just need to define a predictable point in time at which things like API regsitration should happen.
Just to throw out ideas here (and yes it's very similar to what I've proposed about a year ago), Embark could have an init and registerAPICommands (and others) encoded in its protocol like this:
init() {
  return Promise.all(this.registeredModules.map(module => module.init())).
    then(modules => Promise.all(modules.map(module => module.registerAPICall()));
}

^ Obviously this is hyper simplified, but just to convey the concept. Notice that things like registering processes would be done in a module.init() function (which can and should be asynchronous by default).

I don't think waiting for "all" the processes to be registered is doable, nor really useful, because we'll just end up with race conditions and no one likes that.

I'm not sure what you mean by that. Why exactly is that not doable? Also if we have a predictable API that tells us when something should be done/finished, race conditions should be exactly what we avoid.
On whether this is useful or not... well this whole discussion is around the fact that we don't have a proper way to handle this, so I think it's not just useful but essential to get this right.

Unfortunately, that's not the only case. We rely on availableProcesses here to determine whether or not a given command matches this command

That's true, but notice that this line is only called when the user inputs the command. That means that it's the user's responsibility to wait for the service to be registered (he can usually  monitor that in the dashboard or cockpit).

One way I can see this working if we had an actual initalization phase within Embark that either signals/broadcasts to several components that it's done initializing (this includes at least processes registered and loaded during bootstrap)

Yeah, I guess doing an action called time to register processes (name pending) would work in that case, though who calls that? The cmd_controller?

an API we'd need anyways if we want a way to ensure any REST APIs are created at a time when it's valid to do so
I don't think that's true. The APIs

That means that it's the user's responsibility to wait for the service to be registered

I think this is a question of good UX. I would say, as a user, I don't want to worry about whether Embark has loaded and initialized all of its internals, so I can use a specific command in the console. Embark should ensure that the commands I run are valid.  Registering/exposing a command that doesn't work (yet) because some thing isn't finished initializing sounds like a bug to me.
Obviously, this is a different case when we're dealing with cases where we don't control when something is loaded/initialized. For example when someone loads a plugin/module at run-time after Embark has been bootstrap. That case needs to be handled separately and applies to module loading/initialization the same way as discussed above.

Yeah, I guess doing an action called time to register processes (name pending) would work in that case, though who calls that? The cmd_controller?

So the way I imagine this, as shown above in the code snippet, it would be something the command controller would not need to worry about. Embark's init() function (or whatever we want to call it) will take care of calling init() for every registered module, which may or may not cause modules to register processes. Once that is done, Embark knows it can run other APIs on every module, such as an API to register API calls, or register console commands or pretty much anything else that we allow modules to do.
To give a concrete example, ProcessManager._registerCommands() will be called by Embark once it knows it can actually do so. Notice that this requires ProcessManager to implement the same API (one for registering console commands) for this to work.

Also, other APIs should be handled by the modules themselves when they are ready.
Unless you were talking about another API in another module that would need everything to be ready?

Yes. I was generally referring to the idea that we probably should only do certain things like registering API calls, or console commands, when we know for sure that these are valid things to do. For example, we probably don't want to allow modules to create anything (such as REST APIs) on top of processes that don't exist yet.
The bottom line is that it would be great if we can say, inside and outside Embark, when we run this code we know that the things you need are available, because Embark ensured to take care of it.

but with the current commands and APIs, I don't think it's necessary

I think, in order to give certain guarantees about Embark's lifecycle (and its modules) we will have to iron this out sooner or later.

As discussed offline, we're considering "removing" this command for the time-being as the root of this problem requires a little bit more effort. The functionality is already gone. In #2023 we're removing the corresponding docs for now as well.
@michaelsbradleyjr @iurimatias I think you both still wanted to leave some thoughts on the discussion above here?

Everything that follows is a bit of a rough sketch, so my apologies in advance if anything's unclear.

I think what we need is ... a registration/initialization phase for processes

I believe it's useful to think of the heart of Embark being:

a process supervisor - start, monitor, restart, stop
a bus for services to interact/react

Embark is almost a mini OS, in some sense. I've been thinking for some time about our terminology/concepts with respect to Embark components and plugins and how they might evolve:

library
bundle
component

application
plugin

I'll attempt to explain what I mean by these terms and connect it back to "phase for processes"...
An Embark library is a package that is used as a building block for Embark components. It could be installed in a project with npm/yarn but probably wouldn't be useful that way because it's designed to be part of an Embark application or plugin.
An Embark bundle is a package that provides multiple Embark components. A bundle is installed into a project with npm/yarn. For example, embark init (default template) might add the @embark-framework/standard-bundle package to a project's package.json.
An Embark component is a package that is either an application or plugin. It is built from Embark libraries and other packages. A component is installed into a project with npm/yarn, as a dependency of a bundle or individually.
An application is a component that involves one/more processes, could be long-running or not. Examples would be blockchain (long-running) and graph (not long-running). Some applications behave as composites of other applications, the prime example being run. An app may provide one or more services that react to one another and/or interact with things external to Embark such as a web browser.
A plugin is a component that hooks into one or more applications. Like apps, plugins may provide services.
So in these terms Embark's CLI can be understood as a way to launch an application and hook up the applicable plugins.

if we know for sure that processes are exclusively things that are stack components, we might not need such a routine as we dictate what stack components exists

I feel like this might make Embark too tight, when, ideally, we want it to be even more flexible than it is now.
Keeping in mind what I wrote above, I'd like to do a thought experiment regarding what could be involved in Embark app bootstrapping and how that relates to init, registration, etc.
Compared to how packages/embark/src/cmd/cmd.js and cmd_controller.js work at present, I'm aiming for something much more dynamic, flexible, and lightweight:
$ cd ~/dapps/foo
$ embark  # or `npx embark` if installed locally

No app was specified so we need to build the top-level --help output.

What Embark components are available?

for each dev/Dep in the project's package.json look in the corresponding node_modules/[pkg]/ directory for an embark.json file.
if embark.json is found check its type: key.

if the type is "bundle", then check the components: key for a list of package names and check each of those with these same steps.
if the type is "application" add its name and the JSON contents to an object that tracks available apps.
if the type is "plugin" add its name and the JSON contents to an object that tracks available plugins.

Convert tracked apps and plugins objects into text output that lists the available apps and options, including any plugin options. The output would look very similar to what embark --help outputs currently.

Notes
For (2) the idea is that an app declares the commands and cli-options it supports. Also, a plugin should declare what app/s it applies to (possibly "*") as well any cli-options it supports. This allows Embark's CLI and its help screens to be highly dynamic. Plugin cli-options would automatically include the plugin name after the double-dash, e.g. --snark-some-option.
$ embark [app] --help

An app was specified but with the help flag so we need to build specific --help output.
Steps (1) and (2) as before, except in (2) everything is ignored except the specified app and any plugins that apply to it.
$ embark [app] --[option] ... --[plugin]-[option] ...

An app and options were specified so we need to launch it!
Step (1) as before, then:

Check the project's embark.json for plugins: and match up with tracked plugins object from Step (1). Plugin options specified in the project's embark.json will be combined with any plugin cli-options that were given by the user. Likewise, project config options will be combined with any app cli-options that were given by the user.
Instantiate the specified app with the embark instance and app options. If any options weren't valid, there will be an exception and Embark should exit with an error message.
Instantiate each plugin with the embark instance, the app instance, and plugin-specific options. If any options weren't valid, there will be an exception and Embark should print an error message that the plugin could not be activated.
The embark instance signals START.
The app and plugins receive signals via an Rx Subject (inbound$) that's a property on the embark instance. The app and plugins send signals via another Rx Subject (outbound$) that's a property on the embark instance. Embark may react to those signals itself, e.g. {source: 'some-app', type: SERVICE_REGISTRATION, value: 'some-service-name'} could register a service as available and the source will subsequently signal {type: SERVICE_STATE, value: STARTED}. The embark instance can track that state however seems best. Whether or not Embark reacts to app/plugin signals, they will be looped back through inbound$. By sending through outbound$ and observing inbound$, app and plugin services can react to one another. What exactly that entails should be internal to the app and plugins, i.e. the supervisory aspect of Embark doesn't need to know about it.
If the app signals with {type: APP_STATE, value: DONE} then embark will wait for the plugin instances to react with {type: PLUGIN_STATE, value: STOPPED} signals and then the top-level process will exit. Similarly, if the user signals for embark to quit, then it will signal STOP, wait for signals from the app and plugins, and then exit.

Notes
The default export of each component (both apps and plugins) should be a constructor that causes no side-effects when instantiated.
Each component instance should have a validateOptions method that's called by its constructor before setting up instance properties based on the options.
By "embark instance" I mean the same kind of object we currently pass to constructors during bootstrapping. However, it can be streamlined quite a bit since much responsibility is shifted to the inner workings of apps and plugins, which Embark shouldn't need to know about.
Much of those inner workings can, though, be implemented in Embark libraries that are reused across apps and plugins, i.e. apps written by the Embark team or 3rd parties. But note that Embark libraries don't have to be used to implement an Embark app or plugin. So long as the app/plugin instance exposes the expected methods and properties (should be a small number of them!) it should be possible to implement it any way desired, e.g. to experiment with a different design for app-internals or to implement an app that's so different from the standard ones it needs unique internals.

To summarize everything: I believe the core supervisory aspect of Embark can be comprised of a relatively small amount of code that has relatively few responsibilities. This will allow for apps and plugins that can do just about anything and in way that they want/need. We can still have very reusable code in the form of libraries that are used across apps and plugins, but by imposing very few requirements on apps and plugins, it's possible for us and our users to easily go off in new directions.
Imagine a scenario like this: Bob would like to use Embark to build Tezos dapps. Frank wants to use Embark to experiment with Cosmos. In both of their cases, some of the existing Embark libraries for blockchain, etc. don't do what they need, while others can be reused as-is. Each builds an Embark application modeled after the @embark-framework/run application along with some helper libraries. Those apps hook to the embark instance via inbound$ and outbound$ as described above, and they're off to the races! Later, the Embark team learns of their projects and by studying the helper libraries that had to be created it's realized how the @embark-framework libs can (or can't) be generalized a bit better to improve their reusability, making it even easier in the future to create apps and plugins for new use cases.

@michaelsbradleyjr thanks for your thorough thoughts here!
I read your post three times to fully follow what you're aiming for. Just to be sure, here's what I understood from this:

Generally you're aiming for Embark kind of composing itself at run-time by reading some configuration which declares which modules and plugins are desired.

I think this is an interesting idea and certainly would provide super high flexibility if done done right. Also, I like the mindset of Embark being a mini OS. This is probably not something we can pursue in the near future, but either way, at the core of this (just to shift focus back to the original question in this issue): we need a registration + bootstrap phase at which point we know Embark is done bootstrapping (I guess this is what you were trying to say with the $inbound and $outbound stuff, which honestly, I didn't fully get).
So I'm fine with Embark becoming a highly composible thing that puts itself together by reading declarative config files at some point at run-time, but even without that, we need those core APIs that describe this bootstrap phase.
I'd propose we agree on such an API first (it has to work one way or the other) and then we can see how this can be done in a way that it's dynamically composable, which I think isn't too hard. In away we just need to determine the plugins/module we need and do something like engine.registerModule() in a dynamic fashion. After that, like I've mentioned above, we'll need this init or bootstrap phase.

Thanks for the feedback @PascalPrecht!

Also, I like the mindset of Embark being a mini OS. This is probably not something we can pursue in the near future...

Does "in the near future" pertain to the dynamic configuration proposal or to Embark being a mini OS? If the latter, just to clarify, I meant that it already is a "mini OS" and wasn't proposing a direction of development; Iuri's describing Embark as being like a pluggable "game engine" is probably more accurate than my calling it a "mini OS".

we need those core APIs that describe this bootstrap phase

Rereading my own post, some of the consequences of the changes I proposed were implicit, when I should have been more explicit.
Basically, I'm proposing the supervisory aspect of Embark shouldn't worry about bootstrapping beyond instantiation and START. The can gets kicked to apps, and they could take any approach they wish. In practice, there would be a set of APIs and a general approach that we reuse across apps, but apps aren't constrained to them. This would allow more freely iterating on different/refactored designs for app-internals (e.g. run3, run4, run5, ...) and allow for 3rd party apps that work very different from the standard run. You can sort of do that now, by jamming an alternative run into cmd.js and cmd_controller.js (we did that during a refactor with run2), but it's pretty hacky.
What follows is basically me thinking out loud. I'm not sure that what I'm going to describe is achievable, I think it is, but I'm definitely painting in broad strokes...
I have a growing feeling that our overall architecture right now — the core Engine, etc. — is too inflexible, and that the wild spread of command handlers and events/requests all over the place is problematic. I don't know "the answer" (yet) to a better architecture, but I'm thinking about a services+agents architecture that gives more structure to how Embark components interact and react.
Services would follow a request/response model that's an abstraction on top of the async signals moving through inbound$ and outbound$, and they could also spontaneously emit signals regarding their own state changes. However, services wouldn't generally react to or interact with each other directly; a service's job would be to respond to requests, and the responsibilities of any one service should be limited and very well defined.
One or more agents would be responsible for creating the workflow between services, and their reactions to signals and responses should pluggable, i.e. so plugins can register actions for the agent to take at different points in its workflow. That would still leave us with the priority/ordering problem, but that's probably unavoidable. An agent could be implemented any number of ways, but redux-observable and xstate seem like natural choices.
So the brain of any Embark app (embark [app]) would be one/more agents. Its workflow and what parts of it are pluggable would be things we document. Besides registering actions with an app's agent/s, a plugin could send requests to an app's services directly or even implement its own agent/s. For major changes in setup/behavior, beyond the scope of a plugin, a developer could make their own app — that would involve reusing existing Embark services and/or creating new ones, and implementing an agent/s for the desired workflow.
If services are independent, i.e. self-contained and don't interact/react directly, I think the init and boostrapping problem becomes simpler or at least better contained. The complexities of waiting for services to be READY or to finish RESTARTING, not making another request to Service A until it has gotten a response from A and finished its workflow dealing with that response, etc. — all of that logic is inside the app's agent/s and not spread through the codebase.


Issue #1922 - implement whole-system search in new query builder

Signed-off-by: Mike Schroeder<EMAIL_ADDRESS>

Included in this PR:

whole-system search excluding the _type parameter in new query builder

Excluded - will address in subsequent PRs:

old query builder updates to use new _profiles and _tags tables
whole-system search with _type parameter in new query builder (including UNION support)

Second commit includes code to allow old query builder to use new _profiles and _tags tables.

Third commit includes code to:

handle _sort with whole-system search
implement whole-system search with _type in new query builder
add UNION support to new query model

Remaining:

support text searches of _tag parameter (i.e. with modifiers like :text, :in, :not-in, :above, :below)

Note: some of the _security testcases will fail until Robin's schema changes go in.


Device Setup Keeps Crashing

There is a known issue where Device Setup keeps crashing. The next releases will hopefully fix this issue by disabling the setup app by default.
Current Fix: Disable the app manualy.

Hi,
Don't understand what the device setup is, however, the Play Store is crashing for me :(
I installed A13 version from sourceforge in A12L, what is the proper version of the module to use for me?
Any workarounds on the crashing thing?
When to expect the new release?

What android version are you using and what MagiskGApps version are you using?

@wacko1805 android 12L
A.13.Core.16-10-2022

Please use the Android 12L version of MagiskGApps
https://magiskgapps.com/download.html?version=android-12L-ALPHA

@wacko1805
Could you please add the link to the site into readme, cause it's not clear, where to download the module (:
Also, have the setup crashing issue already been resolved, so you closed the issue not because of answering to my comment here?

The link to download the module is in the readme already, and was on mobile and misclicked. Reopening issue.

So I installed AOSP 13 from here and installed Magisk fully. Then I installed the A13 Stock. I thought it had broke my ROM as it sat at the Android boot screen (and was doing the little shimmer thing so it wasn't frozen) for about 10 minutes I left it. Then I finally restarted, it got to that screen, and about 20 seconds later, restarted and then finally went through and was installed.
Should I be worried?


Steps to reproduce: No I forgot.
Calculator model: TI-84 Plus CE L-0216C
System info: Boot <IP_ADDRESS>4, OS <IP_ADDRESS>9; Cesium version 3.6.3
It only happened once to me, I guess it's some really extreme corner cases?

Sorry I can't remember clearly, but it might happened in level 700m or 800m, and it might happened when I was jumping on the cloud or spikes.
Thanks TLM and Logical

having this same issue but I never get to play the game, as soon as I start it it goes blank and clears ram and on rare occasions went into a boot loop

Could you give the same info as the original poster? "Calculator model" (with the datecode+letter at the end) and "System info" (boot/os version)

Could you give the same info as the original poster? "Calculator model" (with the datecode+letter at the end) and "System info" (boot/os version)

Model: Ti-84 Plus CE - D5ED
OS version: 5.0.1 | Cesium version 3.6.7
this is the only info I know how to find

You should definitely update the OS version, 5.0.1 is extremely outdated.
Use OS 5.3, for instance, which may solve the issue, but also doesn't require you to put programs in RAM to run them (they can be left in archive, and won't be lost by any crash)

download

You should definitely update the OS version, 5.0.1 is extremely outdated. Use OS 5.3

downloaded the file, will try now, will update after


workbench.action.toggleEditorGroupLayout does not maintain input focus

Does this issue occur when all extensions are disabled?: Yes

Version: 1.93.0-insider
Commit: ae45c9d4b0f71d53151edc6d18be09107903c229
Date: 2024-08-29T05:04:03.909Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.9.3-76060903-generic
Steps to Reproduce:

Open a few editor groups in seemingly any split configuration
Focus one for text input
Press Shift+Alt+0 or otherwise run workbench.action.toggleEditorGroupLayout
Try to type: no result, as no editor has focus any more.

This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.

In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
{
  "key": "shift+alt+0",
  "command": "runCommands",
  "args": {
    "commands": [
      "workbench.action.toggleEditorGroupLayout",
      "workbench.action.focusActiveEditorGroup",
      {"command": "cursorMove",
          "args": {
            "to": "left",
            "by": "character",
            "value": 0}
      },
    ]
  }
}

/verified


Forced downgrade of six in python 3.8 crashes pip in venv

My virtual env is using python 3.8
When I install PyVimeo, six if forcefully downgraded from six 1.14.0 to six 1.10.0. This breaks the entire venv and pip stops working throwing the following error.
(venv) phang@phang:/media/phang/PRO/bafundecore$ pip freeze
Traceback (most recent call last):
  File "/media/phang/PRO/venv/bin/pip", line 8, in <module>
    sys.exit(main())
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/cli/main.py", line 73, in main
    command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/commands/__init__.py", line 96, in create_command
    module = importlib.import_module(module_path)
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/commands/freeze.py", line 12, in <module>
    from pip._internal.operations.freeze import freeze
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/operations/freeze.py", line 17, in <module>
    from pip._internal.req.constructors import (
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/req/__init__.py", line 11, in <module>
    from .req_file import parse_requirements
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/req/req_file.py", line 25, in <module>
    from pip._internal.req.constructors import (
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/req/constructors.py", line 28, in <module>
    from pip._internal.req.req_install import InstallRequirement
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/req/req_install.py", line 30, in <module>
    from pip._internal.operations.install.wheel import install_wheel
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/operations/install/wheel.py", line 33, in <module>
    from pip._internal.utils.wheel import parse_wheel
  File "/media/phang/PRO/venv/lib/python3.8/site-packages/pip/_internal/utils/wheel.py", line 12, in <module>
    from pip._vendor.six import PY2, ensure_str
ImportError: cannot import name 'ensure_str' from 'six' (/media/phang/PRO/venv/lib/python3.8/site-packages/six.py)

Can you try restesting with the latest version? https://pypi.org/project/PyVimeo/#history

Works fine now.


⚠ Spryr has degraded performance

In 99dca46, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 429
Response time: 10481 ms

Resolved: Spryr performance has improved in d010ea4 after 20 minutes.


Message conversion exceptions ignored in SmartCompositeMessageConverter

Describe the bug
Switching to spring-cloud-dependencies:2021.0.3 MessageConversionException exceptions thrown by ApplicationJsonMessageMarshallingConverter are ignored in the SmartCompositeMessageConverter. Related commit: 7921842 .
The unwanted side effect of this is that the handler method gets invoked with the wrong payload type, leading to class cast exceptions:
java.lang.ClassCastException: class [B cannot be cast to class com.fasterxml.jackson.databind.node.ObjectNode

Sample
public Flux<...> compose(Flux<Message<ObjectNode>> flux) {
    flux.map(message -> message.getPayload().at("/foo"))
    ...
}

@Test
void shouldRedirectJsonProcessingExceptions() {
    inputDestination.send(new GenericMessage<>("{".getBytes()), "test");

    var message = targetDestination.receive(1000, "test_errors");
    assertThat(message, is(notNullValue()));
}

Is this behavior expected? Is there a way to avoid this without extra steps in the handler method?

This is indeed expected "in a way". Let me explain.  . .
Indeed we have a stack of message converters to which user can add more message converters. When type conversion is attempted we go thru the stack attempting to find the right converter. Just because a particular converter have answered true  to canConvert() call doesn't always mean it actually can as the conversion may result in exception (your case). At that point we continue with the stack letting other converters to take a crack at it. So that is the "expected behavior" part ends.
What I think we should do (additionally) is check the converted result after the conversion and see if it matches the actual input type. In other words in your case what must have happened is that no other converter picked it up and the result remained in raw format byte[], so we should throw more intelligent exception.
That said something you can already fix by looking as to what is going on with your object and why it can not be converted and possibly implement a different message converter specific to your needs.
Meanwhile I'll look at making it a bit more intuitive

Actually, they are not ignored as there is a debug message.
catch (Exception e) {
  if (logger.isDebugEnabled()) {
	logger.debug("Failure during type conversion by " + converter + ". Will try the next converter.", e);
  }
}

But i'll see what I can do to make it clearer

@olegz , by just logging the exception any invalid formatted JSON coming from Kafka will get to the handler method instead of being treated as an error / exception so that the specific onError callbacks can be called on a flux.
Adding another converter won't help as even if you throw an exception from that converter it will just get caught and logged and the raw bytes will still get to the method handler causing a type error.
The only solution would be to implement checks and conversions in the actual method handler but then we lose the separation of concerns ability. I believe that's why we have converters in the first place.
For these reason I believe catching the exception and logging it is an unwanted behavior.


Take video recording of tests

See docs: https://playwright.dev/docs/videos and https://playwright.dev/dotnet/docs/api/class-video
Note that Dotnet is different to node which is different to java.
Add a flag in the environment config called RecordVideoMode

Off - do not record
On - keep video always
RetainOnFailure - keep only in the event of a test error

For dotnet, instance the browserContext with the correct recordVideo option depending on the environment setting.  When a test finishes, keep the video depending on the enivronment setting.
For playwrite tests in Node.js, video is already natively supported as per the documentation

Passed.  This is working well.
When no environment file is present the default is RetainOnFailure, which I think makes sense.


ETA on Support for OData IN filtering?

Great library and working for us well so far!
Although wondering if/when the IN filtering option might be supported?

I've started working on this and will most likely open a PR in the coming days.
So far the implementation is looking really simple, although I might be overlooking possible edge cases. For common IN queries, what I currently have seems to work fine, but I have yet to write unit tests.
Given that the README explicitly states that the IN operator is not supported, I imagine the maintainers may have had a reason for this. @vaibhav-goyal, is there anything specific you think I should keep in mind or edge cases to look out for?

@Rafaeruo Thank you for your work on IN clause. I think when this library was first implemented the Odata parser/object model did not support IN clause. I can't recall any edge cases so it would be great to see the PR it might remind me why we did not support IN clause in the first place.


Use versioned client APIs

Non-versioned client-go APIs are deprecated, switch to versioned ones.

LGTM


Use latest sac2c pkg (link change)

Latest MacOS VM in github actions changes Xcode version from 10 to 11, which required some changes within sac2c to work. We update our CI to use newer sac2c packages, where this problem is fixed. We switch to using a single link to always get the latest sac2c packages.

Agreed, however for the current siltation that doesn't work. The MacOS pkg is newer then the currently latest package for ubuntu. Once we have a consistent build (with MacOS), then this would make sense.

ubuntu does not use omnibus, does it?

updated to use latest link...

looks much better now :-)


ndots is larger than it needs to be

Howdy!
If I run cat /etc/resolv.conf I get this:
search default.svc.cluster.local svc.cluster.local cluster.local kubelet.kubernetes.rancher.internal kubernetes.rancher.internal rancher.internal
nameserver <IP_ADDRESS>
options ndots:5

where ndots is set to 5.
However, based on this Kubenetes documentation:

v1.2 introduces a beta feature where the user can specify a Pod annotation, pod.beta.kubernetes.io/subdomain, to specify the Pod’s subdomain. The final domain will be “ ...svc.". For example, a Pod with the hostname annotation set to "foo", and the subdomain annotation set to "bar", in namespace "my-namespace", will have the FQDN "foo.bar.my-namespace.svc.cluster.local"

we can see that the longest possible FQDN is something like foo.bar.my-namespace.svc.cluster.local.
Given that the smallest search name is cluster.local, this means that the biggest relative query that could be issued is something like foo.bar.my-namespace.svc, which only has 3 dots, meaning that the optimal size for ndots here is actually 4.
Although this is only a minor performance tweak (it avoids unnecessary strain on the local DNS and reduces the latency of clients performing absolute name look-ups), it also happens that Alpine Linux currently has a bug that seems to affect some clusters, that prevents absolute look-ups from working at all once relative look-ups have been tried first. You can see issues relating to this both here and here.
I've raised a bug on the musl libc mailing list (the version of libc that Alpine Linux uses) to hopefully get this fixed, but this would seem like an even easier 'fix' (improvement at least) on the Rancher side since it just involves changing a single variable, which has a positive performance impact too.
Please let me know what you think?

It looks like the underlying problem that inspired me to create this issue may be a Rancher bug too.
Thanks!

Hi,
With kubernetes and docker running Alpine Linux without cropping manually  the search field
I can't resolve name.
Before (not working) :
search default.svc.cluster.local svc.cluster.local cluster.local kubelet.kubernetes.rancher.internal kubernetes.rancher.internal rancher.internal
nameserver <IP_ADDRESS>
options ndots:5

$ nslookup google.com
nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'google.fr': Name does not resolve

After cropping (working):
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver <IP_ADDRESS>
options ndots:5

$ nslookup google.com
nslookup: can't resolve '(null)': Name does not resolve

Name:      google.fr
Address 1: <IP_ADDRESS> wo-in-f94.1e100.net
Address 2: 2a00:1450:400c:c07::5e wo-in-x5e.1e100.net

Do you experience same problem ?
I use image like docker:dind based on alpine.

I'm currently experiencing something that might be related to this.  I'll describe below and I can raise a new issue if it turns out to be something else.
I have a Kubernetes cluster running in Rancher on 3 bare-metal nodes.  For some reason containers in pods I've deployed via kubectl can't resolve internet addresses properly.  Commands like nslookup, curl, git clone and anything http-related all fail.  Any internet address resolves to <IP_ADDRESS>, which is the address of my internal DNS server (which is configured on the hosts):
root@buildit-jenkins-7b7587bcbd-tf8sg:/# ping github.com
PING neptune.webster.com (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: icmp_seq=0 ttl=63 time=0.368 ms

Other commands like dig and drill (on Alpine) work properly.  This behavior occurs in both Debian and Alpine images.
If I comment out this line in /etc/resolv.conf then everything starts working:
options ndots:5

So I'm not sure what's going on at all here.  Anyone have any ideas?  Here's my resolv.conf:
nameserver <IP_ADDRESS>
search default.svc.cluster.local svc.cluster.local cluster.local rancher.internal rancher.zone  webster.com
options ndots:5

Thanks for your report!
With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.
If you think we should keep this issue open, please let me know.


Compilation issue of RPC agent.

For fixing, added below flag to the CMAKE Command.
$sudo cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/cmake ..

Which distro were you using that required explicitly passing in the CMAKE path? For the distros we've tested, the package manager installs cmake to the distro specific path, which ends-up being available via the PATH variable. Thanks!

@mpvats-intel provided an answer and no response.  closing issue as resolved.


Rev C Battery Buzzer

This should no longer drain the battery while off but plugged into the battery.
Before, drain was calculated to be about 1mA through the voltage dividers.  (It would take a week to drain the battery 200mAh.)
Now it is about 3uA due to combined drain-to-source leakage.  (It would take several years to drain the battery 200mAh.)

reviewing

Merged.


[stable/fluent-bit] Add GELF backend type

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

No, this is a change to an existing chart.
What this PR does / why we need it:
Adds support for the GELF backend to the Fluent Bit
Special notes for your reviewer:
This was forked off #17144, since that PR was marked as stale.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @hectorj2f

/ok-to-test

This PR is a duplicate of: https://github.com/helm/charts/pull/17144


Remove inactive elements from the semantic tree

In this PR:

OverlayEntries can be a semantic barriers meaning that everything below that entry is no longer included in the semantics tree (used for e.g. Dialogs).
When the Drawer in a Scaffold is open all elements outside of the drawer are no longer part of the semantics tree.
A new includesNodeWithLabel matcher for tests.

This is fantastic.

This patch introducesExcludeSemantics widgets between Stack and its children (which can be ParentDataWidgets). This causes asserts to be thrown (see https://travis-ci.org/flutter/flutter/jobs/235859177#L549).
@abarth Do you have an idea for a clean solution to fix this? Hixie and I were out of ideas today.

I'd try a different approach.
Currently, we have RenderExcludeSemantics, which hides a subtree of render tree from the semantics compiler.  I'd try adding a RenderSemanticsBarrier that prevents the semantics compiler from seeing anything before it in paint order.  I'd then teach ModalBarrier to build a SemanticsBarrier.
Essentially, you're trying to use a tree-order primitive to do a paint-order job.  Instead, you might have more success if you invent a paint-order primitive to do a paint-order job.

Yeah, that was the other approach we talked about, though we had dismissed it as impractical. Speaking with Adam this morning, Adam convinced me that we should take a look at that again. It certainly would be more idiomatic and would more closely match what we're really doing.

@goderbauer I'm going to close this PR since we've concluded this approach isn't going to work. I hope that's ok. (I'm going through open PRs tidying things up.)


Update autorest version to prerelease 3.0.0-alpha.20240506.2

Triggered from branch: feature/v3

API change check
API changes are not detected in this pull request.


Add Leetcode solution for problem number 454(4Sum II)

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Given four integer arrays nums1, nums2, nums3, and nums4 all of length n, return the number of tuples (i, j, k, l) such that:
0 <= i, j, k, l < n
nums1[i] + nums2[j] + nums3[k] + nums4[l] == 0
Use Case
Input: nums1 = [1,2], nums2 = [-2,-1], nums3 = [-1,2], nums4 = [0,2]
Output: 2
Explanation:
The two tuples are:

(0, 0, 0, 1) -> nums1[0] + nums2[0] + nums3[0] + nums4[1] = 1 + (-2) + (-1) + 2 = 0
(1, 1, 0, 0) -> nums1[1] + nums2[1] + nums3[0] + nums4[0] = 2 + (-1) + (-1) + 0 = 0

Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@Ajay-Dhangar  Sir please add respective labels

/assign me


Ambiguity in generated sdk.go file for controllers.

Describe the bug
Some of the autogenerated code throws error when building controller's main.go
Steps to reproduce

Add '_ "github.com/aws/aws-controllers-k8s/services/apigatewayv2/pkg/resource/api"' to main.go file so that resourceManagerFactory is initialized.
run go build -o ../../bin/controller main.go
Following errors show up apart from https://github.com/aws/aws-controllers-k8s/issues/98

# github.com/aws/aws-controllers-k8s/services/apigatewayv2/pkg/resource/api
../../pkg/resource/api/sdk.go:61:3: undefined: tmpElem0
../../pkg/resource/api/sdk.go:61:36: elem0.ImportInfo undefined (type *string has no field or method ImportInfo)
../../pkg/resource/api/sdk.go:62:23: undefined: tmpElem0
../../pkg/resource/api/sdk.go:67:3: undefined: tmpElem1
../../pkg/resource/api/sdk.go:67:36: elem1.Warnings undefined (type *string has no field or method Warnings)
../../pkg/resource/api/sdk.go:68:23: undefined: tmpElem1
../../pkg/resource/api/sdk.go:108:3: undefined: tmpElem0
../../pkg/resource/api/sdk.go:108:36: elem0.ImportInfo undefined (type *string has no field or method ImportInfo)
../../pkg/resource/api/sdk.go:108:36: too many errors

iteration should be performed on responseObject and not Ko.Status.ImportInfo

tmp0 := []*string{}
	for _, elem0 := range ko.Status.ImportInfo {
		tmpElem0.__listOf__string = elem0.ImportInfo
		tmp0 = append(tmp0, tmpElem0)
	}
	ko.Status.ImportInfo = tmp0

Expected outcome
Controller's main.go to build successfully
Environment

Kubernetes version 1.14
Using EKS (yes/no), if so version?  yes
AWS service targeted (S3, RDS, etc.) apigatewayv2

The above code fixes the original issue, but following is one more case where the generated code fails to build.
This bug is surfacing in sdkFind method for apigatewayv2 api resource.
../../pkg/resource/api/sdk.go:64:3: undefined: f7elem
        ko.Status.APIEndpoint = resp.ApiEndpoint
	ko.Status.APIID = resp.ApiId
	ko.Status.CreatedDate = &metav1.Time{*resp.CreatedDate}
	f7 := []*string{}
	for _, f7iter := range resp.ImportInfo {
		f7elem.f7 = f7iter
		f7 = append(f7, f7elem)
	}
	ko.Status.ImportInfo = f7

The iteration for f7iter thrown exception for undefined variable.

Turns out this is happening because of APIGatewayV2's "Shapes that are structures but really are not structures but are actually just aliases for strings". Things like these:
    "StringWithLengthBetween0And1024" : {
      "type" : "string"
    },
    "StringWithLengthBetween0And2048" : {
      "type" : "string"
    },
    "StringWithLengthBetween0And32K" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And1024" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And128" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And1600" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And256" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And512" : {
      "type" : "string"
    },
    "StringWithLengthBetween1And64" : {
      "type" : "string"
    },

The code that is generating a constructor for fields that are defined like this:
    "CreateRouteInput" : {
      "type" : "structure",
      "members" : {
...
        "AuthorizationScopes" : {
          "shape" : "AuthorizationScopes",
          "locationName" : "authorizationScopes"
        },
...

are looking at the AuthorizationScopes shape definition:
    "AuthorizationScopes" : {
      "type" : "list",
      "member" : {
        "shape" : "StringWithLengthBetween1And64"
      }
    },

and getting confused because StringWithLengthBetween1And64 is another Shape but is really just a string.


NgModules for RC5

We should refactor the app to use NgModules, this way we can remove the directives/pipes from all components.
Should we make an NgModule / chart type, and a global one that export everything ?

@ocombe - Is this complete?

yes


Refactor with hooks

Third Milestone 🔢
Changes in this pull request :

Update Calculator.js from class to function.
Use useState hook.
Update logic/calculate.js to match the new changes, because  this.setState merges the old and new state, useState doesn't.

ScreenShot

Hi @benwmx  🙋♀,
STATUS APPROVED ✔
Good job on the pull request 👍🏾
Functional components ✅
Git flow 👌🏾
Your project is complete!  There is nothing else to say other than... it's time to merge it 🔗 🚢
Congratulations! 🎉
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers 🥂  and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Improving efficiency of db queries for students

To help address #1244, this took 1/3 the time to execute the student queries with 500 fake students.

Also removing that errant yarn-error log for #1245

👍  let's see what kind of improvement this creates in prod!

Hey @edavidsonsawyer! I pushed this to the live tool and tested it a few times with an in-browser stopwatch. There's definitely an improvement, and it does seem to be in the neighborhood of 1/3 the original time. That puts us from 60 second load times to 20 second load times, which is better but still not in the neighborhood we want to be in.
My suggestion for a next step: @kevinrobinson has been doing some excellent work compressing JSON in #1228. This strategy involves moving from an HTML-rendering path for putting data on the page to a JSON-oriented path where an HTML page loads, the JS runs, and it requests data via a JSON endpoint that can be compressed and help optimize.
I'm going to work on merging in @kevinrobinson's #1228 (looks like it has a couple of merge conflicts) so that we can take advantage of the compression/optimization he's unblocked for us.
If you have other suggestions or strategies we should try @edavidsonsawyer please post them! Let's keep working on this until the load time gets pushed down into the neighborhood we want!

Thanks, @alexsoble! The stuff @kevinrobinson is doing looks promising. I'll add further suggestions to #1244. In the meantime, would you be able to check on the prod site and see the effect of changing the dates via the slider? I suspect the slowness isn't coming from the render but I want to make sure that's the case.

Hey @alexsoble and @kevinrobinson! I'm noticing the school view (which I'd imagine has some of the same problems the dashboard does) takes advantage of a precompute job. Is there any objection to my adding some dashboard specific tasks there?

@edavidsonsawyer When I move the sliders it takes about five seconds (counting out loud) for the data to update.

@alexsoble thanks. There's probably some optimizations I can do in there.

@edavidsonsawyer Ya, my feeling is let's make sure we've tackled the productive optimizations available to us in the existing code before adding a precompute jobs. Precompute jobs are awesome but sometimes they fail; they need to be debugged when they fail; there needs to be a fallback strategy for when they fail . . . fixing the N+1 query cut the load time down to a third, if we can find a couple of more low-hanging optimizations like that we'll be in a business. Also I'd say the slowness in the slider response indicates we could cut several seconds out in the JS alone.

@alexsoble makes sense!


Please add percentage information to atleast India level numbers.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
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.

Could you please elaborate on what percentage information?

Like percentage of death in all cases , percentage of people cured out of all cases , percentage of death among closed cases e.t.c

Implementation done.


HTTP/3 connection params

Dedup client/server builders. And it's likely there will be more shared parameters in the future.

Should we keep the client/server builders? Also, any suggestions on the name of the parameter builder?

Should we keep the client/server builders?

I would keep the client/server builders because there will possibly be parameters which only belong to server or client.

Also, any suggestions on the name of the parameter builder?

Maybe just ParameterBuilder? But i'm not good with names.

The API still feels a bit weird. There should probably be one builder instead of two: Config and Builder.
h3::config::Config {}

h3::client::Builder { config }
h3::server::Builder { config }

So, it should either be something that looks like
// somehow dedupped
h3::config::ClientConfig {}
h3::config::ServerConfig {}

// no more Builder
h3::client::new(conn, client_config)
h3::server::new(conn, server_config)

or
// somehow dedupped
h3::Endpoint::client().build(conn)
h3::Endpoint::server().build(conn)

I like this option better.
// somehow dedupped
h3::config::ClientConfig {}
h3::config::ServerConfig {}

// no more Builder
h3::client::new(conn, client_config)
h3::server::new(conn, server_config)

Yeah. Using a config struct has a potential advantage of easier mapping to settings. We could potentially have something like impl From<Config> for Settings.

Changed user-facing config structs to be compositions:
ClientConfig { conn: ConnectionConfig, ... }
ServerConfig { conn: ConnectionConfig, ... }

this way we could could easily provide some config for the shared ConnectionInner.


[HOLD Web-Expensify 30466] Add email to the set password link

Details
The SetPassword API command requires an email to be provided, along with a new password and a validateCode. For the SetPasswordPage, we were previously assuming that the email would be read from Onyx storage.
However, that may not be the case if we send the user a set password link via a notification, as the user may not have completed the first part of the sign-in flow (which saves their email into Onyx storage). If this is the case, the API call to SetPassword will fail since the email sent over will be undefined.
In lieu of the changes in https://github.com/Expensify/Web-Expensify/pull/30466/ and https://github.com/Expensify/Auth/pull/5402, I'm adding an email parameter to the set password route to ensure we're always sending over and reading an email when the user navigates from this page.
Fixed Issues
Fixes Expensify/Expensify#156786
Fixes https://github.com/Expensify/Expensify/issues/157873
Tests (local dev)

On Web-Expensify, check out jasper-ecashValidatePasswordEmail; on Auth, check out and make jasper-resendValidateCodeSetCashPassword.
Make sure you're following the steps with an unvalidated Expensify email. Run ./script/sql.sh then:

Get your accountID:

SELECT validated from accounts WHERE email = "[your<EMAIL_ADDRESS>

Make sure your account is invalidated with this command:

UPDATE logins SET validatedDate = "" WHERE accountID = [your accountID];

Make sure you've got the most up to date partnerName for Expensify.cash:

INSERT OR IGNORE INTO partners ( created, partnerID, partnerName, partnerPassword, partnerKey ) VALUES ( '2021-03-18 00:00:00', 84, 'chat-expensify-com', 'DD1431EB9E11F0071EC05C24E9CB2FD595B1ED75', 'asdf,fdsa');

Hit expensify.com.dev/api?command=ResendValidateCode&referer=https://expensify.cash/&accountID=[your accountID] to queue up a job that will send yourself a set password email.

Use SELECT * from notifications; and check to make sure there's a SetCashPassword notification with your accountID queued up in the last row.

Then run vssh and php /vagrant/Web-Expensify/script/notifyall.php to send it out.

to troubleshoot bedrock jobs, use the dev Bedrock Job Manager

Check your email for an email with the subject "Your magic sign in link for Expensify.cash". Click on the link.
Modify the first part of the URL with whatever localhost:[port] your local version of cash is running on (e.g. localhost:8081)

After this, the URL should look something like this: localhost:8081/setpassword/[accountID]/[validateCode]

Navigate to that new URL and set a new password (it's better to do this in an incognito window).
Sign out of e.cash and try to sign in to that email with the new password. Verify that you can sign in.

Tested On

[x] Web
[x] Mobile Web
[ ] Desktop
[ ] iOS
[ ] Android

Screenshots
Web

Mobile Web

For your mobile web screenshot, is there a way we can give the whole page a background color so that we don't have the strange background color block below the form content?

@shawnborton For sure! I made a new issue since it's not entirely related to what I'm fixing here. I've included more details in the issue. Look out for a PR soon!

QUESTION FOR REVIEWER: Is this testable on Desktop/iOS/Android?

Short answer: No.
Longer answer: Once we have "deep links" set up for iOS and Android we can theoretically drop you straight into the app on your device and everything should work the same (see Deep Linking in react-nav docs). There is an issue here to address this. As for Desktop, I think it just wouldn't be very valuable to implement right now, but maybe in the future.

I'm curious if this issue is related: https://github.com/Expensify/Expensify/issues/157873  to this PR?

Hmm not sure if related.. the error you are seeing there seems to suggest that we have not set the login in credentials.
https://github.com/Expensify/Expensify.cash/blob/ec2ffc28f0d988cb73daad44c037534ba676c287/src/libs/actions/Session.js#L216

LGTM (besides everything @chiragsalian mentioned so far)

Is this ready for review? If so you'll need to let us know by posting "Ready for review" and / or clicking the re-request review icon next to our names in the reviewers section.

@chiragsalian I left a comment on your review that I thought would be better for you to respond to first before reviewing, but looking back I should have just requested another review. Thanks for making sure I stay on top of this and sorry for all the back and forth!

I left a comment on your review that I thought would be better for you to respond to first before reviewing

Just so I'm on the same page are you talking about a comment on my review in this PR or elsewhere that you are waiting for a response? Either way, if i haven't responded to it can you link me which comment you're waiting for a response from 🙂
Also yeah no worries about the back and forth. As long as there is daily movement its all cool.

Looks like you were able to get to my comment anyways! Thanks :)

Is this still on HOLD ?

@marcaaron, Yes because https://github.com/Expensify/Web-Expensify/pull/30466 isn't live yet.

@jasperhuangg let's add some QA test steps to the description in addition to the local dev steps?

This LGTM. I tested on iOS and also Android since I noticed we did not test on those platforms. We should let QA know that they can test iOS and Android by clicking on the links with the app installed (at least this should work in theory).

Thanks a lot!


MaterialApp.builder introducing strange context issues

I'm trying to use MaterialApp.builder() to wrap all my views, in an enclosing 'RootView' widget, which contains the Scaffold.
So, looks something like this:
MaterialApp(
   builder: (context, route) {
     return RootView(child: route);
   },
   home: Page1(),
)

class RootView extends StatelessWidget {
  final Widget child;

  const RootView({Key key, this.child}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      drawer: Container(width: 200, color: Colors.red),
      body: child,
    );
  }
}

When I do this, I get some weird behavior in my Scaffold.

The default "leading" icon for the drawer, throws an No Overlay widget found. error. Screenshot: http://treefortress.com/shared/qemu-system-i386_2019-11-24_16-22-11.png

When trying to call showBottomSheet(), I get an error The method 'addLocalHistoryEntry' was called on null., this seems to be because the ModelRoute.of() call inside Scaffold, is returning null.

What gives?
If I omit builder, and do the exact same thing inside Home, everything works as expected.
So this works fine:
MaterialApp(
   home: RootView(child: Page1()),
)

This does not:
MaterialApp(
   builder: (context, route) => RootView(child: route),
   home: Page1(),
)

As I understand the builder usage, these should be functionally equivalent??
Wrapping everything in Home is not a real solution, as I want a persistent Scaffold, AppBar and Drawer, with only the body of the scaffold changing each time a new page is pushed to the Navigator.
UPDATE
I've found 2 workaround that get the job done.

Using the MaterialApp.onGeneratedRoute method, and wrapping the RootView there
When pushing a new route, wrap the RootView there:

Navigator.of(context).push(
    MaterialPageRoute(builder: (context) => RootView(child: Page2())),
);

Hi  @esDotDev
given your last update

UPDATE
I've found 2 workaround that get the job done.

Using the MaterialApp.onGeneratedRoute method, and wrapping the RootView there
When pushing a new route, wrap the RootView there:

Navigator.of(context).push(
    MaterialPageRoute(builder: (context) => RootView(child: Page2())),
);

I feel safe to close this issue,
if you disagree please write in the comments
and I will reopen it.
Thank you

Hey, no I don't feel like this should be closed, as the workaround should not be necessary, and something is still broken with builder(). I would love to have some clarification around what is happening, and why builder does not work in this case.

I don't understand closing this. It's a clear bug in the API. You'd think you'd at least want to track it?

Issue # 1 and 2 are replicable on latest dev channel.

Now that I understand Material App better, I'm not sure this is a bug. The child returned by builder is the navigator object itself, not the child route. This means that you can't use Builder in this way, you can not inject anything between MaterialApp and Navigator, like I'm trying to do with Scaffold.

Now that I understand Material App better, I'm not sure this is a bug. The child returned by builder is the navigator object itself, not the child route. This means that you can't use Builder in this way, you can not inject anything between MaterialApp and Navigator, like I'm trying to do with Scaffold.

@esDotDev I don't understand your point here.
If I try to provide the leading by myself or set the automaticallyImplyLeading to false in the app bar then there is no error.
 AppBar(automaticallyImplyLeading: false),

Also if I use Column or ListView as root widget of Scaffold Body then that also not working.


fix(r11s-chart): Fixes to r11s chart

Description
Fixes a couple of syntax issues in a JSON template for the r11s cluster

Extra comma
Extra closing brackets
Incorrect way of processing an array value in go-template lang

Also re-adds a property that was mistakenly removed in this PR.

@pradeepvairamani @znewton FYI


[Feature] Word Calculator

Description
Feature Proposal: Average Word Length, Export Results, Total Word Count, and Unique Word Count
Description
I propose adding four new features to enhance the functionality of the word calculator:

Total Word Count: Include functionality to count and display the total number of words in the provided text.
Unique Word Count: Implement a feature to count and display the number of unique words in the text.
Average Word Length: Calculate and display the average length of words in the given text.
Export Results: Allow users to export the calculated results in different formats (e.g., CSV, JSON) for further analysis or documentation.

Assign this Feat Issue to me ! Thank you.
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @Tholkappiar


⚠ GreatPosterWall has degraded performance

In 1f4fb61, GreatPosterWall ($GPW) experienced degraded performance:

HTTP code: 200
Response time: 2499 ms

Resolved: GreatPosterWall performance has improved in 5847afb after 6 minutes.


Fix Travis Builds for Pull Requests

This should fix Travis Builds for Pull Requests. Currently, builds fail since Travis switched to Ubuntu Xenial where Oracle JDK 8 isn't available.
See https://travis-ci.community/t/install-of-oracle-jdk8-is-failing/4365/2.

I also removed the sed command as it was unnecessary and causing the build to stall.


[EventHubs] fix sample issue when running in build pipeline

The value provided to EVENTHUB_CONNECTION_STRING in the live test pipeline
doesn't contain the event hub name so it's failing with error:

TypeError: Either provide "eventHubName" or the "connectionString": "***", must contain "EntityPath=".

This PR passes event hub name too to the client constructor in the same way as
some other tests do.
Fixes #20369

/azp run js - event-hubs - tests


Error message when using ocsp tool with -verify_other option

Using openssl master (bfd6b619b6ccba8, beta1-in-dev).
When the ocsp tool is used to query an OCSP responder, it prints the response status, as expected.
But when it's executed with the -verify_other option it prints an error in addition to the positive status:
40E77536037F0000:error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:crypto/encode_decode/decoder_lib.c:92:No supported data to decode.

Reproducer:
wget https://raw.githubusercontent.com/redhat-qe-security/certgen/master/certgen/lib.sh
. lib.sh
x509KeyGen ca
x509Key --der ca
x509SelfSign ca
x509KeyGen server
x509CertSign --CA ca server

openssl ocsp -index ca/index.txt -port 8888 -rsigner $(x509Cert ca) -rkey $(x509Key ca) -CA $(x509Cert ca) >ocsp.log 2>ocsp.err &
sleep 1

# clean output:
openssl ocsp -CAfile ca/cert.pem -issuer ca/cert.pem -cert server/cert.pem -url http://localhost:8888

# output with error message:
openssl ocsp -CAfile ca/cert.pem -issuer ca/cert.pem -verify_other ca/cert.pem -cert server/cert.pem -url http://localhost:8888

I've bisected between 3.0.0 alpha16 (where it's not a problem) and current master @ 6d2e0076e6a8146f3 (where it is) and the problematic commit is 4d2d4b4bc1a8515fa


Testing codefresh workflow

Change Overview
Ignore the PR.
Pull request type
Please check the type of change your PR introduces:

[x] :construction: Work in Progress
[ ] :rainbow: Refactoring (no functional changes, no api changes)
[ ] :hamster: Trivial/Minor
[ ] :bug: Bugfix
[ ] :sunflower: Feature
[ ] :world_map: Documentation
[ ] :robot: Test

Issues

#XXX

Test Plan

[ ] :muscle: Manual
[ ] :zap: Unit test
[ ] :green_heart: E2E

dummy PR raised for testing codefresh workflow with release process

ok-to-test

ok-to-test

ok-to-test

Closing the PR as its was just for testing

/ok-to-test


[$500] IOU - Page shows spinner after returning from Amount editor in confirmation page

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

Version Number: v.1.4-37.0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation:
Action Performed:

Go to staging.new.expensify.com
Go to FAB > Request money > Manual.
Enter amount > Next.
Proceed to confirmation page.
Click Amount.
Click Back button.

Expected Result:
App returns to confirmation page without loading.
Actual Result:
App loads briefly when returning to confirmation page.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/3c29b2f9-9d39-455b-a5ad-33d56826a128

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01df4afe95e80594cd
Upwork Job ID:<PHONE_NUMBER>947040256
Last Price Increase: 2024-02-06

We think that this bug might be related to #vip-bills
CC @davidcardoza

This is intentional to show the spinner as it might show outdated currency, which might be confusing to the user. See https://expensify.slack.com/archives/C01GTK53T8Q/p1705504483396879?thread_ts=1704818739.022579&cid=C01GTK53T8Q also.

This was indeed discussed and we landed on the current spinner solution. I'm not sure that this is the best UX, but this is definitely not a blocker. Gonna close the issue. Thanks everyone!


200.2 release

Merge v.next (200.2) into main.
This was done through the following steps:

Make a local, untracked copy of v.next and set aside
Check out main
Merge v.next into main
Commit all merge conflicts to resolve commit history
Replace conflicted directory with local copy and commit

This branch is now up to speed with main and consistent with v.next. Hopefully this resolves the hundreds of commits going forwards.

Please disregard the style check errors. It's a false positive as a result of the Surface Placement sample having an odd filename convention.