Added selectedDetent and fixed a List bug where the BottomSheetView would be permanently hidden

Hi @wojtek717!
I was searching for a lightweight solution like your's yesterday. This is great, thank you for creating this package!
I started to experiment with your package in my app and caught a couple of issues.
Permanently hidden BottomSheetView
I noticed that the BottomSheetView would sometimes get into a state where it was permanently hidden.
Before this PR:
https://github.com/user-attachments/assets/03151a6d-b8a1-4fa5-b177-91aa85cc96fb
After this PR:
https://github.com/user-attachments/assets/164e3115-131b-4643-a929-fe48545de867
Selected Detent
Added the concept of a selectedDetent. This persists the bottom sheet's detent state when switching tabs. Also added support for selecting the initial detent of the bottom sheet, which defaults to the smallest detent.
Before this PR:
https://github.com/user-attachments/assets/cf71ee43-968c-406b-b0fc-263dd2d46564
After this PR:
https://github.com/user-attachments/assets/041fafe5-2a4e-4848-9f4e-655af4244ad6
Miscellaneous changes
I made BottomSheetViewConfiguration conform to @Observable and made it @State in BottomSheetView / BottomSheet. You previously had it as a var that would be updated by view modifiers. The only reason those changes would work is because the sheetHeight was being called frequently enabling the SwiftUI engine to check BottomSheetViewConfiguration's new state.
I noticed you were adding ViewBuilder closures as instance properties, such as @ViewBuilder private let content: () -> Content, and that you were using @escaping in the initializer. This is considered bad practice, there can be unintended side effects. To learn more about this, I recommend reading this article! You can see the changes I made in BottomSheet that fix this.
Lastly, I did some general quality of life fixes like exposing cornerRadius for the sheet, naming improvements, and removed some forced view modifiers, such as the forced bottom safe area being ignored.
I may open a second PR with some other optional suggestions, but I wanted to keep my changes limited to what I saw as essential for the package.

Moved this PR to draft state - there are a couple of regressions introduced

I am noticing some bad drag behavior as a result of my sheetHeight changes. My assumption is the onScrollGeometryChange's action is the source of this issue.
I added max to ensure the bottom sheet wouldn't be permanently hidden:
if newValue < 0.0 {
    sheetHeight = max(
        minHeight(for: screenHeight),
        sheetHeight + newValue
    )
}

But I think the drag gesture is swapping between minHeight and sheetHeight + newValue causing this bad behavior:
https://github.com/user-attachments/assets/a5f0ca89-da78-4fce-a92d-80d9256c256c

Fixed the "jumpy" behavior noted in the last comment in the latest commit, d5698a9. This clamps and smooths the drag gestures.
https://github.com/user-attachments/assets/34a06838-efee-4994-b536-8de8560ea8d4

@samdogg7 Thank you very much for this PR and for your accurate comments. I had some of your corrections on target myself but you preceded me 💪! I will check and test your changes as soon as possible 👀.
I am glad that my work has found an audience and a willingness to further improve this package.

@samdogg7 Would you mind creating a cumulative issue briefly listing the fixes you have made? I think it would be useful for us to keep changlelog in an organized way.

No problem! This is awesome. I can definitely write up a consolidated list of changes and comment them here.
I have a few other suggestions that I've left out of this PR- I think I'll open it separately with you. They are preferential, and not necessary fixes.

I definitely opened the PR early 😅 Caught some things after posting it

Thanks, let's focus on this PR and later we can create a list with next improvements/bugs to do.

@wojtek717 here is the change summary:
Changelog
Fixes:

Resolved issue with BottomSheetView becoming permanently hidden.
Smoothed and clamped drag gestures to prevent "jumpy" behavior during long drags.

Enhancements:

Introduced selectedDetent to persist detent state across tabs and allow setting an initial detent (default: smallest).
Refactored BottomSheetViewConfiguration to conform to @Observable and use @State, enhancing state consistency.
Exposed cornerRadius customization for the bottom sheet.
Improved code quality with naming refinements and removal of forced view modifiers (e.g., forced bottom safe area).
Updated the example of BottomSheet.

Best Practices:

Refined handling of ViewBuilder closures in BottomSheet to avoid unintended side effects by removing @escaping in the initializer.

close #11

@samdogg7 One last thing, can you pull latest main branch to this pr so GH Action will run?

@wojtek717 merged main into the branch!


FXGL 3D capabilities question

Hi, I have been using JavaFX for my GUI applications for almost 5 years now, I remember hearing about FXGL a few years ago and by then i still remember it mentioned 'Experimental 3D' in it's readme, i also checked out some of the FXGL 3D videos.
I'm not sure how much FXGL's 3D capabilities have improved since then though.
Recently i had the idea to start a new project, which was my own very simple 3D model editor and i wanted to use JavaFX for it.
The main features i would want it to have are:

Ability to create new triangles with the mouse, either by clicking any point on the screen to create a new vertex or by clicking an existing vertex and then a point on the screen to create an edge
Ability to manipulate existing vertices and triangles with a transformation gizmo (I know how to do this already if i can figure out the first feature)

However even creating the first feature is quite painful with 'pure' JavaFX, because to do that i would need to somehow figure out how to convert a 2D mouse position to 3D, the hardest part has been figuring out the correct depth.
The best way I've found to do this is by using the internal CameraHelper class and it's pickProjectPlane(camera, x, y) method
But i haven't even been able to get that to work nicely, it seems like if i use a PerspectiveCamera with fixedEyeAtCameraZero set to true it never gives the correct result, it is close to some extent tho, if i have it as false then it works better and the only issue is if the camera is zoomed in/out, then the depth values are not what I'd expect, but it also messes with the scale of everything, the docs also say that if i transform the PerspectiveCamera (which i do, as i want to move freely in space with my mouse) then it's recommended for it to be true.
My question is, does FXGL offer anything out of the box that makes projecting 2D mouse coordinates to the 3D scene coordinates any easier? I've also looked at FXyz but couldn't find anything related to that i could easily use for my purpose.
Here is an example GIF (from existing 3d modeling software) of the first feature i mentioned: https://imgur.com/a1txiO0

Hi, I'm afraid there is currently nothing out-of-the-box that supports the first feature you talk about. FXGL's 3D is limited to creating a few extended primitives, loading .obj and being able to translate vertices of a mesh (this last one could be somewhat helpful?).
I wonder if this problem (2D mouse to 3D environment) has a generic engine-agnostic solution somewhere on the web. If so, then it becomes a problem of figuring out how to translate that to JavaFX, which I'm hoping is the easier problem.
P.S. FXyz devs have a lot of experience with 3D, I wonder if they can provide some helpful hints.

Hi, unfortunately this problem of translating it to JavaFX is the hardest part, i know exactly how to do it in raw opengl for example, essentially the steps are:

unproject screen coordinates at z = 0 and z = 1 for the origin and direction, then just subtract the origin from the direction and normalize, that gets the ray
intersect the ray with some plane and the intersection point is the 3D position

From what i know this is not easy to do in JavaFX at all because to unproject, you would need access to the cameras view/projection matrix (or the combined one) which JavaFX doesn't expose, there is an internal CameraHelper#pickProjectPlane but like i already mentioned, this doesn't seem to work correctly with cameras that have their eye position fixed at 0
I'll create an issue in the FXyz repo and hopefully they can help


returning mixed crashes in (at least) php 7.4.26

https://github.com/sebcode/b/blob/29584190cb3a7c079e9c6b80e904669b6e68abcf/src/BookmarkManager.php#L85
returning mixed crashes for me in (at least) php 7.4.26
i guess that if you want to use types, you should rather use:
public function getConfig(string $key): ?string

this will work as long as -- i think to understand -- the configs are done by putenv, which will always return a string (or false... but you're catching that branch in putenv())

php 8 is required as defined in dockerfile :)
nevertheless, agreed that mixed is incorrect here. should be fixed in 720b3d464e568833dfb94595862eee70bdd28c44


Added x86 support

Hello,
I added x86 support so that this crate compiles and works with the target i686. This is an important feature for bootloaders which need to switch to long mode by creating a page table mapping etc.
What did I change?
I changed most of the u64 data types to usize ones. I did not blindly replace them but checked if it actually makes sense.
I also changed the pure asm function definitons by changing the link name of the function depending on your architecture: https://github.com/Luis-Hebendanz/x86_64/blob/master/src/asm/mod.rs#L251
What's missing?
The asm functions implementation and testing them. I'm having trouble testing this because all rust versions I know or have set up have the inline_asm feature.
The i686 build command builds fine, but I am wondering why. External asm functions like _x86_64_asm_set_cs should throw errors because of the use of 64bit registers.
cargo build --target i686-unknown-linux-musl --no-default-features --features external_asm,instructions

Setting up another Github action with the target set to i686.

Thanks for the pull request!
I agree that it would be useful to provide more functions on 32 bit. However, I don't think that switching types from u64 to usize is a good way to achieve this. This crate deliberately uses fixed-size integer types in most places because it represents types of the 64bit x86_64 architecture, independent of the target system the crate is compiled for. The idea is that the crate always describes a 64-bit x86_64 system, even if compiled for 32-bit or even ARM systems.
This is the reason that VirtAddr is a u64 and not an usize, even if compiled for a 32-bit target. And the PageTable type always describes a 64-bit page table, instead of dynamically trying to adjust for the compilation target. This is what makes it possible to create a 64-bit compatible page table from a 32-bit bootloader in the first place.
So the crate deliberate doesn't try to be flexible and support multiple architectures, but to always be compatible with x86_64. For this reason, we represent registers like Cr0 and RFLAGS by fixed-size integer types too. This ensures that they always describe the registers of a 64-bit machine, even if created or inspected from a 32 bit system. Thus, it should be even possible to use this crate on an 32-bit ARM system to analyze a memory dump of an x86_64 system. Switching the register types from u64 to usize would break that property.
For the same reasons, I'm not sure whether it's a good idea to try to port the instructions to 32 bit mode. I agree that it can be  useful, but it makes the purpose of this crate less clear. Also, some instructions might behave slightly different in 32-bit mode (e.g. if paging is disabled), so I would prefer to keep this crate focused on x86_64. After all, we need to keep maintaining the 32-bit instruction implementations if we decide to add 32-bit support to this crate.
For all these reasons, I think that it would make more sense to create a separate crate for most of the functionality introduced in this PR. The crate could be compatible with the x86_64, e.g. provide conversion methods from it EFLAGS type to the RFLAGS type of x86_64. This way, we can keep the purpose of this crate clear, while still supporting 32-bit systems better. What do you think about this approach?

Thanks for the pull request!
I agree that it would be useful to provide more functions on 32 bit. However, I don't think that switching types from u64 to usize is a good way to achieve this. This crate deliberately uses fixed-size integer types in most places because it represents types of the 64bit x86_64 architecture, independent of the target system the crate is compiled for. The idea is that the crate always describes a 64-bit x86_64 system, even if compiled for 32-bit or even ARM systems.
This is the reason that VirtAddr is a u64 and not an usize, even if compiled for a 32-bit target. And the PageTable type always describes a 64-bit page table, instead of dynamically trying to adjust for the compilation target. This is what makes it possible to create a 64-bit compatible page table from a 32-bit bootloader in the first place.
So the crate deliberate doesn't try to be flexible and support multiple architectures, but to always be compatible with x86_64. For this reason, we represent registers like Cr0 and RFLAGS by fixed-size integer types too. This ensures that they always describe the registers of a 64-bit machine, even if created or inspected from a 32 bit system. Thus, it should be even possible to use this crate on an 32-bit ARM system to analyze a memory dump of an x86_64 system. Switching the register types from u64 to usize would break that property.
For the same reasons, I'm not sure whether it's a good idea to try to port the instructions to 32 bit mode. I agree that it can be  useful, but it makes the purpose of this crate less clear. Also, some instructions might behave slightly different in 32-bit mode (e.g. if paging is disabled), so I would prefer to keep this crate focused on x86_64. After all, we need to keep maintaining the 32-bit instruction implementations if we decide to add 32-bit support to this crate.
For all these reasons, I think that it would make more sense to create a separate crate for most of the functionality introduced in this PR. The crate could be compatible with the x86_64, e.g. provide conversion methods from it EFLAGS type to the RFLAGS type of x86_64. This way, we can keep the purpose of this crate clear, while still supporting 32-bit systems better. What do you think about this approach?

Thanks for the code review~

This ensures that they always describe the registers of a 64-bit machine, even if created or inspected from a 32 bit system. Thus, it should be even possible to use this crate on an 32-bit ARM system to analyze a memory dump of an x86_64 system

I never though of that usecase!  Hmm yeah I see, a second crate is probably the way to go here. I will close the pull request and do as you suggested and make a best effort compatible crate (sometime in the future) :-)

Thanks for the code review~

This ensures that they always describe the registers of a 64-bit machine, even if created or inspected from a 32 bit system. Thus, it should be even possible to use this crate on an 32-bit ARM system to analyze a memory dump of an x86_64 system

I never though of that usecase!  Hmm yeah I see, a second crate is probably the way to go here. I will close the pull request and do as you suggested and make a best effort compatible crate (sometime in the future) :-)


The CLI converter stops converting in case a process contains an Umlaut

Describe the bug
If one process model deployed to an engine and contains an Umlaut and gets converted with the CLI converter, you will get an exception and no results.
Steps to reproduce

Model a process with an Umlaut
Deploy it to the process engine
Convert it with the CLI converter
Find the output:

org.camunda.bpm.model.xml.ModelParseException: SAXException while parsing input stream
        at org.camunda.bpm.model.xml.impl.util.DomUtil.parseInputStream(DomUtil.java:245)
        at org.camunda.bpm.model.xml.impl.parser.AbstractModelParser.parseModelFromStream(AbstractModelParser.java:131)
        at org.camunda.bpm.model.bpmn.impl.BpmnParser.parseModelFromStream(BpmnParser.java:65)
        at org.camunda.bpm.model.bpmn.Bpmn.doReadModelFromInputStream(Bpmn.java:250)
        at org.camunda.bpm.model.bpmn.Bpmn.readModelFromStream(Bpmn.java:132)
        at org.camunda.community.migration.converter.cli.ConvertEngineCommand.lambda$modelInstances$1(ConvertEngineCommand.java:59)
        at java.util.stream.Collectors.lambda$toMap$58(Unknown Source)
        at java.util.stream.ReduceOps$3ReducingSink.accept(Unknown Source)
        at java.util.HashMap$EntrySpliterator.forEachRemaining(Unknown Source)
        at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
        at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
        at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
        at java.util.stream.ReferencePipeline.collect(Unknown Source)
        at org.camunda.community.migration.converter.cli.ConvertEngineCommand.modelInstances(ConvertEngineCommand.java:56)
        at org.camunda.community.migration.converter.cli.AbstractConvertCommand.call(AbstractConvertCommand.java:57)
        at org.camunda.community.migration.converter.cli.AbstractConvertCommand.call(AbstractConvertCommand.java:18)
        at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
        at picocli.CommandLine.access$1500(CommandLine.java:148)
        at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
        at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
        at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
        at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
        at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
        at picocli.CommandLine.execute(CommandLine.java:2170)
        at org.camunda.community.migration.converter.cli.ConvertCommand.main(ConvertCommand.java:17)
Caused by: org.xml.sax.SAXException: Fatal Error: URI=null Line=40: Ungültiges Byte 2 von 3-Byte-UTF-8-Sequenz.
        at org.camunda.bpm.model.xml.impl.util.DomUtil$DomErrorHandler.fatalError(DomUtil.java:207)
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
...

Expected Behaviour
The process model gets converted
Library version
egal
Camunda version
egal
Camunda Distribution
Tomcat
Other Camunda distribution
No response

The problem does not lie in our codebase at first glance, we should check how camunda-bpm-platform handles this.

I tried out but could not reproduce. Let's talk and log our results here @ingorichtsmeier

I could reproduce it with the following steps.

Start my windows laptop
Start SpringToolSuite 4.17 (maybe any other eclipse or even IDE helps as well)
Check the workspace setting for file encoding: Windows -> Preferences -> General -> Workspace. My setting is Default: (windows-1252).
Create a new project in the workspace.
Double-check the file encoding on the project: Right click -> Properties -> Resources -> Text file encoding. My setting for Text file encoding is Other: windows-1252.
Open the Camunda modeler and create a new BPMN Diagram with Umlaute.
Save it in the project.
Deploy the model from the Modeler to a running Camunda-7-Platform.
Convert all process models with the command line converter:java -jar backend-diagram-converter-cli-0.4.3.jar engine http://localhost:8081/engine-rest

Check the output and see the stacktrace.
To double-check, delete the deployment from the cockpit.
Convert again like in 9.
All is good, the example diagrams got converted.

Another finding:
If I start the program from the IDE against my engine, everything is fine.
If I start it from the command line against my engine, I get the exception.
Maybe the XML encoding is influenced by system settings that are overridden in the maven build here: https://github.com/camunda-community-hub/camunda-7-to-8-migration/blob/main/pom.xml#L15-L18 (just a rough guess)

The build should stick to UTF-8 encoding, however, we could see if the HTTP clients response encoding/decoding can be set depending on the platform encoding.
Here is the entrypoint for this approach: https://github.com/camunda-community-hub/camunda-7-to-8-migration/blob/fe947d342f1da74ff26210ae97dea13bb29c90b0/backend-diagram-converter/cli/src/main/java/org/camunda/community/migration/converter/cli/ProcessEngineClient.java#L46

These are the characters from the BpmnXml:
09:53:02.629 [main] INFO  o.c.c.m.c.cli.ProcessEngineClient - 228:ä
09:53:02.629 [main] INFO  o.c.c.m.c.cli.ProcessEngineClient - 246:ö
09:53:02.629 [main] INFO  o.c.c.m.c.cli.ProcessEngineClient - 252:ü

This solves the problem:
java -Dfile.encoding=UTF-8 -jar backend-diagram-converter-cli-0.4.3.jar engine http://localhost:8081/engine-rest

It's a Windows issue if you run it on the Windows command line.

Documented here: https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/backend-diagram-converter/cli


can two factor authentication be added on top of NGINX basic HTTP authentication

Hi
I have implemented basic HTTP authentication in NGINX using https://www.digitalocean.com/community/tutorials/how-to-set-up-basic-http-authentication-with-nginx-on-centos-7. But I was wondering if I could use 2 factor authentication on top of above basic one. If so, can anyone guide me the right direction to address it .

Hello @manas86, if you wish to use Authelia, you won't need the setup you've gone through since Authelia will handle the authentication with login/password as a first factor. Basically, Authelia is the authority for users authentication; it handles both first and second factor. So, there is not much configuration to be done at the level of nginx since nginx will only use the auth_request module (http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) to forward session verification requests to Authelia and redirects if the user is not authenticated.
I advise you to deploy Authelia in fews seconds by following the README and try it out yourself :).
Thanks,
Clément.

Hello @manas86, did it answer your question? Can I close the ticket?


Task tree logging should be the same as gulp-cli

When gulp-cli is available globally, running gulp --tasks prints a pretty tree of tasks with colors and task description.
Gulp can also be used without a global gulp-cli, by running it from npm scripts:
"scripts": {
  "help": "gulp --tasks"
  "gulp": "gulp"
}

Now running npm run help will also print the list of gulp tasks. But in this case, the list will be very basic, with no description available.
Would it be conceivable to instead have both modules share the same code and display the same task tree?

They do use the same code https://github.com/gulpjs/gulp/blob/4.0/bin/gulp.js#L3
What versions of local and global gulp are you using?

Absolutely right, I forgot to mention this difference was only present in Gulp 3.

It's a thing added in gulp 4. I'd recommend just updating to 4.0 at this point, if you want the output to be the same.

The very large majority of users are still using Gulp 3. Gulp 4 isn't yet the current version of Gulp,  and there is no estimated release date of Gulp 4. I believe there are enough reasons, and the solution is simple enough, to justify patching Gulp 3.
I am ready to do most of the work if you reconsider the validity of this issue (I can't create the module where the shared code will be, though).

The large majority of users aren't using gulp-cli! :stuck_out_tongue:
I believe gulp 3 is now feature frozen, so I doubt the maintainers would accept a patch adding this functionality. The resources would be best spent getting gulp 4 out of the door—if you're willing to help, that would be super useful!
Check out the outstanding issues here: https://github.com/gulpjs/gulp/issues?q=is%3Aissue+is%3Aopen+label%3Agulp4


Optional go mod tidy

This was mostly implemented, but action.yaml didn't define+forward the input.

just filthy


SW-5951 Upgrade values on all-variables import

When the all-variables CSV is imported, automatically upgrade the values of any
variables that were replaced with new versions.

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

#2374
#2373  👈
#2372
#2371
main

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

Join @sgrimm and the rest of your teammates on  Graphite

Merge activity

Sep 5, 6:09 PM EDT: @sgrimm started a stack merge that includes this pull request via Graphite.


Did a lot of things

I just inspected the project in intellij and fixed a lot of warnings.
All of this does not really matter, but it looks a bit better.
Here is the changelog:

Fix annotation missing from override in NamespaceID.
Remove redundant scopes already included in broader ones in editorconfig.
Trim unused types in editorconfig.
Added quotes in pr.yml as the string contained a -.
Removed references to MinestomConsoleWriter.
Removed redundant suppressions.
Replaced "System.getProperty("line.separator")" with System.lineSeparator().
Removed empty methods, ones that are identical to their super and some other dead code.
Made EntityProjectileDamage inherit from EntityDamage.
Remove some deprecated API usage.
Remove some unused characters.
Remove unused imports and redundant code.
Replace some ifs with switch.
Use more pattern variables.
Do the java 21 SequencedCollection things.
Improve broken javadocs.
Replaced log concatenation with parameterized messages.
Simplify math.
Make some variables a primitive type.
Removed return/continue statements at the end of the function/loop.
Improve updatePose and convertToPacketSlot.
Improve MergedMap size() efficiency.

oops

Comment copied from Discord (https://discord.com/channels/706185253441634317/706186227493109860/1236417810272358530):

It is too big to properly review for a bunch of formatting changes and cleanup changes (i am generally opposed to this > kind of pr). Its possible ill cherry pick some of the named bits into the 1.20.5 branch however


Fix presence update bug (#279)

Copy pasted hydrabolts commit
https://github.com/hydrabolt/discord.js/commit/b436fac5c45fda59d4755f447f7bed9b980ae11a

this is not the right way to fix the issue


Are scripts supposed to work on SageMaker notebook instances?

Hey there, thanks a lot for creating these examples. I've noticed that some scripts have parts that mention sagemaker notebook instances, but they fail both on server and client side because they expect DOMAIN_ID, USER_ID etc.
Are these supposed to work on SageMaker notebook instances?

Hi, @mariokostelac , great to see your interest in the solution.
Which scripts and which commands do you run?
For notebook instances, you should use the sm-local-ssh-notebook. Let me know if it's not the case.

Not really. I've used sm-ssh-ide start to start it from the console, but it really seem to be developed for SageMaker studio
Then I've found
https://github.com/aws-samples/sagemaker-ssh-helper/blob/976e45a53c4234c17b60c5a69a7d2bcd044fea4e/SageMaker_SSH_Notebook.ipynb#L128
and try to change the notebook into a script that I can run on-demand from the terminal, but I get following output:
(base) [ec2-user@ip-172-16-24-195 ~]$ python start_ssh.py
sagemaker.config INFO - Not applying SDK defaults from location: /etc/xdg/sagemaker/config.yaml
sagemaker.config INFO - Not applying SDK defaults from location: /home/ec2-user/.config/sagemaker/config.yaml
[sagemaker-ssh-helper] WARNING: SageMaker SSH Helper is not correctly initialized. Did you forget to call wrapper.create()_before_ fit() / run() / transform() / deploy()?
[sagemaker-ssh-helper] SageMaker SSH Helper startup params: start_ssh=false, ssh_instance_count=1, node_rank=0
[sagemaker-ssh-helper] Skipping SageMaker SSH Helper setup from start_ssh.py

Script
from sagemaker_ssh_helper.wrapper import SSHEstimatorWrapper
from sagemaker.pytorch import PyTorch
import sagemaker
import logging
import os

logging.basicConfig(level=logging.INFO)

import time
import os

import sagemaker_ssh_helper
sagemaker_ssh_helper.setup_and_start_ssh()

while os.environ.get("START_SSH", "false") == "true":
    time.sleep(10)  # will sleep forever

starting it from the terminal would be very useful because I can start it from the lifecycle script etc.

@mariokostelac I see what you're trying to do. You need to copy all the commands from the notebook to your script. Now your import of SSHEstimatorWrapper in your script is unused, but you should use it to trigger the local SageMaker training job in a container:
estimator = PyTorch(entry_point='ssh_notebook.py',
                    source_dir='ssh_notebook/',
                    dependencies=[SSHEstimatorWrapper.dependency_dir()],
                    base_job_name='ssh-notebook',
                    role=sagemaker.get_execution_role(),
                    framework_version='1.9.1',
                    py_version='py38',
                    instance_count=1,
                    instance_type='local',
                    container_log_level=logging.INFO)

ssh_wrapper = SSHEstimatorWrapper.create(estimator, connection_wait_time_seconds=0, local_user_id=local_user_id, log_to_stdout=True)

estimator.fit({'notebook': 'file://'})

Note that you should use instance_type='local' which means the SSH Helper will start on the notebook instance itself without spinning new instances.
Then you need the second script ssh_notebook.py which will be running inside the container and which will trigger the SSH setup logic inside the container.
If you are trying to produce the same lifecycle configuration script as for SageMaker Studio, you won't get the desired result, because SageMaker notebook instance already has the Systems Manager Agent running that will conflict with the Systems Manager Agent that SSH Helper will try to start. That's why you need to start it in a container and the simplest way to do it is through SSHEstimatorWrapper and the local job. Of course, you can also build your own container for this purpose, but it will take more effort.

@ivan-khvostishkov just to make sure that I understand the setup.

Container is really made just to start SMM agent and ssh setup in it.
Notebooks are still run on the SageMaker host outside of the docker container.
Is that a good description?

When I establish SSH over SSM session, is it SSH-ing into SageMaker instance or the docker container?

Not sure if I understood your concerns, but in case of SageMaker Notebook instances, yes, the container is a work-around to run a SSM agent, because another SSM agent is already running on the host and you don't want to break it.
You can run your notebooks both from the host (if you use Notebook Jupyter UI) or from the container itself (if you run another notebook server and access it through SSH). In both cases the notebook file itself can have the same physical location on the host.
Note the file mapping part when you launch the estimator:
estimator.fit({'notebook': 'file://'})

It will ensure the notebook host filesystem is mapped into container and your notebook files will be both available inside the container in /opt/ml/input/data/notebook.

My concern is that ssh into the container is limiting a good chunk capabilities I have in the web terminal. E.g. I can copy files, but I can't install packages, change conda environments properly etc.

Got it now!
But how your development flow looks like in this case? Do you want to install the packages over SSH, but use the packages through the SageMaker Notebook Web UI?
If you connected through SSH, why do don't just start a notebook inside your container env and forget about the packages that are installed on the host machine completely? That is, work only inside the container, just like you would normally do it in  SageMaker Studio?

But how your development flow looks like in this case? Do you want to install the packages over SSH, but use the packages through the SageMaker Notebook Web UI?

Sometimes yes. I manage conda envs, install new packages, run some offline job. I often use it as EC2 machine.

If you connected through SSH, why you don't just start a notebook inside your container env and forget about the packages that are installed on the host machine completely? That is, work only inside the container, just like you would normally do it in SageMaker Studio?

I could do that, but then my VsCode/ssh can disconnect over night (because of Mac power management for example) and lose the work. I'd really like SSH onto the machine, not a machine inside the machine.
I'll see whether SageMaker studio fits this bit better.
Btw I've seen people disabling Amazon's SSM before to do SSH over SSM. Are there any unintended consequences of that?

I could do that, but then my VsCode/ssh can disconnect over night (because of Mac power management for example) and lose the work.

Why would you lose the work? The work will stay inside the container. Once you power on the Mac again, you just reconnect with SSH Helper to the container that will be (hopefully) still running.
I was running a container inside Notebook Instance for many days and the SSM connection from inside the container stays online.
Of course, because it's a single instance (same as your local laptop), you better save your work to some durable location like version control system for code and database or S3 for any data.

I'll see whether SageMaker studio fits this bit better.

SageMaker Studio will be the same.

Btw I've seen people disabling Amazon's SSM before to do SSH over SSM. Are there any unintended consequences of that?

I'm not the right person to answer this question. I think, it worth trying, but to with regards to consequences I recommend to double-check with AWS Support by raising the support case: https://docs.aws.amazon.com/awssupport/latest/user/case-management.html

Why would you lose the work? The work will stay inside the container. Once you power on the Mac again, you just reconnect with SSH Helper to the container that will be (hopefully) still running.

If you attach the vscode into the remote container, and run the notebook from vscode, when vscode loses the connection, you lose the connection to the kernel and it's pretty much impossible to continue working on that kernel.

I was running a container inside Notebook Instance for many days and the SSM connection from inside the container stays online.

I'm not afraid of the container dying, but more of mental overhead of understanding that what you ssh into and what you VsCode into is not really what you see in the Web interface when you open it.
Thanks for explaining @ivan-khvostishkov and thanks for creating this repo. I'm trying to find the service that's going to have the lowest overhead and it seems that SageMaker notebooks might not be that, which is fine. New SageMaker studio maps closely to what I had in mind (I think). I believe I'll be able to setup ssh there too, and get exactly what I wanted.
I saw there were some plans to rewrite bash helpers into python. Do you know if that might happens soon?

Ok, I'm getting your point. Few more ideas from me:

If you attach the vscode into the remote container, and run the notebook from vscode, when vscode loses the connection, you lose the connection to the kernel and it's pretty much impossible to continue working on that kernel.

I'm not sure about VS Code but PyCharm has the nice capability to connect to the remotely running notebook server:

This is the feature that you are probably looking for. Take a look at SageMaker Studio like you are planning to do anyways and let me know how the testing goes. SageMaker SSH Helper will start a separate instance with the remote notebook for you if you use SageMaker Studio (not with SageMaker Notebook Instances, though, you will need to slightly modify the script by yourself). This is how even if you loose the connection and close your laptop lid, the notebook will continue to run remotely and you will reconnect and continue your work from where you have left last time (considering that the instance will be still alive).

I'm not afraid of the container dying, but more of mental overhead of understanding that what you ssh into and what you VsCode into is not really what you see in the Web interface when you open it.

If you mean the filesystem tree structure, then completely agree with you, this is the slight inconvenience coming from the need to run a docker container with different mount point and directories mapping.

I saw there were some plans to rewrite bash helpers into python. Do you know if that might happens soon?

In the new version (spoiler) there will be the sm-ssh tool written in Python, but it will still call bash scripts under the hood. However, it will be a good foundation for further Python refactoring and everyone has the chance to contribute.

@mariokostelac The new release v2.2.0 with sm-ssh tool has just been published. Please feel free to reopen this issue or create a new one if you need further guidance.


Add mlir out of tree build

hi @sylvestre. It has been reproduced in the latest commit
--
Command Output (stderr):
--
CMake Error at /usr/lib/llvm-15/lib/cmake/mlir/AddMLIR.cmake:[283](https://github.com/opencollab/llvm-toolchain-integration-test-suite/runs/6108847481?check_suite_focus=true#step:6:283) (message):
  Cannot build aggregate from imported targets which were not installed via
  MLIR_INSTALL_AGGREGATE_OBJECTS (for MLIRCAPIIR).
Call Stack (most recent call first):
  mlir_dialect/cylib/MLIR/CMakeLists.txt:49 (add_mlir_aggregate)

CMake Error at /usr/lib/llvm-15/lib/cmake/mlir/AddMLIR.cmake:283 (message):
  Cannot build aggregate from imported targets which were not installed via
  MLIR_INSTALL_AGGREGATE_OBJECTS (for MLIRCAPIRegistration).
Call Stack (most recent call first):
  mlir_dialect/cylib/MLIR/CMakeLists.txt:49 (add_mlir_aggregate)

25 files changed, can you please reduce it? it is way big, sorry :(

25 files changed, can you please reduce it? it is way big, sorry :(

the cpp code are removed now.


Only align if data section size contains files

Addresses https://github.com/randovania/mercury-engine-data-structures/pull/108
Is it different for dread? In SR there exists some empty BLA_discardables.pkg. If they have no files in the data section, they also have no 128 byte alignment after the header.

if you're unsure, add a test that rebuilds and compares every pak to make sure everything passes

I don't even know if dread has empty packages but I added a test for dread.


Explicit Error Codes

explicitly number/label each error for visibility when debugging, and to prevent reordering them in the future

Thanks, it's clearer now


gltf convert to glb => encounter mesh glitches issue

Hi, I'm using gltfpack (fantastic tool) to convert/compress my gltf models.
When I try a model, I found the converted binary .glb file have vertices or triangle-indices issue (I'm not very sure).
I downloaded a ship model from free3d.com website (https://free3d.com/3d-model/wwii-ship-uk-king-george-v-class-battleship-v1--185381.html)
And uses blender to convert .obj file to become .gltf file. Then uses gltfpack to convert .gltf file to .glb file.
(command: gltfpack -i <input.gltf> -o <input.flb> [optional: -c | -cc]
Then I rendered that model using my 3d-display html with three.js .
Either compressed or unocmpressed .glb model file has some kind of glitch issue.
I am not sure if I had done something, so try to ask for help here.
original .gltf

converted .glb

Would you mind attaching the glTF file you got from Blender? I've used gltfpack to convert the .obj file directly to .glb and the result doesn't seem to have any issues:

wups @zeux how can we direct convert a .obj to .glb with gltfpack?

@arpu Just specify .obj as an input instead of .gltf/.glb.

Would you mind attaching the glTF file you got from Blender? I've used gltfpack to convert the .obj file directly to .glb and the result doesn't seem to have any issues:

Yes you are right.
If I try to convert .obj to .glb/.gltf directly, everything is fine (rendered correctly) in my three.js web page.
Here is the .gltf model file (.zip) I used blender (v2.91) to export. If this can help..
https://drive.google.com/file/d/1cw_Ui7Rx6lw2bsm7Ey7uoHVwzj7-H2BU/view?usp=sharing

Ah, gotcha. This is a result of this issue: https://github.com/mrdoob/three.js/pull/18871
When you use .obj -> .glb conversion by gltfpack, the bump map is ignored since it can't be represented by glTF.
Your Blender converted scene attaches a bump map into the normal map slot. This results in incorrect shading in general, which is part of the reason for broken shading. The additional issue is that due to texture coordinate quantization, some triangles get a degenerate UV mapping where e.g. U coordinate on multiple vertices is exactly equal. This then causes the bug referenced above.
If you want to work around this bug, you can increase the number of bits gltfpack uses for texture coordinates by e.g. providing -vt 14 as a command-line option (default is 12 which isn't quite sufficient for this model).
Ideally the issue in three.js would be fixed, as e.g. Babylon.JS doesn't suffer from the same issue and renders the model correctly, but I'm not sure if there are any plans to handle degenerate UVs more gracefully:

P.S. It's also possible that you can fix this problem by getting the Blender export to output vertex tangent information, although I haven't checked this.

I’ve submitted a fix to three.js repository - starting with three.js r126 which should release in a couple of weeks the workarounds will not be necessary anymore.


Add vagrant to provide a faster/easier way to run application

In order to fulfill #153  , I wrote a script to provision Tablero with ansible. To make this even easier, I create a config.json file that can be used to setup configs without environment variables.
###How to run

fil the config.json file with your config.
Install Vagrant and Ansible
run vagrant up
open the box with vagrant ssh
run npm start

now tablero will be available on the host machine on localhost:3000

@enzoz Can you check this, please? (:

@rodrigomaia17 :+1: :smile:


Loyalties Program support

Add support for new methods related to Loyalty Programs.
Validation namespace:

Validate Validation Rules: POST /validation-rules/:rule-id/validation - Docs

Rewards namespace:

List: GET /rewards - Docs
Create: POST /rewards - Docs
Get: GET /rewards/:rewardId - Docs
Update: PUT /rewards/:rewardId - Docs
Delete: DELETE /rewards/:rewardId - Docs
List Assignments: GET /rewards/:rewardId/assignments - Docs
Create Assignment: POST /rewards/:rewardId/assignments - Docs
Update Assignment: PUT /rewards/:rewardId/assignments/:assignmentId - Docs
Delete Assignment: DELETE /rewards/:rewardId/assignments/:assignmentId - Docs

Loyalties namespace:

List: GET /loyalties - Docs
Create: POST /loyalties - Docs
Get: GET /loyalties/:campaignId - Docs
Update: PUT /loyalties/:campaignId - Docs
Delete: DELETE /loyalties/:campaignId - Docs
List Reward Assignments: GET /loyalties/:campaignId/rewards - Docs
Create Reward Assignment: POST /loyalties/:campaignId/rewards - Docs
Update Reward Assignment: PUT /loyalties/:campaignId/rewards/:assignmentId - Docs
Delete Reward Assignment: DELETE /loyalties/:campaignId/rewards/:assignmentId - Docs
List Earning Rules: GET /loyalties/{campaignId}/earning-rules - Docs
Create Earning Rules: POST /loyalties/:campaignId/earning-rules - Docs
Update Earning Rules: PUT /loyalties/:campaignId/earning-rules/:earningRuleId - Docs
Delete Earning Rules: DELETE /loyalties/:campaignId/earning-rules/:earningRuleId - Docs
List Members: GET /loyalties/:campaignId/members - Docs
Add Member: POST /loyalties/:campaignId/members - Docs
Get Member: GET /loyalties/:campaignId/members/:memberId - Docs
Add Points: POST /loyalties/:campaignId/members/:memberId/balance - Docs
Redeem Reward: POST /loyalties/:campaignId/members/:memberId/redemption - Docs

Redemption:

Redeem Voucher, added reward property: Docs
Redeem Voucher (client), added reward property Docs

Events:

Track Event, added loyalty property Docs
Track Event (client), added loyalty property Docs

@bandraszyk I created a PR which adds new methods to the SDK
https://github.com/voucherifyio/voucherify-nodejs-sdk/pull/95
@frakti A review will be very useful. Particularly noteworthy are the methods for redeeming rewards and adding points in the loyalty namespace.

@bandraszyk I guess we can close the ticket, can't we?


New insecure flag

Hi @grobie , we have an issue with certificate validation when scraping from inside VPN.
in order to bypass this, i added an insecure flag. maybe it helps somebody else.
for sure it is not the best solution, but i am willing to learn if i made mistakes :)
Can't scrape HAProxy: Get https://foo.bar.somedomain.io/stats;csv: x509: certificate is valid for *.somedomain.io, somedomain.io, not foo.bar.somedomain.io  source=haproxy_exporter.go:298

@ionutvilie You shouldn't need TLS to begin with. The haproxy_exporter is supposed to run on the same machine as HAProxy. Then you can simply use HTTP or a unix socket and scrape the process running on localhost.

Well, I merged #86 in the end.


Examine possible OOM issues and fix them

This issues consists of conducting a preliminary analyses on where we could have possible OOM issues inside the sidecar.
For example, the account_states map
https://github.com/chainbound/bolt/blob/51f474c274bb781ba312fee1b5cd732b6f1dfdca/bolt-sidecar/src/state/execution.rs#L137-L164
can grow indefinitely and it is currently not cleared. However it is very small: only 48 bytes per AccountState and a total of 92 bytes  per entry if we include 20 bytes for the Address key, 16 bytes for the key and value pointer and 8 bytes of internal metadata. This means 1 GiB of memory can cover ~22 millions of addresses.
This possible OOM issue should be addressed nonetheless, and a similar analysis should be conducted in other parts of the sidecar.

Regarding the account_state map an LRU cache isn't good for the job. The reason is that an entry is updated in two places:

when receiving a commitment request from the user
after that, at every slot to fetch its state update
so we cannot use the notion of "recently used" for clearing up stale entries that made a commitment requests a lot of epochs ago.
Ideally, it should incorporate a scoring logic where we give a good boost when the cache is accessed upon receiving a commitment from that user.

There are LRU map implementations that have some methods to modify / read elements without promoting them. I think schnellru is one (check out the peek methods)

This is cool and provides some hooks upon insertion, deletion and replace. It still doesn't serve our purpose because we need indeed a custom scoring logic. I'm writing a wrapper over an HashMap, will link a PR soon!

Here we can see a ~10MiB bump in memory when proposing a PBS block, and such memory hasn't been allocated since. This is on Holesky with tag v0.3.0:alpha.rc2 started the 13th of November. We should restart it with the latest image and track it again, since I don't see any concerning log yet.


Build breaks in flutter project

After adding the specified pod to my Podfile I am no longer able to build the app and it fails with below output.
This only happens after ive added the documented pod to my podfile and run pod install.
Ive also tried to remove Podfile.lock and rerun pod install but it has no effect.
If I remove pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '9.3.0' from Podfile it works again.
Im not experienced with iOS development so I did not know how to exactly title this issue.
Flutter pubspec.yaml:
...
  #
  # Firebase dependencies
  #
  firebase_analytics: ^9.3.0
  firebase_auth: ^3.5.1
  firebase_core: ^1.20.0
  firebase_crashlytics: ^2.8.6
  firebase_dynamic_links: ^4.1.1
  firebase_messaging: ^12.0.1
  firebase_storage: ^10.3.3
  firebase_remote_config: ^2.0.13
  cloud_firestore: ^3.4.3
  cloud_functions: ^3.3.3
  firebase_app_check: ^0.0.6+18
  firebase_performance: ^0.8.2+1

...

Podfile:
# Uncomment this line to define a global platform for your project
platform :ios, '11.0'

# CocoaPods analytics sends network stats synchronously affecting flutter build latency.
ENV['COCOAPODS_DISABLE_STATS'] = 'true'

project 'Runner', {
  'Debug' => :debug,
  'Profile' => :release,
  'Release' => :release,
}

def flutter_root
  generated_xcode_build_settings_path = File.expand_path(File.join('..', 'Flutter', 'Generated.xcconfig'), __FILE__)
  unless File.exist?(generated_xcode_build_settings_path)
    raise "#{generated_xcode_build_settings_path} must exist. If you're running pod install manually, make sure flutter pub get is executed first"
  end

  File.foreach(generated_xcode_build_settings_path) do |line|
    matches = line.match(/FLUTTER_ROOT\=(.*)/)
    return matches[1].strip if matches
  end
  raise "FLUTTER_ROOT not found in #{generated_xcode_build_settings_path}. Try deleting Generated.xcconfig, then run flutter pub get"
end

require File.expand_path(File.join('packages', 'flutter_tools', 'bin', 'podhelper'), flutter_root)

flutter_ios_podfile_setup

target 'Runner' do

  use_frameworks!

  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))

  # See https://github.com/invertase/firestore-ios-sdk-frameworks
  pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '9.3.0'
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)
  end
end

Output:
Error output from Xcode build:
↳
    2022-08-04 17:02:30.182 xcodebuild[24482:1409455] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
    2022-08-04 17:02:30.182 xcodebuild[24482:1409455] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
    ** BUILD FAILED **

Xcode's output:
↳
    Writing result bundle at path:
        /var/folders/39/gmxs8gmd6b98tg0n8dsz0zjw0000gn/T/flutter_tools.UcLLVR/flutter_ios_build_temp_dirLqs2Bi/temporary_xcresult_bundle

    4 warnings generated.
    1 warning generated.
    4 warnings generated.
    1 warning generated.
    35 warnings generated.
    warning: [CP] FirebaseFirestore.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64 ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] gRPC-Core.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64 ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] Libuv-gRPC.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator ios-arm64' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] gRPC-C++.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator ios-arm64' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] BoringSSL-GRPC.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] FirebaseFirestoreSwift.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64 ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] abseil.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64 ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    warning: [CP] leveldb-library.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator' for the current build architectures (arm64 armv7) and platform (-iphoneos).
    /Users/user/Projects/flutter/project/ios/Pods/DKPhotoGallery/DKPhotoGallery/DKPhotoGalleryContentVC.swift:39:52: warning: using 'class' keyword to define a class-constrained protocol is deprecated; use 'AnyObject' instead
    internal protocol DKPhotoGalleryContentDataSource: class {
                                                       ^~~~~
                                                       AnyObject
    /Users/user/Projects/flutter/project/ios/Pods/DKPhotoGallery/DKPhotoGallery/DKPhotoGalleryContentVC.swift:55:50: warning: using 'class' keyword to define a class-constrained protocol is deprecated; use 'AnyObject' instead
    internal protocol DKPhotoGalleryContentDelegate: class {
                                                     ^~~~~
                                                     AnyObject
    remark: Incremental compilation has been disabled: it is not compatible with whole module optimization
    /Users/user/Projects/flutter/project/ios/Pods/DKPhotoGallery/DKPhotoGallery/DKPhotoGalleryContentVC.swift:39:52: warning: using 'class' keyword to define a class-constrained protocol is deprecated; use 'AnyObject' instead
    internal protocol DKPhotoGalleryContentDataSource: class {
                                                       ^~~~~
                                                       AnyObject
    /Users/user/Projects/flutter/project/ios/Pods/DKPhotoGallery/DKPhotoGallery/DKPhotoGalleryContentVC.swift:55:50: warning: using 'class' keyword to define a class-constrained protocol is deprecated; use 'AnyObject' instead
    internal protocol DKPhotoGalleryContentDelegate: class {
                                                     ^~~~~
                                                     AnyObject
    /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_core-1.20.0/ios/Classes/FLTFirebaseCorePlugin.m:229:50: warning: incompatible pointer to integer conversion sending 'NSNumber * _Nonnull __strong' to parameter of type 'BOOL' (aka 'signed char') [-Wint-conversion]
        [firebaseApp setDataCollectionDefaultEnabled:enabled];
                                                     ^~~~~~~
    In module 'FirebaseCore' imported from /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_core-1.20.0/ios/Classes/FLTFirebasePlugin.h:10:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseCore/FirebaseCore/Sources/Public/FirebaseCore/FIRApp.h:125:10: note: passing argument to parameter 'dataCollectionDefaultEnabled' here
        BOOL dataCollectionDefaultEnabled;
             ^
    1 warning generated.
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:38: warning: 'UNMutableNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
                                         ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:97:12: note: 'UNMutableNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNMutableNotificationContent : UNNotificationContent
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:38:47: warning: 'UNNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
                     withContentHandler:(void (^)(UNNotificationContent *_Nonnull))contentHandler;
                                                  ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:37:12: note: 'UNNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNNotificationContent : NSObject <NSCopying, NSMutableCopying, NSSecureCoding>
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    2 warnings generated.
    2 warnings generated.
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:38: warning: 'UNMutableNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
                                         ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:97:12: note: 'UNMutableNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNMutableNotificationContent : UNNotificationContent
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:38:47: warning: 'UNNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
                     withContentHandler:(void (^)(UNNotificationContent *_Nonnull))contentHandler;
                                                  ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:37:12: note: 'UNNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNNotificationContent : NSObject <NSCopying, NSMutableCopying, NSSecureCoding>
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    2 warnings generated.
    2 warnings generated.
    /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_auth-3.5.1/ios/Classes/FLTFirebaseAuthPlugin.m:90:72: warning: sending 'FLTFirebaseAuthPlugin *__strong' to parameter of incompatible type 'id<FLTFirebasePlugin> _Nonnull'
        [[FLTFirebasePluginRegistry sharedInstance] registerFirebasePlugin:self];
                                                                           ^~~~
    In module 'firebase_core' imported from /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_auth-3.5.1/ios/Classes/FLTFirebaseAuthPlugin.m:7:
    /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_core-1.20.0/ios/Classes/FLTFirebasePluginRegistry.h:23:64: note: passing argument to parameter 'firebasePlugin' here
    - (void)registerFirebasePlugin:(id<FLTFirebasePlugin> _Nonnull)firebasePlugin;
                                                                   ^
    1 warning generated.
    /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_auth-3.5.1/ios/Classes/FLTFirebaseAuthPlugin.m:90:72: warning: sending 'FLTFirebaseAuthPlugin *__strong' to parameter of incompatible type 'id<FLTFirebasePlugin> _Nonnull'
        [[FLTFirebasePluginRegistry sharedInstance] registerFirebasePlugin:self];
                                                                           ^~~~
    In module 'firebase_core' imported from /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_auth-3.5.1/ios/Classes/FLTFirebaseAuthPlugin.m:7:
    /Users/user/.pub-cache/hosted/pub.dartlang.org/firebase_core-1.20.0/ios/Classes/FLTFirebasePluginRegistry.h:23:64: note: passing argument to parameter 'firebasePlugin' here
    - (void)registerFirebasePlugin:(id<FLTFirebasePlugin> _Nonnull)firebasePlugin;
                                                                   ^
    1 warning generated.
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:38: warning: 'UNMutableNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
                                         ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:97:12: note: 'UNMutableNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNMutableNotificationContent : UNNotificationContent
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:38:47: warning: 'UNNotificationContent' is only available on iOS 10.0 or newer [-Wunguarded-availability]
                     withContentHandler:(void (^)(UNNotificationContent *_Nonnull))contentHandler;
                                                  ^
    In module 'UserNotifications' imported from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:22:
    /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk/System/Library/Frameworks/UserNotifications.framework/Headers/UNNotificationContent.h:37:12: note: 'UNNotificationContent' has been marked as being introduced in iOS 10.0 here, but the deployment target is iOS 9.0.0
    @interface UNNotificationContent : NSObject <NSCopying, NSMutableCopying, NSSecureCoding>
               ^
    While building module 'FirebaseMessaging' imported from /Users/user/Projects/flutter/project/ios/Pods/Headers/Public/Firebase/Firebase.h:66:
    In file included from <module-includes>:1:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/Target Support Files/FirebaseMessaging/FirebaseMessaging-umbrella.h:13:
    In file included from /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FirebaseMessaging.h:18:
    /Users/user/Projects/flutter/project/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessagingExtensionHelper.h:37:1: note: annotate 'populateNotificationContent:withContentHandler:' with an availability attribute to silence this warning
    - (void)populateNotificationContent:(UNMutableNotificationContent *)content
    ^
    2 warnings generated.
    2 warnings generated.
    2 warnings generated.
    1 warning generated.
    In file included from /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:8:
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:43:4: error: expected a type
    + (FIRFirestoreSource)FIRFirestoreSourceFromArguments:(NSDictionary *_Nonnull)arguments;
       ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:45:4: error: expected a type
    + (FIRFirestore *_Nullable)getCachedFIRFirestoreInstanceForKey:(NSString *_Nonnull)key;
       ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:46:40: error: expected a type
    + (void)setCachedFIRFirestoreInstance:(FIRFirestore *_Nonnull)firestore
                                           ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:12:33: error: no type or protocol named 'FIRListenerRegistration'
    @property(readwrite, strong) id<FIRListenerRegistration> listenerRegistration;
                                    ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:19:3: error: use of undeclared identifier 'FIRFirestore'
      FIRFirestore *firestore = arguments[@"firestore"];
      ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:19:17: error: use of undeclared identifier 'firestore'
      FIRFirestore *firestore = arguments[@"firestore"];
                    ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:27:32: error: use of undeclared identifier 'firestore'
      self.listenerRegistration = [firestore addSnapshotsInSyncListener:listener];
                                   ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:33:30: error: no known instance method for selector 'remove'
      [self.listenerRegistration remove];
                                 ^~~~~~
    8 errors generated.
    note: Using new build system
    note: Planning
    note: Build preparation complete
    note: Building targets in dependency order
    /Users/user/Projects/flutter/project/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.5.99. (in target 'TOCropViewController-TOCropViewControllerBundle' from project 'Pods')
    /Users/user/Projects/flutter/project/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.5.99. (in target 'TOCropViewController' from project 'Pods')
    /Users/user/Projects/flutter/project/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.5.99. (in target 'FMDB' from project 'Pods')
    /Users/user/Projects/flutter/project/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.5.99. (in target 'AppAuth' from project 'Pods')

    Result bundle written to path:
        /var/folders/39/gmxs8gmd6b98tg0n8dsz0zjw0000gn/T/flutter_tools.UcLLVR/flutter_ios_build_temp_dirLqs2Bi/temporary_xcresult_bundle

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:42:3

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:44:3

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:45:39

Generics Issue (Xcode): No type or protocol named 'FIRListenerRegistration'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:11:32

Semantic Issue (Xcode): Use of undeclared identifier 'FIRFirestore'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:18:2

Semantic Issue (Xcode): Use of undeclared identifier 'firestore'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:18:16

Semantic Issue (Xcode): Use of undeclared identifier 'firestore'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:26:31

ARC Semantic Issue (Xcode): No known instance method for selector 'remove'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:32:29

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:82:39

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:89:37

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:135:39

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:143:45

Parse Issue (Xcode): Expected a type
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:166:36

Semantic Issue (Xcode): Use of undeclared identifier 'FIRTimestamp'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:18:35

Semantic Issue (Xcode): Unknown type name 'FIRTimestamp'; did you mean 'CVTimeStamp'?
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:19:4

ARC Casting Rules (Xcode): Implicit conversion of Objective-C pointer type 'id' to C pointer type 'CVTimeStamp *' requires a bridged cast
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:19:30

Semantic Issue (Xcode): Member reference type 'CVTimeStamp *' is a pointer; did you mean to use '->'?
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:20:30

Semantic Issue (Xcode): No member named 'seconds' in 'CVTimeStamp'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:20:31

Semantic Issue (Xcode): Member reference type 'CVTimeStamp *' is a pointer; did you mean to use '->'?
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:21:31

Semantic Issue (Xcode): No member named 'nanoseconds' in 'CVTimeStamp'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:21:32

Semantic Issue (Xcode): Use of undeclared identifier 'FIRGeoPoint'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:25:35

Semantic Issue (Xcode): Use of undeclared identifier 'FIRGeoPoint'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:26:4

Semantic Issue (Xcode): Use of undeclared identifier 'geoPoint'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:26:17

Semantic Issue (Xcode): Use of undeclared identifier 'geoPoint'
/Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTFirebaseFirestoreWriter.m:27:23

Error (Xcode): too many errors emitted, stopping now

Encountered error while building for device.
make: *** [ios] Error 1

I have the same error when doing flutter build ios.
From this answer (in a forum), it seems like this is not a Flutter nor Firebase problem since the same error message is output when executing xcodebuild --help in the command line.
Part of flutter build ios output:
Running pod install...                                             27.8s
Running Xcode build...
Xcode build done.                                           42.1s
Failed to build iOS app
Error output from Xcode build:
↳
    2022-08-12 17:37:57.105 xcodebuild[53770:692714] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension
    Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
    2022-08-12 17:37:57.106 xcodebuild[53770:692714] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension
    Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
    ** BUILD FAILED **

Part of xcodebuild --help output
2022-08-12 17:39:00.769 xcodebuild[54518:695248] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore
2022-08-12 17:39:00.770 xcodebuild[54518:695248] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore

Any updates on this issue? I have been having this for more than a month now and I have just commented out FirebaseFirestore to get it working. But build times are 45+ mins :(

Sorry @sathishgovindarajuworks (and @crtl ) I've been traveling so haven't had time to look personally. And no one else has volunteered their time, so no triage has been done.
So, no updates no (in general open source means you get what you see: there are no hidden updates, either way)
Mostly commenting to say that a proper implementation of https://ccache.dev/ will work around slow compilation for you quite effectively. In CI with firestore compiling I see compilation times of just a few minutes typically. Here's a whole recipe for you using https://github.com/hendrikmuhs/ccache-action - https://github.com/invertase/react-native-firebase/blob/main/.github/workflows/tests_e2e_ios.yml
note especially
https://github.com/invertase/react-native-firebase/blob/main/.github/workflows/tests_e2e_ios.yml#L75-L80
these to make sure Xcode is cached effectively
https://github.com/invertase/react-native-firebase/blob/main/.github/workflows/tests_e2e_ios.yml#L75-L80
and then these instructions (which are about the same between flutter and react-native) to get Xcode to use ccache https://reactnative.dev/docs/build-speed#xcode-specific-setup

I had a chance to scan this just a little more - I wonder if your flutter project needs to change it's ios deployment target to 9+
In the Xcode trace you should remove all warnings and notes, and focus just on the errors. They are here

    In file included from /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:8:
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:43:4: error: expected a type
    + (FIRFirestoreSource)FIRFirestoreSourceFromArguments:(NSDictionary *_Nonnull)arguments;
       ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:45:4: error: expected a type
    + (FIRFirestore *_Nullable)getCachedFIRFirestoreInstanceForKey:(NSString *_Nonnull)key;
       ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/Private/FLTFirebaseFirestoreUtils.h:46:40: error: expected a type
    + (void)setCachedFIRFirestoreInstance:(FIRFirestore *_Nonnull)firestore
                                           ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:12:33: error: no type or protocol named 'FIRListenerRegistration'
    @property(readwrite, strong) id<FIRListenerRegistration> listenerRegistration;
                                    ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:19:3: error: use of undeclared identifier 'FIRFirestore'
      FIRFirestore *firestore = arguments[@"firestore"];
      ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:19:17: error: use of undeclared identifier 'firestore'
      FIRFirestore *firestore = arguments[@"firestore"];
                    ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:27:32: error: use of undeclared identifier 'firestore'
      self.listenerRegistration = [firestore addSnapshotsInSyncListener:listener];
                                   ^
    /Users/user/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-3.4.3/ios/Classes/FLTSnapshotsInSyncStreamHandler.m:33:30: error: no known instance method for selector 'remove'
      [self.listenerRegistration remove];
                                 ^~~~~~
    8 errors generated.

Looks to me like some sort of huge issue with imports/includes. That usually implies an easy fix (huge things are usually an obvious simple thing like one missing import statement) but I could be wrong. I would need to see the steps you can take to create a project with this problem

Hello, someone has found a solution for this issue there:
https://github.com/firebase/flutterfire/issues/9015#issuecomment-1193825846

@paulb777 - @kevin-trancoso5 has pointed to a comment that is I think the correct root cause analysis
I missed this PR / changelog note where you bumped the minimum versions for zip distribution https://github.com/firebase/firebase-ios-sdk/pull/9633 / https://firebase.google.com/support/release-notes/ios#zip_and_carthage_users
Apologies everyone!
From @szotp-lc

The problem is occuring because:
invertase library no longer includes arm7v binaries (8.15 still had them),
cloud_firestore still technically supports [iOS 10] (https://github.com/firebase/flutterfire/blob/master/packages/cloud_firestore/cloud_firestore/ios/cloud_firestore.podspec#L32).
iOS 10 is the last version that supports iPhone 5c (32 bit / arm7v device)
Cocoapods wants to build iOS 10, sees there is no arm7v for some dependencies, and derps-out.
Although it's technically problem of invertase, it would make a lot of sense to raise the deployment target in this repo to iOS 11.

I will bump minimum versions supported here from 10 to 11 corresponding to this change. If people still need to support 10, they'll have to use the cocoapods distribution and accelerate another way (ccache is my favorite)

Good catch @mikehardy. Also https://github.com/firebase/firebase-ios-sdk is planning to update to iOS 11 in the next major version, largely because Xcode 14 is doing so.
Given that the zip builder has already changed to iOS 11, agreed that the invertase podspecs should change now.

For everyone that is affected by this, you might try the tag '9.5.0-1' here to see if it helps you.
You will need an iOS minimum deployment target of 11 set in your Podfile and your app info via Xcode to avoid other problems I think
Assuming this works, it's a closed issue and the next release will auto-magically incorporate the change :crossed_fingers:


[Vulnerability] pyzmq 22.2.1 contains security vulnerabilities

pyzmq.libs/libkrb5-d3f87200.so.3.3、pyzmq.libs/libpcre-6b975b27.so.1.2.0 contains many security vulnerabilities.
The vulnerabilities include the following:
libkrb5-d3f87200.so.3.3:CVE-2021-36222、CVE-2018-5730、CVE-2018-5729、CVE-2017-7562、CVE-2018-5710、CVE-2017-11368
libpcre-6b975b27.so.1.2.0:CVE-2017-13846、CVE-2020-14155、CVE-2019-20838、CVE-2016-3191
Please confirm these.
Vulnerability query address:https://nvd.nist.gov/search

Just to confirm, you are using the new linux arm wheels? Those are the only ones bundling libkrb5/libpcre, which come from CentOS 7 and are up-to-date with upstream. Can I get more information on how you are using them and your environment setup?

This pyzmq is contained in salt 3002.5 and is used in EulerOS and CentOS.

How did you determine that these vulnerabilities were present? For instance, when I lookup CVE-2018-5730, it was fixed in krb5-libs-1.15.1-34, but the wheels bundle a build that is much more recent than that (1.15.1-50). When I run scans myself via snyk or trivy, I don't turn up any results.

I scanned it using a self-developed tool, the scanned files are pyzmq.libs/libkrb5-d3f87200.so.3.3 and libpcre-6b975b27.so.1.2.0.
Maybe take a look at the detailed vulnerability description.


convert indexing arrays to int to avoid future deprecation

This PR just gets rid of some deprecation warnings using numpy 1.11 from non-integer indices. The default for the bins in irradiance.py is now 0 (versus the old NaN), which may or may not be a problem. Maybe the default should be something else?

The 0 will turn into a -1, which will be a valid indexer and as you said may be a problem. Alternatively, we could use an int that is two larger than the number of elements in each array, so that invalid values ultimately result in an IndexError. The problem here is that I think this means that nans in the input data will result in IndexErrors, which is also unfortunate. I suppose we can add nan filters, but that's one more complication to test.
I think that we can use defaults of pd.Series(np.nan, index=times, dtype=np.object), but I'm not sure what the performance hit would be. It's probably minor for most applications.
Annoying that numpy doesn't support integer nans.

I'd like to resolve this one way or another, but I don't care what we do. Thoughts?


WPS-Office isn't working

Describe the bug
I tried to install WPS-Office from this derivation: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/office/wpsoffice/default.nix through home-manager
And I got this error:
0curl: (6) Could not resolve host: kdl.cc.ksosoft.com
To Reproduce
Steps to reproduce the behavior:
Try to install wpsoffice

@Ninlives

Hi @Th0rgal, looks like wpsoffice has changed their host for downloading, I've updated the url and has in https://github.com/NixOS/nixpkgs/pull/76731


SLING-5341 - Update jackrabbit version in commons.testing

@joelrich - the Jira issue has been resolved, can you please close the pull request?


Support newest Hugo version (0.81.0)

Now, Pages only supports Hugo 0.54, and have a lot of bugs with Hugo 0.81.0, can't deploy my sites.

You can simply set the environment variable HUGO_VERSION to the appropriate version and this will work.
Please see this pull request for more details: https://github.com/cloudflare/cloudflare-docs/pull/896.


Database table list listed

Issue Type: Bug

Open the list of servers
Expand a connection (under Servers)
I would expect to see a list of tables from the database, but nothing is shown

I can find tables manually and query data by writing queries manually (eg. "SELECT * FROM orders" is working).

The database properties doesn't work either:

Azure Data Studio version: azuredatastudio 1.25.1 (e7eacc32c0d20bd4da843320c3bfac231b308c98, 2020-12-11T01:57:41.946Z)
OS version: Darwin x64 20.2.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
1, 2, 2

Memory (System)
32.00GB (2.07GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

agent
Mic
0.48.0

datavirtualization
Mic
1.10.0

application-logs.zip
console.log
Please see the attached files.

application-logs.zip
console.log
Please see the attached files.

@martinthogersen Have you updated to the latest version? Please let me know if you're still experiencing this issue.


Changes to file test/components/hello.world.jsx are lost

Changes to file test/components/hello.world.jsx are lost (rewritten with this commit: https://github.com/indooorsman/esbuild-css-modules-plugin/commit/9e426f5b679101b9400a6146429ef8ce2e31eef3#diff-b9ff8c20d74d99f9fd7ea9244e1d89a896466cee6737312c9686bb45851a454a). I think that was happen accidentally, so it would be nice to restore them :).
Originally posted by @maestrow in https://github.com/indooorsman/esbuild-css-modules-plugin/issues/2#issuecomment-898848515

@maestrow restored, sorry for the mistake


Running on iOS 10 simulator issue

I know that iOS simulator doesn't support Metal.
But I need to test other features on iOS 10 simulator and can't start app.
On iOS 11 and iOS 12 simulators app starts.
I get this error:
dyld: Library not loaded: /System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders
  Referenced from: /Users/Igor/Library/Developer/CoreSimulator/Devices/D3924F1D-AC68-4A71-BBDB-710DDB67948D/data/Containers/Bundle/Application/3A2F03A1-17E4-4128-B1D4-067A9C66B230/Unfold.app/Frameworks/MetalPetal.framework/MetalPetal
  Reason: no suitable image found.  Did find:
	/System/Library/Frameworks/MetalPerformanceShaders.framework/MetalPerformanceShaders: mach-o, but not built for iOS simulator

How can I fix this?

simulator is not support.

There seems no easy fix for this issue. Apple did not ship "MetalPerformanceShaders.framework" with the iOS 10 simulator. The only way to resolve this issue is try not to link that framework, which involves  lots of code change and conditional compile directives.
I'll look into this when time permits.

Thank you!

@YuAo Check, please, could https://github.com/xmartlabs/MetalPerformanceShadersProxy be useful for this fix?

Nop.

No.

Fixed. (in version 0.9.5)

Fixed. (in version 0.9.5)

Thank you!


Having issues using the plugin

Hey, after following install instructions, this is the error I get:
Uncaught error: Cannot read properties of undefined (reading 'layout')
TypeError: Cannot read properties of undefined (reading 'layout')
    at Poi (https://xxx/static/sanity-a8e1b759.js:7916:23561)
    at https://xxx/static/sanity-a8e1b759.js:7916:23787

I guess I am missing something obvious, as always!

+1 I'm migrating from V2 and I'm running into this error.


Log prints stack traces to standard error instead of logging them

The Log methods taking a Throwable always write the stack trace to standard error.
I was always wondering whether my config was wrong until I looked into the source: it actually uses Throwable.printStackTrace. Is this by design? I really need stack traces in the regular log output.

This was by design, to provide a way to log the error and print stack trace on std-err when calling e.g. Log.error(msg, err);.
The functionality that you need can be achieved by providing the exception as argument e.g. Log.error(msg, "error", err);.
However, I am refactoring the logging mechanism now, to unify both ways of logging, which will reduce the surprises like that. The target output for stack traces will be configurable.

Thanks, works for me! (And you are right about surprises - I'd never have guessed that the stack trace would be printed when the Throwable is given as an argument).


Remove unnecessary Makefiles from in-tree extensions

I am considering this issue blocked on merging #1245 so that as to not duplicate some work.


Project name change

The project is expanding and thus its name is changed

if you fix the conflicts i can merge it


libsForQt5.qtstyleplugin-kvantum: 0.11.2 -> 0.20.0

Motivation for this change
Update to version 0.20.0
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.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.

Result of nixpkgs-review pr 126476 at 36d4744e run on aarch64-linux 1

1 package failed to build:

libsForQt512.qtstyleplugin-kvantum

2 packages built successfully:

libsForQt5.qtstyleplugin-kvantum (libsForQt515.qtstyleplugin-kvantum ,plasma5Packages.qtstyleplugin-kvantum)
libsForQt514.qtstyleplugin-kvantum

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

Can you mark the package broken on qt5.version less than 5.14?


Regression with Timeouts and/or UdpSockets?

I hadn't intended to upgrade tokio yet, but did after a cargo update. After running my standard integration test suites, one of my timeout tests started hanging. I haven't had time to investigate deeply, but wanted to notify as quickly as possible about this. This appears to be specifically related to Udp and not Tcp.
As I haven't had time to dig into why the test is hanging, I'm assuming it's not Timeouts but something with the UdpSocket, due to no issues seen with Tcp.
reproduce with this repo: https://github.com/bluejekyll/trust-dns
hung:
cargo test --manifest-path integration-tests/Cargo.toml --test client_future_tests test_timeout_query_udp

very similar test and code path, but TCP works:
cargo test --manifest-path integration-tests/Cargo.toml --test client_future_tests test_timeout_query_tcp

This appears to have been introduced with tokio-core at 0.1.13 and continues through to 0.1.15

Could this be related to #311? I’ll try and dig into the details when I have some time later today.

It still hangs w/ the fix from #311, so I will try investigating as well

Sorry! I forgot to give you a branch! tokio-core will need to be upgraded before reproducing.

I looked through the trust-dns source. I'm wondering if this is a case of "it just happened to work" before and the internal implementation change exposed a bug.
You create the timeout [here]: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/dns_handle.rs#L304
The only place I see the timeout polled is [here]: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/dns_handle.rs#L192
So, it looks like you never poll the timeout until the next iteration of DnsFuture::poll, but nothing will actually notify the DnsFuture task (because the timeout is never polled), so poll will never be called.
I'm pretty sure I fixed some code that caused unnecessary spurious notifications, so it is possible that this broke the tests.
Hope this helps.

Thanks for taking a look! I’ll double check the logic in that section and correct it.

I'm going to close this issue. If I am wrong, please comment and I can open it up again.
Cheers.


Remove cobra/viper dependency

This project seems to be one of the only projects within Prometheus that uses cobra/viper for configuration.  In order to standardize things, and possibly reduce @TheTincho workload, I think it would be better to follow the standard use of kingpin.v2 and yaml.v2.
See: https://github.com/prometheus/promu/pull/91

@pgier I think this is done now. :grin:

@SuperQ yep, I think this can be closed.