Unattend.xml support for Windows

Is your feature request related to a problem? Please describe.
Windows supports Unattend.xml to configure a Windows machine during installation. It would be really helpful if a Windows machine had the ability to support specifying your own unattend.xml.
Describe the solution you'd like
That Harvester supports defining your own unattend.xml file in place of the cloud-init when using Windows. The Azure Terraform provider moved to have a Windows and Linux machine resource to allow for those differences to be expressed explicitly.
Describe alternatives you've considered
An alternative to supplying an entire unattend.xml is to specify a default unattend.xml that bootstraps the drivers like in the quickemu project, then just provide fields for the pieces that need to be configurable like the host, users, and any commands you want executed.
Additional context

This type of capability would be very nice indeed.
The alternative, which we have been able to get working is to:

Generate an AutoUnattend.xml file
Create an ISO image including this file
Create an ISO resource in Harvester using that ISO image
Define the VM with the ISO from above in the correct boot order

It works, but it is quite cumbersome/fragile, even when automated.

We only need to change UI to complete the feature. Following are my steps to create a Windows VM with unattend.xml.
Setup

Create a Windows Image.

Case 1: Windows VM with default password

Create a ConfigMap win-default-password-configmap with default password 123456.

apiVersion: v1
kind: ConfigMap
metadata:
  name: win-default-password-configmap
data:
  unattend.xml: |-
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
      <settings pass="oobeSystem">
        <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
          <OOBE>
            <HideEULAPage>true</HideEULAPage>
            <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
            <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
            <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
            <NetworkLocation>Work</NetworkLocation>
            <SkipUserOOBE>true</SkipUserOOBE>
            <SkipMachineOOBE>true</SkipMachineOOBE>
            <ProtectYourPC>3</ProtectYourPC>
          </OOBE>
          <AutoLogon>
            <Password>
              <Value>123456</Value>
              <PlainText>true</PlainText>
            </Password>
            <Enabled>false</Enabled>
            <Username>Administrator</Username>
          </AutoLogon>
          <UserAccounts>
            <AdministratorPassword>
              <Value>123456</Value>
              <PlainText>true</PlainText>
            </AdministratorPassword>
          </UserAccounts>
          <RegisteredOrganization/>
          <RegisteredOwner/>
          <TimeZone>Eastern Standard Time</TimeZone>
        </component>
      </settings>
    </unattend>

Use windows-iso-image-base-version template or follow the document to setup a Windows VM. Don't click Create button at this step.
Click Advanced Options and choose Windows as OS Type.

Click Edit as YAML.
Add win-default-password-configmap ConfigMap as a sysprep volume and add sysprep volume as a disk device.

Create the VM.
Install Windows without desktop.
After installation, we will see a lock page, because we don't enable AutoLogon.

Follow Ctrl-Alt-Del to unlock the page and input 123456 as password.

Finally, we can login without error.

Case 2: Windows VM with auto login
Follow the steps in Case 1. The only different part is changing false to true in the AutoLogon.Enabled field in the ConfigMap.


Bug: Reshape() with -1 fails

When calling the chainer function Reshape() with a -1 value (e.g. Reshape((-1, 10, 10))) I get an error:
InvalidType: Expect: prod(in_types[0].shape) == prod((-1, 10, 10))
Actual: 2800 != -100

The cupy function reshape does support -1 arguments, so the error seems to be just the check in chainer's Reshape. The problematic check is:
_type_check_prod(in_types[0].shape) == _type_check_prod(self.shape)
If a -1 argument is present, it should instead check if the size of in_types[0] is divisible by the product of the axis-lengths that are not -1.
I would send a PR but I'm not exactly clear on the correct usage of type_check.expect, and had some issues with it in the past. Should be simple enough to fix though.

Thank you for reporting a problem. As you say, Reshape can easily support -1 value.
I'll fix its type check method.


Caching until the data has changed

Hi @Kikobeats 👋
I came across your PR in Next.js that replaces LRU cache with the library and decided to drop a line. Curious if cacheable-response could potentially offer a solution to my problem.
Imagine a Next.js app that's sitting in front of a GraphQL server, which serves a more or less static dataset. This can be a list of products, which normally changes once in a while, but this can happen at any time. Alternatively, the website can focus on showing weather forecasts, which update a few times a day.
What we need for these conditionally static websites is to avoid rendering React trees on every request. At the same time, we want to have an option to flush or miss the cache before any for the requests after running some async checker. On a product website this could be a light GraphGL query to the backend asking the modification time and on the weather website we can just check the current time. In both of these cases, I would like to cache pages forever until the condition has changed, but at the same time I would never want to send the x-cache-expired-at header to the clients, because any page refresh at any time can unexpectedly result the new data.
Implementing these tricks seems somewhat possible by adding additional express logic around your module, but I'm wondering if it's possible to add some native support. WDYT?
Thanks for your work!

You can achieve with:

Setup an Infinity ttl cache. Content will never expired.
When you need to refresh the cache copies, create a request with forceas a query param. It can be done internally, doing ping to your own API, then the user never face with the problem.

That’s what I’m about to do, yes. Except that there’ll be my dataset timestsmp instead of force as a param. What I’d like to avoid doing is removing the headers that your module sets. Can there be added an option that does not set response headers?

note that x-cache-expired-atis just for debugging purposes; why remove that since users are not going to see it and you know what the value represent?

But does not x-cache-* get picked by a reverse proxy and turned into a real cache header? That's what I thought but I might be wrong. If that's the case, an option to not set these headers would be useful.
Also, a method to reset the whole cache could be useful in the use cases described above. Calling it after quickly checking the dataset modification date feels easier than injecting custom get requests to artificially miss the cache. What I mean is something like lruCache.reset(). Changing request parameters instead of resetting cache causes higher RAM usage over time.

I don't think so. Prefixed header with x- are not standard and in this case the value is written in a human readable format intentionally

Even if there's no chance that headers can be picked up by reverse proxies, what is the benefit from making them compulsory in production? Regardless of them, cache-control that's being set at all times does not enable the use cases described above. Well, at least if all these headers are not manually removed from the Express response (which is laborious).
WDYT re the reset method? Would it be worth discussing it in a separate issue?

As I said, it is added for debugging purposes.
If you are saying that the value is not representing the correct expiration date even after a for force refresh, that's a bug and we need to open a new issue 🙂


folder_branch_ops: add a test method for forcing a stuck conflict

This allows us to force a TLF into a stuck conflict state, where CR will not work to automatically resolve the issue.  It works by:

Writing a no-op gcOp to the main folder view, and flushing it to the server.
Reverting that op locally, to go back one revision.
Putting CR into a mode where it auto-fails every resolution.
Making 11 files one-by-one, to trigger CR this many times and get into a stuck state.
Then putting CR back into a normal mode, but it will still be "stuck" because of all the other failed attempts.

This also adds a fs force-conflict command for devel-only builds, to force it into this state for testing purposes.
cc: @jakob223 -- I basically took what you implemented in a test and put it in a proper folderBranchOps method.  I didn't both rewriting your test though, since it explicitly uses two separate users which isn't needed here.
Issue: KBFS-4136

Also, since we now have isStuck, do you want to change conflict_resolver.go to check isStuck when deciding whether or not to proceed CRing, so that we don't have the possibility of having two different logics in 2 different places checking the same thing?

I thought about this, but it's hard to get rid of the complexity in recordStartResolve() because after the "stuck" check it still depends on the db, key, and conflictsSoFar variables, so I'd have to change isStuck() to return all those variables, which somehow seemed grosser than just duplicating the code.  I'm pretty on the fence though, so if that seems better to you I'll be happy to do it.  We can also make two helper functions, isStuck() and isStuckWithConflicts() or something, and the former one can call the latter but just return the bool and drop everything else.

Also, since we now have isStuck, do you want to change conflict_resolver.go to check isStuck when deciding whether or not to proceed CRing, so that we don't have the possibility of having two different logics in 2 different places checking the same thing?

I thought about this, but it's hard to get rid of the complexity in recordStartResolve() because after the "stuck" check it still depends on the db, key, and conflictsSoFar variables, so I'd have to change isStuck() to return all those variables, which somehow seemed grosser than just duplicating the code. I'm pretty on the fence though, so if that seems better to you I'll be happy to do it. We can also make two helper functions, isStuck() and isStuckWithConflicts() or something, and the former one can call the latter but just return the bool and drop everything else.

:| it does seem like neither option is clearly better - I think the two-function approach seems the best overall.

Merging over unrelated core CI failure in kex2.


Update context.xml to remove session persistence warning

Checklist

[ ] the individual contributor license agreement is signed
[ ] commit message follows commit guidelines

Description of change

if the choice is to apply it on all applications it's OK, but I prefer to set it in the context app into server.xml


WMTS constructor throws when given bounding rectangle outside of tiling scheme

I'm parsing a WMTS Capabilities document to automatically create WMTS Imagery Providers. This generally works pretty well but I ran into a problem with this one.  They specify a bounding box that I'm converting to a Rectangle for the constructor's rectangle parameter.
<ows:WGS84BoundingBox crs="urn:ogc:def:crs:OGC:2:84">
    <ows:LowerCorner>-179.99999463556182 -88.99999992161116</ows:LowerCorner>
    <ows:UpperCorner>179.99999550841463 88.99999992161116</ows:UpperCorner>
</ows:WGS84BoundingBox>

When you pass that value (via Rectangle.fromDegrees) you wind up with a bounding rectangle such that the call to TilingScheme.positionToTileXY here in the WMTS provder constructor returns undefined -- the corners of the bounding rectangle are determined to fall outside of the tiling scheme's rectangle.  This means that 2 lines later the references to the x and y coordinates of those tiles will throw, all the way out of the constructor.
I traced this through the WebMercatorTilingScheme constructor and it looks like the bounding rectangle for the default version of that (no arguments) winds up being between about 85 degrees N/S.  So, it looks like in the interim, I can either clamp my Rectangle construction to avoid passing bounds outside of 85 degrees (probably fine for my use case), or I can construct my own replacement tiling scheme (which I haven't done before and probably don't need to invest time in learning).
What's the long term fix for this?  Maybe it's using the intersection of the tiling scheme rectangle with the rectangle argument as the actual bounds -- that's probably the approach I'll use.  But it definitely shouldn't just throw due to an unchecked null-pointer error, at least.

@tfili @kring any thoughts on this?

The error could probably be handled better but the coordinates are invalid for Web Mercator. Anything outside of 85.06/-85.06 is invalid.
What should be done with the tiles? Do we cut off the parts outside the range and use the tiles like normal? Do we expand the range covered by each tile? Or maybe just the top/bottom rows? There are multiple ways to handle it and who knows if any will be correct. It sounds like your approach would only work if the tiles actually only covered 85.06/-85.06.
Really I think the correct answer is to throw on construction, maybe with a more informative message.


Building join queries failed on some Cultures due to ToUpper conversion of Join.Type

Some Cultures produce invalid join syntax when coverted to upper case by ToUpper because it converts i to uppercase dotted I. Changing it to ToUpperInvariant solves the issue.
public class Join : BaseQuery<Join>
{
  protected string _type = "inner join";

  public string Type
  {
    get
    {
    	return _type;
    }
    set
    {
    	_type = value.ToUpper(); // resolved by changing value.ToUpperInvariant()
    }
  }

@gongun  There have been a few culture-specific issues recently.
I've just replaced all ToUpper() calls with ToUpperInvariant(). The build should be on MyGet as a pre-release.
Added #225 for reviewing culture-specific issues.


[Feature Request] An api to support deepseek V3

🥰 Feature Description
An interface to support deepseek V3 model.
🧐 Proposed Solution
An interface to support deepseek V3 model.
📝 Additional Information
No response

#5989


Change text FE

What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
What is the current behavior?
Please link any relevant issues here.
What is the new behavior?
Feel free to include screenshots if it includes visual changes.
Additional context
Add any other context or screenshots.

@LuongBinh double checking you intended this to be a PR on this repo? What was your intent with these changes?
Also heads up - you've leaked your OpenAI API key on your forked branch (showing in this PR). You should rotate this key ASAP if you haven't already. Be sure to not commit credentials/keys/secrets to Git!


Feature: Prompt Template Registry

Description:
the current solution supports fixed prompt templates defined in the LLM adapters lambda functions. While this provide flexibility to change the prompts it does not easily enable experimentation.
We are proposing to add a separate Prompt Template Registry to store multiple versions of prompts linked to specific model adapters.
The prompt registry service needs to:

store up to X versions of a prompt template set per model adapter. A prompt set is defined as 1 or multiple prompts required by the model interface to operate (idefics requires 1 prompt, langchain requires 3 prompts, etc)
maintain an editable draft version
OPTIONAL: create a readonly version from the current DRAFT
provide backend validatation of prompts based on the interface. For example: Langchain prompt templates require specific placeholders depending on the prompt (std, qa, condense);
allow users to quickly experiments with variations of prompts in a set via the UI
provide validation/warning in the UI when the prompt entered does not match what required by the model: Eg Human/Assistant pattern for Claude, or [INST] pattern for LLama2 and derivatives

The current functionality needs to be modified to make use of the prompt registry and in particular the chat bot playground MUST allow the user to select version of the prompt set compatibile with the selected model. This choice MUST be persisted locally for each combination used (default is using the DRAFT prompt set).
The initial DRAFT prompt set for each model corresponds to the current prompt templates defined in the model adapters.

Replaces #133

Replaces #72

this is sorely needed, @massi-ang have you started on this on yet? if not I will take it on.

We are considering the integration of Promptus https://github.com/aws-samples/promptus. Can you provide your feedback on that tool if you have time? Could you work on the integration?

That looks great, yes I will take it on and start looking at pulling its functionality in here

A quick fix would be just use ReACT to start in the base adapter. Haven't tested, but would this work to at least get better responses universally?
https://github.com/aws-samples/aws-genai-llm-chatbot/blob/3e3d2838385db22bf9f09b9ddefb567840a40991/lib/model-interfaces/langchain/functions/request-handler/adapters/base/base.py
def get_prompt(self):
    REACT_PROMPT_TEMPLATE = """You are an AI assistant using the REACT (Reason + Act) framework to solve tasks step by step. Follow these guidelines:

Thought: Analyze the task and think about how to approach it.
Action: Decide on an action to take based on your thought. Actions can include:

Search: Look up information
Calculate: Perform calculations
Ask: Request clarification from the user

Observation: Describe the result of your action.
Repeat steps 1-3 until you have enough information to provide a final answer.
Final Answer: Provide the solution to the task.

Always maintain a friendly and helpful demeanor. If you don't know the answer to a question, honestly admit it and explain what information you would need to provide an answer.
Current conversation:
{chat_history}
"""


repr for floats is inconsistent with CPython

From @slozier on January 11, 2016 21:6
Under CPython (2.7.x), repr of a float returns the shortest string representation which round-trips back to the value. With IronPython, repr returns the representation with 17 digits of precision (which was how CPython did it in 2.6.x).
The function of interest is __repr__ in IronPython\Runtime\Operations\FloatOps.cs.
CPython:
>>> repr(0.1)
'0.1'
>>> repr(0.3)
'0.3'
>>> repr(0.8455124082255701)
'0.8455124082255701'

IronPython:
>>> repr(0.1)
'0.10000000000000001'
>>> repr(0.3)
'0.29999999999999999'
>>> repr(0.8455124082255701)
'0.84551240822557006'

Copied from original issue: IronLanguages/main#1271

From @simplicbe on January 11, 2016 21:53
This should be fixed very easily. Should a test case be added or changed for this?

I thought there was already an issue for this.

From @slozier on January 11, 2016 22:42
I also assumed there would already be an issue for this but I had no luck finding it...


beacon: use types.NodeID over string and []byte

Motivation
Part of #4139
Changes
Instead of []byte and string track NodeIDs using the NodeID type.
Test Plan
existing tests pass
TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors merge


Cannot import blacksheep.contents. Can't deploy on Vercel

Describe the bug
I'm trying to replace my FastAPI apps on Vercel with BlackSheep.
Here is an example: https://github.com/clementpoiret/blacksheep-vercel
Unfortunately, it seems I can't deploy it, it leads to a server error because:
> Ready! Available at http://<IP_ADDRESS>:3000
> Building @vercel/python:server/api.py
Installing required dependencies...
> Built @vercel/python:server/api.py [20s]
Traceback (most recent call last):
  File "/home/cp264607/.cache/com.vercel.fun/runtimes/python3/../python/bootstrap.py", line 147, in <module>
    lambda_runtime_main()
  File "/home/cp264607/.cache/com.vercel.fun/runtimes/python3/../python/bootstrap.py", line 127, in lambda_runtime_main
    fn = lambda_runtime_get_handler()
  File "/home/cp264607/.cache/com.vercel.fun/runtimes/python3/../python/bootstrap.py", line 113, in lambda_runtime_get_handler
    mod = importlib.import_module(module_name)
  File "/home/cp264607/anaconda3/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 "/tmp/zeit-fun-b57c65a91f69d/vc__handler__python.py", line 12, in <module>
    __vc_spec.loader.exec_module(__vc_module)
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "./server/api.py", line 1, in <module>
    from blacksheep import Application, Content, Response
  File "/tmp/zeit-fun-b57c65a91f69d/blacksheep/__init__.py", line 7, in <module>
    from .contents import Content as Content
ModuleNotFoundError: No module named 'blacksheep.contents'
TypeError: Object prototype may only be an Object or null: undefined
    at Function.setPrototypeOf (<anonymous>)
    at new LambdaError (/usr/lib/node_modules/vercel/dist/index.js:9679:16)
    at Lambda.<anonymous> (/usr/lib/node_modules/vercel/dist/index.js:9812:27)
    at Generator.next (<anonymous>)
    at fulfilled (/usr/lib/node_modules/vercel/dist/index.js:9726:58)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

Do you know what is happening?
Thanks

Hi @clementpoiret
I apologize for replying late - I was very busy this week. I am not familiar with Vercel, therefore I did a bit of reading.
Judging by the comments I read under this blog post: https://dev.to/andrewbaisden/how-to-deploy-a-python-flask-app-to-vercel-2o5k
I suspect that it's possible to deploy a Python app with all dependencies (deploying the virtual environment packages without building them on the Vercel server) - this is not going to work with custom extensions libraries like those of BlackSheep. I just signed-up for Vercel and I'll give it a try, to gain a better insight. Thanks for sharing the project template!

I investigated for more than one hour, I learnt some basics of Vercel and run an application locally, but I couldn't find yet why the BlackSheep import fails.

Hi @RobertoPrevato, thanks for your investigation. Yes it also fails locally, so I think we can discard the "Vercel OS hypothesis". Mine was that vercel is looking for .py files only, which aren't here. Maybe its not compatible with cpython ?

I managed to make some progress!
Here you can see an API I deployed to Vercel, where you get a reply from BlackSheep: https://blacksheep-vercel-six.vercel.app - the import error is caused by exotic things Vercel does with the Python packages.
I found a fix by accidentally pushing a change, but this should fix the import error:
import os
import sys

sys.path.append(os.getcwd())

The error page from BlackSheep is caused by another problem: the Vercel server doesn't trigger the ASGI server lifecycle events - currently BlackSheep requires the "Start-up" event being fired by the ASGI server.
I might change this detail because it's causing several problems when underlying servers don't trigger the start event, like in this case.
The problem on the local environment happens for another reason, which I can explain tomorrow. Now it's 11 PM here. 😄

Ohh nice finding! Don't you think we can open an issue on vercel also? Because if it happens with blacksheep it can also happen for other libs 🤔

Don't you think we can open an issue on vercel also? Because if it happens with blacksheep it can also happen for other libs 🤔

Judging from what I saw yesterday night, I think so. It seems that relative imports are not working because they move Python library files and they (probably) should copy the extension files (.so files in this case) to the root folder. This being said, I'll try to create a dev distribution package of BlackSheep that doesn't use relative imports, and instead always uses absolute imports. This might fix the problem.
When it comes to the problem that happens locally, it seems it's caused by the fact that vercel dev doesn't use the same Python interpreter that is available when running the vercel dev command itself:

I prepared a Python 3.10 virtual environment
vercel dev uses Python 3.8 on the host
Python 3.8 doesn't have the extensions available because they depend on the version of Python

(this might be beause vercel doesn't support Python 3.10, yet?) - I'm not sure.

The other problem regarding lifecycle events might also be caused by breaking changes in uvicorn or the ASGI specification: I need to check this before I can be certain that it's a problem in the Vercel ASGI handler.
If it doesn't handle life cycle events in general, this is indeed an issue because web applications often need to handle disposable things such as HTTP connection pools, DB connection pools upon start and stop.

I confirm my findings about the local environment. I made an experiment to confirm the case:

vercel dev uses different Python interpreters when installing dependencies and then when running the function app: in my case, Python 3.10 is used when installing dependencies, meaning that extensions get installed for this version of Python (e.g. example.cpython-310-x86_64-linux-gnu.so)
later when trying to run the application, it uses Python 3.8 from /usr/bin/python3 - this fails because the extension that were installed are for a different version of Python - they should be example.cpython-38-x86_64-linux-gnu.so

if I copy the required files for Python 3.8 at runtime before trying to import, it fixes the problem, but indeed the error happens for httptools - which is also using C extensions.
In my opinion this should be submitted as a bug to Vercel. Right now I don't want to put more time into this, though, because I have very little time. 😢
In summary, we are speaking about 3 different problems in this issue.

Thanks a lot, you already made awesome progress! I'll open issues directly for Vercel and reference this one :)


Let 552 fe project developer can edit existing projects

Waiting for BE response
This PR adds the Project edition page
Testing instructions
Acceptance criteria
The project developer must be signed in
(Additional criteria: The user must be the creator/owner of the project)
The user is able to edit the project’s mandatory and optional fields according to specifications and role - see snapshot spreadhseet
There will be a way to validate the information entered in the fields
Errors are displayed if the information is incorrect
There will be a way for the user to know that the content should be written in the language of the account
There will be a way confirm or dismiss the edition
Note: Save/cancel
The layout must comply with the desings defined at HeCo - Work in progress
Tracking
LET-552

Same comments from https://github.com/Vizzuality/heco-invest/pull/252 will apply here as well.


Python 3.9 does not seem run,

This issue has been moved from a ticket on Developer Community.

I am trying to run Python 3.9 but does seem to work on visual studio, I change the  to env(Python3.9(64-bit))
and try that , keeping saying  there are errors in file very time I try to start it, proceed with the project, then nother message pop up debuging does not support Python 2.5 or earlier, but I am using Python 3.9, so want is going on here, suggest to to use a virual envirionment  so I did that, does not seem run my proctject.

Original Comments
Feedback Bot on 4/5/2021, 08:08 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Original Solutions
(no solutions)

Sorry for the trouble. Please reactivate this bug with the errors your seeing. We need those to be able to help.


XDomainRequest POST should send data

Right now no payload is send because of missing parameter

Ouch... This is awkward. How did I forget that thing... Thanks a lot for the pull request. I'll merge it, make tests on my side, and push a new version tomorrow ;)


Functionality

The get functionality has been added
The add functionality has been added
The refresh button functionality has been added
The modules has been added for more simplicity for the functions
The async has been used for the functions
Added styles to the file

I've added the style in this pull request, so could you review this for the current Review request.
Thank you


swagger ui and uuid

I notices that swashbuckle's swaggerui interface relies on the swaggerui javascript code which unfortunately always assigns the same
guide value to uuid strings:
(source: https://github.com/swagger-api/swagger-ui/blob/b825e440770d9328996a116784cb77b05ab24c6c/src/core/plugins/samples/fn.js)
"string_uuid": () => "3fa85f64-5717-4562-b3fc-2c963f66afa6",
is there any way to override the client UI to randomize this everytime the "execute" button is called, specifically with net 6's minimal API configuration?

Seems like this would be a question better asked in the Swagger-UI repo?
If its possible to configure it in the ui you should be able to do it with the custom index feature: https://github.com/domaindrivendev/Swashbuckle.AspNetCore#customize-indexhtml


System.UInt64 support

Hi,
When I was using RClr and got following error:
> clrGetMemberSignature(spec_obj, 'defaultArrayLength')
[1] "Property defaultArrayLength, UInt64, can write: True"
> clrGet(spec_obj, 'defaultArrayLength')
Error in (function ()  :
  clr_obj_ms_convert_to_SEXP: COM variant type code 21 unsupported. Returning NULL
Error in clrCallStatic(clrFacadeTypeName, "GetFieldOrProperty", objOrType,  :
  Type:    RDotNet.EvaluationException
Message: Error in (function ()  :
  clr_obj_ms_convert_to_SEXP: COM variant type code 21 unsupported. Returning NULL

Method:  RDotNet.ProtectedPointer evaluateCall(IntPtr)
Stack trace:
   at RDotNet.Function.evaluateCall(IntPtr call)
   at RDotNet.Function.createCallAndEvaluate(IntPtr argument)
   at Rclr.RDotNetDataConverter.CreateClrObj(Object obj) in c:\Users\hhusl\AppData\Local\Temp\RtmpWMoV35\R.INSTALL337439456109\rClr\src\ClrFacade\RDotNetDataConverter.cs:line 603
   at Rclr.RDotNetDataConverter.TryConvertToSexp(Object obj) in c:\Users\hhusl\AppData\Local\Temp\RtmpWMoV35\R.INSTALL337439456109\rClr\src\ClrFacade\RDotNetDataConverter.cs:line 320
   at Rclr.RDotNetDataConverter.ConvertToR(Object obj) in c:\Users\hhusl\AppData\Local\Temp\RtmpWMoV35\R.INSTALL337439456109\rClr\src\ClrFacade\RDotNetDataConverter.cs:line 220
   at Rclr.ClrFacade.marshallDataToR(Object obj, Boolean tryUseConverter) in c:\Users\hhusl\AppData\Local\Temp\RtmpW

I believe this is because RClr (essentially R.NET) doesn't support the type System.UInt64. Could you help me to fix that? Thanks a lot!

R has no support for UInt64 data types (it's integer types are restricted to 32 bit).  There have been some attempts to add that in, but nothing that's built in to the default versions of R.  I would avoid UInt64 types, or if you can't, you can try to pass them back and forth as a string with converters as needed.

@evolvedmicrobe Thanks, I will try the way you suggested.


jdk 11 support

See travis CI for build failures with jdk11.  We should get this working with jdk 11

Closing as fixed via #105


Kconfig: excessive select usage

Describe the bug
Several subsytems (mcumgr, hawkbit) have defaulted to using select for all their dependencies.
https://github.com/zephyrproject-rtos/zephyr/blob/5a5e15fc958a0ce299809286a2dc9826d6e4124c/subsys/mgmt/hawkbit/Kconfig#L4-L21
https://github.com/zephyrproject-rtos/zephyr/blob/5a5e15fc958a0ce299809286a2dc9826d6e4124c/subsys/mgmt/mcumgr/Kconfig#L5-L9
https://github.com/zephyrproject-rtos/zephyr/blob/5a5e15fc958a0ce299809286a2dc9826d6e4124c/subsys/mgmt/mcumgr/transport/Kconfig.bluetooth#L5-L9
This goes against practically every recommendation in https://docs.zephyrproject.org/latest/build/kconfig/tips.html#select-recommendations.

The symbols have prompts
The symbols have dependencies
There is 0 expectation that the dependencies will ever stay in sync

Additionally, no effort has been made to address https://docs.zephyrproject.org/latest/build/kconfig/tips.html#select-pitfalls.
In general, mixing depends on and select for the same symbol commonly causes dependency loops.
This is damaging because these select statements can corrupt otherwise perfectly valid configuration setups that don't reference the offending symbol at all.
config MY_NVS_ABSTRACTION
	bool "NVS abstraction"
	depends on NVS

config MY_NETWORKING_FEATURE
	bool "Networking feature"
	depends on MY_NVS_ABSTRACTION

# Turn on networking if my app needs some feature
config NETWORKING
	default y if MY_NETWORKING_FEATURE

source "Kconfig.zephyr"

This results in the dependency loop shown below (Note the trip through config HAWKBIT):
/home/jordan/code/zephyr/zephyr/scripts/kconfig/kconfig.py: Dependency loop
===============

MY_NVS_ABSTRACTION (defined at /home/jordan/code/zephyr/zephyr/tests/misc/test_build/Kconfig:10), with definition...

config MY_NVS_ABSTRACTION
        bool "NVS abstraction"
        depends on NVS

...depends on NVS (defined at subsys/fs/nvs/Kconfig:6), with definition...

config NVS
        bool "Non-volatile Storage"
        select CRC
        help
          Enable support of Non-volatile Storage.

(select-related dependencies: HAWKBIT)

(imply-related dependencies: HAWKBIT)

...depends on NET_L2_OPENTHREAD (defined at subsys/net/l2/openthread/Kconfig:12), with definition...

menuconfig NET_L2_OPENTHREAD
        bool "OpenThread L2"
        select NET_L2_PHY_IEEE802154
        select OPENTHREAD
        select SETTINGS if FLASH
        select OPENTHREAD_SETTINGS_RAM if !FLASH
        select CPLUSPLUS
        select REBOOT
        select ENTROPY_GENERATOR
        imply FLASH
        imply FLASH_PAGE_LAYOUT
        imply FLASH_MAP
        imply MPU_ALLOW_FLASH_WRITE
        imply NVS
        imply NET_UDP
        imply NET_IPV6
        imply NET_CONFIG_NEED_IPV6
        depends on NETWORKING && NETWORKING

...depends on NETWORKING (defined at /home/jordan/code/zephyr/zephyr/tests/misc/test_build/Kconfig:19, subsys/net/Kconfig:62), with definition...

config NETWORKING
        bool
        default y if MY_NETWORKING_FEATURE

config NETWORKING
        bool "Link layer and networking (including IP)"
        select NET_BUF
        select POLL
        select ENTROPY_GENERATOR
        help
          This option enables generic link layer and networking support
          and is the basis for higher level protocols (e.g. IP protocols).

(select-related dependencies: (MCUMGR_SMP_UDP && MCUMGR) || HAWKBIT || UPDATEHUB)

...depends on MY_NETWORKING_FEATURE (defined at /home/jordan/code/zephyr/zephyr/tests/misc/test_build/Kconfig:14), with definition...

config MY_NETWORKING_FEATURE
        bool "Networking feature"
        depends on MY_NVS_ABSTRACTION

...depends again on MY_NVS_ABSTRACTION (defined at /home/jordan/code/zephyr/zephyr/tests/misc/test_build/Kconfig:10)
CMake Error at /home/jordan/code/zephyr/zephyr/cmake/modules/kconfig.cmake:328 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  /home/jordan/code/zephyr/zephyr/cmake/modules/zephyr_default.cmake:108 (include)
  /home/jordan/code/zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  /home/jordan/code/zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:97 (include_boilerplate)
  CMakeLists.txt:4 (find_package)

Impact
Valid configurations are unable to be expressed in Kconfig. Working around these issues requires patching Zephyr.

thanks for raising this. It's something I have often tried to point out but few people care.
Unfortunately at the stage where we are now, it becomes a huge task to clean up.

@JordanYates I wonder if #55297 addressed this issue?


Rig auto-assignment logic

WIP, still need to finish parsing logic and handle asset loads properly

CI fails because of existing issues I believe.


Not reactive using the local mysql server

Hi Ben,
Thanks a lot for contributing such a great package.
I have encountered one problem for using this package with my local mysql server. The problem is that is not reactive anymore: I have to manually refresh the page.
I also download your leaderboard example. If it directly uses the nutmel:mysql-server, it is reactive. However, if I switch to use my local mysql server. Even the leaderboard example is no longer reactive.
Could you please give some hints on solving this. Thanks a lot. :)

Hi zliulnspire, I was fighting with the same problem and the problem was that I created the DB with capital letter in the name... So your DB's name must be mydatabase NOT Mydatabase. I hope it helps you.

Hi @zliuInspire, I was fighting with the same problem and the problem was that I created the DB with capital letter in the name... So your DB's name must be mydatabase NOT Mydatabase. I hope it helps you.

Hey folks, does this apply to tables too, and/or with underscores? My database name is all lowercase with underscores, but I have multiple tables with capital letters & understores in it, and I'm getting the same problem.


npm & jspm grid columns too narrow (again / still)

have you made it wider before making the screenshot?
(not close to a computer)

I did not (knowing that this would indeed resolve the issue). Two reasons

I want to make all screenshots for the user manual be identical size - so until Montery can remember its size and position, this is not a good option for me.

Current problem with squished arrows happens with the Monterey default size - indicating high probability that other people with observe it as well.

are you thinking about the small numbers after sort icon, thats for showing the sort order number..
in multisort you get 1 and 2 etc etc, and they are supposed to be smaller then the main text in header

I did not even realize that there is the sort number indicator - my problem report refers to the 4 "short horizontal bars" to the left of the number. Only now, I believe that I understand that this is an icon representing "sorting".
So, please take my problem report as "make columns a bit wider, so that the bars and the small numbers get to be visible"

The sorting indicator with horizontal bars only becomes visible when columns are sorted (clicked) for the first time
No sorting

First sort order and sorting from low to high


Would like to see more async variants for cp/rm etc

Currently shelljs is useful in test suites and such like, but not so useful in a production nodejs app, if there's a need to copy/delete directories recursively, since it doesn't offer async variants of these filesystem commands. Is this a matter of principle, or just that the work hasn't yet been done?

Marking this as a duplicate of #2

Let's continue the discussion on #2


StreamFieldFactory not working

    images = wagtail_factories.StreamFieldFactory(         {"image": wagtail_factories.ImageChooserBlockFactory},     )
The images attribute is an empty list after I run this factory. What am I doing wrong?

I have the same case... On the model, the body field is a textfield. And a, example code would be:
class ArticlePageFactory(wagtail_factories.PageFactory):     title = factory.Faker('sentence', nb_words=4)     body = wagtail_factories.StreamFieldFactory({         'paragraph':  RichTextBlockFactory,         'heading': wagtail_factories.blocks.CharBlockFactory,     })     live = True
Then on the tests:
article = ArticlePageFactory(parent=root)
I get for article.body
<StreamValue []>

+1 for me as well.
On a fresh project on a cloud instance of Gitpod, after running wagtail start mysite and pip install wagtail-factories:
# home/models.py
from django.db import models

from wagtail.core.models import Page
from wagtail.core import blocks
from wagtail.core.fields import StreamField
from wagtail.admin.edit_handlers import StreamFieldPanel

class HomePage(Page):
    body = StreamField([
        ('heading', blocks.CharBlock(form_classname="full title")),
    ])

    content_panels = Page.content_panels + [
        StreamFieldPanel('body'),
    ]

# home/factories.py
import wagtail_factories

from .models import HomePage

class HomePageFactory(wagtail_factories.PageFactory):
    title = "test page"
    body = wagtail_factories.StreamFieldFactory({
        "heading": "test heading"
    })

    class Meta:
        model = HomePage

gitpod /workspace/wagtail-gitpod $ python manage.py shell
Python 3.8.12 (default, Sep 13 2021, 03:12:02)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.27.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from home.factories import HomePageFactory

In [2]: home = HomePageFactory()

In [3]: home.title
Out[3]: 'test page'

In [4]: home.body
Out[4]: <StreamValue []>

I would love to help out and fix this issue, but I'm at a loss as to where to start debugging this issue. Any tips?

@confuzeus I don't believe this issue should be closed as it does seem like a genuine bug.


fix: use regexp raw literal if possible

to get around not serializable regexp the raw literal value should be used instead of the value
FIX ISSUE #294

Any change to get this merged?

Yes when will this fix be merged? I hand code this locally and it fixed the problem.

I've not merged it because it is not the correct fix. Sorry I forgot to comment. Please see the estree spec on RegExpLiteral. We can't rely on raw being there unless we're codegen-ing the result of a parse. Instead, use the pattern and flags properties to construct a regexp literal.

@michaelficarra thanks for clearing. I'll update the PR

@michaelficarra please review again

@KnisterPeter This isn't going to work either, unfortunately. If we want to codegen a RegExp with flags that the engine running escodegen does not support, it will throw. I think you're going to have to actually build up a RegExp literal yourself.

@michaelficarra and one more update

Looks good otherwise. Please squash and I'll merge.

Done

@KnisterPeter Merged, thanks.


[$500] Android - LHN is displayed instead Expensify uses Plaid to connect your account

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: <IP_ADDRESS>
**Reproducible in staging?:**Y
**Reproducible in production?:**Y
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 account settings >> Workspace
Click on the workspace to view its settings
Click on Cards or Reimbursements settings
Select "Connect bank account" >> "Connect online with Plaid
Put app on background
Open app again

Expected Result:
Expensify uses Plaid to connect your account is displayed instead LHN after putting the app in the background
Actual Result:
LHN is displayed instead Expensify uses Plaid to connect your account after putting the app in the background
Workaround:
Unknown
Platforms:

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

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

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/78819774/90e415ba-7c42-46c1-807c-fa2be04005ed

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

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

Upwork Job URL: https://www.upwork.com/jobs/~01f99be3ed1dcad788
Upwork Job ID:<PHONE_NUMBER>807620096
Last Price Increase: 2023-10-30

s

Proposal
Please re-state the problem that we are trying to solve in this issue.
Android - LHN is displayed instead Expensify uses Plaid to connect your account
What is the root cause of that problem?
This is because iOS and Android handle activity lifecycles differently. For Android we need to reinitialize Plaid Link when the app comes back to the foreground
What changes do you think we should make in order to solve the problem?
I suggest to change this part of code

like below
    useEffect(() => {
        initializePlaidLink()

        return () => {
            dismissLink();
        };
        // We generally do not need to include the token as a dependency here as it is only provided once via props and should not change
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, []);

   const  initializePlaidLink = () => {
       props.onEvent(CONST.BANK_ACCOUNT.PLAID.EVENTS_NAME.OPEN, {});
       openLink({
           tokenConfig: {
               token: props.token,
           },
           onSuccess: ({publicToken, metadata}) => {
               props.onSuccess({publicToken, metadata});
           },
           onExit: (exitError, metadata) => {
               Log.info('[PlaidLink] Exit: ', false, {exitError, metadata});
               props.onExit();
           },
       });
    };

    AppState.addEventListener('change', (nextAppState)=>{
        if (!nextAppState.match(/inactive|background/)) {
            initializePlaidLink();
        }
    });

What alternative solutions did you explore? (Optional)
NO

@shahinyan11 Thanks for the proposal. Can you please elaborate on your RCA? How is the lifecycle different?
After reopening the App I'm seeing an error which seems pretty much related to this bug
 ERROR  Looks like you have configured linking in multiple places. This is likely an error since deep links should only be handled in one place to avoid conflicts. Make sure that:
- You don't have multiple NavigationContainers in the app each with 'linking' enabled
- Only a single instance of the root component is rendered
- You have set 'android:launchMode=singleTask' in the '<activity />' section of the 'AndroidManifest.xml' file to avoid launching multiple instances

@s77rt  Sorry but there was a problem in my proposal and it didn't work completely. I'm currently working on this to fix the problem and create new proposal.

Proposal
Please re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
This is because iOS and Android handle activity lifecycles differently. When the Plaid Link window opens, the Android application goes into background mode, and then when we further change the application state to background and go back, even the App and Expensify components are mounted again . And because of that the app navigates to initial route
What changes do you think we should make in order to solve the problem?
I suggest to add new lastRoute key in Onyx data and set it  in useEffect hook of PlaidLink component and remove it in function onExit . Below you can see modified useEffect hook where I added 2 new lines with comment // New code
  useEffect(() => {
        Onyx.set(ONYXKEYS.LAST_ROUTE, Navigation.getActiveRoute())

        props.onEvent(CONST.BANK_ACCOUNT.PLAID.EVENTS_NAME.OPEN, {});
        openLink({
            tokenConfig: {
                token: props.token,
            },
            onSuccess: ({publicToken, metadata}) => {
                props.onSuccess({publicToken, metadata});
            },
            onExit: (exitError, metadata) => {
                Onyx.set(ONYXKEYS.LAST_ROUTE, '') // New code
                Log.info('[PlaidLink] Exit: ', false, {exitError, metadata});
                props.onExit();
            },
        });

        return () => {
            dismissLink();
        };

        // We generally do not need to include the token as a dependency here as it is only provided once via
         props and should not change
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, []);

After that,  when the application becomes active ( actually re-renders App.js ) we need to check if "lastRout" exists in the "Onyx" data and go to that route after the navigation is ready.  For this I added Onyx.connect in Navigation.js file and the function openLastRoute  which called in setNavigationReady function .
let lastRoute;

Onyx.connect({
    key: ONYXKEYS.LAST_ROUTE,
    callback: (val) => {
        lastRoute = val
    },
});

...

function openLastRoute(){
    navigate(lastRoute)
}

https://github.com/Expensify/App/assets/46921547/e283064b-1e7e-4708-b764-46499765d5d5
What alternative solutions did you explore? (Optional)
We can discus about modifying Navigation.js to handling if existence of lastRoute  with another way

@shahinyan11 Thanks for the update. Regarding your RCA:

When the Plaid Link window opens, the Android application goes into background mode

Any specific reason why this happens on Android only? Is this coming from react-native-plaid-link-sdk?

Note: For future proposals please do not post new comments instead just edit the old one

@s77rt  Yes it is coming from react-native-plaid-link-sdk .  It's possible that this behavior can be changed using Java or Kotlin at the package level, but I'm not sure because I don't have enough knowledge with those.

@shahinyan11 If the bug is coming from react-native-plaid-link-sdk we should probably fix the bug upsteam.

@s77rt  But on the package side it's not a bug, it's just behavior for android.
I also noticed that Plaid has different integration methods, and there is a way with Webview, but I haven't explored it deeply.

@shahinyan11 If the bug is coming from react-native-plaid-link-sdk we should probably fix the bug upsteam.
And if so. what should I do next ?

@shahinyan11 If the bug is coming from react-native-plaid-link-sdk we should probably fix the bug upsteam.

and if so what should I do

@s77rt is not the handling on the react native side an option ?

It's an option as long as the fix is on react-native-plaid-link-sdk (assuming the bug is on react-native-plaid-link-sdk)

@s77rt Ok . I will continue to explore the react-native-plaid-link-sdk package until I get a response from you, maybe there will be another option

Sounds good, thanks @s77rt! ❤

@s77rt @dylanexpensify  I have looked for other ways, but it is not possible to change this behavior in Android. There is only one way which we can try. This is the way to use Webview but Plaid does not recommend using WebViews for new integrations for several reasons:
User Experience: The Plaid Link SDKs for Android, iOS, and React Native are designed to provide a seamless and native experience for users. They are optimized for mobile devices and provide a better user experience than a WebView.
Security: The SDKs are more secure than a WebView integration. They are regularly updated to include the latest security enhancements and to meet evolving industry standards.
Maintenance and Support: Plaid actively maintains and supports the SDKs, ensuring they are up-to-date with the latest features and improvements. On the other hand, support for WebView-based integrations is being phased out.
Future Compatibility: Starting from September 30, 2023, all WebView-based integrations will need to extend the WebView handler for redirects to support certain institutions. This adds an additional layer of complexity to your integration.
For these reasons, Plaid recommends using the native SDKs for new integrations instead of a WebView.

@shahinyan11 Thanks for your time but we are not looking for solutions yet. Let's try to have a deeper understanding of the root cause first. As far as I can tell we only assumed that the bug is on react-native-plaid-link-sdk. Did you find out what part of code causes the underlaying app to get into background mode?

@shahinyan11 any updates?

@shahinyan11 Thanks for your time but we are not looking for solutions yet. Let's try to have a deeper understanding of the root cause first. As far as I can tell we only assumed that the bug is on react-native-plaid-link-sdk. Did you find out what part of code causes the underlaying app to get into background mode?

It is wrong to call this a bug. This is not a bug at all, this is standard android OS behavior. we should to integrate with Webview or handle it on the application side ?

@s77rt , @dylanexpensify  To be honest, I don’t understand what you. Why do we call it a bug? This can be called a bug for the business logic of our application, but it is not a bug at the package level. The Android SDK behaves like this.

@shahinyan11 If the bug is upstream it should be fixed upstream. Applying a app-level solution to fix something in the plaid sdk is a workaround.
I'm not really totally sure how react-native-plaid-link-sdk invokes its activity causing the Expensify App to get into background mode. If this is something that is enforced by Android then we would probably have nothing to do here. Regardless we still need to confirm the root cause.

@s77rt The react-native-plaid-link-sdk works by invoking the Plaid Link flow, which is a
separate activity from our main application.
there isn't a way to keep our app's Activity in the foreground at the same time
as the Plaid Link window. This is due to how Android manages Activities.
In Android, only one Activity can be in the foreground at a time (i.e., interacting with
the user). When we start a new Activity (like the Plaid Link flow), it becomes the
foreground Activity and our current Activity goes into the background.
This is standard Android behavior and is not something that can be changed from
within the Plaid SDK or our app. The Android operating system manages the
transition between Activities to ensure a consistent user experience across all apps .
You can see the function where written the logic of starting new activity  here and the file where calls this function here

@shahinyan11 Thanks for the update. That was helpful! Since we cannot prevent the App from going into background mode. Can we figure out why having the app running in background after Plaid messes up the rest of the flow?

Open App (App in foregroung)
Launch Plaid (App in background)
Open App again
App is reinitialised

In step 4, what is causing the re-initialization?

@s77rt  This behavior could be due to how Android manages its activity lifecycle. When we leave the app, Android might be destroying the activity hosting our app to free up resources,  such as memory, for other apps that are in the foreground and actively being used by the user and when we click the app icon, a new activity is created, causing our app to restart. Android manages its resources very carefully to ensure smooth performance and a good user experience.
But I found a solution to stop this behavior . The solution is update this line to  android:launchMode="singleInstance" .
And after that, we need to open the Plaid link window again because it closes after going back.  For this I made below changes .

The onExit function to below

  onExit: ({metadata}) => {
      Log.info('[PlaidLink] Exit: ', false, {metadata});
      props.onExit(metadata.status);
  },

The onExitPlaid prop to below

onExitPlaid={(status) => {
    BankAccounts.setBankAccountSubStep(null)

    if(!status){
        BankAccounts.openPlaidView();
    }
}}

Proposal
Updated

@shahinyan11 Thanks for the update. Can you please explain why using singleInstance mode works over singleTask? Per the docs the singleTask mode won't create a duplicate instance of the root activity (App in this case).

The system creates the activity at the root of a new task or locates the activity on an existing task with the same affinity. If an instance of the activity already exists, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Meanwhile all of the other activities on top of it are destroyed.

@shahinyan11 Thanks for the update. Can you please explain why using singleInstance mode works over singleTask? Per the docs the singleTask mode won't create a duplicate instance of the root activity (App in this case).

The system creates the activity at the root of a new task or locates the activity on an existing task with the same affinity. If an instance of the activity already exists, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Meanwhile all of the other activities on top of it are destroyed.

SingleTask

If an activity instance already exists at the top of a task's stack (in the same task), the system will send an intent to that instance by calling its onNewIntent() method, instead of creating a new instance.
If the activity is not at the top of the task stack, a new instance will be created and pushed to the top of the stack. ( This case is our. The plaid link activity becomes top  activity and after it when we press app icon our main activity creates again )

SingleTask

When a new activity is started with singleInstance mode, if the activity already exists in another task, a new task will be created for that instance. This means that only one instance of an activity is allowed in the entire system, and it is isolated in its own task.
This mode is typically used for activities that need to be isolated from the rest of the application, such as a standalone application or a component that should not be part of the normal flow of activities.

@shahinyan11 Thanks for the update. Can you please explain why using singleInstance mode works over singleTask? Per the docs the singleTask mode won't create a duplicate instance of the root activity (App in this case).

The system creates the activity at the root of a new task or locates the activity on an existing task with the same affinity. If an instance of the activity already exists, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Meanwhile all of the other activities on top of it are destroyed.

SingleTask

If an activity instance already exists at the top of a task's stack (in the same task), the system will send an intent to that instance by calling its onNewIntent() method, instead of creating a new instance.
If the activity is not at the top of the task stack, a new instance will be created and pushed to the top of the stack. ( I think this is our case. The PlaidLink activity becomes at the top and after it, when we click on the application icon, our main activity is created again. )

SingleInstance

When a new activity is started with singleInstance mode, if the activity already exists in another task, a new task will be created for that instance. This means that only one instance of an activity is allowed in the entire system, and it is isolated in its own task.
This mode is typically used for activities that need to be isolated from the rest of the application, such as a standalone application or a component that should not be part of the normal flow of activities.

@shahinyan11 But plaid is not started in singleTask mode, is it? The default is standard

@shahinyan11 But plaid is not started in singleTask mode, is it? The default is standard

Yes

@shahinyan11 I don't see how is plaid launched with singleTask mode. No mode is specified so it should be launched with standard.

@shahinyan11 Although the use of singleInstance seems to fix the reinitialization issue I'm not sure if it is fixing the root cause.
I think we still need to better understand the root cause

A new release of react-native-plaid-link-sdk is available. It mentions a change in the activity.

Change LinkActivity to SingleInstance to fix issue with OAuth Redirects on Android 14.

https://github.com/plaid/react-native-plaid-link-sdk/releases/tag/v11.0.1
Perhaps this would fix our issue?

Interesting, @s77rt what would this entail?

Tested with v10.9.1 (which also includes the activity launch mode change) but didn't help

@bernhardoj Thanks for the confirmation. singleInstance is the only mode that looks promising so far but it may not be the right mode

I can confirm that this issue is caused by the singleTask of launchMode. Here is a video of the "issue" on a native Android project.
Screen.Recording.2023-11-14.at.19.41.42.mov
When we press the app icon from the app launcher, it will launch the activity that has this intent-filter
Because our app main activity has a launchMode set to singleTask, it will clear the plaid activity from the stack.
React native project set the launcMode to singleTask by default though (maybe because RN is designed as a single activity app), so I don't know which launchMode we should use.

@s77rt @bernhardoj Our problem is not that the plaid link window does not stay open after returning to the foreground. this behavior works absolutely correct. We need reinitialize plaid link after coming back .
Our main problem is that the application does not save the current state and does not stay on the last screen. It starts from scratch and goes to the main screen.

I agree that it may be best to keep the App launchMode untouched and fix this on Plaid SDK level especially that we know Onfido is doing it correctly.

@s77rt  After a lot of research I found the problem . Turns out the plaid link adds several different activities . And there is an activity with lunchMode="singleInstance" . I downloaded plaid link example from gitHub and check this. It works correct and I saw that there is not activity with lunchMode="singleInstance" .  After it  I tried to use the same package version in our app which was in example project  and it works .

Proposal
Updated

@shahinyan11 Thanks for the update. Upgrading to 10.8.0 seems to work fine. That should be enough to fix the reinitialization problem. I don't see the need to reopen plaid especially since it's going to be a hack and all the process you went through will be lost already. Also the final outcome so far is going to be similar to that of Onfido which is fine.
🎀 👀 🎀 C+ reviewed
Link to proposal

@robertjchen https://github.com/Expensify/App/issues/30617#issuecomment-1814904843

Reviewed! Agreed with the proposal 👍

I expect my review request to be ready for review by the end of today.

Nice! @s77rt to review!

Payment upcoming!

@dylanexpensify the marked day has passed, but I have not yet received payment ? Is there any problems ?

@dylanexpensify

Apologies! Processing now @shahinyan11!

Payment summary:

Contributor: @shahinyan11 $500
Contributor+: @s77rt $500

Please apply!

@shahinyan11 offer sent!

@dylanexpensify  applied

paid!

@dylanexpensify Are not you leaving reviews at all? )


python311Packages.pyzabbix: init at 1.3.1

Description of changes
Module to interact with the Zabbix API
https://github.com/lukecyca/pyzabbix

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 279669 run on aarch64-darwin 1

4 packages built:

python310Packages.pyzabbix
python310Packages.pyzabbix.dist
python311Packages.pyzabbix
python311Packages.pyzabbix.dist

Result of nixpkgs-review pr 279669 run on x86_64-linux 1

4 packages built:

python310Packages.pyzabbix
python310Packages.pyzabbix.dist
python311Packages.pyzabbix
python311Packages.pyzabbix.dist


Framegrabber stops when saving PCDs

Hi,
I tried saving some in my Qt+PCL+OpenCV application.. saving .png or .bmp with cv::imwrite works just fine, but when I try to use pcd::io::savePCDFileASCII() the framegrabber stops.
The function that saves the images is called by a Qt button and the most strange thing is that framegrabber stops even if the function is not called. Seems that only the "insertion" of pcd::io::savePCDFileASCII() causes the problem. My code is very similar to ex-file_io.cpp
Thanks

Without seeing your code, there is not much meaningful troubleshooting I can help you with. Posting your code, sending some relevant information from the log file (found in /tmp by default), and stating the version of libo3d3xx that you are using will be helpful.
Now, you are suggesting that the FrameGrabber thread stops as opposed to crashes. If it does in fact crash and it is triggered by using PCL, please read Issue #7 and see if it applies. If the FrameGrabber just stops as you state, the one thing I would ask you to do is check how you are managing ownership of the FrameGrabber within your Qt event loop. If you gain access to the FrameGrabber using the recommended
o3d3xx::FrameGrabber::Ptr fg = std::make_shared<o3d3xx::FrameGraber>(...)

Recall that fg is a std::shared_ptr to an o3d3xx::FrameGrabber pointer. So, if somewhere in your event loop, the reference count to fg drops to 0, the smart pointer will call the fg dtor and, yes, by design, the frame grabbing thread will stop.
Again, w/o seeing the code, I am only guessing at what could be going on. Good luck.

Initialization
...
...
// instantiate the camera with default ip, xmlrpc port, and password
	o3d3xx::Camera::Ptr cam;

	// associate the camera with a frame grabber
	o3d3xx::FrameGrabber::Ptr fg;

	// create an buffer for holding the image data from the camera
	o3d3xx::ImageBuffer::Ptr buff;

...
...

bool RoboVis_VISION::cam_Setup() {
	try {
		cam = std::make_shared<o3d3xx::Camera>(m->camIp.toStdString());
		fg = std::make_shared<o3d3xx::FrameGrabber>(cam);
		buff = std::make_shared<o3d3xx::ImageBuffer>();
		return true;
	} catch (const o3d3xx::error_t& e) {
		printf("%s\n",e.what());
		return false;
	}
}

Image Capture
cv::Mat RoboVis_VISION::capture(bool *valid) {
	cv::Mat temp;
	uchar i = 0;
	emit wait();

#ifndef TEST  //trigger camera
	while (m->gpio.digitalRead(0) == false){
		usleep(500);
	}
	m->gpio.digitalWrite(0,true);
#else
	fg->SWTrigger();
#endif

	while (true) {
		if (!fg->WaitForFrame(buff.get(),1500,true)) {
			if (i++ < MAX_ATTEMPT)
				continue;
			else {
				error(CAMERA_ERROR);
				*valid = false;
				fg ->Stop();
				cam->CancelSession();
				is_live = false;
				sleep(0.1);
				this->cam_Setup();
				return old_img;
			}
		} else
			break;
	}

#ifndef TEST
	m->gpio.digitalWrite(0,false);
#endif

	//Capture New Image
	temp = buff->XYZImage();
	m->cloud = buff->Cloud();
	temp.copyTo(old_img);
	*valid = true;
	return temp;
}

Image Save
void RoboVis_GUI::on_btnSaveImage(){
	QDateTime t= QDateTime::currentDateTime();
	QString tt=t.toString("yyyyMMdd-hh:mm:ss");
	QString bmp = tt.append(".bmp");
	QString pcd = tt.append(".pcd");

	if (m->mutex.tryLock(100)){
		cv::imwrite(cv::String(std::string(BASE_DIR) + std::string(IMG_SAVE) + bmp.toStdString()), m->vis_image);
		pcl::io::savePCDFileASCII(std::string(BASE_DIR) + std::string(IMG_SAVE) + pcd.toStdString(), *(m->cloud));
	}
	MYLOG(QString("SAVE -> ") + tt);
}

m is an istance of a class that contains:
pcl::PointCloud<pcl::PointXYZI>::Ptr cloud;
cv::Mat vis_image;

Hope this is useful :)

Can you paste in the output of the log file just after the issue you are describing occurs? By default it is written to /tmp/libo3d3xx.INFO. Also, which version of libo3d3xx are you using? You can get that by running  o3d3xx-version.

version=0.4.5
in /tmp/libo3d3xx.INFO
Running on machine: RoboVis-PC
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0929 16:13:20.319000  6521 frame_grabber.cpp:70] Camera connection info: ip=<IP_ADDRESS>, port=50010
I0929 16:13:21.253365  6521 frame_grabber.cpp:91] Assumed trigger mode: 2
I0929 16:13:21.290552  6525 frame_grabber.cpp:458] Framegrabber thread done.

And now the output from: o3d3xx-dump.

{
    "o3d3xx":
    {
        "libo3d3xx": "405",
        "Date": "Thu Sep 29 16:17:43 2016",
        "HWInfo":
        {
            "Mainboard": "#!02_M381_003_02178445_008022954",
            "Illumination": "#!02_I300_001_02161610_008001175",
            "MiraSerial": "0030-53b9-0022-03bc",
            "MACAddress": "00:02:01:40:30:49",
            "Frontend": "#!02_F342_C32_16_00005_008022797",
            "Diagnose": "#!02_D322_C30_02165464_008023093",
            "Connector": "#!02_A300_001_02064651_008001175"
        },
        "SWVersion":
        {
            "IFM_Software": "1.4.1639",
            "Linux": "Linux version 3.11.0-00001-gda3d004 (eswadmin@dettlx79) (gcc version 4.7.2 (GCC) ) #1 SMP Wed Feb 17 15:55:11 CET 2016",
            "Diagnostic_Controller": "0.3.150",
            "ELDK": "GOLDENEYE_ELDK-2016-03-17_16-21-02-8baf2bee4a4eebca0d2ad7c7345d3a4f971032ec",
            "Calibration_Version": "0.9.160314",
            "Calibration_Device": "00:02:01:40:30:49",
            "Main_Application": "0.4.164",
            "Algorithm_Version": "1.2.14"
        },
        "Device":
        {
            "Name": "RoboVis_SENSOR",
            "Description": "",
            "ActiveApplication": "2",
            "PcicEipEnabled": "false",
            "PcicTcpPort": "50010",
            "PcicProtocolVersion": "3",
            "IOLogicType": "1",
            "IODebouncing": "true",
            "IOExternApplicationSwitch": "0",
            "SessionTimeout": "30",
            "ServiceReportPassedBuffer": "15",
            "ServiceReportFailedBuffer": "15",
            "ExtrinsicCalibTransX": "0",
            "ExtrinsicCalibTransY": "0",
            "ExtrinsicCalibTransZ": "0",
            "ExtrinsicCalibRotX": "0",
            "ExtrinsicCalibRotY": "0",
            "ExtrinsicCalibRotZ": "0",
            "EvaluationFinishedMinHoldTime": "10",
            "SaveRestoreStatsOnApplSwitch": "true",
            "IPAddressConfig": "0",
            "PasswordActivated": "false",
            "OperatingMode": "0",
            "DeviceType": "",
            "ArticleNumber": "",
            "ArticleStatus": "",
            "UpTime": "9.140475314724065e-317",
            "ImageTimestampReference": "18500768",
            "TemperatureFront1": "6.952798554347323e-310",
            "TemperatureFront2": "9.140712466234069e-317",
            "TemperatureIMX6": "9.140831041989071e-317",
            "TemperatureIllu": "6.952764967629592e-310"
        },
        "Net":
        {
            "MACAddress": "",
            "NetworkSpeed": "0",
            "StaticIPv4Address": "<IP_ADDRESS>",
            "StaticIPv4SubNetMask": "<IP_ADDRESS>",
            "StaticIPv4Gateway": "<IP_ADDRESS>",
            "UseDHCP": "false"
        },
        "Apps":
        [
            {
                "Name": "SampleApp",
                "Description": "No Description",
                "TriggerMode": "1",
                "PcicTcpResultSchema": "{ \"layouter\": \"flexible\", \"format\": { \"dataencoding\": \"ascii\" }, \"elements\": [ { \"type\": \"string\", \"value\": \"star\", \"id\": \"start_string\" }, { \"type\": \"blob\", \"id\": \"normalized_amplitude_image\" }, { \"type\": \"blob\", \"id\": \"distance_image\" }, { \"type\": \"blob\", \"id\": \"x_image\" }, { \"type\": \"blob\", \"id\": \"y_image\" }, { \"type\": \"blob\", \"id\": \"z_image\" }, { \"type\": \"blob\", \"id\": \"confidence_image\" }, { \"type\": \"blob\", \"id\": \"diagnostic_data\" }, { \"type\": \"string\", \"value\": \"stop\", \"id\": \"end_string\" } ] }",
                "PcicEipResultSchema": "{ \"layouter\": \"flexible\", \"format\": { \"dataencoding\": \"binary\", \"order\": \"big\" }, \"elements\" : [ { \"type\": \"string\", \"value\": \"star\", \"id\": \"start_string\" }, { \"type\": \"records\", \"id\": \"models\", \"elements\": [ { \"type\": \"int16\", \"id\": \"boxFound\" }, { \"type\": \"int16\", \"id\": \"width\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"height\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"length\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"xMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"yMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"zMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"yawAngle\" }, { \"type\": \"int16\", \"id\": \"qualityLength\" }, { \"type\": \"int16\", \"id\": \"qualityWidth\" }, { \"type\": \"int16\", \"id\": \"qualityHeight\" } ] }, { \"type\": \"string\", \"value\": \"stop\", \"id\": \"end_string\" } ] }",
                "LogicGraph": "{\"IOMap\": {\"OUT1\": \"RFT\",\"OUT2\": \"AQUFIN\"},\"blocks\": {\"B00001\": {\"pos\": {\"x\": 200,\"y\": 200},\"properties\": {},\"type\": \"PIN_EVENT_IMAGE_ACQUISITION_FINISHED\"},\"B00002\": {\"pos\": {\"x\": 200,\"y\": 75},\"properties\": {},\"type\": \"PIN_EVENT_READY_FOR_TRIGGER\"},\"B00003\": {\"pos\": {\"x\": 600,\"y\": 75},\"properties\": {\"pulse_duration\": 0},\"type\": \"DIGITAL_OUT1\"},\"B00005\": {\"pos\": {\"x\": 600,\"y\": 200},\"properties\": {\"pulse_duration\": 0},\"type\": \"DIGITAL_OUT2\"}},\"connectors\": {\"C00000\": {\"dst\": \"B00003\",\"dstEP\": 0,\"src\": \"B00002\",\"srcEP\": 0},\"C00001\": {\"dst\": \"B00005\",\"dstEP\": 0,\"src\": \"B00001\",\"srcEP\": 0}}}",
                "Type": "Camera",
                "Index": "1",
                "Id": "1182112391",
                "Imager":
                {
                    "Channel": "0",
                    "ClippingBottom": "131",
                    "ClippingLeft": "0",
                    "ClippingRight": "175",
                    "ClippingTop": "0",
                    "ContinuousAutoExposure": "false",
                    "EnableAmplitudeCorrection": "true",
                    "EnableFastFrequency": "false",
                    "EnableFilterAmplitudeImage": "true",
                    "EnableFilterDistanceImage": "true",
                    "EnableRectificationAmplitudeImage": "false",
                    "EnableRectificationDistanceImage": "false",
                    "ExposureTime": "60",
                    "ExposureTimeList": "60",
                    "FrameRate": "5",
                    "MinimumAmplitude": "42",
                    "Resolution": "0",
                    "ClippingCuboid": "{\"XMin\": -3.402823e+38, \"XMax\": 3.402823e+38, \"YMin\": -3.402823e+38, \"YMax\": 3.402823e+38, \"ZMin\": -3.402823e+38, \"ZMax\": 3.402823e+38}",
                    "SpatialFilterType": "0",
                    "SymmetryThreshold": "0",
                    "TemporalFilterType": "0",
                    "ThreeFreqMax2FLineDistPercentage": "80",
                    "ThreeFreqMax3FLineDistPercentage": "80",
                    "TwoFreqMaxLineDistPercentage": "80",
                    "Type": "under5m_low",
                    "MaxAllowedLEDFrameRate": "403.2",
                    "SpatialFilter":
                    {
                        "Type": "0",
                        "TypeStr_": "Off"
                    },
                    "TemporalFilter":
                    {
                        "Type": "0",
                        "TypeStr_": "Off"
                    }
                }
            },
            {
                "Name": "SW_Trigger_100K",
                "Description": "No Description",
                "TriggerMode": "2",
                "PcicTcpResultSchema": "{ \"layouter\": \"flexible\", \"format\": { \"dataencoding\": \"ascii\" }, \"elements\": [ { \"type\": \"string\", \"value\": \"star\", \"id\": \"start_string\" }, { \"type\": \"blob\", \"id\": \"normalized_amplitude_image\" }, { \"type\": \"blob\", \"id\": \"distance_image\" }, { \"type\": \"blob\", \"id\": \"x_image\" }, { \"type\": \"blob\", \"id\": \"y_image\" }, { \"type\": \"blob\", \"id\": \"z_image\" }, { \"type\": \"blob\", \"id\": \"confidence_image\" }, { \"type\": \"blob\", \"id\": \"diagnostic_data\" }, { \"type\": \"string\", \"value\": \"stop\", \"id\": \"end_string\" } ] }",
                "PcicEipResultSchema": "{ \"layouter\": \"flexible\", \"format\": { \"dataencoding\": \"binary\", \"order\": \"big\" }, \"elements\" : [ { \"type\": \"string\", \"value\": \"star\", \"id\": \"start_string\" }, { \"type\": \"records\", \"id\": \"models\", \"elements\": [ { \"type\": \"int16\", \"id\": \"boxFound\" }, { \"type\": \"int16\", \"id\": \"width\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"height\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"length\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"xMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"yMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"zMidTop\", \"format\": { \"scale\": 1000 } }, { \"type\": \"int16\", \"id\": \"yawAngle\" }, { \"type\": \"int16\", \"id\": \"qualityLength\" }, { \"type\": \"int16\", \"id\": \"qualityWidth\" }, { \"type\": \"int16\", \"id\": \"qualityHeight\" } ] }, { \"type\": \"string\", \"value\": \"stop\", \"id\": \"end_string\" } ] }",
                "LogicGraph": "{\"IOMap\": {\"OUT1\": \"RFT\",\"OUT2\": \"AQUFIN\"},\"blocks\": {\"B00001\": {\"pos\": {\"x\": 200,\"y\": 200},\"properties\": {},\"type\": \"PIN_EVENT_IMAGE_ACQUISITION_FINISHED\"},\"B00002\": {\"pos\": {\"x\": 200,\"y\": 75},\"properties\": {},\"type\": \"PIN_EVENT_READY_FOR_TRIGGER\"},\"B00003\": {\"pos\": {\"x\": 600,\"y\": 75},\"properties\": {\"pulse_duration\": 0},\"type\": \"DIGITAL_OUT1\"},\"B00005\": {\"pos\": {\"x\": 600,\"y\": 200},\"properties\": {\"pulse_duration\": 0},\"type\": \"DIGITAL_OUT2\"}},\"connectors\": {\"C00000\": {\"dst\": \"B00003\",\"dstEP\": 0,\"src\": \"B00002\",\"srcEP\": 0},\"C00001\": {\"dst\": \"B00005\",\"dstEP\": 0,\"src\": \"B00001\",\"srcEP\": 0}}}",
                "Type": "Camera",
                "Index": "2",
                "Id": "1182112392",
                "Imager":
                {
                    "Channel": "0",
                    "ClippingBottom": "263",
                    "ClippingLeft": "0",
                    "ClippingRight": "351",
                    "ClippingTop": "0",
                    "ContinuousAutoExposure": "false",
                    "EnableAmplitudeCorrection": "true",
                    "EnableFastFrequency": "false",
                    "EnableFilterAmplitudeImage": "false",
                    "EnableFilterDistanceImage": "true",
                    "EnableRectificationAmplitudeImage": "false",
                    "EnableRectificationDistanceImage": "false",
                    "ExposureTimeList": "50;500;5000",
                    "FrameRate": "5",
                    "MinimumAmplitude": "42",
                    "Resolution": "1",
                    "ClippingCuboid": "{\"XMin\": -3.402823e+38, \"XMax\": 3.402823e+38, \"YMin\": -3.402823e+38, \"YMax\": 3.402823e+38, \"ZMin\": -3.402823e+38, \"ZMax\": 3.402823e+38}",
                    "SpatialFilterType": "0",
                    "SymmetryThreshold": "0",
                    "TemporalFilterType": "1",
                    "ThreeFreqMax2FLineDistPercentage": "80",
                    "ThreeFreqMax3FLineDistPercentage": "80",
                    "TwoFreqMaxLineDistPercentage": "80",
                    "Type": "under5m_high",
                    "MaxAllowedLEDFrameRate": "21.5",
                    "SpatialFilter":
                    {
                        "Type": "0",
                        "TypeStr_": "Off"
                    },
                    "TemporalFilter":
                    {
                        "Type": "1",
                        "TypeStr_": "Temporal Mean Filter",
                        "NumberOfImages": "4"
                    }
                }
            }
        ]
    }
}

Hmmm.... I've configured my camera to look like yours (most notably w/ the 100k pixel imager, single frequency, triple exposure, 4-image mean filter, software triggered, etc.). I do not run into any problems. NOTE: I am using libo3d3xx 0.4.8 linked to PCL 1.7. I modified the ex-file_io example to run in a loop and software trigger the camera for image aquisition. That looks like this:
#include <iostream>
#include <memory>
#include <opencv2/opencv.hpp>
#include <pcl/io/pcd_io.h>
#include <pcl/point_cloud.h>
#include "o3d3xx_camera.h"
#include "o3d3xx_framegrabber.h"
#include "o3d3xx_image.h"

int main(int argc, const char **argv)
{
  o3d3xx::Logging::Init();

  o3d3xx::Camera::Ptr cam = std::make_shared<o3d3xx::Camera>();
  o3d3xx::ImageBuffer::Ptr img = std::make_shared<o3d3xx::ImageBuffer>();
  o3d3xx::FrameGrabber::Ptr fg =
    std::make_shared<o3d3xx::FrameGrabber>(
      cam, o3d3xx::IMG_AMP|o3d3xx::IMG_RDIS|o3d3xx::IMG_CART);

  for (int i = 0; i < 20; i++)
    {
      std::cout << i << std::endl;
      fg->SWTrigger();
      if (! fg->WaitForFrame(img.get(), 1500))
        {
          std::cerr << "Timeout waiting for camera!" << std::endl;
          return -1;
        }

      std::string i_s(std::to_string(i));
      pcl::io::savePCDFileASCII(
        "/tmp/point_cloud_" + i_s + ".pcd", *(img->Cloud()));

      imwrite("/tmp/amplitude_" + i_s + ".png", img->AmplitudeImage());
    }

  return 0;
}

With this code, I am not having any problems. Could you run this program and see what you get -- hopefully a bunch of files in your /tmp directory :-)

Ehm.. I'm not able to get your code running... I'm not a mekefile guru and g++ does not resolve the includes.. How should I compile it? Thanks :)

Easiest would be to edit the file in the examples module directory to look like what I have above (or similar) then just compile it using the provided CMakeLists.txt. For example:
$ cd modules/examples
$ .... EDIT THE FILE AS APPROPRIATE ...
$ mkdir build
$ cd build
$ cmake ..
$ make

The binary will be dropped into your current working directory.

ok, your code is working fine.. mine not, same problem..
The log output changed:
I0929 18:20:55.602010  4343 frame_grabber.cpp:70] Camera connection info: ip=<IP_ADDRESS>, port=50010
I0929 18:20:56.706789  4343 frame_grabber.cpp:91] Assumed trigger mode: 2
I0929 18:20:56.747426  4344 frame_grabber.cpp:458] Framegrabber thread done.
W0929 18:21:08.513485  4343 frame_grabber.cpp:171] pcic_ready_ flag not set!

OK. The last line indicates that your code is trying to do a software trigger prior to the PCIC schema being set on the camera -- odd that it is not set as SWTrigger() tries for two seconds before giving up and emitting that error. This tells me the usage pattern is a little different. No big deal, it should still work, once  I get a better mental model of how your code is structured.
A few thoughts/questions:

Could you update to the latest version of libo3d3xx? Now since you want to use the 100K pixel imager this could be tricky, I understand. You may want to install two parallel copies of libo3d3xx on your computer. For example, the version you are using, 0.4.5, could be installed in /opt/libo3d3xx-0.4.5 and you can use this install for the command line tools (i.e., so it can speak the proper dialect of XML-RPC for the firmware you are running). Then, use 0.4.8 for your runtime code -- the FrameGrabber code in this version is more robust to seeing errors in the data stream back from the camera.

Looks like you are using this in a multi-threaded environment. You should take care to handle all synchronization yourself. The core objects are not thread safe.

Related to the previous point, in your cam_Setup(), I'd suggest using the .reset(..) call on the shared_ptr rather than using the assignment operator -- particularly on the FrameGrabber. Again, be sure to grab a mutex or some other synchronization tool before resetting the objects.

For troubleshooting purposes, I would be interested to see if you set your camera into FREE_RUN mode and also removed the call to SWTrigger() from your code, to see if that would work. I understand you likely have a good reason for wanting to software trigger the camera (thermal management, etc.) but again, just for troubleshooting purposes, I'd be curious to see what happens.

My gut tells me, we need to think about how you are managing the FrameGrabber across threads, but, the specific root of the problem is not yet clear to me. Let me know if you try any/some/all of the above -- and your results.

OK. Tried points 3 & 4 also using a mutex as synchronization tool with no success.
My code has 3 threads (QThread) and a class common to all the 3 threads for sharing data between them. Framegrabber is a private variable in only one of the threads and is not accessed by any of the others.
I'll try to upgrade sensor firmware and libo3d3xx version.
Sorry if I'm a bit confusing but my english is not the best..

Sorry if I'm a bit confusing but my english is not the best..
Your English is fine, not confusing.

OK, just be aware that the latest firmware will not allow you to set the camera into 100k pixel mode. This is why I suggested my confusing point 1 above. Doing that will let you keep the firmware you have on the camera and use a version of libo3d3xx that can speak that dialect of XML-RPC for configuration purposes. Then, use the updated version of libo3d3xx for your runtime code and to get the benefit of the better FrameGrabber. I'm not saying this is the solution to our problem here, but, there were some recent changes to the FrameGrabber that make it more robust.

@Obbart Did you get this resolved?

Not yet, I had many other projects to attend to this month and we needed this software to start a plant.
However I spoke with an Ifm tecnician and he said me that the factory default 100k imager will be ready soon. I will try your solution as soon as possible.


Verify GPU AcceleratorProfile is created after restarting Dashboard

Add to gpu_deploy.sh script two verification steps after restarting rhods-dashboard deployment.

First wait for all relevant pods to be running.
Then delete configmap.
Then rollout restart rhods-dashboard deployment.
Then wait for rollout status and replicas to be successful.
At last verify that an AcceleratorProfiles resource is created.

Notice that the wait for pods running happens before the deployment is restarted.
That is why an additional wait for rollout is necessary to be called after restarting the deployment.

This has been tested on smoke test 4285.
Console output:
22:14:21  Deploying Nvidia GPU Operator
[Pipeline] sh
22:14:22  + /home/jenkins/workspace/rhods/rhods-smoke/ods-ci/ods_ci/tasks/Resources/Provisioning/GPU/gpu_deploy.sh
22:14:27  namespace/nvidia-gpu-operator unchanged
22:14:27  operatorgroup.operators.coreos.com/nvidia-gpu-operator-group unchanged
22:14:27  subscription.operators.coreos.com/gpu-operator-certified unchanged
22:14:27  subscription.operators.coreos.com/nfd unchanged
22:14:27  Waiting until GPU pods of 'gpu-operator' in namespace 'nvidia-gpu-operator' are in running state...
22:14:28  pod/gpu-operator-6559b97ffb-v5lnt condition met
22:14:30  nodefeaturediscovery.nfd.openshift.io/nfd-instance configured
22:14:34  clusterpolicy.nvidia.com/gpu-cluster-policy unchanged
22:14:34  Waiting until GPU pods of 'nvidia-device-plugin-daemonset' in namespace 'nvidia-gpu-operator' are in running state...
22:14:35  pod/nvidia-device-plugin-daemonset-kdbl9 condition met
22:14:35  pod/nvidia-device-plugin-daemonset-zgj2t condition met
22:14:35  Waiting until GPU pods of 'nvidia-container-toolkit-daemonset' in namespace 'nvidia-gpu-operator' are in running state...
22:14:36  pod/nvidia-container-toolkit-daemonset-btkjh condition met
22:14:36  pod/nvidia-container-toolkit-daemonset-qtq6c condition met
22:14:36  Waiting until GPU pods of 'nvidia-dcgm-exporter' in namespace 'nvidia-gpu-operator' are in running state...
22:14:37  pod/nvidia-dcgm-exporter-q2snc condition met
22:14:37  pod/nvidia-dcgm-exporter-r8rfc condition met
22:14:37  Waiting until GPU pods of 'gpu-feature-discovery' in namespace 'nvidia-gpu-operator' are in running state...
22:14:38  pod/gpu-feature-discovery-b8xdc condition met
22:14:38  pod/gpu-feature-discovery-hwjx5 condition met
22:14:38  Waiting until GPU pods of 'nvidia-operator-validator' in namespace 'nvidia-gpu-operator' are in running state...
22:14:39  pod/nvidia-operator-validator-r4mm8 condition met
22:14:39  pod/nvidia-operator-validator-vwl76 condition met
22:14:39  Deleting configmap migration-gpu-status
22:14:40  configmap "migration-gpu-status" deleted
22:14:40  Rollout restart rhods-dashboard deployment
22:14:41  deployment.apps/rhods-dashboard restarted
22:14:41  Waiting for up to 3 minutes until rhods-dashboard deployment is rolled out
22:14:41  Waiting for deployment "rhods-dashboard" rollout to finish: 3 out of 5 new replicas have been updated...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 3 out of 5 new replicas have been updated...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 3 out of 5 new replicas have been updated...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 4 out of 5 new replicas have been updated...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 4 out of 5 new replicas have been updated...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 2 old replicas are pending termination...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 2 old replicas are pending termination...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 2 old replicas are pending termination...
22:15:49  Waiting for deployment "rhods-dashboard" rollout to finish: 1 old replicas are pending termination...
22:16:15  Waiting for deployment "rhods-dashboard" rollout to finish: 1 old replicas are pending termination...
22:16:15  Waiting for deployment "rhods-dashboard" rollout to finish: 1 old replicas are pending termination...
22:16:15  Waiting for deployment "rhods-dashboard" rollout to finish: 4 of 5 updated replicas are available...
22:16:42  deployment "rhods-dashboard" successfully rolled out
22:16:42  Verifying that an AcceleratorProfiles resource was created in redhat-ods-applications
22:16:43  Name:         migrated-gpu
22:16:43  Namespace:    redhat-ods-applications
22:16:43  Labels:       <none>
22:16:43  Annotations:  <none>
22:16:43  API Version:  dashboard.opendatahub.io/v1
22:16:43  Kind:         AcceleratorProfile
22:16:43  Metadata:
22:16:43    Creation Timestamp:  2024-01-09T15:46:11Z
22:16:43    Generation:          1
22:16:43    Managed Fields:
22:16:43      API Version:  dashboard.opendatahub.io/v1
22:16:43      Fields Type:  FieldsV1
22:16:43      fieldsV1:
22:16:43        f:spec:
22:16:43          .:
22:16:43          f:displayName:
22:16:43          f:enabled:
22:16:43          f:identifier:
22:16:43          f:tolerations:
22:16:43      Manager:         unknown
22:16:43      Operation:       Update
22:16:43      Time:            2024-01-09T15:46:11Z
22:16:43    Resource Version:  2416221
22:16:43    UID:               ce19e4c7-97eb-46b6-b2f4-cc719e0d8e1b
22:16:43  Spec:
22:16:43    Display Name:  NVIDIA GPU
22:16:43    Enabled:       true
22:16:43    Identifier:    nvidia.com/gpu
22:16:43    Tolerations:
22:16:43      Effect:    NoSchedule
22:16:43      Key:       nvidia.com/gpu
22:16:43      Operator:  Exists
22:16:43  Events:        <none>

I approve this since this PR doesn't break anything and doesn't add extra additional time. It might be useful for debugging.

Note: bunch of those shellcheck warnings could be easily fixed.

Note: bunch of those shellcheck warnings could be easily fixed.

@jstourac oh, I missed your suggestion, since the spell check warnings did not break the Quality Gate...
Maybe we should enforce it in the gating.


Create a new Next.js page called login

Background
We want to create a new Login page within the Igbo API website to grant developer access to their developer dashboard.
Ideal Solution
Create a new Next.js boilerplate page called login. This page should be blank, but the route https://igboapi.com/login should navigate to this blank page.

Sure.
I can take on this.

is the page to contain placeholder content for now?

yeah, i can add more details in this ticket - if you want to pick this up @kingdanie lmk~

Yes please,

Screenshot of a draft I made:


Monitor mainapp load in CI system

@AndreasAntener FYI

The current load issue is related to after the sensors app starts. But its not the sensors app, because if you stop it it continues at high load.

Potentially related to what #4638 fixed.

Will be fixed with #4657.

Once we have better auto mission testing in place I'll add profiling.

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)


PlayFab not supported as a Phaser 3 plugin

I'm having trouble following this doc as PlayFab doesn't seem to be supported as a Phaser plugin anymore.
As a result, the below line is no longer working
game.PlayFab = game.plugins.add(Phaser.Plugin.PlayFab);
Instead of using the API like this game.PlayFab.ClientApi.LoginWithCustomID, it should be PlayFabClientSDK.LoginWithCustomID following this doc.

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

ID: 82fcb8b9-f11d-792b-6a7a-2d1428e1d05f
Version Independent ID: 108172a6-78c8-238e-fe00-4bc1341f6adf
Content: Setting up PlayFab authentication in Phaser.io - PlayFab
Content Source: playfab-docs/features/authentication/platform-specific-authentication/phaser-io.md
Product: playfab
GitHub Login: @joannaleecy
Microsoft Alias: joanlee

Correct, those were some old docs. Apologies for the confusion and delay in responding. The obsolete Phaser.io docs are being removed as we no longer officially support it.


SLM as user doesn't work out of the box

Out of the box, SLM as user on http://<IP_ADDRESS>:8000/ doesn't work due to missing slm_map.

Added to SLM/slm/settings/urls.py:
urlpatterns = [
path('admin/', admin.site.urls),
path('accounts/', include('allauth.urls')),
path('ckeditor/', include('ckeditor_uploader.urls')),
path('', include('slm.urls')),
path('',include('slm.map.urls'))
]
No more complains. Can log in. However, missing ../static/urls.js so no show.

Made a copy of https://slm.igs.org/static/urls.js in local setup: ../slm/static/urls.js
Created a mapbox account and token. Add token to the database using admin interface::MapSetting.
Seems working.

On user interface: Added a site. Uploaded an ASCII site log. Published it. Could view it. No site information in database.
On admin interface: Added a site, uploaded an ASCII site log. No errors. Can view uploaded file on user interface. Still no site information in database.

Unable to add site information from any site's form.


Add type conversion builtins

I want to do the following
expr.Eval("value + 2", map[string]interface{"value": "1"})

But value is a string. Casting func?
expr.Eval("int(value) + 2", map[string]interface{"value": "1"})

Add helper.

It would be nice to have build in support.

I was thinking about it too. But still can’t find good solution what will simple enough to explain to not programmer users of expr.

could it be optional? E.g expr.TypeConvertors()
In Golang, I think there are only so many conversions you can do. One challenge is if the casting was not sensible due to loss of accuracy (e.g. to float64) or just invalid (the string "foo" to int)

Yes, we need to find reasonable behaviour in case of loss of accuracy , or other errors.

var castErr error // stash any casting error here
	replaceMap["int"] = func(s string) int {
		v, err := strconv.Atoi(s)
		if err != nil {
			castErr = fmt.Errorf("failed to cast %q to int: %w", s, err)
		}
		return v
	}
	replaceMap["array"] = func(s string) []interface{} {
		array := make([]interface{}, 0)
		if err := json.Unmarshal([]byte(s), &array); err != nil {
			castErr = fmt.Errorf("failed to cast %q to array: %w", s, err)
		}
		return array
	}

	result, err := expr.Eval(expression, bellows.Expand(replaceMap))
	if err == nil {
		err = castErr
	}
	if err != nil {
		return nil, fmt.Errorf("failed to evaluate expression %q: %w", expression, err)
	}

Array cast looks more like Json.parse.

One solution to this might be for users to add the Sprig functions. They have a big library and it seems to work nicely:
http://masterminds.github.io/sprig/conversion.html
There are security issues with Sprig methinks, need to understand what sub-set of commands are safe.

I think adding some basic casting based on https://github.com/spf13/cast would be useful.
toFloat, toString, ...

Looking forward to this enhancement. It would be a massive life-saving feature by avoiding putting custom patch functions in every time into map.
I was thinking about this, maybe you can introduce a new Node type: ConversionNode with a new OpCode: OpConversion. (IDK there is already a OpCast opcode, it seems to do something for the config.Expect stuff) - don't know much about the internals, just using the keywords as a placeholder.

But still can’t find good solution what will simple enough - @antonmedv

What about:

float64(Foo.Bar)
int("Baz.Qux")
string(Quux)

If conversion fails, the Compile() func should return an error.

Added int() and float().